Issue Subdomains get a 403 error

[tessa67]

Hey @therider62,

huge progress. That log line is the smoking gun:

proxy_lock: refused proxy backend unix:/var/www/vhosts/system/maindomain.com/php-fpm.sock for /index.php

So the wildcard vhost receives the request, tries to hand it over to PHP-FPM via the MAIN domain's socket, and that handover is refused. That's why you get a 403 and why the request shows up in the wildcard's log but never reaches WordPress.

And the Host-header test confirms it: with `Host: maindomain.com` you get a 200, with `Host: sub.maindomain.com` you get 403. The vhost works, the PHP-FPM socket path does not.

Next steps, in this order:

1) Check the socket and its owner/permissions:

ls -la /var/www/vhosts/system/maindomain.com/php-fpm.sock

It should exist and be owned correctly. If it's missing, restart the PHP handler:

systemctl restart plesk-php*

2) Rebuild the PHP-FPM configs for the domain:

plesk repair web maindomain.com -y

Then restart PHP-FPM again and test.

3) If it still refuses, check whether the main domain's FPM pool is actually running and listening on that exact socket:

ss -xlp | grep maindomain.com

4) As a quick sanity check in the panel: Domains > maindomain.com > PHP Settings. Note which handler is set. The wildcard vhost is pointing at the main domain's socket, so both need to be on the same, working handler.

The `Require valid-user` on line 98 of the vhost config is not your problem here — if that were it, you'd get a 401, not a 403 from the proxy.

Post the output of step 1 and 3 (anonymized) and we'll see whether the socket is missing, owned wrong, or just not accepting connections.

Regards
Tessa

 

[therider62]

ls -la /var/www/vhosts/system/maindomain.com/php-fpm.sock

srw-rw---- 1 root psaserv 0 Nov 4 06:27 /var/www/vhosts/system/maindomain.com/php-fpm.sock

systemctl restart plesk-php*

plesk repair web maindomain.com -y

Checking web server configuration. Please wait
Repairing web server configuration for the domain maindomain.com ... [OK]

Checking php-fpm configuration
Repairing php-fpm configuration for the domain maindomain.com ...... [OK]

Checking for missing log rotation configuration files ............... [OK]

Error messages: 0; Warnings: 0; Errors resolved: 0

systemctl restart plesk-php*

Retrying refreshing sub.maindomain.com in the Browser. Still getting 403 error

ss -xlp | grep maindomain.com

u_str LISTEN 0 4096 /var/www/vhosts/system/_.maindomain.com/php-fpm.sock 94296477 * 0 users("php-fpm",pid=4095182,fd=9))
u_str LISTEN 0 4096 /var/www/vhosts/system/maindomain.com/php-fpm.sock 94296479 * 0 users("php-fpm",pid=4095182,fd=10))
u_str LISTEN 0 4096 /var/www/vhosts/system/kabbal-on-angular.maindomain.com/php-fpm.sock 94299168 * 0 users("php-fpm",pid=4095181,fd=17))
u_str LISTEN 0 100 private/plesk-maindomain.com-152.53.65.145-2a0a-4cc0-80-3bb-588b-d6ff-fe5d-83dc 59792013 * 0 users("master",pid=1208171,fd=131))

 

[therider62]

As for the PHP handler: Both maindomain.com and *.maindomain.com point at PHP version 8.5.12 and "FPM-Application (Apache)". Is that referring to the "handler" you are talking about?

 

[tessa67]

Hey @therider62,

the socket exists and is listening, so it's not missing — but the proxy_lock error is still there. That points to a permission/locking issue rather than a missing backend.

Since the socket is owned by root:psaserv with srw-rw----, Apache (running as the subscription user) needs to be in a group that can access it. Let's check what user Apache runs as for this domain and whether it can actually reach the socket:

1) Check the Apache user for the domain:

ps aux | grep -E 'apache|httpd' | grep maindomain

2) Test if that user can access the socket (replace USER with what you find above):

sudo -u USER test -w /var/www/vhosts/system/maindomain.com/php-fpm.sock && echo "OK" || echo "NO ACCESS"

3) The proxy_lock warning is interesting — it's not a standard Apache error. Check if mod_proxy_lock is loaded and whether there's a known Plesk issue with it:

apache2ctl -M | grep proxy_lock

There's a known Plesk forum thread about ProxyLockSocket breaking socket-based FCGI setups after certain updates [citation:5]. If mod_proxy_lock is loaded, try adding this to the wildcard domain's additional Apache directives (Domains > wildcard > Apache & nginx Settings):

<IfModule mod_proxy_lock.c>
    ProxyLockSocket "/var/www/vhosts/system/maindomain.com/php-fpm.sock"
</IfModule>

Then rebuild and restart Apache:

plesk repair web maindomain.com -y
systemctl restart apache2

4) Also check AppArmor — it's active on Ubuntu and can block Apache from locking/accessing Unix sockets even when file permissions look fine [citation:1][citation:4]. Quick check:

aa-status | grep -i apache

If AppArmor has a profile for apache2 in enforce mode, that's a strong candidate. You can test temporarily with:

aa-complain /usr/sbin/apache2

Then restart Apache and try the subdomain again. If it works, we know AppArmor is the culprit and can write a proper profile exception instead of leaving it in complain mode.

Post the outputs of 1, 2, and 4 and we'll know whether it's permissions, mod_proxy_lock, or AppArmor.

Regards
Tessa