ERR_EMPTY_RESPONSE: co oznacza i jak naprawić

Czym jest błąd ERR_EMPTY_RESPONSE?

ERR_EMPTY_RESPONSE to strona błędu Chrome i Edge z komunikatem „Ta strona nie działa. Strona example.com nie wysłała żadnych danych” (This page isn't working. example.com didn't send any data). W Chromium to błąd sieciowy -324, zdefiniowany jako: „Serwer zamknął połączenie, nie wysyłając żadnych danych” (The server closed the connection without sending any data).

Przeglądarka zaszła tu dalej niż przy większości błędów połączenia. Adres został rozwiązany, połączenie otwarte, a przeglądarka wysłała żądanie. Potem serwer albo coś przed nim zamknęło połączenie z pustą odpowiedzią: bez kodu statusu, bez nagłówków, bez strony. Kod Chromium używa tego błędu tylko dla nowego połączenia, które zamyka się po zerze bajtów. Gdy zamyka się stare, ponownie używane połączenie, Chrome po cichu ponawia próbę.

Ponieważ żądanie faktycznie dotarło, ERR_EMPTY_RESPONSE zwykle wskazuje na stronę serwera: aplikację, która uległa awarii podczas obsługi żądania, regułę, która celowo zrywa połączenia, albo usługę, która przyjęła połączenie, ale nic za nią nie stało. Kilka przyczyn na Twoim własnym komputerze również może go wywołać.

Co powoduje błąd ERR_EMPTY_RESPONSE?

Rozwiązanie 1: Odśwież stronę i spróbuj trybu incognito

Jeśli serwer zrestartował się w nieodpowiednim momencie, wystarczy odświeżyć stronę kilka sekund później. Jeśli błąd się powtarza, otwórz stronę w oknie incognito (Ctrl + Shift + N, Mac Cmd + Shift + N). Tryb incognito startuje bez plików cookie i bez rozszerzeń, więc szybko pokazuje, czy ma z tym coś wspólnego coś zapisanego w przeglądarce.

Następnie sprawdź, czy strona nie działa u wszystkich. Narzędzie HTTP Headers od DNS Robot pobiera stronę z naszych serwerów: jeśli dostajemy normalną odpowiedź, problem leży między Tobą a stroną. Jeśli my też nic nie dostajemy, zawodzi sama strona.

Rozwiązanie 2: Wyłącz VPN, proxy i skanowanie HTTPS

Wszystko, co stoi pośrodku Twoich połączeń, może przyjąć żądanie, a potem je zamknąć, nie przekazując odpowiedzi:

• VPN: całkowicie go rozłącz i odśwież stronę.

• Proxy: w Windows 11 Ustawienia → Sieć i Internet → Serwer proxy → wyłącz Użyj serwera proxy. Na Macu Ustawienia systemowe → Sieć → Twoje połączenie → Szczegóły… → Proxy.

• Skanowanie HTTPS w antywirusie: wyłącz tylko funkcję ochrony WWW lub skanowania HTTPS (zwykle nazywa się ona skanowanie HTTPS, Web Shield (osłona WWW) albo filtrowanie protokołu SSL/TLS) i odśwież stronę. Jeśli to pomoże, dodaj wyjątek dla tej strony i włącz skanowanie z powrotem.

Rozwiązanie 3: Wyczyść dane strony i wyłącz rozszerzenia

Bardzo duże lub uszkodzone pliki cookie mogą sprawić, że serwer porzuci żądanie, zamiast na nie odpowiedzieć, co często objawia się błędem dopiero po zalogowaniu. Wyczyść pliki cookie tej strony: kliknij ikonę po lewej stronie paska adresu → Pliki cookie i dane witryn (lub Ustawienia witryny) → usuń dane, a potem zaloguj się ponownie.

Następnie wyłącz wszystkie rozszerzenia w chrome://extensions i odśwież stronę. Włączaj je z powrotem po jednym, aby znaleźć to, które przeszkadza. Często jest to bloker reklam, narzędzie do ochrony prywatności albo cokolwiek, co edytuje żądania.

Rozwiązanie 4: Wyczyść DNS i zresetuj stos sieciowy

Jeśli na jednym komputerze puste odpowiedzi dają wszystkie strony, zresetuj jego konfigurację sieci. W Windows uruchom poniższe polecenia w wierszu polecenia jako administrator i zrestartuj komputer. Na Macu wyczyść pamięć podręczną DNS oraz usuń i dodaj ponownie sieć Wi-Fi.

