Comment corriger l’erreur ERR_SPDY_PROTOCOL_ERROR dans Chrome

ERR_SPDY_PROTOCOL_ERROR est une erreur réseau Chrome qui survient lorsque le navigateur ne parvient pas à établir ou maintenir une session SPDY ou HTTP/2 valide avec un serveur web. Elle se manifeste par un échec de chargement de page, généralement accompagné de l’écran d’erreur standard de Chrome, et peut être déclenchée par des connexions socket obsolètes, des données de cache corrompues, des incompatibilités TLS/SSL, des extensions interférentes ou une négociation de protocole mal configurée côté serveur.

Le nom de l’erreur fait référence à SPDY — le protocole de transport multiplexé de Google, désormais obsolète, qui a précédé HTTP/2. Bien que Chrome ait abandonné la prise en charge native de SPDY après la version 51, la couche interne de gestion des sockets et des sessions utilise toujours la terminologie dérivée de SPDY, ce qui explique pourquoi le code d’erreur persiste même sur les connexions HTTP/2 et HTTP/3 modernes. Comprendre cette distinction est essentiel pour diagnostiquer précisément la cause profonde.

Ce qui cause réellement ERR_SPDY_PROTOCOL_ERROR

Avant d’appliquer des correctifs à l’aveugle, il est utile de connaître les modes de défaillance précis à l’origine de cette erreur :

• Sessions socket SPDY/HTTP2 obsolètes mises en cache dans le pool de connexions de Chrome qui ne correspondent plus à l’état TLS actuel du serveur
• Certificats SSL/TLS expirés ou réémis côté serveur qui invalident une session existante sans réinitialisation propre de la négociation
• Incompatibilités ALPN (Application-Layer Protocol Negotiation) où le serveur annonce la prise en charge de HTTP/2 mais la négociation TLS échoue en cours de session
• Données de profil de navigateur corrompues, notamment le cache, les cookies ou le fichier d’état réseau
• Proxy, VPN ou logiciel de sécurité effectuant une inspection TLS qui brise la couche de tramage HTTP/2
• Versions de Chrome obsolètes présentant des bogues connus dans l’implémentation HTTP/2 ou QUIC
• Mauvaise configuration côté serveur — par exemple, une instance Nginx ou Apache avec un module h2 défaillant, ou un certificat expiré sur un nœud edge CDN

Correctif 1 : Vider directement les sockets SPDY

C’est le correctif le plus ciblé et devrait être votre première action. Chrome maintient un pool persistant de sessions socket SPDY/HTTP2. Si une session devient corrompue — par exemple, après un redémarrage du serveur ou la réémission d’un certificat — Chrome continuera à réutiliser la session défaillante jusqu’à ce qu’elle soit explicitement vidée.

1. Ouvrez un nouvel onglet Chrome.
2. Naviguez vers chrome://net-internals/#sockets
3. Cliquez sur Flush socket pools.
4. Puis naviguez vers chrome://net-internals/#dns
5. Cliquez sur Clear host cache.
6. Fermez l’onglet et rechargez la page défaillante.

Ce vidage en deux étapes efface simultanément le pool de sessions de la couche transport et le cache de résolution DNS, ce qui résout les deux causes les plus courantes dans le navigateur en une seule opération.

Pourquoi l’ancienne URL ne fonctionne plus : De nombreux guides font encore référence à chrome://net-internals/#events&q=type:SPDY_SESSION%20is:active. Chrome a supprimé l’onglet Events dans les versions récentes. Utilisez directement #sockets et #dns.

Correctif 2 : Vider le cache et les cookies du navigateur

Les réponses HTTP mises en cache, les cookies stockés et l’état HSTS (HTTP Strict Transport Security) obsolète peuvent tous entrer en conflit avec la configuration TLS ou de protocole actuelle d’un serveur.

1. Ouvrez Chrome et appuyez sur Ctrl+Shift+Delete (Windows/Linux) ou Cmd+Shift+Delete (macOS).
2. Définissez la Plage de temps sur Toute la période.
3. Cochez Cookies et autres données des sites et Images et fichiers en cache.
4. Cliquez sur Effacer les données.

