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 Хостинг, първо проверете списъка с процеси на сървъра и конфигурацията на защитната стена.

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

Стъпка 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 напълно (не само раздела) преди повторно тестване.

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

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

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

На Windows:

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

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 сертификати са валидни, правилно верифицирани и инсталирани на правилния сървърен интерфейс.

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

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

Разширени гранични случаи и клопки

Конфликти при разрешаване на IPv6 срещу IPv4: Ако даден домейн се разрешава към IPv6 адрес, но мрежата ви не поддържа правилно IPv6, Chrome може да опита IPv6 връзка, която бива отказана, след което да не успее бързо да се върне към IPv4. Временното деактивиране на IPv6 на мрежовия адаптер може да потвърди това. На Linux можете да принудите IPv4 с curl -4 https://example.com.

Кеширане на остарели грешки от произхода от Cloudflare или CDN: Ако даден сайт използва Cloudflare и изходният сървър спре, Cloudflare може известно време да обслужва кеширана версия, след което да започне да връща грешки 521 (изходът е отказал връзка) или 522, които Chrome може да показва като ERR_CONNECTION_REFUSED в зависимост от начина, по който грешката се проксира.

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

Конфликти на портове на имейл сървъра: Ако управлявате Имейл хостинг на същия сървър като уеб приложението си, уверете се, че конфликтите на портове между SMTP (25, 587), IMAP (993) и HTTP/HTTPS (80, 443) не причиняват неуспех при свързването на уеб сървъра.

Ограничения на споделения хостинг: В среди за Споделен уеб хостинг, отказ на връзка може да означава, че сървърът на хостинг доставчика е претоварен, акаунтът е спрян или DNS на домейна все още не сочи към правилния споделен IP. Проверете контролния панел на хостинга за статуса на акаунта и DNS конфигурацията.

Практическа матрица за решения: Кое решение да приложите първо

Използвайте този контролен списък за ефективна триажа:

• Грешката се появява на всички уебсайтове едновременно — Първо проверете настройките на прокси и конфигурацията на VPN/защитна стена
• Грешката се появява само на един конкретен домейн — Проверете дали сайтът е глобално недостъпен; след това изчистете DNS кеша
• Грешката се появява само в Chrome, не в други браузъри — Изчистете кеша на Chrome, деактивирайте разширенията или създайте нов профил в Chrome
• Грешката се появява само в мрежата ви, не при мобилни данни — Рестартирайте рутера; проверете DNS или защитната стена на ниво ISP
• Грешката се появява след промяна в конфигурацията на сървъра — Проверете статуса на процеса на уеб сървъра, свързванията на портове и правилата на защитната стена на сървъра
• Грешката се появява периодично при натоварване — Разследвайте изчерпването на ресурси (файлови дескриптори, памет, ограничения на връзките) на сървъра
• Грешката се появява само при HTTPS, не при HTTP — Разследвайте валидността на SSL сертификата и TLS конфигурацията
• Грешката се появи след промяна на DNS настройките — Върнете DNS промените и изчистете кеша; проверете дали новият резолвер е достъпен

ЧЗВ

Каква е разликата между 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 действително е бил проблемът.