ERR_CONNECTION_REFUSED: Що це означає і як повністю це виправити

Помилка ERR_CONNECTION_REFUSED означає, що ваш браузер надіслав запит на підключення до веб-сервера, і цей сервер активно відхилив його — не проігнорував, а явно відмовив у TCP-рукостисканні. Це принципово інший режим збою порівняно з тайм-аутом (ERR_CONNECTION_TIMED_OUT) або помилкою DNS (ERR_NAME_NOT_RESOLVED), і ця відмінність має величезне значення при діагностиці першопричини.

На практиці, коли Chrome відображає "Цей сайт недоступний. ERR_CONNECTION_REFUSED," це означає одне з трьох: цільовий сервер не прослуховує запитуваний порт, брандмауер або рівень безпеки надсилає TCP RST (скидання) пакет назад до вашого клієнта, або ваш локальний мережевий стек неправильно налаштований і маршрутизує запит некоректно ще до того, як він досягає сервера. Визначення того, яка з цих трьох категорій стосується вашої ситуації, є найшвидшим шляхом до вирішення проблеми.

Розуміння механіки на рівні TCP

Більшість посібників з усунення несправностей браузера трактують ERR_CONNECTION_REFUSED як розпливчасту «мережеву проблему». Це не так. На рівні TCP відмова у з’єднанні означає, що сервер (або посередник) надіслав назад пакет RST/ACK у відповідь на SYN-пакет вашого браузера. Це явне відхилення, а не мовчазне скидання.

Ця відмінність має практичне діагностичне значення: якби з’єднання мовчки скидалося брандмауером, ви б бачили ERR_CONNECTION_TIMED_OUT. Відмова у з’єднанні означає, що щось активно відповідає — тобто хост доступний на мережевому рівні, але служба на цільовому порту недоступна або заблокована.

Поширені причини на рівні портів включають:

• Процес веб-сервера (Apache, Nginx, Node.js) аварійно завершився або зупинився
• Сервер прослуховує нестандартний порт, і URL його не вказує
• Хостовий брандмауер (iptables, ufw, Windows Defender Firewall) відхиляє з’єднання на порту 80 або 443
• Зворотний проксі (HAProxy, Nginx, Cloudflare) налаштований неправильно і повертає RST-пакети вище за потоком
• Застосунок за проксі аварійно завершився, залишивши проксі без бекенду для пересилання

Першопричини: структурований розбір

Причини на стороні клієнта

Причини на стороні сервера

Покроковий посібник з діагностики та виправлення

Крок 1: Визначте, чи проблема є глобальною або локальною

Перш ніж змінювати будь-які локальні налаштування, з’ясуйте, чи сайт недоступний для всіх або лише для вас. Використовуйте ці інструменти:

• downforeveryoneorjustme.com — проста перевірка доступності
• isitdownrightnow.com — включає історію часу відповіді
• ping.pe — пінгує ціль з кількох глобальних місць одночасно

Якщо сайт доступний із зовнішніх вузлів, але не з вашого комп’ютера, проблема є локальною. Якщо він недоступний глобально, проблема на стороні сервера і поза вашим контролем — зверніться до адміністратора сайту або зачекайте.

Для адміністраторів серверів, які керують власною інфраструктурою, глобально недоступний сайт вимагає негайного розслідування процесу веб-сервера, правил брандмауера та мережі вище за потоком. Якщо ви використовуєте середовище VPS Hosting, спочатку перевірте список процесів вашого сервера та конфігурацію брандмауера.

Крок 2: Перевірте, чи сервер дійсно прослуховує (для адміністраторів серверів)

Якщо ви адмініструєте відповідний сервер, підключіться через SSH і виконайте наступне, щоб підтвердити, що прослуховується на яких портах:

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

Якщо виведення порожнє для порту 80 або 443, ваш процес веб-сервера не запущений. Перезапустіть його:

# For Nginx
sudo systemctl restart nginx

# For Apache
sudo systemctl restart apache2

# Check status
sudo systemctl status nginx

Також перевірте, чи ваш брандмауер не блокує вхідні з’єднання:

# Check iptables rules
sudo iptables -L INPUT -n -v

# If using ufw
sudo ufw status verbose

Якщо порт 443 заблокований, дозвольте його:

sudo ufw allow 443/tcp
sudo ufw allow 80/tcp
sudo ufw reload

Для адміністраторів, які використовують Dedicated Servers, також перевірте, чи брандмауер або правила груп безпеки вашого хостинг-провайдера вище за потоком не блокують порт на мережевому периметрі — це окремо від брандмауера на рівні ОС.

Крок 3: Перезапустіть роутер і очистіть локальний мережевий стан

Для проблем на стороні клієнта перезапуск роутера очищає таблиці NAT, оренди DHCP та будь-які тимчасові збої маршрутизації. Від’єднайте роутер на 30 секунд, потім підключіть знову. Це особливо ефективно, коли помилка з’явилася раптово без будь-яких змін конфігурації.

Крок 4: Очистіть кеш DNS

Застарілий запис кешу DNS, що вказує на стару або виведену з експлуатації IP-адресу, є однією з найпоширеніших причин ERR_CONNECTION_REFUSED на стороні клієнта. Сервер за кешованою IP-адресою може більше не обслуговувати цільовий сайт.

На Windows:

ipconfig /flushdns

На macOS (Ventura, Sonoma та більшість сучасних версій):

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

На Linux (systemd-resolved):

sudo systemd-resolve --flush-caches

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

nslookup example.com
# or
dig +short example.com

Порівняйте це з відомою IP-адресою сайту. Якщо вони відрізняються, поширення DNS може ще тривати.

Крок 5: Очистіть кеш браузера та файли cookie

У Google Chrome перейдіть до chrome://settings/clearBrowserData або скористайтеся комбінацією клавіш:

• Windows/Linux: Ctrl + Shift + Delete
• macOS: Cmd + Shift + Delete

Встановіть діапазон часу на Увесь час, позначте Кешовані зображення та файли і Файли cookie та інші дані сайтів, потім натисніть Видалити дані. Повністю перезапустіть Chrome (не лише вкладку) перед повторним тестуванням.

Для швидкого тесту без очищення даних відкрийте вікно Анонімного перегляду (Ctrl + Shift + N). Якщо сайт завантажується в анонімному режимі, але не у звичайному вікні, причиною є кешований ресурс або розширення браузера.

Крок 6: Перевірте та вимкніть налаштування проксі

Неправильно налаштований або недіючий проксі-сервер є частою причиною ERR_CONNECTION_REFUSED на всіх веб-сайтах одночасно. Chrome за замовчуванням використовує системні налаштування проксі.

На Windows:

Перейдіть до Параметри > Система > Проксі та вимкніть «Використовувати проксі-сервер», якщо він увімкнений без вашого відома. Крім того, виконайте це з підвищеного командного рядка:

netsh winhttp reset proxy

На macOS:

Перейдіть до Системні налаштування > Мережа, виберіть активний інтерфейс, натисніть Деталі, потім вкладку Проксі та зніміть позначки з усіх активних протоколів проксі.

Після вимкнення проксі протестуйте сайт. Якщо він завантажується, конфігурація проксі була причиною. Або налаштуйте її правильно, або видаліть повністю.

Крок 7: Змініть DNS-резолвер

DNS-резолвер вашого провайдера за замовчуванням може повертати некоректні результати, зазнавати збою або активно блокувати певні домени. Перехід на публічний резолвер усуває цю змінну.

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

На Windows (через PowerShell):

Set-DnsClientServerAddress -InterfaceAlias "Wi-Fi" -ServerAddresses ("1.1.1.1","1.0.0.1")

На macOS:

Перейдіть до Системні налаштування > Мережа > [Ваш інтерфейс] > Деталі > DNS, видаліть наявні записи та додайте 1.1.1.1 і 1.0.0.1.

На Linux (systemd-resolved):

Відредагуйте /etc/systemd/resolved.conf:

[Resolve]
DNS=1.1.1.1 1.0.0.1
FallbackDNS=8.8.8.8 8.8.4.4

