ERR_EMPTY_RESPONSE: przyczyny i naprawa

2026-09-19

ERR_EMPTY_RESPONSE oznacza, że połączenie zostało zaakceptowane, ale serwer odesłał zero bajtów, zamiast poprawnej odpowiedzi HTTP albo choćby strony błędu. Handshake TCP się udał; cokolwiek powinno odpowiedzieć na żądanie, nigdy tego nie zrobiło.

Co oznacza ERR_EMPTY_RESPONSE

Ten błąd siedzi później w cyklu żądania niż odrzucone czy przekraczające limit czasu połączenie. Przeglądarka pomyślnie łączy się z serwerem, a przy żądaniu HTTPS handshake TLS zwykle też się kończy, ale po wysłaniu żądania połączenie zamyka się bez linii statusu HTTP, bez nagłówków i bez żadnej treści. To różni się od strony błędu 500 czy 502, która wciąż jest kompletną odpowiedzią HTTP; tutaj nie ma nic do sparsowania, bo nic nie wróciło.

To sprawia, że ERR_EMPTY_RESPONSE jest trudniejszy do zdiagnozowania od strony klienta niż większość błędów połączenia, bo każda warstwa aż po połączenie transportowe włącznie zadziałała poprawnie. Wina leży konkretnie w tym, co generuje odpowiedź HTTP: procesie aplikacji, frameworku obsługującym żądanie, albo w proxy przed nim, które zamknęło gniazdo zamiast przekazać dalej, albo wygenerować, poprawną stronę błędu.

Jak pojawia się błąd

Chrome pokazuje "This site can't be reached ... ERR_EMPTY_RESPONSE", gdy połączenie zamyka się bez danych. curl zgłasza ten sam warunek prostymi słowami:

curl -v https://example.com/api/generate
* Connected to example.com (203.0.113.10) port 443
> GET /api/generate HTTP/1.1
> Host: example.com
*
* Empty reply from server
curl: (52) Empty reply from server

"Empty reply from server" to dokładne sformułowanie curla dla tego warunku i jest to najwyraźniejszy sygnał, że samo połączenie zadziałało, podczas gdy to, co powinno wygenerować odpowiedź, tego nie zrobiło.

Co powoduje ERR_EMPTY_RESPONSE

Proces workera zawiesił się w trakcie obsługi żądania. Nieobsłużony wyjątek, zabicie z powodu braku pamięci albo naruszenie ochrony pamięci mogą zamknąć połączenie, zanim jakakolwiek odpowiedź zostanie zapisana.
Aplikacja przekroczyła limit czasu za proxy, które zamyka się po cichu. Niektóre konfiguracje reverse proxy zamykają połączenie klienta bez wysyłania strony błędu, gdy backend zajmuje zbyt dużo czasu, zamiast zwrócić poprawne 502 albo 504.
Czysty HTTP jest serwowany na porcie HTTPS, albo odwrotnie. Klient mówiący TLS do portu serwującego czysty HTTP, albo na odwrót, nie dostaje żadnej poprawnej odpowiedzi, którą warstwa protokołu klienta mogłaby sparsować, i często ujawnia się to jako pusta odpowiedź, a nie jasny błąd protokołu.
Rozszerzenie przeglądarki albo lokalne proxy ingeruje w odpowiedź. Blokery reklam, rozszerzenia prywatności albo firmowe proxy, które inspekcjonuje i czasem źle obsługuje odpowiedź, mogą okroić ją do niczego.
Health check load balancera oznacza backend jako niezdrowy w trakcie żądania, zamykając połączenie do tego backendu, zanim odpowiedź się skończy.

Jak rozpoznać, kto zawinił

Wyłącz najpierw rozszerzenia przeglądarki albo wypróbuj okno incognito; rozszerzenie po stronie klienta to jedna z bardziej częstych i najłatwiejszych do wykluczenia przyczyn. Jeśli pusta odpowiedź utrzymuje się z wyłączonymi rozszerzeniami, przetestuj z drugiego urządzenia albo sieci, żeby wykluczyć lokalne proxy. Jeśli zdarza się konsekwentnie z wielu zewnętrznych lokalizacji, przyczyną jest serwer albo awaria aplikacji. Uruchomienie kontroli HTTP z kilku punktów kontrolnych naraz potwierdza, czy pusta odpowiedź jest powszechna, czy związana z jednym klientem, rozszerzeniem albo siecią.

Jak naprawić ERR_EMPTY_RESPONSE

Jeśli jesteś odwiedzającym

