Unpublished page returns 404 for editor/superuser

[snck]

I have a strange problem with a site that I was not able to solve until now.

I have a website running on domain.com (which is also the only entry in the hosts array). If an editor (or me as superuser, but for me this is happening only sporadically) is logged in (also using domain.com/processwire/), they cannot access an unpublished page using the "view" link, but get a 404 error page.

If the previewed url is changed from domain.com/xyz/page/ to www.domain.com/xyz/page/ manually in the address bar, the page is viewed correctly.

There is no .htaccess rule for www redirects in place and I have disabled ProCache for debugging purposes.

What makes it even more bizarre: Sometimes if the user logged out and is logging in again, they get redirected to the page they wanted to view directly after submitting the login form.

Has somebody experienced a behaviour like this before? As I am not able to reliably reproduce this behaviour, I feel a little lost. At first I was thinking that this problem is related to some network configuration/filter/firewall stuff on the client's network, but as I was also facing it a few times, I am really confused. Is there any configuration on the webhost side that could cause issues like this? 

Any input is appreciated!

Thanks,
Flo

[ngrmm]

I've one page in production which has similar bizarre issue.

I'm not able to view an unpublished page as a superuser. But this happens only in chrome. No problem safari or firefox. I gave up to find out why ?
Which browser are you using?

Please let me know if you have solved this issue
Found this here but I'm a noob in host server settings
 

[snck]

Thanks for the input, @ngrmm!

After further investigation, it became apparent that the editor who was experiencing the problem always accessed the backend of the website via a bookmark that referred to a URL with a www subdomain.

Since the www subdomain is not set up as a host in config.php, the "View" link always points to the domain without www. Presumably the session cookies were running on the subdomain, which were not classified as "same site" by the browser and/or cookie policy, which may have led to the 404 error.

For me, this has now been resolved. I was at least able to solve the problem for the editor by using a rewrite rule that redirects all traffic for the www subdomain to the main domain. Since then, the strange behavior has no longer occurred.