ERR_HTTP2_PROTOCOL_ERROR : signification et solutions

Qu'est-ce que ERR_HTTP2_PROTOCOL_ERROR ?

ERR_HTTP2_PROTOCOL_ERROR est une erreur de Chrome et d'Edge qui signifie que le navigateur a reçu une réponse HTTP/2 qui enfreint les règles du protocole. Dans Chromium, il s'agit de l'erreur réseau -337 : « il y a une erreur de protocole HTTP/2 ». Chrome n'a pas de page d'erreur dédiée, vous voyez donc la page générique : « Ce site est inaccessible. La page Web à l'adresse … est peut-être temporairement inaccessible ou a peut-être été déplacée de façon permanente vers une nouvelle adresse Web », avec ERR_HTTP2_PROTOCOL_ERROR en dessous.

HTTP/2 est la version plus rapide de HTTP qu'utilisent aujourd'hui la plupart des sites HTTPS. Elle est plus stricte que HTTP/1.1 : les réponses sont découpées en trames binaires, les en-têtes suivent des règles précises, et la taille annoncée d'une réponse doit correspondre à ce qui arrive réellement. Quand Chrome voit une réponse qui enfreint ces règles, par exemple une réponse qui s'arrête en plein flux ou qui contient un en-tête interdit, il considère toute la réponse comme mal formée et la rejette.

Les développeurs la voient souvent dans la console des DevTools sous la forme net::ERR_HTTP2_PROTOCOL_ERROR 200 (OK). Cette combinaison est un indice fort : le serveur a répondu 200, mais le corps de la réponse n'est jamais arrivé intact.

Ce que HTTP/2 considère comme mal formé

La norme HTTP/2 (RFC 9113) liste les erreurs qui rendent une réponse mal formée, et un flux réinitialisé avant la fin échoue lui aussi. Voici les problèmes à l'origine de la plupart des erreurs rencontrées en pratique :

Quelles sont les causes de ERR_HTTP2_PROTOCOL_ERROR ?

La plupart des cas viennent du serveur, mais quelques éléments de votre propre ordinateur peuvent abîmer une réponse à son arrivée :

