Как исправить ошибку ERR_CONNECTION_TIMED_OUT: полное техническое руководство

Ошибка ERR_CONNECTION_TIMED_OUT означает, что ваш браузер отправил запрос на подключение к удалённому серверу, но не получил ответа в течение отведённого времени — как правило, 30 секунд в браузерах на основе Chromium. TCP-рукопожатие так и не завершается, поэтому браузер прекращает попытку и отображает эту ошибку вместо загруженной страницы.

Это не однопричинный сбой. Он может возникать на стороне клиента (ваш компьютер, ваша сеть, ваш браузер), в промежуточной инфраструктуре (DNS-резолверы, прокси, межсетевые экраны) или на стороне сервера (перегруженный источник, неправильно настроенный веб-сервер, истёкший SSL или сбой маршрутизации на вышестоящем уровне). Для правильной диагностики необходимо последовательно проверить каждый уровень.

Что происходит во время тайм-аута соединения

Когда вы вводите URL и нажимаете Enter, браузер выполняет точную последовательность действий: разрешение DNS, TCP-соединение (SYN / SYN-ACK / ACK), необязательное TLS-рукопожатие, затем цикл HTTP-запрос/ответ. Ошибка тайм-аута означает, что процесс завис где-то в этой цепочке — чаще всего на этапе TCP-соединения, до обмена какими-либо HTTP-данными.

Понимание того, на каком этапе произошёл сбой, подскажет, где искать решение. Сбой DNS выдаёт другой код ошибки (`ERR_NAME_NOT_RESOLVED`). Сбой TLS выдаёт `ERR_SSL_PROTOCOL_ERROR`. Когда вы видите именно `ERR_CONNECTION_TIMED_OUT`, DNS-запрос выполнился успешно, но TCP-сокет так и не получил SYN-ACK от целевого IP. Это значительно сужает круг поиска.

Основные причины возникновения ошибки

Метод 1: Проверка интернет-соединения на сетевом уровне

Не просто «проверьте, работает ли интернет». Выполните структурированный тест:

• Пропингуйте шлюз: Откройте командную строку и выполните `ping 192.168.1.1` (или IP вашего роутера). Если это не работает, проблема находится между вашим компьютером и роутером.
• Пропингуйте публичный IP напрямую: Выполните `ping 8.8.8.8`. Если это работает, но сайты не открываются, проблема в DNS, а не в подключении.
• Выполните трассировку маршрута: `tracert google.com` в Windows или `traceroute google.com` в Linux/macOS. Найдите место, где узлы перестают отвечать — это укажет на проблемный сегмент сети.
• Перезагрузите роутер: Отключите его от питания на 30 секунд. Это принудительно обновит аренду DHCP и восстановит сессию PPPoE/PPPoA с провайдером.
• Проверьте через мобильную точку доступа: Если сайт открывается через LTE, но не через домашний широкополосный интернет, неисправность находится выше вашего роутера — скорее всего, у провайдера или на конкретном маршруте, который он использует.

Метод 2: Очистка и перестройка кэша DNS

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

В Windows:

“`

ipconfig /flushdns

ipconfig /registerdns

“`

В macOS (Ventura / Sonoma):

“`

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

“`

В Linux (systemd-resolved):

“`

sudo systemd-resolve –flush-caches

“`

После очистки проверьте, что кэш пуст, в Windows с помощью `ipconfig /displaydns` — вывод должен быть минимальным. Затем попробуйте подключиться снова, прежде чем вносить другие изменения, чтобы определить, был ли кэш DNS единственной причиной.

Метод 3: Переключение на надёжный публичный DNS-резолвер

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

В Windows (IPv4):

1. Откройте Панель управления > Сеть и Интернет > Центр управления сетями и общим доступом > Изменение параметров адаптера.
2. Щёлкните правой кнопкой мыши по активному адаптеру и выберите Свойства.
3. Выберите Протокол Интернета версии 4 (TCP/IPv4) и нажмите Свойства.
4. Выберите Использовать следующие адреса DNS-серверов и введите предпочтительный резолвер.

