ERR_CONNECTION_RESET: dlaczego połączenie zrywa się w połowie

Co oznacza ten błąd

Połączenie zostało nawiązane, przeglądarka wysłała żądanie albo już odbierała odpowiedź, i nagle druga strona wysłała pakiet RST: „koniec, rozłączam”. Chrome pokazuje ERR_CONNECTION_RESET („Nie można uzyskać dostępu do tej witryny” z dopiskiem „Połączenie zostało zresetowane”), Firefox „Połączenie zostało przerwane”. To nie ERR_CONNECTION_REFUSED (nikt nie odebrał) ani ERR_CONNECTION_TIMED_OUT (nikt nie odpowiedział): tu ktoś odebrał i w trakcie się rozmyślił.

Reset może wysłać serwer (proces umarł w trakcie odpowiedzi), coś pomiędzy (firewall, proxy, load balancer, filtr dostawcy internetu) albo coś na komputerze odwiedzającego (antywirus skanujący HTTPS, VPN). Jeśli błąd pojawia się tylko przy jednej akcji, na przykład przy wysyłaniu dużego pliku, to wskazówka: limity wielkości żądania.

Częste przyczyny

Po stronie odwiedzającego

1. Antywirus z „ochroną WWW” albo skanowaniem HTTPS, który podmienia połączenie i zrywa je, gdy czegoś nie rozumie.
2. VPN albo proxy, zwłaszcza firmowe, z filtrem treści.
3. Niestabilne Wi-Fi, router z błędną tablicą NAT, stary wpis w pamięci podręcznej DNS po zmianie adresu strony.
4. Dostawca internetu albo sieć blokująca domenę resetem (tak działają niektóre filtry).

Po stronie właściciela

5. Proces aplikacji ginie w trakcie odpowiedzi. PHP-FPM z segfaultem, przekroczony memory_limit, proces zabity przez OOM-killer: nginx nie dostaje końca odpowiedzi i resetuje połączenie z przeglądarką.
6. Firewall, fail2ban albo limit zapytań zrywający połączenia z danego adresu po kilku żądaniach.
7. Konfiguracja TLS, która psuje się w połowie uścisku dłoni: niepasujący klucz, stara biblioteka, HTTP/2 z błędną konfiguracją.
8. Limit wielkości żądania: client_max_body_size w nginx albo LimitRequestBody w Apache zbyt mały; przy wysyłaniu pliku serwer zrywa połączenie zamiast odpowiedzieć kodem 413.
9. Keepalive i limity czasu między proxy a backendem: backend zamyka bezczynne połączenie, a proxy właśnie chce nim wysłać żądanie.
10. Proxy albo load balancer (Cloudflare, HAProxy, Traefik) z backendem, który odpowiada innym protokołem, niż oczekuje pośrednik.

Jeśli odwiedzasz cudzą stronę

1. Wyłącz na chwilę skanowanie HTTPS w antywirusie i VPN; spróbuj ponownie.
2. Spróbuj z telefonu bez Wi-Fi. Jeśli tam działa, winna jest Twoja sieć: zrestartuj router.
3. Wyczyść pamięć podręczną DNS (ipconfig /flushdns, sudo dscacheutil -flushcache, sudo resolvectl flush-caches).
4. Sprawdź stronę narzędziem Is it down?: „połączenie zerwane” także z zewnątrz oznacza, że problem ma właściciel.

Jeśli to Twoja strona: najpierw sprawdź

Odtwórz błąd i zobacz, w którym momencie połączenie pada:

curl -v https://przyklad.pl 2>&1 | tail -n 20
curl -v -o /dev/null -F 'plik=@duzy.zip' https://przyklad.pl/upload 2>&1 | tail -n 10

Connection reset by peer zaraz po Client hello to TLS (przyczyna 7); po wysłaniu nagłówków to aplikacja albo firewall (5, 6); w trakcie wysyłania dużego pliku to limit wielkości (8). Na serwerze:

sudo tail -n 50 /var/log/nginx/error.log
sudo tail -n 50 /var/log/php8.3-fpm.log
sudo dmesg -T | grep -iE 'oom|killed process|segfault' | tail -n 20
sudo fail2ban-client status
sudo nft list ruleset | grep -nE 'reject|drop'

Szukaj linii upstream prematurely closed connection, child … exited on signal 11 (SIGSEGV), Allowed memory size, recv() failed (104: Connection reset by peer). Każda z nich wskazuje inny krok poniżej.

