ERR_CONNECTION_RESET: oorzaken en oplossingen

Wat ERR_CONNECTION_RESET betekent

Anders dan ERR_CONNECTION_REFUSED, dat optreedt voordat er ook maar data beweegt, gebeurt een reset nadat de TCP-handshake lukte en de verbinding al data uitwisselde. Iets onderweg, of een van de eindpunten zelf, stuurt dan een RST-pakket dat de verbinding beëindigt zonder de gebruikelijke afsluitsequentie. De browser kan niet zien of de RST van de server kwam, van een tussenliggend apparaat zoals een firewall of loadbalancer, of van de eigen netwerkstack van de client, dus blijft de melding generiek ongeacht de oorzaak.

Een normale TCP-afsluiting bestaat uit een FIN-uitwisseling in beide richtingen, waardoor elke kant kan afronden wat al in de wachtrij stond. Een RST slaat dat helemaal over: wat onderweg was wordt weggegooid, en elke data die de server al begon te schrijven maar de client nog niet ontvangen had gaat verloren. Dat is waarom een reset halverwege een grote bestandsdownload of een lang API-antwoord vaak een zichtbaar afgekapt resultaat achterlaat in plaats van een nette storing voordat er iets laadde.

Hoe de fout verschijnt

Chrome toont "This site can't be reached ... ERR_CONNECTION_RESET" halverwege het laden, soms nadat een deel van de pagina al is weergegeven. curl rapporteert het rechtstreeks:

curl -v https://example.com/api/report
* TLSv1.2 (IN), TLS alert, close notify
* OpenSSL SSL_read: Connection reset by peer, errno 104
curl: (56) Recv failure: Connection reset by peer

Aan de serverkant logt nginx een overeenkomende regel voor dezelfde gebeurtenis: readv() failed (104: Connection reset by peer) while reading upstream. Een reset die consequent optreedt bij hetzelfde aantal bytes of dezelfde tijdsduur in een verzoek wijst op een limiet voor grootte of timeout ergens op het pad, niet op een willekeurige netwerkhapering.

Wat ERR_CONNECTION_RESET veroorzaakt

• Een firewall, IDS, of WAF verbreekt de verbinding halverwege de stream. Een regel die halverwege een verzoek of antwoord matcht, in plaats van bij het opzetten van de verbinding, levert een reset op in plaats van een directe weigering.
• MTU- of pakketfragmentatieproblemen. Een pad met een kleinere MTU dan een van beide eindpunten verwacht kan grote pakketten beschadigen, en sommige verkeerd geconfigureerde routers reageren daarop door de verbinding te resetten in plaats van correct te fragmenteren.
• TLS-inspectie door antivirussoftware of een bedrijfsproxy. Onderschepping die halverwege een handshake of een antwoord faalt, reset de verbinding vaak in plaats van netjes te falen.
• Een workerproces van de server crasht midden in een verzoek. Een applicatiefout, een out-of-memory kill, of een workerherstart tijdens een deployment laten allemaal een open verbinding achter zonder iets over om hem te beantwoorden.
• Een mismatch in keep-alive-timeout tussen client en server of proxy. Is de idle-timeout van een loadbalancer korter dan die van de backend, dan kan hij een verbinding resetten die de backend nog steeds als actief beschouwt.
• Interferentie of traffic shaping door de provider. Sommige internetproviders resetten langdurige of hoge-bandbreedteverbindingen, met name voor streaming of grote downloads, als een vorm van verkeersbeheer.

Hoe u vaststelt wiens fout het is

Test hetzelfde verzoek vanaf een tweede netwerk, zoals mobiele data in plaats van het wifi op kantoor. Werkt het daar wel, dan onderschept een lokale firewall, antivirus, of proxy de verbinding. Treedt de reset overal identiek op, dan ligt de oorzaak aan de serverkant of bij een WAF-regel ervoor. Een HTTP-controle vanaf meerdere locaties tegelijk laat zien of de reset overal optreedt of beperkt is tot één netwerk, zonder dat u een tweede apparaat nodig heeft om mee te testen.

Hoe u ERR_CONNECTION_RESET oplost

Bent u de bezoeker