Pour une approche plus chirurgicale — si vous souhaitez uniquement effacer les données d’un domaine spécifique sans supprimer l’intégralité de l’état de votre navigateur — utilisez ce qui suit :

1. Naviguez vers chrome://settings/siteData
2. Recherchez le domaine concerné.
3. Supprimez uniquement les cookies et le stockage de ce site.

De plus, effacez l’état HSTS du domaine sur chrome://net-internals/#hsts en saisissant le nom d’hôte sous Delete domain security policies. Une entrée HSTS obsolète peut forcer Chrome à emprunter un chemin de mise à niveau qui entre en conflit avec un serveur ayant modifié sa configuration TLS.

Correctif 3 : Mettre à jour Google Chrome

Les implémentations HTTP/2 et QUIC de Chrome reçoivent des correctifs fréquents. Utiliser une version obsolète peut signifier que vous portez des bogues de gestion de protocole connus qui ont déjà été corrigés en amont.

1. Cliquez sur le menu à trois points et accédez à Aide > À propos de Google Chrome.
2. Chrome vérifiera et téléchargera automatiquement les mises à jour.
3. Cliquez sur Relancer pour appliquer la mise à jour.

Pour vérifier votre version actuelle depuis la barre d’adresse, naviguez vers chrome://version/. Comparez le numéro de build avec le blog Chrome Releases pour confirmer que vous utilisez le dernier canal stable.

Correctif 4 : Désactiver le VPN, le proxy et les outils d’inspection TLS

Les VPN, les proxys d’entreprise et les produits antivirus qui effectuent une inspection approfondie SSL/TLS (également appelée interception HTTPS) sont une cause fréquente et sous-diagnostiquée de ERR_SPDY_PROTOCOL_ERROR. Ces outils terminent la connexion TLS au niveau du client, la rechiffrent avec leur propre certificat et la transmettent au serveur. Si l’implémentation HTTP/2 de l’outil est incomplète ou si sa chaîne de certificats n’est pas approuvée, Chrome rejettera la session.

Pour désactiver les paramètres proxy sous Windows :

1. Appuyez sur Win+I pour ouvrir les Paramètres.
2. Accédez à Réseau et Internet > Proxy.
3. Définissez Détecter automatiquement les paramètres sur Activé et Utiliser un serveur proxy sur Désactivé.

Pour désactiver les paramètres proxy via l’Invite de commandes :

netsh winhttp reset proxy

Pour vérifier si un proxy est actuellement actif :

netsh winhttp show proxy

Si vous êtes sur un réseau d’entreprise, consultez votre administrateur informatique avant de désactiver les paramètres proxy, car cela pourrait enfreindre la politique réseau. Demandez plutôt si l’outil d’inspection SSL prend en charge le mode de passage HTTP/2.

Correctif 5 : Réinitialiser la pile TCP/IP et vider le cache DNS

Des entrées corrompues dans la pile TCP/IP ou un cache DNS empoisonné peuvent provoquer des échecs de connexion qui se manifestent sous forme d’erreurs de protocole. Ce correctif opère au niveau de la couche réseau du système d’exploitation, en dessous de Chrome lui-même.

Ouvrez l’Invite de commandes en tant qu’Administrateur (appuyez sur Win+R, tapez cmd, puis appuyez sur Ctrl+Shift+Enter), puis exécutez les commandes suivantes dans l’ordre :

netsh int ip reset
netsh winsock reset
ipconfig /flushdns
ipconfig /release
ipconfig /renew

Redémarrez votre machine après avoir exécuté ces commandes. La commande netsh winsock reset est particulièrement importante — un catalogue Winsock corrompu peut provoquer des erreurs de protocole intermittentes et apparemment aléatoires qui sont difficiles à remonter jusqu’à leur source.

Sur macOS, la commande équivalente pour vider le DNS est :

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

Correctif 6 : Désactiver ou isoler les extensions du navigateur

