ERR_EMPTY_RESPONSE: serwer nie wysłał żadnych danych

Co oznacza ten błąd

Przeglądarka połączyła się z serwerem, wysłała żądanie i dostała w odpowiedzi ciszę, a potem zamknięte połączenie: ani kodu statusu, ani nagłówka, ani bajta treści. Chrome pokazuje „Ta strona nie działa” z dopiskiem „przyklad.pl nie wysłała żadnych danych” i kodem ERR_EMPTY_RESPONSE; curl mówi Empty reply from server. Firefox częściej pokazuje „Połączenie zostało przerwane”.

Warto odróżnić to od sąsiadów, bo każdy wskazuje inne miejsce: przy ERR_CONNECTION_REFUSED nikt nie odbiera, przy ERR_CONNECTION_TIMED_OUT nikt nie odpowiada w czasie, przy ERR_CONNECTION_RESET połączenie zostaje gwałtownie zerwane. Tu serwer grzecznie przyjmuje połączenie, coś po jego stronie ginie albo milczy, i połączenie jest zamykane normalnie, tylko puste. To prawie zawsze proces, który umarł, zanim zdążył odpowiedzieć, albo pośrednik, który nie miał co przekazać.

Częste przyczyny

Po stronie odwiedzającego (rzadko, ale szybko do wykluczenia)

1. Uszkodzona pamięć podręczna albo ciasteczko, które powoduje błąd w aplikacji tylko dla Ciebie.
2. Rozszerzenie przeglądarki, które modyfikuje żądanie (nagłówki, blokowanie skryptów).
3. VPN, proxy albo antywirus ze skanowaniem HTTPS, który „zjada” odpowiedź.
4. Inna sieć daje inny wynik: wtedy problem jest po drodze, nie na serwerze.

Po stronie właściciela

5. Proces PHP-FPM albo serwera WWW ginie w trakcie żądania. Segfault w rozszerzeniu PHP, przekroczony memory_limit, proces zabity przez OOM-killer. nginx dostaje pustą odpowiedź od backendu i, zależnie od konfiguracji, przekazuje pustkę dalej albo odpowiada błędem 502.
6. Wtyczka albo rozszerzenie z błędem krytycznym, który kończy skrypt przed wysłaniem nagłówków, z wyłączonym wyświetlaniem błędów. Typowe po aktualizacji WordPressa.
7. Proxy albo upstream zamyka bez odpowiedzi: nginx loguje upstream prematurely closed connection while reading response header; reguła return 444; w nginx celowo zamyka połączenie bez odpowiedzi (często używana przeciw botom i przypadkiem obejmująca wszystkich).
8. Firewall albo reguła bezpieczeństwa odrzuca odpowiedź, nie żądanie: ModSecurity w trybie, który przerywa odpowiedź, filtr wychodzący, błędna reguła w nftables.
9. Zły port albo protokół: HTTP wysłane na port, na którym nasłuchuje inna usługa (baza, SSH, panel), która nie rozumie HTTP i rozłącza.
10. Keepalive i limity czasu: backend zamyka bezczynne połączenie w tej samej chwili, w której proxy wysyła nim nowe żądanie; odpowiedź nigdy nie powstaje.
11. Za duże nagłówki albo odpowiedź przekraczające bufory, przy których serwer zamyka połączenie zamiast odpowiedzieć kodem błędu.

Jeśli odwiedzasz cudzą stronę

1. Odśwież w oknie prywatnym (bez ciasteczek i rozszerzeń).
2. Wyczyść pamięć podręczną i ciasteczka tej strony.
3. Wyłącz na chwilę VPN, proxy i skanowanie HTTPS w antywirusie.
4. Spróbuj z telefonu bez Wi-Fi. Jeśli wszędzie pusto, a narzędzie Is it down? też zgłasza „serwer zamknął połączenie bez odpowiedzi”, działać musi właściciel.

Jeśli to Twoja strona: najpierw sprawdź

Potwierdź z zewnątrz narzędziem Is it down? i odtwórz błąd przez curl, żeby zobaczyć, czy pusto jest dla każdego adresu, czy tylko dla jednej podstrony:

curl -v https://przyklad.pl/ 2>&1 | tail -n 8
curl -v https://przyklad.pl/wp-admin/ 2>&1 | tail -n 8
curl -sI http://127.0.0.1/ -H 'Host: przyklad.pl'       # na serwerze, z pominięciem CDN

Empty reply from server tylko na jednej ścieżce wskazuje aplikację (przyczyny 5, 6); na wszystkich ścieżkach serwer WWW, proxy albo firewall (7–10). Na serwerze:

