MTU 1420：为什么有些网站会卡住以及如何修复

MTU 是网络中可以不经分片发送的最大数据包大小。以太网上的常见值是 1500 字节。当流量经过隧道时，隧道自身的头部会占用一部分空间，留给有效载荷的空间就更少：典型值是 1420。

这本身不是问题。问题出现在一方认为自己可以发送 1500，但路径上存在一段 1420 的链路，而关于这一点的通知消息丢失了。

症状表现

• SSH 能连接，问候语能收到，但在大目录中执行 ls 会让会话卡住。
• 页面开始加载，加载到一半就卡住。
• curl -I（只请求头部）正常，但完整的 curl 会卡住。
• apt update 成功，apt upgrade 在下载时停滞。
• 小请求畅通无阻，大响应永远收不到。

共同的迹象是一样的：小数据包能通过，大数据包无声无息地消失。连接不会断开，只是陷入沉默。

原因在于，数据包大小协商机制依赖 ICMP 服务消息。如果路径上有东西过滤了这些消息，发送方就永远不知道数据包过大，于是一遍又一遍地重发。

检查

发送一个设置了“不分片”位的数据包，并不断减小大小，直到它能通过：

ping -M do -s 1472 -c 2 1.1.1.1
ping -M do -s 1392 -c 2 1.1.1.1

-s 指定的大小会加上 28 字节的头部：1472 对应 MTU 1500，1392 对应 MTU 1420。如果第一个选项失败而第二个成功，您就找到了限制值。

当前接口的值：

ip link show
ip route get 1.1.1.1

如何修复

一次性检查：

ip link set dev eth0 mtu 1420

永久生效，通过 systemd-networkd —— 文件 /etc/systemd/network/10-eth0.network：

[Match]
Name=eth0

[Link]
MTUBytes=1420

systemctl restart systemd-networkd

如果网络由 NetworkManager 管理：

nmcli connection modify "System eth0" 802-3-ethernet.mtu 1420
nmcli connection up "System eth0"

第二种方法，在您无法改动 MTU 时很有用，就是在边界处钳制 TCP 段大小。在 nftables 中：

tcp flags syn tcp option maxseg size set rt mtu

什么时候会影响您

在 Millida VDS 机器本身上，网络配置是正确的，您通常不需要手动改动 MTU。只有在您自己搭建隧道时才需要处理它：WireGuard、OpenVPN、GRE、到办公室的 VPN，或机器之间的链路。在隧道内部，MTU 总是更小，您需要显式设置它。

对于 WireGuard，在 [Interface] 部分中：

MTU = 1420

常见错误

在您用 ping -M do 命令复现症状之前，不要改动 MTU。没有这一步检查，您就是在凭猜测改动一个正常工作的配置——结果旧问题没解决，反而带来新问题。不要完全屏蔽 ICMP；参见 nftables。