ERR_EMPTY_RESPONSE значит, что сервер принял запрос и закрыл соединение, ничего не ответив. Ни кода ошибки, ни заголовков, ни страницы — ноль байт. Chrome показывает «Страница недоступна. Сайт не отправил данных». Мы подняли стенд с сервером, который закрывает соединение по-разному, и nginx, проверили девять вариантов в Chromium 149 и разбираем, что из них даёт эту ошибку, а что — другую.
Отвечает ли сайт вообще, можно проверить нашим сервисом проверки доступности: он запрашивает страницу со своего сервера и показывает код ответа и время отклика.
Что означает ошибка
Браузер открывает соединение с сервером, отправляет запрос и ждёт ответ. Ответ начинается со строки статуса — например, «HTTP/1.1 200 OK». При ERR_EMPTY_RESPONSE до этой строки дело не доходит: сервер закрывает соединение штатно, не прислав ни одного байта.
В исходниках Chromium, в файле net_error_list.h, у ошибки номер -324 и описание «The server closed the connection without sending any data». Это отличает её от соседних кодов:
| Код | Что произошло |
|---|---|
| ERR_EMPTY_RESPONSE (-324) | соединение закрыто штатно, ответа не было |
| ERR_CONNECTION_RESET (-101) | соединение сброшено пакетом RST |
| ERR_CONNECTION_CLOSED (-100) | соединение закрыто посреди обмена |
| ERR_INVALID_HTTP_RESPONSE (-370) | сервер прислал что-то, но не ответ HTTP |
| 502, 503, 504 | ответ пришёл, это код ошибки от сервера или прокси |
Раз браузер дошёл до отправки запроса, адрес сайта найден, соединение установлено, а для HTTPS ещё и сертификат принят. Значит, DNS и сертификат ни при чём.
Стенд: девять вариантов «ничего не прислал»
Мы написали сервер, который на каждом порту ведёт себя по-своему, и подняли рядом nginx 1.22. Открывали адреса в Chromium 149 и проверяли curl 7.88.
| Что сделал сервер | Chromium | curl |
|---|---|---|
| Принял запрос и закрыл соединение | ERR_EMPTY_RESPONSE | (52) Empty reply from server |
| То же по HTTPS | ERR_EMPTY_RESPONSE | (52) |
| Молчал 30 секунд, потом закрыл | ERR_EMPTY_RESPONSE через 60 секунд | (52) |
nginx return 444 по HTTP/1.1 | ERR_EMPTY_RESPONSE | (52) |
nginx return 444 по HTTP/2 | ERR_HTTP2_PROTOCOL_ERROR | (92) PROTOCOL_ERROR |
| Принял запрос и сбросил соединение (RST) | ERR_CONNECTION_RESET | (56) Connection reset by peer |
| Закрыл соединение, не дочитав запрос | от прогона к прогону разное: ERR_CONNECTION_RESET, ERR_SOCKET_NOT_CONNECTED | (56) |
| Прислал мусор вместо ответа | ERR_INVALID_HTTP_RESPONSE | (1) HTTP/0.9 |
| nginx перед бэкендом, который закрыл соединение молча | ответ 502 Bad Gateway | 502 |
Что из этого следует.
Пустой ответ — это закрытие без единого байта. Как только сервер сбрасывает соединение вместо штатного закрытия, ошибка становится ERR_CONNECTION_RESET. Как только присылает хоть что-то непохожее на ответ — ERR_INVALID_HTTP_RESPONSE.
Закрытие до чтения запроса — лотерея. Если сервер закрывает соединение раньше, чем прочитал запрос, исход зависит от того, что успеет раньше. В стенде к статье ERR_CONNECTION_RESET такой случай дал пустой ответ, у нас — сброс.
Chromium повторяет запрос сам. На сервер, который молчал 30 секунд и закрывал соединение, браузер пришёл дважды, с интервалом 30 секунд, и показал ошибку только через минуту. Поэтому при этой ошибке страница обычно «долго грузится», а потом падает.
nginx перед приложением прячет пустой ответ за 502. Если упало приложение за прокси, посетитель увидит 502, а не ERR_EMPTY_RESPONSE. В журнале nginx при этом строка «upstream prematurely closed connection while reading response header from upstream». Пустой ответ браузер получает, когда соединение закрывает тот, с кем он говорит напрямую: сам nginx, защита от ботов, балансировщик, приложение без прокси.
Код 444 по HTTP/2 выглядит иначе. nginx не может просто закрыть соединение, по которому идут другие запросы, и сбрасывает только поток. Chrome показывает ERR_HTTP2_PROTOCOL_ERROR. Так что одно и то же правило даёт разные ошибки в зависимости от протокола.
Наш замер: пустой ответ на живых сайтах
17.10.2026 мы запросили главные страницы 2056 сайтов организаций Екатеринбурга по HTTPS и по HTTP. По HTTPS ответили 1624 сайта, по HTTP — 1718. Пустой ответ хотя бы по одному адресу дали 4 сайта.
- Три сайта закрывали соединение только для curl. По HTTP они молчали на запрос с заголовком User-Agent от curl и отвечали перенаправлением 301 на HTTPS, когда заголовок был как у Chrome. Все три отдают «Server: nginx/1.18.0» — фильтр по User-Agent на одной настройке. Посетитель в браузере ошибки не видит, а сервисы проверки и скрипты получают пустой ответ.
- Один сайт молчал для всех. По HTTP пустой ответ приходил и с заголовком браузера, три раза подряд; Chromium показал ERR_EMPTY_RESPONSE за 316 мс. По HTTPS Chromium до запроса не дошёл: сертификат сайта выдан не доверенным центром.
Вывод для владельца: если ваш сайт проверяют сервисы и не видят его, а в браузере всё открывается, первым делом проверьте фильтры по User-Agent.
Чем отличается от 502 и 504
В отличие от ERR_EMPTY_RESPONSE, ошибки 502 и 504 — это ответы. Их отправляет прокси или балансировщик, когда сервер за ним не справился: 502 — бэкенд ответил неправильно или закрыл соединение, 504 — не ответил вовремя. Браузер получает страницу с кодом и содержимым, и пользователи видят сообщение от сервера, а не от Chrome.
ERR_EMPTY_RESPONSE браузер пишет сам, потому что данных не пришло вовсе. Ситуация обратная: ответить было некому или тот, кто должен был ответить, решил промолчать. На стенде одна и та же поломка бэкенда за nginx дала 502, а без nginx — пустой ответ.
Почему возникает ошибка
На стороне сайта:
- Правило, закрывающее соединение. В nginx это
return 444: документация называет его нестандартным кодом, который «closes a connection without sending a response header» — закрывает соединение, не отправив заголовок ответа. Так часто отсекают запросы к неизвестному домену, ботов и запросы без нужного заголовка Host. - Защита от ботов и WAF. Фильтры трафика отсекают подозрительные запросы без ответа, чтобы не тратить ресурсы. Под правило могут попасть обычные посетители: целые подсети, страны, старые браузеры.
- Падение процесса. Приложение, которое слушает порт напрямую, упало посреди обработки запроса или было убито из-за нехватки памяти.
- Таймаут на балансировщике. Промежуточный сервер ждал ответа дольше своего предела и закрыл соединение молча.
На стороне посетителя:
- VPN или прокси, который не смог связаться с сайтом и закрыл соединение с браузером;
- антивирус с проверкой HTTPS, который встаёт между браузером и сайтом;
- фильтр на рабочем компьютере, который закрывает соединения с запрещёнными сайтами.
Пошаговая проверка: кто виноват
Проверяйте в таком порядке и после каждого шага пробуйте открыть сайт заново.
- Обновите страницу. Разовый сбой на этом закончится, и перезагрузка компьютера не понадобится.
- Откройте сайт с телефона через мобильный интернет или с другого компьютера. Ошибка везде — проблема на стороне сайта.
- Ошибка только у вас — выключите по одному VPN, прокси и проверку HTTPS в антивирусе.
- Откройте сайт в режиме инкогнито: в нём по умолчанию отключены расширения. Удалось открыть — причина в расширении.
- Если сайт не открывается только с рабочего компьютера, обратитесь к администратору сети.
Как исправить ошибку посетителю
Отключить VPN и прокси
Если VPN-сервер не может соединиться с сайтом, он закрывает соединение с браузером, и Chrome видит пустой ответ. Отключите VPN и обновите страницу. Если сайт открылся, ошибка вызвана VPN: попробуйте другой сервер VPN или включите его обратно только для тех сайтов, где он нужен. Проверьте и прокси в настройках системы: в Windows — «Параметры» → «Сеть и Интернет» → «Прокси».
Отключить проверку HTTPS в антивирусе
Антивирусы с проверкой защищённых соединений сами открывают соединение с сайтом и отдают ответ браузеру. Если у них что-то пошло не так, браузер получает пустое соединение. Выключите проверку на время и обновите страницу; если помогло — добавьте сайт в исключения.
Окно инкогнито и расширения
В окне инкогнито расширения по умолчанию отключены и нет ваших cookie. Если там сайт открылся, по одному выключайте расширения в обычном окне: блокировщики рекламы, VPN-расширения, расширения, которые меняют запросы.
Удалить cookie сайта
Защита от ботов иногда закрывает соединение из-за cookie, которую сама поставила раньше. Удалите cookie только этого сайта через значок слева от адреса — очистить всю историю и данные браузера незачем. Если доступ заблокирован фильтром по адресу, это не изменится: ошибка будет и после очистки.
Сообщить владельцу сайта
Если вы пытаетесь открыть чужой сайт, сделать больше, чем описано выше, вы не можете.
Если ошибка повторяется с разных устройств и сетей, исправить её может только владелец. Сообщите адрес страницы, время и свой IP-адрес — по нему владелец найдёт запись в журналах.
Сбрасывать DNS-кэш и сетевые настройки при этой ошибке не нужно: раз запрос дошёл до сервера, адрес найден и соединение установлено.
Как исправить владельцу сайта
Воспроизвести запрос
curl -sv -o /dev/null https://example.ru/
curl -sv -o /dev/null -A "Mozilla/5.0" https://example.ru/
Пустой ответ curl показывает как «(52) Empty reply from server». Если с заголовком браузера ответ есть, а без него нет, соединения закрывает фильтр по заголовку User-Agent.
Найти запись в журнале
- Журнал доступа nginx. nginx записывает закрытые по
return 444запросы с кодом 444. Найдите строку с адресом и временем жалобы и посмотрите, какое правило сработало. - Журнал ошибок приложения и системы. Если процесс упал или его убил механизм нехватки памяти, это видно там, а не в журнале веб-сервера.
- Журналы защиты и балансировщика. Если перед сайтом CDN или фильтр, ищите блокировки там.
Что поправить
- Безопасность не должна ломать доступ людям. Правила с кодом 444 должны срабатывать только на то, что действительно не нужно: запросы к чужим доменам, к несуществующим путям вроде /wp-login.php на сайте без WordPress. Проверьте, не попали ли под них обычные посетители.
- Если приложение слушает порт напрямую, поставьте перед ним прокси: при падении посетитель получит 502 с понятной страницей вместо пустого ответа, а вы — строку в журнале.
- Сверьте таймауты балансировщика и приложения: долгие запросы не должны обрываться посередине.
Как убедиться, что ошибка устранена
После правки конфигурации проверьте главную и несколько внутренних страниц тремя способами: curl без заголовка браузера, curl с заголовком браузера и сам браузер с другого подключения, например с телефона. Чаще всего ошибка остаётся у некоторых пользователей, потому что правило защиты срабатывает не на всех.
Чтобы узнать о следующем сбое прежде клиентов, помогут сервисы мониторов доступности: они запрашивают сайт раз в несколько минут и присылают сообщение, если ответа нет. Учтите, что при использовании мониторов с заголовком не как у браузера фильтр по User-Agent может закрывать соединение и для них — работа фильтра тогда видна как пустой ответ, хотя сайт для людей работает.
Похожие ошибки
- ERR_CONNECTION_CLOSED — соединение закрыто посреди обмена.
- ERR_CONNECTION_RESET — соединение сброшено пакетом RST; на стенде её давал сервер, который сбрасывал соединение вместо штатного закрытия.
- ERR_HTTP2_PROTOCOL_ERROR — то же правило 444, но по HTTP/2.
- Ошибка 502 — прокси получил от бэкенда пустой ответ и сообщил об этом кодом.
- Ошибка 413 — сервер отказался принять слишком большой файл или форму и ответил кодом, а не молчанием.
Границы замера
- Стенд — Chromium 149 и curl 7.88 на Linux, nginx 1.22, всё на одной машине. Другие веб-серверы, CDN и фильтры могут вести себя иначе.
- Edge, Opera, Яндекс Браузер не проверяли: у них движок Chromium, но поведение версий может отличаться.
Коротко
- ERR_EMPTY_RESPONSE — сервер принял запрос и штатно закрыл соединение, не прислав ни байта.
- Сброс соединения даёт ERR_CONNECTION_RESET, мусор вместо ответа — ERR_INVALID_HTTP_RESPONSE, правило 444 по HTTP/2 — ERR_HTTP2_PROTOCOL_ERROR.
- Chromium повторяет запрос один раз, поэтому ошибка часто появляется после долгой загрузки.
- Посетителю: обновить, проверить с телефона, отключить VPN, прокси и проверку HTTPS в антивирусе.
- Владельцу: curl, журнал доступа nginx на код 444, журналы приложения и защиты.