ERR_EMPTY_RESPONSE: что значит и как исправить

Что такое ERR_EMPTY_RESPONSE?

ERR_EMPTY_RESPONSE — страница ошибки Chrome и Edge с текстом «Страница недоступна. Сайт example.com не отправил данных» (This page isn't working. example.com didn't send any data). Внутри Chromium это сетевая ошибка -324 с определением: «сервер закрыл соединение, не отправив никаких данных».

Браузер продвинулся дальше, чем при большинстве ошибок соединения. Адрес разрешился, соединение открылось, и браузер отправил запрос. Затем сервер или что-то перед ним закрыл соединение с пустым ответом: ни кода состояния, ни заголовков, ни страницы. Код Chromium использует эту ошибку только для нового соединения, которое закрылось с нулём байт. Когда закрывается старое, повторно используемое соединение, Chrome вместо этого тихо повторяет запрос.

Поскольку запрос действительно был доставлен, ERR_EMPTY_RESPONSE обычно указывает на сторону сервера: приложение упало во время обработки запроса, правило намеренно обрывает соединения или служба приняла соединение, но за ней ничего не было. Впрочем, несколько причин на вашем компьютере тоже могут её вызвать.

Причины ERR_EMPTY_RESPONSE

Решение 1: перезагрузите страницу и откройте режим инкогнито

Если сервер перезапустился в неудачный момент, достаточно обновить страницу через несколько секунд. Если ошибка повторяется, откройте страницу в окне инкогнито (Ctrl + Shift + N, на Mac — Cmd + Shift + N). Режим инкогнито запускается без cookie и без расширений, поэтому быстро показывает, замешано ли что-то, сохранённое в браузере.

Затем проверьте, не лежит ли сайт у всех. Инструмент HTTP Headers от DNS Robot запрашивает страницу с наших серверов: если мы получаем нормальный ответ, проблема где-то между вами и сайтом. Если и мы ничего не получаем, сбоит сам сайт.

Решение 2: выключите VPN, прокси и проверку HTTPS

Всё, что стоит посередине ваших соединений, может принять запрос, а затем закрыть его, не передав ответ обратно:

• VPN: полностью отключите его и обновите страницу.

• Прокси: в Windows 11 — Параметры → Сеть и Интернет → Прокси-сервер → выключите Использовать прокси-сервер. На Mac — Системные настройки → Сеть → ваше подключение → Подробнее… → Прокси.

• Проверка HTTPS в антивирусе: выключите только функцию проверки веб-трафика или HTTPS (она часто называется проверка HTTPS, веб-экран (Web Shield) или фильтрация протоколов SSL/TLS) и обновите страницу. Если это помогло, добавьте сайт в исключения и включите проверку обратно.

Решение 3: очистите данные сайта и отключите расширения

Очень большие или повреждённые cookie могут заставить сервер оборвать запрос вместо ответа — часто это проявляется как ошибка, возникающая только после входа в аккаунт. Очистите cookie этого сайта: нажмите значок слева от адресной строки → Файлы cookie и данные сайтов (или Настройки сайтов) → удалите данные и войдите снова.

Затем отключите все расширения на странице chrome://extensions и обновите страницу. Включайте их по одному, чтобы найти мешающее, — чаще всего это блокировщик рекламы, инструмент приватности или что-то, что редактирует запросы.

Решение 4: очистите DNS-кеш и сбросьте сетевой стек

Если на одном компьютере пустые ответы дают все сайты, сбросьте его сетевую конфигурацию. В Windows выполните команды ниже в командной строке от имени администратора и перезагрузите компьютер. На Mac очистите DNS-кеш, удалите сеть Wi-Fi и добавьте её заново.

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

Также попробуйте другую сеть, например мобильный интернет на телефоне. Если там сайт работает, соединение может обрывать фильтр в вашей обычной сети (в школе, на работе или у провайдера).

ERR_EMPTY_RESPONSE на localhost и в Docker

Разработчики чаще всего видят эту ошибку на собственной машине. Обычные причины:

• Приложение в Docker-контейнере слушает 127.0.0.1. Внутри контейнера 127.0.0.1 означает «только этот контейнер», поэтому пробросу порта Docker не к чему подключиться, и браузер получает пустой ответ (или, в зависимости от настройки, сброс соединения). Заставьте приложение слушать 0.0.0.0 внутри контейнера, например next dev -H 0.0.0.0, vite --host 0.0.0.0, flask run --host=0.0.0.0 или uvicorn main:app --host 0.0.0.0.

• Не совпадает проброс портов контейнера. -p 8080:3000 перенаправляет ваш порт 8080 на порт 3000 внутри контейнера. Если приложение на самом деле слушает 5000, каждый запрос возвращается пустым.

• http:// на порту, который принимает только HTTPS. Некоторые серверы ожидают на порту TLS и просто кладут трубку, когда приходит обычный HTTP. Попробуйте https://localhost:8443 вместо http://.

• Dev-сервер упал во время обработки запроса. Посмотрите терминал, в котором он запущен. Исключение или ошибка нехватки памяти в этот момент — ваш ответ.

# Воспроизведите без браузера
curl -v http://localhost:8080/
# "Empty reply from server" = соединение принято, в ответ ничего не отправлено

# Какие порты публикует контейнер и что слушает внутри него?
docker ps --format "table {{.Names}}\t{{.Ports}}"
docker exec -it <container> sh -c "netstat -tlnp 2>/dev/null || ss -tlnp"

Владельцам сайтов: почему сервер отправляет пустые ответы

• Падения и завершение процессов из-за нехватки памяти. Если процесс, обрабатывающий запрос, умирает, соединение закрывается, так ничего и не отправив. Проверьте логи приложения и dmesg -T | grep -i "killed process" на предмет срабатывания OOM killer в Linux, особенно на тяжёлых страницах и при загрузке файлов.

• Намеренные обрывы. Специальная директива nginx return 444; закрывает соединение без какого-либо ответа, и её часто используют, чтобы блокировать вредных ботов или неизвестные имена хостов. Если такое правило срабатывает на реальных посетителей (слишком широкое правило по user agent или GeoIP), они видят ERR_EMPTY_RESPONSE, а на соединениях HTTP/2 — ERR_HTTP2_PROTOCOL_ERROR, потому что там nginx вместо этого сбрасывает поток. WAF, ограничители запросов и сервисы защиты от ботов могут делать то же самое.

• Проброс портов и балансировщики без бэкенда. Слушатель, который принимает соединение, но за которым нет работающего сервера, может закрыть его пустым. Проверьте состояние целевых серверов и то, что порт бэкенда совпадает.

• Таймауты, которые закрывают соединение вместо ответа. Пусть долгие запросы возвращают нормальную ошибку (например, 504), а не молча закрывают сокет — тогда посетители и мониторинг увидят, что произошло.

• Слишком большие запросы. Очень большие заголовки или cookie могут заставить некоторые серверы оборвать запрос. Держите cookie маленькими.

# Есть ли правила, которые обрывают соединения?
sudo grep -rn "return 444" /etc/nginx/

# Проверьте снаружи — так, как подключаются посетители
curl -sv https://yourdomain.com/ -o /dev/null

ERR_EMPTY_RESPONSE и похожие ошибки: в чём разница

Связанные руководства: ERR_CONNECTION_CLOSED, ERR_CONNECTION_RESET, 502 Bad Gateway и 500 Internal Server Error. Чтобы проверить, принимает ли порт сервера соединения извне, воспользуйтесь Port Checker.