ERR_CONNECTION_TIMED_OUT: причины и решение

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

ERR_CONNECTION_TIMED_OUT — ошибка браузера, которая появляется, когда не удалось установить TCP-соединение с сервером за отведённое время. Ключевое отличие от других ошибок соединения: браузер не получил ни ответа, ни отказа — он просто «не дождался».

Механизм такой:

1. Браузер резолвит домен в IP-адрес через DNS.
2. Пытается установить TCP-соединение с этим IP по нужному порту (обычно 80 или 443), отправляя пакет SYN.
3. Если за таймаут (обычно десятки секунд) на SYN не приходит ответ SYN-ACK, браузер сдаётся и показывает ошибку.

То есть «соединение истекло» — это про сеть и доступность сервера, а не про содержимое сайта. Сервер либо не отвечает, либо его ответ не доходит до вас.

Что такое TCP-соединение и почему оно «истекает»

Чтобы понимать диагностику, полезно представлять, что происходит «под капотом». Установка соединения по TCP — это так называемое «тройное рукопожатие»:

1. SYN — ваш браузер отправляет серверу пакет с запросом на соединение.
2. SYN-ACK — сервер, если он жив и слушает порт, отвечает подтверждением.
3. ACK — браузер подтверждает, и соединение считается установленным.

Таймаут возникает, когда шаг 2 не наступает: пакет SYN ушёл, но ответа SYN-ACK нет и нет. Причин этому три:

• SYN не дошёл — пакет потерялся или отфильтрован где-то по пути (файрвол, сеть);
• SYN дошёл, но некому ответить — на порту никто не слушает, и сервер молча отбрасывает пакет (в отличие от ERR_CONNECTION_REFUSED, когда он отвечает отказом);
• ответ не вернулся — сервер ответил, но SYN-ACK потерялся на обратном пути или заблокирован файрволом.

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

Чем таймаут отличается от других ошибок соединения

ERR_CONNECTION_TIMED_OUT часто путают с похожими ошибками, но причины и лечение у них разные:

Если видите именно «err timed out» (соединение истекло) — вы по адресу. Если домен не резолвится в IP — это проблема DNS, и это другой сценарий.

Причины: почему соединение истекает

Причин немного, и они делятся на три группы: проблема на вашей стороне, проблема сети по пути и проблема на сервере.

Проблемы на вашей стороне

Прежде чем копать сервер, исключите локальные факторы — они дают ровно такой же симптом:

• VPN или прокси. Отключите VPN и попробуйте снова: часто соединение через VPN «не доживает» до сервера.
• Антивирус или файрвол на машине. Некоторые антивирусы перехватывают соединения и могут резать их по таймауту. Временно отключите защиту для проверки.
• Файл hosts. Если в hosts прописан неверный IP для домена, браузер будет стучаться не туда. Проверьте C:\Windows\System32\drivers\etc\hosts (Windows) или /etc/hosts (Linux/macOS).
• DNS-кеш и сетевые настройки. Сбросьте кеш: ipconfig /flushdns (Windows) или sudo dscacheutil -flushcache (macOS).

Быстрый способ понять, «это только у меня или у всех», — открыть сайт с другого устройства или из другой сети (например, с мобильного интернета).

Диагностика шаг за шагом

Правильный порядок — от сети к серверу. Каждый шаг сужает круг подозреваемых.

Шаг 1. Пинг — доступен ли хост

ping -c 4 example.com

-c 4 — отправить ровно четыре пакета (без этого в Linux пинг идёт бесконечно). Пример успешного вывода:

PING example.com (93.184.216.34) 56(84) bytes of data.
64 bytes from 93.184.216.34: icmp_seq=1 ttl=55 time=12.3 ms
64 bytes from 93.184.216.34: icmp_seq=2 ttl=55 time=11.9 ms
64 bytes from 93.184.216.34: icmp_seq=3 ttl=55 time=12.1 ms
64 bytes from 93.184.216.34: icmp_seq=4 ttl=55 time=12.2 ms