Потім перезапустіть резолвер:

sudo systemctl restart systemd-resolved

Крок 8: Тимчасово вимкніть брандмауер та антивірус

Деякі антивірусні продукти та хостові брандмауери перехоплюють HTTPS-трафік через локальний проксі та можуть надсилати RST-пакети, коли їхній механізм перевірки дає збій або коли цільовий домен знаходиться у списку блокування. Тимчасове вимкнення (лише для діагностичних цілей) підтверджує, чи вони є причиною.

Якщо вимкнення програмного забезпечення безпеки вирішує помилку, додайте конкретний виняток для цільового домену, а не залишайте програмне забезпечення вимкненим. Негайно увімкніть його знову після тестування.

Крок 9: Протестуйте в іншому браузері та мережі

Протестуйте URL у Firefox, Edge або Safari. Якщо він завантажується в іншому браузері, проблема специфічна для Chrome — ймовірно, пошкоджений профіль, несправне розширення або налаштування проксі, специфічне для Chrome. Спробуйте створити новий профіль Chrome для ізоляції проблеми.

Якщо сайт не працює в усіх браузерах, перейдіть на мобільну точку доступу. Якщо він завантажується через мобільні дані, джерелом проблеми є ваш провайдер або домашній роутер.

Крок 10: Перевірте проблеми конфігурації SSL/TLS (адміністратори серверів)

Неправильно налаштований SSL-сертифікат може спричинити збій сервера або відмову від TLS-з’єднань, що Chrome у деяких граничних випадках відображає як ERR_CONNECTION_REFUSED замість помилки сертифіката. Використовуйте наступне для тестування з командного рядка:

curl -vI https://yourdomain.com

Зверніть увагу на етап TLS-рукостискання у детальному виведенні. Збій тут вказує на проблему з сертифікатом або набором шифрів. Також можна протестувати за допомогою:

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

Якщо ваш SSL-сертифікат закінчився або неправильно налаштований, його оновлення або заміна вирішує проблему. Переконайтеся, що ваші SSL Certificates дійсні, правильно зв’язані та встановлені на правильному інтерфейсі сервера.

ERR_CONNECTION_REFUSED порівняно з подібними помилками браузера

Розуміння того, чим ця помилка відрізняється від пов’язаних помилок, запобігає неправильній діагностиці:

Розширені граничні випадки та підводні камені

Конфлікти розпізнавання IPv6 та IPv4: Якщо домен розпізнається до IPv6-адреси, але ваша мережа не підтримує IPv6 належним чином, Chrome може спробувати IPv6-з’єднання, яке буде відхилено, а потім не зможе швидко перейти на IPv4. Тимчасове вимкнення IPv6 на мережевому адаптері може підтвердити це. На Linux можна примусово використовувати IPv4 за допомогою curl -4 https://example.com.

Кешування застарілих помилок origin через Cloudflare або CDN: Якщо сайт використовує Cloudflare і origin-сервер виходить з ладу, Cloudflare може деякий час обслуговувати кешовану версію, а потім починає повертати помилки 521 (origin відмовив у з’єднанні) або 522, які Chrome може відображати як ERR_CONNECTION_REFUSED залежно від того, як помилка проксується.

Локальні середовища розробки: Розробники часто бачать ERR_CONNECTION_REFUSED при доступі до localhost:3000 або подібних адрес. Причина майже завжди полягає в тому, що процес сервера розробки не запущений, аварійно завершився або прив’язаний до 127.0.0.1 на іншому порту, ніж очікувалося. Запустіть ss -tlnp | grep node (або відповідний процес), щоб підтвердити, що насправді прослуховується.

Конфлікти портів поштового сервера: Якщо ви використовуєте Email Hosting на тому ж сервері, що й ваш веб-застосунок, переконайтеся, що конфлікти портів між SMTP (25, 587), IMAP (993) та HTTP/HTTPS (80, 443) не спричиняють збій прив’язки веб-сервера.

