ERR_CONNECTION_RESET bij maar één site

Elke andere site laadt, maar één site blijft falen met "Deze site is niet bereikbaar" en ERR_CONNECTION_RESET. Opnieuw laden helpt niet. Deze handleiding is een beslisboom. Elke stap vindt de oorzaak of sluit er een uit, en de volgorde loopt van de snelste controles naar de meest veelzeggende.

Wat "verbinding opnieuw ingesteld" eigenlijk betekent

Een TCP-verbinding kan netjes eindigen, of in één keer worden afgebroken met een resetpakket (RST). Chrome en andere Chromium-browsers tonen ERR_CONNECTION_RESET als er een reset binnenkomt voordat de pagina is afgeleverd. Firefox toont een vergelijkbare pagina "De verbinding werd geherinitialiseerd". De reset kan komen van de server van de site, van software op je eigen computer, of van een apparaat midden in het netwerk dat zich voordoet als een van de twee kanten.

Daarom heeft dezelfde fout zulke uiteenlopende oorzaken. De truc is uitzoeken wie de reset stuurde en wanneer.

Stap 1: is het echt maar één site?

Open twee of drie sites die niets met elkaar te maken hebben, waaronder een die je zelden bezoekt. Falen er meerdere, dan ligt het probleem bij je verbinding, router of apparaat, niet bij die ene site. Herstart de router en kijk of andere apparaten op hetzelfde netwerk werken. Faalt maar één site, ga dan verder.

Stap 2: is het maar één netwerk?

Dit is de test die het meest vertelt, en hij is gratis. Open de site via mobiele data in plaats van wifi, of verbind je laptop via de hotspot van je telefoon. Opent de site op het ene netwerk en krijg je een reset op het andere, dan speelt het falende netwerk een rol. De gebruikelijke oorzaken staan in Waarom opent een site wel via mobiele data maar niet via wifi? Faalt hij overal, dan is de site zelf of je apparaat de waarschijnlijkere oorzaak.

Stap 3: een andere browser, een privévenster, geen extensies

Probeer een privé- of incognitovenster, waarin de meeste extensies standaard uitstaan. Probeer daarna een andere browser. Adblockers, privacy-extensies, add-ons voor "veilig browsen" en browserbeleid van een bedrijf kunnen allemaal verbindingen sluiten. Werkt de site in een privévenster, zet je extensies dan één voor één weer aan tot de fout terugkomt.

Stap 4: zet andere VPN's, proxy's en HTTPS-scans uit

Alles wat in het pad van je verkeer zit, kan een verbinding resetten die het niet bevalt:

• Een andere VPN- of proxy-app. Zet die helemaal uit en test opnieuw.
• "HTTPS-scan" of "webbescherming" van je antivirus. Sommige beveiligingspakketten inspecteren versleuteld verkeer en verbreken verbindingen die ze riskant vinden. Pauzeer die functie even om te testen en zet hem daarna weer aan.
• De systeemproxy. Kijk op Windows in Instellingen → Netwerk en internet → Proxy. Kijk op macOS in Systeeminstellingen → Netwerk → je verbinding → Details → Proxy's. Een proxy die je niet herkent, of een overblijfsel van een oude app, kan losse sites breken. Verwijder alleen wat je zeker zelf hebt ingesteld, en vraag het je IT-afdeling op een beheerde computer.

Stap 5: wis de DNS-cache en probeer versleutelde DNS

Is de site naar andere servers verhuisd, dan gebruikt je apparaat misschien nog het oude adres, wat kan leiden tot een reset of een time-out. Leeg de 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"

Vergelijk daarna het antwoord van je netwerk met dat van een onafhankelijke resolver: nslookup example.com en dan nslookup example.com 1.1.1.1. Verschillen ze en werkt alleen het onafhankelijke antwoord, dan is de DNS van je netwerk het probleem. Versleutelde DNS lost dat soort blokkade op, zoals uitgelegd in DoH en DoT. Verschillende adressen alleen zijn geen bewijs, want grote sites geven verschillende netwerken verschillende servers.

Stap 6: controleer datum en tijd

Een verkeerde klok geeft meestal een certificaatfout in plaats van een reset, maar het is een controle van tien seconden. Zet automatische datum en tijd aan en laad opnieuw. Klik nooit door een certificaatwaarschuwing heen om "langs" een falende pagina te komen.

Stap 7: ligt de site eruit?

Kijk op de statuspagina of het officiële sociale account van de site, of gebruik een openbare checker die test of een site voor iedereen of alleen voor jou plat ligt. Ligt de site eruit, wacht dan. Houd er rekening mee dat zo'n checker vanaf zijn eigen servers test, dus "online" daar bewijst niet dat de site vanaf jouw netwerk bereikbaar is.

Stap 8: lees de reset met curl

Krijgt de site nog steeds alleen op één netwerk een reset, kijk dan naar de handshake zelf. curl zit ingebouwd in Windows 10 en 11, macOS en de meeste Linux-systemen. Voer het uit in een terminal, met jouw site in plaats van example.com:

curl -v https://example.com

