Applicable to:
- Plesk for Linux
Symptoms
-
All websites show the error:
PLESK_INFO: 421 Misdirected Request
-
The following error message is logged in domain's log (Plesk > Domains > example.com > Logs):
CONFIG_TEXT: AH02032: Hostname default-203_0_113_2 (default host as no SNI was provided) and hostname www.example.com provided via HTTP have no compatible SSL setup
Cause
In recent Apache version, Apache team has released fixes for CVEs that affected Apache + nginx functionality: new changes do not allow Apache process requests from nginx without the server name (by default, nginx does not pass the server name through SNI when establishing a connection with a proxied HTTPS server).
This issue has been addresses in Plesk Obsidian 18.0.70 and later releases.
Resolution
Update Plesk Obsidian to the latest build.
Note: The hotfixes are compatible with the manual workaround. So, even for servers where manual solution is already applied, no extra steps are required after installing Plesk update.
Manual workaround for previous Plesk versions:
Add proxy_ssl_server_name, proxy_ssl_name and proxy_ssl_session_reuse directives in nginx configuration to make nginx pass the server name to Apache through TLS Server Name Indication (SNI) extension:
- Connect to the Plesk server via SSH.
-
Run the script (without any modifications):
# echo -e "proxy_ssl_server_name on;\nproxy_ssl_name \$host;\nproxy_ssl_session_reuse off;" > /etc/nginx/conf.d/fixssl.conf && systemctl restart nginx
Comments
When the fix released? I didn't run update the apache but why my server got this error in sudden in this morning (Hong Kong time).
I get a permission error running that script
Hey George Kwan
Most likely you have automatic system updates setting checked in your Plesk at Tools & Settings > Update Settings.
This setting triggers system update every night.
Yes, I just noticed this option is enabled.
The update last night 18.0.71 broke ours
Support said, the issue happened due to Apache package update from OS repository, it has nothing to do with Plesk version.
The below workaround worked.
Andrew Petty I guess you have to log in to your server as a root user or a user which has administrative rights.
Try running
sudo suin your SSH console to switch to root or use SSH Terminal extension in Plesk.I noticed I got the issue after the apt-daily-upgrade.service in this morning.
I applied the script above as root but that just gave a 403 permission page on the website. So I reverted out those lines and back to Misdirected issue.
The apache2 (2.4.58-1ubuntu8.7) was updated over (2.4.58-1ubuntu8.6) and casued the issue!!!
Thank you for the quick fix. Adding the nginx directives and restarting the service resolved the 421 Misdirected Request error.
Best regards
Kev
Kuzma Ivanov
I also had this issue which is fixed by the resolution provided, However this has impacted our system for:
1. The request that was on Apache previously is now coming as Nginx (as checked in server logs)
2. I've running project of PHP where I fetch data of multipart/form-data using $_REQUEST but now due to this it's always set to blank.
Could you please let me know how can I resolve both of the points?
Fix confirmed as working on Ubuntu 22.04 with Plesk 18.0.71.
Began with update installed automatically at approx 03:00h this morning.
Thanks for the quick fix. It worked perfectly
We have updated to new version but the error remains. Plesk update to Versión 18.0.71.
Misdirected Request
The client needs a new connection for this request as the requested host name does not match the Server Name Indication (SNI) in use for this connection.
Any suggestions?
After update we apply:
echo -e "proxy_ssl_server_name on;\nproxy_ssl_name \$host;" > /etc/nginx/conf.d/fixssl.conf && service nginx restart
And starts working!!!
Thanks.
Thank you so much! Saved my day!
This solution works perfectly fine.
Confirmation: Solution for “421 Misdirected Request” after Apache update
I can confirm that the workaround described in this article immediately resolved the “421 Misdirected Request” error on all of my domains after the recent Apache update.
All websites are accessible again via HTTPS and HTTP/2 without any issues.
Thank you for providing an effective and straightforward solution!
You took all Plesk hosted websites down, worldwide. Good job.
Plesk 18.0.71 on Ubuntu 22.04 - Vultr Hosted
problem starts tonight after automatic update; the quick fix worked flawlessly.
Thanks, you saved my day!
I have this similar problem.
"Kuzma Ivanov
I also had this issue which is fixed by the resolution provided, However this has impacted our system for:
1. The request that was on Apache previously is now coming as Nginx (as checked in server logs)
2. I've running project of PHP where I fetch data of multipart/form-data using $_REQUEST but now due to this it's always set to blank.
Could you please let me know how can I resolve both of the points?"
@Manuel Giger, I was thinking the same but after reading above. It looks like issue happened due to Apache package update from OS repository.
“I got the issue after the apt-daily-upgrade.service”
Hello,
my plesk panel did an auto update today, and i got the same problem, but i am not even using nginx to apply that fix, is there another workaround?
The fix worked for me — applied via terminal in Plesk CP
This fix worked! Thanks for the fast fix!
I don't have this issue.
Running…
- Plesk 18.0.71
- Rocky Linux 8.10
- httpd-2.4.37-65.module+el8.10.0+1984+1bed3124.4.x86_64
I ran updates, and there are no updates available for Apache.
I ran the command anyway, just in case an automatic update happens during the night.
This may be an issue specific to Ubuntu.
Thank you very much, this command solved it. IT WORKS!!!
Its also on Ubuntu 24.04.2 LTS.
My automatic updates have been disabled and this error happend as well. Is plesk doing some package updates even if auto updates are disabled? The fix above worked for me.
Marc Pfeiffer have you unchecked all three automatic update checkboxes in the settings?
Same here. Updates disabled. Error happened anyway, fix worked also. But I disabled automatic updates for exactly this reason. I do an AWS AMI backup before every manual update session to be able to revert in critical cases. I don't think it should be updating automatically.
Please sign in to leave a comment.