不少用户在自行调整VPN隧道参数、申请扩容本地带宽之后，反而遇到了VPN连接频繁断连、内网资源无法访问、跨网业务延迟飙升的反常问题，很多时候并非调整操作本身出错，而是调整前没有留存足够的基准参考信息，出问题后找不到对照依据快速回退。很多人在接触VPN与本地带宽：调整前需要记录什么这个问题时，第一反应是测速存结果就足够，实际上需要覆盖配置、运行、排查多个维度的核心信息，才能把调整操作的风险降到最低。
现有VPN连接的基准运行参数
首先要记录的不是瞬时速度数值，而是当前VPN的隧道协议类型、加密套件版本、隧道封装模式，这些底层参数是后续所有调整操作的基础参照，坚果不少用户调整带宽后随意更换VPN协议，忽略了不同运营商线路对不同协议的路由转发策略存在差异，反而会出现体验不升反降的情况。
接下来要记录当前VPN本地侧和远端侧分配的网关地址、DNS服务器规则，以及已经配置好的分流策略，明确哪些本地网段的流量强制走VPN隧道、哪些流量直接走本地公网转发，如果没有提前留存这些规则，调整本地带宽后更换了运营商分配的网关地址，很容易出现内部办公站点无法访问、所有流量都涌入VPN隧道造成整体拥堵的问题。
运维人员逐一核查记录当前VPN与本地网络的基准运行参数，为后续带宽调整操作留存可靠的对照依据。
还要记录当前VPN连接的稳定运行特征，比如常规场景下的连续在线时长，有没有已经发现的隐性触发问题，比如大体积文件传输一段时间后会出现自动断连的现象，这些信息可以帮你后续快速判断，调整后出现的异常是新操作引发的，还是原本就存在的未暴露问题。
本地带宽的实际运行基线数据
这里要注意区分运营商的签约标称带宽和本地网络的实际可用带宽，调整之前先记录本地不启动VPN、空闲状态下的上下行带宽峰值，以及日常时段的平均带宽占用率，不要直接把运营商公示的签约带宽当成基准数值，很多时候本地局域网内的其他设备后台自动更新、云盘同步悄悄占用了带宽，调整VPN之后很容易误判是VPN拖慢了整体网络速度。
还要记录本地网络当前的NAT网关类型、已经配置的端口映射规则、防火墙的出站访问限制，不少家用场景或者小型办公场景部署的VPN服务，对NAT网络的映射规则有特定要求，如果调整带宽时运营商后台把用户网络从公网IP改成了运营商内网NAT，没有提前记录之前的NAT类型作为对照，出问题后很难定位到根源。
另外要记录本地网络下长期在线的固定设备清单，以及这些设备对应的高优先级业务类型，比如有没有24小时运行的实时视频监控、工业数据传输这类对网络稳定性要求极高的业务，这些信息可以帮你后续调整VPN分流规则的时候，主动避开核心业务的流量路径，避免影响正常运行。
故障定位所需的对照参考信息
调整操作执行前，先完成两组基础测试并留存结果：第一组是完全关闭VPN客户端、所有流量直连本地公网时，访问日常使用的远端业务站点的延迟、连通性状态，作为后续排查的第一基准参照。
第二组是正常开启VPN、不改动任何现有配置的前提下，访问相同远端站点的连通性数据，把两组数据对应存档，后续调整完VPN配置或者本地带宽之后，一旦出现异常就可以逐项对比三组数据的差异，快速定位问题出在VPN配置改动环节，还是本地带宽的运营商线路变动环节。
还要手动导出当前VPN客户端或者服务端的完整配置文件，存放到本地非系统存储的位置，不要完全依赖软件自带的自动备份功能，不少调整操作会直接覆盖软件的自动备份文件，出问题后根本找不到原始配置快速回退，反而拉长了故障修复的时间。
容易被忽略的边界规则记录
要提前梳理并记录本地网络的隐私边界规则，坚果加速器手机连接设置明确哪些本地局域网设备的流量是禁止上传到VPN远端的，比如本地部署的私有监控服务器、内部文件共享节点，调整带宽之后很容易因为修改全局路由规则，导致这些敏感设备的流量意外流出本地网络，带来不必要的信息安全风险。
最后还要记录当前VPN服务端的预设并发连接数上限、单通道带宽配额规则，很多用户花成本扩容了本地带宽之后，坚果加速器手机连接设置发现VPN的传输速度始终达不到预期，排查后才发现VPN服务端本身就设置了带宽上限，没有提前记录这些规则的话，很容易做很多无用的调整操作。