Les extensions qui interceptent les requêtes réseau — bloqueurs de publicités, outils de confidentialité, extensions antivirus, extensions VPN et commutateurs de proxy personnalisés — peuvent corrompre les trames HTTP/2 ou injecter des en-têtes qui violent la spécification HTTP/2, déclenchant une erreur de protocole.

Méthode d’isolation systématique :

1. Ouvrez chrome://extensions/
2. Désactivez toutes les extensions simultanément.
3. Rechargez la page défaillante.
4. Si l’erreur a disparu, réactivez les extensions une par une, en rechargeant la page après chacune, jusqu’à identifier le coupable.

Vous pouvez également ouvrir Chrome en mode Navigation privée (Ctrl+Shift+N), qui désactive toutes les extensions par défaut (sauf si vous les avez explicitement autorisées en Navigation privée). Si la page se charge correctement en Navigation privée, une extension est définitivement la cause.

Correctif 7 : Redémarrer votre routeur ou modem

Les tables NAT (Network Address Translation) et l’inspection de paquets avec état sur les routeurs grand public peuvent conserver des entrées de session TCP obsolètes qui empêchent les nouvelles connexions HTTP/2 de compléter leur négociation. Un cycle d’alimentation complet — pas seulement un redémarrage logiciel — efface ces tables.

1. Éteignez complètement le routeur et le modem.
2. Attendez 60 secondes (pas 30 — les condensateurs ont besoin de temps pour se décharger complètement et effacer l’état volatile).
3. Allumez d’abord le modem, attendez qu’il se synchronise complètement, puis allumez le routeur.
4. Attendez une connexion complète avant de tester.

Correctif 8 : Désactiver temporairement l’antivirus ou le pare-feu

Les logiciels de sécurité dotés de fonctionnalités de scan HTTPS ou de bouclier web fonctionnent de manière similaire à un proxy d’inspection TLS d’entreprise. Ils interceptent la négociation TLS, ce qui peut briser la négociation de session HTTP/2 si le moteur du logiciel de sécurité ne prend pas entièrement en charge l’extension ALPN ou le tramage HTTP/2.

Les produits courants connus pour causer ce problème incluent Avast, AVG, Kaspersky et ESET lorsque leurs modules de protection web sont actifs.

• Désactivez temporairement la fonctionnalité Bouclier Web ou Scan HTTPS spécifiquement (pas l’antivirus entier).
• Testez l’URL défaillante.
• Si l’erreur se résout, cherchez une option pour ajouter le site concerné à une liste d’exclusion du scan HTTPS plutôt que de désactiver la protection globalement.

Correctif 9 : Créer un nouveau profil Chrome

Un profil utilisateur Chrome corrompu — spécifiquement le sous-dossier Network dans le répertoire du profil — peut provoquer des ERR_SPDY_PROTOCOL_ERROR persistantes qui survivent aux vidages de cache et aux vidages de sockets. Le fichier d’état réseau du profil stocke les données HSTS, les journaux de transparence des certificats et les résultats de négociation de protocole mis en cache.

Pour tester avec un profil vierge :

1. Naviguez vers chrome://settings/
2. Faites défiler jusqu’à Personnes et cliquez sur Ajouter une personne (ou Ajouter un profil).
3. Créez un profil de test minimal.
4. Ouvrez l’URL défaillante dans le nouveau profil.

Si l’URL se charge correctement dans le nouveau profil, le problème est isolé à l’état réseau stocké de votre profil d’origine. Vous pouvez supprimer manuellement le dossier Network de votre répertoire de profil sans perdre vos favoris ni vos mots de passe :

• Windows : %LOCALAPPDATA%GoogleChromeUser DataDefaultNetwork
• macOS : ~/Library/Application Support/Google/Chrome/Default/Network
• Linux : ~/.config/google-chrome/Default/Network

Supprimez le dossier Network lorsque Chrome est fermé, puis relancez-le.

Correctif 10 : Diagnostiquer et escalader les problèmes côté serveur

