ss -ti 的 retransmits 字段仅统计 rto 超时重传，不包含快速重传、sack 或 tlp；其值为 0 不代表无丢包，持续增长才表明存在稳定丢包问题。
ss -ti 的 retransmits 字段只统计超时重传，别当成总重传数
执行 ss -ti state established 时，每行末尾的 retransmits 值常被误读为“该连接至今重传了多少次”，但它实际只计 RTO 超时触发的重传，不含快速重传（3×dupACK）、SACK 重传或 TLP。这意味着：
- 即使
TcpRetransSegs在 /proc/net/snmp 中持续上涨，retransmits仍可能长期为 0 - 该值在连接关闭后清零，无法回溯历史；只对当前活跃连接有效
- 它对应内核统计中的
TCPTimeouts，不是TCPRetransSegs
若你看到某连接 retransmits > 0 且随时间增长，说明该路径存在稳定丢包或高延迟，值得重点排查。
用 ss -tunap 定位目标连接，再加 -i 查重传细节
单靠 ss -ti 列出所有连接效率低、干扰多，必须先缩小范围：
- 查特定端口（如 443）：
ss -tunap dport = :443 - 查特定远端 IP：
ss -tunap dst 192.168.1.100 - 查特定进程（如 nginx）：
ss -tunap | grep nginx
拿到目标四元组（源IP:端口 → 目标IP:端口）后，再执行 ss -ti src 10.0.1.5:34567 dst 10.0.2.8:443，输出中 retransmits 才真正对应这个流的超时重传次数。
宝塔Linux面板11.8.1
下载
宝塔Linux面板11.8.1为官网当前正式版，新增AI建站能力并经过宝塔网站工程师深度调教，开放自定义AI功能API，同时对WAF进行界面重构和深度优化，提升拦截能力与运维效率。
/proc/net/snmp 是唯一能查系统级累计重传段数的地方
想确认整个系统是否在重传，不能依赖 ss -s 或 netstat -s 的模糊描述，直接读内核原始计数器：
- 运行
cat /proc/net/snmp | grep -A1 Tcp | tail -n1，找到类似这一行：Tcp: RtoAlgorithm RtoMin RtoMax InSegs OutSegs RetransSegs InErrs ... - 第 15 列是
RetransSegs（已重传 TCP 段总数），第 11 列是OutSegs（总发出段数） - 该值自启动累计，重启归零；不同内核版本列序基本一致，但建议先
head -1 /proc/net/snmp确认字段顺序
netstat -s 只是它的文本封装，字段名不统一（有的写 TCPRetransSegs，有的写 RetransSegs），解析脚本容易翻车；而 /proc/net/snmp 格式稳定，Prometheus node_exporter 也直读它。
tcpdump 抓包才是验证重传行为的最终手段
当 ss -ti 和 /proc/net/snmp 提示异常，但你还不能确定是哪条路径、哪个包在重传，就得抓包：
- 抓指定连接：
sudo tcpdump -i any 'tcp and (src host 10.0.1.5 and dst port 443)' -w conn.pcap - Wireshark 打开后过滤
tcp.analysis.retransmission，就能标出所有重传包 - 注意：抓包本身不区分重传类型（超时/快速/SACK），但能确认是否真有重复序列号、是否被接收端丢弃
别指望 ss 或 netstat 告诉你“为什么重传”——只有抓包结合 dropwatch 或 tcpretrans（bcc 工具）才能定位到丢包点在 iptables、socket 接收队列还是网卡驱动层。
