ping 探测 MTU 是什么
MTU 是单个数据帧能承载的最大 IP 包长度，以太网默认 1500。路径上存在隧道、PPPoE、VPN 时中间链路可用 MTU 会更小，而中间设备又常把「需要分片」的 ICMP 报文丢掉，于是出现典型的 MTU 黑洞：小包（ping、DNS）一切正常，大包（HTTPS 握手、文件上传）卡死或超时。ping -M do 的原理是不允许内核分片，直接发指定大小的包：能通说明链路支持这个尺寸，报 Message too long 说明超了。
基本信息
| 适用平台 | Linux（iputils ping）、macOS（-D）、Windows（-f -l） |
|---|---|
| 语法 | ping -M do -s 载荷大小 目标（IPv4） |
| 换算关系 | 可用的路径 MTU = -s 值 + 28（20 字节 IP 头加 8 字节 ICMP 头） |
| 常见 MTU | 以太网 1500，PPPoE 1492，WireGuard 1420，IPSec 常见 1400 附近 |
| IPv6 | ping -6 走 PMTUD，不能照搬 -M do 的结论 |
| 前提 | 目标需允许 ICMP echo，否则要改用 TCP 探测 |
典型使用场景
- 迁移后小页面能打开、大文件传一半卡住，怀疑 MTU 黑洞时定位链路可用值。
- 新上隧道或 VPN 后验证两端实际可用 MTU，据此确定接口 MTU 与 MSS 钳制值。
- 跨运营商专线验收，确认路径上没有隐藏的小 MTU 环节。
- 排查「能拿到响应头但下载中断」这类疑似分片导致的连接异常。
- 给新建隧道设备确定接口 MTU 配置，避免上线后出现大包不通。
探测流程
探测流程
ping -M do -s 1472 -c 2 8.8.8.8 # 1472 + 28 = 1500，验证标准以太网 MTU
ping -M do -s 1400 -c 2 10.1.1.5 # 隧道环境常用起点
ping -M do -s 1420 -c 2 10.8.0.1 # WireGuard 默认 MTU 对应的载荷
for s in 1472 1400 1350 1300 1200; do # 逐步缩小，找到还能通的尺寸
ping -c1 -W1 -M do -s $s 10.1.1.5 >/dev/null 2>&1 && echo "可用 $s" && break
done
ping -M do -s 1473 -c1 8.8.8.8 # 故意超一点，应报 Message too long
ip link show eth0 | grep mtu # 查看本机接口 MTU 基准值选项与结果读法
| 选项或输出 | 含义 | 判断要点 |
|---|---|---|
| -M do | 禁止分片 | 不加这个参数内核会自动分片，探测无效 |
| -s N | ICMP 载荷大小 | 不是整包大小，别直接写 1500 |
| -c N | 发送次数 | 探测 2 到 3 次足够，避免误判抖动 |
| -W N | 超时秒数 | 跨地域放宽到 3 到 5 秒，太短会把慢链路判成不通 |
| Message too long | 包超过链路 MTU | 说明可用上限在这条路径更低 |
| 100% packet loss | 全部丢失 | 可能被策略丢 ICMP，需用 TCP 方式交叉验证 |
-M do 只适用于 IPv4：IPv6 的路径 MTU 发现机制不同，不能把结论直接套用。macOS 对应参数是 -D，Windows 用 -f 配合 -l，写跨平台探测脚本时要分别处理。
云环境和部分运营商对 ICMP 做限速甚至直接丢弃，ping 不通不等于 TCP 不通。此时改用 tcping 类工具，或借 curl 传输较大数据量观察是否中断来侧面判断。
实测出可用 MTU 只是定位问题，真正的修复通常落在两处：隧道两端接口的 MTU 配置，以及防火墙或路由器上的 TCP MSS 钳制。只调客户端 MTU 往往治标不治本。