Wypróbuj okno incognito albo prywatne z wyłączonymi rozszerzeniami, żeby wykluczyć bloker reklam albo rozszerzenie prywatności ingerujące w odpowiedź.
Wyłącz dowolne lokalne proxy albo VPN i spróbuj ponownie, bo niektóre przechwytują i czasem źle obsługują odpowiedzi zamiast je przepuszczać.
Wyczyść cache przeglądarki dla witryny; zbuforowany, uszkodzony stan połączenia może czasem ponownie objawić się jako ten błąd przy ponownej próbie.
Poczekaj i przeładuj. Jeśli przyczyną jest zawieszony proces workera na serwerze, nadzorca procesu zwykle restartuje go w ciągu sekund.

Jeśli prowadzisz witrynę

Sprawdź logi aplikacji pod kątem awarii o tym samym znaczniku czasu co nieudane żądanie; nieobsłużony wyjątek albo zabicie z powodu braku pamięci to najczęstsza przyczyna i zwykle zostawia wyraźny ślad.
Potwierdź poprawny protokół przypięty do każdego portu. Zweryfikuj, że port 443 faktycznie serwuje TLS, a port 80 czysty HTTP, nie odwrotnie, bezpośrednią kontrolą:
```
curl -v https://example.com:443/
curl -v http://example.com:80/
```
Przejrzyj zachowanie timeoutu reverse proxy. Na nginx backend przekraczający proxy_read_timeout wciąż powinien zwrócić 504, więc pusta odpowiedź zamiast poprawnej strony błędu zwykle oznacza, że coś zamyka połączenie niżej w stosie.
Sprawdź logi load balancera i health checków pod kątem backendu oznaczonego jako niezdrowy w czasie awarii, co może zamknąć trwające połączenia do tej instancji.
Zrestartuj dotknięty proces workera albo usługę, jeśli awaria zostanie potwierdzona, i uważnie monitoruj logi po restarcie pod kątem powtórzenia tego samego błędu.

Jak zapobiec ERR_EMPTY_RESPONSE

Awaria workera pod konkretnymi warunkami, takimi jak konkretna treść żądania albo skok zużycia pamięci, może być na tyle sporadyczna, że przejdzie ręczny test, jednocześnie regularnie zawodząc dla prawdziwych odwiedzających. Ciągłe monitorowanie HTTP, które sprawdza kod statusu i treść odpowiedzi w regularnych odstępach z ponad 300 punktów kontrolnych w 158 miastach, wyłapuje wzorzec pustej odpowiedzi, który pojedyncza ręczna kontrola prawdopodobnie by przeoczyła, z alertami e-mailem, SMS-em, połączeniem głosowym, przez Slack, Telegram i inne kanały.

Powiązane błędy

ERR_CONNECTION_RESET też przedwcześnie kończy działające połączenie, ale wprost resetem, a nie cichym zamknięciem.
502 Bad Gateway to poprawna odpowiedź błędu HTTP od proxy, w przeciwieństwie do pustej odpowiedzi, którą opisuje ten błąd.
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_EMPTY_RESPONSE to to samo co błąd 502?

Nie. 502 to kompletna odpowiedź HTTP z linią statusu, nagłówkami i zwykle treścią, wysłana celowo przez proxy. ERR_EMPTY_RESPONSE oznacza, że żadna odpowiedź HTTP nie została w ogóle wysłana, tylko zamknięte połączenie.

Dlaczego dzieje się to tylko na jednej konkretnej stronie?

Strona, która konsekwentnie wywołuje ten błąd, podczas gdy inne ładują się bez problemu, zwykle wskazuje na awarię w ścieżce kodu, której używa ta konkretna strona albo endpoint API, a nie na ogólny problem serwera czy sieci.

Czy bloker reklam naprawdę może spowodować ten błąd?

Tak. Niektóre blokery reklam i rozszerzenia prywatności przechwytują i przepisują odpowiedzi, a błąd albo zbyt agresywna reguła mogą czasem okroić legalną odpowiedź do niczego, zamiast czysto ją zablokować.

Czy ERR_EMPTY_RESPONSE oznacza, że moje dane zostały utracone?

Niekoniecznie przy żądaniu GET, ale przy wysłaniu formularza albo wywołaniu API zmieniającym dane sprawdź, czy akcja faktycznie została zakończona na serwerze, zanim spróbujesz ponownie, bo klient nie może po pustej odpowiedzi stwierdzić, czy żądanie zostało przetworzone.

Dlaczego curl mówi "Empty reply from server" zamiast kodu błędu?

Bo nie ma odpowiedzi HTTP, z której można by odczytać kod statusu. Własne sformułowanie curla opisuje zdarzenie na poziomie transportu, zamknięte połączenie bez danych, które jest o jedną warstwę poniżej samego protokołu HTTP.

Czy to moja sieć mogła zamknąć połączenie zamiast serwera?

Zdarza się to rzadziej niż przyczyna po stronie serwera, ale się zdarza. Firmowe proxy albo zapora kończąca długo trwające połączenia po stałym okresie bezczynności może wyprodukować ten sam objaw; przetestowanie tego samego żądania z innej sieci szybko to wyklucza.