Как узнать порт сервера: свой, чужой и порт прокси

Коротко. Какой порт слушает ваш сервис, показывают ss -tulpn в Linux, netstat -ano в Windows и lsof -nP -iTCP -sTCP:LISTEN в macOS. На каком порту отвечает хост снаружи, проверяют подключением — сканером портов. Стандартные номера смотрят в /etc/services и реестре IANA. Порт прокси берут из строки доступа, а не из «типовых» значений.

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

Порт сервиса и порт хоста — это два разных вопроса

Порт — не свойство сервера. Это номер, который конкретный процесс попросил у ядра, чтобы принимать соединения. Поэтому «порт сервера» существует только в паре: адрес, на котором процесс слушает, плюс номер. Один и тот же сервер одновременно держит десятки таких пар, и половина из них принципиально недоступна снаружи.

Вопрос	Откуда смотрим	Нужен доступ к ОС	Инструмент	Что получаем
Какой порт слушает мой сервис	Изнутри сервера	Да, желательно root	ss, lsof, netstat	Полный список: адрес, порт, протокол, процесс, PID
Какой процесс занял порт 8080	Изнутри сервера	Да, нужен root	ss -tlnp, lsof -i, fuser	Имя процесса и PID
На каком порту отвечает хост	Снаружи, по сети	Нет	Сканер портов, nc, curl	Только три исхода: отвечает, отказ, тишина
Какой порт должен быть у протокола	Справочник	Нет	/etc/services, реестр IANA	Зарегистрированный номер — договорённость, не факт

Разница принципиальная. Изнутри вы видите истину: ядро отдаёт таблицу сокетов, там нет догадок. Снаружи вы видите только реакцию на попытку подключения, и эта реакция может лгать — фаервол умеет отвечать отказом за чужой закрытый порт и умеет молчать за открытый.

Как узнать, какой порт слушает мой сервис в Linux

ss — основной инструмент

ss входит в пакет iproute2 и есть в любом современном дистрибутиве по умолчанию. Он читает данные напрямую из ядра и работает заметно быстрее старого netstat на машинах с тысячами соединений.

# все слушающие сокеты TCP и UDP, с процессами, без резолва имён
ss -tulpn

# то же самое, но только TCP
ss -tlnp

Типичный вывод выглядит так:

Netid State  Recv-Q Send-Q  Local Address:Port  Peer Address:Port Process
udp   UNCONN 0      0           127.0.0.1:323        0.0.0.0:*    users:(("chronyd",pid=1644,fd=5))
tcp   LISTEN 0      128           0.0.0.0:22         0.0.0.0:*    users:(("sshd",pid=2498,fd=7))
tcp   LISTEN 0      128              [::]:22            [::]:*    users:(("sshd",pid=2498,fd=8))
tcp   LISTEN 0      65535       127.0.0.1:3000       0.0.0.0:*    users:(("dockerd",pid=2489,fd=115))
tcp   LISTEN 0      65535         0.0.0.0:443        0.0.0.0:*    users:(("dockerd",pid=2489,fd=111))

Читать нужно колонку Local Address:Port, и читать её целиком. 0.0.0.0:443 — слушает на всех адресах IPv4, снаружи достижим. [::]:22 — то же самое для IPv6. А 127.0.0.1:3000 — слушает только на петлевом интерфейсе: с самого сервера порт работает, из сети его не существует. Это не мелочь, а причина примерно половины обращений «порт открыт, но не отвечает».

Флаг	Что делает
-t	Только TCP
-u	Только UDP
-l	Только слушающие сокеты (без установленных соединений)
-p	Показать процесс и PID, который держит сокет
-n	Не резолвить порты в имена и адреса в домены — вывод быстрее и однозначнее
-a	Все сокеты, включая установленные соединения

У ss есть собственный язык фильтров, и он избавляет от grep, который легко ошибается на подстроках (grep :22 поймает и порт 2222, и 8022):

# кто слушает конкретный порт
ss -tlnp 'sport = :22'

# все установленные исходящие и входящие соединения с процессами
ss -tnp state established

# соединения только с одним адресом
ss -tnp 'dst 203.0.113.10'

Без root колонка Process будет пустой. ss -tulpn от обычного пользователя честно покажет порты, но не покажет, кто их держит: ядро не отдаёт эту связку без привилегий. Если процессов не видно — не ищите баг, запустите через sudo.

Почему netstat «command not found»

