Une mise à jour d’Apache provoque l’erreur « 421 Misdirected Request » sur de nombreux sites web

Ce matin du 17 juillet 2025, de nombreux sites web hébergés via la plate-forme Plesk (un panneau de contrôle d’hébergement) sont subitement devenus inaccessibles, affichant à la place une page d’erreur « 421 Misdirected Request ».

Cette panne fait suite à une mise à jour récente du serveur web Apache sur les systèmes Ubuntu, qui a introduit un changement inattendu causant un conflit avec le proxy Nginx. Résultat : les sites concernés refusaient les connexions HTTPS avec ce code d’erreur inhabituel.
Nous examinons ci-dessous l’ampleur du problème, ses causes et la solution à appliquer.

• Quels serveurs impactés ?

• A quelle date l'erreur a-t-elle été constatée ?

• Cause de l'erreur 421 Misdirected Request

• Nombre de sites touchés en France et dans le monde

• Solution pour corriger l'erreur 421 sur les serveurs

• Et après ?

Ce sont les principaux serveurs affectés. Plesk utilise un duo Nginx + Apache sur Ubuntu, et après la mise à jour nocturne d’Apache, tous les sites web hébergés affichaient une erreur 421. Un administrateur résume : « L’update installé automatiquement vers 3h00 ce matin a déclenché le problème ».

Le bug ne touche pas que Plesk. Par exemple, les utilisateurs du panel HestiaCP (open-source) ont constaté le même « Misdirected Request » après un simple "apt update && apt upgrade" qui mettait Apache à jour. Les logs montraient une mention « no SNI was provided » indiquant l’absence d’indication du nom de domaine dans la connexion SSL.

De manière générale, tout serveur web sous Ubuntu ayant Apache (version récente) derrière un proxy Nginx SSL peut être concerné. Si Nginx ne transmet pas le nom d’hôte lors de la connexion sécurisée, Apache considère la requête comme « mal adressée » et la rejette avec le code 421.

À l’inverse, les serveurs Plesk tournant sous d’autres systèmes (par ex. AlmaLinux, Rocky Linux, Debian, etc.) n’ont pas (encore) rencontré ce bug.
« Cela semble spécifique à Ubuntu », note un administrateur Plesk sous RockyLinux 8, qui n’a reçu aucune mise à jour Apache similaire sur sa distribution.

Le problème est apparu suite à la dernière mise à jour de sécurité d’Apache, publiée mi-juillet 2025.
Canonical (éditeur d’Ubuntu) a diffusé le 16 juillet un bulletin de sécurité listant plusieurs failles corrigées dans Apache. L’une de ces corrections a modifié le comportement d’Apache vis-à-vis de la gestion des noms de domaine en proxy inverse.

Dans la nuit du 16 au 17 juillet, de nombreux serveurs Ubuntu ont appliqué automatiquement cette mise à jour, provoquant les erreurs 421 au petit matin du 17 juillet.

Sur les serveurs Plesk, l’option de mises à jour automatiques est souvent activée, déclenchant une mise à jour système chaque nuit. C’est pourquoi, des administrateurs du monde entier ont découvert leurs sites hors-ligne au réveil.

L’erreur 421 signifie qu’Apache a refusé la requête car « le nom d’hôte demandé ne correspond pas au SNI utilisé pour la connexion ».
En d’autres termes, le serveur a reçu une demande HTTPS destinée à un domaine précis, mais la négociation TLS ne lui a pas indiqué ce nom de domaine (via l’extension SNI). Ce mécanisme SNI (Server Name Indication) permet normalement à un serveur multi-sites de présenter le bon certificat SSL pour le bon domaine.

Dans la configuration Plesk (et similaire), Nginx fait office de proxy devant Apache : il reçoit les connexions HTTPS des visiteurs, puis les transmet en interne à Apache. Le hic, c’est qu’en l’absence de configuration explicite, Nginx n’incluait pas le nom de domaine (SNI) quand il ouvrait sa propre session TLS vers Apache.
Jusqu’à présent, cela passait inaperçu car Apache se contentait de la configuration par défaut. Mais la récente mise à jour a renforcé les vérifications SSL : l’équipe Apache a corrigé des failles liées au fonctionnement conjoint Apache+Nginx , ce qui a introduit cette nouvelle exigence.
Désormais, si le nom du site n’est pas explicitement fourni lors de la connexion, Apache considère la requête comme mal aiguillée et la bloque (donnant le code 421).

En résumé, la mise à jour de sécurité a rendu Apache plus strict sur la correspondance entre la connexion TLS et le site demandé.
Il ne s’agit pas d’un bug volontaire, mais plutôt d’un effet de bord d’un correctif de sécurité.

D’ailleurs, la note Ubuntu indique qu’un ancien paramètre de configuration TLS (SSLEngine optional) a été retiré et peut nécessiter des ajustements dans certains environnements – exactement le cas de figure des proxys Nginx. Plesk a confirmé que le problème est en cours d’investigation de leur côté, en lien avec ces changements Apache.

