ERR_CONNECTION_REFUSED что это за ошибка и как быстро исправить

Фраза выглядит пугающе, хотя смысл довольно приземлённый. Браузер постучался к сайту и получил отказ на уровне соединения. Не пустил не браузер и не сам сайт в смысле страницы, а компьютер на стороне сервера или устройство на пути до него. Проще говоря, дверь есть, звонок сработал, но изнутри кто-то нажал кнопку отказ.

Техническая картина такая. Браузер пытается установить TCP соединение на нужный порт, чаще это 443 для HTTPS. В ответ приходит явный отказ. Обычная причина в том, что на порту никто не слушает или межсетевой экран на стороне сервера режет подключения. Иногда отказывает локальный софт на вашей стороне. Например, корпоративный агент безопасности, локальный прокси или расширение, которое вмешивается в трафик.

Важно различать отказ соединения и ошибки уровня HTTP. Если сайт отвечает кодом 403 или 500, значит до приложения мы добрались и сервер нам что-то сказал. При ERR_CONNECTION_REFUSED до приложения дело не дошло. Нас остановили у порога, не выдав даже «официальную» страницу с объяснением.

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

Из хорошего здесь одно. Ошибка вполне детерминирована. Если найти тот узел, который нажимает кнопку отказ, починка обычно проходит быстро. Важно идти по шагам и не хвататься сразу за экзотические трюки.

Чем это отличается от ERR_CONNECTION_TIMED_OUT и от кодов 4xx или 5xx

Путаница возникает постоянно. При таймауте соединение никто не отверг, просто не ответили вовремя. Это похоже на звонок в дверь без реакции. Такое случается при перегрузке, проблемах маршрутизации, нестабильном мобильном интернете или когда сервер завис. При отказе же система бодро возвращает «нет» сразу. Это активный и быстрый ответ, а не молчание.

HTTP коды вроде 404, 403, 500 относятся уже к диалогу между браузером и приложением. Дверь открылась, а внутри администратор сказал нет доступа или случилась ошибка. Поэтому советы для таких случаев другие. Там помогают вход по аккаунту, чистка куки, проверка прав, а не пляски вокруг сетевых портов.

Есть и ещё одно наблюдение. ERR_CONNECTION_REFUSED часто появляется точечно. Главная открывается, а личный кабинет падает. Или по HTTP всё живо, а HTTPS отказывает. Это признак того, что конкретный сервис не слушает свой порт или его блокирует ограничение по адресу, диапазону, стране. Иногда блок срабатывает у провайдера, иногда у CDN, иногда у корпоративного фильтра.

Иногда ошибка прячется за расширениями. Менеджеры паролей, блокировщики рекламы, VPN и инспекторы трафика умеют перехватывать запросы. Если расширение работает нестабильно, браузер получит отказ от локального посредника. Поэтому частое решение выглядит скучно. Запускаем чистый профиль, отключаем расширения, пробуем гостевой режим.

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

Пошаговая диагностика дома и в офисе

Начните с простого. Проверьте адрес и протокол. Если в закладке осталась старая ссылка с портом или схемой http, откройте домен вручную без всего лишнего. Попробуйте и https и http. Иногда производится принудительное перенаправление, и на этом шаге станет ясно, где всё ломается.

Дальше исключаем локальные вмешательства. Откройте сайт в режиме инкогнито или в другом браузере. Отключите расширения на один запуск. На Windows проверьте настройки прокси и параметр автоматического обнаружения. На macOS загляните в раздел сети, вдруг включён старый корпоративный профиль. Если используете VPN, остановите его и повторите попытку.

Проверьте DNS. Сбой резолвинга иногда маскируется под отказ соединения. На Windows помогает сброс DNS и стека Winsock. Это делается в командной строке с правами администратора командой ipconfig /flushdns и затем netsh winsock reset с перезагрузкой. На macOS очистка кэша проходит командой sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder. На Android загляните в раздел Частный DNS и временно выключите его, чтобы проверить, не в нём ли причина. Для справки можно открыть официальные инструкции по Chrome и Android в справке Google и по сетям Mac на сайте Apple — Chrome Help, Android Private DNS, Apple Support.

Теперь смотрим на защитное ПО. Антивирусы и брандмауэры любят ставить фильтр-прокси. Отключите проверку HTTPS на минуту и повторите вход на сайт. Если помогло, добавьте сайт в исключения или обновите сертификаты в продукте безопасности. В корпоративной сети сверяйтесь с политиками и списками разрешённых доменов, они тоже могут возвращать отказ.

Если ничего из этого не сработало, меняем среду. Подключитесь через мобильный интернет, попросите знакомого с другой сети открыть тот же адрес, либо используйте другой провайдер. Работает везде кроме вашей сети — значит, вероятен фильтр со стороны провайдера или роутера. Перезагрузите роутер, отключите на нём фильтры и родительский контроль, проверьте настройки DNS. На некоторых моделях помогает временное отключение аппаратного ускорения NAT.