netstat живёт в пакете net-tools, который во многих дистрибутивах давно не ставится по умолчанию. На свежих системах семейства RHEL (AlmaLinux, Rocky, CentOS Stream) и в минимальных образах Debian и Ubuntu его просто нет — и это не поломка, а осознанное решение мейнтейнеров: net-tools считается устаревшим и не получает новых возможностей.

# AlmaLinux / Rocky / RHEL / Fedora
sudo dnf install net-tools

# Debian / Ubuntu
sudo apt install net-tools

Ставить его ради одной команды обычно не нужно — у всего есть эквивалент в ss:

Задача	netstat (net-tools)	ss (iproute2)
Слушающие TCP и UDP с процессами	netstat -tulpn	ss -tulpn
Все TCP-соединения	netstat -tan	ss -tan
Только установленные	netstat -tan | grep ESTABLISHED	ss -tn state established
Статистика по протоколам	netstat -s	ss -s
Таблица маршрутизации	netstat -rn	ip route show

Флаги -tulpn у обеих команд совпадают, поэтому переучиваться почти не приходится: достаточно заменить одно слово.

lsof — когда нужен взгляд со стороны процесса

lsof смотрит на сокет как на открытый файл. Это удобно, когда вопрос звучит не «кто на порту», а «что вообще открыл этот процесс».

# все слушающие TCP-сокеты
lsof -nP -iTCP -sTCP:LISTEN

# всё, что происходит на конкретном порту, включая активные соединения
lsof -nP -i :443

# только соединения указанного процесса
lsof -nP -p 2498 -a -i

Флаги -n и -P отключают резолв адресов и портов в имена. Без них lsof напишет ssh вместо 22 и полезет в DNS за каждым адресом — на загруженном сервере это превращает мгновенную команду в минутное ожидание.

Как найти процесс по порту

Классическая задача: порт занят, приложение не стартует. Три способа, любой подойдёт:

# 1. через ss — точный фильтр, без ложных совпадений
ss -tlnp 'sport = :8080'

# 2. через lsof — покажет и слушателя, и активные соединения
lsof -nP -i :8080

# 3. через fuser — самый короткий, отдаёт только PID
fuser -n tcp 8080

Получив PID, выясняем, что это за процесс и кто им управляет:

ps -p 2498 -o pid,user,comm,args --no-headers
# 2498 root sshd sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startups

# какой systemd-юнит владеет процессом
systemctl status 2498

Последняя команда часто экономит больше всего времени: systemctl status <PID> принимает номер процесса и печатает имя юнита. Дальше становится понятно, что перезапускать и где лежит конфиг.

Как найти порт по процессу

Обратная задача: сервис работает, а на каком порту — неизвестно.

# находим PID по имени
pgrep -a nginx

# смотрим все его сетевые сокеты
lsof -nP -p 1234 -a -i

# либо фильтруем вывод ss по PID
ss -tulpn | grep 'pid=1234'

Если процесс запущен внутри контейнера, на хосте вы увидите не его, а dockerd или containerd, который опубликовал порт наружу. Это нормально: порт публикует рантайм, а не приложение. Внутрь контейнера смотрят отдельно — docker exec <name> ss -tulpn, если в образе есть iproute2.

Как узнать порт сервера в Windows и macOS

Windows

В Windows netstat на месте и никуда не делся. Ключ -o добавляет колонку PID — без неё вывод почти бесполезен.

:: все соединения и слушающие порты с номерами процессов
netstat -ano

:: только слушающие
netstat -ano | findstr LISTENING

:: кто занял конкретный порт
netstat -ano | findstr :8080

:: что за процесс с этим PID
tasklist /FI "PID eq 1234"

В PowerShell то же самое решается без разбора текста — командлеты возвращают объекты, которые можно фильтровать:

# все слушающие порты
Get-NetTCPConnection -State Listen | Sort-Object LocalPort

# кто занял порт 8080, сразу с именем процесса
Get-NetTCPConnection -LocalPort 8080 |
  Select-Object LocalAddress, LocalPort, State, OwningProcess,
    @{Name='Process'; Expression={(Get-Process -Id $_.OwningProcess).ProcessName}}

Читаются адреса так же, как в Linux: 0.0.0.0 — все интерфейсы, 127.0.0.1 — только локально, [::] — IPv6.

macOS

