调高net.ipv4.tcp_retries2不会减少重传，只延长死连接存活时间；重传频发根因是底层丢包或延迟，需用ss -i、tcpretrans定位源头，并排查网卡驱动、TSO/GSO、MTU及物理链路等问题。
为什么 net.ipv4.tcp_retries2 调高反而让重传更频繁？
这不是参数本身的问题，而是它只控制「超时后重试的轮数上限」，不控制重传触发条件。真正导致重传次数升高的是底层丢包或延迟，tcp_retries2 只是决定了系统在放弃连接前“最多试几次”。默认值 15 意味着最后一次重传后约 15–30 分钟才断连，期间你看到的“高重传次数”其实是持续丢包下的被动响应。
- 调大
tcp_retries2不会减少重传，只会延长死连接的存活时间，可能掩盖真实网络问题 - 调小（如设为 6）会让连接更快失败，便于快速发现异常，但可能误杀弱网场景下的正常连接
- 该值对 SYN 握手阶段无效——SYN 重传由
tcp_syn_retries控制，需单独排查
如何用 ss -i 和 tcpretrans 定位真实重传源头？
ss -i 能直接显示每个 socket 的重传统计，比全局计数器更有针对性；tcpretrans（来自 bcc-tools）则可追踪到具体哪条流、哪个目的 IP 在高频重传。
- 运行
ss -i state established | grep retrans，关注retrans字段非 0 的连接，再结合dst和timer判断是否卡在某次超时 -
tcpretrans -L可列出当前所有正在重传的 TCP 流，加-C参数还能显示重传率（%），>5% 就值得深挖 - 注意区分「快速重传」（3 个重复 ACK 触发）和「超时重传」（RTO 超时触发）：前者说明路径上有丢包但链路尚通，后者往往指向中间设备故障或严重拥塞
网卡驱动、TSO/GSO 和 MTU 不匹配如何引发隐性重传？
这类问题不会报错，但会导致分片异常、校验失败或硬件丢包，最终体现为 TCP 层不断重传。常见于虚拟化环境或升级内核/驱动后。
