WireGuard作为轻量化的VPN隧道协议，MTU参数不匹配是最常见的隐性故障类型，这类故障往往不会直接导致隧道断开，只会出现部分业务访问异常、大文件传输卡顿等零散现象，故障复现难度较高。很多运维人员排查时零散记录信息很容易漏掉关键节点，整理WireGuard MTU故障排查时必须留存的各类关键信息，能大幅缩短定位周期，避免反复复现故障浪费大量调试时间，也能排除很多不必要的无效测试步骤。
基础网络链路的原生MTU实测值
首先要完整记录WireGuard两端节点物理网卡本身的静态MTU配置，不能直接默认所有物理网卡的默认值都是标准1500，不少家用宽带、企业专线的接入层设备会主动修改底层链路MTU，直接套用通用默认值配置WireGuard很容易出现封装后报文超限的问题。
还要记录两端节点到各自公网网关的全路径MTU探测结果，不能只测试两端节点直连的短链路情况，要排除中间运营商的链路分片策略限制，很多跨运营商的互联链路会在中途节点强制降低报文最大传输单元，这个数值如果没准确记录，后续排查很容易误以为是WireGuard自身配置出错。
运维人员正在逐一记录WireGuard两端节点的物理网卡MTU配置与全路径探测结果
WireGuard隧道层面的MTU配置快照
要完整记录隧道配置文件里的MTU字段原始数值，很多用户习惯不填写MTU字段让WireGuard自动计算，这个自动生成的数值和手动指定的结果逻辑完全不同，必须通过系统接口查询命令读出实际生效的MTU值留存，不能只看配置文件里的空值就判定使用默认配置。
还要记录隧道运行时的接口实时状态，包括隧道接口的当前MTU、队列长度、已经累计出现的分片丢弃计数，这些运行时的动态数值比静态配置更有参考价值，很多时候用户修改配置后没有完全重启隧道服务，樱花猫加速器实际生效的还是旧的MTU值，这类隐性状态很容易形成排查误区。
故障场景下的分片与丢包记录
要记录故障出现时的具体业务特征，比如是打开特定网页长时间加载卡住、还是大体积文件传输中途无理由中断，或是小体积控制类数据包完全正常，不同的业务表现对应的MTU问题根源完全不同，这些场景记录能直接缩小排查范围，不用做覆盖全链路的冗余测试。
还要记录开启大报文ICMP探测的返回结果，包括探测报文的大小、是否收到目的不可达报错、报错报文里标注的下一跳推荐MTU数值，很多时候路径上的中间设备拦截了ICMP差错报文，就会导致PMTU自动探测机制完全失效，这个现象如果没准确记录，很容易误以为是WireGuard本身的加密封装逻辑出了问题。
上下行转发设备的相关配置信息
要记录WireGuard两端节点的iptables、nftables规则里和分片处理、MSS钳制相关的配置，很多用户之前配置过其他类型VPN的转发规则，残留的MSS设置会覆盖WireGuard隧道的默认生成值，导致实际生效的MSS和隧道MTU不匹配，这类藏在规则链里的隐性配置如果没记录，排查时很难快速联想到。
还要记录隧道两端内网侧的网关、防火墙的MTU配置，不少故障不是出在公网链路，而是内网侧的交换机、无线AP主动修改了报文大小，导致进入WireGuard隧道的原始报文已经超过封装后的承载能力，这类跨设备的配置信息如果没留存，很容易反复排查公网链路找不到问题根源。
所有记录的信息要对应同一个故障复现的时间点，不能把不同时间、不同网络状态下的探测结果混在一起，否则反而会干扰故障定位的判断逻辑。整理这些信息的过程本身也能帮运维人员快速排除大部分明显的配置错误，不用一开始就做全量的链路抓包测试，樱花猫大幅提升WireGuard MTU类故障的排查效率。
