Linux ss 看不到监听端口时先查哪个 namespace

Linux 上执行 ss -lntup 却看不到明明已经启动的监听端口时，优先检查的不是端口号，也不是立刻重启服务，而是网络命名空间（network namespace，简称 netns）。端口、网络设备、路由表以及 /proc/net 都属于网络命名空间的视图；如果服务在容器 netns 中，而你在宿主机的初始 netns 里执行 ss，结果为空是正常现象。

先确认 ss 当前到底在看哪个网络命名空间

第一步只做观察，不要先修改服务配置。下面的命令会同时显示当前 shell 的 netns 标识和监听 TCP/UDP socket：

# 记录当前 shell 的网络命名空间，并查看监听端口及进程
readlink /proc/self/ns/net
ss -lntup

# 只筛选目标端口，避免被大量连接干扰
ss -lntup '( sport = :8080 )'

如果第二条命令没有输出，只能说明“当前视图里没有 8080 的监听 socket”，不能直接推出服务没有启动。特别是在 Docker、Podman、Kubernetes 或手工使用 unshare 创建 netns 的环境中，宿主机和容器可以分别拥有自己的端口空间。

用 /proc/PID/ns/net 判断服务和命令是否同域

已知服务 PID 后，把它和当前 shell 的 net 指针并排比较。符号链接括号中的编号相同时，通常说明两者加入了同一个网络命名空间；编号不同时，ss 看不到对方的端口就有了明确解释。

# 将 1234 替换为目标服务的真实 PID
pid=1234
printf 'shell netns: '; readlink /proc/self/ns/net
printf 'process netns: '; readlink "/proc/$pid/ns/net"

# 同时查看进程所在命名空间的网络接口，辅助确认容器边界
nsenter -t "$pid" -n ip addr

这里的 -n 表示切换到目标进程的网络命名空间。若 nsenter 报权限错误，先确认排查账号是否有进入该进程命名空间所需的权限；不要把权限错误误判成端口不存在。

在正确的 netns 中重新执行 ss

如果目标进程 PID 是可靠的，最直接的复查方式是让 nsenter 在它的网络命名空间里执行 ss：

# 在目标进程的网络命名空间中查 8080 的监听端口
pid=1234
nsenter -t "$pid" -n ss -lntup '( sport = :8080 )'

如果服务确实监听在 8080，这时通常会看到类似 LISTEN 0 4096 0.0.0.0:8080 的结果；若要看到进程信息，执行用户需要拥有查看 socket 对应进程的权限。结果里的绑定地址也有意义：127.0.0.1:8080 只接受该 netns 内的回环访问，不等于宿主机或其他容器能够访问。

对于已经由 ip netns 命名并挂载的命名空间，也可以使用：

# 只在名为 app-net 的网络命名空间中筛选 TCP 监听
ip netns exec app-net ss -lntp '( sport = :8080 )'

哪些结果能证明是视图问题

复查时建议固定记录三项：readlink /proc/PID/ns/net 的结果、执行 ss 的命名空间、监听地址与 PID。三者对不上时，先修正观察位置；三者一致但仍无端口，才进入服务启动和 bind 配置排查。

常见问题

为什么在宿主机执行 ss 看不到容器端口？

容器通常使用独立网络命名空间，宿主机的 ss 只显示宿主机视图。应进入容器或用目标进程的 PID 配合 nsenter -t PID -n 查询。

ss 的 -N 参数什么时候使用？

ss -N 名称 用于切换到指定名称的网络命名空间；前提是该命名空间能通过名称访问。只有进程 PID 时，nsenter -t PID -n 更直接。

看到 LISTEN 是否代表外部一定能连通？

不代表。还要检查绑定地址、veth 或端口映射、防火墙规则以及访问方是否位于可达的网络命名空间。