ERR_CONNECTION_REFUSED: что означает отказ в подключении и что проверить

ERR_CONNECTION_REFUSED появляется, когда браузер определил адрес сервера, но подключение было отклонено. Это происходит до получения веб-страницы и HTTP-кода. Поэтому искать причину только в CMS рано: сначала нужно проверить IP-адрес, порт, веб-сервер, firewall, CDN и сеть пользователя.

Ниже — порядок действий для посетителя и владельца сайта. Он помогает отличить локальную проблему от аварии на сервере и собрать факты для хостинга или администратора.

Что означает ERR_CONNECTION_REFUSED

Для открытия сайта браузер сначала получает IP-адрес домена, затем подключается к нужному сетевому порту: обычно 443 для HTTPS или 80 для HTTP. Только после успешного подключения начинаются TLS и HTTP.

ERR_CONNECTION_REFUSED означает, что попытка соединения была явно отклонена на сетевом уровне. Частый сценарий — адрес доступен, но на нужном порту нет процесса, который принимает запросы. Отказ также может вернуть firewall, прокси или другое промежуточное устройство. Браузер еще не получил ответ приложения, поэтому это не ошибка 404, 500, 502 или 503.

Само сообщение не называет виновника. Оно показывает результат одной попытки с конкретного устройства и через конкретную сеть.

Чем отказ в подключении отличается от timeout и reset

Похожие ошибки требуют разной диагностики.

• ERR_CONNECTION_REFUSED: подключение отклонено; часто ошибка появляется быстро.
• ERR_CONNECTION_TIMED_OUT: браузер не дождался подключения или ответа.
• ERR_CONNECTION_RESET: соединение принудительно сбросила одна из сторон или промежуточное устройство.
• HTTP 5xx: соединение состоялось, а веб-сервер, прокси или приложение уже вернули код ошибки.

Скорость появления сообщения — только подсказка, а не доказательство. Точный вывод делают по повторной проверке, адресу назначения, сетевой ошибке и логам.

Подробный разбор ситуации, когда браузер долго ждет, есть в статье про ERR_CONNECTION_TIMED_OUT. Не стоит исправлять refused увеличением таймаута: если порт отклоняет подключение, более долгое ожидание не запустит веб-сервер.

Основные причины ERR_CONNECTION_REFUSED

Веб-сервер остановлен или не слушает нужный порт

Nginx, Apache, Caddy или другой сервер мог завершиться после обновления, ошибки конфигурации или перезагрузки. Процесс может работать, но принимать соединения только на другом порту или локальном интерфейсе.

Практический пример: приложение запущено на внутреннем порту, а reverse proxy после изменения конфигурации не поднялся. Панель хостинга доступна, сервер включен, но посетителю некому отвечать на 443 порту.

Firewall отклоняет соединение

Правило firewall, WAF, панели хостинга или облачной сети может запрещать входящие подключения. Важно различать явное отклонение и молчаливое отбрасывание пакетов: во втором случае пользователь чаще увидит timeout.

Домен ведет на старый или неправильный IP

После переноса сайта A- или AAAA-запись может указывать на сервер, где сайт уже отключен. Тогда DNS формально работает, но новый адрес назначения отклоняет подключение.

Особенно полезно сравнить IPv4 и IPv6. Например, A-запись ведет на рабочий сервер, а забытая AAAA-запись — на хост без настроенного HTTPS. У части клиентов сайт откроется, а у тех, кто предпочтет IPv6, появится ошибка.

CDN или reverse proxy не достигает origin-сервера

Если домен работает через CDN, браузер обычно подключается к узлу CDN, а тот — к origin. При проблеме между ними пользователь может увидеть код самого CDN вместо ERR_CONNECTION_REFUSED. Но при прямой технической проверке origin отказ в подключении укажет на закрытый порт, остановленный веб-сервер или блокировку адресов CDN.

Ошибка есть только в сети пользователя

Локальный proxy, VPN, антивирусный веб-фильтр, корпоративный шлюз или измененный файл hosts может направлять запрос не туда. Если сайт открывается из других сетей, проверьте настройки конкретного устройства и сравните, какой IP получает домен.

Это не означает, что жалобу одного клиента можно игнорировать. Ограничение может затрагивать целого оператора, офисную сеть или регион, поэтому важны несколько независимых проверок.

Что может проверить посетитель

1. Записать точный URL и время ошибки.
2. Открыть сайт с другого устройства или через мобильный интернет.
3. Сравнить результат с VPN и без него, если VPN уже используется и его можно безопасно переключить.
4. Проверить, открываются ли другие сайты.
5. Передать владельцу скриншот и сообщить, повторяется ли ошибка в другой сети.

