Panel access throws NetworkError opens the panel as expected. aborts with message:

NetworkError when attempting to fetch resource.

Any ideas to solve this, because customer only wants to use www-variant and redirect all other variants (http, non-www, etc) to this domain as well.

Kirby Version 3.4.
php 7.4
Provider: ionos

Additional info:

Firefox reports:
NetworkError when attempting to fetch resource.

Safari reports
Preflight response is not successful

To me that sounds like something is wrong with the server config that handles the redirect from non-www to www. Where does this happen? In .htaccess or in httpd.conf or the nginx config if you are on Nginx.

I have removed the redirects for testing purposes.
Now the page is accessible via:

The panel without www is running.
The panel with www is not.

Same as here, it seems: Cannot connect to Panel on Server - Strange Errors - #7 by nedimbora

Unfortunately, it doesn’t say if the problem was solved.

yes. i found this article as well. :frowning:

maybe it has something to do with the way kirby handles proper headers.

It’s already been asked above, but ow did you implement the redirect?

Also, what do you see in the network tab?

I don’t use a redirect for test purpose anymore.
Both variants (www and non-www) are accessible now.
The panel works on the non-www-version and www-version shows the mentioned error above.

Attached screenshot with the error:

I wonder why it automatically redirects to the non-www version. There seems to be something wrong on that end. Also, I wonder why you get this OPTIONS request at all. Is there anything in your config file? When exactly does this show up? When trying to log in?

There is nothing special in the Kirby configuration and I have no way to check the server settings and no idea about it.
The message appears directly after accessing the url. Not redirect happens.

This is not good, how should one analyze the problem without knowing the details?

Just a guess: Your redirection does not operate correct. The CORS error from your screenshot indicates that there is an API call from to - or vice versa. To mitigate, you could add a Access-Control-Allow-Origin header in your webserver/vhost config with the URL of the other site resp.

However, if the root cause is really a misconfigured redirection, I would recommend to work on this end. If you really like to use only and uncoditionally send requests from to, I would set the A-record of the DNS entry of your to the IP and a CNAME for (of course to

Thank you for your answer. I just meant I don’t have experienced skills in Apache server settings, but on the hosting package I have no possibilities to change it anyway.