Сообщение «компьютер отверг запрос на подключение» (в английских версиях — connection refused) означает, что удалённая машина получила ваш сетевой пакет, но целевой порт оказался закрыт: ни одна программа не принимает на нём соединения. Это принципиально отличается от тайм-аута, когда запрос вообще не доходит до адресата, — здесь диагностика ведётся уже на стороне конкретного компьютера и конкретной службы.

Ошибка встречается в самых разных сценариях: при подключении по SSH, к веб-серверу, к базе данных, при удалённом доступе через RDP или при обращении браузера к локальному сервису вроде localhost:8080. Логика поиска причины во всех случаях одинакова: сначала проверяется, запущена ли нужная служба, затем — слушает ли она нужный порт, и только потом — не блокирует ли соединение брандмауэр.

Что технически означает отказ в подключении

Когда клиент отправляет запрос на TCP-порт, операционная система сервера проверяет, есть ли процесс, который «слушает» этот порт. Если такого процесса нет, система отвечает пакетом сброса (RST), и клиент получает connection refused. Это штатное поведение сетевого стека, а не признак поломки оборудования.

Важно различать три типа неудачного подключения:

  • 🔌 Connection refused — порт закрыт, служба не запущена или слушает другой интерфейс;
  • ⏱️ Connection timed out — пакеты не доходят: проблема с маршрутизацией, файрвол молча отбрасывает трафик, хост недоступен;
  • 🚫 Connection reset — соединение началось, но было принудительно оборвано одной из сторон.

Такое разграничение экономит время: при «refused» искать проблему в кабелях и роутере бессмысленно — сеть работает, отказ даёт сама целевая система.

Основные причины ошибки

На практике список причин невелик, и проверять их стоит в порядке от простого к сложному.

  • 🛑 Служба не запущена — самая частая причина: веб-сервер, SSH-демон или база данных просто не стартовали или завершились с ошибкой;
  • 🔢 Неверный порт — клиент обращается не туда: например, приложение работает на 8080, а запрос идёт на 80;
  • 🧱 Брандмауэр или антивирус — правило блокирует входящие соединения на нужный порт;
  • 🏠 Служба привязана только к localhost — программа слушает 127.0.0.1 и недоступна извне;
  • 🌐 Неверный адрес назначения — опечатка в IP, подключение к другой машине в сети.

Отдельный случай — служба слушает только IPv6-интерфейс, а клиент подключается по IPv4 (или наоборот). Внешне это выглядит как «порт закрыт», хотя приложение исправно работает. Проверить это можно через вывод списка слушающих сокетов, о котором ниже.

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

📊 Где вы столкнулись с ошибкой «connection refused»?
Подключение по SSH или RDP
Локальный сервер (localhost)
Веб-сервер или сайт
База данных или другое приложение

Шаг 1. Проверяем, запущена ли служба

Начните с самого вероятного: работает ли вообще программа, к которой вы подключаетесь. На Windows откройте оснастку «Службы» через services.msc и найдите нужную службу в списке — её состояние должно быть «Выполняется». Если служба остановлена, попробуйте запустить её вручную и посмотрите журнал событий на предмет ошибок старта.

На Linux состояние проверяется через системный менеджер. Для службы SSH, например:

systemctl status sshd

Если служба в состоянии failed или inactive, смотрите её журнал командой journalctl -u имя_службы — там обычно указана причина: ошибка в конфигурационном файле, занятый порт, отсутствующие ключи. Типичный сценарий: после правки конфига служба не смогла перезапуститься, и порт остался закрытым.

💡

После любой правки конфигурационного файла сетевой службы проверяйте её синтаксис встроенной командой проверки (если она предусмотрена, например sshd -t или nginx -t) — это предотвратит ситуацию, когда служба «молча» не стартует.

Шаг 2. Проверяем, слушает ли система нужный порт

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

На Windows в командной строке:

netstat -ano | findstr :8080

На Linux удобнее вывод ss:

ss -tlnp | grep 8080

