很多用户在手动调整VPN路由规则、本地带宽限速策略或者更换VPN节点之前，经常跳过前置数据记录步骤，调整之后遇到连接卡顿、访问异常、内网资源无法连通的问题时，根本没法回溯到底是哪一步改动引发的故障，最后只能重置所有配置从头排查，反而浪费大量时间。VPN与本地带宽：调整前需要记录什么，本质上是为后续所有改动留好基准参照线，哪怕调整后出现非预期故障，也能通过对照基准数据快速定位问题点，不用盲目试错。
当前VPN连接的基础链路状态数据
首先要记录的是VPN建立连接之后的原生链路标识信息，不需要借助第三方测速工具，先从系统自带的网络状态面板里提取内容。比如Windows平台的网络属性里可以看到VPN虚拟网卡获取的内网IP地址、分配的DNS服务器地址、当前VPN连接的加密协议类型，还有虚拟网卡的默认网关地址。这些信息不需要做额外解读，原样记录下来即可，避免后续调整配置时不小心改动了虚拟网卡的默认参数，导致VPN服务端判定连接异常。
接下来要记录VPN连接的连通性基准表现，先测试几个日常高频访问的站点，包括需要走VPN链路的境外业务站点，还有只能走本地链路的内网办公服务器、家庭NAS资源，分别记录这些资源在当前配置下能不能正常打开、飞鱼加载有没有明显延迟，不要直接跳去做带宽相关的测试。这个步骤的预期结果，是你能明确区分当前哪些流量走VPN、哪些流量走本地，不会调整之后搞混分流规则的对错，把原本应该走内网的流量导去VPN链路。
调整VPN路由规则或带宽策略前，先从系统自带网络面板提取记录原生链路标识信息
本地带宽的基线运行状态数据
很多人调整带宽之前只测一次下载速度，这是完全不够的，你需要先断开VPN，单独记录本地裸链路的运行状态。这里要记录的内容包括本地运营商分配的公网IP段、光猫和路由器的拨号模式、当前有没有其他设备在跑大流量后台任务，比如自动系统更新、云盘同步任务之类的，先把所有非必要后台流量暂停，拿到干净的本地链路基准。如果调整前没有清理后台流量，后续你测出的带宽变化，根本没法判断是调整VPN配置带来的影响，还是其他设备后台占用导致的波动。
之后再重新连上VPN，在不改动任何原有配置的前提下，记录VPN链路承载流量时的本地带宽占用分布，比如哪些进程的流量是走虚拟网卡、哪些还是走物理网卡，系统自带的资源监视器就可以看到对应进程的网络关联网卡信息。这个步骤的预期结果是你能明确原有配置下的带宽分配逻辑，不会调整之后把原本不该占VPN带宽的流量导过去，飞鱼VPN引发整体卡顿，也不会误把本地链路的带宽限制当成VPN本身的链路问题。
现有分流规则与路由表配置快照
这部分是很多用户最容易遗漏的关键数据，调整VPN和带宽之前，一定要把当前系统的全量路由表导出保存，Windows用route print命令、macOS和Linux用netstat -rn命令，把输出的所有路由条目完整存成文本文件，飞鱼VPN不要只截图。截图的内容没法直接检索对照，后续排查时还要手动输入比对，很容易看错路由条目的优先级参数，反而耽误排查进度。
如果你用的VPN客户端自带自定义分流规则，不管是白名单模式还是黑名单模式，都要把所有已经添加的规则条目逐条复制备份，包括对应规则指定的是走VPN通道还是直连本地，不要只记个大概的规则方向。这个步骤的作用是，如果你调整之后出现部分站点无法访问的问题，直接对照备份的路由表和规则，就能快速看出是新增的路由条目冲突，还是分流规则写反了，不用逐条试错排查。
历史故障点的对应状态标记
如果之前你在用这套VPN和本地带宽配置的时候，已经遇到过一些偶发的小问题，比如特定内网IP段访问VPN资源会断连、部分海外站点加载时偶尔跳转到本地链路，这些之前的故障场景，也要在调整前记录下当前的表现状态。哪怕这些故障是偶发的，你也可以记录下当前复现故障的操作路径，方便调整之后对照故障的出现频率有没有变化。
很多用户调整配置本来就是为了解决这些偶发问题，但如果调整之后旧问题没解决反而出了新问题，你可以对照调整前的记录，判断旧故障的表现有没有变化，到底是调整动作本身引发了新问题，还是原本的链路隐患一直存在。避免把原本运营商侧的链路波动问题，误判成自己调整VPN配置引发的故障，做很多无用的改动。
要注意所有这些记录动作，都不要引入第三方不可信的测速工具或者陌生节点测试，避免测试过程本身改变原有网络状态，所有记录的内容只作为你后续调整的参照基准，不代表调整之后一定能获得更好的网络表现，也不能完全规避所有偶发的网络故障，只是把盲目调整的试错成本降到最低。任何单次测试的结果都只能作为参考，不能直接排除所有其他潜在的网络影响因素。
