Today morning I woke up seeing my developer’s message saying the site he was working on is down showing a 421 Misdirected Request error. Upon checking other sites on the same server I saw that only two sites are affected, then I checked another server and all of the sites on that other server of us were showing the same error. Both servers are powered by Plesk. I was like okay, another day, another super urgent issue to fix. So I started my Thursday in rush trying to figure out what has gone wrong all of a sudden. To give you some context our servers use Plesk and we use Cloudflare as our DNS provider. If your website hosted on Plesk too and they suddenly became inaccessible with the following error:
421 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.
First, don’t panic and know that you’re not alone.
Thousands of other sites have experienced or are experiencing downtime as of the time I am writing this post due to a recent Apache update that changed how Server Name Indication (SNI) is handled in proxy setups involving nginx and Apache which is a configuration used by Plesk.
🔍 What Caused the Problem?
My first guess was that this seems to be SSL-related issue. So to fix it, I went ahead and deselected/unassigned the SSL from the hosting settings under the Plesk control panel for the affected sites and boom the site suddenly came up obviously with a site is insecure message. The two sites being affected on the first server were the ones that had the Proxy (orange color) option disabled on CloudFlare DNS settings (which apparently switch off or override the Cloudflare SSL configuration so that the site uses what ever certificate is issued using Plesk I guess.) So when I enabled them the SSL insecure issue got fixed too.
So what suddenly caused this issue:
It appears that Apache recently released a security update that no longer allows proxy requests from nginx without a valid SNI header. This change was part of a patch addressing vulnerabilities (CVEs), and it directly impacts how nginx communicates with Apache over HTTPS in reverse proxy configurations.
Because nginx, by default, doesn’t send the SNI header, Apache fails to match the correct SSL certificate to the requested domain, triggering the 421 Misdirected Request error.
Is this issue exclusive to Plesk servers?
No, this issue is not exclusive to Plesk. It’s caused by a change in Apache’s behavior following a recent update, and it potentially can affect any server setup where nginx is used as a reverse proxy to Apache over HTTPS, not just Plesk who have received the recent Apache update.
✅ Which Sites Are Affected?
- Plesk servers using both nginx + Apache (default configuration)
- Systems that recently received the Apache 2.4.58-1ubuntu8.7 (or similar) update
- Most commonly on Ubuntu 22.04 and newer
- Even servers with automatic updates disabled in Plesk may still receive OS-level package updates via
apt-daily-upgrade
It appears that sites which were using the CloudFlare SSL feature (CluodFlare SSL option set to automatic or Manual Full) and had their A record proxy option enabled and CloudFlare site setting not paused were not affected.
⚡ Temporary Fix (From Plesk)
Plesk has acknowledged the issue and published a workaround that immediately resolves the problem.
👉 Fix Steps via SSH:
- Connect to your server as root (via SSH)
- Run the following command:
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
This command creates a custom nginx config that:
- Forces nginx to pass the server name via SNI
- Prevents SSL session reuse (ensures clean connection)
- Then restarts nginx to apply the changes
✅ Your site(s) should start working again within seconds, I tested this on two of our Plesk servers and it worked like a charm.
🛠 Alternative Workarounds
If you’re unable to apply the SSH fix:
1. Use Cloudflare as the SSL Termination Point
If you’re using Cloudflare, you can:
- Set SSL mode in Cloudflare to Full (or Full Strict)
- In Plesk > Hosting Settings > set SSL certificate to “None”. Make sure if you host your emails you will not turn off or misconfigure the SSL used by your mail server as that can affect your email deliverability.
This effectively tells the server to skip SSL handling and lets Cloudflare manage it.
🧠 This is only a workaround and works best when Cloudflare is proxying (orange cloud ON).
2. Temporarily Disable HTTP/2 (I didn’t test this myself.)
In some cases, HTTP/2 exacerbates the SNI mismatch issue.
To disable HTTP/2 for a specific domain in Plesk:
- Go to Domains > yourdomain.com > Apache & nginx Settings
- Under Additional Apache directives for HTTPS, add:apacheCopyEdit
Protocols http/1.1
- Save and restart Apache
🧪 How to Verify It’s Fixed
Okay, it’s silly to write this, you probably know how to test your site is working, but in my case I fixed this and it came up and then my developer again texted me back that it is not fixed for him at least. So verify your site is coming up using all the following methods:
- Visiting it in your browser, use a new incognito tab or test on different browsers with their cache and history cleared (HTTPS version)
- Test with curl from your terminal (if curl is installed already). Try running:
curl -Iv https://yourdomain.com
- And finally testing the SSL via: SSL Labs Test or this SSL checker.
📌 Permanent Fix on the Way
Plesk is working on integrating a fix into upcoming versions (Plesk Obsidian 18.0.70/71+). You can follow their KB article on this link here to get notified when the patch becomes part of the official updates.
✅ Summary
Fix Option | Use Case |
---|---|
Add proxy_ssl_name fix via SSH | Recommended for all Plesk servers with nginx |
Disable SSL in Plesk and use Cloudflare SSL | Works if you’re behind Cloudflare |
Disable HTTP/2 | Useful if still getting SNI errors |
Wait for Plesk’s permanent fix | Plesk is aware and will patch in updates |
If you’re managing client websites on Plesk, it’s a good idea to proactively apply this patch to all affected servers — even if they haven’t shown the error yet especially if your server is running Ubuntu 22.04 or if automatic updates are enabled.
Need help applying the fix? Feel free to reach out.