Linux系统查看所有开放端口的命令及操作步骤

先说一个核心结论：最准确的方法是直接读取内核 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 输出中其实已经明确显示，但很多人在快速浏览时容易忽略。