• Windows быстрый чек. Команды ipconfig /flushdns и netsh winsock reset с перезагрузкой. Проверка прокси в Параметры сети и интернет. Временно отключаем антивирусный фильтр HTTPS. Официальная база знаний Microsoft по Winsock находится на сайте поддержки Microsoft.
• macOS быстрый чек. Сброс DNS командами из абзаца выше. Проверяем профили и VPN в Сетях. Меняем DNS на публичные и возвращаем назад, чтобы обновить кэш.
• Android быстрый чек. Отключаем Частный DNS, проверяем без VPN, чистим кэш приложения браузера. Включаем мобильные данные вместо Wi-Fi для сравнения.
• Браузерный чек. Гостевой режим. Отключены все расширения. Временное отключение защищённого DNS в настройках браузера. На Firefox можно свериться с официальной справкой Mozilla по сетевым ошибкам — support.mozilla.org.

Если вы владелец сайта и получаете жалобы на отказ соединения

Самая частая причина на стороне сервера звучит прозаично. Сервис не слушает порт. В журнале процесс упал, система подняла его заново, но он слушает только localhost, а внешний интерфейс пуст. Проверьте конфигурацию и директивы прослушивания. В Nginx это listen с указанием адреса, в Apache VirtualHost с правильным IP и портом.

Следующий кандидат это брандмауэр. На Linux проверьте правила nftables или iptables, на простых конфигурациях — UFW. В облаке проверьте группы безопасности и сетевые ACL. Порт может быть закрыт где-нибудь на входе, и вы это не заметите из локального curl. Для быстрой проверки используйте внешний мониторинг с нескольких регионов.

CDN и проксирующие сервисы иногда режут подключения до вашего origin. Причина в лимитах, в защите от ботов или в несоответствии TLS. Проверьте соединение от балансировщика до бэкенда. Убедитесь, что сертификаты и наборы шифров совпадают с ожидаемыми, а origin отвечает быстро. Полезно заглянуть в официальную документацию вашего CDN. Для Cloudflare это раздел для разработчиков — developers.cloudflare.com, для Nginx — nginx.org, для Apache — httpd.apache.org.

Отказы на пике часто рождаются из-за исчерпания ресурсов. Кончились файловые дескрипторы, система перестала выдавать новые соединения и начала отказывать сразу. Проверьте лимиты, метрики сокетов в TIME_WAIT, очередь на accept. Расставьте алерты. Масштабирование по горизонтали обходится дешевле, чем расследования в авральном режиме.

Не забывайте про инфраструктурные мелочи. Контейнер проброшен не на тот порт. В Kubernetes не совпадают targetPort и port в Service. Межсетевой экран на уровне узла конфликтует с правилами кластера. Эти ситуации легко ловятся простым тестом из внешней сети с помощью curl и утилиты проверки портов. Главное проверять именно тот маршрут, по которому ходят пользователи.

• Проверка прослушивания. ss -ltnp или netstat -ltnp покажут, кто слушает 443 и на каком адресе.
• Брандмауэр. Просмотрите правила UFW, iptables или nftables и правила в облачном провайдере.
• Журналы сервисов. journalctl -u nginx или аналог для вашего веб-сервера и бэкенда.
• Лимиты. Проверьте ulimit, системные лимиты файловых дескрипторов и параметры ядра для сокетов.

Короткий чек-лист и частые вопросы

Если нужна быстрая победа, идите сверху вниз. Чистый браузер без расширений, другой канал связи, сброс DNS и Winsock, временное отключение фильтра HTTPS, проверка роутера и его DNS. Уже это решает большинство случаев у домашних пользователей. Для офисных сетей полезно сверить прокси и политики безопасности, особенно если домен новый.

Что делать, если сайт открывается у всех, кроме вас. Это напоминает локальный фильтр или кэш. Проверьте частный DNS, VPN, прокси, расширения и защиту. Обновите сертификаты в антивирусе, если он перехватывает HTTPS. Сбросьте кэш роутера через перезагрузку. Поменяйте DNS на время, затем верните обратно.

Нужно ли отключать брандмауэр. Не навсегда. Только как короткий тест. Если после отключения всё работает, настройте корректные исключения и включите защиту обратно. Никогда не оставляйте систему без брандмауэра ради удобства.

Можно ли обойти отказ через мобильный интернет или VPN. Как тест это полезно. Если так работает, значит проблема не в сайте. Но постоянный обход не лечит причину. Лучше найти и устранить фильтр либо дождаться исправления на стороне сервера.

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

• Где посмотреть официальные советы по браузеру. Для Chrome есть раздел о сетевых ошибках в справке Google. Для Firefox советы на портале поддержки Mozilla. Для macOS по сетям и DNS помогает база знаний Apple. Ссылки выше в тексте.
• Чем ERR_CONNECTION_REFUSED отличается от 403. В первом случае сервер на порт не пустил. Во втором вы вошли на сайт, но не получили доступ к ресурсу.
• Почему главная работает, а раздел падает. Разные порты, разные подсервисы, разные правила доступа. Чаще всего проблема в конфигурации балансировщика или в упавшем бэкенде.
• Опасно ли это. Нет, сама ошибка не про взлом. Это про недоступность конкретного соединения. Опасность только в том, что вы теряете доступ к нужной информации или сервису.