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

 

[tessa67]

yes, that's exactly the handler I meant. "FPM-Application (Apache)" is the right choice for a WordPress multisite — it runs PHP-FPM behind Apache and still lets WordPress's .htaccess rules do their thing. So the handler itself is fine.

The problem is the handover to the main domain's FPM socket, which is still being refused with that proxy_lock error even though the socket exists and is listening. That smells like a permissions issue on the socket's parent directory, or the Apache user not being in the right group.

Please run these and post the outputs (anonymized):

1) Permissions on the socket's parent directory:

ls -ld /var/www/vhosts/system/maindomain.com/

Expected is something like `drwxr-x--- root psaserv`. If the group or mode looks different, Apache may not be able to reach the socket.

2) Which user Apache actually runs as, and whether it's in the psaserv group:

id $(ps -o user= -C apache2 | head -1)

The Apache user (usually www-data) needs to be a member of psaserv to access the socket.

3) Whether mod_proxy_lock is loaded at all:

apache2ctl -M | grep proxy_lock

There are reports of mod_proxy_lock breaking socket-based FCGI setups after certain Plesk updates. If it's loaded, that's a likely culprit, and we can look at disabling it for the wildcard domain or setting ProxyLockSocket explicitly.

Post the outputs of 1 and 2 first — that tells us whether this is a plain permissions problem or whether the proxy lock module is getting in the way.

It’s like a detective story trying to find this bug. I'm digging through the Plesk logs like a detective.

Regards
Tessa

 

[therider62]

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

==> no output, but

ps aux | grep -E 'apache|httpd'

root 3040754 0.0 0.1 215984 131492 ? Ss Nov04 0:22 /usr/sbin/apache2 -k start
www-data 4103401 0.0 0.1 215224 121132 ? S 17:37 0:00 /usr/sbin/apache2 -k start
www-data 4103402 0.0 0.1 216400 120572 ? S 17:37 0:00 /usr/sbin/apache2 -k start
www-data 4103403 1.2 0.2 2209168 138680 ? Sl 17:37 0:09 /usr/sbin/apache2 -k start
www-data 4103421 2.5 0.2 2210684 140288 ? Sl 17:37 0:19 /usr/sbin/apache2 -k start
root 4110550 0.0 0.0 6632 2388 pts/0 S+ 17:50 0:00 grep --color=auto -E apache|httpd

so, are we looking for www-data?

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

OK

apache2ctl -M | grep proxy_lock

proxy_lock_module (shared)

Now, before I actually start changing Apache & nginx Settings, I take a deep breath, a break, go buy something before shops close, and am probably back in around an hour. If you're still there, I'll be happy to continue work.

 

[tessa67]

Hey @therider62,

The outputs confirm two things:
- The Apache user is www-data and it CAN access the socket (your `sudo -u www-data test -w` returned OK).
- `proxy_lock_module` is loaded.

So permissions are not the problem. The proxy_lock module is. There's a known Plesk forum report where exactly this module broke socket-based FCGI/HTTP handovers, and the fix was adding a conditional ProxyLockSocket directive to the vhost [citation:4].

The next step is to add this to the wildcard domain's Additional Apache directives from Issue - Subdomains get a 403 error (Domains > *.maindomain.com > Apache & nginx Settings > Additional directives for HTTPS):

If that doesn't fix it, the fallback is to disable proxy_lock_module entirely via Plesk (Tools & Settings > Apache Web Server) or on the CLI:

plesk sbin httpd_modules_ctl -d proxy_lock
systemctl restart apache2

One caveat: disabling a module server-wide affects all domains, so it's the less elegant option.

Try the conditional directive first.

Regards
Tessa

 

[tessa67]

@AlL: In case someone from the staff is reading this: I am running out of ideas. Am I missing something, or could the staff please provide some insight?