ERR_HTTP2_PROTOCOL_ERROR : causes et corrections

Ce que signifie ERR_HTTP2_PROTOCOL_ERROR

HTTP/2 envoie les requêtes et les réponses sous forme de trames binaires sur une seule connexion, avec des règles strictes concernant la taille des trames, l'encodage des en-têtes (HPACK), et l'état des flux. Un serveur, un proxy, ou un CDN qui envoie une trame mal formée, un en-tête surdimensionné, ou une trame pour un flux déjà fermé enfreint ces règles, et le client démonte la connexion plutôt que de deviner ce qui était voulu. Comme l'échec peut provenir du serveur applicatif, d'un proxy intermédiaire, d'une bordure CDN, ou de la propre pile réseau du navigateur, cette erreur couvre un éventail de causes racines plus large que la plupart des autres de cette liste.

Comment l'erreur apparaît

Chrome et Edge affichent « This page isn't working - ERR_HTTP2_PROTOCOL_ERROR », parfois seulement sur certains chargements de page et pas d'autres, ce qui est un indice que la panne est intermittente plutôt qu'une mauvaise configuration fixe. Firefox affiche généralement une erreur de connexion générique plutôt que de nommer le protocole.

curl peut forcer HTTP/2 et montrer exactement sur quelle trame la connexion a échoué :

curl --http2 -v https://example.com/ 2>&1 | tail -20
...
* Recv failure: Connection reset by peer
* HTTP/2 stream 1 was not closed cleanly: PROTOCOL_ERROR (err 1)

Comparer cela à une requête HTTP/1.1 vers la même URL permet d'isoler si le problème est spécifique au protocole :

curl --http1.1 -sI https://example.com/

Si la requête HTTP/1.1 réussit et que celle en HTTP/2 échoue, la faute se situe dans la façon dont quelque chose dans la chaîne implémente HTTP/2, pas dans l'application elle-même.

Ce qui provoque ERR_HTTP2_PROTOCOL_ERROR

• Des en-têtes mal formés ou surdimensionnés venant de l'application ou d'un proxy. Un cookie très long, un ensemble surdimensionné d'en-têtes de réponse, ou une valeur d'en-tête contenant des caractères que HPACK ne peut pas encoder violeront la taille de trame que le serveur ou le client attend.
• Un reverse proxy ou un équilibreur de charge avec une implémentation HTTP/2 bogué ou obsolète. Certaines piles HTTP/2 plus anciennes de nginx, Apache, ou d'appareils embarqués ont des problèmes connus avec des séquences de trames spécifiques sous charge.
• Un bug de bordure CDN ou une incompatibilité de protocole entre la bordure et l'origine. Le tronçon navigateur-vers-bordure et le tronçon bordure-vers-origine peuvent utiliser des protocoles différents ; un bug dans la traduction entre les deux produit occasionnellement cette erreur seulement pour certaines formes de requêtes.
• Un logiciel antivirus ou une extension de navigateur qui intercepte le trafic HTTPS. La même classe de logiciel qui cause des échecs de handshake SSL peut aussi casser un flux HTTP/2 sain si sa couche d'interception ne parle pas correctement HTTP/2.
• Un navigateur obsolète avec une vieille implémentation HTTP/2, ou un cache réseau de navigateur corrompu.
• Une incompatibilité de Content-Length derrière un reverse proxy. Si nginx (ou un autre proxy) transmet une réponse dont le Content-Length déclaré ne correspond pas aux octets réellement envoyés, le framing HTTP/2 en aval peut se casser en cours de route.

Comment savoir de qui vient la faute

Lancez une vérification HTTP depuis plusieurs emplacements : si l'échec est constant partout, la gestion de HTTP/2 par le serveur ou le CDN est en cause. S'il n'échoue que pour vous, il est bien plus probable que ce soit local, un navigateur, un antivirus, ou un équipement réseau entre vous et le site.

Comment corriger ERR_HTTP2_PROTOCOL_ERROR

Si vous êtes visiteur

1. Rechargez la page. Puisque la cause est souvent une seule trame mal formée plutôt qu'une mauvaise configuration persistante, une connexion fraîche réussit fréquemment.
2. Videz le cache du navigateur sur chrome://settings/clearBrowserData, puisqu'une ressource mise en cache corrompue peut déclencher cela au rechargement.
3. Désactivez temporairement le scan HTTPS/SSL de l'antivirus et réessayez ; cette classe de logiciel est une cause courante et souvent négligée.
4. Essayez une fenêtre incognito pour écarter une extension.
5. Mettez à jour le navigateur vers la dernière version, puisque d'anciennes implémentations client HTTP/2 avaient des bugs connus.

Si vous gérez le site

