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

Для более быстрого теста без очистки данных откройте окно Incognito (Ctrl + Shift + N). Если сайт загружается в Incognito, но не в обычном окне, виноват кэшированный ресурс или расширение браузера.

Шаг 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 vs. Похожие ошибки браузера

Понимание того, чем эта ошибка отличается от связанных ошибок, предотвращает неправильный диагноз:

Advanced Edge Cases and Pitfalls

1) Конфликты разрешения IPv6 и IPv4:

Если домен разрешается на адрес IPv6, но ваша сеть не поддерживает IPv6 должным образом, Chrome может попытаться установить соединение IPv6, которое будет отклонено, а затем не сможет быстро вернуться к IPv4. Временное отключение IPv6 на сетевом адаптере может подтвердить это. В Linux вы можете принудительно использовать IPv4 с помощью curl -4 https://example.com.

2) Кэширование Cloudflare или CDN устаревших ошибок источника:

Если сайт использует Cloudflare и исходный сервер выходит из строя, Cloudflare может некоторое время обслуживать кэшированную версию, а затем начать возвращать ошибки 521 (источник отказал в соединении) или 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 действительно проблемой.