能 ping 通但网页打不开的解法
在拨号、隧道或地址转换出口下，TCP 三次握手可以完成，但传输大报文时被中间链路或设备丢弃，现象就是能 ping 通小包、网页打不开或大文件传不动。这类问题的标准解法是在出口接口上调整 TCP 报文长度参数，把协商出来的报文段限制在链路可用范围内：接口会改写经过的 TCP 握手中的长度协商字段，从源头避免大包被丢。
基本信息
| 适用平台 | 三厂出口接口，包括物理接口与拨号、隧道逻辑接口 |
|---|---|
| 作用范围 | 只改写经过该接口的 TCP 连接协商参数，不影响其他协议 |
| 常用取值 | 拨号链路常从 1452 起算，叠加隧道后按层次递减 |
| 生效方式 | 握手阶段协商生效，已建立的连接需要重新建立才受新参数影响 |
| 核对命令 | 查看接口当前配置中的相关参数 |
典型使用场景
- 拨号出口网页打不开、下载卡住，小包却正常
- VPN 隧道内访问内网应用异常，表现为登录页面打不开
- 跨运营商链路访问特定站点失败，本地网络其他站点正常
- 割接后新增隧道或封装导致大包被丢，业务部分不可用
- 排查疑似 MTU 问题时作为快速验证手段
华为 VRP
华为 VRP
interface Dialer1
tcp mss 1200 # 按线路可用报文长度减去协议开销计算
display current-configuration interface Dialer1 | include mss
! 改动后重新发起连接才会生效，旧连接不受影响思科 IOS
思科 IOS
interface Dialer1
ip tcp adjust-mss 1400 # 改写经过该接口的 TCP 协商参数
show running-config interface Dialer1 | include adjust-mss
! 只作用于穿越该接口的流量，不影响设备自身发起的连接H3C Comware
H3C Comware
interface Dialer1
tcp mss 1280
display current-configuration interface Dialer1
! 改动后重新建立连接验证效果参数估算与三厂写法
| 链路类型 | 估算方式 | 三厂命令 |
|---|---|---|
| 拨号链路 | 在可用报文长度基础上减去封装开销 | 华为与 H3C 用 tcp mss，思科用 ip tcp adjust-mss |
| 隧道叠加 | 每增加一层封装再按开销递减 | 命令位置放在承载隧道的接口上 |
| 互联网出口 | 按运营商链路的实际可用长度确认 | 先取保守值验证，再逐步调整 |
| 二层专线 | 长距链路通常无需调整 | 确有丢大包现象时再调整并验证 |
排查与验证要点
- 先用大包测试确认问题方向：用不分片的探测方式发大包，失败而小包成功即可初步定位
- 参数取保守值先验证可用性，再根据实际吞吐逐步调整，避免一次调到最优值导致反复
- 改动后要重新发起连接：已建立的会话沿用旧参数，测试必须新建连接
- 只对 TCP 生效：UDP 与 ICMP 的大包问题需要调整接口报文长度或排查中间设备
- 同一条路径上多层封装时，命令放在最外层的承载接口上更可靠
常见疑问
- 为什么改了没生效：旧连接仍用旧参数，需要断开重建会话再测
- 会不会影响性能：参数偏小时会增加报文数量，轻微影响吞吐，但换来确定可用
- UDP 大包丢怎么办：调整接口层面的报文长度或排查中间设备的处理策略
- 需要每台设备都改吗：只在报文被丢弃或需要改写的那个出口接口上配置即可
这类问题的典型特征是握手成功但数据传输中断：ping 用小包能通，浏览器打开页面时卡住，业务系统登录页面无法加载，容易误判为应用或服务器问题。
调整参数是治标手段，能立刻恢复业务；同时值得追查根因，例如隧道封装开销、链路协商异常或中间设备对分片的处理策略，避免同类问题在其他路径上重复出现。