小网页能开、大文件却卡住，什么时候才该怀疑代理 MTU？
路径 MTU 黑洞常表现为连接建立、小数据成功，但较大传输停滞。它只是候选原因；先排除节点丢包、TLS、规则和目标限速，再做可撤销的 MTU 对照。
先看重点只有同一路径反复出现“小请求成功、较大响应停住”，换节点或直连能恢复，且日志没有明确 TLS/规则错误时，才值得测试 MTU。记录当前值，临时小幅降低 TUN MTU并重测同一目标；能稳定恢复才说明相关。不要照抄极小值或一次改系统所有网卡。
MTU 是一条链路能承载的最大 IP 包尺寸，路径 MTU 则取整条路径中最小的那一段。代理、VPN 和 TUN 会增加封装开销；如果发送端认为可以发更大的包，而中间设备又没有正确反馈“包太大”，连接可能进入 Path MTU 黑洞。
RFC 2923 描述的典型现象是：TCP 能建立连接、开始传输，然后不再前进直到超时；小控制数据正常，大批量传输失败。但很多其他故障也长得一样，不能见到“卡住”就改 MTU。
哪些现象组合才像 MTU
- TCP/HTTPS 已经连上，不是立刻拒绝；
- 很小的页面、请求头或聊天文本成功；
- 大响应、上传、图片或登录后的页面稳定停在相近阶段；
- 同一目标直连正常，特定 TUN/节点路径失败；
- 更换一条网络或关闭封装后立即恢复；
- 客户端日志没有证书、规则拒绝或订阅错误。
如果所有请求都超时，更像节点、DNS 或路由故障；若明确报证书不受信任，更应处理系统时间与 TLS；视频慢但最终持续下载，先看吞吐和丢包。
为什么 ping 通不能排除
普通 ping 包很小，能通过不代表大包能通过。某些网络还会单独限制 ICMP，使 ping 失败但网页正常。路径 MTU 发现又依赖“Packet Too Big”或“需要分片”等反馈；防火墙错误丢掉反馈时，发送端不知道应该缩小包。
因此，不把“一次 ping 通/不通”当结论。它只能是同一路径下的一项辅助结果。
先排除更常见的原因
固定同一设备、目标和时间，依次比较：
- 直连与代理；
- 系统代理与 TUN；
- 同一订阅的另一个节点；
- 当前网络与手机热点；
- TCP 页面与 UDP/QUIC 应用。
同时查看客户端日志和浏览器错误。若仅一个节点慢、其他节点正常，优先按线路质量处理；若仅一个网站返回 429/地区限制，也不是 MTU。
做一次最小、可撤销的 MTU 对照
Mihomo TUN 提供 mtu 参数，官方说明一般用户保持默认即可。只有前面的症状一致时，才记录当前配置，临时把 TUN MTU 小幅降低一档，重载后重复同一个大请求多次。
判断标准是稳定可重复：原值失败、较低值成功、恢复原值再次失败。一次偶然成功可能只是线路抖动。不要同时换节点、改 DNS 或关闭 IPv6。
也不要直接把系统所有网卡改成网上推荐的固定数字。不同接入、封装和 IPv4/IPv6 路径的开销不同；过低虽可能绕开黑洞，却会增加包数量和处理开销，掩盖真正问题。
IPv6 和 UDP 也有自己的发现机制
RFC 8201 定义 IPv6 Path MTU Discovery；RFC 8899 为 UDP 等数据报传输定义更稳健的探测方式。实际应用是否实现、网络是否正确传递反馈，各不相同。因此“网页修好了”不能自动证明游戏、QUIC 和语音也使用同一包大小策略。
如果只有 UDP/QUIC 失败而 TCP 正常，先看UDP/QUIC 被阻断的判断方法，再把 MTU作为一个候选变量。
什么时候应停止自己调
最低风险的对照仍无法稳定复现、设备受组织管理，或问题出现在路由器/运营商隧道时，应恢复默认并把时间、目标、节点、网络和对照结果交给服务方。高质量排障记录比一串随机 MTU 数字更容易定位。
资料来源
以下来源于 2026/8/8 复核。版本、支持平台和发布状态以后续官方页面为准。
持续更新
收到新教程，也欢迎纠错
想收到新文章，可以关注 TG 频道；发现下载失效、套餐变化或步骤不一致，请附上页面链接和可公开的截图。不要发送订阅链接、密码或完整账户信息。
读者互动
这篇内容对你有帮助吗？
最新评论
- 正在加载评论……