sudo tail -n 50 /var/log/nginx/error.log
sudo tail -n 50 /var/log/php8.3-fpm.log
sudo journalctl -u php8.3-fpm -n 50 --no-pager
sudo dmesg -T | grep -iE 'oom|killed process|segfault' | tail -n 20
sudo nginx -T | grep -nE 'return 444|proxy_pass|fastcgi_pass'
sudo ss -tlnp | grep -E ':80 |:443 '

Szukaj: upstream prematurely closed connection, exited on signal 11, Allowed memory size … exhausted, Out of memory: Killed process … php-fpm, return 444. Każda linia prowadzi do innego kroku poniżej.

Naprawy na własnym serwerze albo hostingu z SSH

1. Proces ginie: pamięć i segfault

grep -n memory_limit /etc/php/8.3/fpm/php.ini
free -m
ps -ylC php-fpm8.3 --sort:rss | tail -n 5

Podnieś memory_limit rozsądnie (256M) i znajdź wtyczkę albo import, który zjada pamięć. Jeśli OOM-killer zabija PHP-FPM, obniż pm.max_children, żeby suma procesów mieściła się w pamięci. Segfault po aktualizacji: wyłącz po kolei rozszerzenia w /etc/php/8.3/fpm/conf.d/ (OPcache, APCu, ioncube, xdebug). Po każdej zmianie sudo php-fpm8.3 -t && sudo systemctl reload php8.3-fpm.

2. Wtyczka z błędem krytycznym

Włącz na chwilę log błędów WordPressa w wp-config.php:

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

wp-content/debug.log poda plik i linię. Wyłącz wtyczkę przez wp plugin deactivate nazwa-wtyczki albo zmianę nazwy jej katalogu przez SFTP. Szczegóły w poradniku o błędzie krytycznym WordPressa.

3. nginx: return 444 i upstream

sudo grep -rn 'return 444' /etc/nginx/

Reguła 444 powinna obejmować tylko nieznane nazwy hostów albo konkretne user agenty, nie domyślny blok server dla Twojej domeny. Przy upstream prematurely closed sprawdź, czy backend żyje i na którym sockecie nasłuchuje (grep -r '^listen' /etc/php/*/fpm/pool.d/). Potem sudo nginx -t && sudo systemctl reload nginx.

4. Firewall i ModSecurity

sudo nft list ruleset | grep -nE 'output|reject|drop'
sudo tail -n 30 /var/log/modsec_audit.log

Reguły w łańcuchu output potrafią odrzucać odpowiedzi serwera; usuń te, które obejmują porty 80/443. W ModSecurity wyłącz regułę po identyfikatorze (SecRuleRemoveById) zamiast całego modułu.

5. Zły port albo protokół

sudo ss -tlnp pokazuje, kto naprawdę nasłuchuje na 80 i 443. Jeśli to nie serwer WWW (panel, aplikacja deweloperska, baza), zatrzymaj go albo przenieś. Sprawdź też, czy proxy_pass nie wskazuje portu HTTPS z http:// albo odwrotnie.

6. Keepalive między proxy a backendem

Ustaw w backendzie limit bezczynności dłuższy niż w nginx (np. Node.js server.keepAliveTimeout = 65000 przy keepalive_timeout 60;), albo wyłącz keepalive do backendu (proxy_set_header Connection ""; i brak keepalive w upstream). Dla dużych nagłówków podnieś fastcgi_buffer_size 32k; i proxy_buffer_size 32k;.

Gdy to problem dostawcy hostingu

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

Dzień dobry, moja strona przyklad.pl od około 19:20 UTC odpowiada pustą odpowiedzią (ERR_EMPTY_RESPONSE, curl: „Empty reply from server”), także w sprawdzeniu z zewnątrz i dla wszystkich adresów. Po mojej stronie nic się nie zmieniło. Czy procesy PHP mojego konta są zabijane z braku pamięci albo czy serwer WWW lub firewall zamyka połączenia do mojej domeny bez odpowiedzi? Proszę o fragment logu błędów z tego okresu.

Jak zapobiec następnemu

Pusta odpowiedź to w praktyce proces, który umarł, i to widać wcześniej: rosnąca pamięć, wpisy OOM, usługa, która się restartuje. Agent serwerowy pilnuje pamięci i usług, a sprawdzanie strony w monitoringu stron wyłapuje pustą odpowiedź w ciągu minuty i potwierdza ją z innej lokalizacji, zanim dostaniesz alert. Awaria? Naprawiamy: Quick Fix restartuje padającą usługę po udanym teście jej konfiguracji i zwalnia pamięć, w stałej cenie; przyczynę w kodzie, konfiguracji proxy albo firewalla usuwa Deep Fix, przez całą dobę. Zobacz naprawa serwera.