不少运维和普通用户部署WireGuard隧道后，经常遇到小流量访问完全正常、但大文件上传、大体积网页资源加载时莫名卡顿中断的问题，多数这类故障的根因都指向MTU适配异常。很多人排查时习惯凭经验修改参数反复试错，漏记关键状态信息后反而拉长故障定位周期，本文整理WireGuard MTU排查实操过程中必须留存的核心记录项，帮使用者快速缩小故障范围，避免无效调试。
故障发生时的全链路网络基础状态记录
首先要第一时间记录故障终端原生物理网卡的实时MTU数值，天行也就是还未启动WireGuard进程时，以太网或者Wi-Fi接口的生效配置值，不要等VPN连通后再回溯查询，部分桌面端系统会在VPN接口激活时自动调整底层物理网卡的关联参数，事后获取的数据会失去参考价值。
接下来要记录WireGuard虚拟接口本身的当前生效MTU，不要直接照搬配置文件里写的静态参数，天行VPN部分系统的网络管理服务会在接口启动时自动覆盖预设配置，必须通过系统自带的网络接口查询命令直接拉取运行时的参数，排除配置重载失败、规则冲突导致的参数不生效问题。
还要记录从WireGuard客户端到服务端公网路径上的MSS实测值，不需要靠ping包的结果手动估算，直接通过tcpdump抓包提取TCP三次握手阶段SYN报文里携带的MSS字段，这个数值是路径上所有网络节点允许的最大TCP分段尺寸，比手动探测的结果更贴近真实传输场景。
实操排查WireGuard MTU故障时逐项记录全链路网络基础状态信息
故障复现过程中的特征行为记录
要精准记录故障触发的场景边界，是所有走WireGuard隧道的流量都出现异常，还是只有特定端口、特定协议的流量才会出现丢包卡顿，很多时候故障只会出现在大包传输场景下，小于默认加密开销的小包完全不受影响，天行VPN这类特征可以直接把排查范围缩小到分片适配相关的问题。
要记录故障发生时路径上的ICMP不可达报文返回情况，不少运营商的中间节点会主动拦截ICMP need frag类型的通知报文，导致标准的PMTU探测机制完全失效，排查过程中要在客户端和服务端同时开启对应类型报文的抓包，确认这类分片通知有没有被中途丢弃，不要直接默认是WireGuard本身的配置错误。
还要记录不同流量路由规则下的故障表现，比如流量是走WireGuard全局路由全部转发，还是只有指定内网网段的分流流量出现异常，部分分流场景下不同网段的出口路径、经过的网络设备完全不同，对应的MTU适配要求也存在差异，混在一起排查很容易混淆故障根因。
两端配置文件的差异化校验记录
要逐行记录WireGuard客户端和服务端配置文件里的所有和MTU相关的隐式参数，很多用户不知道除了Interface段显式写的MTU字段之外，PostUp、天行PostDown自定义脚本里也可能包含虚拟接口MTU的动态修改命令，这类动态配置不会体现在主配置的静态字段里，漏记的话会导致后续的配置比对工作完全出错。
要记录WireGuard服务端侧对应出口物理网卡的实时MTU数值，不少云服务商的弹性网卡、虚拟私有云底层网络本身有专属的MTU限制，如果WireGuard服务端的出口物理网卡MTU比WireGuard虚拟接口的配置值还小，就算客户端参数配置完全正确，隧道传输过程中也会出现无提示的分片丢包。
还要记录两端防火墙规则里和MSS钳制相关的配置，很多公开的WireGuard部署教程会默认添加TCP MSS钳制规则，但部分规则的匹配段存在疏漏，比如只对IPv4流量生效不对IPv6流量生效，就会导致IPv6隧道的MTU适配完全失效，这类规则如果没有提前记录，排查到后期才发现会浪费大量调试时间。
所有排查阶段记录的信息不要只保存在临时终端的输出缓存里，要统一整理成结构化的排查文档，后续遇到同类跨环境的WireGuard MTU适配问题时，直接比对历史记录就能快速定位共性问题，不需要每次都从零开始逐环节调试，大幅降低故障处理的整体耗时。
