Linux ss定位端口监听进程与连接状态的方法

Linux 上排查“某个端口到底被谁占用”，建议先把 ss 当成一张套接字关系表来读：-l 看监听，-p 关联进程，-n 保留真实端口号，最后用状态过滤器确认连接是否真的建立。这样能把“端口没开”“端口被错误进程占用”和“服务已监听但没有客户端连接”分开。

官方地址：https://github.com/iproute2/iproute2/blob/main/man/man8/ss.8

先用监听表确认端口是否真的打开

第一轮不要直接猜服务名，也不要只看某一行输出。-l 表示只看监听套接字，-n 禁止端口和服务名解析，-t、-u 分别加入 TCP、UDP，-p 请求显示进程信息。

# 第一轮同时查看 TCP/UDP 监听、数字端口和关联进程
sudo ss -lntup

# 只确认 8080 是否存在监听，避免被其他端口干扰
sudo ss -lntp '( sport = :8080 )'

如果列表没有目标端口，先不要把问题归结为防火墙：服务可能尚未启动、只绑定了回环地址，或者实际监听的是 IPv6。查看 0.0.0.0:8080、127.0.0.1:8080 与 [::]:8080 时，要把绑定地址一并记录。

把端口、PID 和程序名关联起来

监听行中的 users:(()) 是进程关联信息。普通用户通常只能看到自己有权限访问的进程；遇到进程名为空或信息不完整时，优先用 sudo 重跑，而不是立即判断端口由内核或未知程序占用。

# 只看 TCP 监听，并请求显示 PID/程序名
sudo ss -lntp

# 以 PID 继续检查命令行和工作目录，确认是否是目标服务
pid=1234  # 将这里替换为 ss 输出中的真实 PID
ps -p "$pid" -o pid,ppid,user,comm,args

如果同一程序出现多个监听端口，先按 PID 聚合，再看绑定地址。一个进程可能同时监听 IPv4 与 IPv6，也可能由父进程负责监听、子进程负责处理请求。端口归属确认后，再回到服务管理器检查启动参数，避免直接杀掉共享监听的进程。

用连接状态判断“服务可达”还是“只有端口”

监听只说明套接字在等待连接，不说明业务请求已经到达。要看 TCP 连接，可使用 -a 同时包含监听与非监听套接字，再用状态表达式缩小结果。

# 查看所有 TCP 套接字，保留数字地址便于逐项比对
sudo ss -ant

# 只看已经建立的连接，并限定本地端口为 8080
sudo ss -nt state established '( sport = :8080 )'

ESTAB 能证明 TCP 三次握手已经完成，但它仍不等于应用层健康；还需要结合服务日志、响应耗时和请求内容。TIME-WAIT 是连接关闭后的内核状态，数量多不应直接当作监听失败。若要观察重传和定时器，可增加 -o，但它提供的是 TCP 层线索。

一份可复用的 ss 排查清单

1. 先运行 sudo ss -lntup，记录协议、绑定地址、端口与 PID。
2. 若无结果，分别检查 IPv4/IPv6 绑定和服务启动状态。
3. 若进程不符预期，用 ps 核对 PID、父进程和完整参数。
4. 若监听正常，再用 sudo ss -nt state established 判断是否有实际连接。
5. 看到大量 TIME-WAIT 或 SYN-RECV 时，把它们作为连接生命周期信号，结合应用日志和负载数据分析。

这套顺序的关键是先回答“谁在监听”，再回答“谁连进来了”。端口号、绑定地址、PID 和状态四列同时记录，通常比反复切换多个工具更容易复盘。

常见问题

ss 为什么看不到程序名？

最常见原因是权限不足。对监听查询使用 sudo ss -lntp；若仍为空，再核对 PID 是否已快速退出。

看到 ESTAB 就代表接口可用吗？

不代表。ESTAB 只说明 TCP 连接建立，应用层仍可能超时、返回错误或没有完成协议握手。

ss 和 netstat 应该怎么选？

新排障优先使用 ss。它属于 iproute2，能直接按连接状态和过滤表达式查询；只有在旧脚本明确依赖 netstat 输出格式时才保留兼容方案。