ERR_CONNECTION_REFUSED: почему браузер не может подключиться и как это исправить

ERR_CONNECTION_REFUSED — ошибка более низкого уровня, чем привычные 404 и 502: сервер не просто отдал ошибку, он вообще отказался разговаривать. До HTTP дело не дошло. Хорошая новость: список причин конечен и проверяется по шагам. Разбираем со стороны посетителя и со стороны владельца сайта — с командами и типовыми сценариями.

Что происходит на уровне сети

Прежде чем показать страницу, браузер делает три шага: узнаёт IP-адрес по имени домена (DNS), устанавливает TCP-соединение с этим адресом на порт 443 или 80 и только потом отправляет HTTP-запрос. ERR_CONNECTION_REFUSED возникает на втором шаге: адрес известен, компьютер по этому адресу существует и отвечает — но на нужном порту никто не слушает, и система сервера явно отвечает «отказ» (TCP RST). Образно: вы дозвонились до здания, но в нужном кабинете бросают трубку. Этим ошибка отличается от родственников: при DNS_PROBE_FINISHED_NXDOMAIN не находится сам адрес, при ERR_CONNECTION_TIMED_OUT — никто не берёт трубку вовсе, а при 502 разговор состоялся, просто ответили ерундой.

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

В отличие от 5xx-ошибок, здесь причина бывает и на вашей стороне — поэтому есть что проверять. Идите по шагам, после каждого пробуя открыть сайт заново.

Если после всех пяти шагов ошибка на месте и с других устройств сайт тоже не открывается — дело на стороне сайта, и дальше уже зона ответственности владельца.

Если вы владелец: кто не слушает порт

Со стороны сервера ERR_CONNECTION_REFUSED у посетителей означает одно из трёх. Первое и самое частое — веб-сервер не запущен: упал и не поднялся после перезагрузки машины, не стартовал из-за ошибки в конфиге (nginx с битым конфигом просто не запускается). Второе — слушает не то: конфигурацию меняли, и сервис поднялся только на 80-м порту без 443, или привязался к localhost вместо внешнего адреса. Третье — файрвол: правило закрыло 443-й порт для всех или для части сетей. Диагностика — три команды с самого сервера:

# Жив ли веб-сервер
systemctl status nginx

# Кто слушает 80 и 443 порты
ss -tlnp | grep -E ':80|:443'

# Виден ли порт снаружи (запускать НЕ с сервера)
nc -zv example.ru 443

Если ss показывает, что порт слушается, а снаружи nc получает отказ, — между сервером и миром стоит файрвол или панель хостинга с собственными правилами. Отдельный коварный случай — порт закрыт не для всех, а выборочно: например, файрвол зарезал диапазоны адресов, в которые попала часть посетителей или ваш мониторинг. Симптоматика тогда в точности как у истории с WAF: «у одних работает, у других отказ». Что вообще такое порты и почему за открытыми нужно следить — мы разбирали в статье про порты.

Одна ошибка — разные имена

Полезно узнавать эту ошибку в лицо во всех обличиях — тогда жалобы из разных источников складываются в одну картину:

Последняя строка — важная примета для владельца: в access-логе веб-сервера таких запросов нет вообще. Сервер их не видел — отказ произошёл раньше. Если жалоб много, а лог чист, это не «пользователи выдумывают», это как раз почерк отказа соединения: ищите на уровне файрвола, портов и самого факта запущенности сервиса, а не в приложении.

Почему эту ошибку особенно легко не заметить

Когда сайт отдаёт 502 или 503, что-то всё-таки отвечает — ошибку видно, её кто-нибудь скриншотит и присылает. Отказ соединения выглядит иначе: браузер посетителя молча показывает серую страницу, человек решает «не работает интернет» и уходит, ничего вам не сообщив. При частичном отказе (закрыт порт для части сетей) сайт может терять посетителей неделями при формально «работающем» сервере. Единственный надёжный детектор — регулярные попытки соединения снаружи, из разных сетей: TCP-проверка порта отвечает ровно на тот вопрос, на котором ломается эта ошибка, — «пускают ли вообще внутрь».

Частые вопросы

ERR_CONNECTION_REFUSED — это блокировка сайта? Обычно нет: блокировки чаще проявляются как таймаут или ошибка сброса соединения на этапе TLS. Но исключать нельзя — если сайт открывается через другую сеть и не открывается через вашего оператора, картина похожа на фильтрацию. Сравните из двух-трёх сетей, прежде чем делать выводы.

Почему сайт открывается по HTTP, а по HTTPS — отказ? Веб-сервер слушает 80-й порт, но не слушает 443-й: сертификат не настроен, либо в конфиге нет ssl-секции, либо 443 закрыт файрволом. Проверьте ss -tlnp на сервере.

Локальный сайт (localhost) даёт ERR_CONNECTION_REFUSED. Это то же самое? Механика та же: на порту, куда стучится браузер, никто не слушает. Не запущен dev-сервер, занят/изменён порт, слушается только 127.0.0.1 при обращении по имени машины — типовые причины на локалке.

Как застраховаться от этой ошибки на будущее? Три привычки: включить автозагрузку всех сервисов и проверять её после переездов (systemctl is-enabled nginx); всегда тестировать конфиг перед применением (nginx -t — битый конфиг тогда просто не применится, вместо того чтобы уронить сервис при следующем рестарте); и держать внешнюю TCP-проверку порта, которая заметит отказ раньше первого недовольного клиента.

Ошибка появляется периодически, раз в несколько минут. Что это? Похоже на нестабильный процесс, который падает и перезапускается супервизором, или на балансировщик с одним мёртвым бэкендом из нескольких. Смотрите историю внешних проверок и логи перезапусков — периодичность сама укажет на виновника.