Een gezonde verbinding toont een paar regels zoals deze, en daarna de headers van de pagina. De precieze formulering hangt af van je curl-versie en TLS-bibliotheek:

*   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

Het patroon dat wijst op filtering op naam ziet er zo uit:

*   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

Lees het regel voor regel. "Connected" betekent dat de TCP-verbinding met het IP-adres van de server werkte, dus het adres zelf is niet geblokkeerd. "Client hello" is het eerste TLS-bericht, en dat bevat de sitenaam als leesbare tekst in een veld dat SNI heet. "Connection reset by peer" direct daarna betekent dat iets de verbinding verbrak zodra die naam zichtbaar was, voordat de server kon antwoorden. Sommige netwerken sluiten de verbinding in plaats daarvan stil af. curl meldt dat als een onverwacht einde van het bestand of een SSL-"syscall"-fout, en Chrome kan ERR_CONNECTION_CLOSED tonen.

Vergelijk met andere uitkomsten:

Voer voor meer zekerheid dezelfde opdracht uit op een ander netwerk. Werkt het daar wel, dan hoort het filter bij het eerste netwerk. Dit is geen gok over een zeldzame situatie. Een studie uit 2020 van OONI en het Centre for Internet and Society vond TLS-verbindingen die direct na de ClientHello werden verbroken voor bepaalde sites bij Bharti Airtel, en SNI gecombineerd met het bestemmingsadres bij Reliance Jio. CIS meldde los daarvan dat Jio SNI-inspectie gebruikte, en die melding werd besproken op het forum ntc.party. Meer achtergrond: Controleren of een website geblokkeerd is.

Waar GreenTunnel helpt, en waar niet

GreenTunnel is een lokale VPN op je apparaat die wij maken, dus lees dit deel in het besef dat we niet neutraal zijn. Hij richt zich op twee van de oorzaken hierboven:

• SNI-filtering. Hij geeft de eerste TLS-pakketten van een verbinding een andere vorm, bijvoorbeeld door de Client hello of het TLS-record ervan te splitsen, zodat een filter dat naar een sitenaam zoekt die niet in één stuk vindt. Hoe het werkt: SNI, DPI en het splitsen van TLS-records.
• DNS-blokkering. Opzoekingen gaan via versleutelde DNS (DoH of DoT) naar Cloudflare, Google of Quad9, zodat het netwerk niet stilletjes een nep-antwoord kan teruggeven.

Zijn tool Inspect URL voert de vergelijkingen uit stap 5 en 8 uit voor één site op het netwerk waarop je zit, en zegt of de site op naam gefilterd wordt, een nep-DNS-antwoord krijgt, op IP-adres geblokkeerd wordt, of in orde is. Werkt een techniek, dan kun je op Use this technique tikken.

Hij helpt niet als:

• de site offline is, of de reset van de eigen server of beschermingsdienst van de site komt,
• de blokkade op IP-adres is, wat zich toont als een time-out bij "Trying",
• een werk-, school- of ander beheerd netwerk de site bewust blokkeert. De regels van dat netwerk zijn aan de eigenaar. Respecteer het beleid en vraag de beheerder als je toegang nodig hebt voor je werk,
• de oorzaak een extensie, antivirus of verouderde DNS op je eigen apparaat is. Los die direct op.

Eerlijke grenzen en verantwoord gebruik

GreenTunnel verbergt je IP-adres niet en is geen anonimiteitstool. Hij komt niet langs IP-blokkades, afgesloten netwerken of allowlists, en belooft niet dat een bepaalde site opengaat. Filters veranderen in de loop van de tijd en verschillen per provider, dus een resultaat van vandaag kan volgende maand anders zijn.

Veelgestelde vragen

Betekent ERR_CONNECTION_RESET altijd dat een site geblokkeerd is?

Nee. Extensies, HTTPS-scans van antivirus, een achtergebleven proxy, verouderde DNS of de site zelf kunnen het allemaal veroorzaken. Blokkering wordt pas waarschijnlijk als de reset op één netwerk gebeurt, direct na de Client hello, en de site elders wel werkt.

Waarom werkt de site via mobiele data maar krijg ik op wifi een reset?

De twee netwerken gebruiken verschillende providers, resolvers en filters. Een van hen leest misschien de sitenaam of beantwoordt DNS anders. Voer curl -v op beide uit en vergelijk waar elk stopt.

Lost cookies wissen een verbindingsreset op?

Zelden. Cookies worden verstuurd nadat de verbinding is opgezet, terwijl de meeste resets daarvoor gebeuren. Sitegegevens wissen kan helpen als de site zelf een slechte sessie weigert, maar dan zie je meestal een HTTP-fout.

Kan GreenTunnel een reset door de firewall van mijn bedrijf oplossen?

Daar is hij niet voor bedoeld. Een beheerd netwerk blokkeert sites volgens het beleid van de eigenaar. Vraag het de beheerder in plaats van te proberen eromheen te komen.

Bronnen

• OONI en Centre for Internet and Society, Investigating TLS blocking in India, juli 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.
• curl-project, curl-handleiding (de optie -v).