先说一个核心结论：最准确的方法是直接读取内核 socket 表，也就是执行 sudo ss -tuln。其他工具要么速度慢、要么权限不足、要么仅扫描而不监听状态，像 root 进程开启的 0.0.0.0:22 这类关键端口，很容易被遗漏。
为什么 ss -tuln 是唯一能反映“真实开放”状态的命令
ss 命令不经过用户态解析，直接读取内核网络子系统，结果实时且无遗漏。它所显示的 LISTEN 状态，正是进程调用了 bind() 和 listen() 的真实痕迹。
-t：仅列出 TCP 监听套接字，例如 SSH、HTTP 等服务。-u：仅列出 UDP 监听套接字，例如 DNS、NTP 等协议。-l：过滤出 LISTEN 状态，即“已开启但尚未建立连接”的端口。-n：禁用反向 DNS 和服务名解析，避免因解析卡顿或显示混乱——比如将:80解析为:http，反而影响判断效率。
需要特别注意的是，未加 sudo 时，普通用户只能查看到自身启动的进程；若要查询 nginx、mysqld、sshd 等系统级服务，必须添加 sudo 权限。
lsof -i -P -n -s TCP:LISTEN 用于确认占用端口的进程
当 ss 输出显示 0.0.0.0:3000，但你无法确定是 node 还是 python 启动的服务时，lsof 能够直接提供 PID、USER、COMMAND 等关键字段。
-i：仅显示网络相关文件，即 socket 连接。-P：端口号不转换为服务名，绕过/etc/services映射。-n：IP 地址不反向解析，避免 DNS 解析延迟。-s TCP:LISTEN：精确过滤 TCP LISTEN 状态，排除已建立连接的干扰信息。
实际运维中需注意：lsof 在最小化系统（如 Alpine 容器）中通常未预装。若提示 command not found，无需强行安装，建议优先使用 ss 查询端口，再结合 ps aux | grep 搜索对应进程名称。
切勿将防火墙放行端口与监听端口混为一谈
防火墙规则 ≠ 端口监听状态，这个误区很多人都会遇到。一个端口完全可能出现以下情况：
- 进程正在监听（
ss可以查看到），但防火墙未放行（外部无法连接）。 - 防火墙已放行（
firewall-cmd --list-ports有输出），但实际没有进程监听（ss查询不到）。
查看防火墙自身规则：
- firewalld：
sudo firewall-cmd --list-ports - iptables：
sudo iptables -L -n -v | grep -i "accept" | grep -i "tcp|udp" - ufw：
sudo ufw status verbose
这些命令仅能说明“流量是否允许通过”，并不能反映“是否有程序在监听”。判断“端口是否真正开放”，始终以 ss -tuln 的输出为最终依据。
nmap -Pn 127.0.0.1 容易产生误判，需谨慎使用
nmap 默认会先发送 ICMP ping 或 ARP 探测，但 Docker 容器、加固内核以及部分云主机默认会丢弃这些探测包，导致返回 Host is down——这并非端口问题，而是 nmap 自身被环境拦截所致。
- 必须添加
-Pn参数：告知nmap“跳过存活探测，直接进行扫描”。 - 未加
sudo时，nmap实际会退化使用慢速的connect()扫描模式（-sT），还可能被防火墙拦截。 -sU（UDP 扫描）默认不启用，需单独指定；全端口扫描（-p-）耗时较长，日常运维中不常使用。
需要理解的复杂之处在于：监听地址决定了端口的对外可见性。0.0.0.0:80 可从任意网卡访问，而 127.0.0.1:3306 仅限本机连接——这个关键细节，ss 输出中其实已经明确显示，但很多人在快速浏览时容易忽略。
