ERR_CONNECTION_REFUSED: Какво означава и как да го поправите напълно

Грешката ERR_CONNECTION_REFUSED означава, че вашият браузър е изпратил заявка за свързване към уеб сървър, и този сървър активно я е отхвърлил — не я е игнорирал, а явно е отказал TCP handshake. Това е принципно различен режим на отказ от timeout (ERR_CONNECTION_TIMED_OUT) или DNS отказ (ERR_NAME_NOT_RESOLVED), и това разграничение е изключително важно при диагностициране на основната причина.

На практика, когато Chrome показва “Този сайт не може да бъде достигнат. ERR_CONNECTION_REFUSED,” това означава едно от три неща: целевият сървър не слуша на исканото портче, firewall или защитен слой изпраща TCP RST (reset) пакет обратно към вашия клиент, или вашия локален мрежов стек е неправилно конфигуриран и маршрутизира заявката неправилно преди да достигне сървъра. Определянето кое от тези три категории се отнася до вашата ситуация е най-бързия път към решение.

Разбиране на 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: Изчистете браузъра кеш и бисквитки

В Google Chrome, отидете на chrome://settings/clearBrowserData или използвайте клавишната комбинация:

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

Задайте времевия диапазон на Всичко, отметнете Кеширани изображения и файлове и Бисквитки и други данни на сайта, след това щракнете Изчистване на данни. Рестартирайте Chrome напълно (не само раздела) преди повторното тестване.

За по-бързо тестване без изчистване на данни, отворете Incognito прозорец (Ctrl + Shift + N). Ако сайтът се зарежда в Incognito, но не в нормален прозорец, кеширан ресурс или браузърно разширение е виновникът.

Стъпка 6: Одитирайте и деактивирайте настройките на прокси

Неправилно конфигуриран или мъртъв прокси сървър е честа причина за ERR_CONNECTION_REFUSED на всички уебсайтове едновременно. Chrome използва системните настройки на прокси по подразбиране.

• На Windows:

Отидете на Настройки > Система > Прокси и деактивирайте “Използване на прокси сървър”, ако е активиран без ваше знание. Алтернативно, изпълнете това от повишена Command Prompt:

netsh winhttp reset proxy

• На macOS

Отидете на System Settings > Network, изберете активния интерфейс, щракнете Details, след това раздела Proxies, и отметнете всички активни прокси протоколи.

След деактивиране на прокси, тестирайте сайта. Ако се зарежда, вашата конфигурация на прокси е била причината. Или я преконфигурирайте правилно, или я премахнете напълно.

Стъпка 7: Променете вашия DNS разрешител

Разрешителят на DNS по подразбиране на вашия интернет доставчик може да връща неправилни резултати, да изпитва прекъсване или активно да блокира определени домейни. Преминаването към публичен разрешител елиминира тази променлива.

Препоръчани публични DNS разрешители:

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

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

• На macOS:

Отидете на System Settings > Network > [Вашия интерфейс] > Details > 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 handshake в подробния изход. Отказ тук указва проблем със сертификат или cipher suite. Можете също да тестирате с:

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

Ако вашия SSL сертификат е изтекъл или е неправилно конфигуриран, неговото обновяване или замяна разрешава проблема. Убедете се, че вашите SSL Certificates са валидни, правилно верижни и инсталирани на правилния интерфейс на сървъра.

ERR_CONNECTION_REFUSED срещу подобни грешки в браузъра

Разбирането как тази грешка се различава от свързаните грешки предотвратява неправилната диагностика:

Advanced Edge Cases and Pitfalls

1) IPv6 vs. IPv4 resolution conflicts:

Ако домейн се разрешава към 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) Localhost среди за разработка:

Разработчиците често виждат 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/firewall
• Грешката се появява само на един конкретен домейн — Проверете дали сайтът е глобално недостъпен; след това изчистете DNS кеша
• Грешката се появява само в Chrome, не и в други браузъри — Изчистете Chrome кеша, деактивирайте разширенията или създайте нов Chrome профил
• Грешката се появява само в вашата мрежа, не и в мобилните данни — Рестартирайте маршрутизатора; проверете DNS на ниво ISP или firewall
• Грешката се появява след промяна на конфигурацията на сървъра — Проверете статуса на процеса на уеб сървъра, привързаност на портовете и правила на firewall на сървъра
• Грешката се появява периодично при натоварване — Разследвайте изчерпване на ресурсите (файлови дескриптори, памет, ограничения на свързване) на сървъра
• Грешката се появява само на HTTPS, не и на HTTP — Разследвайте валидността на SSL сертификата и конфигурацията на TLS
• Грешката се появи след промяна на DNS настройките — Върнете DNS промените и изчистете кеша; проверете дали новият resolver е достъпен

Често задавани въпроси

1) Каква е разликата между ERR_CONNECTION_REFUSED и ERR_CONNECTION_TIMED_OUT?

ERR_CONNECTION_REFUSED означава, че сървърът (или защитна стена) активно изпрати TCP пакет за нулиране, отхвърляйки връзката незабавно. ERR_CONNECTION_TIMED_OUT означава, че не е получен отговор в рамките на периода на изчакване — пакетите са мълчаливо отхвърлени. Отхвърлена връзка се появява по-бързо и указва активно отхвърляне, докато изчакването предполага правило за маршрутизиране или защитна стена 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 беше действително проблемът.