服务器能 ping 通，浏览器却一直转圈；SSH 可以登录，下载文件时却停住；接入 VPN 后只有部分网站打不开。这些现象值得检查路径 MTU，但仅凭“ping 通、网页打不开”还不能确定原因。
普通 ping 验证的是 ICMP 回显是否可达，没有验证 TCP 443 端口、TLS 握手和 HTTP 服务。排查时先找出连接停在哪一步，再通过不同包长、IPv4/IPv6 对比和连接信息判断是否存在路径 MTU 黑洞。直接把所有网卡改成同一个较小 MTU，可能掩盖故障，也可能影响现有连接。
一、哪些现象值得怀疑 MTU？
以下线索同时出现时，可以把 MTU 检查往前排：
小请求通常正常，传输较大响应或文件时反复停住。
TCP 能建立连接，但 TLS 握手或随后传输没有进展。
故障只发生在 VPN、隧道或某条出口路径上，换网络后恢复。
同一服务的 IPv4 正常、IPv6 异常，或反过来。
这些都不是独立的确诊条件。端口封禁、TLS 配置、源站过载、代理限制和普通丢包也可能造成类似表现。如果已经收到 HTTP 403、404 或 500，说明那一次请求至少到达了能返回 HTTP 响应的服务，应先沿对应状态码排查，不能直接归因于 MTU。
RFC 2923 记录过典型的 PMTUD 黑洞表现：小包和交互连接可以通过，批量传输却在较大报文处失败。[1]
二、MTU、路径 MTU 和 TCP MSS 有什么区别？
MTU 是接口或链路能够承载的 IP 包大小限制。Linux 中可以先用 ip link 查看接口配置；看到本机接口 MTU 为 1500，并不代表整条路径都支持 1500。
路径 MTU（PMTU）受路径中较小的链路 MTU 限制。隧道封装会增加外层报文开销，如果底层网络容量没有随之增加，留给内层报文的空间就会变小。
TCP MSS 表示一个 TCP 段可承载的数据大小，不包含 IP 和 TCP 头。只按基础头部估算，IPv4 常用 MTU 减 40，IPv6 常用 MTU 减 60；实际发送还要考虑选项、扩展头及封装开销。这两个差值不能直接作为所有网络的配置公式。
MSS 也不等于整条路径的探测结果：通信双方在握手中通告的能力，未必能反映中间隧道或链路的限制。[1][2][3]
三、路径 MTU 黑洞为什么会让网页卡住？
在 IPv4 中，报文设置 DF（不分片）且超过下一跳 MTU 时，路由器应返回 ICMP“需要分片但 DF 已设置”消息，供发送端调整报文大小。对应类型是 ICMP Type 3、Code 4。[2]
IPv6 路由器不替经过的报文分片。报文超过转发链路的 MTU 时，需要通过 ICMPv6 Packet Too Big 消息通知发送端。[3]
如果大包被丢弃，而相关反馈又被防火墙或中间设备拦截，发送端可能继续重传无法通过的报文。小型握手报文能通过，后续较大的数据报文却停滞，于是出现“连得上，但传不动”。
反馈丢失还可能发生在返回路径。因此，只看业务服务器的入站规则不够，还要核对出口、防火墙、隧道边界及云网络的对应策略。[1][2][3]
四、先定位 HTTPS 停在哪一步
下面命令用于 Linux 环境。把 example.com 和示例 IP 替换成有权测试的目标；命令中的地址不是本文的实测结果。
curl -4 -v --connect-timeout 5 --max-time 20 -o /dev/null https://example.com/ curl -6 -v --connect-timeout 5 --max-time 20 -o /dev/null https://example.com/
观察输出停在域名解析、TCP 连接、TLS 握手，还是接收响应阶段。只有目标配置了对应协议的地址、本机也具备相应网络条件时，IPv4/IPv6 对照才有意义。
需要排除 DNS 指向差异时，可以指定地址，同时保留请求中的域名及正常的 TLS 证书验证：
curl -v --resolve example.com:443:203.0.113.10 --connect-timeout 5 --max-time 20 -o /dev/null https://example.com/
203.0.113.10 是文档示例地址，必须替换。不要用关闭证书校验来证明“TLS 正常”。如果经过 CDN 或代理，固定地址测试也要确认测的是预期节点，不能把绕过 CDN 后的结果当成原路径结果。[7]
五、用不同包长检查 MTU 线索
先查看本机接口及去往目标的路由：
ip link show ip route get 203.0.113.10
在 Linux iputils ping 中，可对 IPv4 做一组低频、有限次数的对照：
ping -4 -c 4 -W 2 -M do -s 1472 203.0.113.10 ping -4 -c 4 -W 2 -M do -s 1400 203.0.113.10 ping -4 -c 4 -W 2 -M do -s 1200 203.0.113.10
-s 设置 ICMP 数据长度，不是整个 IP 包长度。
仅在 IPv4 头为 20 字节、ICMP 头为 8 字节时，1472 字节负载对应 1500 字节 IP 包。
-M do 设置不分片策略，同时仍受内核 PMTU 检查约束；过大的包可能被本机拒绝，并非一定已经发到中间路由器。[4]
如果大包持续失败，小包稳定成功，而且 HTTPS 故障与该路径一致，MTU 假设就多了一项证据。若出现本机“message too long”，应结合接口和路由信息分析；若只是超时，还可能是目标禁止回显或中间设备限速。
单次成功也不能精确代表所有业务路径。ICMP 与 TCP 可能走不同的负载均衡路径，去程和回程也可能不对称。IPv6 的基础头长度不同，不要把 1472 原样当作 IPv6 的 1500 字节测试负载。
六、结合 tracepath 和 TCP 连接信息复核
tracepath 可以提供路径及 PMTU 线索，使用 UDP 探测，通常不需要超级用户权限：
tracepath -4 example.com tracepath -6 example.com ss -tin dst 203.0.113.10
tracepath 没有回包不等于对应节点故障；过滤策略和回包信息不足都可能影响结果。[5]
ss 输出可辅助观察连接的重传和传输进展。部分系统会显示 pmtu、mss 等字段，具体取决于内核、工具版本和连接状态。应在业务卡住时连续观察，而不是只保存一次正常截图。
证据仍不够时，可以在有权限的链路两端做短时、限定目标的抓包，核对较大报文是否反复重传，以及发送端能否收到相关 ICMP/PTB 消息。反馈可能来自中间路由器，抓包过滤条件不能只覆盖客户端与服务端之间的 TCP 数据。
本机抓包还可能受网卡分段、聚合卸载影响；看到一个很大的报文，不能据此认定线上真的发送了同样大小的 IP 包。抓包文件可能包含地址和业务内容，应限制采集范围，并按内部规则保管。
七、确认后怎么修复？
1. 校准接口与隧道 MTU
根据实际封装协议、外层地址族和底层链路上限确定内层 MTU，不要统一套用 1500、1450 或 1400。涉及远程连接所用接口时，先准备控制台或其他带外入口，在维护窗口验证并保留回滚配置。
2. 检查必要的 ICMP 反馈
按安全策略允许 PMTUD 所需的 IPv4“需要分片”及 ICMPv6 Packet Too Big 反馈通过，并核对方向和关联流量处理。无需为了排查清空防火墙，也不要把“允许 ping”误认为“已经允许全部必要的 ICMP 错误消息”。[2][3]
3. 有针对性地评估 MSS 调整
在明确的 TCP 隧道或转发边界，可以评估 MSS clamping，但数值和方向应以实际路径为依据，并通过新建连接验证。它调整 TCP 的协商信息，不能修复 UDP 或 QUIC 的报文大小问题，也不能替代完整的路径排查。
4. 理解 tcp_mtu_probing 的适用范围
先只读查看当前配置：
sysctl net.ipv4.tcp_mtu_probing
Linux 内核文档对该参数的定义如下：[6]
0：关闭 TCP 的报文层 MTU 探测。
1：通常不启用，在检测到 ICMP 黑洞时启用。
2：始终启用，初始 MSS 使用 tcp_base_mss。
经过复核后，可以在受控环境评估值 1 的效果，但不要把它当成通用的一键优化。它作用于相应网络命名空间内的 TCP 栈，不能直接修复转发经过该主机的所有流量，也不解决 UDP/QUIC 故障。
如需变更，应先记录原值和作用范围，测试新连接，再决定是否持久化；回滚到记录的原值。不要同时修改大量内核参数，否则难以判断是哪项改动产生了影响。
八、修复后怎么确认没有遗漏？
用故障出现时的同一域名、出口和访问方式复测，覆盖小响应、较大下载以及适用的上传场景。如果业务同时提供 IPv4 和 IPv6，分别检查；如果使用 HTTP/3，还要单独验证基于 UDP 的路径。
对于 CDN 网站，应分开记录“客户端到边缘节点”与“边缘节点到源站”的结果。源站本机 curl 正常，只验证了当次请求所走的路径，不能证明真实用户到 CDN 的链路正常。
保存接口/隧道 MTU、测试目标、时间、包长、连接现象和修改前后配置。确认连接持续有进展、没有反复卡住，并观察一个有代表性的业务周期；一次 ping 成功不足以结束排查。
常见问题
ping 不丢包，可以排除网络故障吗？
不能。默认的小型 ICMP 回显与 HTTPS 的协议、报文大小和路径处理可能不同，需要配合业务请求验证。
把 MTU 改成 1400 就能解决吗？
不保证。它可能让某条路径暂时恢复，也可能降低传输效率或造成新问题。应先确定封装开销和故障位置，再选择配置。
只在 TLS 握手时卡住，也是 MTU 吗？
可能，但证书链、TLS 策略、中间代理和丢包等因素也需要检查。应结合握手进展、包长对照和重传证据判断，不能只看浏览器报错文字。
只调整 MSS，HTTP/3 会一起恢复吗？
不会因此自动恢复。MSS 属于 TCP；HTTP/3 使用 QUIC/UDP，需要单独检查其路径和报文大小处理。
总结
遇到“ping 通但网站打不开”，先找出请求停在解析、连接、握手还是传输阶段。当小包正常、大包持续停滞，并且接口、隧道或地址族对照指向同一条路径时，再重点检查 PMTU 与反馈消息。
修复应落到可验证的配置上：校准 MTU、检查必要的 ICMP/PTB、按需评估 MSS 和 TCP 探测机制。记录原值、限制变更范围，并使用真实业务路径复测，才能知道问题是否得到解决。
参考资料
资料核验日期：2026 年 9 月 8 日。命令适用于相应工具可用的 Linux 环境，不同发行版和内核版本可能存在差异。本文未将示例命令或示意图作为 CloudFlew 的实测结果。