Обратите внимание на колонку адреса. Значение 0.0.0.0:8080 означает, что служба принимает соединения со всех интерфейсов, а 127.0.0.1:8080 — только локальные подключения. Если вы подключаетесь с другой машины, а служба привязана к localhost, отказ гарантирован: нужно изменить параметр привязки (bind address) в конфигурации приложения.

☑️ Быстрая диагностика «connection refused»

Выполнено: 0 / 5

Шаг 3. Проверяем брандмауэр и сетевой путь

Если служба работает и порт слушается на правильном интерфейсе, следующий подозреваемый — фильтрация трафика. В Windows входящие соединения контролирует брандмауэр Защитника: откройте «Правила для входящих подключений» и проверьте, есть ли разрешающее правило для вашего порта или приложения. В Linux правила могут задаваться через iptables, nftables или надстройки вроде ufw и firewalld — конкретный инструмент зависит от дистрибутива.

Не забывайте про промежуточные устройства. Если сервер находится за роутером, для доступа извне потребуется проброс портов (port forwarding), а при работе в корпоративной сети трафик может резать сетевой экран организации — тогда вопрос решается с администратором сети.

⚠️ Внимание: проброс портов на домашнем роутере открывает службу для всего интернета. Прежде чем публиковать SSH, RDP или панель управления наружу, убедитесь, что настроена надёжная аутентификация, а лучше — используйте VPN вместо прямого проброса.

Проверить доступность порта с клиентской стороны можно командой Test-NetConnection адрес -Port 8080 в PowerShell или утилитой telnet адрес 8080, если она установлена. Ответ «TCPTestSucceeded: False» с быстрым отказом подтверждает закрытый порт.

Типичные сценарии и их решения

Разные протоколы имеют свои частые причины отказа. Сводная таблица поможет сориентироваться:

Сценарий Вероятная причина Что проверить
SSH к Linux-серверу Служба sshd остановлена или слушает нестандартный порт systemctl status sshd, директива Port в конфиге
RDP к Windows Удалённый рабочий стол отключён в настройках Параметры удалённого доступа, служба TermService
Веб-сервер (сайт) Веб-сервер не стартовал после правки конфига Журнал ошибок nginx/Apache, проверка синтаксиса конфига
База данных СУБД слушает только localhost Параметр bind-address / listen_addresses
Локальное приложение Конфликт портов: порт занят другой программой netstat -ano, поиск PID процесса

Обратите внимание на последнюю строку: если порт занят другим процессом, нужная служба не сможет его открыть и завершится с ошибкой — внешне это выглядит как обычный «connection refused». Вывод netstat -ano покажет PID процесса, удерживающего порт, после чего его можно найти в диспетчере задач.

Почему localhost работает, а подключение по IP — нет

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

Что делать, если ничего не помогло

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

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

💡

Ошибка «connection refused» — это всегда ответ целевой системы, а не сбой сети. Диагностика сводится к цепочке: служба запущена → порт слушается → интерфейс привязки верный → брандмауэр пропускает трафик.

Часто задаваемые вопросы

Чем «connection refused» отличается от «connection timed out»?

Refused означает, что сервер получил запрос, но порт закрыт — служба не слушает его. Timed out — запрос вообще не достиг цели или был молча отброшен фильтром: проблема на сетевом уровне, а не в приложении.

Почему ошибка возникает при подключении к localhost?

Даже локально порт должен кем-то слушаться. Если приложение не запущено, упало при старте или работает на другом порту, обращение к localhost вернёт тот же отказ. Проверьте процесс и занятые порты через netstat или ss.

Может ли антивирус вызывать эту ошибку?

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

Служба работает, но подключение из другой сети не проходит. В чём дело?

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

Как узнать, какая программа заняла нужный порт?

В Windows выполните netstat -ano | findstr :порт и найдите PID в последней колонке, затем сопоставьте его с процессом в диспетчере задач. В Linux команда ss -tlnp сразу показывает имя процесса рядом с портом.