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

ERR_CONNECTION_TIMED_OUT — это браузерная ошибка, которая означает: браузер попытался подключиться к сайту, но не дождался ответа за отведённое время. Чаще всего её видят в Chrome и браузерах на Chromium, но смысл одинаковый для всех клиентов: соединение зависло на одном из этапов — DNS, TCP, TLS, прокси, CDN, балансировщик, веб-сервер или само приложение.

Для пользователя это выглядит просто: страница долго грузится, затем появляется сообщение «Сайт не отвечает» или «Время ожидания ответа истекло». Для владельца сайта такая ошибка опаснее обычной «медленной загрузки»: часть аудитории может вообще не попасть на сайт, а в логах приложения при этом иногда ничего не будет, потому что запрос не дошёл до backend.

Разберём, что означает ERR_CONNECTION_TIMED_OUT, чем эта ошибка отличается от ERR_CONNECTION_REFUSED и 504 Gateway Timeout, как проверить проблему со стороны пользователя и как диагностировать её на сервере.

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

Ошибка ERR_CONNECTION_TIMED_OUT появляется, когда браузер не получил ответ в пределах таймаута. Таймаут — это ограничение по времени: клиент не может ждать бесконечно, поэтому через некоторое время прерывает попытку и показывает ошибку.

Упрощённо открытие сайта проходит несколько этапов:

1) DNS-разрешение — браузер узнаёт IP-адрес домена. Например, example.com превращается в 93.184.216.34.

2) TCP-соединение — клиент отправляет SYN на IP и порт, обычно 80 или 443, и ждёт ответа SYN-ACK.

3) TLS-рукопожатие — для HTTPS браузер договаривается с сервером о шифровании и проверяет сертификат.

4) HTTP-запрос — браузер отправляет GET / или другой запрос.

5) Ответ сервера — веб-сервер, прокси или приложение возвращает HTML, JSON, редирект или ошибку.

ERR_CONNECTION_TIMED_OUT может возникнуть почти на любом из этих этапов. Ключевой признак: клиент не получил явный отказ и не получил корректный ответ. Он просто ждал, пока время не вышло.

Это отличает таймаут от ситуаций, где сервер отвечает сразу, но с ошибкой. Например, 403 Forbidden — сервер доступен, но запрещает доступ. 500 Internal Server Error — приложение ответило, но сломалось внутри. А при ERR_CONNECTION_TIMED_OUT браузер может вообще не добраться до уровня HTTP.

Где искать проблему: у пользователя, в сети или на сайте

Главная сложность таймаутов — они не всегда глобальные. Сайт может открываться у администратора, но не открываться у части пользователей. Или наоборот: с домашнего интернета всё зависает, а с мобильной сети работает.

Чтобы не тратить время впустую, сначала определите масштаб.

1) Не открывается только один сайт или все сайты — если не открывается только один домен, вероятнее проблема на стороне сайта, DNS, CDN, маршрутизации или блокировок. Если не открываются многие сайты, проверьте локальную сеть, роутер, DNS-провайдера, VPN или прокси. Для общей диагностики можно использовать чеклист из статьи «Не открывается сайт».

2) Ошибка воспроизводится в одном браузере или везде — если проблема только в Chrome, проверьте расширения, кэш, прокси-настройки и антивирус. Если сайт не открывается ни в Chrome, ни в Firefox, ни через curl, ищите глубже: сеть, DNS, firewall, сервер.

3) Ошибка зависит от сети — откройте сайт через мобильный интернет, другую Wi-Fi-сеть или VPN. Если через другую сеть всё работает, возможны проблемы маршрутизации, блокировки у провайдера, некорректный DNS-кэш или фильтрация трафика.

4) Ошибка видна внешним проверкам — если мониторинг доступности фиксирует таймаут из нескольких локаций, это уже не локальная проблема пользователя. Например, Statuser проверяет сайт с заданным интервалом и присылает уведомление о сбое; такие проверки помогают понять, начался ли реальный инцидент или проблема ограничена одной сетью.

5) Есть ли записи в логах сервера — если в access-логах Nginx или приложения нет запросов от проблемного клиента, значит соединение не дошло до HTTP-уровня. Тогда смотрите DNS, firewall, CDN, балансировщик, маршрутизацию и TCP-соединения.

Частые причины ERR_CONNECTION_TIMED_OUT

У ERR_CONNECTION_TIMED_OUT нет одной универсальной причины. Ниже — самые распространённые сценарии.

1) Сервер недоступен по сети — сервер выключен, завис, потерял сеть, заблокирован firewall или не отвечает на нужном порту. Браузер отправляет пакеты, но не получает ответа.

