Indice dei contenuti dell'articolo:
Durante la notte tra il 17 e il 18 luglio 2025, moltissimi amministratori di sistema si sono ritrovati a dover affrontare un problema tanto improvviso quanto devastante: tutti i siti ospitati su server Plesk con stack Apache + NGINX hanno iniziato a restituire l’errore 421 Misdirected Request. Senza alcun preavviso, i siti sono diventati inaccessibili, con implicazioni gravi per chi gestisce eCommerce, portali aziendali e servizi critici online.
Cos’è l’errore 421 Misdirected Request?
Questo errore HTTP viene generato da NGINX quando non riesce a instradare correttamente una richiesta HTTPS al virtual host appropriato, in particolare nel contesto dell’SNI (Server Name Indication). Significa che il server ha ricevuto una richiesta cifrata, ma non è riuscito ad associarla a uno specifico certificato SSL valido per quel nome host.
Nel caso in questione, l’errore è stato causato da una modifica nel comportamento di NGINX dopo un aggiornamento automatico notturno distribuito tramite i repository ufficiali Plesk. L’update ha cambiato il modo in cui vengono gestite le connessioni SSL in presenza di reverse proxy, generando un comportamento errato nella negoziazione TLS.
Perché è successo?
Con l’aggiornamento automatico, NGINX ha iniziato a richiedere esplicitamente la presenza di due direttive nella configurazione proxy SSL:
proxy_ssl_server_name on;
proxy_ssl_name $host;
Queste direttive sono fondamentali per passare correttamente il nome del server richiesto (host) dal proxy NGINX al backend HTTPS. Senza di esse, NGINX non riesce a identificare il certificato corretto da usare, e restituisce quindi il famigerato 421 Misdirected Request.
Come risolvere rapidamente il problema
La soluzione tecnica — che ha ripristinato immediatamente la funzionalità HTTPS su tutti i domini — è molto semplice, ma deve essere applicata manualmente. Basta creare un file di configurazione custom all’interno di /etc/nginx/conf.d/ con le direttive corrette e poi riavviare NGINX:
echo -e “proxy_ssl_server_name on;\nproxy_ssl_name \$host;” > /etc/nginx/conf.d/fixssl.conf && service nginx restart
Questo piccolo fix consente a NGINX di gestire correttamente le richieste in ingresso passando l’host richiesto al backend, evitando l’errore 421 su tutti i siti che usano certificati TLS dinamici o condivisi (come nel caso di Let’s Encrypt).
Considerazioni finali (e amare)
Tutto questo è successo senza che nessuno toccasse nulla. Nessun sysadmin ha commesso errori, nessuna modifica manuale è stata fatta. È stato un aggiornamento automatico notturno rilasciato dal vendor a provocare il caos. Un semplice pacchetto aggiornato in modo non retrocompatibile, e centinaia di siti web sono diventati inaccessibili nel giro di pochi secondi.
Abbiamo imparato da questa brutta esperienza che bisogna disabilitare l’aggiornamento automatico di Plesk.
E a chi lavora nel settore, viene spontanea una riflessione:
com’è possibile che, nel 2025, ci si debba ancora svegliare la mattina e trovare decine o centinaia di sistemi offline a causa di aggiornamenti automatici imposti da un pannello di controllo?
La verità è semplice e scomoda: affidarsi completamente a Plesk, cPanel o simili espone a questi rischi. Quando la gestione del sistema è lasciata nelle mani di software automatizzati, il prezzo della “comodità” è la perdita di controllo. E chi lavora in ambienti di produzione sa bene che l’affidabilità viene prima della facilità.
Noi di MANAGED SERVER SRL consigliamo da sempre soluzioni gestite professionalmente, con configurazioni manuali, trasparenti, testabili e versionate, dove nessun aggiornamento viene applicato senza test.
Un server ben configurato senza pannelli di controllo è spesso più robusto, stabile e sicuro rispetto a un sistema “semplificato” gestito da un software che decide cosa fare e quando farlo, a nostra insaputa.
Automazione sì, ma sotto controllo umano. Altrimenti è solo un altro punto debole.
