SiteGuard4 ноября 202613 мин чтения

ERR_CONNECTION_REFUSED: что делать, если сайт отклонил подключение

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

Посетителю стоит сначала проверить адрес и понять, где повторяется сбой. Владельцу сайта — сопоставить публичный адрес с работающей службой и правилами доступа. Такой порядок позволяет быстрее найти причину и не менять исправные настройки. Ниже — последовательная инструкция для обычного сайта, локального проекта и приложения в Docker.

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

В списке сетевых ошибок Chromium CONNECTION_REFUSED соответствует числу −102 и описывает отклонённую попытку соединения. Это внутренний код сетевого стека браузера. Он не относится к HTTP-статусам, которые сервер возвращает в ответ на запрос страницы.

Представьте адрес сайта как сочетание имени, протокола и порта. Для HTTPS по умолчанию используется порт 443, для HTTP — 80. Если приложение запущено на другом порту, а браузер обращается к стандартному, можно получить отказ даже на полностью работающем компьютере. Наличие сервера в панели хостинга ещё не подтверждает, что нужная служба принимает подключения.

Типичная причина — на выбранном адресе и порту никто не слушает соединения. Это может произойти после остановки процесса, неудачного запуска или изменения настроек. Но сообщение не доказывает, что отказ отправило именно приложение: сетевой фильтр тоже способен явно отклонить попытку. В частности, документация iptables описывает REJECT с ответом TCP RST. Чтобы установить источник, нужны дополнительные наблюдения.

Сообщение	Что оно помогает различить	Основное направление проверки
ERR_CONNECTION_REFUSED	Попытка соединения отклонена	Адрес, порт, слушающая служба, правила отказа
ERR_CONNECTION_TIMED_OUT	Подключение не завершилось за отведённое время	Доступность пути и ответ на попытку подключения
ERR_CONNECTION_RESET	Соединение сброшено	Обстоятельства разрыва и участвующие сетевые узлы
HTTP 403 Forbidden	Получен HTTP-ответ с запретом выполнения запроса	Права доступа и политика приложения или прокси

Разница с HTTP 403 особенно важна. При 403 сервер или посредник уже ответил по HTTP. При отказе в соединении искать ошибку только в пароле, роли пользователя или содержимом страницы преждевременно. Одинаковое слово «отказ» в русском сообщении обозначает разные этапы взаимодействия.

Что делать посетителю, если сайт отклонил подключение

1. Сохраните точный адрес и проверьте его

Посмотрите на всю адресную строку: домен, поддомен, протокол и число после двоеточия, если оно есть. Ссылка на старую административную панель или тестовый порт может перестать работать, хотя основной сайт доступен. Откройте официальный адрес из проверенного источника. Не заменяйте HTTPS на HTTP для входа или оплаты: это не исправляет причину отказа и меняет условия безопасности соединения.

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

2. Определите масштаб сбоя

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

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

3. Сопоставьте результаты

Ошибка только в одном браузере. Проверьте его профиль, расширения, параметры подключения и корпоративные политики.
Ошибка на нескольких устройствах одной сети. Имеет смысл проверить маршрутизатор, настройки доступа и используемый сетевой посредник.
Отказ повторяется из разных сетей. Передайте наблюдения владельцу сайта: вероятность общей проблемы на стороне публикации сервиса выше.
Не открывается только один нестандартный порт. Проверьте, предусмотрен ли такой адрес официальной инструкцией сервиса.

Эти результаты сужают поиск, но не выносят окончательный диагноз. Два подключения могут получить разные IP-адреса одного домена или пройти через разные узлы. Успешное открытие с телефона не доказывает исправность всех серверов сайта; неуспех на двух устройствах также не доказывает блокировку провайдером.

4. Отправьте владельцу полезное описание

Укажите время с часовым поясом, конечный адрес, полный код ошибки, браузер и результаты сравнения сетей. Можно приложить снимок окна без личных данных. В справке Chrome обращение к владельцу рекомендуется для проблем отдельного сайта. Не передавайте пароли, cookies и содержимое личного кабинета: для первоначальной проверки отказа они обычно не нужны.

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

Если ERR_CONNECTION_REFUSED появляется только в Chrome, Яндекс Браузере или на телефоне

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

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

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

