Если нужно проверить открытые порты в Linux, чаще всего речь идет не о «любых портах», а о тех, что слушают входящие соединения. Для этого удобнее всего использовать ss, а если нужно понять, какой процесс держит порт, подключить lsof или netstat. Ниже — короткий набор команд без лишней лирики.
Сразу важное: открыть порт в фаерволе и увидеть слушающий порт в системе — это не одно и то же. Команды ниже показывают, что реально слушает сам Linux. Если порт закрыт фаерволом, это уже отдельная проверка.

Коротко
- Для локальной проверки слушающих портов используйте
ss -lntupилиss -ltnup. - Если нужен процесс, который держит порт, добавьте
sudoи смотрите полеusers. lsof -iпомогает увидеть, какая программа привязана к порту.netstatдо сих пор встречается, но на новых системах чаще удобнееss.- Для проверки удаленного хоста используйте
nmapилиnc.
Симптомы
- Сервис запущен, но снаружи к нему не подключиться.
- Нужно быстро понять, слушает ли сервер нужный порт.
- Неясно, какой процесс занял порт 80, 443, 3306 или другой номер.
- После изменения конфигурации служба не подняла порт.
- Нужно проверить, открыт ли порт только локально или ещё и на сетевом интерфейсе.
Причина
- Процесс не запустился или упал сразу после старта.
- Сервис слушает только на
127.0.0.1, а не на внешнем адресе. - Порт занят другой программой.
- Фаервол или
iptables/nftablesрежет входящий трафик. - Сервис работает по UDP, а проверяли только TCP.
Что проверить перед исправлением
- Выясните, нужен ли вам TCP или UDP.
- Поймите, проверяете вы локальный сервер или удаленный хост.
- Если нужен PID и имя процесса, запускайте команды через
sudo. - Проверьте, что нужная служба вообще запущена.
Для начала удобно посмотреть только слушающие TCP-порты. Это быстро и обычно достаточно, чтобы понять, жив ли сервис.
ss -ltn
Если нужно увидеть процессы и UDP тоже, используйте более полный вариант.
sudo ss -ltnup
Решение
1. Посмотреть открытые порты через ss
ss — основной современный инструмент. Он показывает сокеты быстрее и чище, чем старый netstat.
ss -ltnup
-l— только слушающие сокеты.-t— TCP.-u— UDP.-n— без попытки резолвить имена.-p— показать процесс, если хватает прав.
Если нужен конкретный порт, отфильтруйте вывод через grep.
ss -ltnp | grep ':443'
2. Узнать, какой процесс держит порт через lsof
lsof удобен, когда надо быстро понять, какая программа заняла порт.
sudo lsof -iTCP -sTCP:LISTEN -P -n
Чтобы проверить конкретный порт, можно сузить вывод.
sudo lsof -i :8080
3. Использовать netstat, если он уже есть
На старых системах или в привычных скриптах до сих пор встречается netstat. Команда не новая, но рабочая.
sudo netstat -tulpn
Если netstat не установлен, это не проблема. На новых дистрибутивах проще жить на ss и lsof.
4. Проверить удаленный хост
Если вы хотите понять, открыт ли порт на другом сервере, локальные команды уже не помогут. Тогда пригодится nc или nmap.
nc -vz 192.168.1.10 22
nmap -Pn -p 1-1024 192.168.1.10
Для массовой проверки лучше брать nmap. Для одной-двух точек хватит nc.
5. Проверить, слушает ли сервис только localhost
Бывает так: порт есть, но он привязан только к 127.0.0.1. Снаружи сервис выглядит «закрытым», хотя внутри машины он жив.
ss -ltnp | grep 127.0.0.1
Если нужно принимать подключения с сети, сервис должен слушать не только loopback-адрес, но и внешний интерфейс, например 0.0.0.0 или конкретный IP.
Как проверить результат
- Порт появился в списке
LISTENилиUNCONNв зависимости от протокола. - В выводе виден правильный процесс и PID.
- Снаружи порт отвечает на
ncили виден вnmap. - Сервис слушает не только на localhost, если доступ нужен по сети.
Если порт слушает, но снаружи все равно не открывается, дальше проверяйте фаервол, маршрутизацию и привязку сервиса к адресу.
Частые ошибки
- Путать локально слушающий порт и доступность порта снаружи.
- Проверять только TCP и забывать про UDP.
- Запускать команды без
sudoи потом не видеть имя процесса. - Думать, что
netstatобязателен, хотяssуже давно удобнее. - Не смотреть, на каком адресе именно слушает сервис.
Похожие материалы
- Как проверить доступность сервиса без браузера: curl, nc и ss
- Ping проходит, а TCP timeout: как понять, где ломается соединение
- Диагностика TCP-соединений в Linux




