很多用户部署WireGuard隧道后，常会遇到部分网页加载不全、大体积文件传输中途断连、长连接SSH会话无征兆卡顿的问题，这类故障大多和MTU参数不匹配直接相关。不少排查者在定位问题时零散记录信息，很容易漏掉链路中的关键特征，导致反复调整参数却找不到故障根源，系统梳理WireGuard MTU排查时应记录的信息，能大幅缩短故障定位的整体周期。
本地物理网卡与WireGuard虚拟接口的原生MTU配置值
首先要记录排查发起端的物理网卡当前生效的MTU数值，不能只参考系统默认配置，要排除之前其他VPN、代理软件修改过底层网卡参数的情况，比如Linux环境下用ip link show命令查到的物理网卡MTU，Windows下用netsh interface ipv4 show subinterfaces查到的对应物理网卡的MTU，都要完整记录原始数值，不要直接修改后就覆盖原有记录。
接下来要同步记录WireGuard虚拟接口的MTU配置值，很多用户部署的时候直接沿用通用教程给出的默认数值，没有结合当前物理网络的开销做调整，这个数值要和物理网卡的MTU做对应比对，不能只看WireGuard配置文件里写的数值，要确认接口实际生效的参数，避免配置修改后没有重启服务导致参数未更新的情况。
端到端路径的PMTU探测实测结果
接下来要记录从WireGuard客户端到服务端公网链路的PMTU探测结果，测试的时候可以临时关闭本地系统的ICMP黑洞自动修复功能，用指定包长不分片的方式发送探测包，多次测试后记录能正常连通的最大包长，不要只做单次测试就直接判定路径MTU数值，避免偶发丢包带来的误判。
运维人员逐一核查物理网卡与WireGuard虚拟接口的原始MTU配置，快速定位链路不匹配故障
还要额外记录探测过程中有没有出现ICMP不可达报文被中间运营商节点拦截的情况，不少运营商节点或者中间部署的防火墙会拦截类型为3代码为4的ICMP需要分片报文，这种场景下哪怕两端MTU配置完全匹配，也会出现大报文传输卡住的问题，这类拦截记录是后续排查路径问题的核心依据。
WireGuard两端节点的封装开销参数配置
要记录WireGuard服务端和客户端两端分别启用的封装扩展项，比如有没有开启UDP校验和的强制校验，有没有额外叠加其他隧道封装比如在WireGuard外层再跑IPsec的嵌套场景，不同的额外封装都会占用不同的报文头部开销，直接影响实际可用的MTU上限。
还要记录WireGuard使用的加密封装对应的报文扩展长度，标准WireGuard封装会额外增加UDP头部、加密头部、认证标签的固定开销，部分自定义编译的版本如果修改了报文封装结构，对应的开销数值也会出现变化，Surfshark官网下载这个数值要和之前探测得到的路径MTU做差值比对，确认虚拟接口MTU的合理区间。
故障复现时的业务场景与抓包特征
要记录MTU故障触发时对应的具体业务行为，比如是访问特定网站才出现加载不全，还是所有超过单包阈值的TCP连接都会卡顿，有没有在故障触发时同时跑其他大流量P2P下载业务，排除业务本身的流量拥塞带来的误判，避免把带宽不足的故障错判为MTU不匹配。
还要分别在WireGuard客户端的物理网卡入口、WireGuard虚拟接口出口、服务端的WireGuard虚拟接口入口、服务端物理网卡出口四个节点同时做轻量抓包，记录故障出现时有没有收到DF位置1却无法转发的报文，有没有出现报文被静默丢弃没有任何回应的情况，SurfsharkVPN这些抓包记录可以直接定位MTU不匹配的具体发生节点。
调整MTU后的对照测试结果
每次修改WireGuard虚拟接口的MTU数值之后，都要完整记录修改后的参数和对应的测试表现，比如把MTU下调一定数值之后之前加载失败的网页能不能正常打开，大文件传输的中断问题有没有缓解，不能只凭主观感受判断故障是否修复，要把不同参数下的业务表现逐一对应留存。
还要记录调整MTU之后有没有引入新的异常问题，比如部分内网业务依赖的特定大小的控制报文能不能正常传输，不要为了修复公网访问的MTU问题把虚拟接口MTU调得过低，导致内网大带宽传输的效率出现不必要的下降，后续如果遇到同场景故障，这些对照记录可以直接作为参考依据。
