不少用户不管是家用VPN优化跨网访问体验，还是企业IT管理员调整专线带宽搭配VPN办公链路，经常跳过前置记录步骤直接改配置，最后出现VPN断连、业务访问异常、带宽扩容后速率没提升的问题，根本找不到回溯对比的参考依据。VPN与本地带宽调整前需要记录什么，本质上是给后续所有操作留好可对照的基准线，避免调整后的异常无法溯源，把小问题拖成影响正常使用的故障。
IT管理员在调整VPN与本地带宽前，逐项记录当前链路的各项基准连接参数
当前VPN链路的基础连接参数
首先要记录当前使用的VPN客户端或者硬件网关的原生配置，明确正在使用的是IPsec、OpenVPN还是SSL VPN的协议类型，除了常规的服务端接入点域名之外，还要把当前本地DNS解析出来的接入点实际IP同步记录下来，很多用户调整本地带宽之后运营商DNS地址发生变更，原有VPN域名的解析结果出现偏差，直接导致无法连接到之前的合法接入点。
其次要留存VPN隧道的协商参数，proton vpn包括当前启用的加密套件、是否开启了TCP MSS钳制功能、隧道允许的最大传输单元数值，这些参数和本地带宽对应的MTU配置是强绑定的，如果调整带宽之后修改了本地网络的MTU数值，没有同步匹配隧道参数，很容易出现大文件传输卡顿、部分网页加载不全、大体积数据包直接丢包的隐形问题。
本地网络的基准带宽实测数据
这里的实测需要分两个场景分别记录，首先完全断开VPN连接，直接让本地设备连入运营商公网线路，选择常用的测速节点多次测试，记录下载、上传的实际可达速率，同时标注测试同一时间点的内网在线设备数量、后台正在运行的流量任务，比如有没有云盘自动同步、系统补丁更新这类隐性占带宽的进程在运行，避免后续测速结果偏差找不到原因。
再保持VPN正常连通的状态，在完全一致的测试环境下跑同样的测速节点，记录VPN隧道叠加之后的上下行速率，同时记录这个时段VPN客户端或者VPN网关的CPU、内存占用率，要是后续调整带宽之后VPN的资源占用率出现异常飙升，就可以对照这次留存的基准数据，快速定位是不是新带宽的流量规模和VPN原有调度规则出现了冲突。
现有业务的网络连通基线
对于需要用VPN承载办公业务的企业场景，要提前记录所有需要走VPN隧道访问的业务地址的连通状态，比如内网OA服务器的私网IP、共享文件服务器的地址、各类业务系统的服务端口连通性，用ping或者端口探测工具确认连通正常之后把结果截图留存，等调整完带宽之后如果业务访问失败，就能快速区分是带宽调整带来的问题，还是VPN配置本身被误改导致的故障。
还要导出并记录本地网络的当前路由表，尤其是VPN服务端推送的特殊路由条目，明确哪些网段的流量是强制走VPN隧道、哪些网段是分流直接走本地公网，很多管理员调整带宽的时候顺手修改了本地路由器的路由规则，把原本要分流的公网流量全部导入VPN隧道，直接把承载能力有限的VPN链路完全堵死，提前留存完整路由表就能快速对比出异常的新增路由条目。
故障定位的前置参考信息
要提前记录调整前72小时内本地网络和VPN链路出现过的所有已知异常现象，protonvpn比如有没有偶发的VPN断连、部分公网网站访问异常、跨地域业务访问延迟偏高的情况，这些原本就存在的隐性小问题，很容易在调整带宽之后被当成是新操作导致的故障，提前做好标注就能排除后续的误判，不用把时间浪费在排查原本就存在的问题上。
还要记录本地网络核心设备的当前配置状态，比如家用场景下的主路由器、企业场景下的VPN网关的固件版本、WAN口的拨号模式、是否开启了旧的QoS流量限制规则，很多用户调整带宽完成之后，忘记之前设置的旧限速规则还在生效，导致新扩容的带宽完全发挥不出标称的速率，提前把这些配置页面截图留存，调整完成之后对照就能快速找到问题根源。
所有这些记录的信息，建议同时用本地离线文档和本地截图两种方式留存，不要只把记录文件存在必须连通VPN才能访问的内网云盘里，不然调整过程中VPN意外断连，你连自己之前存的基准记录都调不出来，反而会耽误故障排查的进度。
