云主机上用 ss 看监听和连接

登录一台云主机排查“端口没通”时，很多人还在找 netstat。不少新发行版默认不再安装 net-tools，netstat 要么不存在，要么只是 iproute2 的一个兼容包装。直接用 ss 更合适：它读内核的套接字信息，输出更快，过滤条件也更明确。下面是我在排查云主机端口时固定的三步，只读查看，不改防火墙、不改安全组。

一、先确认进程到底有没有在听

端口不通，先分清是进程没监听，还是监听了但被安全组或本机防火墙挡住。只看 TCP 监听：

ss -lnt

-l 是 listening，-n 是不把端口解析成服务名，-t 是 TCP。输出里的 Local Address 如果是 127.0.0.1:8080，说明进程只接受本机连接，云主机的公网或内网 IP 都连不上，这和安全组无关。如果是 0.0.0.0:8080 或 *:8080，才表示在所有网卡上监听。IPv6 同理，再加 -6，或直接用 ss -lntu 把 UDP 一并看掉。需要对应进程时加上 -p，没有权限就只能看到用户自己的进程，看系统服务需要相应权限，不要为了看一行输出去改账号。

二、按端口和状态把连接收窄

监听正常但业务仍超时，再看已建立的连接，而不是把全部套接字打出来：

ss -tnp state established '( sport = :8080 or dport = :8080 )'

state established 只留已建立连接。括号里的过滤表达式是 ss 自己的语法，sport 是本地端口，dport 是对端端口。连接数异常多时，先数一下：

ss -tn state established '( sport = :8080 )' | wc -l

如果 LISTEN 存在、established 却一条都没有，请求多半在到达主机之前就被安全组、网络 ACL 或上游负载均衡丢掉了。这时去翻应用日志通常看不到报错，因为请求根本没进进程。反过来，如果存在大量 SYN-RECV 或 TIME-WAIT，再用 ss -tan 按状态查看，判断是连接建不起来，还是旧连接回收不及。不要一上来就 tcpdump，抓包的噪音更大，也更容易误抓到不该看的流量。

三、和本机防火墙对一下，再决定要不要动安全组

ss 只能说明套接字在不在，不能说明安全组是否放行。在改云上安全组之前，先看本机有没有再拦一层。firewalld 环境可以用：

firewall-cmd --list-ports

nftables 环境用 nft list ruleset，只看不改。如果本机已经放行，而从另一台同子网主机仍连不上，再去控制台核对安全组入方向和路由，避免在主机上反复重启服务。排查顺序可以记成一句：ss 看监听地址，ss 看连接状态，最后才看安全组和防火墙。这样大部分“端口没通”在两分钟内就能分出是进程、本机防火墙还是云网络的问题。

补充两个容易看错的地方。ss 默认把 IPv4 和 IPv6 分开列出，同一个端口可能出现两行。如果应用只绑定了 IPv4，客户端却走 IPv6，连接会失败，看起来像“端口开了但连不上”。对照 Local Address 里是 0.0.0.0 还是 [::]，就能分清是哪一层地址族。容器场景里，宿主机上看到的监听进程常常是 docker-proxy 或转发进程，并不等于容器内的业务进程。这时 -p 只能当线索，还要回到端口映射确认容器里的进程是否真的在听。把地址族和进程名一起看完，再决定要不要改安全组，能少走一次弯路。