Linux ss按进程与端口筛选监听套接字的实现方法

排查 Linux 上“某个端口到底被谁监听”时，我更愿意先用 ss 把范围缩小到监听套接字，再看进程信息。最稳的基线命令是 sudo ss -ltnp：-l 只看 listening，-t 只看 TCP，-n 保留数字地址和端口，-p 显示占用套接字的进程。端口已知时，再加上 'sport = :8080'，比先看全部连接再凭经验猜更可靠。

先把 ss 查询收敛到监听套接字

ss 的默认输出并不是“所有监听端口”，而是开放的非监听套接字；因此排查服务入口时，第一步应该显式加 -l。如果需要同时看 UDP，把 -t 换成 -u，不要把两类结果混在一起解释。

# 只看 TCP 监听端口，并显示数字地址、端口和进程
sudo ss -ltnp

# 只看 UDP 监听端口；UDP 没有 TCP 的连接状态语义
sudo ss -lunp

# 让输出保持一行，便于复制到工单或后续脚本处理
sudo ss -ltnp -o

-o 会补充 TCP 定时器信息，适合需要观察连接计时的场景，但它不是进程筛选开关。经验上，第一次定位只保留 -ltnp，减少无关字段，确认目标后再加扩展信息。

用 sport 表达式精确筛选端口

已知服务端口时，使用 sport 表示本地端口，最容易避免把远端端口或已建立连接混进来。下面的写法只看 TCP 监听状态中本地 8080 端口：

# 只筛选本地监听的 8080 端口
sudo ss -ltnp 'sport = :8080'

# 同时限定 IPv4，避免只在 IPv6 上监听的结果造成误判
sudo ss -4ltnp 'sport = :8080'

# 查询一组大于等于 8000 的本地监听端口
sudo ss -ltnp 'sport >= :8000'

官方语法允许用 =、!=、>、、>= 和 比较端口。生产排障里建议先用等值查询，确认服务后再扩大范围；端口名也可以使用服务名，但用数字更方便跨机器复盘。

从 users 字段定位进程和 PID

-p 会在结果中显示类似 users:(("nginx",pid=1234,fd=7)) 的信息。ss 的过滤表达式主要匹配地址、端口、设备、cgroup 等条件，并没有“按进程名直接筛选”的通用谓词，所以进程名通常在输出层做二次过滤。

# 先把监听范围缩到目标端口，再按进程名过滤
sudo ss -ltnp 'sport = :8080' | grep 'users:(("nginx"'

# 只保留表头和包含目标进程的行，避免空结果看不出字段含义
sudo ss -ltnp | awk 'NR == 1 || /users:\(\("caddy"/'

# 已拿到 PID 后，再查看进程命令行；失败时保留原始 PID 供继续排查
pid=1234
ps -p "$pid" -o pid=,user=,comm=,args= || echo "进程已退出，重新执行 ss"

如果结果里只有地址和端口，没有 users，先用 sudo 重跑。权限不足时，进程信息可能被内核隐藏；而进程刚好在重启，则可能出现 PID 与服务管理器状态不一致，应该把 ss 和 ps 的查询时间一起记录。

查不到监听结果时按边界复核

遇到“服务明明启动却查不到”，不要立即改服务配置。先按四个边界复核：第一，确认查询的是 TCP 还是 UDP；第二，用 ss -4 和 ss -6 分别查看地址族；第三，确认端口是本地 sport 而不是远端 dport；第四，容器、沙箱或网络服务运行在独立 namespace 时，要在相同 namespace 中查询。

最终工单至少保留一条完整命令、执行时间、Local Address:Port、进程名/PID 和权限信息。这样下一次服务重启后，即使 PID 发生变化，也能重新用端口和地址复现，而不是只凭一张模糊的“端口占用”截图判断。

相关问题

为什么 ss -ltnp 看不到已经建立的连接？

因为 -l 只保留监听套接字。需要看连接时去掉 -l，或明确使用 state established，不要把两种状态混为一谈。

为什么端口能看到但 PID 显示不出来？

最常见原因是权限不足或进程在查询瞬间退出。先用 sudo 重跑，再用 PID 查询进程状态；如果仍为空，记录服务重启和 namespace 边界。

sport 和 dport 应该怎么选？

排查本机监听入口优先用 sport；分析客户端连接到哪个远端服务时才使用 dport。端口相同不代表语义相同。

这套方法的核心不是记住一条万能命令，而是先锁定监听状态，再锁定协议和本地端口，最后把 users 字段中的进程信息与权限、地址族、namespace 一起解释。