VPN 已连接但大文件传不动：用证据排查 MTU

紧急情况： 通过 VPN 可以 Ping 到服务器，也能打开登录页，但上传文件或完整加载应用会停滞。这可能符合包大小问题，却不能单凭此认定 MTU 有错；丢包、路径限制或应用本身也可能产生相似症状。

选择可重复的测试

对同一文件和目标，比较启用与不启用隧道的结果。记录时间、连接类型及结果。目的不是同时更改多项设置后碰巧恢复服务，而是保留可以再次验证的明确差异。

Windows 与 IPv4 的初步检查

示例使用文档地址，不应期待原样执行就获得回复。请替换为隧道路径中获准测试且会响应的目标。此测试的 DF 选项适用于 IPv4。

ping /4 /n 2 /f /l 1472 192.0.2.10
ping /4 /n 2 /f /l 1400 192.0.2.10
netsh interface ipv4 show subinterfaces

对于没有额外选项的 IPv4，将 Ping 数据大小换算成 IP 包大小，通常需要加上 28 字节的 IP 和 ICMP 开销。因此 1472 字节的数据对应 1500 字节的数据包；1472 本身不是 MTU。

如果明确收到需要分片的消息，而较小尺寸成功，包大小受限的假设会更有依据。仅有超时不能证明这一点，因为路径或目标可能过滤 ICMP。小 Ping 成功，也不能确认所有 TCP 传输都正常。

将修复限定在同一路径

用不同尺寸寻找该路径上的成功边界，并记录接口原值。证据充分时，可按照产品文档，仅在相关范围测试隧道 MTU 或 TCP 路径 MSS。1400 不是所有 VPN 的固定答案，Ping 数据大小也不能未经计算直接填入接口 MTU。

同时检查 PMTUD 路径是否正常，以及必要的 ICMP 消息。一起修改所有接口 MTU 或开放整个防火墙，既不利于诊断，也缺乏明确回退。有限修改无效时，应恢复旧值，再检查下一个假设。

恢复标准是真实传输能够重复成功

多次测试同一文件、请求及双向路径。一次 Ping 或短传输成功并不足够。我的建议是为重要隧道保留小型传输测试场景，便于在运营商或设备变更后重复验证。

关键决策： 测量包大小；VPN 显示已连接，不代表数据路径健康。

技术参考: Microsoft / Ping · RFC / PMTUD.