Issue Subdomains get a 403 error

[therider62]

I am running a multisite-wordpress installation with about 30 sites, half a dozen of which are mapped to 2nd-level-domains aliases, the rest are subdomains of the master domain.

I created a wildcard domain as an alias to the master domain, as well as the various 2nd-level-alias-domains.

All of them are secured by one Let's-Encrypt certificate. Everything ran smoothly for the past several months.

One of the 2nd-level-alias-domains was transferred away to another provider. Next time the certificate expired, it could not be renewed, because that particular 2nd-level-alias failed to comply with requirements. I deleted that alias, and this time the certificate renewal worked like a charm. Wonderful!

But now I noticed that the subdomain sites can't be opened anymore. The main site opens, the 2nd-level-domain sites open too, but the subdomain sites receive a 403 error.

1. I checked the .htaccess and could not find a problem there.
2. I checked "Protocol", and am not receiving an error there.
3. I activated DEBUG output in the WP toolkit, but did not get any output from there either.
4. The main domain has the correct certificate selected and activated. The certificate contains the wildcard domain as well, plus all the 2nd-level-domains.
5. I don't think this has anything to do with the WP Toolkit, but one can never be sure, of course.

Does anyone have an idea what could be the problem here and why this is popping up right now? Or where I should go looking for what kind of configuration error?

Of course, I am updating my wordpress installation all the time, as well as all the themes and plugins that go along with it. But I can not imagine that that could lead to a 403 error.

 

[therider62]

Before I forget: My OS is: Ubuntu 24.04.5 LTS
My PLESK is: Plesk Obsidian 18.0.76 Update 6 Web Pro Edition

 

[Sebahat.hadzhi]

@therider62 , could you please monitor the following logs when you reproduce the error and confirm what's being logged:

/var/www/vhosts/maindomain.com/logs/error_log
/var/www/vhosts/subdomain.maindomain.com/logs/error_log

 

[therider62]

@therider62 , could you please monitor the following logs when you reproduce the error and confirm what's being logged:

/var/www/vhosts/maindomain.com/logs/error_log
/var/www/vhosts/subdomain.maindomain.com/logs/error_log

Thank you for your request. This is interesting.

* /var/www/vhosts/maindomain.com/logs/error_log does not produce any output, when I refresh the subdomain, that is producing the 403.
The only error I can see, but I am not 100% sure if it was triggered by my refresh, is this:

[Wed Nov 04 17:22:03.751229 2026] [core:error] [pid 3156918:tid 139805295875776] [client 193.32.127.215:0] AH00124: Request exceeded the limit of 10 internal redirects due to probable configuration error. Use 'LimitInternalRecursion' to increase the limit if necessary. Use 'LogLevel debug' to get a backtrace.

* /var/www/vhosts/subdomain.maindomain.com/ does not exist. I am assuming this is because the subdomain is only a site within the multisite wordpress. I never added it explicitly as a subsite to PLESK. I *did* add a general purpose subsite "*", or the wildcard domain, meaning "*.maindomain.com".

 

[tessa67]

Hey @therider62,

that "10 internal redirects" line (AH00124) is a loop inside Apache. A loop usually ends in a 500 though, not a 403, so I wouldn't be sure yet that this is your problem. First thing to find out is who actually throws the 403. Try this:

curl -skI https://sub.maindomain.com/

Look at the "Server" header and the body of the response (nginx, Apache and WordPress all have different-looking 403 pages). To rule out DNS, you can also pin the request to your server IP:

curl -skI --resolve sub.maindomain.com:443:YOUR_SERVER_IP https://sub.maindomain.com/

Since the subdomains are only a wildcard alias of the main domain, they don't get their own log folder - their requests end up in the main domain's logs. Watch these while you reload the subdomain (the system-level folder also includes the nginx proxy logs):

tail -f /var/www/vhosts/system/maindomain.com/logs/proxy_access_ssl_log /var/www/vhosts/system/maindomain.com/logs/access_ssl_log /var/www/vhosts/system/maindomain.com/logs/error_log /var/www/vhosts/system/maindomain.com/logs/proxy_error_log

If the request shows up in an access log with a 403, you know which layer answers. If it shows up nowhere, check the server-wide logs too:

tail -f /var/log/nginx/error.log /var/log/apache2/error.log

Next, since this started right after you deleted the alias and the cert got renewed: Plesk regenerated the vhost configs in that process. Check whether the wildcard alias is still in the generated configs. You should see *.maindomain.com in both:

grep -i "ServerAlias" /etc/apache2/plesk.conf.d/vhosts/maindomain.com.conf

grep -i "server_name" /var/www/vhosts/system/maindomain.com/conf/nginx.conf

Then let Plesk rebuild the web config for that domain and test again:

plesk repair web maindomain.com -y

or, the older way:

plesk sbin httpdmng --reconfigure-domain maindomain.com

Two more things worth checking in the panel:

- In the settings of the wildcard alias: is an alias redirect option ("Redirect with the 301 code" or similar) enabled? Combined with an HTTP->HTTPS redirect and the WordPress multisite redirects, that could build exactly this kind of loop. That's only a guess on my part, not something I can confirm from here.
- Hosting & DNS > Apache & nginx Settings: any additional directives that block or redirect?

If the 403 turns out to come from a security layer (ModSecurity / WAF, fail2ban, Imunify), the logs will show it. For ModSecurity the audit log is usually here:

tail -f /var/log/modsec_audit.log

To get more detail on the redirect loop, you can temporarily add this to the additional Apache directives of the domain (remove it afterwards, it's noisy):

LogLevel debug

Let us know what the curl output and the logs say, then we can narrow it down.

Regards
Tessa