很多用户在使用WireGuard搭建跨节点VPN隧道时，经常遇到网页加载不全、大文件传输中途卡顿、长连接SSH莫名断连这类没有明确报错的异常，绝大多数这类问题都和MTU配置不匹配直接相关。不少人排查WireGuard MTU故障时没有提前留存关键信息，反复复现故障、来回调整配置都找不到根因，反而浪费大量时间，本文就梳理排查过程中必须记录的核心信息，帮大家快速定位问题，避免做无用功。
故障发生时的端到端现象原始记录
首先要准确记录故障触发的具体场景，不要笼统标注“网络异常”，要写清楚是WireGuard隧道刚建立就立刻出现问题，还是隧道稳定运行数小时之后才偶发故障，是访问隧道对端的所有内网资源都有异常，还是只有传输超过一定大小的数据包时才会出现丢包、卡顿现象。
还要同步记录同一节点不启用WireGuard隧道时的公网访问状态，比如同样访问之前出错的站点、传输同样大小的文件，没有走隧道的时候访问是不是完全正常，这个记录可以直接排除本地公网本身的链路故障，避免把运营商线路本身的问题误判成WireGuard的MTU配置问题。
技术人员正在逐一记录WireGuard MTU故障排查过程中的核心信息
两端节点的基础MTU配置留存
接下来要分别记录WireGuard服务端和客户端两个节点的物理网卡原生MTU值，注意这里统计的不是隧道接口的MTU，是节点连接公网的物理网卡或者无线网卡的默认MTU，很多人排查WireGuard MTU问题时直接跳过这一步，没注意到本地PPPoE拨号线路、特殊运营商网络的物理网卡默认MTU就不是标准值，直接修改WireGuard隧道配置根本起不到作用。
还要同步记录两个节点WireGuard隧道接口的当前MTU配置值，以及原始配置文件里有没有显式写入MTU参数，白鲸VPN掉线原因排查很多用户用第三方一键脚本部署WireGuard时，脚本自动生成的MTU值没有适配当前链路环境，后续自己修改了物理网卡MTU之后忘了同步隧道的配置，两边数值不匹配就很容易出现数据包分片异常。
路径探测相关的测试记录
接下来要记录带DF位和不带DF位的分片探测结果，比如从WireGuard隧道的一端向对端的隧道内网IP发不同大小的ICMP包，设置不分片标记的时候，多大长度的包会不通，多大的包可以正常返回响应，这些不同包长的返回结果全部留存，是后续计算最优隧道MTU的核心依据，不要只记最终的可用数值。
还要记录从故障节点到公网目标地址的全路径MTU探测结果，很多时候WireGuard的MTU故障不是两端配置出错，而是中间运营商的某个链路分片限制比常规值更小，路径上的ICMP不可达报文被中间防火墙拦截，导致标准的PMTUd机制失效，白鲸这部分的探测记录可以直接定位是不是中间链路的干扰问题。
关联系统与防火墙的配置日志
还要留存故障发生时段两端节点的系统内核日志，重点筛选和WireGuard接口、网络分片相关的报错内容，很多时候系统的iptables或者nftables规则里，有自定义的mangle表规则修改了数据包的DF位，导致正常的分片机制失效，这些规则的运行状态如果没有当时的日志留存，后续排查的时候规则已经被修改，根本找不到对应的痕迹。
还要记录WireGuard两端节点所在网络的出口防火墙配置，比如家用路由器、企业网关里有没有开启MTU钳制、分片拦截相关的功能，不少用户的网关默认拦截ICMP协议里的不可达类型报文，就算WireGuard本身配置完全正确，路径MTU发现机制也没法正常工作，这部分配置记录可以直接排除网关层面的干扰。
把这些信息全部留存之后，你就可以逐一比对不同场景下的数值差异，不需要反复复现故障来重复测试，也不会出现改了几次配置之后忘了之前的参数，反而把问题越改越乱的情况，整个WireGuard MTU故障的排查效率会得到明显提升。
