Linux ss 怎么按进程和 TCP 状态筛选连接

Linux 上用 ss 查连接时，最稳妥的顺序是：先让 ss 用 state 原生过滤 TCP 状态，再用 -p 显示进程归属；需要按进程名或 PID 缩小时，对输出做固定字符串匹配。若目标是由 systemd 管理的服务，而且 cgroup 路径稳定，可以直接使用 cgroup 表达式，减少文本过滤带来的歧义。

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

常用起点是 sudo ss -Hntp state established：-t 只看 TCP，-n 保留数字地址和端口，-p 显示进程，-H 去掉表头。状态过滤由 ss 完成，进程名和 PID 再按需要缩小。

先把筛选拆成状态条件与进程归属

ss 的过滤能力分成两类。第一类是套接字条件，例如 state established、源端口、目标端口和 cgroup；它们属于 ss 的原生过滤表达式。第二类是 -p 展示出来的进程信息，其中包含进程名和 PID。进程名并不是手册列出的通用表达式谓词，因此临时排障时通常在状态过滤之后再匹配输出。

先状态、后归属有两个好处：输出更短，后续字符串匹配也更不容易命中无关连接。如果一上来运行 ss -antp 再层层过滤，监听、已连接和关闭中的套接字会混在一起，排查目标反而不清楚。

用 ss 原生 state 先缩小 TCP 连接范围

查看当前已建立的 TCP 连接，可以使用下面这条命令：

# 只显示已建立的 TCP 连接，并带出进程归属
sudo ss -Hntp state established

这里的核对点很简单：每行应包含本地地址、对端地址和状态对应的套接字信息；能够读取归属时，行尾还会出现 users:、进程名和 pid=。如果行尾没有进程信息，先不要怀疑状态条件，普通用户可能无权查看其他用户的进程归属，改用 sudo 再比较。

监听端口与异常关闭状态也可以直接换状态名：

# 查看 TCP 监听套接字；-l 明确限定监听集合
sudo ss -Hnlpt state listening

# 查看进入 CLOSE-WAIT、等待本地应用关闭的 TCP 连接
sudo ss -Hntp state close-wait

# 查看 TIME-WAIT 这类短生命周期 TCP 套接字
sudo ss -Hntp state time-wait

ss(8) 还定义了 connected、synchronized、bucket 等状态集合。要快速观察一组连接，可选集合名；要定位单一故障现象，优先写具体状态，后续判断更直观。

按进程名或 PID 继续过滤

进程名适合“我知道服务名称，但进程可能重启换 PID”的临时排障。使用 grep -F 做固定字符串匹配，可以避免把进程名中的字符误当成正则表达式：

# 先由 ss 限定 ESTABLISHED，再匹配 nginx 的进程字段
sudo ss -Hntp state established | grep -F '("nginx",'

# 监听场景同样先限定状态，再匹配进程名
sudo ss -Hnlpt state listening | grep -F '("nginx",'

核对时应同时看进程名、PID、本地端口和对端地址。仅匹配普通单词 nginx 可能碰到其他字段；匹配 ("nginx", 更贴近 -p 的进程片段，但脚本仍应考虑不同 iproute2 版本的输出变化。

PID 适合追踪某个已经锁定的进程实例：

# 把 2451 替换为已确认的目标 PID，逗号用于缩小误匹配范围
target_pid=2451
sudo ss -Hntp state established | grep -F "pid=${target_pid},"

PID 会在进程重启后变化，所以它适合一次性诊断，不适合长期监控规则。脚本化之前还要处理 grep 无匹配时返回非零状态的情况，不能把“当前没有目标连接”直接当成命令故障。

systemd 服务优先考虑 cgroup 条件

ss 的表达式支持 cgroup 谓词。与进程名文本相比，cgroup 更接近服务边界：同一个服务的主进程和工作进程可以落在同一层级中，进程重启也不需要更新 PID。典型用法如下：

# 路径必须替换为本机已经确认的 cgroup v2 相对路径
service_cgroup=/system.slice/nginx.service
sudo ss -Hntp state established cgroup = "$service_cgroup"

先从本机服务管理信息确认路径，再传给 ss；不要根据服务名猜路径。该方案还取决于系统的 cgroup 层级与 iproute2 支持情况。如果命令报告表达式不支持或路径不匹配，就退回“原生状态过滤 + 进程字段匹配”，不要把两者结果强行视为等价。

根据排障场景选择筛选方案

实际使用时还要避开三个常见问题。第一，忘记 -a 或 -l 时，默认输出并不等于全部 TCP 套接字；第二，没有足够权限时，-p 可能看不到期望的进程；第三，把 grep 放在最前面无法减少 ss 查询的状态范围，只是在处理已经产生的文本。

常见问题

为什么用了 -p 仍然看不到进程名？

先确认连接确实属于仍在运行的用户态进程，再比较普通用户与 sudo 的结果。权限不足时，套接字本身可能可见，但其他用户的进程归属不会完整显示。

为什么 ss -t 默认没有监听端口？

ss 无参数或只限定协议时的默认集合不是“所有套接字”。查看监听端口应显式加 -l，需要同时看监听与非监听集合时再考虑 -a。

进程名过滤和 cgroup 过滤哪个更适合脚本？

一次性排障用进程名更方便；稳定的 systemd 服务更适合 cgroup，因为它不依赖某个 PID，也能覆盖工作进程。跨发行版部署时，应先确认目标环境的 cgroup 路径和 iproute2 能力。

能不能再按端口一起筛选？

可以。ss 表达式支持 sport 与 dport 谓词。应把端口条件留在 ss 原生表达式中，再对进程字段做后处理，这样比对整行文本匹配端口更明确。