ERR_CONNECTION_​TIMED_​OUT: как исправить

ERR_CONNECTION_TIMED_OUT возникает, когда браузер не успевает установить соединение с узлом и не получает HTTP-ответ. Проверьте масштаб сбоя, затем по отдельности DNS, TCP-порт, маршрут, proxy или VPN. Владельцу сайта после этого нужно проверить edge, firewall, listener и связь с origin и upstream.

Эта ошибка не сообщает, какой участок задержал соединение. Имя могло разрешиться в неверный адрес, TCP-пакеты могли потеряться по пути, firewall — молча отбросить их, а reverse proxy — не дождаться origin. Одинаковая страница браузера скрывает разные причины, поэтому исправление начинается не с очистки всего подряд, а с определения границы отказа.

Сначала отделите ошибку браузера от HTTP-тайм-аута

ERR_CONNECTION_TIMED_OUT — сетевая ошибка Chromium для попытки соединения, которая завершилась по тайм-ауту. В этом случае браузер не получил обычный HTTP-ответ. Код 408 или 504, напротив, уже является ответом HTTP и указывает на другую стадию.

Тайм-аут и отказ в соединении не взаимозаменяемы. TCP может долго повторять попытку, если пакеты молча теряются. Явный сброс соединения обычно возвращает отказ быстро. Не берите долгий индикатор загрузки за доказательство того, что приложение медленное: запрос мог ещё не попасть ни в веб-сервер, ни в приложение.

Определите масштаб без сброса настроек

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

Зафиксируйте перед проверками:

• точный URL, время и текст ошибки;
• устройство, сеть, активный VPN и системный proxy;
• работает ли другой сайт на том же устройстве;
• работает ли этот адрес через другую сеть.

Перезагрузка роутера полезна, если проблема ограничена его сетью и есть признаки сбоя самого устройства. Она не исправляет firewall на сервере, неправильный адрес домена или неработающий origin. Кнопка «сбросить всё» выглядит занятой работой, но стирает конфигурацию быстрее, чем устанавливает причину.

Проверьте DNS отдельно от TCP

Сначала убедитесь, что имя возвращает ожидаемые IPv4- и IPv6-адреса. Ошибка разрешения имени обычно имеет собственное сообщение, но неверная или старая запись вполне способна привести браузер к адресу, где TCP-подключение будет ждать до тайм-аута.

Сравните результат с адресами, которые должен публиковать владелец домена. Если несколько адресов обслуживают сайт, проверьте каждый: один неисправный узел способен давать плавающую ошибку. Для dual-stack отдельно сравните IPv4 и IPv6, потому что рабочий A-адрес не компенсирует недоступный AAAA-путь на каждом клиенте.

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

Проверьте TCP 443 и этап соединения

После подтверждения адреса проверьте именно порт сервиса. Успешный ping не доказывает доступность HTTPS: ICMP и TCP 443 могут проходить по разным правилам. Неуспешный ping тоже не доказывает поломку, поскольку ответы ICMP часто ограничивают.

На Windows используйте Test-NetConnection example.com -Port 443 -InformationLevel Detailed. Команда проверяет TCP-подключение к выбранному порту и показывает разрешённый адрес. Это не HTTP-запрос и не проверка содержимого сайта.

На всех трёх системах доступен curl. В Windows указывайте исполняемый файл явно, чтобы не попасть на старый PowerShell alias.

Замените HTTPS_URL полным адресом с протоколом HTTPS. Параметр connect-timeout ограничивает фазу подключения, куда входят разрешение имени и протокольные рукопожатия. Он не задаёт допустимое время всей загрузки. Подробный режим показывает, на каком адресе и этапе остановился запрос, но может вывести служебные заголовки: не публикуйте результат без удаления токенов, cookie и внутренних имён.

Повторите безопасный тест с -4 и -6, если домен имеет оба семейства адресов. Рабочий IPv4 рядом с тайм-аутом IPv6 сужает проблему до AAAA-записи, IPv6-маршрута или правил на этом пути. Не удаляйте IPv6 вслепую со всех устройств; исправьте опубликованный адрес или доступность сервиса.

Как проверить маршрут без ложного диагноза

На Windows команда tracert -d example.com показывает последовательность IP-переходов без обратного разрешения имён. На Linux и macOS используйте traceroute -n example.com. Сохраните результат рядом с временем тайм-аута и адресом, который проверяли.

