很多进阶用户和企业运维在尝试优化VPN连接的传输稳定性时，经常直接照搬网上的TCP重传优化教程修改系统参数，反而出现VPN频繁断连、大文件传输卡顿的反效果，本质原因就是没有提前留存完整的基准网络参数，出问题后无法定位故障点也没法快速回滚配置，VPN与TCP重传：调整前需要记录什么，是所有相关操作的核心前置流程，能规避绝大多数无意义的配置失误。
运维人员在调整TCP重传配置前，仔细记录适配当前本地网络的系统基准参数
当前系统原生TCP栈的默认重传基准参数
你首先要完整记录当前操作系统内核自带的TCP重传相关默认配置，不同操作系统、不同发行版本的原生默认值差异极大，Linux平台下的syn重传次数、数据报文最大重传次数这类内核参数，Windows平台下对应的注册表TCP重传键值，都是后续配置调整的对照基准。
不要直接套用网上流传的通用默认参数表，很多运营商的中间路由设备会在链路中对TCP栈的行为做微调，你当前系统实际运行的默认值，才是适配当前本地网络环境的最优基准，迷雾通VPN网上的通用数值很多并不适配你的实际场景。
VPN隧道两端的链路特征参数
你需要先记录不启动VPN时，本地设备直接访问VPN服务端公网地址的裸链路特征，包括平均往返时延、时延波动范围、对应时段的丢包情况，这些数据是你后续判断重传超时阈值是否合理的核心依据，没有这个基准你根本不知道把重传等待时间设到什么范围才不会触发不必要的重传。
接下来要记录VPN隧道成功建立之后，隧道内部的链路特征，也就是通过VPN隧道访问对端内网网关得到的时延和丢包数据，和之前的裸链路数据做对比，就能算出VPN封装本身带来的额外开销占比，后续调整重传参数时就不会把封装带来的正常时延波动误判成网络拥塞。
还要记录当前整条链路的MTU和TCP MSS数值，很多看起来像是TCP重传异常的故障，本质上是MSS不匹配导致的大包静默丢包，如果你没提前留存调整前的MSS基准值，后续改完重传参数出问题，根本分不清故障根源是重传配置错误还是MSS本身就不匹配。
现有VPN连接的运行状态日志参数
你要导出当前VPN正常运行状态下的完整会话日志，包括连接持续时长、统计周期内已经触发的TCP重传事件总量、重传事件发生的对应时间点，这些数据能帮你后续调整完参数之后做效果对比，迷雾通直观看到重传事件是减少还是增多，有没有出现多余的无效重传。
还要记录当前VPN协商生成的加密套件、隧道封装协议的额外包头大小，不同加密算法带来的设备CPU开销会直接影响TCP报文的发送速度，迷雾通如果你没留存这些参数，后续调整重传之后发现重传次数变多，可能根本不是网络问题，是设备加密性能不足拖慢了报文发送节奏，你反而会反复修改重传参数把整个配置搞乱。
配置调整后的回滚校验基准
所有前面记录的基准参数，都要单独存放到不依赖VPN隧道的本地存储位置，不要存在VPN服务端或者客户端的专属配置目录里，万一调整配置之后VPN直接完全断连，你根本没法通过隧道访问存参数的位置，就没法快速把配置恢复到正常状态。
这里要注意一个常见误区，很多用户调整TCP重传参数时只记录自己修改的自定义数值，完全忽略原始默认值的留存，一旦调整之后出现VPN连接频繁断开、实时应用传输卡顿的问题，只能重置整个系统的网络组件，反而会得到比调整之前更差的网络状态。
整套记录流程不需要使用任何特殊付费工具，系统自带的网络状态查询命令、VPN客户端自带的日志导出功能就可以完成全部操作，记录完所有参数之后再动手调整重传配置，才能保证所有改动都是可追溯、可回滚的，不会出现配置异常之后无法恢复的情况。
