ERR_CONNECTION_RESET: причины и решения

2026-09-19

ERR_CONNECTION_RESET означает, что работавшее соединение было резко оборвано на полпути, обычно файрволом, защитным ПО или сбоем на стороне сервера, а не штатным закрытием той или иной стороной.

Что означает ERR_CONNECTION_RESET

В отличие от ERR_CONNECTION_REFUSED, которая срабатывает еще до того, как пошли какие-либо данные, сброс происходит уже после того, как TCP-рукопожатие прошло успешно и соединение уже обменивалось данными. Затем что-то по пути следования, либо одна из конечных точек, отправляет пакет RST, завершающий соединение без обычной последовательности закрытия. Браузер никак не может определить, пришел ли RST от сервера, от промежуточного устройства вроде файрвола или балансировщика нагрузки, либо от собственного сетевого стека клиента, поэтому сообщение остается общим независимо от причины.

Обычное закрытие TCP включает обмен пакетами FIN в обе стороны, что позволяет каждой стороне завершить отправку того, что уже стояло в очереди. RST полностью пропускает это: все, что было в пути, отбрасывается, а любые данные, которые сервер уже начал записывать, но клиент еще не получил, теряются. Именно поэтому сброс на полпути большой загрузки файла или долгого ответа API часто оставляет заметно обрезанный результат, а не чистый сбой до того, как что-либо загрузилось.

Как проявляется ошибка

Chrome показывает "This site can't be reached ... ERR_CONNECTION_RESET" в процессе загрузки, иногда уже после того, как часть страницы отрисовалась. curl сообщает об этом прямо:

curl -v https://example.com/api/report
* TLSv1.2 (IN), TLS alert, close notify
* OpenSSL SSL_read: Connection reset by peer, errno 104
curl: (56) Recv failure: Connection reset by peer

На стороне сервера nginx логирует соответствующую строку для того же события: readv() failed (104: Connection reset by peer) while reading upstream. Сброс, стабильно происходящий на одном и том же количестве байт или на одной и той же секунде запроса, указывает на лимит размера или таймаута где-то на пути, а не на случайный сетевой сбой.

Что вызывает ERR_CONNECTION_RESET

Файрвол, IDS или WAF обрывает соединение посреди потока. Правило, сработавшее уже в процессе запроса или ответа, а не в момент установки соединения, дает сброс вместо немедленного отказа.
Проблемы с MTU или фрагментацией пакетов. Путь с меньшим MTU, чем ожидает та или иная конечная точка, может повредить крупные пакеты, а некоторые неправильно настроенные маршрутизаторы в ответ сбрасывают соединение вместо того, чтобы корректно фрагментировать его.
Проверка TLS антивирусным ПО или корпоративным прокси. Перехват, проваливающийся на полпути рукопожатия или ответа, часто сбрасывает соединение вместо аккуратного отказа.
Воркер-процесс сервера падает посреди запроса. Ошибка приложения, уничтожение из-за нехватки памяти или перезапуск воркера во время деплоя - все это оставляет открытое соединение, на которое больше некому отвечать.
Несовпадение таймаута keep-alive между клиентом и сервером или прокси. Если таймаут простоя у балансировщика нагрузки короче, чем у бэкенда, он может сбросить соединение, которое бэкенд все еще считает активным.
Вмешательство провайдера или формирование трафика. Некоторые провайдеры сбрасывают долгоживущие или высокоскоростные соединения, особенно для стриминга или крупных загрузок, в рамках управления трафиком.

Как понять, кто виноват

Проверьте тот же запрос из другой сети, например с мобильного интернета вместо офисного Wi-Fi. Если там все работает, соединение перехватывает локальный файрвол, антивирус или прокси. Если сброс происходит одинаково повсюду, причина лежит на стороне сервера либо в правиле WAF перед ним. HTTP-проверка, запущенная сразу из нескольких мест, покажет, является ли сброс общим или ограничен одной сетью, без необходимости искать второе устройство для теста.

Как исправить ERR_CONNECTION_RESET

Если вы посетитель

