ERR_CONNECTION_RESET: příčiny a opravy

2026-09-19

ERR_CONNECTION_RESET znamená, že spojení, které fungovalo, se uprostřed náhle přerušilo, obvykle kvůli firewallu, bezpečnostnímu softwaru nebo pádu na straně serveru, ne proto, že by ho některá strana normálně uzavřela.

Co znamená ERR_CONNECTION_RESET

Na rozdíl od ERR_CONNECTION_REFUSED, které nastane dřív, než se přenesou jakákoli data, reset nastává poté, co se TCP handshake povedl a spojení už si vyměňovalo data. Něco na cestě, nebo jeden z koncových bodů samotný, pak pošle paket RST, který spojení ukončí bez obvyklé uzavírací sekvence. Prohlížeč nemá způsob, jak zjistit, jestli RST přišel od serveru, mezilehlého zařízení jako firewall nebo load balancer, nebo z vlastního síťového stacku klienta, takže zpráva zůstává obecná bez ohledu na příčinu.

Normální uzavření TCP zahrnuje výměnu FIN oběma směry, což umožní každé straně dokončit odeslání toho, co už měla ve frontě. RST tohle celé přeskočí: cokoli bylo na cestě, se zahodí, a jakákoli data, která server už začal psát, ale klient je ještě nedostal, se ztratí. Proto reset uprostřed stahování velkého souboru nebo dlouhé odpovědi API často zanechá viditelně useknutý výsledek místo čistého selhání dřív, než se cokoli načetlo.

Jak se chyba projevuje

Chrome zobrazí "This site can't be reached ... ERR_CONNECTION_RESET" uprostřed načítání, někdy až poté, co se část stránky už vykreslila. curl to hlásí přímo:

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

Na straně serveru zaznamená nginx pro stejnou událost odpovídající řádek: readv() failed (104: Connection reset by peer) while reading upstream. Reset, který nastává důsledně na stejném počtu bajtů nebo po stejném počtu vteřin od začátku požadavku, ukazuje na pevný limit velikosti nebo timeoutu někde na cestě, ne na náhodnou síťovou chybu.

Co způsobuje ERR_CONNECTION_RESET

Firewall, IDS nebo WAF přeruší spojení uprostřed přenosu. Pravidlo, které zafunguje až uprostřed požadavku nebo odpovědi, ne v okamžiku spojení, vyprodukuje reset místo okamžitého odmítnutí.
Problémy s MTU nebo fragmentací paketů. Cesta s menším MTU, než jaké očekává některý koncový bod, může poškodit velké pakety, a některé špatně nastavené routery na to reagují resetováním spojení místo správné fragmentace.
Kontrola TLS antivirovým softwarem nebo firemní proxy. Zachytávání, které selže uprostřed handshake nebo odpovědi, spojení často resetuje, místo aby elegantně selhalo.
Worker proces serveru uprostřed požadavku spadne. Chyba aplikace, zabití kvůli nedostatku paměti, nebo restart workeru během nasazení, to všechno nechá otevřené spojení bez toho, co by na něj odpovědělo.
Nesoulad timeoutu keep-alive mezi klientem a serverem nebo proxy. Pokud je timeout nečinnosti load balanceru kratší než u backendu, může resetovat spojení, které backend pořád považuje za aktivní.
Zásah poskytovatele internetu nebo tvarování provozu. Někteří poskytovatelé internetu resetují dlouho trvající nebo vysoce vytěžující spojení, zvlášť u streamování nebo velkých stahování, jako formu řízení provozu.

Jak zjistit, čí je to chyba

Otestujte stejný požadavek z druhé sítě, například z mobilních dat místo firemní Wi-Fi. Pokud tam funguje, spojení zachytává lokální firewall, antivirus nebo proxy. Pokud reset nastává identicky všude, příčina sedí na straně serveru nebo v pravidle WAF před ním. HTTP kontrola spuštěná z více míst najednou ukáže, jestli je reset univerzální, nebo omezený na jednu síť, aniž byste k testování potřebovali druhé zařízení.

Jak opravit ERR_CONNECTION_RESET

Pokud jste návštěvník

