Table des matières de l'article :
Pendant la nuit entre le 17 et 18 July 2025, de nombreux administrateurs système se sont retrouvés confrontés à un problème aussi soudain que dévastateur : Tous les sites hébergés sur des serveurs Plesk avec la pile Apache + NGINX ont commencé à renvoyer l'erreur 421 de requête mal dirigéeSans avertissement, les sites sont devenus inaccessibles, avec de graves conséquences pour ceux qui gèrent des sites de commerce électronique, des portails d’affaires et des services en ligne critiques.
Qu'est-ce que l'erreur 421 Demande mal dirigée ?
Cette erreur HTTP est générée par Nginx lorsqu'il ne parvient pas à acheminer correctement une requête HTTPS vers l'hôte virtuel approprié, en particulier dans le contexte deSNI (indication du nom du serveur)Cela signifie que le serveur a reçu une demande chiffrée, mais n'a pas pu l'associer à un certificat SSL spécifique valide pour ce nom d'hôte.
Dans le cas en question, l’erreur a été causée par un changement de comportement de NGINX Après une mise à jour nocturne automatique distribuée via les référentiels officiels de Plesk, la mise à jour a modifié la façon dont les connexions SSL sont gérées en présence de proxys inverses, ce qui a entraîné une comportement incorrect dans la négociation TLS.
Pourquoi est-ce arrivé?
Avec la mise à jour automatique, NGINX a commencé à exiger explicitement que deux directives soient présentes dans la configuration du proxy SSL :
proxy_ssl_server_name activé ;
nom_proxy_ssl $hôte;
Ces directives sont essentielles pour transmettre correctement le nom du serveur (hôte) demandé par le proxy NGINX au serveur HTTPS. Sans elles, NGINX ne peut pas identifier le certificat correct à utiliser, et renvoie ainsi l'infâme 421 Demande mal acheminée.
Comment résoudre rapidement le problème
La solution technique — qui a immédiatement restauré la fonctionnalité HTTPS sur tous les domaines — est très simple, mais il doit être appliqué manuellement. Il suffit de créer un fichier de configuration personnalisé à l'intérieur. /etc/nginx/conf.d/ avec les directives correctes puis redémarrez NGINX :
echo -e « nom_serveur_proxy_ssl activé ;\nnom_serveur_proxy_ssl \$hôte ; » > /etc/nginx/conf.d/fixssl.conf && redémarrage du service nginx
Ce petit correctif permet à NGINX de gérer correctement les requêtes entrantes en transmettant l'hôte demandé au backend, évitant ainsi l'erreur 421 sur tous les sites qui utilisent des certificats TLS dynamiques ou partagés (comme dans le cas de Let's Encrypt).
Considérations finales (et amères)
Tout cela s'est produit sans que personne ne touche à quoi que ce soitAucun administrateur système n'a commis d'erreur, aucune modification manuelle n'a été effectuée. une mise à jour nocturne automatique Lancé par le fournisseur pour semer le chaos. Un simple package mis à jour de manière non rétrocompatible a rendu des centaines de sites web inaccessibles en quelques secondes.
Nous avons appris de cette mauvaise expérience que nous devons désactiver la mise à jour automatique de Plesk.
Et pour ceux qui travaillent dans le secteur, une réflexion vient spontanément :
Comment est-il possible qu’en 2025, nous devions encore nous réveiller le matin et trouver des dizaines ou des centaines de systèmes hors ligne à cause de mises à jour automatiques imposées par un panneau de contrôle ?
La vérité est simple et gênante : se fier entièrement à Plesk, cPanel ou similaire vous expose à ces risques. Lorsque la gestion du système est laissée entre les mains d’un logiciel automatisé, le prix de la « commodité » est perte de contrôleEt ceux qui travaillent dans des environnements de production savent bien que la fiabilité passe avant la facilité.
Chez MANAGED SERVER SRL, nous avons toujours recommandé des solutions gérées par des professionnels, avec des configurations manuel, transparent, testable et versionnéoù aucune mise à jour n'est appliquée sans test.
Un serveur bien configuré sans panneaux de contrôle Il est souvent plus robuste, stable et sécurisé qu’un système « simplifié » géré par un logiciel qui décide quoi faire et quand le faire, à notre insu.
L'automatisation, oui, mais sous contrôle humain. Sinon, ce n'est qu'une faiblesse de plus.