На телефоне сравнение Wi-Fi и мобильной сети полезно как диагностический шаг. Если отличается только сеть, проверьте её ограничения и адрес назначения. Если ссылка содержит localhost или 127.0.0.1, переход на мобильную связь не поможет: такой адрес обозначает сам телефон, а не компьютер разработчика. Для этой ситуации нужен корректный адрес локального проекта.

Очистка cookies не запускает остановленный веб-сервер и не открывает порт. Массовый сброс сетевых настроек тоже не стоит делать первым действием: он может удалить рабочую конфигурацию и усложнить сравнение. Такие меры оправданы только после подтверждения проблемы соответствующего компонента, а не по самому тексту ERR_CONNECTION_REFUSED.

Как владельцу сайта найти причину отказа

Шаг 1. Зафиксируйте точку назначения

Запишите домен, протокол, порт и IP-адрес, к которому выполняется проблемная попытка. Сопоставьте их с текущей схемой размещения. После переезда DNS может указывать на прежний сервер, где веб-служба уже выключена. Здесь требуется исправить обнаруженное несоответствие; случайная смена DNS-сервера на компьютере посетителя не заменяет проверку правильности публикации.

Если домен имеет IPv4- и IPv6-адреса, проверьте оба направления раздельно. Служба может принимать соединения только в одном из них. При использовании CDN или балансировщика публичное имя ведёт на посредника, поэтому проверка этого имени и проверка origin отвечают на разные вопросы. Прямой доступ к origin может быть намеренно ограничен.

Шаг 2. Проверьте TCP-подключение к своему сервису

В Windows для одиночной проверки собственного узла можно использовать PowerShell. Замените пример своим доменом и нужным портом:

Test-NetConnection -ComputerName "example.com" -Port 443 -InformationLevel Detailed

По документации Microsoft, команда показывает диагностические сведения, включая результат TCP-проверки. Посмотрите на RemoteAddress, RemotePort и TcpTestSucceeded. Значение True подтверждает установление TCP-соединения в данной попытке, но не правильность сертификата, HTTP-ответа или работы приложения. Значение False само по себе не отличает явный отказ от таймаута и других причин неуспеха. Учтите, что эта проверка может идти другим путём, чем браузер с настроенным прокси, поэтому сравнивайте условия подключения.

Обычный ping не заменяет эту проверку: он не проверяет веб-службу на порту 443. Сервер может отвечать на ping и одновременно не принимать HTTPS. Обратная ситуация также возможна. Сравнивайте именно необходимый адрес и порт, а результат сохраняйте вместе со временем проверки.

Шаг 3. Убедитесь, что нужный порт действительно слушается

На собственном Linux-сервере список слушающих TCP-сокетов можно посмотреть командой:

ss -ltn

Параметры означают слушающие сокеты, TCP и числовое отображение адресов; они описаны в руководстве ss. Ищите нужный порт и адрес привязки. Если ожидаемой строки нет, выясните, запущен ли нужный процесс, завершился ли старт успешно и совпадает ли используемый порт с конфигурацией. Для контейнера проверяйте также соответствующее сетевое окружение. Публикация через сетевые правила Docker не обязательно отображается как отдельный слушатель на хосте, поэтому сопоставьте вывод с конфигурацией публикации.

Наличие строки с 127.0.0.1 означает привязку к локальному IPv4-адресу. Это подходит для внутреннего приложения за прокси, но не делает сервис доступным напрямую через внешний адрес. В Nginx адрес и порт приёма задаёт директива listen. Изменение только server_name не исправляет отсутствие слушателя на нужном порту.

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

Шаг 4. Сопоставьте внутренний и внешний доступ

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

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

Шаг 5. Проверьте, на каком участке возник отказ

Сообщение connection refused в журнале обратного прокси и ERR_CONNECTION_REFUSED в браузере посетителя — разные наблюдения. В первом случае прокси мог принять пользовательское соединение, а затем не подключиться к приложению и вернуть HTTP 502. Поэтому сопоставляйте браузерный результат с журналами нужного компонента, а не ищите одинаковую надпись во всей системе.