Звёздочки на промежуточном узле не доказывают, что он теряет пользовательский трафик. Маршрутизатор может пересылать TCP и не отвечать на диагностические пакеты. Значимее повторяемая граница, после которой не отвечает конечный сервис, особенно если независимый TCP-тест из другой сети показывает то же самое.

Маршрут до CDN или anycast-адреса может отличаться между сетями и меняться со временем. Сравнение двух трасс — это указатель для провайдера или сетевого администратора, а не список виновных автономных систем.

Проверьте proxy, VPN и локальный firewall

Если ошибка есть только в одном браузере, проверьте его proxy и расширения. Если она повторяется во всех приложениях одного устройства, изучите системный proxy, VPN и защитное ПО. Корпоративный агент способен направлять HTTPS через инспекцию трафика даже тогда, когда пользователь не настраивал proxy вручную.

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

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

Что проверять владельцу сайта

Начните с журналов внешнего edge или load balancer. Если попытка клиента там не появилась, проверяйте DNS, маршрут и firewall перед edge. Если edge принял запрос, но origin его не увидел, проблема находится между балансировщиком и origin. Запись в access log приложения переводит диагностику к обработчику и его зависимостям.

Затем подтвердите listener на ожидаемом адресе и порту.

Слушающий сокет на 127.0.0.1 может быть правильным за локальным reverse proxy и неправильным для прямого внешнего подключения. Сокет на 0.0.0.0 или :: тоже не гарантирует доступность: до него остаются host firewall, security group, ACL, NAT и правила load balancer.

Проверьте origin локально, сохранив доменное имя для Host и TLS SNI: curl –resolve HOSTNAME:443:127.0.0.1 –connect-timeout 5 -I HTTPS_URL. Замените оба заполнителя одним доменным именем, а адрес — фактическим адресом listener. Запускайте такой тест только для своего сервиса. Успех подтверждает локальную цепочку, но не внешний маршрут.

Далее сравните health check балансировщика с реальным listener: порт, протокол, путь, Host, SNI и ожидаемый статус. Неверный health check способен исключить рабочий origin из пула, а разрешающее правило для старого диапазона адресов — заблокировать новый edge.

Firewall и правила доступа на сервере

Не начинайте с очистки ruleset. Проверьте журналы и счётчики правила на точном интерфейсе, адресе назначения и TCP-порту 443. Облачный security group, сетевой ACL и firewall операционной системы — разные границы; разрешение на одной из них ничего не говорит о двух других.

Если порт доступен из локальной сети сервера, но недоступен извне, двигайтесь наружу: host firewall, маршрут, NAT, security group, ACL, load balancer. Если внешний edge соединяется, а произвольный интернет-клиент нет, это может быть намеренной архитектурой. Origin за CDN часто и должен принимать трафик только от edge.

Изменяйте одно узкое правило и держите путь отката. Не добавляйте постоянное разрешение для всего интернета ради проверки административного порта. Для HTTPS публичный доступ должен заканчиваться на предусмотренном edge или listener, а не на случайно найденном процессе.

Если сервер возвращает 408 или 504

HTTP 408 означает, что сервер не получил полный запрос за время, которое был готов ждать. Ищите медленную передачу клиента, обрывы на пути, слишком жёсткий лимит приёма и перегрузку принимающей стороны. Сам факт 408 не доказывает медленную бизнес-логику приложения.

HTTP 504 означает, что gateway или proxy не дождался upstream. Сопоставьте request ID и время между журналами edge, reverse proxy, приложения, базы и внешних зависимостей. Без этой цепочки увеличение тайм-аута лишь делает ожидание длиннее.

В nginx proxy_connect_timeout относится к установлению соединения с upstream, а proxy_read_timeout — к интервалам между чтениями от него, а не ко всему времени ответа. Первый тайм-аут направляет к адресу, listener, маршруту и firewall origin. Второй — к зависшему обработчику, очереди, базе или внешнему API.

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

Короткий план действий

Если проблема плавающая, одного успешного теста мало. Сохраните несколько наблюдений с временем, сетью, разрешённым IP и этапом curl. Так владелец сайта увидит, какой edge или адрес связан со сбоем, а провайдер сети получит маршрут и временную точку вместо просьбы «проверить интернет».