小网页能开，大页面卡住：认识代理链路的MTU

摘要：解释MTU、路径MTU和大包传输停滞的关系，并给出保留现场、逐项对照的排查思路。

代理已经连接，简单页面可以打开，图片或较长响应却一直等待。这类现象除了拥塞、站点故障，也值得检查数据包大小。MTU是链路能够承载的最大传输单元，通常以字节表示；它限制的是网络包，而不是整张网页的文件大小。

路径MTU取决于沿途链路中最小的MTU，并非只看电脑网卡的设置。假设两段链路分别允许1500和1400字节，路径就不能按1500字节的容量来理解。这个数字例子只用于说明关系，并非任何节点的测量结果。路径MTU定义解释了这一点。

IP隧道还会增加外层封装，占用包大小的空间；多层封装需要继续计算开销。但普通应用代理与IP隧道并不相同，不能对所有翻墙协议套用同一个减法，也不能照搬别人客户端的MTU值。隧道说明讨论的是具体封装路径上的限制。

路径MTU发现用于帮助发送端调整包大小。IPv6链路上的“包太大”消息若无法到达发送端，就可能出现连接建立成功、传输数据却停滞的情况。IPv6规范说明了这种风险。TCP中的类似问题也可能表现为小包成功，大包反复重传，最终超时。TCP案例可作原理参考。

不过，大页面包含多个请求，也可能卡在某个图片域名、脚本或服务器处理阶段。文件再大也会拆成许多包，网页大小不能直接推算MTU。仅凭“短页面正常、长页面异常”，还不足以确认发生了路径MTU问题。

先在浏览器网络面板找出真正等待的请求，记录目标域名、开始时间、是否已收到响应头，以及停在连接还是下载阶段。选少量公开页面对照，保持同一设备、节点和代理模式，不用大文件测速代替排障。

随后只切换一项条件，例如网络入口或节点，观察现象是否稳定复现。必要时由熟悉网络的人结合重传和包太大消息检查链路。只有证据支持这一方向，再按客户端文档调整相关接口，记录原值并复测；改善一次也不能证明根因。避免同时修改DNS、防火墙和网卡参数，否则即使恢复连接，也难以知道哪一步起作用。