Перезапустите маршрутизатор или модем. Зависшая запись в таблице NAT или устаревшее состояние соединения на бытовых маршрутизаторах - частая и легко устранимая причина.
Отключите любой VPN или прокси и перезагрузите страницу. Если сброс прекращается, значит VPN или прокси перехватывает или неправильно обрабатывает соединение.
Отключите сканирование HTTPS в антивирусе, обычно указанное как "веб-защита" или "сканирование SSL/TLS", и повторите попытку. Если это помогло, добавьте сайт в список исключений, а не оставляйте сканирование выключенным.
Проверьте, не выставлено ли необычно низкое значение MTU, если вы используете VPN или мобильную точку доступа; небольшое понижение MTU на клиенте может устранить сбросы, связанные с фрагментацией.

Если вы администрируете сайт

Проверьте логи приложения и системы на предмет падения или уничтожения из-за нехватки памяти примерно в момент сброса. Гибель воркер-процесса посреди запроса - одна из самых частых причин.
Просмотрите правила WAF и IDS и их логи. Правило, сбрасывающее соединения при совпадении определенных данных или частоты запросов, может выглядеть в точности как случайный сетевой сбой, пока вы специально не проверите лог безопасности.
Согласуйте таймауты keep-alive по всему стеку. В nginx выставьте таймаут со стороны прокси равным или выше собственного таймаута бэкенда:
```
keepalive_timeout 65s;
proxy_read_timeout 65s;
```
Несовпадение здесь - частая причина сбросов под нагрузкой, когда фронтенд закрывает соединение, которое бэкенд еще рассчитывает использовать.
Следите за сообщениями о сбросе upstream в логе обратного прокси, вроде upstream prematurely closed connection while reading response header from upstream, которое указывает прямо на приложение-бэкенд, а не на сеть.
После любого изменения перезагружайте, а не редактируйте на лету: nginx -t && systemctl reload nginx проверяет конфигурацию перед тем, как она вступит в силу.

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

Сброс, появляющийся только под нагрузкой или только для крупных ответов, редко проявляется при быстрой ручной проверке, поскольку зависит от порогов времени или размера, которые единичный запрос может не задеть. Постоянный мониторинг HTTP, проверяющий код состояния и содержимое тела по расписанию из 300+ контрольных точек в 158 городах, ловит прерывистый паттерн сброса, который пропустил бы разовый тест, и оповещает по email, SMS, голосовым звонком, через Slack, Telegram и другие каналы, как только это начинает происходить.

Часто задаваемые вопросы

Означает ли ERR_CONNECTION_RESET, что меня взломали?

Нет. Это почти всегда указывает на сетевое устройство, правило файрвола, перехват антивирусом или сбой на стороне сервера, а не на атаку на ваше устройство.

Почему это происходит только при загрузке крупных файлов?

Крупные передачи с большей вероятностью упираются в несовпадение MTU, таймаут прокси или лимит размера, настроенный на файрволе или балансировщике нагрузки, - все это может оборвать соединение посреди потока, тогда как маленький запрос успел бы завершиться, не задев эти пороги.

Может ли это вызвать мой собственный антивирус?

Да. Функции сканирования HTTPS, перехватывающие и заново шифрующие TLS-трафик, иногда сбоят на конкретных сайтах или крупных ответах и сбрасывают соединение вместо того, чтобы пропустить его насквозь.

Хуже ли сброс, чем таймаут?

Не обязательно. Сброс означает, что что-то активно завершило соединение, что часто легче диагностировать, чем таймаут, где ничего не происходит и невозможно понять, дошел ли пакет вообще.

Почему сброс происходит каждый раз в одном и том же месте?

Стабильное количество байт или прошедшее время до сброса обычно указывает на фиксированный лимит - например, таймаут прокси, максимальный размер ответа или настройку keep-alive, - а не на случайный сбой.

Может ли мобильный оператор сбрасывать мои соединения?

Некоторые операторы действительно сбрасывают долгоживущие соединения в рамках управления сетью, особенно на перегруженных сотах или для высокоскоростных передач вроде видеостриминга. Если один и тот же запрос стабильно работает по Wi-Fi, но сбрасывается на мобильном интернете, вмешательство на уровне оператора - разумное объяснение.