Si tous les correctifs côté client échouent, l’erreur provient du serveur. Les causes courantes côté serveur incluent :

• Certificat SSL/TLS expiré ou récemment réémis sans redémarrage du serveur pour prendre en compte le nouveau certificat
• Configuration HTTP/2 défaillante dans Nginx (directive http2 mal configurée) ou Apache (mod_http2 chargé mais Protocols h2 http/1.1 non correctement défini)
• Mauvaise configuration du CDN ou du proxy inverse où le nœud edge et le serveur d’origine ont des paramètres de protocole conflictuels
• Incompatibilité de version TLS — par exemple, un serveur configuré pour utiliser uniquement TLS 1.3 tandis qu’un proxy intermédiaire ne prend en charge que TLS 1.2

Exemple de configuration HTTP/2 correcte pour Nginx :

server {
    listen 443 ssl;
    http2 on;
    ssl_certificate     /etc/ssl/certs/your_domain.crt;
    ssl_certificate_key /etc/ssl/private/your_domain.key;
    ssl_protocols       TLSv1.2 TLSv1.3;
    ssl_ciphers         HIGH:!aNULL:!MD5;
}

Remarque : Dans Nginx 1.25.1+, http2 on remplace l’ancienne syntaxe listen 443 ssl http2. L’utilisation de la syntaxe obsolète sur les versions récentes peut provoquer des échecs de négociation ALPN.

Exemple de configuration HTTP/2 correcte pour Apache :

Protocols h2 http/1.1
SSLEngine on
SSLCertificateFile    /etc/ssl/certs/your_domain.crt
SSLCertificateKeyFile /etc/ssl/private/your_domain.key

Si vous gérez votre propre infrastructure serveur, vous assurer que vos Certificats SSL sont valides, correctement chaînés et renouvelés avant expiration élimine le déclencheur côté serveur le plus courant de cette erreur. Les environnements d’hébergement fonctionnant sur un Hébergement VPS correctement maintenu vous donnent un accès direct aux fichiers de configuration du serveur, ce qui facilite l’application de ces correctifs sans attendre un fournisseur d’hébergement mutualisé.

Pour les équipes exécutant des applications web sur des Serveurs Dédiés, vérifier que mod_http2 ou le module HTTP/2 de Nginx est correctement compilé et activé devrait faire partie de toute liste de contrôle post-déploiement.

Outils de diagnostic pour identifier la cause profonde plus rapidement

Avant de parcourir chaque correctif séquentiellement, utilisez ces outils pour cerner la source :

La commande curl est particulièrement utile pour confirmer si le problème est spécifique au navigateur ou à l’ensemble du serveur :

curl -v --http2 https://your-domain.com 2>&1 | grep -E "ALPN|HTTP|SSL|error"

Si curl échoue également à négocier HTTP/2, le problème est définitivement côté serveur. Si curl réussit mais que Chrome échoue, le problème se situe dans l’état de session du navigateur ou dans un outil d’interception local.

ERR_SPDY_PROTOCOL_ERROR vs. erreurs réseau Chrome associées

Pour les sites où QUIC cause de l’instabilité, vous pouvez le désactiver sur chrome://flags/#enable-quic en définissant le flag sur Disabled. Cela force Chrome à revenir à HTTP/2 ou HTTP/1.1 basé sur TCP.

Matrice de décision technique : quel correctif appliquer en premier

Utilisez cette matrice pour prioriser votre dépannage en fonction du contexte dans lequel l’erreur apparaît :

Si vous gérez votre propre serveur web et avez besoin d’un panneau de contrôle pour simplifier la gestion des SSL et des protocoles, les Panneaux de contrôle VPS fournissent des interfaces graphiques pour l’installation de certificats et la configuration du serveur web, réduisant le risque de mauvaise configuration manuelle. Pour les projets plus petits sur un Hébergement Web Mutualisé, les paramètres de protocole sont gérés au niveau de l’infrastructure — contactez le support si vous suspectez une mauvaise configuration HTTP/2 côté serveur.

