Table of contents of the article:
During the night between the 17 and the 18 July 2025, many system administrators have found themselves having to deal with a problem as sudden as it is devastating: All sites hosted on Plesk servers with Apache + NGINX stack started returning 421 Misdirected Request errorWithout warning, sites became inaccessible, with serious implications for those running e-commerce sites, business portals, and critical online services.
What is Error 421 Misdirected Request?
This HTTP error is generated by Nginx when it fails to properly route an HTTPS request to the appropriate virtual host, particularly in the context ofSNI (Server Name Indication). This means that the server received an encrypted request, but was unable to associate it with a specific SSL certificate valid for that hostname.
In the case in question, the error was caused by a change in NGINX behavior After an automatic nightly update distributed via the official Plesk repositories, the update changed the way SSL connections are handled in the presence of reverse proxies, resulting in a incorrect behavior in TLS negotiation.
Why did it happen?
With the automatic update, NGINX began explicitly requiring two directives to be present in the SSL proxy configuration:
proxy_ssl_server_name on;
proxy_ssl_name $host;
These directives are essential to correctly pass the requested server name (host) from the NGINX proxy to the HTTPS backend. Without them, NGINX cannot identify the correct certificate to use, and thus returns the infamous 421 Misdirected Request.
How to quickly fix the problem
The technical solution — which immediately restored HTTPS functionality on all domains — is very simple, but it must be applied manually. Just create a custom configuration file inside /etc/nginx/conf.d/ with the correct directives and then restart NGINX:
echo -e “proxy_ssl_server_name on;\nproxy_ssl_name \$host;” > /etc/nginx/conf.d/fixssl.conf && service nginx restart
This small fix allows NGINX to correctly handle incoming requests by passing the requested host to the backend, avoiding the 421 error on all sites that use dynamic or shared TLS certificates (as in the case of Let's Encrypt).
Final (and bitter) considerations
All this happened without anyone touching anything. No sysadmin made any mistakes, no manual changes were made. It was an automatic nightly update Released by the vendor to wreak havoc. A simple package updated in a way that wasn't backwards compatible, and hundreds of websites became inaccessible in a matter of seconds.
We learned from this bad experience that we need to disable Plesk automatic updating.
And for those who work in the sector, a reflection comes spontaneously:
How is it possible that, in 2025, we still have to wake up in the morning and find dozens or hundreds of systems offline due to automatic updates imposed by a control panel?
The truth is simple and inconvenient: relying completely on Plesk, cPanel or similar exposes you to these risks. When system management is left in the hands of automated software, the price of “convenience” is loss of controlAnd those who work in production environments know well that reliability comes before ease.
We at MANAGED SERVER SRL have always recommended professionally managed solutions, with configurations manual, transparent, testable and versioned, Where no update is applied without testing.
A well-configured server without control panels It is often more robust, stable and secure than a “simplified” system managed by software that decides what to do and when to do it, without our knowledge.
Automation, yes, but under human control. Otherwise, it's just another weakness.
