ERR_CONNECTION_RESET sur un seul site

Tous les autres sites se chargent, mais un seul échoue sans cesse avec « Ce site est inaccessible » et ERR_CONNECTION_RESET. Recharger ne change rien. Ce guide est un arbre de décision. Chaque étape trouve la cause ou en écarte une, et l’ordre va des vérifications les plus rapides à la plus révélatrice.

Ce que signifie vraiment « connexion réinitialisée »

Une connexion TCP peut se terminer poliment, ou être coupée net par un paquet de réinitialisation (RST). Chrome et les autres navigateurs Chromium affichent ERR_CONNECTION_RESET quand une réinitialisation arrive avant que la page soit livrée. Firefox affiche une page similaire, « La connexion a été réinitialisée ». La réinitialisation peut venir du serveur du site, d’un logiciel sur votre propre ordinateur, ou d’un équipement au milieu du réseau qui se fait passer pour l’une des deux extrémités.

C’est pourquoi la même erreur a des causes si différentes. L’astuce consiste à découvrir qui a envoyé la réinitialisation et quand.

Étape 1 : est-ce vraiment un seul site ?

Ouvrez deux ou trois sites sans rapport entre eux, dont un que vous visitez rarement. Si plusieurs échouent, le problème vient de votre connexion, de votre box ou de votre appareil, pas de ce site. Redémarrez la box et vérifiez si les autres appareils du même réseau fonctionnent. Si un seul site échoue, continuez.

Étape 2 : est-ce un seul réseau ?

C’est le test le plus parlant, et il est gratuit. Ouvrez le site en données mobiles au lieu du Wi-Fi, ou partagez la connexion de votre téléphone avec votre ordinateur portable. Si le site s’ouvre sur un réseau et se réinitialise sur l’autre, le réseau en échec est en cause. Les causes habituelles sont traitées dans Pourquoi un site s’ouvre-t-il en données mobiles mais pas en Wi-Fi ? S’il échoue partout, le site lui-même ou votre appareil est la cause la plus probable.

Étape 3 : autre navigateur, fenêtre privée, sans extensions

Essayez une fenêtre privée ou de navigation privée, où la plupart des extensions sont désactivées par défaut. Puis essayez un autre navigateur. Les bloqueurs de publicité, les extensions de confidentialité, les modules de « navigation sécurisée » et les règles de navigateur imposées par une entreprise peuvent tous fermer des connexions. Si le site marche dans une fenêtre privée, réactivez vos extensions une par une jusqu’à ce que l’erreur revienne.

Étape 4 : désactiver les autres VPN, proxys et l’analyse HTTPS

Tout ce qui se trouve sur le chemin de votre trafic peut réinitialiser une connexion qui lui déplaît :

• Une autre appli VPN ou proxy. Désactivez-la complètement et testez à nouveau.
• L’« analyse HTTPS » ou la « protection web » de l’antivirus. Certaines suites de sécurité inspectent le trafic chiffré et coupent les connexions qu’elles jugent risquées. Mettez cette fonction en pause un instant pour tester, puis réactivez-la.
• Le proxy système. Sous Windows, regardez dans Paramètres → Réseau et Internet → Proxy. Sous macOS, regardez dans Réglages Système → Réseau → votre connexion → Détails → Proxys. Un proxy que vous ne reconnaissez pas, ou un reste d’une ancienne appli, peut casser certains sites. Ne supprimez que ce que vous savez avoir configuré vous-même, et demandez à votre service informatique sur un ordinateur géré.

Étape 5 : vider le cache DNS et essayer le DNS chiffré

Si le site a changé de serveurs, votre appareil utilise peut-être encore l’ancienne adresse, ce qui peut provoquer une réinitialisation ou un délai dépassé. Videz les caches :

# Windows (Command Prompt)
ipconfig /flushdns

# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# Chrome's own cache: open chrome://net-internals/#dns and click "Clear host cache"

Ensuite, comparez la réponse de votre réseau avec celle d’un résolveur indépendant : nslookup example.com puis nslookup example.com 1.1.1.1. Si elles diffèrent et que seule la réponse indépendante fonctionne, le problème vient du DNS de votre réseau. Le DNS chiffré règle ce type de blocage, comme expliqué dans DoH et DoT. Des adresses différentes ne prouvent rien à elles seules, car les grands sites attribuent des serveurs différents selon les réseaux.

Étape 6 : vérifier la date et l’heure

Une horloge fausse provoque en général une erreur de certificat plutôt qu’une réinitialisation, mais la vérification prend dix secondes. Activez la date et l’heure automatiques, puis rechargez. Ne cliquez jamais pour ignorer un avertissement de certificat afin de « passer » une page en échec.

Étape 7 : le site est-il en panne ?

Consultez la page d’état du site ou son compte officiel sur les réseaux sociaux, ou utilisez un service public du type « en panne pour tout le monde ou seulement pour moi ». Si le site est en panne, attendez. Gardez en tête qu’un tel service teste depuis ses propres serveurs, et qu’un résultat « en ligne » ne prouve pas que le site est joignable depuis votre réseau.

Étape 8 : lire la réinitialisation avec curl

Si le site se réinitialise toujours sur un seul réseau, examinez la négociation elle-même. curl est intégré à Windows 10 et 11, à macOS et à la plupart des systèmes Linux. Lancez-le dans un terminal en remplaçant example.com par votre site :

curl -v https://example.com

Une connexion saine affiche quelques lignes comme celles-ci, puis les en-têtes de la page. La formulation exacte dépend de votre version de curl et de la bibliothèque TLS :

