• Halloween is coming! To celebrate the occasion, we dusted off a couple of old skins, and even created a brand new one (Pixel).
    To get into the festive spirit, install the Skins extension.
  • The new Python extension is now available. It allows customers to deploy and manage WSGI-based Python applications on their websites directly from Plesk.
  • The Plesk Mobile apps for iOS and Android and the Plesk Mobile Center extension have been deprecated, and are no longer available for new installations. In Plesk Obsidian 18.0.84, the Plesk Mobile Center extension will be removed from servers during the upgrade, and the Plesk Mobile apps will lose their server management features.
  • The Social Login extension has been deprecated and will be removed in Plesk Obsidian 18.0.84. After that, it will no longer be possible to log in to Plesk with a Google, Facebook, GitHub account, or with a passkey. Plesk usernames and passwords, as well as logging in with a WebPros Account, are not affected.

Issue Plesk 18.0.81 Update #7 breaks AJP connectors for some applications

We're finding evidence that http over socket is broken by this. Does anyone have a working http over socket? Example, this fastcgi-based setup worked fine before this module was deployed, broke, and was fixed by adding the conditional + proxylocksocket:

<IfModule mod_proxy_lock.c>
ProxyLockSocket "/var/www/vhosts/DOMAIN/application.sock"
</IfModule>
SetHandler "proxy:unix:/var/www/vhosts/DOMAIN/application.sock|fcgi://localhost/"


This version is broken and remains broken:

<IfModule mod_proxy_lock.c>
ProxyLockSocket "/var/www/vhosts/DOMAIN/application.sock"
</IfModule>
ProxyPass / "unix:/var/www/vhosts/DOMAIN/application.sock|http://127.0.0.1/"
ProxyPassReverse / "unix:/var/www/vhosts/DOMAIN/application.sock|http://127.0.0.1/"
 
Hi @HostaHost, hi everyone,

I tried to help with the unix socket question from post #21 and ran a few tests on a small test box. Quick disclaimer first: it's plain Apache 2.4.58 on Ubuntu 24.04, no Plesk, so no mod_proxy_lock. As far as I can tell the module isn't publicly available and I couldn't find any docs or release note entry for it. Everything I say about the module itself comes from this thread only, and I'll point to the post numbers.

What I tested (stock Apache, backend listening on a unix socket, no mod_proxy_lock involved):

- ProxyPass / "unix:<SOCKET_PATH>|http://localhost/" at vhost level: works
- the same with http://127.0.0.1/ (that's the form from post #21): works
- ProxyPass / ProxyPassReverse inside <Location />: works
- SetHandler "proxy:unix:<SOCKET_PATH>|http://localhost/": in my test the backend got the filesystem path (/var/www/html/x) instead of the request URI. So for an http backend I'd stick to ProxyPass; SetHandler is the right tool for fcgi, as in your working example.

So the syntax in #21 is fine on plain Apache. If it's still refused with ProxyLockSocket set, the difference has to come from the module's handling. I can't tell more than that.

What the thread says (staff and users):