В macOS есть и netstat, и lsof, но у netstat здесь другой набор ключей, унаследованный от BSD. Главная ловушка: -p в macOS означает не «процесс», а «протокол».

# основной способ — lsof
lsof -nP -iTCP -sTCP:LISTEN

# кто занял конкретный порт
lsof -nP -i :5000

# netstat: -p здесь выбирает ПРОТОКОЛ, а не процесс
netstat -an -p tcp | grep LISTEN

# с ключом -v появляется колонка process:pid
netstat -anv -p tcp

Поэтому привычная по Linux строка netstat -tulpn в macOS просто не отработает как ожидается. Рабочий инструмент здесь — lsof.

Какой порт слушает nginx, Apache и другие сервисы — смотрим конфиг

Иногда нужен не факт, а намерение: на каком порту сервис должен подняться. Тогда смотрят конфигурацию.

# nginx: полный дамп конфига со всеми include
nginx -T | grep -n 'listen'

# где вообще лежит конфиг, если путь нестандартный
nginx -V 2>&1 | tr ' ' '\n' | grep conf-path

# грубо, но всегда работает
grep -RnE '^[[:space:]]*listen' /etc/nginx/

# Apache: сводка по портам и виртуальным хостам
apachectl -S
grep -RnE '^[[:space:]]*Listen' /etc/httpd/ /etc/apache2/ 2>/dev/null

# OpenSSH: эффективная конфигурация после всех include
sshd -T | grep -iE '^port|^listenaddress'
# port 22
# listenaddress [::]:22
# listenaddress 0.0.0.0:22

# Docker: что опубликовано наружу
docker ps --format '{{.Names}}\t{{.Ports}}'
docker port <container>

У docker ps есть важная тонкость в колонке Ports. Запись вида 0.0.0.0:8080->80/tcp означает публикацию: порт 8080 хоста проброшен в контейнер. А голое 80/tcp без стрелки — это только EXPOSE в образе, то есть объявление о намерении. Такой порт доступен другим контейнерам в общей сети, но на хосте его нет, и ss -tulpn его не покажет. Команда docker port <container> для такого контейнера вернёт пустой вывод — это и есть проверка.

Конфиг говорит о намерении, ss — о факте. Расходятся они постоянно: сервис не перечитал конфиг, стартанул с другим файлом, упал при биндинге и остался на старом порту. Правило простое: конфиг читаем, чтобы понять замысел, но верим тому, что показывает таблица сокетов.

Как узнать порт IP-адреса: на каком порту отвечает хост

Если доступа к операционной системе нет, остаётся один способ — попробовать подключиться. Ответов ровно три, и путать их нельзя.

Исход	Как выглядит	Что это значит
Открыт	Соединение установилось сразу	На порту кто-то слушает и принимает соединения
Закрыт	Мгновенный отказ, Connection refused	Хост доступен, но на этом порту никто не слушает
Фильтруется	Тишина до истечения таймаута	Пакет отброшен фаерволом; про сам порт вывода сделать нельзя

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

# nc: код возврата 0 — соединились, 1 — нет
nc -z -w2 example.com 443 && echo OPEN || echo CLOSED

# curl: видно и код ответа, и причину отказа
curl -sS --connect-timeout 5 -o /dev/null -w '%{http_code}\n' http://example.com:8080/

У curl код выхода 7 — «не удалось подключиться». Он же появляется при отказе и при таймауте, поэтому различать их надо по времени: отказ приходит мгновенно, фильтрация висит до конца --connect-timeout.

Сканировать чужие хосты без разрешения владельца нельзя. Это не диагностика, а несанкционированное воздействие: в большинстве юрисдикций такое подпадает под законы о неправомерном доступе к компьютерной информации, а у любого провайдера — под запрет в правилах пользования услугами. Проверяйте только свои серверы и те, на которые у вас есть письменное разрешение. Всё в этой статье написано для собственной инфраструктуры.

Про то, как трактовать результат проверки открытых портов и какие из них стоит закрывать, подробно разобрано отдельно — в статье как проверить открытые порты. Здесь важно другое: сканирование отвечает на вопрос «отвечает ли хост на этом порту», но никогда не отвечает на вопрос «какой процесс за ним стоит». Баннер сервиса можно подделать, порт можно повесить на что угодно, а номер сам по себе ничего не гарантирует.

Стандартные порты и где их смотреть: /etc/services и реестр IANA