--- example.com ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms

Построчно:

• первая строка — домен резолвится в IP 93.184.216.34, значит DNS в порядке;
• строки 64 bytes from ... — каждый ответ ICMP echo-reply, time=12.3 ms — задержка;
• ttl=55 — число хопов, уменьшается на каждом маршрутизаторе;
• итог 0% packet loss — хост жив и отвечает.

Если вместо этого видите 100% packet loss или Destination Host Unreachable — хост не отвечает. Но осторожно: многие серверы просто отключают ICMP, поэтому «пинг не проходит» ещё не значит «сервер лежит». Проверяйте дальше по портам.

Быстрая проверка доступности без консоли — пинг-проверка на UptimeChecker.

Шаг 2. Порт — слушает ли кто-то на 80/443

Таймаут чаще всего означает именно закрытый порт. Проверяем через nc:

nc -zv example.com 443

-z — только сканирование без отправки данных, -v — подробный вывод. Пример успешного соединения:

Connection to example.com (93.184.216.34) 443 port [tcp/https] succeeded!

Пример неудачи — ровно тот таймаут, что видит браузер:

example.com [93.184.216.34] 443 (https) : Connection timed out

Если succeeded! — порт открыт и проблема не в файрволе порта. Если timed out — порт закрыт или пакет не доходит: проверяйте файрвол на сервере и слушающий сервис.

То же самое через telnet (есть не на всех системах, но часто встречается):

telnet example.com 443

Успех выглядит как подключение (мигающий курсор, прервать можно Ctrl+]), неудача — telnet: Unable to connect to remote host: Connection timed out.

Проверить конкретный порт без консоли — проверка порта на UptimeChecker.

Шаг 3. Traceroute — где обрывается путь

Когда пинг до хоста не проходит, нужно понять, на каком участке маршрут обрывается. Для этого traceroute (в Windows — tracert):

traceroute example.com

Вывод — список хопов от вашей машины до сервера:

 1  192.168.1.1  1.2 ms  1.1 ms  1.3 ms
 2  10.0.0.1  5.4 ms  5.1 ms  5.2 ms
 3  212.1.1.1  8.0 ms  8.2 ms  8.1 ms
 4  * * *
 5  * * *
 6  93.184.216.34  12.3 ms  12.1 ms  12.2 ms

Построчно:

• строки 1–2 — ваш локальный роутер и сеть провайдера;
• строка 3 — магистральный маршрутизатор;
• строки 4–5 — * * * — узлы не ответили на ICMP (часто это просто запрет ICMP, а не обрыв);
• строка 6 — конечный сервер отвечает.

Как это читать:

• если обрыв стабильно на ранних хопах (1–2) — проблема у вас или у провайдера;
• если * * * тянутся до самого конца — хост не отвечает (или весь ICMP запрещён);
• если ответ приходит на каком-то хопе, а дальше пусто — обрыв на конкретном участке сети.

Важно: * * * на промежуточных узлах — это норма, если конечный хост в итоге отвечает. Оценивайте результат по конечной точке, а не по «звёздочкам» в середине.

Шаг 4. HTTP напрямую — что видит сервер

Таймаут можно воспроизвести и без браузера, через curl с ограничением времени:

curl -v --connect-timeout 10 https://example.com

--connect-timeout 10 — сколько секунд ждать установления соединения (аналог таймаута браузера). Вывод при таймауте:

*   Trying 93.184.216.34:443...
*  connect to 93.184.216.34 port 443 failed: Connection timed out
*  Failed to connect to example.com port 443 after 10002 ms: Connection timed out
*  Closing connection 0
curl: (28) Failed to connect to example.com port 443 after 10002 ms: Connection timed out

