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

Ситуация знакомая: сервис “вроде поднят”, IP правильный, домен резолвится, а подключение висит или сразу отваливается. И вот вы уже спорите с провайдером, девопсом и самим собой, хотя вопрос простой: доступен ли конкретный порт на удаленном IP. Ниже разберем, как проверять порты быстро, аккуратно и так, чтобы по результатам было понятно, что именно сломалось.

1) Что вообще значит “порт доступен” и почему это не всегда “open”

Для TCP порт “доступен” обычно означает: вы можете установить соединение (тройное рукопожатие) и получить предсказуемый ответ приложения. Для UDP все хитрее: “тишина” может значить и “все ок”, и “фильтруют”, и “сервис не отвечает”. Поэтому в 2026 году проверка порта это не одна команда, а маленькая цепочка: сеть, фильтры, сервис, приложение.

Важно отличать три состояния. “Open” обычно говорит, что на порту что-то слушает и отвечает. “Closed” значит, что хост достижим, но порт закрыт (нет слушателя, либо система явно отвергает). “Filtered” намекает, что где-то на пути режут пакеты (фаервол, security group, ACL, провайдерская фильтрация), и вы не получаете нормального подтверждения ни в одну сторону.

Еще одна ловушка: NAT и проброс портов. На внешнем IP может быть открыт 443, но он уходит на другой внутренний адрес. Или наоборот: на сервере сервис слушает только на 127.0.0.1, и снаружи вы увидите “closed/filtered”, хотя локально “все работает”.

Не забывайте про “порт открыт, но сервис не ваш”. На популярных портах иногда торчит прокси, WAF или чей-то старый демо-сервис. Поэтому проверять стоит не только факт соединения, но и то, что ответ действительно от нужного приложения.

Чтобы быстрее ориентироваться в результатах, держите под рукой мини-шпаргалку:

2) Быстрая проверка “с ноутбука”: nc, curl, bash и немного здравого смысла

Если нужно понять “живой порт или нет” за 10 секунд, чаще всего хватает netcat. Он прост, есть почти везде и честно показывает: удалось ли установить TCP-сессию. Хороший вариант для проверки SSH, RDP, PostgreSQL, Redis (если вы точно понимаете, что делаете) и любых кастомных TCP-сервисов.

Для TCP используйте режим “просто подключиться” с таймаутом. Ключевая идея: не ждите минутами. Если порт доступен, рукопожатие обычно происходит быстро, а если его режут, тоже станет понятно почти сразу.

Примеры команд:

nc -vz -w 2 203.0.113.10 22
 nc -vz -w 2 example.com 443

Если проверяете HTTP/HTTPS, лучше спросить сервис по-человечески через curl. Так вы одновременно проверите DNS, TLS и поведение приложения. На практике это быстрее, чем гадать по одному “open”.

curl -I --max-time 3 http://203.0.113.10:8080/
 curl -Ik --max-time 3 https://example.com/

Есть и “ленивый” способ без утилит, если у вас bash: встроенный /dev/tcp. Он не заменяет диагностику, но иногда спасает на минимальных системах.

timeout 2 bash -c 'cat < /dev/null > /dev/tcp/203.0.113.10/22' && echo OK || echo FAIL

Мини-чеклист, чтобы не обмануть себя:

• Проверяйте по имени и по IP: DNS может вести не туда.
• Добавляйте таймаут: “висит” и “не доступен” разные истории.
• Если порт “open”, подтвердите ответ приложением (curl, баннер, протокол).
• Если вы в корпоративной сети, попробуйте ту же проверку с мобильного интернета: иногда режут на выходе.

А если я на Windows? PowerShell спешит на помощь

Вам не обязательно ставить сторонний софт или Telnet. В современной Windows (10/11/Server) есть мощная встроенная команда Test-NetConnection (или коротко tnc).

Test-NetConnection -ComputerName 203.0.113.10 -Port 443

Если лень писать полностью, используйте алиас:

tnc example.com -p 443

Смотрите на строку TcpTestSucceeded. Если True - порт открыт. Если False - ищите детали в поле PingSucceeded (возможно, сервер жив, но порт закрыт).