Соответствие «номер — протокол» ведёт IANA в реестре Service Name and Transport Protocol Port Number Registry, а процедура регистрации описана в RFC 6335. Копия реестра лежит локально в каждой системе.

# Linux и macOS
grep -wE '443/tcp' /etc/services
getent services 443/tcp
getent services https

# Windows
type %SystemRoot%\System32\drivers\etc\services | findstr 443

Несколько записей, которые встречаются чаще всего:

Порт	Имя в /etc/services	Что обычно за ним
22/tcp	ssh	SSH
25/tcp	smtp	Передача почты между серверами
53/tcp, 53/udp	domain	DNS
80/tcp	http	HTTP без шифрования
110/tcp, 143/tcp	pop3, imap	Получение почты без TLS
443/tcp	https	HTTP поверх TLS
587/tcp	submission	Отправка почты клиентом
993/tcp, 995/tcp	imaps, pop3s	Почта поверх TLS
1080/tcp	socks	Прокси SOCKS
3128/tcp	squid	Кеширующий HTTP-прокси
3306/tcp	mysql	MySQL и MariaDB
8080/tcp	webcache, http-alt	Альтернативный HTTP, прокси, бэкенды

Диапазоны по RFC 6335 делятся на три части: 0–1023 — системные, в Unix-системах занять их может только процесс с привилегиями; 1024–49151 — зарегистрированные за конкретными сервисами; 49152–65535 — динамические, из них ядро выдаёт исходящий порт для каждого нового соединения. Поэтому в выводе ss -tn локальные порты ваших исходящих подключений выглядят как случайные большие числа — так и должно быть. Реальные границы диапазона в Linux при этом задаёт не RFC, а ядро: на многих системах в /proc/sys/net/ipv4/ip_local_port_range лежит куда более широкий интервал.

Имя в /etc/services — ярлык, а не факт. Файл лишь переводит номер в подпись и ничего не проверяет. Реальный пример: nc -z 127.0.0.1 3000 печатает tcp/hbci, потому что за номером 3000 в реестре закреплено это имя, — хотя на самом деле там работает веб-приложение и отдаёт HTTP-редирект. Никогда не делайте вывод о сервисе по подписи из файла.

Отдельный случай — почтовые порты: там номера действительно значат разное поведение, а не только подпись, и путаница между 25, 465 и 587 стоит недоставленных писем. Это разобрано в статье порты 25, 465 и 587.

Как узнать порт прокси и проверить, что он живой

С прокси работает то же правило, что и со всем остальным: авторитетный источник — конфигурация, а не «типовой номер». Провайдер прокси выдаёт строку доступа вида host:port:user:password, и порт в ней — единственная достоверная величина. Угадывать по спискам «стандартных портов прокси» бессмысленно: оператор вправе повесить сервис на любой номер, и чаще всего так и делает.

Где записан порт прокси

# переменные окружения — их читают curl, wget, apt, pip, docker
env | grep -i proxy
# http_proxy=http://10.0.0.5:3128
# https_proxy=http://10.0.0.5:3128
# no_proxy=localhost,127.0.0.1,.internal

# настройки отдельных клиентов
git config --get http.proxy
npm config get proxy

# macOS: системные настройки прокси, включая PAC-файл
scutil --proxy

# Windows: прокси для системных HTTP-клиентов
netsh winhttp show proxy

В графических интерфейсах порт лежит там же, где адрес: в Windows — «Параметры» → «Сеть и Интернет» → «Прокси-сервер», в macOS — «Системные настройки» → «Сеть» → выбранный интерфейс → «Прокси», в браузерах — либо системные настройки, либо собственный раздел. Если задан не адрес, а PAC-файл, порт вычисляется скриптом: тогда его смотрят внутри самого .pac, в функции FindProxyForURL.

Если прокси ваш собственный, вопрос сводится к первой части статьи: ss -tulpn на сервере прокси плюс его конфигурация. Номер порта задаётся в конфиге и ничем не предопределён.

Как проверить, что порт прокси живой

# 1. отвечает ли вообще TCP
nc -z -w3 10.0.0.5 3128 && echo TCP_OK || echo TCP_FAIL

# 2. работает ли прокси как прокси
curl -x http://10.0.0.5:3128 --connect-timeout 5 \
     -sS -o /dev/null -w '%{http_code}\n' https://example.com/

# 3. с авторизацией
curl -x http://10.0.0.5:3128 -U user:password --connect-timeout 5 \
     -sS -o /dev/null -w '%{http_code}\n' https://example.com/