• Côté serveur : réponses coupées en plein flux (un proxy à court d'espace disque ou incapable d'écrire ses fichiers temporaires, une application qui plante pendant l'envoi, un délai dépassé), valeurs de Content-Length erronées, en-têtes interdits ou invalides, et prise en charge de HTTP/2 boguée dans une ancienne configuration de serveur ou de CDN.

• De votre côté : antivirus ou pare-feu qui inspecte le HTTPS et réécrit les réponses, extensions de navigateur qui modifient les requêtes ou les réponses, copie de la page corrompue dans le cache, et parfois une version obsolète de Chrome.

Solution 1 : rechargement forcé et navigation privée

Appuyez sur Ctrl + Maj + R (Mac : Cmd + Maj + R) pour recharger sans le cache. Une réponse coupée une fois peut très bien passer à la tentative suivante.

Ouvrez ensuite la page dans une fenêtre de navigation privée (Ctrl + Maj + N, sur Mac Cmd + Maj + N). La navigation privée n'a ni cookies ni cache de votre profil habituel, et les extensions y sont désactivées par défaut. Si la page s'y charge, la solution 2 ou la solution 3 réglera le problème dans votre fenêtre normale.

Solution 2 : effacez le cache et les cookies de ce site

Une copie en cache corrompue ou un cookie trop volumineux peut déclencher l'erreur à répétition sur un site. Effacez uniquement les données de ce site : cliquez sur l'icône à gauche de la barre d'adresse → Cookies et données de site (ou Paramètres des sites) → supprimez les données, puis rechargez. Pour un nettoyage plus large, appuyez sur Ctrl + Maj + Suppr et effacez les Images et fichiers en cache des derniers jours.

Solution 3 : suspendez l'analyse HTTPS de l'antivirus et les extensions

Un logiciel de sécurité qui déchiffre et inspecte le HTTPS se place au milieu de chaque connexion HTTP/2. Si sa gestion de HTTP/2 est boguée ou obsolète, il peut transmettre des réponses que Chrome juge mal formées. Désactivez uniquement la fonction d'analyse HTTPS (souvent appelée analyse HTTPS, Agent Web (Web Shield), filtrage des protocoles SSL/TLS ou analyse des connexions chiffrées) et rechargez. Si cela règle le problème, mettez l'antivirus à jour et ajoutez une exclusion pour le site.

Ensuite, désactivez toutes les extensions dans chrome://extensions, rechargez, puis réactivez-les une par une. Les bloqueurs de publicités, les outils de confidentialité et tout ce qui modifie les en-têtes sont les suspects habituels.

Solution 4 : mettez Chrome à jour et testez d'autres navigateurs

Ouvrez chrome://settings/help pour installer toute mise à jour en attente, puis redémarrez le navigateur. Ouvrez ensuite la même page dans Firefox ou Safari. Si elle échoue partout, le site est cassé et seul son propriétaire peut le corriger. Si seuls Chrome ou Edge échouent, le problème vient quand même généralement du site, car Chrome est le plus strict face au HTTP/2 mal formé, mais les solutions 2 et 3 valent la peine d'être refaites.

Solution 5 : testez la page sans HTTP/2

Chrome peut être lancé avec HTTP/2 désactivé, ce qui vous dit avec certitude si HTTP/2 est en cause. Fermez d'abord toutes les fenêtres de Chrome, puis lancez-le depuis un terminal :

# Windows (invite de commandes)
"C:\Program Files\Google\Chrome\Application\chrome.exe" --disable-http2

# macOS (Terminal)
open -a "Google Chrome" --args --disable-http2

Si la page se charge dans cette fenêtre, les réponses HTTP/2 du site sont mal formées et le propriétaire doit les corriger. Fermez ensuite Chrome et rouvrez-le normalement. L'option ne s'applique qu'à ce lancement.

Pour les propriétaires de sites : corriger les erreurs de protocole HTTP/2

Si des visiteurs sur des réseaux et des navigateurs différents signalent l'erreur, le problème se trouve dans votre infrastructure. Ces trois vérifications les trouvent presque toutes.

1. Reproduisez l'erreur avec curl

# HTTP/2 : surveillez la fin de la sortie
curl -sv --http2 https://example.com/broken-page -o /dev/null
# Un flux cassé se termine par quelque chose comme :
# HTTP/2 stream 1 was not closed cleanly: PROTOCOL_ERROR (err 1)
# (curl 8.19+ : HTTP/2 stream 1 reset by server (error 0x1 PROTOCOL_ERROR))

# Même URL en HTTP/1.1 pour comparer
curl -sv --http1.1 https://example.com/broken-page -o /dev/null

Si HTTP/1.1 fonctionne et que HTTP/2 échoue, vous avez confirmé l'erreur. Comparez les en-têtes de réponse entre les deux, et notez combien d'octets arrivent avant que le flux ne casse. L'outil En-têtes HTTP affiche aussi les en-têtes envoyés par votre site, vus depuis l'extérieur de votre réseau.

2. Cherchez les réponses coupées en plein flux

La cause serveur la plus fréquente est une réponse qui commence (statut 200, en-têtes envoyés) puis s'arrête trop tôt. nginx met en mémoire tampon les réponses volumineuses de votre application dans des fichiers temporaires : si le disque est plein ou si nginx ne peut pas écrire dans son dossier temporaire, la réponse s'arrête prématurément et le navigateur signale une erreur de protocole. Vérifiez :

df -h                                   # un disque est-il plein ?
sudo grep -E "No space left|Permission denied" /var/log/nginx/error.log | tail
ls -ld /var/lib/nginx/proxy /var/lib/nginx/fastcgi   # dossiers temporaires Debian/Ubuntu ; le propriétaire doit être l'utilisateur nginx

Vérifiez aussi l'application elle-même : un processus PHP ou Node qui plante, dépasse un délai ou atteint une limite de mémoire pendant l'envoi d'une grosse page ou d'un téléchargement produit le même résultat. Les logs de l'application autour de l'heure de l'erreur le montrent généralement.

3. Corrigez le Content-Length et les en-têtes interdits

• Content-Length : laissez le serveur le calculer. Ne le définissez pas à la main dans le code de l'application si un plugin, un middleware ou le serveur web compresse ou modifie aussi la sortie, car la longueur annoncée ne correspond alors plus aux octets envoyés. Une longueur définie dans le code PHP alors qu'un plugin ou un réglage PHP compresse aussi la sortie est l'une des façons dont cela arrive sur les sites WordPress.

• En-têtes propres à la connexion : supprimez le code qui définit Connection, Keep-Alive, Transfer-Encoding ou Upgrade sur les réponses. HTTP/2 les interdit, et si nginx retire la plupart d'entre eux pour vous, certains serveurs d'application et proxys ne le font pas.

• Valeurs d'en-têtes : assurez-vous qu'aucun en-tête ne contient de saut de ligne ou de caractère de contrôle. Cela vient souvent d'une saisie utilisateur placée dans un en-tête, comme un nom de fichier dans Content-Disposition.

• CDN placé devant : si vous utilisez Cloudflare ou un autre CDN, testez directement le serveur d'origine (avec curl --resolve ou une entrée dans le fichier hosts) pour savoir si l'erreur vient de l'origine ou du CDN.

ERR_HTTP2_PROTOCOL_ERROR et les erreurs similaires

Guides détaillés : ERR_QUIC_PROTOCOL_ERROR, ERR_SSL_PROTOCOL_ERROR, ERR_CONNECTION_CLOSED et ERR_EMPTY_RESPONSE. Pour vérifier le certificat et la configuration HTTPS d'un site depuis l'extérieur, utilisez le Vérificateur SSL.