深色模式
MTU 与分片排错
摘要：最经典的诡异故障：「能 ping 通、网页打不开 / SSH 能连但一操作就卡」。多半是 MTU 与不分片（DF）导致大包被悄悄丢弃。本文用
ping -M do -s找到路径 MTU。
适用环境
bash
ip link show | grep mtu # 看各网卡 MTU
# 典型：以太网 1500，VPN/WireGuard 常 1420，PPPoe 14921
2
2
操作步骤
1. 看本机 MTU
bash
ip -br link show1
2. 用不分片的大包探测（核心手段）
bash
# -M do：禁止分片；-s：数据载荷大小（不含 28 字节 IP+ICMP 头）
ping -M do -s 1472 8.8.8.81
2
2
- 能通：路径 MTU ≥ 1500
message too long/ 超时：包太大被丢，需减小-s
3. 二分找到路径 MTU
bash
ping -M do -s 1400 8.8.8.8 # 通
ping -M do -s 1450 8.8.8.8 # 不通
ping -M do -s 1420 8.8.8.8 # 通 → 路径 MTU≈1452(1420+28)1
2
3
2
3
4. 临时调小网卡 MTU 验证
bash
sudo ip link set dev eth0 mtu 1400
# 复测业务，若立刻好转，说明就是 MTU 问题1
2
2
5. 永久生效（按需）
bash
# 以 NetworkManager / systemd-networkd 为例，改对应配置文件中的 MTUBytes1
验证
bash
# 找到能通的最大 -s 后，加 28 即为路径 MTU
ping -M do -s 1420 8.8.8.8 && echo "路径MTU>=1452"
# 再把网卡 MTU 设到该值，业务大包传输恢复即验证成功1
2
3
2
3
常见坑
WARNING
-s 是载荷字节，加上 28（IP 20 + ICMP 8）才是总包大小。说「MTU 1500」时指总包 1500，对应 ping -s 1472。别把两者混为一谈。
DANGER
不要把 MTU 调得过小「以防万一」——会显著降低吞吐和 CPU 效率。应测出真实路径 MTU 后取最大值。VPN 场景通常设 1420 是安全值。