很多运维人员在VPN隧道出现卡顿、应用超时的时候，第一反应直接调整TCP重传参数，反而容易把原本的隐性网络问题掩盖，猎豹加速器甚至导致业务断连，VPN与TCP重传：调整前需要记录什么是很多企业远程接入运维的核心盲区，只有把所有关联的关键信息完整留存，后续调整参数才能做到可回溯、可回滚，不会出现调整后故障范围扩大的问题。
当前VPN隧道的基础连接状态信息
首先要记录VPN隧道本身的运行状态，不能跳过这一步直接碰TCP参数。要先确认VPN是跑在公网还是专线之上，隧道两端的公网/专线接口的实时带宽占用、错包计数、接口队列溢出次数，还有VPN加密算法、猎豹加速器隧道封装模式的当前配置。
这里要注意不要只看隧道的虚拟接口状态，还要记录两端公网侧的NAT映射存活时长，很多时候TCP重传异常不是内核参数的问题，是中间NAT设备提前把映射条目老化删掉了，才会触发大量不必要的重传，跳过这一步记录很容易把后续参数调整的方向带偏。
故障发生时的TCP原生交互日志
VPN与TCP重传：调整前需要记录什么，最核心的就是没有经过隧道封装修改的原始TCP交互数据，要在VPN隧道两端的物理网卡侧同时抓包，而不是只在虚拟隧道接口上抓包，避免隧道封装的额外开销干扰对原始TCP行为的判断。
运维人员在调整TCP重传参数前，完整记录VPN隧道关联的各项关键状态信息
抓包的过滤规则要同时覆盖VPN封装报文和穿越隧道的业务TCP报文，完整记录从三次握手到出现重传现象的全流程报文序列，包括初始SYN包的往返时延、第一次出现重传时的序列号、重传间隔的初始值，不要只截取重传发生的片段，否则后续很难判断重传触发的根因是路径丢包还是对端没有及时回ACK。
两端系统当前的TCP栈默认配置
调整TCP重传参数之前，必须把当前内核所有和TCP重传相关的默认参数全部导出留存，包括初始重传超时阈值、最大重传次数、慢启动阈值、猎豹加速器快速重传触发的重复ACK计数这些配置项，不要只记录你打算修改的那几个参数。
很多运维人员调整参数前没有备份原有配置，后续调整出问题之后根本没法快速回滚到初始状态，甚至不同业务节点的默认TCP配置本来就有差异，没有记录的话后续排查参数调整的效果根本没有对照基准，最后甚至会出现不同节点配置混乱的情况。
故障场景对应的业务侧实际表现
不能只盯着网络层面的参数，还要记录触发重传异常的具体业务场景，是远程桌面访问、跨网文件传输还是业务系统接口调用，网络加速器同时记录同一时刻没有走VPN隧道的同类型业务的运行状态，用来排除业务本身的逻辑问题导致的响应超时，避免把业务问题误判成TCP重传配置问题。
还要记录同一VPN节点下其他用户有没有出现同类问题，是单个用户的终端侧问题、部分网段的路径问题还是全部用户的共性问题，这些信息能帮你区分后续调整TCP重传参数的影响范围，避免调整之后影响所有接入用户的正常使用。
最后所有记录的信息要统一归档，标注清楚记录的时间点、操作人员、当时的故障现象，后续调整完TCP重传参数之后，还要和之前的记录做逐项对照，确认调整带来的变化是符合预期的，没有引入新的不可控问题。如果调整后故障反而加重，还可以直接对照之前留存的配置快速回滚，把业务影响降到最低。