1. Herstart uw router of modem. Een vastgelopen NAT-tabelitem of een verouderde verbindingsstatus op consumentenrouters is een veelvoorkomende, makkelijk te wissen oorzaak.
2. Schakel elke VPN of proxy uit en laad opnieuw. Stopt de reset dan, dan onderschept of misbehandelt de VPN of proxy de verbinding.
3. Zet HTTPS-scanning uit in uw antivirus, meestal te vinden onder "webbescherming" of "SSL/TLS-scanning," en probeer opnieuw. Lost dat het op, voeg de site dan toe aan een uitzonderingslijst in plaats van scanning uit te laten staan.
4. Controleer op een ongewoon lage MTU-instelling als u een VPN of mobiele hotspot gebruikt; hem iets verlagen aan de kant van de client kan resets oplossen die met fragmentatie te maken hebben.

Beheert u de site

1. Controleer applicatie- en systeemlogs op een crash of een out-of-memory kill rond het moment van de reset. Een workerproces dat midden in een verzoek sterft is een van de meest voorkomende oorzaken.
2. Bekijk WAF- en IDS-regels en hun logs. Een regel die verbindingen reset bij bepaalde payloads of snelheden kan identiek lijken aan een willekeurige netwerkstoring totdat u specifiek het beveiligingslog controleert.
3. Stem keep-alive-timeouts op elkaar af in de hele stack. Zet op nginx de proxy-gerichte timeout gelijk aan of hoger dan die van de backend zelf:

   keepalive_timeout 65s;
   proxy_read_timeout 65s;

   Een mismatch hier is een veelvoorkomende oorzaak van resets onder belasting, wanneer de frontend een verbinding sluit die de backend nog verwacht te gebruiken.
4. Let op upstream-resetmeldingen in het reverse-proxylog, zoals upstream prematurely closed connection while reading response header from upstream, wat rechtstreeks naar de backend-applicatie wijst in plaats van naar het netwerk.
5. Herlaad na elke wijziging in plaats van live te bewerken: nginx -t && systemctl reload nginx valideert de configuratie voordat hij van kracht wordt.

Hoe u ERR_CONNECTION_RESET voorkomt

Een reset die alleen onder belasting verschijnt, of alleen bij grote antwoorden, komt zelden naar voren bij een snelle handmatige controle, aangezien hij afhangt van timing- of groottedrempels die één verzoek mogelijk niet raakt. Doorlopende HTTP-monitoring die de statuscode en body-inhoud volgens schema controleert vanaf 300+ meetpunten in 158 steden vangt een af en toe optredend resetpatroon dat een eenmalige test zou missen, en waarschuwt via e-mail, sms, spraakoproep, Slack, Telegram en meer zodra het begint.

Gerelateerde fouten

• ERR_CONNECTION_REFUSED gebeurt wanneer de verbinding nooit tot stand komt.
• ERR_CONNECTION_TIMED_OUT gebeurt wanneer helemaal niets antwoordt op de verbindingspoging.
• This site can't be reached behandelt de volledige verzameling verbindingsfouten die Chrome onder één kop groepeert.

Veelgestelde vragen

Betekent ERR_CONNECTION_RESET dat ik gehackt ben?

Nee. Het wijst vrijwel altijd op een netwerkapparaat, een firewallregel, antivirusonderschepping, of een crash aan de serverkant, niet op een aanval op uw apparaat.

Waarom gebeurt dit alleen bij grote bestandsdownloads?

Grote overdrachten lopen vaker tegen een MTU-mismatch, een proxytimeout, of een groottelimiet ingesteld op een firewall of loadbalancer aan, wat allemaal een verbinding halverwege kan beëindigen die een klein verzoek zou afronden voordat het wordt geraakt.

Kan mijn eigen antivirus dit veroorzaken?

Ja. HTTPS-scanfuncties die TLS-verkeer onderscheppen en opnieuw versleutelen falen soms bij specifieke sites of grote antwoorden en resetten de verbinding in plaats van hem door te laten.

Is een reset erger dan een timeout?

Niet per se. Een reset betekent dat iets de verbinding actief beëindigde, wat vaak makkelijker te diagnosticeren is dan een timeout, waarbij niets gebeurt en u niet kunt zien of het pakket ooit aankwam.

Waarom gebeurt de reset elke keer op hetzelfde punt?

Een consistent aantal bytes of verstreken tijd voor de reset wijst meestal op een vaste limiet, zoals een proxytimeout, een maximale antwoordgrootte, of een keep-alive-instelling, in plaats van op een willekeurige storing.

Kan een mobiele provider mijn verbindingen resetten?

Sommige providers resetten inderdaad langdurige verbindingen als onderdeel van netwerkbeheer, met name op overbelaste zendmasten of bij overdrachten met hoge bandbreedte zoals videostreaming. Werkt hetzelfde verzoek betrouwbaar via wifi maar reset het op mobiele data, dan is interferentie op providerniveau een redelijke verklaring.