有一种故障很怪：网页能打开，但图片加载不出来；小文件能下载，大文件一定失败；某些站点干脆连不上，另一些完全正常。
这通常不是带宽问题，是 MTU 不匹配——数据包超过链路能承受的大小，被丢弃或者未能正确分片。
为什么会不匹配
以太网的标准 MTU 是 1500 字节。但走隧道（代理、VPN、PPPoE）时会额外加封装头，实际可用空间变小，比如变成 1400 或 1450。
如果两端没协商好，小包能过、大包被丢，就出现"能连上但加载不全"。
更麻烦的是 PMTUD（路径 MTU 发现）依赖 ICMP 报文。很多网络会屏蔽 ICMP，导致发送方永远收不到"包太大"的通知，于是一直重传、一直失败。
怎么测
Linux
# 逐步加大包大小，找到能通过的最大值
ping -M do -s 1472 -c 2 example.com
ping -M do -s 1400 -c 2 example.commacOS
ping -D -s 1472 -c 2 example.comWindows
ping -f -l 1472 example.com从 1472 开始每次减 20，第一个能通的数字加上 28（IP 头 20 + ICMP 头 8）就是这个链路的 MTU。
注意：-s 的值要加上 28 才是 MTU。1472 + 28 = 1500。
两种处理方式
方式一：调 MSS（推荐）
不改本机 MTU，而是在链路上做 MSS clamp，让 TCP 协商时把最大段大小降下来。这样既解决问题，又不影响局域网内其他流量。
路由器上通常是类似 TCPMSS --clamp-mss-to-pmtu 的规则。
方式二：降本机 MTU
# Linux
ip link set dev eth0 mtu 1400
# macOS
sudo ifconfig en0 mtu 1400
# Windows（管理员）
netsh interface ipv4 set subinterface "以太网" mtu=1400 store=persistent改完重启网络或重新连接。缺点是要逐台改，且换网络环境可能要改回来。
判断特征
| 现象 | 是不是 MTU 问题 |
|---|---|
| 小页面正常，大页面加载一半 | 很可能是 |
| 能 ping 通，但 HTTPS 握手卡住 | 很可能（ServerHello 包较大） |
| 所有网站都打不开 | 一般不是 |
| 下载小文件正常，大文件必挂 | 是 |
一个快速验证
把 MTU 临时降到 1400，再访问原来打不开的站点。如果恢复正常，基本可以确诊。
反过来，如果降到 1200 还是不行，那就不是 MTU 问题，回去查 DNS 和 TCP。
💡 经验值：PPPoE 拨号通常是 1492，常见隧道是 1400–1450，移动网络有时低到 1280。遇到"打不开某些站"先试 1400，能解决八成。
延伸阅读：四层连通性自检、延迟怎么测才准、TUN 模式和系统代理。