ERR_CONNECTION_RESET: przyczyny i naprawa

Co oznacza ERR_CONNECTION_RESET

W przeciwieństwie do ERR_CONNECTION_REFUSED, które pojawia się, zanim jakiekolwiek dane ruszą, reset zdarza się po udanym handshake'u TCP, gdy połączenie już wymieniało dane. Coś na trasie, albo jeden z punktów końcowych, wysyła wtedy pakiet RST, który kończy połączenie z pominięciem normalnej sekwencji zamknięcia. Przeglądarka nie ma sposobu, żeby stwierdzić, czy RST przyszedł od serwera, urządzenia pośredniczącego takiego jak zapora czy load balancer, czy z własnego stosu sieciowego klienta, więc komunikat pozostaje ogólny niezależnie od przyczyny.

Normalne zamknięcie TCP obejmuje wymianę FIN w obu kierunkach, co pozwala każdej stronie dokończyć wysyłanie tego, co już miała w kolejce. RST pomija to całkowicie: wszystko, co było w drodze, zostaje odrzucone, a dane, które serwer już zaczął zapisywać, ale klient jeszcze nie odebrał, są tracone. Dlatego reset w połowie dużego pobierania pliku albo długiej odpowiedzi API często zostawia widocznie ucięty wynik zamiast czystej awarii, zanim cokolwiek się załadowało.

Jak pojawia się błąd

Chrome pokazuje "This site can't be reached ... ERR_CONNECTION_RESET" w połowie wczytywania, czasem po tym, jak część strony już się wyrenderowała. curl zgłasza to wprost:

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

Po stronie serwera nginx loguje pasującą linię dla tego samego zdarzenia: readv() failed (104: Connection reset by peer) while reading upstream. Reset, który zdarza się konsekwentnie przy tej samej liczbie bajtów albo tej samej liczbie sekund w żądanie, wskazuje na limit rozmiaru albo czasu gdzieś na trasie, a nie na przypadkowy problem sieciowy.

Co powoduje ERR_CONNECTION_RESET

• Zapora, IDS albo WAF porzuca połączenie w trakcie strumienia. Reguła, która dopasowuje się w połowie żądania albo odpowiedzi, a nie w momencie połączenia, produkuje reset zamiast natychmiastowej odmowy.
• Problemy z MTU albo fragmentacją pakietów. Trasa z mniejszym MTU, niż oczekuje którykolwiek z punktów końcowych, może uszkodzić duże pakiety, a niektóre źle skonfigurowane routery odpowiadają na to resetowaniem połączenia zamiast poprawnej fragmentacji.
• Inspekcja TLS przez oprogramowanie antywirusowe albo firmowe proxy. Przechwytywanie, które zawodzi w połowie handshake'u albo odpowiedzi, często resetuje połączenie zamiast zawieść w sposób kontrolowany.
• Proces workera serwera zawiesza się w trakcie żądania. Błąd aplikacji, zabicie z powodu braku pamięci albo restart workera podczas wdrożenia zostawiają otwarte połączenie bez niczego, co mogłoby na nie odpowiedzieć.
• Niedopasowanie timeoutu keep-alive między klientem a serwerem albo proxy. Jeśli timeout bezczynności load balancera jest krótszy niż backendu, może zresetować połączenie, które backend wciąż uważa za aktywne.
• Ingerencja dostawcy internetu albo kształtowanie ruchu. Niektórzy dostawcy resetują długo trwające albo wysokoprzepustowe połączenia, zwłaszcza przy streamingu albo dużych pobraniach, jako formę zarządzania ruchem.

Jak rozpoznać, kto zawinił

Przetestuj to samo żądanie z drugiej sieci, na przykład danych mobilnych zamiast biurowego Wi-Fi. Jeśli tam działa, lokalna zapora, antywirus albo proxy przechwytuje połączenie. Jeśli reset zdarza się identycznie wszędzie, przyczyna leży po stronie serwera albo reguły WAF przed nim. Kontrola HTTP uruchomiona z wielu lokalizacji naraz pokazuje, czy reset jest powszechny, czy ograniczony do jednej sieci, bez potrzeby testowania z drugiego urządzenia.

Jak naprawić ERR_CONNECTION_RESET

Jeśli jesteś odwiedzającym

1. Zrestartuj router albo modem. Zawieszony wpis w tablicy NAT albo nieaktualny stan połączenia w routerach konsumenckich to częsta, łatwa do usunięcia przyczyna.
2. Wyłącz dowolny VPN albo proxy i przeładuj. Jeśli reset ustaje, VPN albo proxy przechwytuje albo źle obsługuje połączenie.
3. Wyłącz skanowanie HTTPS w antywirusie, zwykle pod "ochrona sieci" albo "skanowanie SSL/TLS", i spróbuj ponownie. Jeśli to naprawia problem, dodaj witrynę do listy wyjątków, zamiast zostawiać skanowanie całkiem wyłączone.
4. Sprawdź nietypowo niskie ustawienie MTU, jeśli jesteś na VPN albo hotspocie mobilnym; lekkie obniżenie go po stronie klienta może rozwiązać resety związane z fragmentacją.

