MTU设置多少合适？1500、1492、1400的区别与测试方法
MTU设置多少合适？网络正常时保留默认值；出现“小包能通、大文件传不动”的现象，再测试实际路径。普通以太网常见 1500，传统 PPPoE 常见 1492，VPN 则要结合封装方式和客户端实现判断，1400 没有通用的最佳值地位。
调整之前，先分清你要改的是路由器 WAN 口、电脑物理网卡，还是 VPN 的虚拟网卡。这三个位置的数值可以不同。测错路径、改错接口，即使数字算得准确，也可能对故障没有帮助。
1500、1492和1400分别适合什么情况
MTU 指一个接口能够承载的最大 IP 包大小，单位是字节，包含 IP 头部。接口的上限与整条路径的上限也要分开：去往某个目标时，沿途最小的链路上限决定路径 MTU，换目标或换网络，结果可能改变。定义可参考 华为的 MTU 说明和 RFC 1191。
| 数值 | 常见场景 | 怎么判断 |
|---|---|---|
| 1500 | 普通以太网接口 | 当前连接正常就保留，无需为了提速修改 |
| 1492 | 在 1500 字节以太网上运行的传统 PPPoE | 8 字节封装占用空间，先看拨号设备实际设置 |
| 1400 | 某些隧道故障的临时对照值 | 可以用于观察变化，不能当作所有 VPN 的推荐值 |
| 9000 | 支持巨型帧的局域网，或某些虚拟接口 | 需要看接口用途和实现，不能照搬到公网 WAN 口 |
PPPoE 也有支持更大数值的扩展。只有客户端、接入设备和底层链路配合，才能突破传统的 1492 限制，因此“拨号就必须设 1492”也不适用于每一种部署。RFC 4638说明了这种扩展的条件。
把值改小不会自动降低游戏延迟。 相同数据量可能需要更多包才能传完，协议头和处理开销随之增加。原本没有包大小问题的连接，调小后未必更快。
哪些现象值得检查包大小
下面几种现象一起出现时，值得把路径 MTU 加进排查范围：
- 普通 ping 有回复，传文件却卡住。
- 网页能打开一部分，图片或上传请求一直等待。
- 同一台设备换成手机热点后恢复。
- 小数据请求稳定，大数据请求反复失败。
原因可能是“大包发不出去”的通知没有回到发送端。IPv4 路由器遇到超过下一段链路上限、又被禁止分片的包时，应通知发送端缩小包。通知被过滤后，发送端可能继续重试大包，连接就会停滞。小包正常、大量数据传输失败，是 RFC 2923描述的典型现象。
这些症状也可能来自丢包、服务器故障或客户端规则。完全连不上、所有节点都超时，先按节点超时的排查顺序检查，避免一开始就修改网络参数。
用ping测试IPv4路径上限
先测试不经过 VPN 的普通网络路径。退出代理连接，选一个在当前网络上能稳定回复 ping 的目标。下面用 1.1.1.1 演示；如果它不回复，换一个能回复的目标，不能靠连续缩小包去猜。
Windows 命令提示符中运行：
ping -4 -n 4 -f -l 1472 1.1.1.1-4 固定使用 IPv4，-f 设置禁止分片，-l 指定 ICMP 数据部分的长度。这些参数的含义见 Microsoft ping 文档。
1472 字节数据，加上通常的 20 字节 IPv4 头和 8 字节 ICMP 头，合计 1500 字节。这里只讨论没有 IP 选项的普通 IPv4 Echo 请求；IPv6 不能照搬加 28 的算法。
如果明确提示“需要拆分数据包但是设置了 DF”，尝试更小的值：
ping -4 -n 4 -f -l 1464 1.1.1.1
ping -4 -n 4 -f -l 1400 1.1.1.1找到成功值和失败值后，在两者之间继续测试，逐步缩小范围。比如 1464 连续成功、1465 连续提示需要分片，就得到当前测试条件下约 1492 字节的上限。1464 是测试数据长度，1492 才是加上头部后的 IP 包长度。
Linux 的 iputils ping 可以使用：
ping -4 -c 4 -M do -s 1472 1.1.1.1其中 -s 指定数据长度，-M do 使用禁止分片的路径探测策略；本地已知的路径上限也可能直接阻止发送。参数说明见 iputils ping 手册。
| 结果 | 可以判断什么 | 下一步 |
|---|---|---|
| 连续收到目标回复 | 该大小在当前测试中可用 | 继续向上探测，或者保留默认值 |
| 明确提示需要分片或包过大 | 当前大小超过本地或沿途上限 | 减小后重试，寻找边界 |
| 只有请求超时 | 原因尚未确定 | 先确认小包能否稳定回复，再换目标比较 |
| 大小相同却时通时不通 | 可能有丢包、限流或路径变化 | 重复测试，不据此认定精确上限 |
这个结果只对当前网络、目标和测试方向有参考价值。一次成功回复不足以证明所有网站都能承载同样大小的包。
开着VPN测试时先确认流量走哪里
系统代理一般接管 HTTP 或 SOCKS 请求，ping 使用 ICMP，通常不会通过系统代理。因此，“开着代理 ping 得到 1500”不能证明代理隧道也适合这个值。系统代理和虚拟网卡的区别，可看TUN模式是什么。
即使开启了 TUN，也要确认客户端怎样处理 ICMP。它可能直连、由本地协议栈处理，或者不支持这种转发；虚拟接口上的一次回复，未必经过了你以为的远端节点。
真正要调整 VPN 时，先看客户端对应版本的文档，区分虚拟网卡参数和外层传输参数。虚拟接口承接应用数据后，客户端可能重新建立连接、分段或封装，不能把 WAN 口测到的上限直接当作虚拟接口的最佳值。比如 sing-box TUN 文档中的 mtu 指定的就是 TUN 接口参数。
换一家 VPN 服务也不能保证解决本地链路的包大小问题。 如果故障来自路由器或运营商路径，换节点可能碰巧避开，也可能继续出现。保留“同一文件、同一网络、改前改后”的对照结果，比只看客户端显示已连接更有用。
Windows修改前记下原值并准备恢复
只有前面的测试和实际故障相互印证，才值得尝试修改。下面演示 Windows 物理网卡的 IPv4 临时调整；VPN 虚拟网卡优先通过客户端自身设置处理，避免被客户端重新创建后覆盖。
先查看接口：
netsh interface ipv4 show subinterfaces找到实际联网的 Wi-Fi 或以太网接口，保存接口名称和原数值。假设接口名是 Wi-Fi，原值是 1500，而测得的边界是 1492，在管理员命令提示符中运行：
netsh interface ipv4 set subinterface interface="Wi-Fi" mtu=1492 store=active再次运行查看命令，确认变化，再重新发起此前失败的上传或下载。这里的接口名和数值都是示例，需要替换成你记录的结果。
store=active 表示临时设置，到下次系统启动为止；persistent 会保留到重启之后。参数依据是 Microsoft netsh interface 文档。
没有改善就恢复原值。上面示例的恢复命令是：
netsh interface ipv4 set subinterface interface="Wi-Fi" mtu=1500 store=active每次只改一个位置。电脑、路由器和客户端一起调整，结果变好也无法判断哪一步有效。需要长期保留时，先完成多次对照测试，再按设备文档保存设置。
常见问题
MTU设置多少最好？
连接正常时保留设备默认值。出现包大小相关的故障，才根据对应接口和实际路径测试；别人的测试结果不能替代你的网络结果。
MTU设置1400还是1500？
普通以太网常见 1500。1400 可以作为部分故障的临时对照值，但它占用的有效数据空间更少，也没有保证提高网速；只有实际业务稳定改善才有继续调整的依据。
Windows MTU设置在哪里？
可以用本文的 netsh interface ipv4 show subinterfaces 查看，再通过管理员命令提示符修改指定接口。先记原值，优先使用临时设置，测试无效就恢复。
MTU设置9000可以提高网速吗？
支持巨型帧的局域网需要沿途设备配合，公网连接不能靠单独把网卡改成 9000 提速。VPN 虚拟接口显示这个值时，还要看客户端如何处理数据，不能仅凭数字就认定配置有错。
IPv6 MTU也能用最大ping长度加28吗？
不能。IPv6 的头部和分片规则不同，路由器不对 IPv6 包进行分片，链路还需要满足 1280 字节的最低 MTU 要求。本文命令固定使用 IPv4；IPv6 的规则见 RFC 8200。