Рекомендуемые публичные DNS-резолверы:

Важный пограничный случай: Если вы недавно перенесли сайт на новый сервер или изменили его A-запись, распространение DNS может занять до 48 часов. В этот период часть пользователей будет перенаправляться на старый IP. Выполнение `nslookup yourdomain.com 8.8.8.8` и `nslookup yourdomain.com 1.1.1.1` позволяет сравнить, что возвращают разные резолверы — если IP-адреса различаются, вы находитесь в окне распространения, а не столкнулись с настоящей ошибкой тайм-аута.

Метод 4: Очистка кэша браузера, файлов cookie и расширений

Chrome и другие браузеры на основе Chromium кэшируют DNS-ответы независимо от кэша DNS на уровне операционной системы. Этот внутренний DNS-кэш браузера может хранить устаревшие записи даже после очистки системного кэша.

Очистка внутреннего DNS-кэша Chrome напрямую:

1. Перейдите по адресу `chrome://net-internals/#dns`
2. Нажмите Clear host cache
3. Перейдите по адресу `chrome://net-internals/#sockets`
4. Нажмите Flush socket pools

Очистка данных браузера:

1. Откройте Chrome и нажмите `Ctrl + Shift + Delete`
2. Установите временной диапазон За всё время
3. Отметьте Файлы cookie и другие данные сайтов и Кэшированные изображения и файлы
4. Нажмите Удалить данные

Сначала проверьте в режиме инкогнито. Если сайт открывается в режиме инкогнито, но не в обычном окне, причиной является расширение браузера. Отключите все расширения через `chrome://extensions/` и включайте их по одному, чтобы найти виновника. Чаще всего источником помех являются блокировщики рекламы, VPN-расширения и инструменты безопасности.

Метод 5: Отключение настроек прокси

Неправильно настроенный или устаревший прокси — одна из наиболее часто упускаемых из виду причин этой ошибки, особенно на корпоративных компьютерах или после удаления VPN-программ, оставивших настройки прокси.

Через Chrome:

1. Перейдите в Настройки > Система > Открыть настройки прокси-сервера компьютера
2. В разделе Настройка прокси вручную убедитесь, что параметр Использовать прокси-сервер отключён
3. В разделе Автоматическая настройка прокси убедитесь, что параметр Использовать скрипт настройки отключён, если вы намеренно не используете PAC-файл

Через параметры Windows напрямую:

1. Откройте Параметры > Сеть и Интернет > Прокси-сервер
2. Отключите все записи прокси вручную
3. Включите Автоматическое определение параметров только если этого требует ваша сеть

Через командную строку (самый быстрый способ):

“`

netsh winhttp reset proxy

“`

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

Метод 6: Сброс стека TCP/IP и каталога Winsock

Повреждение каталога Winsock — реализации Windows API сокетов Berkeley — может вызывать периодические или постоянные сбои соединения, которые выглядят идентично тайм-аутам на стороне сервера. Это особенно часто встречается после удаления вредоносных программ, неудачного обновления сетевых драйверов или агрессивной активности антивируса.

Откройте командную строку от имени администратора и последовательно выполните следующие команды:

“`

netsh winsock reset

netsh int ip reset resetlog.txt

ipconfig /release

ipconfig /flushdns

ipconfig /renew

“`

После выполнения всех команд перезагрузите компьютер. Файл `resetlog.txt` будет создан в вашем рабочем каталоге и содержит журнал каждого сброшенного раздела реестра — полезно для аудита повреждений.

В Linux эквивалентом для сброса состояния сети является:

“`

sudo systemctl restart NetworkManager

sudo ip route flush cache

“`

Метод 7: Проверка правил межсетевого экрана и антивируса

Брандмауэр Windows Defender и сторонние пакеты безопасности могут незаметно блокировать исходящие соединения на определённые порты, диапазоны IP или домены. Блокировка не вызывает немедленной ошибки «соединение отклонено» — вместо этого пакеты отбрасываются, и браузер ожидает до достижения порога тайм-аута.

Временный диагностический тест:

1. Перейдите в Панель управления > Система и безопасность > Брандмауэр Windows Defender
2. Нажмите Включение и отключение брандмауэра Windows Defender
3. Временно отключите его для частных и общественных сетей
4. Попробуйте подключиться

Если сайт открывается при отключённом брандмауэре, немедленно включите его снова, а затем создайте конкретное правило для исходящего трафика, разрешающее соединение с нужным доменом или IP, вместо того чтобы оставлять брандмауэр отключённым. Перейдите в Дополнительные параметры > Правила для исходящих подключений > Создать правило для точной настройки.

Для антивирусного программного обеспечения: Большинство современных пакетов включают функцию проверки HTTPS или «веб-щит», выполняющую перехват TLS-трафика по принципу «человек посередине». Это может нарушать соединения, если корневой сертификат антивируса не является доверенным для браузера, или если антивирус ошибочно помечает целевой сервер. Временное отключение компонента веб-щита (а не всего антивируса) является более точным тестом, чем отключение всей защиты.

Метод 8: Сброс флагов Chrome и предиктора сети

Экспериментальные флаги Chrome и функции прогнозирования сети иногда могут вызывать проблемы с подключением, особенно после обновлений браузера, изменяющих поведение этих функций.

Отключение прогнозирования сети:

1. Перейдите в Настройки > Конфиденциальность и безопасность > Файлы cookie и другие данные сайтов
2. Прокрутите до пункта Предварительная загрузка страниц для ускорения просмотра и поиска и отключите его

Сброс всех флагов Chrome до значений по умолчанию:

1. Перейдите по адресу `chrome://flags`
2. Нажмите Reset all в правом верхнем углу
3. Перезапустите Chrome

Сброс всех настроек сетевого стека Chrome:

1. Перейдите в Настройки > Дополнительные > Сброс настроек и удаление вредоносного ПО > Восстановление настроек по умолчанию

Это не удаляет закладки и пароли, но сбрасывает стартовые страницы, настройки новой вкладки, закреплённые вкладки, настройки контента, файлы cookie и расширения — фактически предоставляя чистую базовую конфигурацию сети.

Метод 9: Увеличение тайм-аута TCP-соединения (расширенный)

По умолчанию Windows ожидает примерно 21 секунду перед тем, как объявить попытку TCP-соединения неудачной (на основе значения реестра `TcpMaxConnectRetransmissions`, которое по умолчанию равно 2 повторным передачам с экспоненциальной задержкой). На медленных или перегруженных сетях этого может быть недостаточно.

Настройка через редактор реестра (Windows):

1. Откройте `regedit`
2. Перейдите к `HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTcpipParameters`
3. Найдите или создайте значение DWORD с именем `TcpMaxConnectRetransmissions`
4. Установите значение `3` или `4` (шестнадцатеричное), чтобы разрешить больше попыток повторной передачи

Важно: Это увеличивает время ожидания Windows перед отказом от TCP-соединения. Это не устраняет первопричину — просто даёт больше времени медленным серверам или перегруженным маршрутам для ответа. Используйте это только как диагностический инструмент или для конкретных случаев, например при подключении к географически удалённым серверам.

Метод 10: Проверка доступности сервера

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

Инструменты для проверки доступности сервера с внешних точек наблюдения:

• downforeveryoneorjustme.com — Простая проверка доступности с одного местоположения
• downdetector.com — Агрегирует сообщения пользователей о крупных сервисах
• tools.pingdom.com — Тестирует время отклика из нескольких глобальных точек
• mxtoolbox.com/SuperTool — Проверяет DNS, HTTP-заголовки и подключение
• check-host.net — Одновременно выполняет ping и HTTP-проверки с десятков географических узлов

Выполните `curl -v https://yourdomain.com` из терминала, чтобы увидеть точку сбоя — отклонено ли TCP-соединение, завершается ли тайм-аутом или успешно устанавливается, но возвращает код ошибки HTTP. Эта единственная команда даёт больше информации, чем любой GUI-инструмент.

