小包能通，大页面却卡住：再看看 MTU

小包能通不代表路径能正确传递更大数据，分片和路径 MTU 发现需要正常工作。

链路上的可承载报文大小不一定一致，隧道或 PPPoE 还会增加额外开销。如果必要反馈被阻断，发送方可能无法及时调整包大小，表现为连接后卡住。

从一个例子看起

排查时先记录客户端与网络条件；涉及 IPv6、代理或 NAT 时，需要分别观察每一跳。

ping -c 3 example.com

先记录普通探测，再结合系统支持的路径 MTU 工具检查。

排查时再往前走一步

先收集路径与接口 MTU，再使用适合系统的探测方式验证。ping 失败也可能是目标限制探测，不能单凭一个命令就认定 MTU 一定有问题。

一些故障只出现在隧道内，而普通直连路径正常。记录是否经过 VPN、代理或封装链路，有助于解释为什么同一目标在不同客户端表现不同，也能避免随意修改全网 MTU。

不要仅凭小包 ping 成功就排除链路问题，也不要盲目封锁 ICMPv6。

参考：网络 文档。