1. Comparez HTTP/2 à HTTP/1.1 avec les commandes curl ci-dessus. Si seul HTTP/2 échoue, le problème se situe dans la couche HTTP/2 d'un proxy ou d'un CDN, pas dans l'application.
2. Relevez les limites de taille d'en-tête de nginx si de gros cookies ou en-têtes sont impliqués :

   http2_max_field_size 16k;
   http2_max_header_size 32k;
   large_client_header_buffers 4 16k;

   Redémarrez ou rechargez nginx après le changement et retestez.
3. Cherchez une incompatibilité de Content-Length entre ce que l'application envoie et ce que le proxy transmet ; activez la mise en tampon du proxy (proxy_buffering on;) pour que nginx puisse lire la réponse complète avant de la mettre en trames pour HTTP/2.
4. Mettez à jour nginx, Apache, ou tout équilibreur de charge vers une version actuelle ; les bugs de gestion de trames HTTP/2 sont le genre de chose qui se corrige dans des versions mineures.
5. Désactivez HTTP/2 comme test de diagnostic, pas comme correction permanente : retirez temporairement http2 de la directive listen de nginx. Si les erreurs s'arrêtent, la faute est confirmée comme étant spécifiquement dans la couche HTTP/2, et vous pouvez le réactiver une fois la correction d'en-tête ou de mise en tampon ci-dessus en place.
6. Vérifiez les journaux côté CDN si un CDN se trouve devant l'origine ; la plupart des CDN font apparaître les erreurs de framing HTTP/2 dans leurs journaux de bordure avec plus de détails que ce que le navigateur montre jamais.

Erreurs associées

• ERR_SSL_PROTOCOL_ERROR ressemble à celle-ci mais échoue plus tôt, pendant le handshake TLS, avant qu'aucune trame HTTP/2 ne soit échangée du tout.
• Les codes d'erreur serveur 5xx couvrent les cas où la connexion et le protocole fonctionnent bien mais où l'application elle-même échoue.

Un détail qui vaut la peine d'être distingué : une erreur de protocole HTTP/2 n'est pas la même chose qu'un flux HTTP/2 proprement réinitialisé par l'application, par exemple quand un client annule une requête en plein vol. Les outils de développement du navigateur et les journaux d'accès du serveur étiquettent parfois les deux comme « reset », mais seule une véritable violation de framing produit ERR_HTTP2_PROTOCOL_ERROR dans le navigateur ; un flux annulé intentionnellement s'arrête simplement sans page d'erreur.

Comment prévenir ERR_HTTP2_PROTOCOL_ERROR

Comme cette erreur est souvent intermittente, liée à des tailles d'en-tête spécifiques ou à des versions de proxy spécifiques, elle peut affecter une fraction des visiteurs pendant des semaines avant que quiconque ne remarque un schéma. Une vérification HTTP s'exécutant selon un calendrier depuis plusieurs emplacements détecte un taux d'échec croissant juste après un déploiement, un changement de CDN, ou une mise à jour de proxy, plutôt que de dépendre de signalements dispersés d'utilisateurs. HostTracker alerte par e-mail, SMS, appel vocal, Slack, Telegram et bien plus dès qu'une vérification commence à échouer.

Questions fréquentes

ERR_HTTP2_PROTOCOL_ERROR est-il la même chose qu'une erreur SSL ?

Non. Cette erreur se produit après le succès du TLS, au niveau de la couche de framing HTTP/2. Une erreur SSL signifie que la connexion chiffrée elle-même ne s'est jamais formée.

Pourquoi l'erreur n'apparaît-elle que parfois, pas à chaque chargement de page ?

La plupart des causes ici sont déclenchées par des conditions spécifiques, un en-tête qui dépasse une limite, une course dans un proxy sous charge, une ressource en cache particulière, plutôt qu'une mauvaise configuration fixe qui échouerait à chaque fois.

Désactiver HTTP/2 sur mon serveur nuira-t-il aux performances ?

HTTP/2 offre de vrais avantages (multiplexage, compression d'en-têtes), donc traitez sa désactivation comme une étape de diagnostic temporaire, pas comme une correction permanente. Corrigez le problème sous-jacent de taille d'en-tête ou de mise en tampon et réactivez-le.

Un CDN peut-il causer cela même si mon serveur d'origine va bien ?

Oui. La bordure CDN et l'origine peuvent utiliser des protocoles différents sur chaque tronçon de la connexion, et un bug ou une mauvaise configuration dans la façon dont le CDN traduit entre les deux peut produire cette erreur indépendamment de la santé propre de l'origine.

Cela arrive-t-il sur des sites en HTTP/1.1 ?

Non, ERR_HTTP2_PROTOCOL_ERROR est spécifique aux connexions qui ont négocié HTTP/2. Un site ne servant que du HTTP/1.1 ne peut pas produire cette erreur précise, même s'il peut avoir ses propres problèmes de connexion.