Причины на стороне сервера: что проверить, если вы владелец сайта

Если вы являетесь владельцем сайта и ваши посетители сообщают об ошибке `ERR_CONNECTION_TIMED_OUT`, проблема почти наверняка находится в вашей инфраструктуре. Наиболее распространённые причины на стороне сервера:

Исчерпание очереди соединений веб-сервера:

В Apache директива `MaxClients` (или `MaxRequestWorkers` в Apache 2.4+) ограничивает количество одновременных соединений. При достижении этого лимита новые соединения ставятся в очередь и в конечном итоге завершаются тайм-аутом. Проверьте текущую конфигурацию:

“`

apache2ctl -V | grep -i mpm

grep -i maxrequestworkers /etc/apache2/apache2.conf

“`

В Nginx эквивалентом является `worker_connections` в блоке `events` и `worker_processes`. Распространённая ошибка конфигурации — установка `worker_processes` в значение `1` на многоядерном сервере, что создаёт узкое место.

Межсетевой экран блокирует входящий трафик на порту 80/443:

Если вы управляете средой VPS Хостинг, проверьте правила iptables или nftables:

“`

iptables -L INPUT -n -v | grep -E "80|443"

“`

Отсутствие правила ACCEPT для портов 80 и 443 приведёт к тому, что все подключения браузера будут незаметно завершаться тайм-аутом. Также убедитесь, что межсетевой экран панели управления хостингом (CSF, UFW или Firewalld) не заблокировал случайно эти порты после обновления безопасности.

Проблемы с SSL-сертификатом, вызывающие тайм-ауты TLS-рукопожатия:

Истёкший или неправильно настроенный SSL-сертификат может привести к зависанию TLS-рукопожатия, что в некоторых пограничных случаях проявляется как тайм-аут соединения, а не ошибка сертификата — особенно при использовании старых версий TLS или неправильно настроенных наборов шифров. Проверьте сертификат с помощью:

“`

openssl s_client -connect yourdomain.com:443 -servername yourdomain.com

“`

Исчерпание ресурсов сервера:

Высокая нагрузка на CPU или RAM может привести к тому, что процесс веб-сервера перестанет отвечать. На Linux-сервере проверьте:

“`

top -b -n 1 | head -20

free -h

ss -s

“`

Команда `ss -s` показывает сводку состояний сокетов — большое количество соединений в состоянии `TIME-WAIT` или `CLOSE-WAIT` указывает на проблемы с обработкой соединений, которые приведут к тайм-ауту новых подключений.

Неправильная конфигурация DNS после миграции сервера:

Если вы недавно перенесли сайт на Выделенный сервер или сменили хостинг-провайдера, убедитесь, что A-запись вашего домена указывает на правильный IP-адрес и что TTL старых записей истёк. Используйте `dig yourdomain.com +trace` для отслеживания полной цепочки DNS-разрешения от корневых серверов.

Сравнение ERR_CONNECTION_TIMED_OUT с похожими ошибками браузера

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

Практическая матрица решений: какое исправление применить первым

Используйте эту последовательность для минимизации времени диагностики:

1. Вы можете открыть другие сайты? Нет — сначала исправьте локальную сеть или соединение с провайдером (методы 1, 6). Да — переходите к шагу 2.
2. Сайт открывается на другом устройстве или в другой сети? Да — проблема на стороне клиента (методы 2, 3, 4, 5, 7). Нет — проблема, вероятно, на стороне сервера или связана с распространением DNS.
3. Внешний инструмент проверки (check-host.net) показывает сайт недоступным из нескольких точек? Да — свяжитесь с администратором сервера или вашим хостинг-провайдером. Нет — проблема в региональной маршрутизации или у вашего конкретного провайдера.
4. Сайт открывается в режиме инкогнито? Да — причиной является расширение браузера или кэшированные данные (метод 4). Нет — переходите к исправлениям на уровне DNS и сети.
5. Вы недавно изменяли DNS-записи или переносили серверы? Да — дождитесь распространения DNS и проверьте записи с помощью `dig` или `nslookup`. Нет — проверьте межсетевой экран на стороне сервера и конфигурацию веб-сервера.