Jeśli prowadzisz witrynę

1. Sprawdź logi aplikacji i systemowe pod kątem awarii albo zabicia z powodu braku pamięci w czasie resetu. Umierający w połowie żądania proces workera to jedna z najczęstszych przyczyn.
2. Przejrzyj reguły WAF i IDS oraz ich logi. Reguła resetująca połączenia pasujące do określonych treści albo częstotliwości może wyglądać identycznie jak przypadkowa awaria sieci, dopóki nie sprawdzisz konkretnie logu bezpieczeństwa.
3. Zsynchronizuj timeouty keep-alive w całym stosie. Na nginx ustaw timeout od strony proxy tak, żeby pasował albo przekraczał własny timeout backendu:

   keepalive_timeout 65s;
   proxy_read_timeout 65s;

   Niedopasowanie w tym miejscu to częsta przyczyna resetów pod obciążeniem, gdy frontend zamyka połączenie, którego backend wciąż oczekuje użyć.
4. Obserwuj komunikaty o resecie upstreama w logu reverse proxy, takie jak upstream prematurely closed connection while reading response header from upstream, które wskazują wprost na aplikację backendową, a nie na sieć.
5. Przeładuj po każdej zmianie, zamiast edytować na żywo: nginx -t && systemctl reload nginx waliduje konfigurację, zanim zacznie obowiązywać.

Jak zapobiec ERR_CONNECTION_RESET

Reset, który pojawia się tylko pod obciążeniem albo tylko przy dużych odpowiedziach, rzadko ujawnia się przy szybkiej ręcznej kontroli, bo zależy od progów czasowych albo rozmiarowych, których pojedyncze żądanie może nie osiągnąć. Ciągłe monitorowanie HTTP, które sprawdza kod statusu i treść odpowiedzi według harmonogramu z ponad 300 punktów kontrolnych w 158 miastach, wyłapuje sporadyczny wzorzec resetów, który jednorazowy test by przeoczył, i alarmuje e-mailem, SMS-em, połączeniem głosowym, przez Slack, Telegram i inne kanały, gdy tylko się zacznie.

Powiązane błędy

• ERR_CONNECTION_REFUSED zdarza się, gdy połączenie w ogóle nie zostaje nawiązane.
• ERR_CONNECTION_TIMED_OUT zdarza się, gdy nic w ogóle nie odpowiada na próbę połączenia.
• This site can't be reached obejmuje cały zestaw błędów połączenia, które Chrome grupuje pod jednym nagłówkiem.

Najczęściej zadawane pytania

Czy ERR_CONNECTION_RESET oznacza, że zostałem zhakowany?

Nie. Niemal zawsze wskazuje na urządzenie sieciowe, regułę zapory, przechwytywanie przez antywirus albo awarię po stronie serwera, nie na atak na Twoje urządzenie.

Dlaczego zdarza się to tylko przy pobieraniu dużych plików?

Duże transfery częściej trafiają na niedopasowanie MTU, timeout proxy albo limit rozmiaru skonfigurowany na zaporze czy load balancerze, co wszystko może zakończyć połączenie w połowie strumienia, zanim małe żądanie zdążyłoby to wywołać.

Czy mój własny antywirus może to spowodować?

Tak. Funkcje skanowania HTTPS, które przechwytują i ponownie szyfrują ruch TLS, czasem zawodzą na konkretnych witrynach albo dużych odpowiedziach i resetują połączenie zamiast je przepuścić.

Czy reset jest gorszy niż timeout?

Nie z natury. Reset oznacza, że coś aktywnie zakończyło połączenie, co często łatwiej zdiagnozować niż timeout, gdzie nic się nie dzieje i nie wiadomo, czy pakiet w ogóle dotarł.

Dlaczego reset zdarza się za każdym razem w tym samym momencie?

Konsekwentna liczba bajtów albo upłynięty czas przed resetem zwykle wskazuje na ustalony limit, taki jak timeout proxy, maksymalny rozmiar odpowiedzi albo ustawienie keep-alive, a nie na przypadkową usterkę.

Czy operator komórkowy może resetować moje połączenia?

Niektórzy operatorzy rzeczywiście resetują długo trwające połączenia w ramach zarządzania siecią, zwłaszcza w zatłoczonych komórkach albo przy transferach o dużej przepustowości, takich jak streaming wideo. Jeśli to samo żądanie działa niezawodnie przez Wi-Fi, a resetuje się na danych mobilnych, ingerencja na poziomie operatora to rozsądne wyjaśnienie.