Linux ss 怎样查看连接的 TCP 状态变化

Linux 上判断“连接状态在变化”时，最实用的做法不是只执行一次 netstat，而是用 ss 固定采样口径，再重复观察同一组 TCP 状态。先用 -t 限定 TCP、-a 纳入监听和非监听套接字、-n 禁止地址与服务名解析；然后用 state 过滤器把问题缩小到握手、已建立或关闭阶段。

官方文档地址：https://man7.org/linux/man-pages/man8/ss.8.html

下面的命令用于建立可比较的只读观察口径。文中的输出示例是字段形态说明，不代表某台机器的实际运行结果。

先建立稳定的 TCP 状态基线

基线的关键不是一次列出尽可能多的字段，而是每次都使用相同的协议、集合和显示方式。最小观察可以从所有 TCP 套接字开始；如果只关心监听端口，就把集合收窄到 -l。

# 固定查看 TCP 套接字，并保留监听与非监听连接
ss -tan

# 只看监听端口；-n 让端口保持数字形式，便于多次采样比较
ss -lnt

# 观察一组状态的数量变化；watch 只负责重复执行同一条只读命令
watch -n 1 -- 'ss -tan state connected'

-n 很重要：如果允许反向解析，地址或端口可能显示成主机名和服务名，解析耗时也会让两次采样的响应速度不同。要记录进程归属时再加 -p；权限不足时进程信息可能不完整，这不等于套接字不存在。

用 state 过滤器观察状态集合

ss 的状态过滤器支持标准 TCP 状态，也支持 connected、synchronized、bucket 等集合。排障时不要把状态名当成结论，而要先看它们在固定时间间隔内是否持续聚集。

# 查看监听套接字，确认服务是否在目标端口提供入口
ss -lnt state listening

# 单独查看握手阶段的两类常见状态
ss -tan state syn-sent
ss -tan state syn-recv

# 查看已经建立的连接，并按本地或远端端口缩小范围
ss -tan state established '( sport = :8080 or dport = :8080 )'

# 观察连接关闭后的残留状态
ss -tan state time-wait
ss -tan state close-wait

syn-recv 多说明观察窗口内有连接停留在服务端收到同步请求后的阶段；close-wait 则表示对端已经关闭，应用仍需处理本地关闭流程。它们都需要结合采样趋势、应用日志和端口归属继续判断。

用 -o、-i 和表达式缩小变化范围

当某个状态数量变化后，再增加诊断字段，而不是一开始就把所有信息混在一起。-o 显示 TCP 计时器，适合看重传、保活或 TIME-WAIT 计时；-i 显示 RTT、拥塞窗口等内部 TCP 信息；端口表达式负责把结果关联到服务入口。

# 查看已建立连接的计时器，帮助区分普通连接与计时器等待
ss -nto state established

# 查看 TCP 内部信息；输出字段由内核和 ss 版本决定
ss -ntoi state established

# 只观察 HTTPS 方向上的已建立连接，避免无关端口干扰
ss -nt state established '( dport = :443 or sport = :443 )'

如果结果出现 rtt:、cwnd: 或 timer:，应把它们当作当前快照中的诊断字段。它们能帮助定位方向和条件，却不能替代应用层耗时、连接池状态或负载均衡日志。

按变化模式判断下一步排查方向

可以把连续采样结果整理成三列：时间、状态数量、重点端口。监听项突然消失，先查进程是否退出或监听地址是否变化；syn-recv 持续增多，继续看服务端处理能力、监听队列和上游连接路径；close-wait 持续积累，优先回到应用是否及时关闭连接；time-wait 增多，则要结合连接创建和关闭模式判断是不是短连接过多。

最后要保留采样命令本身。一次 ss -tan 只能说明某一时刻的状态集合，不能证明状态变化的方向；只有在相同过滤条件下重复采样，才能把“当前很多”与“正在持续增长”区分开。

相关问题

为什么 ss 不加参数时看不到监听端口？ss 默认展示打开的非监听套接字；要查看监听端口使用 ss -lnt，要把两类一起列出使用 ss -ant。

state connected 和 established 有什么区别？established 只匹配已建立状态；connected 是一组集合，包含除监听和关闭之外的连接状态，适合做较宽的趋势采样。

close-wait 很多就是 Linux 网络故障吗？不能这样判断。它通常提示对端已关闭而本地应用尚未完成关闭处理，应该结合进程、连接生命周期和应用日志判断。