Resolved Random 404 or Web Server's Default Page - on sub domain

[Teal_cfr]

Server operating system version

Debian 10.13

Plesk version and microupdate number

18.0.49

Hi all,

I have a case that make me get crazy since i don't understand when this is from.

On my server

OS: Debian 10.13
Product: Plesk Obsidian 18.0.49 Update #2, last updated on Jan 24, 2023 05:26 AM

Every sub domain that i create get a Random error like : for 10 loads i will have 5 time 200 / 4 times 404 / 1 time "Web Server's Default Page" of Plesk

I check the configuration of my IPv6 and IPv4 there are both Sharing and no defaut sites set.

My PHP settings and this host is :

7.4.33 (Outdated), run PHP as FPM application served by Apache

My Apache settings are

nginx settings

Proxy mode : activate
Smart static files processing : activate

No Additional nginx directives


Any ideas to solve this will be appreciated

 

[Peter Debik]

Does your domainname reliably resolve to the exact same IPv4 address everytime it is used on the Internet or could there be some round robin configurations involved, antivirus solutions or VPN clients that interfere with the traffic?
Are independent tests through intoDNS: checks DNS and mail servers health or DNSViz | A DNS visualization tool show any errors? Do DNSSEC records exist for the domainname that should not be there?

 

[Teal_cfr]

Hey,

Thanks but no there is no error regarding DNS config.
every request is ending on my server.
I also pass the DNS of my server to slave so only DNS record of my domain provider are used.

There is no variation regarding ipv4 and ipv6 resolution always same ip shown.

 

[Teal_cfr]

staging.mx2k.com | DNSViz

 

[Peter Debik]

Please try to toggle Nginx
as root /usr/local/psa/admin/bin/nginxmng -d
as root /usr/local/psa/admin/bin/nginxmng -e
Does the issue still occur afterwards?

 

[Teal_cfr]

Yup,

No effect on the issue

 

[Peter Debik]

Is your website using an .htaccess file either in the web space root directory or the document root directory? Does that file have any URL rewrites?

 

[Teal_cfr]

Nothing that could make it worst

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

I have an other Host with .htaccess and same issue

 

[Peter Debik]

Are you using additional web servers or did you experiment with them before?

 

[olivier__asap]

Hello,
I have the exact same issue on a subdomain after moving the website from a VPS to another one (same subdomain, same Plesk config, just different IP), the A record points to the correct IP.
I really don't understand where the problem comes from.
It looks like a cache problem but I don't know where to look...
Thanks !

 

[olivier__asap]

https://support.plesk.com/hc/en-us/articles/360015533959-A-website-or-webmail-hosted-in-Plesk-periodically-shows-the-Plesk-web-server-default-page-or-old-website-content-

1. Go to Tools & Settings > Services Management.
2. Click the
   
   button next to Web Server (Apache) to restart the Apache service.

It seems to have solved the problem... I'll keep you posted

 

[Peter Debik]

Yes, but when toggling Nginx, this must reconfigure all webserver configuration files and cause Apache to restart, because in between Apache will need to listen to different ports (80 and 443 directly opposed to ports 7080, 7081 in the Nginx configuration). As @Teal_cfr said it did not work for him it may not be the same case there.

 

[olivier__asap]

That's what I thought but apparently something was blocking the restart of Apache after a config change. I tried many configurations that should have restarted it but since I restarted it manually I don't get any error... Let's wait if it works for @Teal_cfr

 

[Teal_cfr]

Well -_- ...... -_-

It seems to work :O

5 min of loading different page, and 100% code 200 until now

how can it be as simple as this.

 

[Peter Debik]

Thank you for the feedback. Important to know for me, because it means that Apache is not restarting on the port changes, but still only reloading the configuration if graceful restarts are on.