Restartujte router nebo modem. Zaseknutý záznam v tabulce NAT nebo zastaralý stav spojení na spotřebitelských routerech je běžná, snadno odstranitelná příčina.
Vypněte jakoukoli VPN nebo proxy a načtěte stránku znovu. Pokud reset přestane, VPN nebo proxy spojení zachytává nebo špatně zpracovává.
Vypněte skenování HTTPS ve svém antiviru, obvykle uvedené pod "web protection" nebo "SSL/TLS scanning", a zkuste to znovu. Pokud to pomůže, přidejte web na seznam výjimek, místo abyste skenování nechali vypnuté.
Zkontrolujte neobvykle nízké nastavení MTU, pokud jste na VPN nebo mobilním hotspotu; mírné snížení na straně klienta může vyřešit resety spojené s fragmentací.

Pokud web provozujete

Zkontrolujte logy aplikace a systému kvůli pádu nebo zabití pro nedostatek paměti v čase resetu. Worker proces umírající uprostřed požadavku je jedna z nejčastějších příčin.
Projděte pravidla WAF a IDS a jejich logy. Pravidlo, které resetuje spojení odpovídající určitým datům nebo četnosti, může vypadat úplně stejně jako náhodná síťová chyba, dokud se speciálně nepodíváte do bezpečnostního logu.
Sjednoťte timeouty keep-alive napříč celým stackem. Na nginx nastavte timeout směrem k proxy tak, aby odpovídal timeoutu backendu nebo ho přesahoval:
```
keepalive_timeout 65s;
proxy_read_timeout 65s;
```
Nesoulad tady je častou příčinou resetů pod zátěží, kdy frontend zavře spojení, které backend pořád očekává použít.
Sledujte zprávy o resetu upstreamu v logu reverzní proxy, jako je upstream prematurely closed connection while reading response header from upstream, což ukazuje přímo na backendovou aplikaci, ne na síť.
Po jakékoli změně ji restartujte, místo abyste upravovali za běhu: nginx -t && systemctl reload nginx ověří konfiguraci, než se projeví.

Jak předejít ERR_CONNECTION_RESET

Reset, který se objevuje jen pod zátěží, nebo jen u velkých odpovědí, se při rychlé ruční kontrole zřídka projeví, protože závisí na časových nebo velikostních prahových hodnotách, na které jeden požadavek nemusí narazit. Průběžný HTTP monitoring, který podle plánu z více než 300 kontrolních bodů ve 158 městech kontroluje stavový kód i obsah těla, zachytí přerušovaný vzor resetů, který jednorázový test přehlédne, a upozorní e-mailem, SMS, hlasovým hovorem, přes Slack, Telegram a další, jakmile začne.

Související chyby

ERR_CONNECTION_REFUSED nastane, když se spojení vůbec nepodaří navázat.
ERR_CONNECTION_TIMED_OUT nastane, když na pokus o spojení vůbec nic neodpoví.
This site can't be reached pokrývá celou sadu chyb spojení, které Chrome řadí pod jeden nadpis.

Často kladené otázky

Znamená ERR_CONNECTION_RESET, že jsem byl napaden?

Ne. Skoro vždy ukazuje na síťové zařízení, pravidlo firewallu, zachytávání antivirem nebo pád na straně serveru, ne na útok na vaše zařízení.

Proč se tohle stává jen u velkých stahování souborů?

Velké přenosy s větší pravděpodobností narazí na nesoulad MTU, timeout proxy nebo limit velikosti nastavený na firewallu nebo load balanceru, což všechno může ukončit spojení uprostřed přenosu, na což by malý požadavek narazit stihl, ještě než by se stihlo dokončit.

Může tohle způsobit můj vlastní antivirus?

Ano. Funkce skenování HTTPS, které zachytávají a znovu šifrují provoz TLS, u některých webů nebo velkých odpovědí někdy selžou a místo předání spojení ho resetují.

Je reset horší než timeout?

Ne nutně. Reset znamená, že něco spojení aktivně ukončilo, což se často diagnostikuje snáz než timeout, kde se nic neděje a nepoznáte, jestli paket vůbec dorazil.

Proč reset nastává pokaždé na stejném místě?

Konzistentní počet bajtů nebo uplynulý čas před resetem obvykle ukazuje na pevný limit, jako je timeout proxy, maximální velikost odpovědi nebo nastavení keep-alive, ne na náhodnou chybu.

Může mi spojení resetovat mobilní operátor?

Někteří operátoři skutečně resetují dlouho trvající spojení jako součást správy sítě, zvlášť u přetížených buněk nebo u přenosů náročných na šířku pásma jako video streamování. Pokud stejný požadavek spolehlivě funguje přes Wi-Fi, ale resetuje se na mobilních datech, zásah na úrovni operátora je rozumné vysvětlení.