Максим Дорохов 
Как проверить, открыт ли порт: telnet, nc, PowerShell и онлайн-сервисы
«Проверь, открыт ли порт» — задача на одну минуту, если знать команды, и на час мучений, если не знать. Практикум: как проверить порт с любой системы, как читать три возможных ответа (открыт, закрыт, фильтруется) и почему проверка изнутри сервера и снаружи — это две разные проверки с разными ответами. Что такое порты в принципе — в отдельной статье; здесь только практика.
Команды: по одной на каждую систему
# macOS / Linux — nc (netcat), самый удобный: nc -zv example.ru 443 # → succeeded / Connection refused / timed out # Windows — PowerShell: Test-NetConnection example.ru -Port 443 # → смотрите поле TcpTestSucceeded: True/False # Классика везде, где есть telnet: telnet example.ru 443 # → пустой экран или приветствие = порт открыт; ошибка = нет # Несколько портов сразу (nc): nc -zv example.ru 80 443 8080
Все три инструмента делают одно и то же: пытаются установить TCP-соединение. Ответ приходит за секунды — и вот как его читать:
| Результат | Что это значит | Типовая причина |
|---|---|---|
| Открыт (succeeded / True) | Сервис слушает и принимает соединения | Всё штатно — или порт открыт зря (см. про безопасность ниже) |
| Закрыт (Connection refused) | Хост жив и мгновенно отказал: на порту никто не слушает | Сервис не запущен или слушает другой порт/интерфейс — сценарии из статьи про CONNECTION_REFUSED |
| Фильтруется (timed out) | Ответа нет вовсе: пакеты молча отбрасываются | Файрвол в режиме DROP по пути — родня TIMED_OUT |
Изнутри и снаружи — две разные проверки
Самая частая путаница: на сервере ss -tlnp показывает, что порт слушается, а у клиентов соединение не проходит. Противоречия нет — это два разных вопроса. Изнутри вы спрашиваете «запущен ли сервис», снаружи — «пропускает ли к нему мир»: между сервисом и миром стоят файрвол сервера, файрвол хостинга/панели, иногда сетевые фильтры провайдера. Поэтому полная проверка всегда парная:
# 1. НА сервере: слушается ли порт вообще ss -tlnp | grep :443 # 2. С ДРУГОЙ машины/сети: доходит ли до него мир nc -zv example.ru 443 # Слушается, но снаружи timeout → ищите правило в файрволе: iptables -L -n | grep 443 # или nft list ruleset, или панель хостинга
И ещё тоньше: «снаружи» бывает разным. Порт может быть открыт для вашего офиса и закрыт для остального мира (белые списки), открыт из России и фильтроваться из-за рубежа, или наоборот. Если результат проверки зависит от того, откуда проверяют, — вы имеете дело с выборочными правилами, и проверять нужно из нескольких сетей.
Шпаргалка: какие порты обычно проверяют
| Порт | Сервис | Когда проверять |
|---|---|---|
| 80 / 443 | HTTP / HTTPS | Сайт не открывается; после настройки SSL (80 нужен и для продления сертификатов) |
| 22 | SSH | Не подключается терминал; после смены правил файрвола (не отрежьте себя!) |
| 25 / 465 / 587 | SMTP (отправка почты) | Письма не уходят; 25-й у многих провайдеров закрыт по умолчанию от спама |
| 3306 / 5432 | MySQL / PostgreSQL | Проверять, что они ЗАКРЫТЫ снаружи: базы наружу не смотрят |
| 3389 | RDP | Тоже из списка «должен быть закрыт или за VPN» — любимая дверь для перебора |
Половина пользы от умения проверять порты — проверять, что лишние ЗАКРЫТЫ. Открытые наружу базы, панели и RDP сканеры находят за минуты после появления сервера в сети. Ритуал после любых работ с сервером: пройтись nc по списку служебных портов снаружи и убедиться, что мир видит только 80, 443 и (в идеале — с ограничением по IP) SSH.
Полная инвентаризация: что вообще открыто у вашего сервера
Проверка одного порта отвечает на точечный вопрос. Иногда нужен ответ пошире — «что мой сервер вообще показывает миру». Изнутри полный список слушающих портов даёт ss -tlnp: по каждой строке спросите себя, зачем этот сервис слушает внешний адрес, а не 127.0.0.1. Снаружи полную картину даёт сканер nmap с другой машины: nmap -Pn example.ru покажет всё, что реально доступно из интернета, вместе с угаданными сервисами. Два списка должны сходиться с вашими ожиданиями; каждый «сюрприз» в выводе nmap — либо забытый сервис, либо дыра в файрволе. Важная оговорка: сканируйте только собственные серверы — сканирование чужих без разрешения как минимум неэтично, а во многих случаях и наказуемо.
Разовая проверка против постоянной
Команды выше отвечают «как сейчас». Но порты имеют свойство меняться без спроса: обновление панели переписало файрвол, хостер сменил политику, сервис после ребута не поднялся — и порт, который «точно был открыт», молча закрылся (или наоборот — открылся лишний). Для портов, на которых держится бизнес — сайт, почта, API, — правильный режим не «проверил и забыл», а постоянный контроль с уведомлением при изменении статуса. Это ровно та проверка, которую бессмысленно делать руками: она интересна только в момент, когда что-то изменилось.
Пруфен выполняет проверку порта по расписанию от 2 минут из 13 точек в разных сетях — видно и полный отказ, и выборочную фильтрацию «для части мира». В паре с HTTP-проверкой это разводит диагнозы «порт закрыт» и «порт открыт, но сайт отвечает ошибкой» автоматически.
Частые вопросы
Чем проверить порт без терминала? Онлайн-чекерами портов: вводите хост и номер порта — сервис пробует соединиться со своей стороны. Для разовой проверки «снаружи» это даже честнее локальной команды: вы видите картину из чужой сети.
Почему telnet «ничего не показывает» при успехе? Пустой чёрный экран — это и есть успех: соединение установлено, telnet ждёт ввода. Выход — Ctrl+] и quit. Ошибка соединения, наоборот, пишется явно.
Можно ли проверить UDP-порт так же? Сложнее: UDP не подтверждает соединение, поэтому «тишина» может означать и «открыт», и «фильтруется». nc -zuv даёт грубую оценку, но для UDP-сервисов надёжнее проверять сам сервис его протоколом (например, DNS — запросом dig).
Порт открыт, но сайт всё равно не работает. Что дальше? Значит, TCP-уровень в порядке, и проблема выше: TLS-рукопожатие или сам сайт. Дальше по нашим разборам: ошибки рукопожатия и коды ответов HTTP.