Отсутствие записи в HTTP access log совместимо с отказом до обработки запроса, но не доказывает его причину: могла проверяться другая машина, а журнал мог быть отключён. Если слушатель и правила выглядят корректно, следующий шаг администратора — анализ сетевых событий или ограниченная запись трафика на нужном узле с соблюдением правил доступа к данным.

ERR_CONNECTION_REFUSED на localhost и в Docker

Локальный проект на компьютере

Localhost относится к устройству или сетевому окружению, из которого выполняется подключение. Для проекта на ноутбуке проверьте, запущен ли сервер разработки, какой адрес он сообщил при старте и не завершился ли процесс с ошибкой. Порт 3000 в сохранённой закладке не подойдёт, если текущий запуск использует 3001.

Учитывайте различие 127.0.0.1 и ::1: это локальные адреса IPv4 и IPv6. Имя localhost может разрешаться в оба, а приложение — слушать только один. Сопоставьте фактический адрес с настройкой сервера. Это повод исправить согласованность конфигурации, а не отключать IPv6 целиком на устройстве.

Проверка с другого устройства

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

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

Приложение в контейнере

У контейнера своё сетевое окружение: localhost внутри него обычно означает сам контейнер. Чтобы попасть из браузера на хосте в контейнер, проверьте публикацию порта. В документации Docker сопоставление 8080:80 означает порт 8080 хоста и порт 80 контейнера. Одного указания EXPOSE недостаточно для публикации на хосте.

Посмотрите состояние контейнера и отображение портов через docker ps -a. Если контейнер остановлен, сначала изучите причину завершения. Если он работает, проверьте порт приложения внутри и выбранную публикацию снаружи. Для доступа только с компьютера разработчика используйте предназначенную для этого локальную привязку; публикация на всех интерфейсах расширяет доступ и требует отдельного обоснования.

Для подключения из контейнера к службе хоста Docker Desktop документирует имя host.docker.internal. Его наличие и поведение зависят от окружения, поэтому не переносите настройку автоматически на любой сервер. И отдельно проверьте адрес API во фронтенде: JavaScript в браузере пользователя обращается к localhost пользователя, даже если сам сайт размещён в контейнере.

Пример: сайт перестал открываться после переноса

Предположим, после переноса конфигурации HTTPS-адрес выдаёт ERR_CONNECTION_REFUSED из двух разных сетей. Панель хостинга показывает работающий сервер, а HTTP-адрес перенаправляет посетителя на HTTPS. Эти наблюдения ещё не объясняют причину, но выделяют конкретную точку проверки: подключение к публичному адресу на порту 443.

Администратор сверяет DNS, убеждается, что проверки идут на новый узел, и смотрит слушающие сокеты. В этом условном примере порт 80 есть, а 443 отсутствует. Журнал запуска показывает, что конфигурация HTTPS не была подключена к работающему экземпляру веб-сервера. Исправление состоит в восстановлении правильной конфигурации и штатном применении изменений после проверки.

Затем администратор проверяет доступность именно HTTPS, корректность сертификата и нужную страницу из внешней сети. Очистка cookies у посетителей, увеличение таймаута и изменение прав пользователя здесь ничего бы не исправили: они относятся к другим условиям. Ценность диагностики в том, что каждое действие подтверждает конкретную гипотезу.

Как обнаруживать повторные отказы и проверять восстановление

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

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

Зафиксируйте установленную причину и исправление в инструкции проекта: нужный адрес, порт, способ запуска и ожидаемые правила доступа. После следующих изменений повторяйте короткую проверку публикации. Это особенно полезно, если приложение работает за несколькими посредниками и внутреннее состояние службы не совпадает с доступностью для клиента.

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

ERR_CONNECTION_REFUSED означает, что меня заблокировали?

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

Почему ошибка появилась сразу, без долгой загрузки?

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

Поможет ли очистка DNS-кэша?

Она имеет смысл, если подтверждено, что устройство использует устаревший адрес после изменения DNS. Если адрес верный, а служба на нужном порту остановлена, очистка кэша не поможет. Сначала сравните фактический адрес назначения с актуальной конфигурацией сайта.

Почему на сервере всё работает, а снаружи — отказ?

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

Как понять, что проблема устранена полностью?

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