Если вы управляете собственной серверной инфраструктурой — будь то VPS с cPanel или физический сервер — всегда проверяйте журналы сервера, прежде чем тратить время на исправления на стороне клиента. Журнал ошибок Apache (`/var/log/apache2/error.log`) и журнал ошибок Nginx (`/var/log/nginx/error.log`) содержат явные записи о сбоях соединений, событиях исчерпания ресурсов и ошибках конфигурации.

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

Ключевые технические выводы

• `ERR_CONNECTION_TIMED_OUT` конкретно указывает на сбой на уровне TCP — SYN-пакет был отправлен, но SYN-ACK не получен. Это отличает её от ошибок DNS, TLS и HTTP.
• Всегда проверяйте с внешней точки наблюдения (check-host.net, curl с удалённого сервера), прежде чем предполагать, что проблема на вашем локальном компьютере.
• Chrome поддерживает собственный внутренний кэш DNS, отдельный от кэша операционной системы. Очистки только системного кэша через `ipconfig /flushdns` недостаточно — необходимо также очистить `chrome://net-internals/#dns`.
• На стороне сервера незаметное отбрасывание пакетов правилами межсетевого экрана является наиболее распространённой причиной именно этой ошибки. Отклонённое соединение (`RST`) выдало бы другой код ошибки.
• Задержки распространения DNS после миграции серверов часто ошибочно диагностируются как ошибки тайм-аута. Всегда проверяйте с помощью `nslookup` на нескольких резолверах, прежде чем продолжать расследование.
• Для производственных веб-серверов регулярно отслеживайте вывод `ss -s`. Растущее количество `CLOSE-WAIT` указывает на ошибки обработки сокетов на уровне приложения, которые в конечном итоге вызовут тайм-ауты соединений под нагрузкой.

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

Почему ERR_CONNECTION_TIMED_OUT появляется только на одном конкретном сайте, но не на других?

Это почти всегда означает, что целевой сервер недоступен именно из вашей сети — либо сервер не работает, либо его IP изменился из-за распространения DNS, либо правило межсетевого экрана на сервере блокирует ваш диапазон IP. Используйте внешний инструмент проверки, например check-host.net, чтобы подтвердить, недоступен ли сайт глобально или только из вашего местоположения.

Помогает ли очистка кэша DNS при ошибке ERR_CONNECTION_TIMED_OUT?

Может помочь, но только если причиной является устаревшая DNS-запись, указывающая на старый IP сервера. Если DNS-запись верна, а сервер действительно недоступен, очистка кэша не поможет. Всегда проверяйте, какой IP-адрес возвращает домен, с помощью `nslookup` до и после очистки.

Может ли VPN вызывать ошибку ERR_CONNECTION_TIMED_OUT?

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

Как исправить ERR_CONNECTION_TIMED_OUT на сервере, которым я управляю?

Проверяйте в следующем порядке: (1) убедитесь, что процесс веб-сервера запущен (`systemctl status nginx` или `apache2`), (2) проверьте, что порты 80 и 443 открыты в межсетевом экране (`iptables -L` или `ufw status`), (3) проверьте использование ресурсов сервера с помощью `top` и `free -h`, (4) просмотрите журнал ошибок веб-сервера на предмет отказов соединений или сообщений об исчерпании рабочих процессов, (5) убедитесь, что ваш SSL-сертификат действителен и не истёк.

Является ли ERR_CONNECTION_TIMED_OUT тем же, что и 504 Gateway Timeout?

Нет. 504 Gateway Timeout — это ошибка HTTP-уровня, возвращаемая обратным прокси (например, Nginx или CDN), когда он не может получить ответ от вышестоящего исходного сервера в течение настроенного тайм-аута. `ERR_CONNECTION_TIMED_OUT` — это ошибка уровня браузера, возникающая до получения какого-либо HTTP-ответа — само TCP-соединение так и не устанавливается. Обе ошибки указывают на тайм-аут, но на разных уровнях сетевого стека.