Issue my subdomain is redirecting to the plesk index

[Cannibal]

I have a problem with my subdomain in plex the main domain works perfectly, but the subdomain keeps switching between the correct site and the plesk index page I keep pressing f5 several times, sometimes the correct page appears and sometimes the plesk index page appears, I would like to make this plesk index page stop appearing

 

[Peter Debik]

This could be the effect of a round robin DNS configuration where the subdomain is configured multiple times in the nameserver with different IP addresses. In that scenario, at least one is correct, but the other (or others) are pointing to another Plesk server where the subdomain is unknown. For that reason some requests are directed to the correct IP and responded correctly to by the correct server while others are routed to wrong servers that don't know the domain and respond with their default Plesk page instead. To rule out this scenario, carefully examine the DNS settings of the subdomain whether there is only one route that routes the domain to the one correct server.

 

[RafaelKr]

We see exactly the same behavior. Sometimes our Subdomains work and on some requests they result in a 307 redirect to another domain. Interesting thing is it's not the Plesk Server Domain itself, but the one it redirects to. But the redirect seems to be resolved internally.

Example:
- Plesk-Host-Domain is plesk.example.net, IP 11.22.33.44
- plesk.example.net (without 8443) redirects to www.example.com (note it's a completely other Domain with another TLD, but also hosted on Plesk)
- We have a subscription with Domain test.some-other-domain.com (it's created as Domain, not as a Subdomain)

Now when browsing to our domain curl -s -I https://test.some-other-domain.com sometimes we get the intended page for test.some-other-domain.com

HTTP/2 200 
server: nginx
date: Thu, 20 Jul 2023 14:30:11 GMT
content-type: text/html
content-length: 464
x-accel-version: 0.01
last-modified: Thu, 20 Jul 2023 12:14:16 GMT
etag: "1d0-600ea16441d82"
accept-ranges: bytes
vary: Accept-Encoding
x-powered-by: PleskLin

and on every 2nd to 7th requests we get

HTTP/2 307
server: nginx
date: Thu, 20 Jul 2023 12:59:46 GMT
content-type: text/html; charset=iso-8859-1
location: https://www.example.com/
x-powered-by: PleskLin

Note that this is directly served by Plesks nginx and the location is NOT the Plesk-Host-Domain but the one it redirects to. So it doesn't seem to be a DNS round-robin as mentioned in the comment before.

BTW curl -s -I http://11.22.33.44 results in exactly the same 307 redirect. Not to the Plesk-Host-Domain but to our www.example.com.

Is there any way to debug where exactly this redirect happens or even better from which config this is coming from?

I also did a nginx -T manually searching through any "rewrite" and "return" with no matching result.
I also looked for default_server and server_name _ without a result.

Is there any other way how to debug this?

 

[Peter Debik]

Is there any way to debug where exactly this redirect happens or even better from which config this is coming from?

You can look into the webserver configuration of Nginx and Apache, and if no 307 is set there (which is very likely), it can only result from either an .htaccess rewrite setting or a scripted redirect, such as a JavaScript redirect or an http-equiv that is issued by a malicious script in the website. The 307 redirect is unknown to Plesk, there is no such setting. It is also a very unusual redirect. It means that the request type must e maintained (GET or POST). It's rarely used by ordinary software.

 

[RafaelKr]

The interesting thing is I had some different Subdomains (all created as own domains in own subscriptions) all with the same Root domain with the schema:
test.dev.example.com
other.dev.example.com
...

For some of them it worked, some had that redirect issue.

nginx config and Apache config via nginx -t and apache2ctl -DDUMP_CONFIG and couldn't find anything regarding a 307 redirect. In the end I did a systemctl restart nginx and a systemctl restart apache2. Now the issue is gone.

I have no idea where the issue came from and why it's now solved. Also why it only occured sporadically on some requests. It seems there was one or more misbehaving child processes of Apache or nginx and depending on which process served the request it worked or it didn't.