Что проверить владельцу сайта

1. Подтвердить ошибку снаружи

Сначала отделите локальный сбой от общей недоступности. Запустите внешнюю проверку сайта в Web-Puls и сравните ее с открытием из другой сети. Если соединение не установилось и HTTP-кода нет, это важный факт: диагностику нужно начинать до уровня приложения.

Ошибка может зависеть от IPv4 или IPv6, региона, узла CDN либо правила блокировки. Сравните несколько результатов и сохраните время попыток.

2. Сверить DNS с реальной инфраструктурой

Проверьте:

• A- и AAAA-записи домена;
• адреса для версии с www и без нее;
• не остался ли IP старого хостинга;
• ведет ли домен на CDN, если CDN должен быть включен;
• одинаковый ли ответ получают разные DNS-резолверы.

3. Убедиться, что порты 80 и 443 принимают соединения

Администратор сервера должен проверить, запущен ли веб-сервер и на каких адресах и портах он слушает. Если HTTPS должен работать на 443, а процесс привязан только к 127.0.0.1 или другому интерфейсу, внешнее подключение не состоится.

Сопоставьте состояние процесса, список слушающих портов и журнал запуска после последнего изменения. «Сервис запущен» недостаточно, если он слушает не тот адрес.

4. Проверить firewall, хостинг и CDN

Сопоставьте время жалобы с:

• изменениями правил firewall и облачной сети;
• автоматическими блокировками;
• релизом или перезагрузкой сервера;
• сменой IP origin;
• настройками допустимых адресов CDN;
• инцидентами в панели хостинга.

Если сайт доступен из одной сети и получает refused из другой, попросите хостинг проверить блокировки для конкретного исходного IP. Формулировка «сайт иногда не работает» менее полезна, чем URL, время, IP клиента и результат внешней проверки.

5. Сравнить HTTP и HTTPS

Если http://example.ru подключается, а https://example.ru получает отказ, вероятна проблема именно с 443 портом или HTTPS-виртуальным хостом. Если не работает только HTTP, проверьте 80 порт и сервер, который должен выполнять редирект на HTTPS.

Не делайте постоянным решением открытие сайта только по HTTP. Такое сравнение нужно для локализации сбоя, после чего следует восстановить штатный HTTPS.

Проверка через curl для администратора

Если доступна командная строка, безопасная диагностическая команда выглядит так:

curl -v --connect-timeout 10 -o /dev/null https://example.ru/

Вместо example.ru укажите свой домен. Вывод помогает увидеть, какой адрес использован, состоялось ли подключение и дошла ли проверка до TLS и HTTP. Для домена с A- и AAAA-записями можно отдельно сравнить IPv4 и IPv6:

curl -4 -v --connect-timeout 10 -o /dev/null https://example.ru/
curl -6 -v --connect-timeout 10 -o /dev/null https://example.ru/

Не публикуйте полный диагностический вывод, если в URL, заголовках или окружении есть токены и другие секреты. Для обращения в поддержку обычно достаточно времени, URL без секретных параметров, IP назначения и текста сетевой ошибки.

Как не пропустить повторный отказ

После восстановления разовая проверка показывает только текущее состояние. Проблема может вернуться после перезапуска, автоматического обновления firewall или переключения узла.

Чтобы не ждать новой жалобы, можно настроить автоматический мониторинг в Web-Puls. Он регулярно проверяет URL снаружи, хранит историю и помогает быстрее заметить момент, когда сайт перестал отвечать. Для диагностики важно смотреть не только итог «работает/не работает», но и наличие HTTP-кода, время подключения и повторяемость инцидента.

Если требуется не только зафиксировать сбой, но и восстановить веб-сервер, проверить firewall, DNS, CDN или хостинг, отправьте заявку через форму профессиональной поддержки. Альтернативный способ связи указан на странице контактов.

Вывод

ERR_CONNECTION_REFUSED означает отказ на этапе сетевого подключения, до ответа сайта и HTTP-кода. Сначала подтвердите ошибку из другой сети, затем проверьте IP домена, IPv4 и IPv6, порты 80/443, состояние веб-сервера, firewall и маршрут через CDN. Не смешивайте refused с timeout: увеличение времени ожидания не поможет порту, который не принимает соединения.

Лучший результат диагностики — не догадка, а набор фактов: точный URL, время, сеть пользователя, IP назначения, порт и результат внешней проверки. С этими данными хостинг или администратор быстрее найдет место отказа.