Linux网络连接异常中断分类统计报表查看方法

netstat -s 提供的本质上是网络协议层的错误分类统计结果，并不是实时记录每一次连接异常中断的日志。它主要用于汇总 TCP、UDP 等协议的累计错误计数，例如重传次数、SYN 超时次数以及 RST 报文的收发总量。由于这类统计信息没有时间戳、源 IP、目标 IP 和进程上下文等关键数据，仅凭它通常无法直接判断具体是哪一次连接中断、因为什么中断，因此往往还需要结合 /proc/net/snmp、/proc/net/netstat 或 tcpdump 等工具做进一步排查。

netstat -s 输出的是协议层错误分类，不是连接中断日志

很多用户误以为 netstat -s 能直接查看“某一条连接在什么时间、因为什么原因被中断”，但实际上它统计的只是内核协议栈不同层的累计异常事件，例如 TCP 重传、SYN 超时、RST 报文收发次数等。这些数据属于分类汇总值，并不包含时间戳、源/目标 IP 地址，也没有对应的进程信息。

核心要点是：netstat -s 的输出会按协议分别展示，如 TCP、UDP、ICMP 等，而每一部分本质上都是计数器的累计结果。比如 TCP 区块中的 timeouts 表示 SYN 或重传超时的累计次数，retransmits 表示重发报文的总数。它们更适合用来观察网络稳定性趋势和异常增长情况，而不是定位某一次具体的连接断开事件。

• netstat -s 通常需要 root 权限才能看到更完整的网络统计信息，否则部分字段（如某些 TCP 错误计数）可能显示为 0 或不完整
• 输出里的 “failed connection attempts” 和 “connection resets” 往往是排查连接主动断开、连接失败的重要指标
• UDP 模块中的 “packet receive errors” 常见原因是校验失败、接收缓冲区溢出等问题，它与 TCP 的重传机制并不是同一类故障
• 如果发现 TCPSynRetrans 数值较高，而 TCPEstabResets 较低，通常说明问题更集中在建立连接阶段，例如网络延迟、防火墙拦截或服务端无响应，而不是应用层主动关闭连接

/proc/net/snmp 和 /proc/net/netstat 提供更细粒度的 TCP 状态跃迁统计

相比 netstat -s，/proc/net/snmp 和 /proc/net/netstat 更接近内核底层，字段名称也更清晰，特别适合通过脚本进行差值统计和趋势分析。比如 /proc/net/snmp 中的 TCP 行包含 EstabResets（已建立连接被重置次数）、AttemptFails（发起 SYN 后连接失败次数）、RetransSegs（重传段数量）；而 /proc/net/netstat 还会进一步给出 TCPFastRetrans、TCPSlowStartRetrans 等更细的 TCP 重传分类。

需要注意的是，这些字段也都是系统启动以来持续累加的统计值，单次读取参考意义有限，通常必须通过两次采样计算差值，才能真正判断问题是否正在发生。例如：

awk '$1=="Tcp:" {print $15,$16}' /proc/net/snmp# 输出 EstabResets 和 AttemptFails 当前值

• AttemptFails 持续增加 → 说明客户端发送 SYN 后没有收到 SYN-ACK，可能原因包括目标端口未监听、防火墙丢弃数据包或路由不可达
• EstabResets 高于 PassiveOpens → 表示对端频繁返回 RST，常见场景包括服务进程崩溃、负载过高被系统 kill，或连接池策略导致强制回收
• TCPSynRetrans 与 TCPRetransSegs 同时偏高 → 往往意味着网络链路中存在丢包，建议结合 ping、mtr 等工具继续确认中间节点状况
• 在容器环境中，如果 TCPRetransSegs 异常升高但宿主机正常，则问题更可能出现在 veth pair、bridge 或 CNI 插件队列，而不是物理网卡本身

真正定位“具体哪次中断”的唯一办法是抓包 + 连接状态回溯

netstat 这类命令无法直接告诉你“192.168.1.100:52341 在 14:22:33 被 10.0.2.5 发来的 RST 中断了连接”。如果要定位到这种级别的网络连接异常中断明细，就必须依赖 tcpdump、ss -i 以及带时间戳的连接状态信息进行联合分析。

实操建议：

• 先通过 ss -tni 查看当前 ESTABLISHED 连接的重传队列和状态信息，例如 rtt、rto、qloss 等字段，若存在明显丢包或延迟迹象，再进一步抓包分析
• 针对可疑端口执行抓包：tcpdump -i eth0 'port 8080 and (tcp[tcpflags] & (tcp-rst|tcp-fin) != 0)' -w rst.pcap，专门筛选出带有 RST/FIN 标记的 TCP 报文
• 使用 tshark -r rst.pcap -T fields -e ip.src -e ip.dst -e tcp.flags.reset -e frame.time 提取 RST 发生时间、源地址和目标地址，从而还原是谁主动发起了连接重置
• 如果异常中断出现在 TLS 握手完成之后，tcpdump 通常只能看到 FIN/RST 的结果，真正的原因还需要结合应用日志，或借助 openssl s_client -debug 进一步检查证书、协议版本、ALPN 协商等问题

别依赖 netstat -i 看连接中断，它只统计链路层帧错误

netstat -i 显示的是网络接口的收发包数量、错误数和丢弃数，本质上对应的是 OSI 第二层，也就是链路层或 MAC 层统计。这里面的 errs、drop 更多反映的是网卡驱动、内核收包队列或硬件链路层面的异常，例如 RX ring buffer 溢出、DMA 失败、CRC 校验错误等，它和 TCP 连接是否发生中断并没有直接的一一对应关系。

常见误区：

• 看到 eth0 的 rx_errs 很高，就判断为“网络连接频繁中断”，其实也可能只是交换机端口 CRC 错误偏多，而上层 TCP 通过自动重传已经把问题掩盖掉了
• tx_dropped 不为 0 并不等于连接已经断开，它通常表示内核发送队列已满，待发送数据包被丢弃，更常见于本地处理能力不足，例如 CPU 紧张或软中断瓶颈，而不是物理链路直接故障
• 如果想确认物理链路本身是否稳定，应优先使用 ethtool eth0 查看 Link detected 和 Speed 等信息，而不是只看 netstat -i
• 在容器环境中，若 netstat -i 显示高 tx_dropped，大概率问题出在宿主机的 br0 或 veth 设备，比如 txqueuelen 设置过小，可以尝试调大 ip link set dev vethxxx txqueuelen 10000 后继续观察

回到真实的生产环境中，网络连接异常中断的根因通常分散在协议栈不同层级的多条线索里。比如 /proc/net/snmp 里的 TCP 重传计数、tcpdump 抓到的 RST 报文方向，以及应用日志中的 close_notify 记录，往往都需要互相印证、精确对齐，才能最终确认问题根源。单独依赖某一个命令输出的统计报表，通常只能看到整个网络故障拼图中的一小部分。