ERR_CONNECTION_RESET: Ursachen und Lösungen

2026-09-19

ERR_CONNECTION_RESET bedeutet, eine funktionierende Verbindung wurde mitten im Verlauf abrupt abgebrochen, meist durch eine Firewall, Sicherheitssoftware, oder einen serverseitigen Absturz, statt dass eine der beiden Seiten sie normal geschlossen hätte.

Was ERR_CONNECTION_RESET bedeutet

Anders als ERR_CONNECTION_REFUSED, das auftritt, bevor überhaupt Daten fließen, passiert ein Reset, nachdem der TCP-Handshake gelungen ist und die Verbindung bereits Daten austauschte. Etwas entlang des Pfads, oder einer der Endpunkte selbst, sendet dann ein RST-Paket, das die Verbindung ohne die übliche Schließsequenz beendet. Der Browser hat keine Möglichkeit zu erkennen, ob das RST vom Server kam, von einer Middlebox wie einer Firewall oder einem Load Balancer, oder vom eigenen Netzwerk-Stack des Clients, die Meldung bleibt also unabhängig von der Ursache generisch.

Ein normales TCP-Schließen umfasst einen FIN-Austausch in beide Richtungen, was jeder Seite erlaubt, das zu Ende zu bringen, was sie bereits in der Warteschlange hatte. Ein RST überspringt das vollständig: Was gerade unterwegs war, wird verworfen, und alle Daten, die der Server bereits zu schreiben begonnen hatte, die der Client aber noch nicht empfangen hatte, gehen verloren. Deshalb hinterlässt ein Reset mitten in einem großen Datei-Download oder einer langen API-Antwort oft ein sichtbar abgeschnittenes Ergebnis statt eines sauberen Fehlschlags, bevor irgendetwas geladen wurde.

Wie sich der Fehler zeigt

Chrome zeigt "This site can't be reached ... ERR_CONNECTION_RESET" mitten im Laden, manchmal nachdem ein Teil der Seite bereits gerendert wurde. curl meldet es direkt:

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

Auf der Serverseite protokolliert nginx eine passende Zeile für dasselbe Ereignis: readv() failed (104: Connection reset by peer) while reading upstream. Ein Reset, der konsequent bei derselben Byte-Anzahl oder derselben Anzahl Sekunden in eine Anfrage auftritt, deutet auf ein Größen- oder Timeout-Limit irgendwo auf dem Pfad hin, statt auf einen zufälligen Netzwerkstörer.

Was ERR_CONNECTION_RESET verursacht

Eine Firewall, ein IDS oder eine WAF verwirft die Verbindung mitten im Datenstrom. Eine Regel, die mitten in einer Anfrage oder Antwort greift, statt zum Verbindungszeitpunkt, erzeugt ein Reset statt einer sofortigen Ablehnung.
MTU- oder Paketfragmentierungsprobleme. Ein Pfad mit einer kleineren MTU, als beide Endpunkte erwarten, kann große Pakete beschädigen, und manche falsch konfigurierten Router reagieren darauf, indem sie die Verbindung zurücksetzen, statt korrekt zu fragmentieren.
TLS-Inspektion durch Antivirensoftware oder einen Unternehmens-Proxy. Ein Abfangen, das mitten in einem Handshake oder einer Antwort scheitert, setzt die Verbindung oft zurück, statt elegant zu scheitern.
Ein Server-Worker-Prozess stürzt mitten in der Anfrage ab. Ein Anwendungsfehler, ein Out-of-Memory-Kill, oder ein Worker-Neustart während eines Deploys hinterlassen alle eine offene Verbindung, die niemand mehr beantwortet.
Eine Keep-Alive-Timeout-Fehlpassung zwischen Client und Server oder Proxy. Ist das Idle-Timeout eines Load Balancers kürzer als das des Backends, kann er eine Verbindung zurücksetzen, die das Backend noch für aktiv hält.
Eingriffe des Internetanbieters oder Traffic-Shaping. Manche Internetanbieter setzen lang laufende oder bandbreitenintensive Verbindungen zurück, besonders bei Streaming oder großen Downloads, als eine Form des Traffic-Managements.

So finden Sie heraus, wer schuld ist

Testen Sie dieselbe Anfrage von einem zweiten Netzwerk aus, etwa mobilen Daten statt Büro-WLAN. Funktioniert es dort, fängt eine lokale Firewall, ein Antivirenprogramm oder ein Proxy die Verbindung ab. Passiert das Reset überall gleich, sitzt die Ursache serverseitig oder in einer WAF-Regel davor. Eine HTTP-Prüfung von mehreren Standorten gleichzeitig zeigt, ob das Reset überall oder nur in einem Netzwerk auftritt, ohne dass Sie ein zweites Gerät zum Testen brauchen.

So beheben Sie ERR_CONNECTION_RESET

Wenn Sie Besucher sind

