wa6520业务异常

你描述的这个现象非常典型：ICMP（ping）和TCP连接（telnet）正常，但上层应用（HTTP等）失败，同时伴随大量TCP重传。这通常意味着无线链路上存在丢包或乱序，导致TCP协议栈因为收不到预期的ACK确认包而不断重传，最终连接超时。

 根本原因分析

• ping正常：说明网络层（IP）连通性和路径MTU基本没问题，小包能通。

• telnet端口通：说明TCP三次握手可以完成，连接能建立。

• HTTP访问失败+大量TCP重传：说明在传输实际数据（大包或连续数据流）时发生了丢包。无线环境下的干扰、信号波动、速率协商问题，都可能导致数据帧丢失，触发TCP重传。

排查步骤建议

你可以按照从易到难的顺序逐一尝试：

1. 检查无线环境与信号质量

这是WA6520这类AP最常见的问题源头：

• 查看信号强度：在终端上检查连接WA6520的信号强度（RSSI），如果低于-65dBm，建议调整AP位置或减少障碍物。

• 排查无线干扰：登录AP或AC，用display wlan radio all查看信道利用率。如果利用率过高（>50%），尝试更换信道（手动指定一个干净的信道，避免自动选择）。

• 调整速率和频宽：

  • 禁用低速率（如1Mbps、2Mbps），避免无效数据占用空口资源。

  • 如果环境干扰较大，尝试将频宽从80MHz降为40MHz，提高抗干扰能力。

2. 核查QoS配置

检查AP或AC上是否配置了QoS策略，可能误将Web服务的流量优先级降低了。确保Web服务器的流量没有被限速或标记为低优先级。

3. 检查防火墙和安全策略

确认WA6520（或上联的AC/防火墙）上没有配置策略阻止终端访问Web服务器的特定端口或协议。虽然telnet通，但HTTP（80/443）可能被单独拦截。

4. 分析抓包文件精确定位

既然已经抓包，可以进一步分析：

• 查看重传包的源地址：是终端发起的还是服务器发起的？如果是服务器发起的重传，说明下行丢包；如果是终端发起的，说明上行丢包。

• 检查丢包点：在AP的有线口也抓包，对比无线侧和有线侧的流量，可以判断丢包是发生在无线段还是有线段。

5. 尝试调整转发模式（进阶）

有案例表明，将AP从集中转发改为本地转发可能改善无线传输质量。这是因为集中转发模式下，所有流量都要经过AC，增加了一跳路径。如果你的组网支持，可以在AC上修改AP的转发策略为本地转发，然后观察问题是否缓解。