不少使用WireGuard搭建站点互联或者远程接入VPN的用户，都会遇到小体积请求访问正常、大文件传输或大网页加载中途断开的异常，这类故障九成以上和MTU参数不匹配相关，但很多人排查时零散修改参数、没有留存对应信息，反而反复试错找不到根因。这份清单明确了WireGuard MTU故障排查时必须记录的核心信息，帮运维和普通用户快速缩小故障范围，避免无意义的调试操作。
WireGuard接口本身的原生MTU配置参数
首先要记录的就是两端WireGuard配置文件里显式定义的MTU数值，很多用户部署时习惯不填MTU字段，WireGuard的内核模块会自动生成一个估算值，但不同操作系统的默认计算逻辑存在明显差异，Linux服务器端、OpenWrt路由器端、Windows桌面客户端的默认MTU基准值并不统一，很容易出现两端配置不对等的情况。
这里要注意不能只看WireGuard客户端界面显示的运行时MTU，还要进入对应系统的网络接口配置层核对真实数值，比如Linux环境下用ip link show wg0命令查到的MTU值，和配置文件里标注的如果不一致，往往是之前调试留下的临时修改，设备重启后这类临时配置就会失效，记录时要同时标注配置文件里的静态值和当前运行的动态值，避免后续排查出现信息偏差。
底层物理网络接口的MTU与链路PMTU状态
接下来要记录WireGuard外层承载的物理网络接口的MTU数值，比如你用家庭宽带接入WireGuard时，物理网卡的以太网MTU、PPPoE拨号虚拟接口的MTU，这些底层数值都会直接叠加影响WireGuard的可用MTU区间，很多时候故障根因根本不是WireGuard配置错了，而是下层拨号接口的MTU本身就不是标准值。
还要同步记录路径上的PMTU探测状态，排查时可以从WireGuard客户端内网侧，向对端内网的一个存活IP发送不分片的大包测试，记录测试用的包长、连通结果，这个结果能直接反映当前链路里有没有中间节点防火墙拦截ICMP不可达报文，这是很多隐性WireGuard MTU故障的核心诱因，光看本地配置数值根本发现不了。
故障复现对应的业务场景细节
很多人排查MTU故障时只盯着数值，忘了记录故障触发的具体场景，最后改完MTU发现故障还存在，才发现根本不是WireGuard本身的问题。你要记录故障出现时，具体是访问WireGuard对端内网的HTTP服务、还是跨站点传大文件、还是把全部公网流量走WireGuard代理，不同场景对应的故障触发逻辑完全不一样，对应的排查方向也完全不同。
还要记录故障出现时的两端网络位置，比如客户端是连接家用WiFi、还是手机移动网络、还是企业办公内网，不同中间网络的运营商策略、出口防火墙规则都有差异，同样的WireGuard MTU配置在不同网络下表现完全不同，这些场景信息不记录的话，后续做对照测试根本找不到变量，很容易浪费数小时的调试时间。
系统路由与防火墙规则的关联配置
接下来要记录WireGuard运行时的路由表条目，尤其是和WireGuard接口相关的路由对应的MSS钳制配置，很多用户会在iptables或者nftables里添加自定义的MSS调整规则，这些规则如果和WireGuard的MTU数值不匹配，就算界面显示的MTU参数看起来完全合理，TCP大报文还是会被异常截断。
还要记录两端系统的防火墙里有没有针对ICMP报文的拦截规则，不少安全爱好者为了降低攻击面，会把所有类型的ICMP报文全部拦截，直接导致PMTU探测机制完全失效，大报文无法正常传递，这类规则如果没被提前记录，排查的时候很容易把故障原因错归到WireGuard本身的配置问题上，走很多不必要的弯路。
最后要把所有记录的信息整理成结构化的对照清单，每次调整一个MTU参数之后都重新跑一遍大包测试留存结果，不要同时修改多个参数，避免后续无法确认哪项调整真正解决了问题，整个排查过程不需要额外的付费工具，用系统自带的网络命令就能完成所有信息采集，能覆盖绝大多数常见的WireGuard MTU不匹配导致的连接异常问题。
