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-резолвер вашого ISP за замовчуванням може повертати неправильні результати, мати збій або активно блокувати певні домени. Перемикання на публічний резолвер усуває цю змінну.

Рекомендовані публічні 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, щоб ізолювати проблему.

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

Крок 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 vs. Подібні помилки браузера

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

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

1) Конфлікти розпізнавання IPv6 та IPv4:

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

2) Кешування Cloudflare або CDN застарілих помилок походження:

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

3) Локальні середовища розробки:

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

4) Конфлікти портів поштового сервера:

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

5) Обмеження спільного хостингу:

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

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

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

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

Часто задавані питання

1) Яка різниця між ERR_CONNECTION_REFUSED та ERR_CONNECTION_TIMED_OUT?

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

2) Чи може ERR_CONNECTION_REFUSED бути викликаний закінченим SSL сертифікатом?

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

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

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

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

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

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

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