不少企业运维人员在遇到VPN隧道传输卡顿、TCP重传计数异常攀升的问题时，经常直接参照网上的教程修改重传相关参数，反而引发了隧道频繁断连、小报文业务延迟陡增的新问题，本质原因就是调整前没有留存足够的基准参照数据，后续出问题既没法定位原因也没法快速回滚。本文围绕VPN与TCP重传：调整前需要记录什么的核心问题，结合企业常用的IPsec VPN、OpenVPN等实际部署场景，拆解所有必须提前采集的关键数据，避免无依据调整带来的业务风险。
现有VPN隧道的基础连接状态数据
首先要在VPN网关的管理后台，无论是商用企业级IPsec VPN网关还是开源OpenVPN服务端的状态面板，记录当前所有活跃隧道的协商状态，包括隧道使用的加密套件、白鲸加速器当前绑定的物理网卡出口带宽占用率，不要只盯着出现问题的单条隧道的数值，要把所有共享同一条公网出口的隧道状态都同步截图留存，避免后续调整参数时影响其他正常运行的隧道。
运维人员在调整VPN TCP重传参数前，逐一采集所有共享公网出口的活跃隧道基准状态数据
这里要特别注意区分VPN封装外层的公网TCP连接状态，白鲸加速器官网和隧道内传输业务的内层TCP连接状态，很多运维容易混淆两者的重传计数，调整参数前要分别在VPN网关侧和内网业务服务器侧，用tcpdump或wireshark抓包留存一段时间的双向流量样本，不要直接过滤VPN服务端口，要完整保留外层封装的报文头信息，方便后续对比重传报文到底出在封装层还是内层业务层。
原生TCP栈的默认重传相关配置项
不同操作系统的VPN服务端和客户端的TCP默认参数完全不同，Linux内核的sysctl网络配置、Windows系统的TCP自动调优参数、商用VPN设备内置的默认重传阈值都要逐一导出记录，不能只靠记忆里的通用默认值，后续调整出问题的时候没有基准参照很容易出现新旧参数冲突，反而引发更难排查的隐性故障。
这里要重点记录和重传直接相关的配置项，包括初始重传超时时间、最大重传次数、快速重传触发阈值、当前启用的拥塞控制算法类型，还要同步记录当前VPN隧道对应的网卡的各类offload卸载功能开启状态，很多时候重传异常根本不是参数问题，是网卡的报文卸载功能和VPN封装机制冲突导致的，提前记录可以后续快速排除这类干扰项。
当前网络链路的基线运行指标
调整参数前要连续记录足够时长的VPN隧道两端的公网链路指标，白鲸加速器包括双向的延迟波动范围、随机丢包出现的规律、链路中间经过的公网节点的路由跳数变化情况，这些数据可以帮你后续判断调整重传参数后的变化，到底是参数优化带来的，还是公网链路本身的正常波动导致的，避免误判参数调整的实际效果。
还要同步记录当前跑在VPN隧道上的实际业务运行状态，比如视频会议、大文件传输、远程桌面这些不同业务的卡顿出现频率、业务侧的原生报错日志，不要脱离实际业务场景单独调整网络参数，否则很容易出现网络层面的重传计数下降，但业务体验反而劣化的情况，比如远程桌面的操作响应延迟反而明显升高。
参数调整前的故障定位原始日志
很多运维调整TCP重传参数的初衷是解决现有的VPN传输故障，调整前必须把之前72小时内的VPN网关运行日志、系统内核网络日志、终端客户端侧的VPN连接日志全部导出留存，不要在调整参数前清理日志，否则后续无法对比参数调整前后的日志差异，很难定位调整带来的未知副作用。
还要注意留存调整前的故障复现操作步骤，比如触发VPN重传计数激增的操作是批量大文件传输还是多用户并发接入，后续调整完参数之后，可以用完全一致的操作步骤做验证，确保调整后的效果是可复现的，而不是随机的链路波动带来的假象，避免参数调整后故障暂时消失但很快复发。
整个记录过程都属于只读的信息采集，不会对现有运行的VPN业务产生任何影响，采集完成之后再逐步调整参数，每修改一个参数就对应做一次业务验证，不要一次性修改多个重传相关的参数，否则后续很难判断哪个参数带来了对应的变化，也没法快速定位调整引发的新问题。