3) Nmap без лишнего шума: точечный скан, чтение результатов и типовые ловушки

Когда “быстрые” команды дают странные результаты, в игру входит nmap. Важно использовать его точечно. Вам почти никогда не нужен скан “всех портов всего интернета”. Вам нужен один IP и один порт, максимум небольшой список, чтобы не превратить диагностику в атаку на чужую инфраструктуру.

Самый безопасный и понятный режим для TCP проверки конкретного порта выглядит так:

nmap -Pn -p 22,80,443 203.0.113.10

Ключ -Pn говорит “не пытайся пинговать, считай хост доступным”. Это полезно, когда ICMP фильтруется, но сервисы живые. Если оставить дефолт, nmap может решить, что хоста “нет”, хотя на самом деле просто запрещен ping.

Если хочется больше деталей по сервису (но все еще аккуратно), добавьте определение версии. Это поможет понять, что именно отвечает на порту. Например, бывает, что 443 открыт, но там не HTTPS, а какой-нибудь прокси или кастомный протокол.

nmap -Pn -p 443 -sV 203.0.113.10

Для UDP проверка всегда более вероятностная. Nmap умеет, но результаты трактуются осторожно: “open|filtered” часто означает “я не получил явного отказа”. Если вам критично проверять UDP (например, DNS 53, NTP 123), лучше сочетать nmap с прикладными запросами (dig, nslookup, ntpdate/chronyc) и логами на сервере.

Что делать, если nmap показывает filtered, а вы уверены, что порт открыт:

• Проверьте с другой точки: VPN, другой провайдер, другой сервер в облаке.
• Убедитесь, что вы бьете в правильный IP (особенно если есть CDN, балансировщик, Anycast).
• Посмотрите ограничения на стороне облака: security group может пропускать только ваш офисный IP.
• Если сервис за прокси или WAF, он может ронять “неправильные” запросы, но принимать “правильные”.

4) Если вы админ сервера: проверяем слушатель, фаервол и маршрут, чтобы не гадать

Диагностика с клиентской стороны показывает симптом. Чтобы понять причину, почти всегда нужно заглянуть на сервер (или хотя бы на узел, который принимает трафик). Начните с простого: сервис вообще слушает порт? И слушает ли он на внешнем интерфейсе, а не только на localhost.

На Linux чаще всего достаточно ss. Он быстрее netstat и показывает, кто именно держит порт:

sudo ss -lntp | grep -E ':(22|80|443)b'
 sudo ss -lnup | grep -E ':(53|123)b'

Если порт слушается, а снаружи “не коннектится”, следующий подозреваемый - фаервол. В зависимости от системы это может быть nftables/iptables, ufw или firewalld. Вам не нужна идеальная настройка прямо сейчас, вам нужно понять, не режете ли вы сами себе доступ.

sudo ufw status verbose
 sudo nft list ruleset | head -n 80
 sudo iptables -S

Отдельный класс проблем: облако. На виртуалке может быть “все разрешено”, но сверху стоит security group, network ACL или правила балансировщика. Симптом классический: на сервере порт слушает, локально curl работает, а снаружи таймаут. В таких случаях проверка “на уровне облака” часто важнее, чем ковыряние iptables.

Еще один практичный прием: смотрите, приходят ли вообще пакеты на интерфейс. Если у вас есть доступ и права, tcpdump моментально снимает вопросы. Нет трафика - значит проблема до сервера (маршрутизация, security group, провайдер). Трафик есть, ответа нет - проблема на сервере или в приложении.

sudo tcpdump -ni any tcp port 443
 sudo tcpdump -ni any tcp port 22

И напоследок короткий алгоритм “чтобы каждый раз не изобретать велосипед”:

1. С клиента: nc/curl с таймаутом, фиксируем симптом.
2. Nmap точечно: уточняем open/closed/filtered.
3. На сервере: ss показывает слушатель и интерфейс.
4. Фаервол и правила облака: сверяем входящие источники и порты.
5. Логи приложения: если порт открыт, но “не работает”, часто виноват уровень выше TCP.