很多运维和个人用户部署WireGuard实现远程接入或者站点间内网打通时，经常遇到网页加载半截断、大文件传输无响应、SSH长连接莫名卡顿这类没有明确报错的隐性故障，绝大多数场景下这类问题的根源都指向MTU适配异常。如果排查过程中没有系统性留存关键信息，很容易陷入反复修改配置重启服务却找不到根因的死循环，本文梳理WireGuard MTU排查时必须记录的核心信息维度，帮你快速缩小故障定位范围。
运维人员实测公网原生链路MTU，留存故障排查核心数据
基础网络链路的原生MTU实测记录
首先要记录的不是WireGuard配置文件里预设的MTU数值，而是VPN两端公网出口的原生链路MTU实测值，这里的原生指的是完全关闭WireGuard服务的前提下，两端设备直接通过公网互传指定大小的禁分片ICMP包得到的结果，不能直接套用运营商公示的默认MTU数值。
记录的时候要标注测试使用的目标地址，必须是WireGuard对端的公网IP，不能随便选择第三方公网站点作为测试目标，同时要把测试用到的完整命令参数也留存，比如Linux下ping命令加-M do参数的完整语句，Windows下ping加-f参数的对应写法，避免后续复盘的时候怀疑测试方法本身存在偏差。
WireGuard接口的三层配置全量快照
接下来要记录WireGuard运行时的接口实际生效配置，不是你本地存储的wg0.conf静态文件内容，因为很多场景下配置文件修改后没有执行wg-quick reload操作，小黄鸭内核网络栈里实际生效的参数和文件里写的内容并不一致。
这部分的记录项要包含wg show命令输出的所有内容，比如当前接口实际加载的MTU值、对端端点的IP和端口、最新的握手时间、累计传输的字节计数，同时还要把ip addr show wg0的输出也一并留存，确认WireGuard接口本身的IP地址、路由子网没有和本地其他物理网卡的路由段产生冲突。
很多新手排查的时候只会核对配置文件里的MTU行，忽略了系统里预装的NetworkManager或者其他网络管理服务，自动给WireGuard接口下发了额外的MTU参数，导致实际生效值比预期小很多，这类隐蔽问题只有留存运行时快照才能通过比对快速发现。
端到端分片行为的路径探测记录
这部分记录要涵盖从WireGuard客户端内网设备出发，穿过VPN隧道访问对端内网服务的完整路径的分片情况，不能只测试两端WireGuard公网接口的链路状态。你可以在客户端内网的普通办公电脑上，梯子访问对端内网的文件共享服务，用不同大小的禁分片数据包做分层测试，记录每一个包的返回结果。
还要同时记录路径上各跳设备的ICMP不可达报文返回情况，用mtr或者traceroute --mtu这类工具做路径MTU发现探测，把完整的探测结果保存下来，排查是否有中间运营商的防火墙拦截了ICMP need to fragment报文，导致路径MTU发现机制完全失效。这类场景下就算WireGuard本身的MTU配置完全正确，上层大流量数据包也会静默丢包，不会生成任何明确的系统报错。
典型故障场景的复现操作日志
最后要记录故障发生时的完整操作上下文，比如用户反馈网页加载不全的时候，具体访问的业务域名是什么，这个域名的流量策略是走WireGuard隧道还是走本地公网出口，同一时间点其他走隧道的小流量业务比如即时通讯消息、SSH命令行能不能正常收发。
还要留存故障发生前后的系统内核日志片段，过滤关键词包含wireguard、mtu、icmp、fragment的相关日志行，确认故障出现的时间点有没有WireGuard服务自动重连、接口MTU被系统临时修改的异常事件。很多时候运维会把所有网络异常都归因为WireGuard MTU问题，实际上部分故障是内网交换机的VLAN子接口MTU配置不匹配导致的，通过复现日志的流量走向记录就能快速排除这类无关因素。
所有这些记录整理完成之后，你就可以把不同维度的数值做交叉比对，比如原生公网MTU减去WireGuard封装开销之后的理论值，和实际接口配置的MTU、路径探测得到的实际最大传输值做匹配，很快就能定位是配置写错了、中间链路拦截了ICMP、还是内网侧的三层设备MTU不兼容的问题，不用反复调整参数做无意义的试错。