Starten Sie Ihren Router oder Ihr Modem neu. Ein hängender NAT-Tabelleneintrag oder ein veralteter Verbindungszustand auf Consumer-Routern ist eine häufige, leicht zu behebende Ursache.
Deaktivieren Sie jedes VPN oder jeden Proxy und laden Sie neu. Stoppt das Reset, fängt das VPN oder der Proxy die Verbindung ab oder behandelt sie falsch.
Schalten Sie das HTTPS-Scanning in Ihrem Antivirenprogramm aus, meist unter "Webschutz" oder "SSL/TLS-Scanning" aufgeführt, und versuchen Sie es erneut. Behebt das den Fehler, fügen Sie die Website zu einer Ausnahmeliste hinzu, statt das Scanning ganz auszuschalten.
Prüfen Sie auf eine ungewöhnlich niedrige MTU-Einstellung, falls Sie ein VPN oder einen mobilen Hotspot nutzen; sie clientseitig leicht zu senken kann Resets beheben, die mit Fragmentierung zusammenhängen.

Wenn Sie die Website betreiben

Prüfen Sie Anwendungs- und Systemlogs auf einen Absturz oder einen Out-of-Memory-Kill um den Zeitpunkt des Resets. Ein mitten in der Anfrage sterbender Worker-Prozess ist eine der häufigsten Ursachen.
Prüfen Sie WAF- und IDS-Regeln und deren Logs. Eine Regel, die Verbindungen zurücksetzt, die bestimmten Payloads oder Raten entsprechen, kann identisch zu einem zufälligen Netzwerkfehler aussehen, bis Sie gezielt das Sicherheitslog prüfen.
Gleichen Sie Keep-Alive-Timeouts über den ganzen Stack ab. Setzen Sie bei nginx das proxy-seitige Timeout auf mindestens den Wert des Backends selbst:
```
keepalive_timeout 65s;
proxy_read_timeout 65s;
```
Eine Fehlpassung hier ist eine häufige Ursache für Resets unter Last, wenn das Frontend eine Verbindung schließt, die das Backend noch nutzen will.
Achten Sie auf Upstream-Reset-Meldungen im Reverse-Proxy-Log, etwa upstream prematurely closed connection while reading response header from upstream, was direkt auf die Backend-Anwendung hindeutet, nicht auf das Netzwerk.
Laden Sie nach jeder Änderung neu, statt live zu bearbeiten: nginx -t && systemctl reload nginx validiert die Konfiguration, bevor sie wirksam wird.

So beugen Sie ERR_CONNECTION_RESET vor

Ein Reset, das nur unter Last oder nur bei großen Antworten auftritt, zeigt sich bei einer schnellen manuellen Prüfung selten, da es von Timing- oder Größenschwellen abhängt, die eine einzelne Anfrage womöglich nicht erreicht. Laufendes HTTP-Monitoring, das Statuscode und Body-Inhalt planmäßig von über 300 Prüfpunkten in 158 Städten prüft, erkennt ein unregelmäßiges Reset-Muster, das ein einmaliger Test verpassen würde, und alarmiert per E-Mail, SMS, Sprachanruf, Slack, Telegram und mehr, sobald es beginnt.

Häufig gestellte Fragen

Bedeutet ERR_CONNECTION_RESET, dass ich gehackt wurde?

Nein. Es deutet fast immer auf ein Netzwerkgerät, eine Firewall-Regel, Antiviren-Abfangen, oder einen serverseitigen Absturz hin, nicht auf einen Angriff auf Ihr Gerät.

Warum passiert das nur bei großen Datei-Downloads?

Große Übertragungen treffen wahrscheinlicher auf eine MTU-Fehlpassung, ein Proxy-Timeout, oder ein an einer Firewall oder einem Load Balancer konfiguriertes Größenlimit, die alle eine Verbindung mitten im Datenstrom beenden können, die eine kleine Anfrage beenden würde, bevor sie das auslöst.

Kann mein eigenes Antivirenprogramm das verursachen?

Ja. HTTPS-Scanning-Funktionen, die TLS-Traffic abfangen und neu verschlüsseln, scheitern manchmal an bestimmten Websites oder großen Antworten und setzen die Verbindung zurück, statt sie durchzulassen.

Ist ein Reset schlimmer als eine Zeitüberschreitung?

Nicht von Natur aus. Ein Reset bedeutet, etwas hat die Verbindung aktiv beendet, was oft leichter zu diagnostizieren ist als eine Zeitüberschreitung, bei der nichts passiert und Sie nicht sagen können, ob das Paket überhaupt angekommen ist.

Warum passiert das Reset jedes Mal an derselben Stelle?

Eine gleichbleibende Byte-Anzahl oder verstrichene Zeit vor dem Reset deutet meist auf ein festes Limit hin, etwa ein Proxy-Timeout, eine maximale Antwortgröße, oder eine Keep-Alive-Einstellung, statt auf einen zufälligen Fehler.

Kann ein Mobilfunkanbieter meine Verbindungen zurücksetzen?

Manche Anbieter setzen lang laufende Verbindungen im Rahmen des Netzwerkmanagements tatsächlich zurück, besonders auf überlasteten Zellen oder bei bandbreitenintensiven Übertragungen wie Video-Streaming. Funktioniert dieselbe Anfrage über WLAN zuverlässig, wird aber bei mobilen Daten zurückgesetzt, ist ein Eingriff auf Anbieterebene eine plausible Erklärung.