隧道能建立，却在打开较大的页面、传输文件或执行远程操作时反复超时，常见原因之一是报文尺寸超过了路径可承载的上限。排查远程访问隧道的MTU设置与分片故障排查，要同时看隧道内层数据包和外层封装包，不能只把网卡 MTU 改小了事。
先判断是否真是 MTU 问题
如果登录、短消息等小流量正常，较大的传输容易停住，MTU 问题的可能性会上升；若连接从一开始就失败，则还应检查路由、防火墙和认证。记录故障发生的客户端、隧道协议、目标地址，以及“连接建立”和“大流量传输”是否都受影响，便于对比。
MTU 是单个 IP 包可承载的最大长度。隧道会在原始数据包外增加封装头，外层路径的可用空间因此减少；具体开销取决于协议、加密方式和选项。以太网常见 MTU 为 1500 字节，PPPoE 链路常见为 1492 字节，但这些只是常见配置，不代表端到端路径一定支持相同尺寸。
按顺序测出路径上限
- 确认接口与隧道类型。查看客户端的物理接口和隧道接口 MTU，并记录服务端对应配置。Linux 可用 ip link 查看接口信息；其他系统也可在网络接口属性中查看。不要把内层接口数值当成外层路径的实际上限。
- 对隧道对端逐步探测。在 Linux 上，iputils 的 ping 可尝试 -M do 禁止 IPv4 分片，再用 -s 调整 ICMP 数据长度；Windows 的 ping 可用 -f -l 设置不分片和数据长度。IPv4 报文总长还包含 IP 与 ICMP 头，常见情况下合计比数据长度多 28 字节。IPv6 头部开销不同，命令选项也因系统而异，应查对应工具说明。
- 二分缩小尺寸。从较小的数据长度开始递增，找到稳定成功与失败的边界，再在边界附近逐步调整。每个尺寸可重复发送数次，并换一个时段复测；探测包被防火墙限速或丢弃时，单次失败不能直接证明 MTU 过小。
- 对比隧道内外结果。若隧道内小包通、大包失败，而外层连通，检查封装后是否超过外层 MTU；若内外层都丢包，先排查链路或过滤规则。抓包时观察报文长度、重传及分片标记，并同时查看客户端和服务端，避免只凭一端下结论。
怎样理解分片与相关设置
分片不一定会自动补救
IPv4 在允许分片时，超长数据报可能被拆成多个片段；任一片丢失，整个数据报都无法完整交付。设置了 DF 位的 IPv4 报文不能由中间路由器分片，通常需要依靠路径 MTU 发现（PMTUD）让发送端调整尺寸。IPv6 路由器不会替发送端分片，路径上的尺寸问题需要由源端处理。因此，放开分片不一定是可靠修复办法。
区分 MTU 与 MSS
TCP 的 MSS 钳制会调整 TCP 数据段大小，适合缓解 TCP 流量因隧道封装造成的超长问题，但它不覆盖 UDP 等非 TCP 流量，也不能替代正确的 MTU 配置。若只有 TCP 应用恢复，其他协议仍异常，应继续检查隧道 MTU、PMTUD 和防火墙对相关报文的处理。
修改后如何验证
- 先备份客户端和服务端当前配置，记录原始 MTU、探测边界及故障表现。
- 依据实测路径上限与封装开销，选择略低于可用上限的隧道 MTU；不要照搬其他线路的固定数值。
- 如需调整 MSS 钳制，确认规则作用于正确方向和接口，并检查 UDP 等流量是否仍有问题。
- 重新连接隧道，分别测试小包、较大数据传输和不同协议；确认稳定后再持久化配置。
如果减小 MTU 后仍频繁超时，恢复原配置并检查丢包、过滤规则、隧道两端不一致及路径变化。远程访问隧道的MTU设置与分片故障排查应以可重复的尺寸测试和两端抓包为依据，而不是不断试改数值。
常见问题
所有远程访问隧道都应设成同一个 MTU 吗？
不应。封装协议、底层链路和路径不同，可用 MTU 也不同，应以实际探测及设备文档为准。
探测包一直失败，是否说明 MTU 太小？
不一定。防火墙可能过滤探测报文。可比较不同尺寸、协议和方向的结果，并用抓包验证。
调低 MTU 会有什么代价？
可能增加分包数量和协议处理开销；设置过低会降低传输效率。应只调整到满足路径要求的范围。
只改 MSS 能解决所有应用超时吗？
不能。MSS 钳制主要针对 TCP；若故障涉及 UDP 或隧道本身的封装尺寸，还需检查 MTU 与分片路径。