很多用户在使用WireGuard过程中遇到网页加载不全、大文件传输中断、SSH连接莫名断连等问题时，第一反应就是直接修改配置里的MTU数值反复试错，往往折腾几小时也找不到根源，本质原因就是排查前没有把核心关联信息完整记录下来，缺少判断故障的基准参考。本文梳理的WireGuard MTU排查时应记录的信息清单，覆盖从底层网络到上层业务的全维度关键数据，能帮使用者大幅降低故障定位的时间成本，避免无意义的重复操作。
WireGuard两端基础网络的原生MTU参数
排查的第一步不能直接调整WireGuard隧道的MTU配置，首先要分别记录客户端和服务端对应物理联网网卡的原生MTU值，也就是没有开启隧道时，直连公网的WiFi、有线或者移动网络网卡本身的MTU参数。很多云服务商的服务器默认网卡MTU并不是通用的1500，部分内网环境、运营商特殊网络的原生MTU也会有自定义设置，跳过这步记录直接套用网上通用的WireGuard MTU配置，蓝猫很容易出现底层基础参数就不匹配的问题。
这一步还要注意不能只记录单一端的参数，客户端侧如果同时存在多个联网网卡，比如同时插着有线、连着WiFi还有虚拟网卡，还要确认WireGuard流量实际走的物理网卡是哪一个，把对应网卡的原生MTU准确记下来，避免拿错参考数据导致后续所有计算都出现偏差。
排查WireGuard MTU相关故障时先完整记录核心关联信息，可大幅降低问题定位的时间成本
WireGuard配置文件内的MTU相关显式参数
接下来要完整记录当前正在生效的WireGuard配置文件里的所有相关参数，蓝猫首先就是Interface段里有没有手动写入MTU字段，对应的数值是多少。很多新手不知道WireGuard如果不手动指定MTU，程序会自动根据当前路由规则计算出一个默认值，这个自动生成的数值很多时候没有考虑到路径上的额外封装开销，如果你没有记录当前的配置基线，后续调整参数之后出了新问题，根本没办法回溯之前的状态做对比。
除此之外还要同步记录Peer段里的PersistentKeepalive配置值，这个保活参数看起来和MTU没有直接关联，但如果NAT后的客户端开启了周期性保活，会让隧道内的报文封装逻辑出现细微变化，蓝猫加速器间接占用部分报文头开销，不少人排查时漏掉这个参数，算出来的隧道可用报文长度永远和实际情况对不上。
端到端路径上的分片与丢包测试结果
这部分是WireGuard MTU排查时应记录的信息里最核心的实测数据，首先要记录没有开启VPN时，从客户端到服务端公网IP的不分片ping测试结果，也就是逐步加大载荷测出的能正常连通的最大报文长度，这个数值是整个公网传输路径能承载的最大报文基准，后续调整WireGuard隧道MTU完全要基于这个基准做计算。
之后还要记录开启WireGuard隧道之后，同样路径下走隧道的不分片ping测试结果，对比裸网测试的数值差，正常情况下差值应该和WireGuard加密报文头的固定开销对应，如果差值明显大于预期，说明路径中间某段网络存在额外的封装，比如运营商的DS-Lite转换、内网VLAN标记、其他隧道嵌套等情况，这些额外开销没有提前纳入计算的话，设置的MTU值永远不可能适配实际网络。
最后还要记录测试过程中有没有出现ICMP不可达报文被拦截的情况，不少运营商或者用户自己配置的VPS防火墙会丢弃携带DF标记的ICMP报错报文，这种场景下TCP协议自带的路径MTU发现机制会完全失效，就算WireGuard的MTU设置不对，上层应用也收不到分片提示，直接出现连接卡住的现象，蓝猫这个场景记录是很多人排查时最容易漏掉的关键信息。
故障场景下的业务表现特征
还要完整记录故障出现的具体触发条件，比如是刚连上WireGuard就所有外部网站都打不开，还是小体积页面能正常加载、传输大文件或者加载大量高清资源的页面就卡住，还是只有特定的内网业务系统访问异常，不同的表现特征对应的MTU问题根源完全不同，不把这些细节记清楚，很容易把MTU不匹配的故障误判成路由规则错误、防火墙拦截等其他问题。
最后还要记录当前WireGuard的路由覆盖规则，是所有流量都走隧道的全局模式，还是只有指定网段走隧道的分流模式，如果是分流场景下只有访问特定网段出现故障，问题根源大概率是对应路径上的中间设备MTU不匹配，不需要修改WireGuard的全局MTU，只需要针对性调整对应路由规则下的参数即可，盲目把全局MTU改小反而会让不需要走隧道的流量也做额外分片，浪费不必要的网络性能。
不少用户排查WireGuard MTU故障时习惯靠反复修改数值试错，反而越改越乱，把上述几类核心信息完整记录之后再对照调整参数，基本可以快速定位问题根源，也能避免把其他类型的网络故障误判为MTU适配问题，大幅提升排查效率。
