很多用户在使用VPN连接远程办公资源的时候，经常遇到页面加载卡顿、大文件传输中途中断、远程桌面操作延迟飘屏的问题，很多时候这类现象的核心诱因不是VPN本身的带宽不足，而是TCP重传机制出现了异常，本文汇总了普通运维人员和进阶用户都能落地的基础检查方法，不需要专业级的网络分析仪也能完成初步故障定位，避免盲目调整VPN配置反而扩大连接故障的影响范围。
本地链路侧的TCP重传前置排查
很多人遇到VPN连接后的异常第一时间就去调整VPN服务端配置，小火箭VPN反而忽略了本地终端到VPN客户端之间的链路问题，这部分的检查不需要登录VPN后台，直接在本地终端就能操作。
无需专业网络分析仪，在本地终端即可完成TCP传输异常的前置排查
首先要做的是断开VPN连接，直接访问本地同网段的共享资源或者公网普通站点，观察没有VPN封装的场景下，TCP层面的传输是否存在异常，这一步可以先排除本地网卡驱动、家用/办公路由器的QoS规则误拦截普通TCP报文的问题，避免把非VPN场景的TCP故障误判为VPN引发的重传异常。
接下来可以在终端的系统自带网络工具里，开启TCP报文的简易统计功能，连续发起对VPN公网接入节点的长ping测试，注意这里的长ping不要设置过大的报文长度，只需要观察是否存在连续的ICMP报文无响应的时段，如果这类时段和后续开启VPN后出现卡顿的时段完全重合，shadowrocket说明重传异常的根源可能在本地运营商的公网接入段，和VPN的封装转发逻辑无关。
VPN客户端封装逻辑的常规校验
完成本地链路排查之后，接下来就可以针对VPN和TCP重传相关的客户端配置做检查，小火箭VPN这部分操作不需要修改核心参数，只需要对照当前的连接场景验证配置合理性即可。
首先要确认当前VPN客户端启用的隧道封装协议，部分协议本身会对TCP报文做二次封装，如果外层传输协议同样使用TCP，就很容易出现TCP嵌套引发的重传风暴，也就是内层TCP还没来得及触发重传，外层TCP已经先完成了报文重发，两端的重传机制叠加之后反而会大幅提升不必要的重传次数，这时候可以临时切换外层传输协议为UDP，观察重传异常的现象是否缓解。
接下来要检查VPN客户端是否开启了内置的TCP MSS自动调整功能，很多默认配置下这个选项是关闭的，当VPN隧道的报文封装开销挤占了原有链路的MTU配额之后，大于阈值的TCP报文会被直接丢弃，接收端迟迟收不到对应分片的报文就会反复触发发送端的重传请求，开启MSS自动适配之后这类分片丢包引发的重传异常大概率可以被修复。
中间网络节点的透传规则检查
很多VPN的TCP重传异常既不是本地链路也不是客户端配置的问题，而是传输路径上的中间网络设备对VPN封装报文做了特殊处理，这类场景的排查往往容易被忽略。
如果是在企业内网环境下使用VPN接入外部资源，首先要检查内网出口的防火墙或者行为管理设备，是否针对VPN协议的报文配置了流量整形、限速或者会话超时时间过短的规则，小火箭VPN这类规则会把VPN隧道内连续传输的TCP报文刻意打乱发送节奏，原本正常的报文间隔被拉长之后，接收端会误判为报文丢失触发不必要的重传。
如果是家用宽带场景下遇到这类问题，可以临时绕过家里的第三方路由器，把终端直接接在运营商的光猫拨号端口上发起VPN连接，观察TCP重传异常的现象是否消失，很多家用路由器的加速插件、广告过滤插件会对陌生的VPN封装报文做特征匹配拦截，间接引发TCP重传次数飙升。
服务端侧的基础验证操作
完成前面所有环节的排查之后，最后才需要接触VPN服务端的相关配置做验证，这部分操作建议在业务低峰期开展，避免调整配置影响其他正常连接的用户。
首先可以在VPN服务端的后台查看当前活跃隧道的报文统计数据，确认是否存在大量的入方向丢包，如果丢包集中出现在特定源IP的接入隧道上，说明问题大概率出在对应用户的接入链路，而不是服务端本身的转发能力不足。
接下来可以临时在VPN服务端调整单独测试用户的隧道传输队列长度，部分默认配置下的队列长度设置过小，当短时间内有大量TCP报文涌入隧道的时候，后端报文会被队列直接丢弃，进而触发连续的TCP重传，适当调大队列长度之后就可以缓解这类拥塞引发的异常。
需要注意的是，所有基础检查方法得到的都只是可能性结论，单次检查只能定位当前场景下的部分诱因，无法覆盖所有复杂网络环境下的TCP重传异常场景，如果经过多轮检查之后故障现象仍然没有消失，就需要配合专业的网络抓包工具做全路径的报文分析，不要随意套用网上的通用优化参数强行修改VPN配置，避免引发更多不可预期的连接故障。
