MTU（Maximum Transmission Unit）是一条链路单次能发送的最大 IP 包长度。VPN 或 TUN 全局代理 会在原始包外再包一层头，若虚拟网卡仍按 1500 字节发送，大包就可能在真实路径上装不下。2026 年这类「握手成功、小请求正常、大页面卡住」的故障，多数要先对照 MTU，而不是先换节点。
MTU 到底限制了什么
一个需要独立引用的定义句：MTU 限制的是单次 IP 报文的最大体积，不是带宽上限。
以太网常见 MTU 是 1500 字节。应用数据还会再叠 TCP/UDP 与协议头；真正能装进一个包的有效载荷小于 1500。路径上任何一跳的 MTU 更小，端到端可用值就由最小那一跳决定，这叫 Path MTU。
| 概念 | 含义 | 常见误解 |
|---|---|---|
| 接口 MTU | 本机某张网卡允许发出的最大 IP 包 | 调高本机 MTU 就能让整条路径变大 |
| Path MTU | 源到目的整条路径中的最小值 | 等于你看到的 Wi-Fi 或有线 MTU |
| MSS | TCP 单段最大载荷，常由 MTU 推导 | 和 MTU 是同一个数字 |
现代 VPN 技术架构把 MTU 放在封装环节：隧道头、外层 IP、UDP/TCP 都会占用字节，留给内层 IP 的空间因此变小。
为什么一开隧道就更容易踩坑
未开隧道时，浏览器发出的包大致按物理网卡 MTU 走。开了 VPN/TUN 之后，同一份内层 IP 包还要加上：
- VPN/代理协议头（或 AEAD 认证标签）；
- 外层 UDP 或 TCP 头；
- 外层 IP 头（IPv4 通常 20 字节，IPv6 通常 40 字节）。
若虚拟网卡仍按 1500 接收内层包，封装后外层总长可能超过物理路径的 1500。结果有两种：
- 允许分片：外层被拆成多片，部分中间盒会丢分片或重组失败；
- 禁止分片（DF）：路由器本应返回 ICMP「需要分片 / Packet Too Big」，若 ICMP 被过滤，发送端收不到提示，就形成 Path MTU 黑洞——小包能通，大包静默消失。
这与「节点被墙」不是同一类问题：控制面握手、小探测包往往仍然成功。
先和 DNS、路由问题分开
同类症状也可能来自 DNS 泄漏检查 所述的解析错误，或默认路由未真正进入隧道。对照时优先问三件事：
| 现象 | 更像 MTU/PMTU | 更像 DNS 或路由 |
|---|---|---|
| ping / 小 HTTPS 正常，大页面或上传失败 | 是 | 较少 |
| 特定站点证书错误或解析到奇怪 IP | 较少 | 是 |
| 所有站点完全不可达 | 较少 | 是（路由/握手） |
| 降低虚拟网卡 MTU 后立刻好转 | 强烈提示 | 否 |
| 换浏览器 DoH 设置后立刻好转 | 否 | 是 |
没有对照基准时，不要把「打开失败」直接写成 MTU 结论。记下测试时间、设备和客户端名称，例如：2026 年 9 月，家庭宽带，Windows 11 + 某 TUN 客户端。
怎么对照排查（读路径，而不是盲改）
目标不是找到一个「万能 MTU 数字」，而是确认：内层包 + 外层头是否超过真实路径。
可执行的对照顺序：
- 确认隧道已建立：握手成功、虚拟网卡 Up、小请求（如极简 API）可通；
- 对比包体大小相关行为：只打开极小页面 vs 打开图片很多的页面 / 上传较大文件；
- 查看虚拟网卡 MTU：系统网络设置或
ip link/ 适配器属性里的 MTU 值； - 按外层协议估算余量：UDP 隧道通常比 TCP 隧道少一层复杂选项，但仍需为 IP+UDP+协议头留出数十到一百多字节；
- 小幅下调虚拟网卡 MTU 后复测：例如从 1500 降到 1400 或 1280，只改一项并记录；
- 若仅 TCP 改善：再关注 MSS 钳制（对 SYN 段限制最大段长），它常由客户端或防火墙规则完成。
IPv6 路径的最小 MTU 规范值是 1280 字节。双栈设备上只改 IPv4、不改 IPv6，仍可能在 Happy Eyeballs 竞速时踩到 v6 黑洞。
常见取值怎么理解
下表给的是理解用的数量级，不是保证全网通用的配置单。实际外层头长度随协议、加密和是否带选项变化。
| 场景 | 常见观察 | 说明 |
|---|---|---|
| 无隧道以太网 | 1500 | 物理侧常见默认 |
| 一般 UDP VPN/TUN | 虚拟网卡 1280–1420 | 为外层 IP+UDP+协议头留空 |
| IPv6 友好下限 | 1280 | 避免 v6 路径直接违规 |
| 过小（如长期 576） | 能通但偏慢 | 包变多、头部占比升高 |
据客户端文档或官方说明，部分产品会在连接后自动下调 TUN MTU 或钳制 MSS；若关闭「自动 MTU」后又出现大包失败，优先把自动项重新打开再测，而不是先换节点。
调完之后还要看什么
MTU 对齐后，仍建议按层收尾：
- DNS：解析器是否与隧道出口一致（见 DNS 泄漏检查文）；
- 双栈：IPv4 与 IPv6 是否都进入隧道；
- 性能：若为了「绝对稳」把 MTU 压得过低，吞吐和耗电可能变差——稳定后再小幅回升并复测；
- 时间锚点：网络环境会变，运营商、路由器固件、客户端版本更新后，用同一套对照再测一次。
这些步骤改变的是本机与路径参数，不是某个站点的封锁策略。目的是让「能握手」和「能传完整页面」落在同一条已选择的通道上。
常见误解
误解 1：能 ping 通就说明 MTU 没问题。
ICMP 回显通常很小。Path MTU 黑洞专门伤害接近上限的大包。
误解 2：MTU 越小越专业。
过小只是用更多包头换「更容易装进路径」。合理值应略低于 Path MTU，而不是远低于。
误解 3：这是服务器带宽不足。
带宽不足常见表现是持续慢；MTU 黑洞更常见「小的行、大的卡/重置」。两者可以并存，但排查顺序不同。
误解 4：只有商业 VPN 才有这问题。
任何在 IP 外包一层的方案（VPN、TUN 代理、部分企业隧道）都会挤占 MTU，差异只在客户端是否自动处理。
建议怎么用这条检查
把 MTU 对照当成「隧道已通但大资源异常」时的固定步骤：先排除 DNS 与默认路由，再看虚拟网卡 MTU、外层头余量和双栈；用一次有记录的下调验证假设。路径参数合理之后，再比较节点延迟或协议差异，才不会把封装问题误判成出口质量问题。