ERR_EMPTY_RESPONSE: сервер не вернул данные — как исправить

ERR_EMPTY_RESPONSE означает, что браузер установил TCP-соединение и отправил запрос, но сервер закрыл соединение, не вернув ни одного байта ответа — ни статуса, ни заголовков, ни тела. Чаще всего виноват упавший backend (php-fpm, node, gunicorn), таймаут прокси или WAF, который сбросил соединение. Проверьте логи веб-сервера — там будет точная причина.

В этом руководстве разберём, чем ERR_EMPTY_RESPONSE отличается от ошибок 502 и 504, какие серверные и клиентские причины его вызывают, как найти корень проблемы по логам nginx и php-fpm, и что делать администратору и обычному пользователю. Материал рассчитан на владельцев сайтов, DevOps-инженеров и тех, кто просто хочет вернуть доступ к странице.

Что такое ERR_EMPTY_RESPONSE

Это ошибка уровня Chromium (Chrome, Edge, Opera, Яндекс.Браузер). Она возникает, когда соединение с сервером было открыто и запрос ушёл, но ответ оказался пустым: сервер разорвал соединение до отправки HTTP-статусной строки. В отличие от кода ответа 500 или 404, здесь нет валидного HTTP-ответа вообще — поэтому браузер не может показать привычную страницу ошибки сервера и выдаёт собственное сообщение «Не удалось получить данные с сайта».

Причины ERR_EMPTY_RESPONSE

Пустой ответ — это симптом обрыва на транспортном уровне. Источник почти всегда на стороне сервера или промежуточного узла, но иногда виноват и клиент. Основные сценарии:

• Падение backend-процесса. php-fpm, Node.js, gunicorn или uWSGI аварийно завершились (segfault, OOM-killer, необработанное исключение) во время обработки запроса — соединение закрывается без ответа.
• Исчерпание памяти. Ядро Linux (OOM-killer) убивает процесс интерпретатора при нехватке RAM. В dmesg вы увидите строку Out of memory: Killed process.
• Таймаут прокси или upstream. nginx/Apache в роли reverse proxy разрывает соединение, если backend не ответил вовремя, а буферизация настроена так, что клиент не получает 504.
• WAF или rate limiting. Cloudflare, ModSecurity или fail2ban могут сбросить (RST) соединение вместо отдачи страницы блокировки — браузер трактует это как пустой ответ.
• Некорректная конфигурация HTTP/2 или gzip. Сбой при сжатии или мультиплексировании потоков иногда приводит к закрытию соединения без корректного кадра ответа.
• Клиентские причины. Повреждённый кэш браузера, конфликтующее расширение, VPN/прокси или сбойный сетевой драйвер могут мешать получить ответ.

Чем отличается от 502 и 504

Ключевое отличие: при 502 и 504 сервер (обычно прокси) всё же возвращает валидный HTTP-ответ с кодом статуса, а при ERR_EMPTY_RESPONSE ответа нет вообще. Сравним три ситуации:

Проще говоря: 502 и 504 — это «сервер ответил, что что-то не так», а ERR_EMPTY_RESPONSE — «сервер молча положил трубку».

Диагностика на стороне сервера

Начните с логов веб-сервера в реальном времени, затем повторите проблемный запрос через curl -v, чтобы увидеть, на каком этапе рвётся соединение.

tail -f /var/log/nginx/error.log
tail -f /var/log/php8.4-fpm.log
# в другом окне повторите запрос с подробным выводом
curl -v https://example.com/slow-page

Если backend падает от нехватки памяти, это видно в системном журнале:

dmesg -T | grep -i 'out of memory'
journalctl -u php8.4-fpm --since '10 min ago'

Типичная запись при обрыве upstream в nginx выглядит так:

upstream prematurely closed connection while reading response header from upstream,
client: 203.0.113.5, server: example.com, request: "GET /report HTTP/1.1",
upstream: "fastcgi://unix:/run/php/php8.4-fpm.sock"

Эта строка прямо указывает: php-fpm закрыл соединение раньше времени — ищите причину в логе PHP (fatal error, OOM, таймаут скрипта).

Как исправить на сервере

Действуйте от корня, а не от симптома:

1. Поднимите лимиты памяти. Увеличьте memory_limit в PHP или --max-old-space-size в Node.js, если процесс убивает OOM-killer. Добавьте RAM или swap.
2. Согласуйте таймауты. Значения fastcgi_read_timeout, proxy_read_timeout в nginx и request_terminate_timeout в php-fpm должны быть согласованы, чтобы прокси успевал вернуть 504 вместо обрыва.
3. Проверьте пул воркеров. Слишком малый pm.max_children при пике нагрузки приводит к отказам. Настройте пул под реальную память сервера.
4. Изучите правила WAF/rate-limit. Убедитесь, что ModSecurity, fail2ban или Cloudflare не сбрасывают легитимные запросы. Настройте отдачу страницы 429 вместо RST.
5. Отключите проблемный gzip/HTTP2 для теста. Временно уберите сжатие или переключитесь на HTTP/1.1, чтобы локализовать сбой мультиплексирования.
6. Обновите PHP/Node/библиотеки. Segfault часто вызван багом в устаревшем расширении (например, opcache, imagick).

Как исправить пользователю

Если сайт чужой и вы не администратор, попробуйте по порядку:

• Очистите кэш и cookie браузера, обновите страницу с Ctrl+F5.
• Откройте сайт в режиме инкогнито — это отключит расширения.
• Временно отключите VPN, прокси или блокировщик рекламы.
• Сбросьте сетевой стек: ipconfig /flushdns (Windows) или sudo dscacheutil -flushcache (macOS).
• Попробуйте другой браузер или сеть (мобильный интернет) — так вы поймёте, проблема на сервере или у вас.

Если страница открывается в инкогнито и на другом устройстве — причина почти наверняка на сервере, и пользователю остаётся только дождаться исправления или сообщить администратору.

Как проверить

Быстро оценить, отвечает ли сервер и какие заголовки он возвращает, помогает наш бесплатный инструмент проверки HTTP-заголовков: если сервер жив, вы увидите статус и заголовки; если ответа нет — подтвердите, что проблема на стороне сервера. Дополнительно сканер безопасности покажет, не режет ли соединение WAF или неверная конфигурация TLS. Официальную справку по HTTP смотрите в документации MDN, а по обработке ответов upstream — в документации nginx.

Смежные ошибки

ERR_EMPTY_RESPONSE часто соседствует с другими сетевыми сбоями. Если соединение сбрасывается по-другому, полезны разборы: ERR_CONNECTION_RESET, ERR_CONNECTION_CLOSED, а при ответах прокси — 502 Bad Gateway и 504 Gateway Timeout.

Частые вопросы

ERR_EMPTY_RESPONSE — это проблема моего компьютера или сервера?

Чаще всего сервера: упал backend или прокси сбросил соединение. Но исключите клиент — откройте сайт в инкогнито, на другом устройстве и в другой сети. Если везде та же ошибка, значит виноват сервер, и вам остаётся дождаться исправления или написать администратору ресурса.

Почему я вижу пустой ответ, а не код 500 или 502?

Код ответа появляется, только если сервер успел сформировать HTTP-ответ. При ERR_EMPTY_RESPONSE процесс аварийно завершился или соединение было сброшено до отправки статусной строки, поэтому валидного HTTP-ответа нет вообще — браузеру нечего показать, кроме собственной ошибки.

Как быстро найти причину на своём сервере?

Запустите tail -f на error.log nginx и логе php-fpm, затем повторите запрос через curl -v. Строка про «upstream prematurely closed connection» укажет на backend, а запись «Out of memory» в dmesg — на нехватку RAM и работу OOM-killer.

Может ли ERR_EMPTY_RESPONSE вызывать Cloudflare или WAF?

Да. Правила WAF, Cloudflare или fail2ban иногда сбрасывают соединение через TCP RST вместо отдачи страницы блокировки. Проверьте логи защитного слоя и настройте отдачу корректного ответа 403 или 429, чтобы браузер получал понятный статус, а не пустой ответ.

Помогает ли перезагрузка сервера?

Перезапуск php-fpm или веб-сервера временно устранит симптом, если процесс завис или переполнил память. Но без устранения корневой причины — утечки памяти, малого пула воркеров или бага в коде — ошибка вернётся под нагрузкой. Сначала найдите источник по логам, затем правьте конфигурацию.