# 4. SOCKS5 — имя домена резолвит сам прокси
curl --socks5-hostname 10.0.0.5:1080 --connect-timeout 5 \
     -sS -o /dev/null -w '%{http_code}\n' https://example.com/

Как читать результат:

Что вернулось	Диагноз
200	Прокси принимает соединения и проксирует
407	Прокси живой, но требует авторизацию — добавьте -U
403	Прокси живой, но ваш адрес или запрошенный ресурс запрещён правилами
curl: (7) мгновенно	Порт закрыт или указан неверно, либо прокси не запущен
curl: (7) по таймауту	Пакеты фильтруются: фаервол, белый список адресов, сетевой блок
000 в %{http_code}	Ответа не было вообще — смотрите код выхода curl

Успешный TCP-хендшейк — ещё не рабочий прокси. nc -z проверяет только то, что на порту кто-то принял соединение. За этим портом может стоять другой сервис, прокси может отказать по авторизации или по списку доступа, туннель CONNECT к 443 может быть запрещён отдельно от обычного HTTP. Проверять надо тем же протоколом, которым потом будете пользоваться.

Проще всего убедиться, что трафик действительно идёт через прокси, сравнив внешний адрес с прокси и без него — для этого подойдёт проверка IP-адреса. Если адрес не изменился, прокси не применяется, каким бы «живым» ни выглядел его порт. Как вообще устроен внешний адрес и почему их у машины несколько, разобрано в статье как узнать IP-адрес.

Почему порт «открыт», но сервис не отвечает

Самая частая жалоба и самая недооценённая причина. Разберём на живом примере. На сервере ss показывает, что порт слушает:

tcp LISTEN 0 65535 127.0.0.1:3000 0.0.0.0:* users:(("dockerd",pid=2489,fd=115))

С самого сервера всё работает:

curl -sS -o /dev/null -w '%{http_code}\n' http://127.0.0.1:3000/
# 302

А с внешнего адреса того же сервера — нет:

curl -sS -o /dev/null -w '%{http_code}\n' http://203.0.113.10:3000/
# curl: (7) Failed to connect to 203.0.113.10 port 3000: Connection refused

Ничего не сломано. Сервис принципиально не слушает внешний адрес: он привязан к 127.0.0.1. Сканер снаружи покажет порт закрытым, и будет прав.

Симптом	Что видно	Вероятная причина	Чем проверить
Мгновенный отказ	Connection refused, curl: (7) сразу	Никто не слушает, либо биндинг на 127.0.0.1	ss -tulpn на хосте, смотреть адрес слева от порта
Висит до таймаута	Тишина, потом curl: (28) или (7)	Фаервол ОС или облачная группа безопасности отбрасывает пакеты	firewall-cmd --list-ports, ufw status, nft list ruleset, панель провайдера
Работает с IPv4, не работает с IPv6	Разное поведение по адресам	Сокет открыт только на 0.0.0.0 или только на [::]	Обе строки в выводе ss -tlnp
Соединение есть, ответа нет	nc проходит, curl висит или рвётся	Не тот протокол: HTTP на TLS-порт или наоборот	curl -v, openssl s_client -connect host:port
Порт виден в конфиге, но не в ss	Пусто в таблице сокетов	Сервис не стартовал, упал при биндинге или это EXPOSE без публикации	systemctl status, логи сервиса, docker port

Проверка фаервола занимает секунды:

# firewalld (RHEL, AlmaLinux, Rocky, Fedora)
firewall-cmd --list-ports
firewall-cmd --list-services

# ufw (Ubuntu, Debian)
sudo ufw status verbose

# nftables и iptables напрямую
sudo nft list ruleset
sudo iptables -L -n

# какие адреса вообще есть, чтобы на них биндиться
ip -br a

Отдельно держите в голове уровень, который не виден изнутри вообще: облачные группы безопасности и сетевые ACL провайдера. Правило в них живёт вне операционной системы, поэтому firewall-cmd покажет чистую конфигурацию, а пакеты всё равно не дойдут. Если внутри всё в порядке, а снаружи тишина — идите в панель управления хостингом.

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

Как проверить порты онлайн

Если нужно посмотреть на свой сервер именно снаружи — с чужого адреса, из другой сети, без правки локального фаервола — удобнее онлайн-проверка. Она сразу отвечает на вопрос, который изнутри проверить нельзя: видно ли порт из интернета.

