OpenVPN 报告 MTU 使用不一致：这条警告到底比较了什么

那条警告报告的只是对端选项之间的比较，并不是对两台主机之间路径的测量。人们把它读成「MTU 设错了」，于是不断改数字，直到那行警告消失。这等于把配置比较当成网络测量，往往在让日志变安静的同时把隧道弄得更糟。真正有用的第一步，是先判断你遇到的到底是哪一种问题。

三个条件决定答案：对端比较的是什么、这个值是否属于遗留配置，以及警告之外还存在什么症状。

警告比较的是选项，不是数据包

OpenVPN 对端在握手时交换各自的选项字符串，并在选项一致性检查中加以比较。当一方报告的 link-mtu 或 tun-mtu 与另一方不同时，这条不一致会连同两个值一起被记录下来。这个交换从不会发送一个大包去试探结果，所以警告描述的是配置，而不是容量。隧道可能承载满尺寸流量却照样打印这条警告，也可能在大包上失败而什么都不打印。

把完整警告连同本地值和远端值一起保留下来。证据是这一对值，而不是你记住的那个单一数字。

link-mtu 为什么被弃用

OpenVPN 2.6 把 link-mtu 标为弃用，因为可变头部和协商出的加密算法让固定的链路值不再可靠。该选项假定了一种协议已不再保证的包结构，所以一个写着字面 link-mtu 的旧配置，描述的是当前代码无法满足的意图。把这个数字复制进新配置，等于扩散一个过时的假设。应当把它当作旧配置历史的一部分来读，而不是当作建议。

一致性检查里还有一个与 tun-mtu 绑定的可选 OCC 值，它改变的是比较的内容，而不是网络承载的内容。设置它并不会让更大的包变得能通过。

先修好配置，再测试路径

通过配置的负责人去修正非预期的差异，并记住服务端的改动会影响每一个客户端。要编辑实例实际加载的那份配置，而不是下载文件夹里的导出文件。然后重连一个测试客户端，记下哪条警告仍然存在。如果消息只是换了形状而没有消失，那你比较的选项和你以为的不一样。

共享服务器在改动全局值之前，需要先核对客户端清单，因为适合一个站点的值可能会毁掉另一个。

然后测试你真正遇到的症状

如果大流量传输卡住而小请求正常，就对着受控目标测量数据包大小。一个设置「不分片」位并逐步加大载荷的探测，比一个只是能通的 ping 可靠得多地找到路径可用的 MTU。把出问题的应用也纳入测试：ICMP 超时可能反映的是过滤，而一个小的成功 ping 对满尺寸的应用数据包什么也说明不了。

mssfix 限制的是隧道内 TCP 会话所通告的 MSS，它对 TCP 有帮助，对内层 UDP 工作负载毫无作用。分片与卸载设置各有自己的兼容条件。针对已经证实的问题选择一种机制，而不是一次改好几项只为让某行日志安静下来。

把实际生效值连同结果留住

把原始值和修正后的实际生效值，连同一次真实传输的结果一起记录下来。正是这种配对，把过时的配置选项与独立存在的路径 MTU 问题区分开来。没有它，下一个读者只会看到警告消失了，便以为网络发生了变化。

压制一致性检查并不能调和任何东西。它只是移除了观测，让两份配置维持原样。