Liste de contrôle avant d’escalader

Parcourez cette liste de contrôle dans l’ordre. Arrêtez-vous à l’étape qui résout l’erreur.

• [ ] Vider les pools de sockets sur chrome://net-internals/#sockets
• [ ] Vider le cache DNS hôte sur chrome://net-internals/#dns
• [ ] Supprimer la politique HSTS du domaine sur chrome://net-internals/#hsts
• [ ] Effacer tout le cache et les cookies du navigateur (Toute la période)
• [ ] Tester en mode Navigation privée pour exclure les extensions
• [ ] Tester dans un second navigateur (Firefox, Edge) pour exclure les problèmes spécifiques à Chrome
• [ ] Désactiver temporairement le scan HTTPS de l’antivirus
• [ ] Désactiver le VPN ou le proxy
• [ ] Exécuter netsh winsock reset et ipconfig /flushdns en tant qu’Administrateur
• [ ] Cycle d’alimentation complet du routeur et du modem (décharge complète de 60 secondes)
• [ ] Créer un nouveau profil Chrome et supprimer le dossier Network de l’ancien profil
• [ ] Exécuter curl -v --http2 https://your-domain.com pour déterminer si le problème est côté serveur
• [ ] Si côté serveur : auditer la validité du certificat SSL, la configuration du module HTTP/2 et recharger le processus serveur
• [ ] Mettre à jour Chrome vers la dernière version stable

FAQ

Qu’est-ce que ERR_SPDY_PROTOCOL_ERROR et pourquoi apparaît-il encore si SPDY est obsolète ?

La pile réseau interne de Chrome a hérité de codes d’erreur de l’ère SPDY qui n’ont jamais été renommés. L’erreur apparaît désormais pour tout échec dans la couche de session HTTP/2 ou QUIC — y compris les échecs de négociation ALPN, les négociations TLS défaillantes et les entrées de pool de connexions obsolètes — même si SPDY lui-même n’est plus utilisé depuis Chrome 51.

Pourquoi l’erreur apparaît-elle sur un seul site web et pas sur les autres ?

Cela indique presque toujours soit une session socket Chrome obsolète spécifique à ce domaine, soit un problème côté serveur sur cet hôte particulier — comme un certificat récemment réémis qui a invalidé les sessions existantes, ou une configuration HTTP/2 défaillante sur ce serveur. Vider les pools de sockets et tester avec curl --http2 confirmera lequel des deux est en cause.

Un logiciel antivirus peut-il vraiment causer ERR_SPDY_PROTOCOL_ERROR ?

Oui. Les produits de sécurité qui effectuent une inspection HTTPS (Avast, AVG, Kaspersky, ESET et autres) agissent comme un proxy TLS man-in-the-middle. Si leur implémentation HTTP/2 est incomplète ou si leur certificat injecté n’est pas approuvé par le magasin de certificats de Chrome, la session HTTP/2 échouera avec exactement cette erreur. Désactiver uniquement le composant de scan HTTPS — pas l’antivirus entier — est le correctif ciblé correct.

Comment savoir si le problème vient de mon côté ou du côté du serveur ?

Exécutez curl -v --http2 https://your-domain.com depuis la ligne de commande. Si curl échoue également à négocier HTTP/2, le serveur est mal configuré. Si curl réussit mais que Chrome échoue, le problème est local — soit une session Chrome obsolète, une extension, soit un outil de sécurité intercepteur.

Cette erreur affecte-t-elle le SEO ou les performances du site web ?

Pour les utilisateurs finaux, oui — l’erreur empêche complètement le chargement de la page. Pour les propriétaires de sites, une ERR_SPDY_PROTOCOL_ERROR persistante causée par une mauvaise configuration HTTP/2 côté serveur ou un certificat expiré entraînera des échecs de tentatives d’exploration par Googlebot, ce qui peut avoir un impact négatif sur la couverture d’exploration et l’indexation. S’assurer que votre certificat SSL est valide et que votre configuration HTTP/2 est correcte est une exigence SEO technique de base.