小页面正常、大文件卡住：怎样排查路径 MTU

小页面能打开，大文件下载或上传却反复卡住，除了带宽、服务端限制，也可以检查路径 MTU。它指某条路径能承载的最大 IP 包大小。包过大、又无法正确获得调整大小的反馈时，可能出现“小请求正常、大传输超时”。这只是候选原因，需要对照验证。

先固定目标和连接条件

选用你有权测试、且普通 Ping 有回应的目标 IPv4，记录时间、出口和是否经过隧道。同一域名可能返回多个地址，比较包大小时固定同一个 IP。下面的 192.0.2.1 仅是文档示例地址，必须换成实际目标。

只改变探测包大小

Windows 在终端运行：
ping /4 /n 4 /f /l 1472 192.0.2.1

Ubuntu 使用 iputils 的 ping：
ping -4 -c 4 -W 2 -M do -s 1472 192.0.2.1

这些选项限制次数、指定 IPv4，并禁止分片。若失败，保持其他条件不变，把 1472 改为 1400、1300 再比较。出现“需要分片”或“消息过长”时保留原文；Linux 也可能依据本机或缓存的路径限制直接拒绝发包，因此不能据此定位到某台远端路由器。

怎样解释大小差异

在普通、无 IP 选项的 IPv4 Echo 探测中，数据部分再加 20 字节 IP 头和 8 字节 ICMP 头，1472 对应 1500 字节 IP 包。隧道等封装还可能有额外开销，不能把这个数直接套进所有设备配置。

大包失败、小包成功，是继续检查 MTU、封装和过滤规则的线索。只有超时、没有明确反馈时，也可能是 ICMP 过滤或限速；全部无回应更不能推导出 MTU。ICMP 和实际业务还可能经过不同处理。

用真实传输确认改善

在另一条网络上复测同一个文件，记录差异。网络管理者再核对出口、隧道 MTU 和必要的 ICMP 反馈是否被阻断；需要试调时先保存原值，一次只改一处，并用原文件复测。FB4 的普通 Ping 和端口成功不能代替上述包大小测试，也不能单独排除这个问题。

参考资料：Microsoft ping 参数 https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/ping
Linux ping 手册 https://man7.org/linux/man-pages/man8/ping.8.html
IETF 路径 MTU 与黑洞问题 https://www.rfc-editor.org/rfc/rfc1191.html https://www.rfc-editor.org/rfc/rfc2923.html