Як виправити помилку 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 Firewall і сторонні засоби безпеки можуть непомітно блокувати вихідні з’єднання на певні порти, діапазони 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 — Одночасно виконує пінг і HTTP-перевірки з десятків географічних вузлів

Виконайте `curl -v https://yourdomain.com` з терміналу, щоб побачити точне місце збою — чи відхилено TCP-з’єднання, чи стався тайм-аут, чи з’єднання встановлено, але повернуто код помилки HTTP. Ця одна команда дає більше інформації, ніж будь-який графічний інструмент.

Причини на стороні сервера: що перевірити, якщо ви є власником сайту

Якщо ви є власником сайту і ваші відвідувачі повідомляють про `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 Hosting, перевірте правила 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, чи то у bare-metal середовищі — завжди перевіряйте журнали сервера, перш ніж витрачати час на виправлення на стороні клієнта. Журнал помилок 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-з’єднання так і не завершується. Обидві вказують на тайм-аут, але на різних рівнях мережевого стека.