Рабочая последовательность выглядит так:

1. Проверка IP — уточните, какой адрес у сервера виден снаружи. Сканировать не тот адрес — самая обидная потеря времени, особенно если перед сервером стоит CDN.
2. Ping и доступность — убедитесь, что хост вообще отвечает и задержка адекватная. Если ICMP закрыт, это ещё не значит, что закрыты TCP-порты.
3. Проверка портов — посмотрите, какие порты вашего хоста отвечают из интернета, и сравните список с тем, что показал ss -tulpn на самом сервере. Расхождение и есть ответ: что закрыто фаерволом, а что просто слушает петлевой интерфейс.
4. Мониторинг — если порт критичен, поставьте его на постоянную проверку: падение сервиса и молчаливое закрытие порта фаерволом после обновления правил выглядят одинаково и обнаруживаются одинаково поздно.

Проверяйте так только те хосты, которыми владеете или на которые у вас есть разрешение.

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

Почему netstat пишет «command not found», а ss работает

netstat входит в пакет net-tools, который во многих современных дистрибутивах не устанавливается по умолчанию, потому что считается устаревшим. ss из пакета iproute2 присутствует практически всегда и делает то же самое, а флаги -tulpn у обеих команд совпадают. Ставить net-tools ради привычки обычно не нужно.

Почему ss -tulpn не показывает процессы

Связку «сокет — процесс» ядро отдаёт только привилегированному пользователю. От обычного пользователя колонка Process будет пустой, хотя сами порты видны. Запустите команду через sudo.

Можно ли узнать порт, не подключаясь к хосту

Нет. Снаружи порт проявляет себя только через реакцию на попытку соединения. Никакая запись в DNS, WHOIS или заголовках не сообщает, какие порты слушает сервер. Единственное исключение — порт, явно указанный в URL после двоеточия: он относится к конкретной ссылке, а не к хосту в целом.

Почему у моих исходящих соединений всегда разные порты

Это эфемерные порты. Для каждого нового исходящего соединения ядро выдаёт свободный номер из динамического диапазона (RFC 6335 отводит под это 49152–65535, но Linux по умолчанию использует более широкий диапазон — точные границы смотрите в /proc/sys/net/ipv4/ip_local_port_range). Слушающий порт сервиса и локальный порт клиента — разные вещи.

В выводе есть 0.0.0.0:443 и [::]:443 — это два разных сервиса

Обычно нет: это один процесс, открывший отдельные сокеты для IPv4 и IPv6. Убедиться просто — PID в колонке Process будет одинаковым. Тревожно как раз обратное: если строка есть только для одного семейства адресов, часть клиентов до сервиса не достучится.

Порт открыт в фаерволе, но сканер снаружи показывает «закрыт»

Проверьте адрес привязки в выводе ss -tulpn. Если там 127.0.0.1, правило фаервола ни на что не влияет: пакеты из сети до сокета не доходят в принципе. Второй кандидат — облачная группа безопасности провайдера, которая работает вне операционной системы и в firewall-cmd не видна.

Чеклист

• Определитесь, какой из двух вопросов решаете: какой порт слушает мой процесс или на каком порту отвечает хост.
• Изнутри Linux: ss -tulpn под sudo. Без root процессы видны не будут.
• Нет netstat — это норма, а не поломка: ставьте net-tools только если он действительно нужен.
• Читайте адрес слева от порта: 0.0.0.0 и [::] — наружу, 127.0.0.1 — только локально.
• Процесс по порту — ss -tlnp 'sport = :N', lsof -nP -i :N или fuser -n tcp N; затем systemctl status <PID>.
• В Windows — netstat -ano плюс tasklist, в macOS — lsof -nP -iTCP -sTCP:LISTEN, но не netstat -tulpn.
• Конфиг показывает намерение, ss — факт. При расхождении верьте таблице сокетов.
• Снаружи различайте три исхода: отказ мгновенный, фильтрация — по таймауту, открытый порт отвечает сразу.
• Порт прокси берите из строки доступа или конфига, а не из списков «типовых» номеров.
• Живость прокси проверяйте тем же протоколом, которым будете пользоваться: nc -z доказывает только TCP.
• Имя из /etc/services — подпись, а не доказательство того, какой сервис работает за номером.
• Сканируйте только свои хосты и только с разрешения владельца.