ERR_CONNECTION_CLOSED означает, что удалённый сервер оборвал TCP-соединение до того, как браузер получил ответ. Chrome отправил запрос, но вместо данных пришёл сброс (TCP RST) или тишина. Причина почти всегда на стороне сервера, файрвола, антивируса или проблемной сети, реже — в самом браузере.
Это руководство разбирает все источники ошибки: сервер закрыл соединение, антивирус и прокси режут трафик, сбои сети и MTU, сброс TLS-handshake, перегрузку и падение сервера. Ниже — как локализовать проблему за 5 минут и что править пользователю и администратору, с командами curl, chrome://net-internals и анализом логов nginx.
Что означает ERR_CONNECTION_CLOSED
Ошибка относится к сетевому слою Chromium (код net::ERR_CONNECTION_CLOSED). Она возникает, когда соединение было установлено или устанавливалось, но противоположная сторона закрыла его без корректного HTTP-ответа. На уровне TCP это обычно пакет RST (reset) вместо ожидаемого ACK с данными. В отличие от ERR_CONNECTION_REFUSED, где проверку портов вообще не слушает, здесь соединение доходит до сервера, но обрывается на полпути.
Важно отличать эту ошибку от соседних. ERR_CONNECTION_RESET — соединение сброшено уже в процессе передачи данных. ERR_CONNECTION_TIMED_OUT — ответа не было вовсе в отведённое время. ERR_CONNECTION_CLOSED — сервер активно завершил сессию. Диагностика для них частично пересекается, но корневые причины разные.
Причины ERR_CONNECTION_CLOSED
Удобнее разложить причины по слоям: клиент, сеть и сервер. Так проще понять, где искать. В таблице ниже — типовые источники и признаки каждого.
| Слой | Причина | Как проявляется |
|---|---|---|
| Клиент | Антивирус или файрвол режет SSL/TLS проверку-инспекцию | Ошибка только на одном ПК, в инкогнито тоже воспроизводится |
| Клиент | Битый профиль Chrome, расширения, кэш socket pool | Другой браузер открывает сайт нормально |
| Клиент | Некорректный системный прокси или VPN | Отключение прокси/VPN устраняет ошибку |
| Сеть | Проблема MTU/фрагментации, потеря пакетов | Ошибка при большом ответе, стабильна на маленьких |
| Сеть | Провайдер или корпоративный шлюз сбрасывает сессию | С мобильного интернета сайт работает, с Wi-Fi — нет |
| Сервер | Падение или перезапуск бэкенда (PHP-FPM, Node) | Ошибка у всех пользователей, в error.log есть записи |
| Сервер | Сброс TLS-handshake, устаревший протокол/шифр | HTTP работает, HTTPS обрывается |
| Сервер | Лимиты keepalive, worker_connections, OOM-killer | Обрывы под нагрузкой, в пиковые часы |
Сервер закрыл соединение (TCP RST)
Самый частый сценарий. Веб-сервер или его апстрим (PHP-FPM, приложение) аварийно завершил обработку и отправил RST. Причины: сегфолт процесса, превышение fastcgi/proxy таймаутов, нехватка памяти и срабатывание OOM-killer, ошибка в конфиге апстрима. Браузер видит только факт закрытия, детали — в логах сервера.
Антивирус, файрвол и прокси
Многие антивирусы (Kaspersky, ESET, Avast) перехватывают HTTPS для проверки трафика, подменяя сертификат. Если их модуль веб-защиты конфликтует с сайтом или устаревшим TLS, соединение обрывается. Корпоративные прокси и SSL-инспекция на шлюзе делают то же самое. Признак — ошибка воспроизводится только за конкретной сетью или на защищённом ПК.
Проблемы сети и MTU
Если ответ сервера большой, а на маршруте есть звено с меньшим MTU и запрещённой фрагментацией (blackhole PMTUD), крупные пакеты теряются, и соединение виснет и обрывается. Такое чаще встречается на VPN, PPPoE и туннелях. Маленькие страницы открываются, тяжёлые — нет.
Сброс TLS-handshake
Если сервер поддерживает только устаревшие протоколы (TLS 1.0/1.1) или несовместимый набор шифров, современный Chrome может получить сброс во время рукопожатия. То же бывает при неверной конфигурации SNI, отсутствии промежуточного сертификата или строгих настройках безопасности на балансировщике.
Как понять, где проблема
Прежде чем что-то править, локализуйте источник. Пройдите по чек-листу — он за пару минут отделит клиента от сервера:
- Другой браузер — если Firefox или Edge открывают сайт, проблема в профиле/расширениях Chrome.
- Режим инкогнито — исключает расширения и часть кэша.
- Другое устройство в той же сети — если ошибка и там, дело в сети или сервере, не в вашем ПК.
- Другая сеть (мобильный интернет вместо Wi-Fi) — если помогает, режет провайдер или локальный шлюз.
- Серверные логи — если ошибка у всех, смотрите error.log веб-сервера.
Точную сетевую картину даёт встроенный инструмент Chrome. Откройте события соединений:
chrome://net-internals/#events
# в старых версиях — chrome://net-export/ для записи лога
# сброс кэша сокетов и хостов без перезапуска браузера:
chrome://net-internals/#sockets -> Flush socket pools
chrome://net-internals/#dns -> Clear host cacheИз терминала быстрее всего проверить поведение сервера напрямую, минуя браузер и его расширения:
curl -v https://example.com/
# смотрим, на каком этапе обрыв:
# * Connected to ... — TCP есть
# * TLSv1.3 handshake ... — если тут reset, проблема в TLS
# * curl (56) Recv failure — сервер закрыл соединение
# отдельно проверить только TLS-рукопожатие:
openssl s_client -connect example.com:443 -servername example.comКак исправить пользователю
Если ошибка только у вас, идите от простого к сложному:
- Перезагрузите страницу и роутер — часть обрывов лечится сбросом сессии.
- Временно отключите модуль веб-/HTTPS-защиты антивируса и проверьте снова.
- Отключите VPN, системный прокси и подозрительные расширения Chrome.
- Очистите кэш сокетов и DNS через
chrome://net-internals(см. выше). - Сбросьте сетевой стек Windows командами ниже и перезагрузитесь.
# Windows — сброс сетевого стека и DNS:
ipconfig /flushdns
netsh winsock reset
netsh int ip reset
# затем перезагрузка
# проверка системного прокси (не должно быть чужого адреса):
netsh winhttp show proxyЕсли после этого сайт открывается в другом браузере, но не в Chrome, создайте новый профиль Chrome или сбросьте настройки. Битый socket pool и повреждённые данные профиля — частая причина «ошибки только в Chrome».
Как исправить на сервере
Если ошибка воспроизводится у всех и из curl, проблема на сервере. Начните с логов — они укажут точную причину обрыва.
# nginx — ищем сброс апстрима и таймауты:
tail -f /var/log/nginx/error.log
# типовые строки:
# upstream prematurely closed connection
# recv() failed (104: Connection reset by peer)
# upstream timed out (110: Connection timed out)
# состояние апстрима PHP-FPM:
systemctl status php-fpm
journalctl -u php-fpm --since "10 min ago"Дальше действуйте по найденной причине:
- Падение апстрима — проверьте
dmesg | grep -i oomна срабатывание OOM-killer, поднимите лимиты памяти PHP-FPM/приложения, устраните фатальные ошибки. - Таймауты — согласуйте
fastcgi_read_timeout/proxy_read_timeoutв nginx с реальным временем ответа бэкенда. - Keepalive и лимиты — проверьте
worker_connections,keepalive_timeoutи лимиты пула воркеров, если обрывы идут под нагрузкой. - TLS — включите TLS 1.2/1.3, актуальный набор шифров, добавьте промежуточный сертификат в цепочку.
Как проверить
Убедиться, что сервер снова отвечает корректными заголовками и не рвёт соединение, можно нашими инструментами. Запустите HTTP-проверку заголовков — она покажет статус-код, редиректы и анализ заголовков ответа без влияния вашего антивируса и расширений. Для оценки TLS и заголовков безопасности используйте сканер безопасности: он выявит устаревший протокол, неполную цепочку сертификата и другие причины сброса handshake.
Смежные ошибки соединения
ERR_CONNECTION_CLOSED редко приходит одна — рядом обитают похожие ошибки с другими корневыми причинами. Полезно разобрать и их:
- ERR_CONNECTION_REFUSED: порт не слушает
- ERR_CONNECTION_RESET: сброс в процессе передачи
- ERR_CONNECTION_TIMED_OUT: нет ответа вовремя
Частые вопросы
ERR_CONNECTION_CLOSED — это проблема на моей стороне или на сервере?
Проверьте сайт в другом браузере, в режиме инкогнито и с другого устройства в той же сети. Если ошибка исчезает где-то из них — проблема локальная: антивирус, расширения, прокси или профиль Chrome. Если сайт не открывается везде и из curl, причина на сервере или в сети провайдера.
Почему сайт открывается с телефона, но не с компьютера?
Скорее всего, на компьютере активен модуль HTTPS-инспекции антивируса, системный прокси или VPN, который рвёт соединение. Телефон в мобильной сети идёт другим маршрутом без этих посредников. Отключите защиту веб-трафика и прокси на ПК и проверьте снова.
Может ли антивирус вызывать ERR_CONNECTION_CLOSED?
Да, и это одна из самых частых причин. Антивирусы перехватывают HTTPS для проверки, подменяя сертификат. При конфликте с сайтом или устаревшим TLS соединение обрывается. Временно отключите веб-защиту антивируса: если ошибка ушла — настройте исключение для нужного домена.
Чем ERR_CONNECTION_CLOSED отличается от ERR_CONNECTION_RESET?
При CLOSED сервер завершает соединение, часто до передачи полезных данных или в момент рукопожатия. При RESET соединение сбрасывается уже в процессе обмена данными пакетом RST. Причины частично совпадают (сеть, файрвол, сервер), но RESET чаще связан с активным вмешательством посредника в поток.
Как посмотреть, что именно рвёт соединение?
Запустите curl -v https://ваш-сайт/ и смотрите, на каком этапе обрыв: до TLS, во время handshake или при получении данных. Параллельно откройте chrome://net-internals/#events. На сервере читайте error.log nginx — строки про premature close и connection reset укажут источник.
Помогает ли очистка кэша и сброс сети?
Часто да, если причина локальная. Очистите кэш сокетов и DNS в chrome://net-internals, выполните ipconfig /flushdns и netsh winsock reset, перезагрузитесь. Это устраняет застрявшие соединения и повреждённый socket pool. Если ошибка серверная, сброс на клиенте не поможет — правьте конфигурацию сервера.
Источники: MDN: HTTP-статусы и семантика, Chromium: сетевое логирование и net-error коды.