*   Trying 203.0.113.10:443...
* Connected to example.com (203.0.113.10) port 443
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
...
< HTTP/2 200

Le schéma qui indique un filtrage par nom ressemble à ceci :

*   Trying 203.0.113.10:443...
* Connected to example.com (203.0.113.10) port 443
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* Recv failure: Connection reset by peer
curl: (35) Recv failure: Connection reset by peer

Lisez-le ligne par ligne. « Connected » signifie que la connexion TCP à l’adresse IP du serveur a fonctionné, l’adresse n’est donc pas bloquée purement et simplement. « Client hello » est le premier message TLS, et il transporte le nom du site en clair dans un champ appelé SNI. « Connection reset by peer » juste après signifie que quelque chose a coupé la connexion dès que ce nom était visible, avant que le serveur puisse répondre. Certains réseaux ferment plutôt la connexion en silence, ce que curl signale comme une fin de fichier inattendue ou une erreur SSL « syscall », et Chrome peut afficher ERR_CONNECTION_CLOSED.

Comparez avec les autres résultats possibles :

Pour renforcer le diagnostic, lancez la même commande sur un autre réseau. Si elle y fonctionne, le filtre appartient au premier réseau. Ce n’est pas une hypothèse sur un cas rare. Une étude de 2020 de l’OONI et du Centre for Internet and Society a constaté des connexions TLS coupées juste après le ClientHello pour certains sites chez Bharti Airtel, et un filtrage combinant le SNI et l’adresse de destination chez Reliance Jio. Le CIS a aussi signalé séparément que Jio utilisait l’inspection du SNI, et ce rapport a été discuté sur le forum ntc.party. Pour aller plus loin : Comment vérifier si un site est bloqué.

Où GreenTunnel aide, et où il n’aide pas

GreenTunnel est un VPN local qui tourne sur l’appareil, et c’est nous qui le développons. Lisez donc cette partie en sachant que nous ne sommes pas neutres. Il vise deux des causes ci-dessus :

• Le filtrage SNI. Il remodèle les premiers paquets TLS d’une connexion, par exemple en découpant le Client hello ou son enregistrement TLS, si bien qu’un filtre qui cherche un nom de site ne le trouve pas d’un seul tenant. Fonctionnement : SNI, DPI et découpage des enregistrements TLS.
• Le blocage DNS. Les requêtes passent par un DNS chiffré (DoH ou DoT) vers Cloudflare, Google ou Quad9, et le réseau ne peut pas renvoyer discrètement une fausse réponse.

Son outil Inspect URL effectue les comparaisons des étapes 5 et 8 pour un site, sur le réseau où vous êtes, et indique si le site est filtré par nom, reçoit une fausse réponse DNS, est bloqué par adresse IP, ou fonctionne. Si une technique marche, vous pouvez toucher Use this technique.

Il n’aidera pas dans ces cas :

• le site est en panne, ou la réinitialisation vient du serveur du site lui-même ou de son service de protection,
• le blocage se fait par adresse IP, ce qui se traduit par un délai dépassé sur « Trying »,
• une entreprise, une école ou un autre réseau géré bloque le site volontairement. Les règles de ce réseau relèvent de son propriétaire. Respectez la politique en place et demandez à l’administrateur si vous avez besoin d’un accès pour votre travail,
• la cause est une extension, un antivirus ou un DNS périmé sur votre propre appareil. Corrigez-les directement.

Limites honnêtes et usage responsable

GreenTunnel ne masque pas votre adresse IP et n’est pas un outil d’anonymat. Il ne peut pas contourner les blocages par IP, les coupures de réseau ni les listes blanches, et il ne promet d’ouvrir aucun site en particulier. Les filtres évoluent et diffèrent d’un FAI à l’autre, un résultat obtenu aujourd’hui peut donc changer le mois prochain.

Questions fréquentes

ERR_CONNECTION_RESET signifie-t-il toujours qu’un site est bloqué ?

Non. Les extensions, l’analyse HTTPS d’un antivirus, un proxy oublié, un DNS périmé ou le site lui-même peuvent tous la provoquer. Le blocage devient probable seulement quand la réinitialisation se produit sur un seul réseau, juste après le Client hello, et que le site fonctionne ailleurs.

Pourquoi le site marche-t-il en données mobiles mais se réinitialise-t-il en Wi-Fi ?

Les deux réseaux utilisent des fournisseurs, des résolveurs et des filtres différents. L’un d’eux lit peut-être le nom du site ou répond différemment au DNS. Lancez curl -v sur les deux et comparez où chacun s’arrête.

Effacer les cookies règle-t-il une réinitialisation de connexion ?

Rarement. Les cookies sont envoyés une fois la connexion établie, alors que la plupart des réinitialisations ont lieu avant. Effacer les données du site peut aider quand le site lui-même rejette une session invalide, ce qui affiche plutôt une erreur HTTP.

GreenTunnel peut-il régler une réinitialisation causée par le pare-feu de mon entreprise ?

Ce n’est pas son rôle. Un réseau géré bloque des sites selon la politique de son propriétaire. Adressez-vous à l’administrateur au lieu d’essayer de le contourner.

Sources

• OONI et Centre for Internet and Society, Investigating TLS blocking in India, juillet 2020.
• Centre for Internet and Society, Reliance Jio is using SNI inspection to block websites.
• Forum ntc.party, SNI filtering by Indian ISP Reliance Jio.
• Projet curl, manuel de curl (l’option -v).