Ключевое — Failed to connect ... port 443 ... Connection timed out: соединение не установилось. Если бы порт был открыт, вы увидели бы * Connected to example.com ... и дальше TLS-рукопожатие. Различие важно: таймаут на этапе connect — это сеть/порт, а ошибка на этапе TLS — уже про сертификат.

Шаг 5. Проверить «снаружи» — это только у вас или у всех

Таймаут на вашей машине ещё не значит, что сайт лежит для всех. Самый надёжный способ отделить «проблема у меня» от «проблема у сайта» — посмотреть на сайт с независимой точки. Откройте его с другого устройства или из другой сети (например, с мобильного интернета), либо воспользуйтесь внешней проверкой: проверка доступности сайта на UptimeChecker обратится к сайту со сторонних серверов и покажет, отвечает ли он.

Этот шаг экономит часы: если внешняя проверка показывает, что сайт доступен, — копайте локальные настройки (VPN, антивирус, DNS). Если недоступен извне тоже — проблема на стороне сервера, и дальше по чек-листу выше.

Заметка про Windows: tracert и telnet

Команды те же по смыслу, но называются иначе:

• ping — работает так же, но без -c: в Windows пинг по умолчанию шлёт четыре пакета;
• traceroute в Windows называется tracert, синтаксис тот же: tracert example.com;
• telnet в новых версиях Windows по умолчанию не установлен — его нужно включить через «Программы и компоненты» → «Компоненты Windows».

Что делать на стороне сервера

Если диагностика показала, что хост жив (пинг проходит), но порт 80/443 не отвечает — проблема на сервере. Проверяйте по порядку.

Проверить, слушает ли веб-сервер порт

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

Если вывод пустой — Nginx/Apache не запущен или слушает другой порт. Если строка есть, например:

LISTEN 0 511 0.0.0.0:443 0.0.0.0:* users:(("nginx",pid=1234,fd=6))

то сервер слушает порт, и дело в чём-то другом (файрвол, сеть).

Проверить файрвол

sudo ufw status
# или
sudo iptables -L -n

Правило, блокирующее 80/443, — частая причина таймаута при живом сервере.

Проверить, что сервис не упал

sudo systemctl status nginx

Статус active (running) — хорошо, failed или inactive — сервис упал, его нужно поднять и разобраться в логах.

Проверить перегрузку

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

top
free -h
df -h

Забитый диск или память, 100% CPU — и сервер перестаёт успевать отвечать на входящие соединения. Это проявляется как плавающий таймаут: то открывается, то нет.

Проверить облачный файрвол / security group

Если сервер в облаке, порт может быть закрыт на уровне security group провайдера, а не на самом сервере. Проверьте входящие правила в панели облака — это частый пропуск при настройке.

Чек-лист: ERR_CONNECTION_TIMED_OUT

• Определил тип ошибки (таймаут, а не refused/reset/DNS)
• Исключил локальные факторы: VPN, антивирус, hosts
• Пропинг: ping -c 4 example.com — хост жив?
• Проверил порт: nc -zv example.com 443 — открыт?
• Проследил маршрут: traceroute example.com — где обрыв?
• Воспроизвёл через curl с --connect-timeout
• На сервере: ss -tlnp, файрвол, systemctl status, нагрузка
• Проверил облачный security group

Связанные статьи

• Сайт недоступен: что делать и как найти причину — общий план диагностики, если ошибка не только про таймаут;
• Сайт упал: чек-лист диагностики — пошаговый чек-лист, чтобы быстро вернуть сайт в строй.

Коротко

ERR_CONNECTION_TIMED_OUT — это «соединение не установилось», и почти всегда причина — закрытый порт, файрвол или недоступный сервер, а не сам сайт. Диагностика линейна: пинг → порт → маршрут → сервер. Быстро сузить круг помогают пинг-проверка и проверка порта. А чтобы узнавать о таймаутах раньше посетителей, держите сайт под внешним мониторингом доступности — тогда ошибка соединения перестанет быть сюрпризом, а станет алертом в канале.