- ProxyLockSocket only accepts "none" or an absolute unix socket path (error message in #14 and #19). That's why the ajp:// line from #3 gets rejected.
- A later ProxyLockSocket overrides an earlier one, and it can be set in directory scope, e.g. <Location> (#9, #13).
- http(s) proxies are intentionally allowed (#20), which matches what Fede saw in #19.
- A fix for AJP is planned for the next update, and mizar offered an RPM for AlmaLinux (#16, #20).

Things you could try. I could not test these against the module, so please treat them as ideas:

1) First look at what exactly gets refused, it shows which address the module checks:
Code:
grep "proxy_lock" /var/www/vhosts/system/<DOMAIN>/logs/error_log | tail

2) For the unix socket + http case, set both directives in directory scope (based on #9 and #13):
Code:
<IfModule mod_proxy_lock.c>
ProxyLockSocket "<SOCKET_PATH>"
</IfModule>
<Location />
ProxyPass "unix:<SOCKET_PATH>|http://localhost/"
ProxyPassReverse "unix:<SOCKET_PATH>|http://localhost/"
</Location>

3) For AJP/Tomcat, the HTTP connector instead of AJP should work according to #19 and #20:
Code:
ProxyPass / http://127.0.0.1:<TOMCAT_HTTP_PORT>/
ProxyPassReverse / http://127.0.0.1:<TOMCAT_HTTP_PORT>/
ProxyPreserveHost On

Two questions for @mizar, if you have a minute:

- Is the unix socket + ProxyPass + http combination from #21 expected to be allowed with ProxyLockSocket, and if so, in which scope?
- The error message mentions "none" as a valid value. What does it do exactly, and is it meant to be used per domain or location?

One more thing: the official change log for Update 7 only says it addresses a critical security issue, that the web server vhost templates changed, and that the configs of all domains get regenerated. If you use custom vhost templates, it's worth checking them after the update.

Hope this helps a bit!

Regards
Tessa
 
This version is broken and remains broken:

<IfModule mod_proxy_lock.c>
ProxyLockSocket "/var/www/vhosts/DOMAIN/application.sock"
</IfModule>
ProxyPass / "unix:/var/www/vhosts/DOMAIN/application.sock|http://127.0.0.1/"
ProxyPassReverse / "unix:/var/www/vhosts/DOMAIN/application.sock|http://127.0.0.1/"

Thanks for the report, I'll investigate this. Am I right that this directives are added using additional apache directives, and not framed by location / directory?
 
@mizar Thank you for the update and for confirming the issue.

I would appreciate it if you could provide the updated RPM package for AlmaLinux 8 and 9, so we can test the fix before the next official update.

Could you also confirm whether the updated module will automatically allow existing AJP connections configured through standard Apache ProxyPass directives, without requiring any additional configuration changes?

Thanks,

Fede
I upload proxy_lock with the fix for AJP proxies to https://autoinstall.plesk.com/plesk-mod_proxy_lock-04.11.2026/ (release redhat.8 for AlmaLinux 8 and redhat.9 for AlmaLinux 9). Theese version of module should handle AJP proxied connections without extra configuration (even ProxyLockSocket exists for virtual host).

The short instruction - install approprate rpm package with rpm -Uvh, restart apache. To rollback - download previous version module from Index of /pool/PSA_18.0.82_20369 (for 18.0.82) or Index of /pool/PSA_18.0.81_20371 (for 18.0.81), they are in dist-rpm-RedHat-el8-x86_64/opt/hosting/proxylock/ for AlmaLinux8 or dist-rpm-RedHat-el9-x86_64/opt/hosting/proxylock/ for AlmaLinux 9, then rpm -Uvh --oldpackage and restart apache. Please let me know if you have any problems with it.
 
- Is the unix socket + ProxyPass + http combination from #21 expected to be allowed with ProxyLockSocket, and if so, in which scope?
I need to check how exactly Apache handle ProxyPass with "unix:/var/www/vhosts/DOMAIN/application.sock|http://127.0.0.1/", for SetHandler expression after | are used as label, but I'm not completely sure how it is handled for ProxyPass.

- The error message mentions "none" as a valid value. What does it do exactly, and is it meant to be used per domain or location?
It is disabling proxy connections except http-based for the virtual host / directory. However, subequent directives can override this.
 
Thanks for the report, I'll investigate this. Am I right that this directives are added using additional apache directives, and not framed by location / directory?

I tried it bare (the site doesn't use PHP-FPM so the lock directive is "none", tried it as location /, proxy match, directory /full/path, and filesmatch. All versions fail if it's http over socket. The application is intentionally not exposed via http because the socket listener is using the OS uid of the process accessing the socket as its confirming the intended site is calling it, versus having to build an http auth mechanism.
 
Hi Plesk-Team, Hi Everyone,

I've an similar problem with my Lucee configuration, using mod_cfml. And I assume mod_cfml is internally using an ajp connection but with an shared key. what can I do to solve the problem?

The following three lines didn't work:

<IfModule mod_proxy_lock.c>
ProxyLockSocket "ajp://127.0.0.1"
</IfModule>

And I'll get the following error message:

Invalid Apache configuration: [Wed Nov ....] [so:warn] [pid 35611] AH01574: module modcfml_module is already loaded, skippingAH00526: Syntax error on line 6 of /var/www/vhosts/system/DOMAIN/conf/vhost_ssl.conf: ProxyLockSocket: expected 'none' or an absolute unix socket path

This is the modcfml.conf:

<IfModule modcfml_module>
CFMLHandlers ".cfm .cfc .cfml"
ModCFML_SharedKey "<this is shared Key>"
LogHeaders false
LogHandlers false
LogAliases false
VDirHeader false
</IfModule>

PS: PHP is completly disabled for the Domain.
 
I upload proxy_lock with the fix for AJP proxies to https://autoinstall.plesk.com/plesk-mod_proxy_lock-04.11.2026/ (release redhat.8 for AlmaLinux 8 and redhat.9 for AlmaLinux 9). Theese version of module should handle AJP proxied connections without extra configuration (even ProxyLockSocket exists for virtual host).

The short instruction - install approprate rpm package with rpm -Uvh, restart apache. To rollback - download previous version module from Index of /pool/PSA_18.0.82_20369 (for 18.0.82) or Index of /pool/PSA_18.0.81_20371 (for 18.0.81), they are in dist-rpm-RedHat-el8-x86_64/opt/hosting/proxylock/ for AlmaLinux8 or dist-rpm-RedHat-el9-x86_64/opt/hosting/proxylock/ for AlmaLinux 9, then rpm -Uvh --oldpackage and restart apache. Please let me know if you have any problems with it.

Thanks for providing the updated RPM.

Just one question before installing it: could installing this RPM manually, outside the normal Plesk update process, cause any conflicts with future Plesk updates or upgrades, for example when upgrading from 18.0.81 to 18.0.82?

Will Plesk automatically manage and replace this package during subsequent updates, or would any manual intervention be required?
 
Hi Plesk-Team, Hi Fade Marsell,

the soloution is for RedHat / AlmaLinix, right? I need a package for ubuntu 24.04 LTS or should I convert the rpm package to an deb package?
 
Just one question before installing it: could installing this RPM manually, outside the normal Plesk update process, cause any conflicts with future Plesk updates or upgrades, for example when upgrading from 18.0.81 to 18.0.82?

Shouldn't be any problems with it, new rpm packages will have greate release, so they update it. And we don't have any strict version-release requirements for mod_proxy-lock

I've an similar problem with my Lucee configuration, using mod_cfml. And I assume mod_cfml is internally using an ajp connection but with an shared key. what can I do to solve the problem?
Thanks for the report, I will check the module. Honestly, I hear about this module first time, so I can only recommends basic things as an immediate solution:
* disable proxy_lock apache module
* fix virtual hosts templates to exlucde ProxyLockSocket directive for the particular domains
 
@mizar Thank you for providing the updated RPM.

We've tested the new module and can confirm that it resolves the issue. AJP connections are now working normally again.

The only thing we noticed is that, after installing the RPM, the LoadModule directive in /etc/httpd/conf.d/proxy_lock.conf was commented out. We had to uncomment it manually and restart Apache (and verified that the module was correctly loaded).

Apart from that, everything is working as expected.

Thanks again for your help and the quick fix. We hope this correction will be included and maintained in future Plesk updates.
 
The only thing we noticed is that, after installing the RPM, the LoadModule directive in /etc/httpd/conf.d/proxy_lock.conf was commented out. We had to uncomment it manually and restart Apache (and verified that the module was correctly loaded).
It's quite strange, because /etc/httpd/conf.d/proxy_lock.conf is marked by config, so it should not be changed during package update. Tried to reproduce manually, but also without success. What command are you using for package update?

This version is broken and remains broken:

<IfModule mod_proxy_lock.c>
ProxyLockSocket "/var/www/vhosts/DOMAIN/application.sock"
</IfModule>
ProxyPass / "unix:/var/www/vhosts/DOMAIN/application.sock|http://127.0.0.1/"
ProxyPassReverse / "unix:/var/www/vhosts/DOMAIN/application.sock|http://127.0.0.1/"
The module now blocks such connections, but they should be allowed. It will be fixed in next Plesk updates, but if you need fixed version now - please post your operation system and I build fixed module for it.
 
It's quite strange, because /etc/httpd/conf.d/proxy_lock.conf is marked by config, so it should not be changed during package update. Tried to reproduce manually, but also without success. What command are you using for package update?

yes ....... after encountering the AJP issue, I disabled the module by renaming /etc/httpd/conf.d/proxy_lock.conf to /etc/httpd/conf.d/proxy_lock.conf.disable.

I then installed the updated package using:

rpm -Uvh XXXXX.rpm

During the installation, a new /etc/httpd/conf.d/proxy_lock.conf file was created, but the LoadModule directive was commented out:

#LoadModule proxy_lock_module /usr/lib64/httpd/modules/mod_proxy_lock.so
 
@mizar — Ubuntu 24.04 Unix-HTTP correction requested

Thank you for confirming the HTTP-over-Unix-socket issue with mod_proxy_lock.

We have reproduced the defect on Ubuntu 24.04 LTS / Plesk Obsidian 18.0.82 Update 2.

Our Apache reverse proxy returns HTTP 403, with the error:

proxy_lock: refused proxy backend unix:... for /login

The same backend returns HTTP 200 directly.

We have tested the November 4 Ubuntu package and verified that it does not correct this Unix-HTTP case.

Could you please provide the corrected Ubuntu 24.04 .deb supporting HTTP-over-Unix-socket ProxyPass, while preserving existing socket restrictions?

Please also provide compatibility details, package checksum, installation instructions and the original package needed for rollback.

This issue is blocking our production launch. Thank you.
 
Hey @Ferkesh,

quick note from someone who just went through the same class of problem in another thread ("Subdomains get a 403 error"): the symptom matches — mod_proxy_lock (introduced with 18.0.81 Update #7) refuses the proxy handover to your Unix-socket backend and you get the 403.

But heads-up: your case is specifically the HTTP-over-Unix-Socket scenario (ProxyPass / "unix:...|http://127.0.0.1/"), and per @mizar in post #34 of this thread that exact case is NOT covered by the 04.11.2026 Ubuntu package. That package fixes AJP, not Unix-HTTP. So adding ProxyLockSocket alone will likely still be refused on Ubuntu 24.04 with the current build — which matches what you already observed.

What actually worked for a PHP-FPM Unix socket (different scenario, but same module) was adding the explicit socket path as an Additional Apache Directive in the vhost:
Code:
<IfModule mod_proxy_lock.c>
    ProxyLockSocket "<ABSOLUTE_SOCKET_PATH>"
</IfModule>

If that still gives you "refused proxy backend unix:..." for /login, then you're hitting the unfixed HTTP-over-Unix-Socket path and need one of:

1) A patched .deb from @mizar specifically for the Unix-HTTP case (ask him directly in this thread with your OS/arch: Ubuntu 24.04 x86_64, Plesk 18.0.82 Update 2).
2) A temporary workaround until that lands: switch the backend to TCP (127.0.0.1:PORT) instead of a Unix socket, if your app supports it. TCP HTTP proxies are intentionally allowed per @mizar (#20).
3) Last resort: disable mod_proxy_lock for the affected domain/vhost only, not server-wide, and re-enable once the fixed module is in the next Plesk update.

Also worth posting (anonymized): the exact grep output of ProxyLockSocket in /var/www/vhosts/system/<DOMAIN>/conf/, and the full "proxy_lock: refused ..." line from the vhost error log. That tells @mizar exactly which socket/URI combination is being blocked, and makes it easier for him to confirm whether your case is the known-unfixed one.

Good luck — you're not alone with this, it's clearly a Plesk-side regression in the new module.

Regards
Tessa

Thread: Issue - Subdomains get a 403 error
 
Back
Top