不少运维人员在遇到VPN隧道卡顿、丢包、TCP重传计数异常攀升的问题时，经常跳过信息收集环节直接修改TCP重传相关参数，反而引发更难定位的隐性故障，甚至导致全隧道业务中断。做好前置信息记录，是后续调整效果校验、故障回溯、参数回滚的核心前提，本文就围绕VPN与TCP重传：调整前需要记录什么，梳理全流程的必填信息项，避免无依据调整引发的次生问题。
第一类：当前VPN隧道的原生运行状态基线数据
首先要记录调整前数天内的VPN隧道整体连通性日志，包括正常在线时长、异常断连的发生频次、断连触发的时间点，不要只截取调整前1小时的瞬时数据，否则很容易把公网偶发的网络波动当成原有参数不合理导致的问题，后续调整后也没法判断优化动作是否真的起到作用。
接下来要通过端口镜像抓包，记录VPN隧道封装前后的TCP重传原始统计，这里要明确区分是公网侧物理链路的原生TCP重传，还是VPN隧道封装后的虚拟链路重传，很多新手容易把普通公网的链路故障引发的重传当成VPN配置问题，提前把两类重传的占比、发生时段、对应传输的业务流量类型记录清楚，后续调整后才能准确判断参数是否针对VPN链路生效。
第二类：两端网络设备的原生TCP配置基线
首先要分别导出VPN服务端和VPN客户端所在设备的操作系统默认TCP参数配置，包括当前和重传逻辑直接相关的多个核心参数的原始值，不要凭记忆直接修改，不同操作系统发行版、不同VPN设备固件版本的默认参数差异很大，没有原始记录后续想回滚到初始状态都找不到基准参照。
运维人员在调整TCP重传相关参数前，完整采集记录VPN隧道的原生运行基线数据，为后续操作提供可靠依据
还要记录VPN网关本身的专属TCP优化配置项，不少商用VPN设备会在系统内核之外单独封装一层隧道传输的重传控制逻辑，这类自定义参数不会出现在普通系统TCP配置列表里，如果调整前没有单独导出记录，后续很容易出现内核参数和VPN专属配置冲突的问题，导致重传逻辑完全不符合预期。
同时要记录当前VPN链路经过的所有中间网络节点的已知限制，比如部分运营商的核心网会对长连接的高频重传报文做限速，部分企业内网的安全网关会对超过特定频次的重传报文直接丢弃，把这些节点的已知策略提前记录，后续调整参数后如果故障没有改善，就能快速排除中间节点的限制因素，不用反复在VPN设备侧排查。
第三类：当前业务场景的实际运行特征记录
要统计当前跑在VPN隧道上的业务流量类型分布，比如是实时音视频会议流量、大文件备份流量还是普通的网页办公流量，不同业务对TCP重传的容忍度完全不同，没有提前记录业务占比，调整参数后很容易出现某一类业务体验恶化的次生问题，比如调低重传等待时间后，大文件传输的乱序占比反而会明显上升。
还要记录当前已知的所有VPN相关故障现象的完整特征，比如是部分用户访问特定资源卡顿、还是全隧道的传输速率上不去，是高峰期带宽占满时才会出现重传激增、还是闲时低负载状态下也有大量无效重传，火烧云把这些现象的触发条件、影响范围记录清楚，后续调整后可以直接对应校验问题是否得到缓解。
第四类：调整前的基准测试环境快照
要固定一个可复现的测试样本集，比如选一台固定位置的VPN客户端设备，在调整前完成多次基准传输测试，把每次测试的重传统计、传输耗时、峰值带宽数据全部留存，后续调整参数后用完全相同的测试环境、相同的测试样本做对比，得到的结果才有参考价值，不会被随机网络波动干扰判断。
还要记录调整前的VPN网关系统资源占用基线，包括VPN网关的CPU、内存、出口带宽占用率，很多时候重传激增是设备硬件资源不足导致的，科学上网单纯修改TCP重传参数完全无法解决问题，提前记录资源基线可以避免后续很多无效的参数调优动作，少走不必要的弯路。
最后还要单独完成参数调整前的全量配置备份，把所有涉及的系统内核参数、VPN隧道配置项单独导出存到离线位置，一旦调整后出现大面积连通故障，可以第一时间回滚到调整前的状态，避免业务长时间中断，这也是很多运维人员最容易遗漏的关键步骤。
