ping小包通大包丢？路径MTU黑洞的定位与拆弹

有一种网络故障特别折磨人：网页打不开图片、远程桌面连上一会儿就卡死、文件传到一半停住，但 ping 一切正常。工程师到场，ping 网关通、ping 外网也通，看起来"网络没问题"，可业务就是时好时坏。如果你遇到过这种"小包通、大包丢"的怪象，八成是撞上了路径 MTU 黑洞。这篇文章把它的原理、定位和拆弹方法一次讲透。

先讲原理：为什么小包能过大包会死

以太网标准一帧最多装 1500 字节载荷，这就是默认 MTU。当数据包比路径上某一段允许的 MTU 大时，正常情况下路由器会发回"分片需要"（ICMP Frag Needed）提示，发送方就会把包改小重来。问题在于：很多网络为了安全把这个 ICMP 提示也拦了，或者中间有一段隧道（VPN、PPPoE 拨号）额外加了封装头，却没把两端 MTU 相应调小。结果是——提示回不去、包也过不去，数据包就在那个"窄门"前无声消失，TCP 连接表现为握手能成（小包）、传数据卡死（大包）。这就是黑洞：包进去了，没有然后。

两类高频场景：一是 PPPoE 宽带环境，封装开销吃掉 8 字节，标准 1500 的包过不去，实际可用只有 1492；二是 VPN/隧道环境，GRE、IPSec、L2TP 各种封装吃掉几十到上百字节，两端没配 MTU/以小节余量，就出现"内网传小文件行、大文件断"的经典症状。

再讲定位：一条命令把黑洞找出来

定位工具就藏在 ping 里——关键是别用默认参数，要手工控制包大小并禁止分片。Windows 下：ping 目标 -f -l 1472。-f 是"不许分片"（DF 位），-l 是包的载荷大小，1472 加上 28 字节的 IP+ICMP 头正好 1500。从 1472 开始测，通就说明这段路能扛标准以太网满包；不通就往下减：1462、1452……测出能通的最大值，加上 28 就是这条路径的真实可用 MTU。比如测到 1452 才通，路径 MTU 就是 1480——比 1500 少的 20 字节，多半就是某段隧道封装在作祟。再配合 tracert 看丢包从哪一跳开始，黑洞的位置基本就能画出来了。这个测试从两端各做一次更有说服力：路径 MTU 取的是两端测得的最小值。

最后拆弹：三个修法按优先级上

第一修法，治本：在隧道两端显式配置 MTU/TCP MSS 钳制。路由器、防火墙的隧道口把 MTU 设成实测值，同时把 TCP MSS 钳制到"MTU 减 40"，让 TCP 握手时直接协商出能过窄门的数据段大小，业务无感修复。第二修法，兜底：在路由器上开启"ICMP 不可达放行+路径 MTU 发现"，把被安全策略误拦的 Frag Needed 提示放出来，让自动协商机制重新工作——很多单位是防火墙一条"拦全部 ICMP"的老规则埋的雷，放行 type 3 code 4 这一条即可。第三修法，规避：实在改不了设备的场景，把应用侧的包尺寸调小（如数据库网络包大小、挂载参数里的 rsize/wsize），属于缓解不是治愈，留作过渡。

修完记得复测：用之前测出的临界包大小再 ping 一轮，通且稳定才算收工；有条件的话用大文件传输验证十分钟不卡断。把路径 MTU 写进网络档案，以后上 VPN、换线路时先核一遍，这个坑就不会再踩第二遍。

网络故障里，“看着通却不干活"的问题最耗人。如果贵司有分支机构互联、VPN 组网或者宽带接入的网络要维护，欢迎找我们：贵州诚鑫致达科技有限公司，专注企业网络建设与运维、华为交换机防火墙部署，把这类疑难故障变成档案里的一页预案。

（本文由贵州诚鑫致达科技有限公司技术团队原创，欢迎交流企业网络运维方案。）

企业存储选型参考｜贵州诚鑫致达

做机架式部署与数据中心扩容，群晖机型参考：RS2423RP+ · RS1221+ · RS822+。需要选型建议或上门评估，搜「诚鑫致达」即可找到我们。