2) Порт закрыт или отфильтрован — если порт 443 не слушается, часто появляется ERR_CONNECTION_REFUSED. Но если пакеты тихо отбрасываются firewall, клиент будет ждать до таймаута. Подробнее про отказ соединения — в статье ERR_CONNECTION_REFUSED.

3) Проблемы DNS — домен может указывать на старый IP, часть резолверов может видеть устаревшие записи, а у пользователя может быть битый DNS-кэш. Иногда DNS-запрос проходит, но возвращает адрес сервера, который уже не обслуживает сайт.

4) Перегрузка сервера — CPU, RAM, диск, база данных или event loop приложения перегружены. Сервер формально жив, но отвечает слишком медленно или не успевает принимать новые соединения.

5) Переполнение очередей TCP — при всплеске трафика или SYN flood может переполниться SYN backlog или accept queue. Снаружи это выглядит как зависающие подключения: часть клиентов подключается, часть получает таймаут.

6) Ошибки firewall, iptables, nftables, UFW или security group — правило могло случайно закрыть порт 80/443, разрешить доступ только с некоторых IP или начать дропать пакеты вместо явного отказа.

7) Проблемы на CDN или reverse proxy — если сайт работает через Cloudflare, CDN, Nginx, HAProxy или балансировщик, таймаут может происходить между клиентом и CDN либо между CDN и origin-сервером.

8) Неправильные таймауты прокси — Nginx, балансировщик или ingress могут ждать backend слишком долго или, наоборот, рвать соединение не там, где ожидается. В браузере это иногда выглядит как сетевой таймаут, а на промежуточном уровне — как 504.

9) Локальные проблемы пользователя — VPN, корпоративный прокси, антивирус, расширения браузера, DNS over HTTPS, повреждённый кэш, настройки hosts, нестабильный Wi‑Fi.

10) Маршрутизация и потери пакетов — между клиентом и сервером может быть проблемный участок сети. Особенно неприятны частичные сбои: из одного региона сайт открывается, из другого — нет.

Что сделать пользователю

Если вы не администрируете сайт, начните с простых проверок. Они не требуют доступа к серверу и часто помогают отличить локальную проблему от внешней.

1) Обновите страницу и проверьте другой сайт — иногда это кратковременный сбой сети. Если другие сайты открываются мгновенно, а один домен стабильно падает по таймауту, проблема может быть не у вас.

2) Откройте сайт в другом браузере или режиме инкогнито — так вы исключите влияние расширений, кэша, cookies и части настроек профиля.

3) Отключите VPN, прокси и антивирусную фильтрацию — VPN может вести трафик через перегруженный узел, корпоративный прокси — блокировать домен, антивирус — вмешиваться в HTTPS-соединение.

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

5) Очистите DNS-кэш — на Windows выполните ipconfig /flushdns, на macOS команда зависит от версии системы, на Linux часто достаточно перезапустить systemd-resolved или очистить кэш используемого DNS-клиента.

6) Смените DNS-сервер — попробуйте публичные резолверы, например 1.1.1.1 или 8.8.8.8. Если после смены DNS сайт открылся, причина могла быть в резолвере провайдера или устаревшей записи.

7) Проверьте файл hosts — на Windows он обычно находится в C:\Windows\System32\drivers\etc\hosts, на Linux и macOS — в /etc/hosts. Если домен вручную привязан к неправильному IP, браузер будет ходить не туда.

8) Попробуйте мобильный интернет — если с мобильной сети сайт открывается, а с домашней нет, проблема может быть у провайдера, в роутере, DNS или маршрутизации.

Если сайт критичен для работы, сохраните детали: домен, время ошибки, провайдер, город, скриншот, результат проверки через другую сеть. Эти данные помогут администратору быстрее найти причину.

Диагностика для владельца сайта и DevOps

Если вы отвечаете за сайт, задача — понять, на каком уровне пропадает соединение. Начинайте не с перезапуска всего подряд, а с проверки цепочки: DNS → TCP → TLS → HTTP → приложение.

1) Проверьте DNS-записи — убедитесь, что домен указывает на актуальные IP:

dig example.com A
dig example.com AAAA
dig www.example.com CNAME

Если сайт недавно переезжал, сравните ответы разных резолверов:

dig @1.1.1.1 example.com A
dig @8.8.8.8 example.com A

Для подробной отладки пригодится материал про dig и проверку DNS-записей.

2) Проверьте TCP-подключение к порту — с внешней машины выполните:

nc -vz example.com 443
nc -vz example.com 80

Если соединение зависает, порт может фильтроваться firewall или пакеты не доходят до сервера. Если получаете refused, сервис не слушает порт или порт закрыт явно.

3) Проверьте HTTP через curl — команда покажет, на каком этапе тратится время:

curl -v https://example.com/

