Table of contents of the article:
During the night between July 17 and 18, 2025 , many system administrators found themselves faced with a sudden and devastating problem: all sites hosted on Plesk servers with Apache + NGINX stacks began returning the 421 Misdirected Request error . Without warning, the sites became inaccessible, with serious implications for those running e-commerce sites, corporate 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, specifically in the context of Server Name Indication (SNI) . This means that the server received an encrypted request but was unable to associate it with a specific, valid SSL certificate for that hostname.
In this case, the error was caused by a change in NGINX behavior after an automatic nightly update deployed via the official Plesk repositories. The update changed the way SSL connections are handled in the presence of reverse proxies, resulting in incorrect TLS negotiation behavior.
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 for correctly passing 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 a thing . No sysadmin made any mistakes, no manual changes were made. It was a nightly automatic update released by the vendor that caused the chaos. 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 software exposes you to these risks . When system management is left in the hands of automated software, the price of "convenience" is loss of control . And 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.
