在WireGuard VPN的日常部署运维中，MTU参数不匹配引发的隐性故障占比非常高，这类故障很少出现隧道完全断开的极端情况，大多表现为小流量交互完全正常、大体积报文直接丢包，比如网页部分资源加载卡住、大文件传输中途中断、长连接会话无征兆断开。很多运维排查这类故障时习惯边试边改，没有同步留存关键信息，很容易反复走弯路，这份清单梳理了WireGuard MTU排查时应记录的信息全集合，帮你快速缩小故障范围，避免无意义的重复测试。
故障发生时的端到端现象原始记录
排查的第一步首先要留存未经任何加工的故障原始现象，猎豹不能只笼统记录“隧道用不了”，要明确标注异常触发的时间点：是WireGuard隧道刚完成握手建立就立刻出现异常，还是隧道稳定运行数小时之后才随机出现连通问题，异常是所有跨隧道访问全部失效，还是仅特定场景下的大流量传输出现问题。
运维人员逐一记录WireGuard MTU故障排查的关键信息，避免无意义的重复测试走弯路
还要同步记录两端的上层业务具体表现，比如客户端侧是打开部分HTTPS网页卡在加载状态、还是SSH的大交互会话随机断连，服务端侧是跨隧道访问内网共享存储出现传输中断，还是指定大小的ICMP探测包直接丢包，猎豹加速器版本选择这些原始现象不需要提前做技术判断，原样留存就能完全排除后续排查时的记忆偏差，避免把其他类型故障误判为MTU不匹配问题。
两端WireGuard基础配置的原始取值记录
接下来要完整记录隧道接口本身的MTU配置取值，注意不能只读取系统运行时自动生成的接口参数，要确认WireGuard配置文件里显式指定的MTU项，很多运维习惯不手动设置MTU，让WireGuard自动从底层物理接口继承参数，这个自动继承的非显式配置数值也必须原样记录，不能直接默认取值符合预期。
还要同步记录两端WireGuard节点的监听端口、已配置的对等端公钥、预共享密钥启用状态，以及系统路由表中所有指向WireGuard隧道接口的明细路由，部分场景下路由叠加、策略路由优先级异常导致的数据包分片逻辑错误，表现和MTU不匹配高度相似，留存完整的原始配置可以快速排除这类容易混淆的干扰项。
物理链路层的路径MTU相关实测记录
随后要记录WireGuard两端物理出口接口的原生MTU数值，包括客户端侧当前在用的WiFi/有线网卡的MTU参数、服务端侧公网网卡的原生MTU参数，还要同步记录两端物理链路上是否存在PPPoE拨号、VLAN标签、其他三层VPN叠加的情况，猎豹这类额外封装都会占用报文的头部开销，直接压缩WireGuard隧道的可用MTU上限。
接下来要记录双向的大包探测测试结果，分别测试不设置DF位的大包跨隧道传输状态，以及设置DF位的不同大小报文跨隧道传输的连通状态，测试时要分别从客户端向服务端内网地址、服务端向客户端内网地址双向发起，猎豹不能只做单向测试，部分运营商路径不对称的场景下，双向的可用MTU阈值并不完全一致。
中间路径的分片策略相关记录
还要记录跨隧道传输时的ICMP不可达报文拦截状态，确认两端的防火墙规则有没有拦截类型为“需要分片且DF位置1”的ICMP报文，PMTUd路径探测机制失效是WireGuard MTU类故障的最常见诱因，很多运维出于安全考虑刻意全量拦截ICMP报文，反而会直接引发这类隐性的大流量不通问题。
最后要记录路径中间是否存在运营商层面的特殊报文处理策略，部分运营商会对超过特定大小的报文直接丢弃而不返回任何ICMP通知，这类场景下常规的PMTU探测完全失效，必须逐次降低WireGuard隧道MTU做对照测试，每一次调整后的连通状态都要逐一记录，方便后续定位整条路径的真实最大传输单元。
所有WireGuard MTU排查时应记录的信息要统一归档留存，后续遇到同类故障时可以直接对照历史记录快速定位，不需要重复做全量探测。排查过程中不要随意调整其他无关的防火墙规则或者路由配置，避免引入新的变量干扰根因定位，确保所有测试结果的参考价值不受额外改动的影响。
