开启 TUN 后部分网页打不开？MTU 的判断与排查方法

开启 TUN 后，部分网页一直转圈，或者下载建立连接后卡住，MTU 可以作为一个检查方向，但不能只凭这一现象直接调小数值。先确认异常是否只随 TUN 出现，再排除规则、目标服务和解析问题，最后做范围有限的参数对照。

本文讨论桌面代理客户端的排查思路，以 Mihomo 为例。它适合“基础网络可用、只有部分请求异常”的情况，不是通用网络加速教程。

作者：小六

MTU 是什么，和网速有何关系？

MTU 是最大传输单元，表示某条链路一次能够承载的 IP 数据包大小限制，通常以字节计。它控制的是包的大小，与套餐标注的流量、宽带每秒传输速度不同。

可以把网络路径想成经过多段限高不同的道路。包能否通过，要考虑沿途限制，而不能只看本机接口的一项数值。基本概念可参考 Cloudflare 的 MTU 说明。

封装和隧道还会增加额外头部，实际可承载的数据受具体实现影响。虚拟接口的 MTU、本机物理接口的 MTU 与远端路径 MTU，也不是同一个对象。

因此，抄一个别人使用的数值，不能保证适合自己的协议、网络和客户端。Mihomo 对 tun.mtu 的说明也建议一般用户使用默认值，见 TUN 配置文档。

为什么能连接，却在传数据时卡住？

建立连接与传输较大的数据，经过的条件可能不同。路径 MTU 发现机制会帮助发送端调整包的大小；如果相关反馈无法返回，就可能出现连接已建立、数据传输却停住的情况。

IETF 的 RFC 8201明确描述了 IPv6 场景：用于路径 MTU 发现的 ICMPv6 反馈被阻断或未传回时，TCP 握手可能成功，后续传输却卡住。

这是可能的网络原因，不是对所有“网页转圈”的诊断。目标服务响应慢、连接规则不一致、某个资源域名不可达，也可能表现相似。应先保留失败请求和日志，再判断是否值得检查包大小。

哪些现象值得进一步核对？

现象	优先观察什么
开 TUN 异常，关闭后恢复	两次请求是否仍走同一出口，以及接管配置差异
小页面可用，大文件反复停住	失败阶段、重传线索与路径条件
只有一个网站异常	网站状态、资源域名和实际分流
换本地网络后恢复	原网络路径，而不只是远端节点
刚改过 MTU 后出现问题	原值与当前生效配置

这些都是排查线索。尤其是“关 TUN 恢复”，也可能意味着请求没有再进入客户端，不能自动证明 MTU 是原因。

做对照之前，先固定四个条件

固定设备、网络、节点和目标，再记录 TUN 状态与当前参数。每次对照重新建立请求，减少旧连接影响；不要同时换节点和修改多个开关。

第一步：确认实际走的是同一条连接

在客户端记录中核对目标、规则与最终节点。系统代理与 TUN 的接收范围可能不同，关闭 TUN 后浏览器是否仍使用系统代理，要单独确认。

需要分清这两层，可以先看本站的规则模式、系统代理和 TUN 指南。

第二步：找出卡住的请求

网页主页面、图片与接口可能使用不同域名。记录究竟是哪一项失败，以及错误是解析失败、连接超时，还是传输途中停止。不要只凭页面上的转圈图标判断。

如果日志显示域名还没解析成功，先处理解析；如果返回明确的 HTTP 错误，先核对目标服务。MTU 修改不能修复账户授权或页面不存在。

第三步：有依据时，再试客户端支持的调整

优先检查近期改动，必要时恢复客户端原有默认值。如果软件文档或维护者给出了适用于当前版本和协议的测试方案，再按它调整一项参数。

只在客户端支持的配置入口修改，保存原值并重新加载。不要把物理网卡、路由器和 TUN 的 MTU 一起改，也不要把文档示例中的数字理解成最佳值。

第四步：用结果决定是否保留

比较同一失败请求是否恢复，常用页面和下载是否正常。如果没有稳定改善，就恢复原值，继续检查其他方向。

“刚改完就好了”仍可能碰上目标服务恢复。保留时间和重复对照结果，才便于判断改动与现象是否有关。

ping 能通，为什么仍不能排除 MTU 问题？

一次 ping 只反映该次测试包与目标的结果。默认测试包的大小、连接路径和应用实际传输可能不同；目标不回复 ping，也不等于网页连接一定失败。

普通用户不需要从一次 ping 结果推导出一个精确 MTU。确认路径 MTU 通常还需要符合协议的测试、日志或抓包，以及服务端配合。无法取得这些证据时，应把结论写成“待核对”，而不是“已经找到最佳值”。

求助时，提供哪些信息更有用？

提供系统、客户端与内核版本、网络类型、TUN 开关前后的结果、原参数，以及脱敏后的失败阶段。若多个节点都只在同一网络异常，也把这个对照写清楚。

整体下载变慢，可以结合本站的节点测速记录方法继续观察，避免把速度波动全归因于 MTU。

想交流“开启 TUN 后只有部分网页卡住”的排查记录，可以带上上述信息：Telegram 联系我