Il est difficile de quantifier précisément le nombre de sites impactés, mais il s’agit d’une panne de grande ampleur à l’échelle mondiale. Plesk est un acteur majeur de l’hébergement de sites web : la solution équipe plus de 384 000 serveurs et environ 2,3 millions de sites web actifs dans le monde.
Parmi ceux-ci, une proportion significative tourne sous Linux/Ubuntu et a pu recevoir la mise à jour incriminée. Un utilisateur agacé a d’ailleurs commenté : « Vous avez mis hors ligne tous les sites web hébergés avec Plesk dans le monde. Beau travail. ». Cette exagération illustre malgré tout l’impact potentiellement massif : même si seule une fraction des serveurs Plesk a été affectée, cela représente des dizaines de milliers de sites indisponibles simultanément.

En France, où Plesk est également répandu, l’incident a fait des dégâts. On estime à plus de 14 000 le nombre de sites français utilisant Plesk actuellement. Des hébergeurs populaires (OVHcloud, 1&1, IONOS, Ikoula, etc.) proposent Plesk sur leurs offres, ce qui signifie que des milliers de sites français hébergés via ces services ont pu rencontrer l’erreur 421 ce matin.
Par exemple, des sites vitrines d’entreprises sous Wordpress, des boutiques en ligne PrestaShop infogérées ou des blogs personnels gérés via Plesk ont pu se retrouver inaccessibles pendant plusieurs heures.

Pour les visiteurs, le symptôme était simplement une page d’erreur indiquant « 421 Misdirected Request – The request was directed to a server that is not able to produce a response » . Autrement dit, un message d’échec technique que l’internaute moyen ne peut résoudre.

Bonne nouvelle, la correction de ce problème est simple et quasi immédiate. Plesk a publié un correctif de contournement consistant à ajuster la configuration de Nginx afin qu’il renseigne le nom d’hôte (SNI) lors du proxy vers Apache.

Concrètement, il faut ajouter 2 directives dans la configuration globale de Nginx puis redémarrer le service.
Sur un serveur affecté, l’opération se fait en une ligne de commande :

(Cette commande doit être exécutée en root sur le serveur concerné.)

Elle crée un petit fichier de configuration incluant "proxy_ssl_server_name" on et "proxy_ssl_name $host" puis relance Nginx. Instantanément, les sites redeviennent accessibles avec leur certificat correct.

En cas de trafic important, il est recommandé de purger éventuellement le cache CDN (si le site passe par Cloudflare ou autre) une fois le correctif appliqué, afin que les visiteurs récupèrent bien les pages.

Cette solution manuelle a été validée par de nombreux utilisateurs ce jour. Elle n’implique aucun redémarrage complet du serveur, juste Nginx, et l’impact est donc minimal (quelques secondes d’interruption supplémentaire).

Pour les panels comme HestiaCP, une démarche similaire a été partagée : ajouter ces lignes dans les templates Nginx et régénérer les vhosts ce qui règle aussi le souci.

Les administrateurs système qui n’ont pas encore appliqué la mise à jour Apache (par exemple ceux sur des distributions non affectées) peuvent anticiper le problème en ajoutant dès maintenant ces directives Nginx. Cela évitera toute interruption si la mise à jour de sécurité arrive plus tard sur leur système.
Un utilisateur Plesk sur Rocky Linux indique l’avoir fait par précaution, même si son Apache n’avait pas encore bougé. D’une manière générale, vérifier que votre proxy Nginx transmet correctement le SNI à vos backend Apache est désormais une bonne pratique nécessaire.

Du côté des éditeurs, on peut s’attendre à ce que Plesk intègre un correctif permanent dans une prochaine mise à jour de son panel, automatisant l’ajout de ces paramètres pour les configurations concernées.
L’équipe Plesk suit le problème de près (un ticket interne Jira a été ouvert). De même, la communauté open-source pourrait proposer un ajustement dans les configurations par défaut de Nginx pour éviter ce cas de figure à l’avenir.

En attendant, si vous administrez un serveur web Ubuntu, assurez-vous de corriger votre configuration sans tarder. Cette mésaventure rappelle l’importance de la vigilance lors des mises à jour automatiques : même un patch de sécurité bien intentionné peut provoquer des effets de bord.

Heureusement, dans ce cas, la réaction de la communauté a été rapide et la parade facile à appliquer. Quelques heures après l’apparition du problème, « tous les sites sont à nouveau accessibles », concluent soulagés plusieurs administrateurs.

Le retour à la normale est donc en bonne voie et cette alerte 421 ne sera bientôt plus qu’un mauvais souvenir pour les sites web concernés.

Vous cherchez une agence web pour assurer l'hébergement de votre site web et intervenir rapidement en cas de problème ?
Dream me up réalise l'infogérance de vos serveurs web avec réactivité, fiabilité et un accompagnement sur-mesure.