ss 怎样按进程筛选监听端口

ss 按进程查监听端口，通常先用 ss -ltnp 列出 TCP 监听套接字及其进程信息，再按输出中的 PID 或进程名筛选。-p 是显示进程，不是指定 PID；不要把 ss -p 12345 当作按 PID 查询的通用语法。

下面只查看自己有权管理的 Linux 系统，不关闭套接字、不重启服务。ss 属于 iproute2，项目源码入口：https://git.kernel.org/pub/scm/network/iproute2/iproute2.git/。本文依据项目手册编写，命令为说明示例，未在本机执行，配图也不是运行截图。

先列 TCP 监听套接字，再读取进程字段

先不要加进程过滤。确认当前视角里有哪些 TCP 监听记录，再看这些记录是否能显示 users 字段，能避免把“进程信息不可见”误认为“没有监听”。

# 查看当前网络命名空间中的 TCP 监听，保留数字地址和进程信息。
ss -ltnp

# 为后续文本筛选去掉表头，并将每个套接字信息保持在一行。
ss -H -O -ltnp

结果里需要关联的是本地地址、端口以及 users 中的进程名、pid 和 fd。对 TCP 监听记录而言，重点是本地端点，不能把 Peer Address 当作服务监听端口。这里的 PID 是当前观察环境可见的进程标识，不是服务名称。

知道 PID 时，怎样避免匹配到相邻数字

已知 PID 时，应匹配明确的 pid 字段，而不是在整行搜索裸数字。比如直接搜索 12345，可能命中端口、另一个更长 PID，或其他字段。下面先限制变量只能含数字，再匹配 pid= 后面的完整字段。

#!/usr/bin/env bash
set -o pipefail

# 替换为当前环境中已确认的目标 PID，不把进程名当成 PID。
target_pid=12345
case "$target_pid" in
    ''|*[!0-9]*)
        echo "目标 PID 必须是数字" >&2
        exit 2
        ;;
esac

# pid 字段后以逗号结束，避免 12345 命中 123456。
ss -H -O -ltnp |
    awk -v p="$target_pid" '$0 ~ ("(^|[,(])pid=" p ",") { print }'

这段是 Bash 写法。pipefail 用来保留管道上游失败的状态，避免 ss 本身报错却被后面的文本命令掩盖。awk 没有匹配时仍可能正常退出，因此“命令退出成功”和“确实找到匹配记录”也要分开。

此处依赖常见 users 文本中的 pid=数字,fd=数字 表达形式。不同发行版版本若输出不同，应以当地手册与原始输出为准；不要把它当作长期监控系统的无版本结构化协议。PID 还可能因进程退出而复用，重要排障记录应同时保留时间和进程身份线索。

只有进程名时，怎样缩小候选范围

只有进程名时，可以先对显示名称做字面量匹配，再检查每个候选 PID。以 nginx 为例，下面查找的是进程名称字段的一部分固定表达，不是对所有内容做宽泛的 nginx 搜索：

# 按常见进程字段表达筛出候选；名称可能涉及多个主进程或工作进程。
ss -H -O -ltnp | grep -F '"nginx",'

# 已知本地端口时，用 ss 自身的端口过滤进一步缩小范围。
ss -H -O -ltnp 'sport = :8080'

第一条仍是文本筛选，名称可能截断或存在多个同名实例，不能直接证明它就是目标部署。第二条只按本地源端口筛选，不是按进程；应在结果中继续核对 PID。grep 无匹配通常退出 1，这与命令语法错误不是同一种含义。

如果应用叫 java 或 python，显示名称往往不足以区分业务实例。应先借助已有服务管理记录确认目标 PID，再按上一节查询；不要因为进程名字一样，就把几个应用的端口混成一组。

为什么有监听端口，却没有进程信息

能看到地址与端口，但看不到 users 或 pid，不代表套接字没有所属进程。读取进程关联信息受到权限、进程可见性与 /proc 访问环境影响，查询过程中进程退出也可能使关联信息不完整。

先使用自己已有权限查看。如果确实需要观察其他账户的服务，应按组织授权由具备相应权限的人执行同一只读查询，而不是为了显示 PID 修改系统隔离设置。下面仅说明已获授权时的常见调用方式：

# 仅在获准查看系统服务进程信息时使用；不修改网络或服务状态。
sudo ss -H -O -ltnp

不要把无 PID 的记录直接从排障结论中删掉。应记录“存在监听端点，但进程关联未取得”，然后再确认权限和运行环境。反过来，按 PID 查询没有输出，也可能是该进程仅发起出站连接，或它使用了本文没有选择的套接字类型。

容器里看到的 PID 和端口为什么不同

网络命名空间决定你看到哪一组套接字，PID 命名空间决定进程编号视角。宿主机和容器内的同一进程可能显示不同 PID；容器自己的监听端口也不等于宿主机对外映射的端口。

优先在已授权的容器或服务诊断环境中运行 ss，并在同一视角确认目标 PID。对于已命名的网络命名空间，ss 提供 -N NSNAME；但切换网络命名空间不等于自动解决所有 PID、/proc 和权限可见性问题。

# app-net 必须是已存在且获准查看的命名网络命名空间。
ss -N app-net -H -O -ltnp

若它报权限或命名空间不存在，保留原错误并联系该环境的管理方，不要据此判断业务停止监听。容器端口映射还可能由转发规则或代理实现；单看宿主机 ss 的进程列表，不一定能完整还原映射关系。

查到结果后，还需要区分哪些情况

UDP 也用同一条命令吗？ 需要把 TCP 范围改为 UDP，例如使用 -lunp 查看相关端点。UDP 没有 TCP 那样的 LISTEN 状态，不能拿 TCP 状态语义机械解释 UDP 输出。

同一个端口出现多个 PID 是错误吗？ 不一定。套接字可能被多个进程共享或继承，多个记录也可能属于不同地址、地址族或套接字。先保留完整端点和 PID 列表，不能强行归为“一个端口只能一个进程”。

监听 127.0.0.1 与 0.0.0.0 有何区别？ 前者绑定回环地址，后者表示该地址族的通配绑定。即使监听到通配地址，也不能直接证明外部客户端可达，还需考虑路由、访问策略与部署转发。

可以顺便关闭发现的端口吗？ 本文只是只读定位，不使用 ss 的 -K 等关闭能力。发现监听并不授权终止套接字或进程，后续变更应走独立的服务管理流程。

实用顺序是先确定观察环境，再列监听和进程字段，最后按完整 PID 匹配。把“没匹配”“没权限”“命名空间不同”分别记录，结果才不会被误读为同一个故障。

参考：iproute2 项目 ss 手册源码、Linux 命名空间工具说明。