PPPoE拨号后，普通小网页能打开，但登录页、图片、大文件或代理连接加载到一半就卡住；尤其软路由上又叠加VPN或隧道时，应考虑路径MTU和TCP MSS问题。PPPoE会增加封装开销，隧道再增加一层头部，实际可承载的数据包可能小于以太网常见的1500字节。
但“页面卡住”并不自动等于MTU问题。DNS、丢包、代理节点、TLS、目标服务和缓存都可能造成类似表现，需要通过包大小与协议阶段对照。
MTU、MSS和PMTUD分别是什么
| 概念 | 含义 | 与故障的关系 |
|---|---|---|
| MTU | 接口一次可承载的最大IP包大小 | 超过路径能力的包需分片或丢弃 |
| TCP MSS | TCP连接声明愿意接收的最大数据段 | 通常根据MTU扣除IP与TCP头计算 |
| PMTUD | 路径MTU发现机制 | 依赖ICMP等反馈获知需要缩小包 |
| MSS Clamping | 路由设备改写TCP SYN中的MSS | 帮助TCP避免发送过大的数据段 |
IPv4可以分片，但现代网络更依赖路径MTU发现；IPv6中路由器不会替发送端分片。若“Packet Too Big”或“需要分片”类ICMP被错误拦截，就可能出现PMTU黑洞：小包通过，大包无声丢弃。
为什么小网页正常、大内容卡住
DNS、TCP握手和小型HTTP响应的数据包较小，可能顺利通过。TLS证书链、图片、上传或下载会产生更大的连续数据，超过路径MTU后丢包，发送端又收不到正确反馈，于是不断重传，看起来像页面加载一半。
某些站点正常、某些站点异常，也可能因为目标路径、CDN、TLS证书大小和协议不同。
PPPoE和隧道会增加多少开销
PPPoE常让可用MTU低于普通1500字节以太网，具体取决于运营商是否支持更大底层帧；VPN、GRE、WireGuard、IPsec、代理隧道和VLAN又各有不同开销。不能从一篇教程复制固定MTU数值适用于所有环境。
应从设备当前WAN、隧道和运营商文档获取起点，再通过可复现测试逐步验证。
Windows和Linux怎样做禁止分片测试
在自有或允许ICMP的目标上，Windows IPv4可使用类似：
ping 目标地址 -f -l 1400Linux常见命令参数因实现而异，可查看本机 ping --help，使用禁止分片/路径发现选项逐步调整载荷。测试值是ICMP载荷，不等于完整IP包大小，需要加上IP与ICMP头部。
目标可能限制ICMP，因此ping失败只能作为线索。还要结合HTTPS下载、TLS和抓包。
一套可靠的定位流程
- 建立直连对照。不走代理或额外隧道时测试同一站点和大文件，记录是否正常。
- 记录接口MTU。查看PPPoE WAN、LAN、隧道和虚拟网卡当前值，不先修改。
- 做包大小测试。从较小载荷逐步增加，记录在哪个范围开始失败以及ICMP反馈。
- 观察TLS阶段。确认卡在CONNECT、TLS握手、首字节还是正文传输。
- 查看重传与ICMP。在自有网络抓包，判断大包重传、Packet Too Big或Fragmentation Needed是否出现。
- 小幅调整并单次验证。按设备文档调整MTU或MSS，每次只改一项，出现恶化立即回退。
什么时候使用MSS Clamping
TCP流量经过MTU较小的PPPoE或隧道时，路由器可在SYN阶段将MSS限制到安全值，让端点从一开始发送较小TCP段。它只影响TCP，不修复UDP、ICMP或所有IPv6问题。
如果路径MTU发现本来正常，盲目设置过低MSS会增加包数量、降低效率。应根据实际接口和路径动态计算或采用系统推荐规则，而不是硬编码陌生数值。
UDP和QUIC还需要单独处理
浏览器HTTP/3、游戏和实时通信使用UDP，不读取TCP MSS。TCP网页修复后，UDP仍可能因MTU或分片失败。分别测试HTTP/2与HTTP/3、IPv4与IPv6，明确代理是否支持UDP。
常见误区
- 把所有网页慢都归因于MTU，却不看丢包和目标服务；
- 只改LAN MTU，实际瓶颈在PPPoE或隧道接口；
- 永久阻断所有ICMP，破坏PMTUD；
- 用ping通证明HTTPS大包一定正常；
- 一次把MTU降得很低，导致性能下降却没有基线；
- 只修IPv4，不检查IPv6 Packet Too Big。
调整后的验收
用小网页、登录、证书较大的HTTPS站点、上传、下载和长连接分别测试，记录TLS握手、吞吐、重传、IPv4/IPv6和代理出口。观察一段时间，确保不是偶然恢复。
需要路由、测速和网络工具时，可从极跃圈网址导航选择。排查记录应保留原MTU、每次改动、可通过的最大载荷、ICMP反馈和业务结果，才能证明调整有效。