Для измерения DNS, TCP, TLS и общего времени удобно использовать форматированный вывод:

curl -o /dev/null -s -w "dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} starttransfer=%{time_starttransfer} total=%{time_total}\n" https://example.com/

Если time_connect большой или соединение не устанавливается, проблема ниже HTTP. Если соединение быстрое, но time_starttransfer высокий, тормозит backend, база данных, внешний API или прокси. Больше примеров есть в статье «Что такое curl и как им пользоваться».

4) Проверьте трассировку и потери — если таймаут воспроизводится только из некоторых сетей, используйте mtr:

mtr -rw example.com

Смотрите не только на потери на промежуточных узлах, а на потери до финальной точки. Разбор таких отчётов есть в статье про mtr и WinMTR.

5) Проверьте, слушает ли сервер нужные порты — на сервере:

ss -ltnp | grep -E ':80|:443'

Вы должны увидеть Nginx, Caddy, Apache, HAProxy или другой процесс, который слушает 0.0.0.0:443, [::]:443, 0.0.0.0:80 или конкретный публичный IP.

6) Посмотрите firewall и security group — проверьте UFW, iptables, nftables, правила облачного провайдера и сетевые ACL. Частая ошибка: порт открыт на сервере, но закрыт в security group.

7) Проверьте логи Nginx и приложения — если запросы доходят, они должны появляться в access-логах. Если в момент таймаутов access-лог пустой, ищите проблему до Nginx. Если записи есть, смотрите статус, upstream time и ошибки backend.

8) Проверьте ресурсы сервера — используйте top, htop, vmstat, iostat, free -m, df -h. Сервер может отвечать на ping, но не принимать HTTP из-за нехватки памяти, высокой загрузки CPU, зависшего диска или исчерпания файловых дескрипторов.

Как исправлять проблему на сервере

Исправление зависит от найденного уровня. Ниже — типовые действия, которые чаще всего возвращают сайт к жизни.

1) Если сервис не слушает порт — перезапустите веб-сервер или приложение и проверьте статус:

systemctl status nginx
systemctl restart nginx

Для приложения проверьте свой менеджер процессов: systemd, PM2, Docker, Kubernetes, supervisor. Важно не просто перезапустить, а понять, почему процесс остановился: OOM, ошибка конфигурации, падение после деплоя, отсутствие доступа к секретам или базе.

2) Если виноват firewall — откройте нужные порты. Для UFW это может выглядеть так:

ufw allow 80/tcp
ufw allow 443/tcp
ufw status

Проверьте также облачные security groups. Локальный firewall может быть настроен правильно, но облачный периметр всё равно будет дропать пакеты.

3) Если проблема в DNS — исправьте A, AAAA, CNAME-записи, удалите неактуальные IPv6-записи, проверьте TTL. Отдельно проверьте www и корневой домен: нередко один работает, другой указывает на старую инфраструктуру.

4) Если перегружен backend — ищите узкое место. Проверьте p95/p99 latency, ошибки базы, пул соединений, внешние API, очереди, блокировки, медленные SQL-запросы. Таймаут в браузере может быть следствием того, что приложение заняло все воркеры и перестало принимать новые запросы.

5) Если перегружен Nginx или балансировщик — проверьте лимиты соединений, worker_connections, worker_rlimit_nofile, системные лимиты ulimit, размер accept queue, upstream health. Если включён rate limiting, убедитесь, что он не блокирует легитимный трафик слишком агрессивно.

6) Если таймаут между proxy и upstream — смотрите настройки proxy_connect_timeout, proxy_read_timeout, proxy_send_timeout, keepalive, health checks и состояние upstream-серверов. Но не лечите проблему только увеличением таймаутов: если backend отвечает 60 секунд, пользователю всё равно плохо.

7) Если проблема в CDN — проверьте, доступен ли origin напрямую, корректны ли IP в настройках CDN, не блокирует ли firewall адреса CDN, не истёк ли сертификат на origin. Для Cloudflare похожие сценарии могут проявляться как 522 или 524, но у пользователя иногда всё равно выглядит как браузерный таймаут.

8) Если сбой начался после деплоя — откатите релиз или переключите трафик на предыдущую версию. После восстановления разберите причину: миграция БД, изменение Nginx, новый Docker-образ, неправильная переменная окружения, изменение DNS или сертификатов.

Полезно держать внешнюю проверку доступности отдельно от внутренних метрик: сервер может выглядеть здоровым, а сайт — быть недоступен из интернета из-за DNS, CDN или firewall. Подробнее об этом — в разделе про профилактику ниже.

Чем ERR_CONNECTION_TIMED_OUT отличается от похожих ошибок

Браузерные и HTTP-ошибки часто путают, но для диагностики разница принципиальна.

