Как проверить доступность порта

Порт помогает транспортному протоколу направить трафик нужному сетевому сервису на узле. Для TCP порт проверяют попыткой установить соединение. Для UDP такой подход недостаточен, потому что у протокола нет аналогичного рукопожатия. В обоих случаях результат относится к конкретному адресу, сети, моменту и транспортному протоколу.

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

Что означает «порт доступен»

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

Если приходит явный отказ, узел или промежуточное устройство сообщил, что соединение не принимается. Частая причина - сервис не запущен или слушает другой интерфейс. Тайм-аут менее определён: пакет мог быть отброшен firewall, потерян по пути, отправлен на недоступный адрес или остаться без ответа по другой причине.

Слова open, closed и filtered являются выводом инструмента из наблюдаемого поведения, а не постоянным свойством порта. Правила способны отличаться для офисной сети, VPN, IPv4, IPv6 и адресов CDN.

Быстрая внешняя проверка

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

Не отправляйте во внешний инструмент внутренние имена, приватные адреса или сведения о закрытой инфраструктуре. Сервис снаружи всё равно может не иметь маршрута к ним, а сам запрос раскрывает введённые данные оператору инструмента.

Проверка TCP через netcat

nc, или netcat, умеет установить TCP-соединение без полноценного прикладного диалога:

nc -vz -w 3 example.com 443

-v включает подробный вывод, -z просит проверить соединение без обычной передачи данных, а -w 3 ограничивает ожидание в реализациях, поддерживающих этот синтаксис. Опции netcat различаются между системами, поэтому сверяйтесь с локальной справкой nc -h.

Команда создаёт реальную попытку подключения, которая может попасть в журналы сервера и системы защиты. Успех говорит о TCP-пути до порта 443, но не проверяет имя в сертификате и HTTP-ответ.

В Windows PowerShell аналогичная точечная проверка выглядит так:

Test-NetConnection example.com -Port 443

Смотрите поле TcpTestSucceeded, а также фактически выбранный адрес. Если у имени есть IPv4 и IPv6, команда может проверить только один из них. Для диагностики различий сначала получите оба адреса через DNS и тестируйте поддерживаемым способом отдельно.

Проверка протоколом приложения

После TCP полезно выполнить безопасный запрос тем протоколом, который должен работать. Для HTTPS:

curl --head --connect-timeout 5 https://example.com/

--head запрашивает только заголовки HTTP, а ограничение времени не даёт бесконечно ждать установления соединения. Сервер всё равно получает запрос и может учитывать его в журнале. Некоторые приложения не поддерживают HEAD корректно, поэтому ошибка метода не равна недоступному порту.

HTTPS-проверка дополнительно использует DNS-имя, SNI, TLS-сертификат и HTTP. Если nc подключается, а curl сообщает об ошибке сертификата, сетевой порт доступен, но проблема находится выше транспортного уровня. Не добавляйте --insecure как способ «починить» такую ошибку: изучите проверку SSL-сертификата.

Практический пример: новый HTTPS-сервис недоступен

Предположим, команда развернула приложение на api.example.com:443, но клиент получает тайм-аут.

1. Проверьте A и AAAA, чтобы знать фактические адреса. Старый IPv6 часто объясняет отличие между клиентами.
2. На самом сервере убедитесь штатными средствами платформы, что процесс слушает ожидаемый порт и интерфейс. Сервис на 127.0.0.1:443 не принимает внешние подключения.
3. Выполните точечный TCP-тест из той же сети, где работает клиент.
4. Сравните тест из внешней разрешённой точки. Различие укажет на сетевые политики или маршрут.
5. Проверьте firewall узла, облачные security group и балансировщик, сохраняя принцип минимального доступа.
6. После успешного TCP выполните TLS- и HTTP-проверку по имени.

Меняйте по одному уровню и фиксируйте время. Одновременное отключение firewall, замена DNS и перезапуск приложения может случайно восстановить доступ, но не даст понять причину и способно открыть лишние порты.

Особенности UDP

UDP передаёт датаграммы без установления соединения. Утилита может отправить пакет на UDP-порт, но молчание не различает открытый сервис, который ждёт корректный формат, от фильтрации. Иногда приходит ICMP-сообщение о недоступном порте, но его отсутствие не доказывает открытость.

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

Частые ошибки

• Не уточнять TCP или UDP и переносить вывод между протоколами.
• Проверять доменное имя, не замечая, какой из нескольких IP выбрал клиент.
• Считать успешный TCP-connect доказательством исправного приложения.
• Считать тайм-аут точным доказательством блокировки одним конкретным firewall.
• Проверять внутренний адрес из внешнего сервиса.
• Открывать порт для всего интернета вместо диагностики источника и минимального правила.
• Отключать TLS-проверку, чтобы скрыть ошибку имени или цепочки.
• Сканировать диапазон, когда для задачи достаточно одного согласованного узла и порта.
• Забывать, что исходящие правила на стороне клиента тоже могут блокировать соединение.

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

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

Что означает успешное подключение к TCP-порту?

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

Чем отказ в соединении отличается от тайм-аута?

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

Можно ли проверить UDP-порт так же, как TCP-порт?

Нет. У UDP нет TCP-рукопожатия, а отсутствие ответа может означать нормальное поведение сервиса, фильтрацию или потерю пакета. Надёжнее отправлять корректный запрос прикладного протокола и оценивать ожидаемый ответ с разрешения владельца системы.