谁来选定 WireGuard 的 MTU：wg-quick、内核还是你

WireGuard 没有 MTU 协商。它把接口交给它的数据原样加密后发出去，如果封装后的报文超出路径，就会在你无法察觉的地方被丢弃或分片。总得有人选定接口的 MTU，而那个人就是把接口拉起来的工具。

有三个候选者，而且很容易混淆。

取值可能来自的三个地方

该值可以显式写在接口配置里，可以由配置工具根据路由信息计算，也可以由拥有该接口的任意网络管理器设定。单用 wg 命令以上都不做，因为 wg 只负责密钥和对端。MTU 位于网络接口上，所以 ip link show wg0 才是读取它的地方。

如果不确定属于哪种情况，先读 MTU，再查清是谁启动了该接口。

按谁在管理接口来定

若由 wg-quick 启动，显式的 MTU 行优先，否则它会算出一个值。若由网络管理器启动，就由该管理器的配置决定。若由容器运行时或服务商客户端启动，请读它们的文档，而不是套用 wg-quick 的行为。

要决定的不是抽象上哪个数值最好。而是你实际上能配置哪个组件。

默认计算做了什么

wg-quick 查找通往对端端点的路由，取该出接口的 MTU，再减去封装开销。外层是 IPv4 时约 60 字节，是 IPv6 时约 80 字节。结果会被压上限，使 1500 字节的路径得到 1420，而不是一个只在单一地址族可用的值。这是合理的默认值，不是对你路径的实测。

它无法得知后续的隧道、移动链路，或被过滤的 ICMP 路径。

这个上限掩盖了一个真问题。如果你的路径端到端确实是 9000 字节，1420 就把性能留在了桌上；如果路径是 1400，1420 已经太大。默认值是折中，就该按折中对待。

当路径在你脚下变化

一台从以太网漫游到 Wi-Fi 再到手机热点的笔记本，会保留启动时的接口 MTU。外层路径如今可能更小，却没有任何东西重新协商。嵌套隧道会让情况更糟，因为每一层都从同一预算里扣除自己的开销。在办公室好用的值，不是机场好用的值。

最近一次握手能证明密钥有效。它完全不能证明大报文能否通过。

一次只测一个数值

保持同一个应用和目的地，只改一个值然后测量。ping -M do -s 1372 会测试一个带 DF 位的 1400 字节报文，这正是你想要的测试形态。如果小请求能通、大请求卡住，那是尺寸问题，不是路由问题。

只改 MTU。同时调整多个报文选项，无法告诉你哪一个起了作用。

也别指望改 MTU 能修好缺失的返回路由、转发规则或 DNS 故障。它们同样会表现为没有流量，而且各有各的测试方法。wg-quick 手册记录了这一自动选择。