1) ERR_CONNECTION_TIMED_OUT — клиент не дождался ответа. Причина может быть в сети, firewall, маршрутизации, перегрузке сервера или зависшем подключении. HTTP-статуса может не быть вообще.

2) ERR_CONNECTION_REFUSED — удалённая сторона явно отказала в соединении. Обычно это значит, что по IP доступ есть, но порт закрыт или сервис не слушает. Для расследования полезно сравнить оба сценария: таймаут часто говорит о фильтрации или потере пакетов, refused — о явном отказе.

3) DNS_PROBE_FINISHED_NXDOMAIN — браузер не смог найти домен в DNS. Это другой класс проблемы: до TCP-соединения дело не дошло. При ERR_CONNECTION_TIMED_OUT IP обычно уже найден, но соединение или ответ не получены.

4) 504 Gateway Timeout — это HTTP-ответ от шлюза, proxy или балансировщика. То есть какой-то сервер всё-таки ответил браузеру и сообщил, что не дождался upstream. Подробнее — в руководстве по ошибке 504 Gateway Timeout.

5) 502 Bad Gateway и 503 Service Unavailable — тоже HTTP-ошибки на стороне инфраструктуры или приложения. Они означают, что запрос дошёл до proxy или сервера, но дальше произошёл сбой. При чистом ERR_CONNECTION_TIMED_OUT ответ может не сформироваться вообще.

Практический вывод: если есть HTTP-код, смотрите логи веб-сервера и приложения. Если HTTP-кода нет и браузер показывает сетевой таймаут, начинайте с DNS, TCP, firewall, маршрутизации и доступности порта.

Как предотвратить повторение таймаутов

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

1) Настройте внешние проверки доступности — проверяйте не только ping, а реальный HTTPS URL, желательно с контролем статуса, времени ответа и содержимого страницы. Обзор подхода — в статье «Что такое uptime monitoring и как он работает».

2) Следите за latency, а не только за фактом ответа — сайт может ещё открываться, но уже деградировать. Рост времени соединения, TLS, TTFB и p95/p99 latency часто предупреждает о проблеме раньше, чем начнутся массовые таймауты.

3) Мониторьте насыщение ресурсов — CPU, RAM, диск, network, файловые дескрипторы, количество соединений, размер очередей, пул БД. Таймауты часто появляются не из-за одного «упавшего» процесса, а из-за saturation: система жива, но не справляется.

4) Проверяйте DNS и сертификаты после изменений — переезд на новый IP, подключение CDN, выпуск сертификата, включение IPv6 и изменение reverse proxy должны проходить через чеклист. Особенно опасны неактуальные AAAA-записи: часть клиентов может пытаться ходить по IPv6, который фактически не обслуживает сайт.

5) Делайте health checks на уровне балансировщика — балансировщик не должен отправлять трафик на backend, который завис, не прошёл миграции или потерял связь с базой. Health check должен проверять не только процесс, но и минимальную готовность приложения.

6) Разделяйте таймауты по уровням — клиентский таймаут, таймаут CDN, таймаут reverse proxy, таймаут приложения и таймаут запросов к БД должны быть согласованы. Если они настроены хаотично, расследование превращается в угадывание.

7) Храните логи и метрики достаточно долго — многие таймауты кратковременны. К моменту расследования всё уже работает, и без истории остаются только жалобы пользователей. Нужны access/error-логи, метрики соединений, latency, ошибок upstream и состояния ресурсов.

8) Используйте безопасные деплои — blue-green, canary или хотя бы быстрый rollback уменьшают риск, что неудачный релиз положит весь сайт. Особенно это касается изменений Nginx, ingress, Docker networking, security groups и DNS.

FAQ

Почему Chrome пишет ERR_CONNECTION_TIMED_OUT, а сайт у других открывается?
Проблема может быть локальной: DNS-кэш, VPN, прокси, расширение браузера, провайдер или маршрут до сервера. Проверьте сайт через другую сеть и другой браузер.

Может ли ERR_CONNECTION_TIMED_OUT быть из-за SSL-сертификата?
Напрямую чаще появляются TLS-ошибки, но косвенно да: если TLS-рукопожатие зависает из-за CDN, proxy, firewall или неправильной конфигурации HTTPS, браузер может показать таймаут.

Почему в логах Nginx нет запросов, хотя пользователи жалуются на таймаут?
Значит запросы не доходят до Nginx. Проверяйте DNS, CDN, firewall, security groups, маршрутизацию, открытые порты и TCP-соединения.

Достаточно ли увеличить таймауты в Nginx?
Обычно нет. Увеличение таймаутов может скрыть симптом, но не устранить перегрузку backend, зависшие запросы, проблемы БД или сети. Сначала найдите этап, на котором возникает задержка.