Telnet: как проверить порт и почему эта древняя утилита всё ещё полезна

Telnet старше интернета в его нынешнем виде, давно небезопасен как средство удалённого доступа — и при этом остаётся самым известным способом ответить на вопрос «открыт ли порт». Разбираем, как включить telnet в Windows, как читать три его исхода и когда вместо него взять современные альтернативы.

Telnet — утилита, которая устанавливает простое TCP-соединение с указанным хостом и портом. Когда-то через telnet администрировали серверы — от этой роли отказались десятилетия назад в пользу SSH: telnet передаёт всё, включая пароли, открытым текстом. Но у него осталась вторая профессия — щуп для портов. Команда из трёх слов отвечает на вопрос, который возникает при половине сетевых проблем: доступен ли порт N на сервере X отсюда?

Включение: в Windows telnet выключен

В macOS и Linux клиент либо уже есть, либо ставится из репозитория одной командой. В Windows он выключен по умолчанию — включается за минуту: «Панель управления → Программы → Включение или отключение компонентов Windows → Клиент Telnet», либо командой в PowerShell от администратора:

dism /online /Enable-Feature /FeatureName:TelnetClient

Впрочем, чуть ниже покажем способ обойтись в Windows вообще без telnet — PowerShell умеет то же самое из коробки.

Проверка порта: команда и три исхода

telnet prufen.ru 443

Дальше возможны ровно три сценария, и каждый — диагноз:

Разница между «refused» и «timeout» — самое ценное, что даёт telnet: отказ означает, что сеть до сервера работает и проблема в сервисе; таймаут — что вас не пускают по дороге. Это те же два мира, что и в браузерных ошибках ERR_CONNECTION_REFUSED и ERR_CONNECTION_TIMED_OUT — telnet просто показывает их без браузерной обёртки.

Типовые применения: SMTP-порт 25, который хостинги и провайдеры часто режут (проверьте telnet'ом — сразу ясно, почему «не отправляется почта»), порт базы данных 3306/5432 («почему сайт не видит базу на соседнем сервере»), порт 443 нового сервера перед переездом. Какие порты за что отвечают — в нашей статье о портах.

Бонус-приём: поговорить с сервером вручную

На незашифрованных протоколах telnet позволяет сыграть роль клиента буквально: подключиться к SMTP на 25-й порт и увидеть приветствие почтового сервера, или к HTTP на 80-й и набрать запрос руками:

telnet prufen.ru 80
GET / HTTP/1.1
Host: prufen.ru
 ← пустая строка = конец запроса
HTTP/1.1 301 Moved Permanently ...

Практической пользы в 2026-м немного — почти всё живёт за TLS, куда telnet не умеет, — но для понимания, что HTTP это просто текст по TCP, упражнение бесценное.

Современные альтернативы

PowerShell (Windows, ничего ставить не нужно):

Test-NetConnection prufen.ru -Port 443
# TcpTestSucceeded : True ← порт открыт

netcat (Linux/macOS) — тот же щуп, но со скриптовыми возможностями: nc -zv prufen.ru 443 проверяет порт, не входя в интерактив, и умеет диапазоны портов — ему посвящён наш отдельный разбор. А полная карта способов проверки портов — от онлайн-инструментов до nmap — собрана в статье «Как проверить, открыт ли порт».

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

Почему telnet выключен в Windows по умолчанию? Потому что как средство удалённого доступа он опасен: всё, включая пароли, летит открытым текстом, и любой на пути может это прочитать. Microsoft убрала клиент из коробки, чтобы им не пользовались по старой памяти для администрирования. Для проверки портов эта опасность не имеет значения — вы не передаёте ничего секретного, — но для входа на устройства используйте только SSH.

Можно ли проверить UDP-порт телнетом? Нет — telnet работает только по TCP. UDP-сервисы (DNS на 53-м, VPN-протоколы) телнетом не проверяются в принципе: у UDP нет соединения, которое можно «установить». Для этого есть netcat с флагом -u, и даже он даёт лишь косвенный ответ.

Telnet говорит «порт открыт», а сервис не работает — как так? См. жёлтую плашку выше: TCP-соединение принимает операционная система, а полезную работу делает приложение за ним. Зависший процесс может держать порт открытым часами. Поэтому «порт отвечает» — необходимое, но не достаточное условие здоровья сервиса.

Почему изнутри сервера порт открыт, а снаружи нет? Сервис слушает только локальный интерфейс (127.0.0.1 вместо 0.0.0.0) либо между вами и сервером стоит файрвол — на самом сервере, у хостинга или на маршруте. Проверка с самого сервера и проверка снаружи отвечают на разные вопросы; для базы данных «снаружи закрыто» — это, кстати, правильная настройка.

Ограничение, о котором забывают

Telnet проверяет доступность порта из вашей точки. Порт базы данных, закрытый файрволом для всего интернета, но открытый для вашего IP, — это правильная настройка, а не проблема; порт 443, открытый для вас, но зафильтрованный для части регионов, — проблема, которую вы telnet'ом со своего компьютера не увидите. Для картины «как порт выглядит из разных мест» нужна проверка порта из распределённых локаций — и по расписанию, потому что порты имеют свойство закрываться в самый неудобный момент: после обновления файрвола, миграции или «наведения порядка» на сервере.