Обмеження спільного хостингу: У середовищах Shared Web Hosting відмова у з’єднанні може вказувати на те, що сервер хостинг-провайдера перевантажений, обліковий запис призупинено або DNS домену ще не вказує на правильну спільну IP-адресу. Перевірте панель керування хостингом на предмет статусу облікового запису та конфігурації DNS.

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

Використовуйте цей контрольний список для ефективного сортування:

• Помилка з’являється на всіх веб-сайтах одночасно — Спочатку перевірте налаштування проксі та конфігурацію VPN/брандмауера
• Помилка з’являється лише на одному конкретному домені — Перевірте, чи сайт недоступний глобально; потім очистіть кеш DNS
• Помилка з’являється лише в Chrome, не в інших браузерах — Очистіть кеш Chrome, вимкніть розширення або створіть новий профіль Chrome
• Помилка з’являється лише у вашій мережі, не через мобільні дані — Перезапустіть роутер; перевірте DNS або брандмауер на рівні провайдера
• Помилка з’явилася після зміни конфігурації сервера — Перевірте статус процесу веб-сервера, прив’язки портів та правила брандмауера на сервері
• Помилка з’являється переривчасто під навантаженням — Дослідіть вичерпання ресурсів (файлові дескриптори, пам’ять, ліміти з’єднань) на сервері
• Помилка з’являється лише на HTTPS, не на HTTP — Дослідіть дійсність SSL-сертифіката та конфігурацію TLS
• Помилка з’явилася після зміни налаштувань DNS — Скасуйте зміни DNS та очистіть кеш; перевірте доступність нового резолвера

FAQ

У чому різниця між ERR_CONNECTION_REFUSED та ERR_CONNECTION_TIMED_OUT?

ERR_CONNECTION_REFUSED означає, що сервер (або брандмауер) активно надіслав пакет скидання TCP, негайно відхиливши з’єднання. ERR_CONNECTION_TIMED_OUT означає, що відповідь не була отримана протягом часу очікування — пакети були мовчки скинуті. Відмова у з’єднанні з’являється швидше і вказує на активне відхилення, тоді як тайм-аут свідчить про правило DROP маршрутизації або брандмауера.

Чи може ERR_CONNECTION_REFUSED бути спричинений простроченим SSL-сертифікатом?

Опосередковано, так. У деяких конфігураціях сервера прострочений або неправильно налаштований SSL-сертифікат спричиняє збій процесу веб-сервера під час запуску або його аварійне завершення при обробці TLS-з’єднань, що призводить до відсутності прослуховувача на порту 443. Chrome тоді повідомляє ERR_CONNECTION_REFUSED, оскільки нічого не прослуховує, хоча основною причиною є проблема з сертифікатом.

Чому ERR_CONNECTION_REFUSED з’являється лише на одному конкретному веб-сайті?

Якщо помилка ізольована на одному домені, найімовірніші причини такі: веб-служба цільового сервера аварійно завершилася, брандмауер сервера блокує ваш діапазон IP, записи DNS домену вказують на стару IP-адресу, де жодна служба не запущена, або сайт було знято. Використовуйте curl -v https://thatdomain.com з іншої мережі або сервера для ізоляції причини.

Як виправити ERR_CONNECTION_REFUSED на localhost?

Сервер застосунку не запущений або прив’язаний до іншого порту, ніж ви запитуєте. Підтвердіть, що прослуховується, за допомогою ss -tlnp на Linux/macOS або netstat -ano | findstr :PORT на Windows. Запустіть процес сервера застосунку та переконайтеся, що він прив’язаний до 0.0.0.0 або 127.0.0.1 на очікуваному порту.

Чи завжди очищення DNS виправляє ERR_CONNECTION_REFUSED?

Лише тоді, коли першопричиною є застарілий запис кешу DNS, що вказує на IP-адресу, де служба більше не працює. Якщо сервер не працює, брандмауер блокує з’єднання або проксі неправильно налаштований, очищення DNS не матиме ефекту. Використовуйте dig або nslookup для перевірки розпізнавання DNS до та після очищення, щоб підтвердити, чи DNS дійсно був проблемою.