很多用户遇到VPN连接卡顿、大文件传输断连、网页加载不全的问题时，第一反应就去手动修改MTU数值，但盲目调整反而容易导致全链路网络异常，小火箭共享账号网站甚至本地局域网其他设备的共享连接也出现故障，VPN与MTU设置：调整前需要记录什么，是所有运维人员和普通用户动手修改参数前必须完成的前置步骤，能帮你后续快速定位故障，避免把小问题拖成全网络配置混乱的麻烦。
当前VPN链路的原生默认状态参数
调整MTU前要记录的第一类核心信息，就是没有做任何修改前，VPN客户端、本地网卡、出口网关三层的默认MTU数值，很多用户改之前根本没记原始值，改出问题之后连恢复基准的参照都没有，最后只能靠重置整个网络配置来解决问题。
这里要注意不能只看VPN客户端界面里显示的参数，还要分别在操作系统的网卡配置页，查询物理网卡、虚拟VPN网卡各自的出厂默认MTU，同时登录家庭或者企业的主路由后台，记录WAN口当前的默认MTU，三层参数都记全，后续排查是哪一层的参数不匹配的时候可以直接对应，不用再逐层重新测试。
调整前的全链路连通性基准测试结果
很多人忽略这一步，直接改完MTU之后才发现之前的网络问题根本和MTU无关，反而把原本正常的连接改出故障，所以调整之前必须先记录不同场景下的连通状态，shadowrocket作为后续修改后的对照基准。
调整VPN MTU设置前完整记录VPN客户端、本地网卡、出口网关三层的默认参数，可避免后续配置异常无法快速恢复的问题。
你需要分别记录不连接VPN时，访问公网普通网站、大体积资源站点、企业内部服务的访问状态，再记录连接VPN之后，相同站点的加载表现、是否出现加载不全、大文件传输是否中断、视频会议是否有丢包卡顿的具体现象，把这些内容逐一写下来，后续调整MTU之后做对比，才能判断参数修改到底有没有起到预期作用。
还要额外记录VPN连接不同节点的当前状态，比如你平时常用的几个不同线路的VPN节点，连接每个节点时的初始连通表现，避免后续调整完MTU之后，把节点本身的公网链路波动误判成MTU修改带来的效果，做出错误的参数调整决策。
本地网络环境的关联配置信息
很多用户的网络环境里不止有VPN这一个会修改报文分片的服务，调整MTU之前必须把这些关联配置都记录下来，避免不同服务的参数互相冲突，反而引发新的网络问题。
你需要记录本地是否同时运行了代理工具、流量加密软件、游戏加速器这类同样会修改网络报文封装格式的应用，记录这些应用的当前运行状态和各自的MTU相关配置，避免后续调整VPN的MTU之后，多个软件的分片规则叠加，导致报文被多次拆分，反而加剧网络延迟。
还要记录当前局域网内其他设备的网络使用状态，比如有没有设备正在跑大流量的下载任务、有没有正在进行的实时音视频会议，这些场景本身就容易出现临时的网络波动，把这些场景记录下来，后续测试新的MTU参数的时候，可以选择相同的网络负载环境做对照，得到的结论才具备参考性。
历史故障的对应现象记录
大部分用户想着调整VPN MTU，都是已经遇到了特定的网络故障，调整之前必须把这些故障的具体触发条件完整记录，不要只笼统写“网络卡”这类模糊描述。
你要记录故障是只有连接VPN的时候才出现，还是不连VPN的时候也会偶发，故障是访问特定站点才触发，还是所有网络应用都有异常，故障出现的时候VPN的连接协议是OpenVPN还是IKEv2这类具体的参数，这些信息记录完整之后，哪怕调整MTU之后故障没有解决，你也可以把这些信息提供给VPN服务的技术支持，快速定位真正的故障原因，不用反复重复排查步骤。
很多新手调整VPN MTU的时候总觉得参数越小越不容易丢包，盲目把数值改到远低于合理区间，反而会导致报文封装效率大幅下降，网络实际传输表现反而比调整之前更差，提前把所有前置信息记录完整，你每一次修改都有明确的对照基准，不会出现改完之后不知道哪里出问题、也没法恢复到之前正常状态的窘境。