Naprawy na własnym serwerze

1. Padający PHP-FPM albo aplikacja

sudo systemctl status php8.3-fpm
sudo journalctl -u php8.3-fpm -n 50 --no-pager
grep -n memory_limit /etc/php/8.3/fpm/php.ini

Segfault po aktualizacji to zwykle niezgodne rozszerzenie PHP (OPcache, APCu, ioncube): wyłącz je po kolei w /etc/php/8.3/fpm/conf.d/. Przekroczony memory_limit przy jednej podstronie to wtyczka albo import; podnieś limit rozsądnie (256M) i znajdź winnego. OOM-killer zabijający procesy oznacza za dużo procesów roboczych na za mało pamięci: obniż pm.max_children. Po zmianie sudo php-fpm8.3 -t && sudo systemctl reload php8.3-fpm.

2. Firewall i fail2ban

sudo fail2ban-client status nginx-limit-req
sudo fail2ban-client set nginx-limit-req unbanip 198.51.100.7

Reguły reject w firewallu odrzucają połączenia resetem; sprawdź, czy nie obejmują legalnego ruchu, a za Cloudflare, czy banowane są prawdziwe adresy, nie zakresy pośrednika (real_ip_header CF-Connecting-IP).

3. TLS

echo | openssl s_client -connect przyklad.pl:443 -servername przyklad.pl 2>&1 | grep -E 'Protocol|Cipher|error'
sudo nginx -T | grep -nE 'ssl_protocols|ssl_ciphers|http2'

Reset w trakcie uścisku dłoni oznacza niepasujący klucz, błędną listę szyfrów albo problem z HTTP/2 po aktualizacji. Pełna diagnoza w poradniku ERR_SSL_PROTOCOL_ERROR.

4. Limit wielkości żądania

# nginx, w bloku server albo http
client_max_body_size 64m;

Apache: LimitRequestBody 67108864. PHP: upload_max_filesize i post_max_size w php.ini na tę samą wartość. Potem test konfiguracji i przeładowanie.

5. Keepalive między proxy a backendem

Jeśli nginx stoi przed aplikacją (Node.js, PHP-FPM przez TCP, Apache), ustaw, by backend trzymał połączenie dłużej niż proxy, albo wyłącz keepalive do backendu:

upstream app {
    server 127.0.0.1:3000;
    keepalive 16;
}
proxy_http_version 1.1;
proxy_set_header Connection "";

W aplikacji ustaw keepAliveTimeout wyżej niż keepalive_timeout w nginx; inaczej backend zamyka połączenie dokładnie wtedy, gdy proxy chce z niego skorzystać.

6. Proxy i load balancer

Backend mówiący HTTP, gdy balancer oczekuje HTTPS (albo odwrotnie), kończy się resetem przy pierwszym bajcie. Sprawdź protokół backendu w konfiguracji balancera i tryb SSL w Cloudflare; szczegóły w poradniku o błędach 521 i 522.

Gdy to problem dostawcy hostingu

Na hostingu współdzielonym procesy PHP, firewall i limity należą do dostawcy. Wyślij:

Dzień dobry, moja strona przyklad.pl od około 18:05 UTC odpowiada „connection reset” (ERR_CONNECTION_RESET), także w sprawdzeniu z zewnątrz; curl zgłasza „Connection reset by peer” po wysłaniu nagłówków. Po mojej stronie nic się nie zmieniło. Czy procesy PHP mojego konta są restartowane lub zabijane z braku pamięci, albo czy firewall zrywa połączenia do mojej domeny?

Jak zapobiec następnemu

Zerwane połączenia zaczynają się od procesu, który ginie, a to widać wcześniej: rosnące zużycie pamięci, wpisy OOM w dzienniku, zatrzymująca się usługa. Agent serwerowy pilnuje pamięci i usług, a sprawdzanie strony z zewnątrz w monitoringu stron wyłapuje zerwane połączenia w ciągu minuty. Awaria? Naprawiamy: Quick Fix restartuje padającą usługę po udanym teście jej konfiguracji i zwalnia pamięć w stałej cenie; limity, TLS, keepalive i proxy porządkuje Deep Fix, przez całą dobę. Zobacz naprawa serwera. Gdy serwer zamyka połączenie bez wysłania choćby bajta, zobacz ERR_EMPTY_RESPONSE.