在不猜数值的前提下排查可疑的 VPN MTU 问题

把一串互联网 MTU 值逐个试到感觉更快为止，这不是测试，而是没有停止规则的搜索。有效的做法只改变一个受控的尺寸条件，并把结果与同一条路径对比。从一个可重复、无害的失败出发，并保留能让你撤销实验的可用配置。下文全部以这条纪律为前提，因为没有它，你最后只剩下一个无法辩护的数字。

改数字之前先固定路径

在动任何设置之前，先写下设备、接入链路、隧道协议、端点、目的地和地址族。这六项事实就是路径，而针对另一条路径的探测测的是另一个问题。它们也让结果可复现，而这正是测试与瞎折腾一下午的区别。把记录放在终端旁边，而不是记在脑子里。

从你有权限执行的最窄测试开始。服务端的改动会波及该端点的每一位用户，所以它属于排查的结尾，而不是开头。

在 Linux 上探测形如 ping -M do -s 1400 host，在 Windows 上形如 ping -f -l 1400 host。两种情况下你设置的都是载荷而不是包大小，因为 IP 和 ICMP 头会加在上面。

读你面前这套系统的文档，而不是从论坛帖子里抄一个开关。选一个你自己控制的目的是地，这样没有回应才是信号而不是谜团。把确切的命令和确切的尺寸记在与路径同一条笔记里。没有尺寸的结果只是轶事。若一次运行里改了两件事，你就不知道是哪一件带来了结果。

被丢弃的探测可能意味着 ICMP 过滤，而不是尺寸上限，而这个错误会让人去调一个从来不是问题的数值。在改动任何东西之前，把探测与真实应用对比，并与尺寸相关的报错或一次限定范围的抓包对比。成功的小 ping 同样证明不了什么，因为它们可能安稳地待在限额之下。在配置发生变动之前，至少要有两次独立观测。

如果探测成功而应用失败，你就有证据表明这条路径上不是简单的尺寸上限。把它写下来，因为它直接排除了一整支候选改动。

改动客户端为这个协议所记录的那项设置，并让端点和目的地保持原样，否则你就同时改了两件事。TCP 的 MSS 钳制并不覆盖所有 UDP 负载，所以一个开始能用的浏览器可能让隧道协议照旧坏着。IPv4 与 IPv6 在这里是两条独立路径，因为在任何路由发生之前，报文头就已经不同了。

如果两种地址族都发布，就都测一遍，因为来自其中一种的结果对另一种什么也说明不了。今晚在这条路径上奏效的数值只是一个数据点，不是整个 VPN 的 MTU。不要凭一次成功传输就把它提升为全局设置。把这个数值写下来，并注明它来自哪条路径。

如果对比不支持假设，就把原始数值放回去。检查网络管理器有没有在别处保存了持久覆盖，因为实验正是这样变成策略的。重新连接，并试用普通应用，而不只是你正在测的那一个。然后记录症状、实际生效的路径、旧值与新值，以及结果的可重复程度。

在任何人扩大改动范围之前，把这份记录与变更申请放在一起。路径 MTU 发现机制在 RFC 1191 中说明了为什么较小的数值能救活一条路径却对另一条毫无作用，而一串数字并不能替代那个模型。当你能说出路径、尺寸、观测以及你恢复的数值时，测试才算结束。