ipconfig /flushdns
netsh winsock reset
netsh int ip reset
ipconfig /release
ipconfig /renew

Spróbuj też innej sieci, na przykład danych mobilnych w telefonie. Jeśli tam strona działa, połączenie może przerywać filtr w Twojej zwykłej sieci (szkolnej, firmowej lub u dostawcy internetu).

ERR_EMPTY_RESPONSE na localhost i w Dockerze

Programiści najczęściej widzą ten błąd na własnym komputerze. Typowe przyczyny:

• Aplikacja w kontenerze Docker nasłuchuje na 127.0.0.1. Wewnątrz kontenera 127.0.0.1 oznacza „tylko ten kontener”, więc przekierowanie portu w Dockerze nie ma się z czym połączyć, a przeglądarka dostaje pustą odpowiedź (albo, zależnie od konfiguracji, reset połączenia). Ustaw aplikację tak, by w kontenerze nasłuchiwała na 0.0.0.0, na przykład next dev -H 0.0.0.0, vite --host 0.0.0.0, flask run --host=0.0.0.0 lub uvicorn main:app --host 0.0.0.0.

• Mapowanie portów kontenera się nie zgadza. -p 8080:3000 przekierowuje Twój port 8080 na port 3000 wewnątrz kontenera. Jeśli aplikacja faktycznie nasłuchuje na porcie 5000, każde żądanie wraca puste.

• http:// na porcie obsługującym tylko HTTPS. Niektóre serwery oczekują na danym porcie TLS i po prostu się rozłączają, gdy dociera zwykłe HTTP. Spróbuj https://localhost:8443 zamiast http://.

• Serwer deweloperski uległ awarii podczas obsługi żądania. Sprawdź terminal, w którym działa. Wyjątek lub błąd braku pamięci w tym momencie to Twoja odpowiedź.

# Odtwórz błąd bez przeglądarki
curl -v http://localhost:8080/
# "Empty reply from server" = połączenie przyjęte, nic nie zostało odesłane

# Które porty publikuje kontener i co nasłuchuje w jego wnętrzu?
docker ps --format "table {{.Names}}\t{{.Ports}}"
docker exec -it <container> sh -c "netstat -tlnp 2>/dev/null || ss -tlnp"

Dla właścicieli stron: dlaczego serwer wysyła puste odpowiedzi

• Awarie i zabicie procesu przy braku pamięci. Jeśli proces obsługujący żądanie zginie, połączenie zamyka się bez wysłania czegokolwiek. Sprawdź logi aplikacji oraz dmesg -T | grep -i "killed process" pod kątem linuksowego OOM killera, zwłaszcza na ciężkich podstronach i przy przesyłaniu plików.

• Celowe zrywanie połączeń. Specjalna dyrektywa nginx return 444; zamyka połączenie bez żadnej odpowiedzi i często służy do blokowania złych botów lub nieznanych nazw hostów. Jeśli taka reguła trafia w prawdziwych odwiedzających (zbyt szeroka reguła user agenta lub GeoIP), widzą oni ERR_EMPTY_RESPONSE albo, przy połączeniach HTTP/2, ERR_HTTP2_PROTOCOL_ERROR, bo wtedy nginx resetuje strumień. WAF-y, limitery żądań i usługi ochrony przed botami mogą robić to samo.

• Przekierowania portów i load balancery bez backendu. Nasłuch, który przyjmuje połączenie, ale nie ma za sobą sprawnego serwera, może zamknąć je bez odpowiedzi. Sprawdź stan celów (target health) i to, czy port backendu się zgadza.

• Limity czasu, które zamykają połączenie zamiast odpowiedzieć. Niech długotrwałe żądania zwracają właściwy błąd (na przykład 504), zamiast po cichu zamykać gniazdo, żeby odwiedzający i monitoring widzieli, co się stało.

• Zbyt duże żądania. Bardzo duże nagłówki lub pliki cookie mogą sprawić, że niektóre serwery porzucą żądanie. Utrzymuj małe pliki cookie.

# Czy są jakieś reguły, które zrywają połączenia?
sudo grep -rn "return 444" /etc/nginx/

# Test z zewnątrz, tak jak łączą się odwiedzający
curl -sv https://yourdomain.com/ -o /dev/null

ERR_EMPTY_RESPONSE a podobne błędy

Powiązane poradniki: ERR_CONNECTION_CLOSED, ERR_CONNECTION_RESET, 502 Bad Gateway i 500 Internal Server Error. Aby sprawdzić, czy port serwera przyjmuje połączenia z zewnątrz, użyj Port Checkera.