网络状态显示"已连接"，实际却在半双工模式下苟延残喘

某个据点的网络连接质量一直不太稳定，表现为间歇性访问缓慢、连接超时，但从来没有真正意义上的完全断线——链路状态一直显示”已连接”。这类”时好时坏、但从不彻底坏掉”的症状，恰好是最难排查的一类：完全断线容易被立刻发现，而这种半死不活的状态，往往会被归咎为”网络就是不太稳定”，然后被搁置。

先排除最直接的怀疑对象

按常规思路，先尝试了最简单的处理方式——重启防火墙设备。症状确实会短暂缓解，但过一段时间又会复发，说明这不是一次性的偶发故障，背后有一个持续存在、没有被解决的根因。

换一个角度：不看”通不通”，看”质量好不好”

网络链路”看起来通”和”实际工作正常”之间，其实还有一层经常被忽略的检查：以太网的速率和双工模式是否匹配。如果链路两端协商出的双工模式不一致（一端全双工、一端半双工），连接依然可以建立、状态依然显示正常，但半双工模式下无法同时收发数据，一旦流量稍大就会开始出现冲突（collision），引发大量重传，表现出来就是间歇性变慢、偶发超时——这正好和本例的症状完全吻合。

用防火墙自带的硬件诊断命令，直接查看对应网络接口的实际协商状态：

get hardware nic wan1

结果显示这个接口的协商结果是速率 100M、双工模式 Half（半双工）——问题就出在这里。

“已连接”这三个字，只保证链路建立了，不保证它工作得体面

修复

手动进入接口配置，把速率和双工模式从自动协商强制指定为100M 全双工：

conf sys int
edit wan1
set speed 100full

手动指定之后，链路两端不再需要通过自动协商去猜测对方的能力，间歇性变慢和超时的症状随之消失。

教训

1. “连接状态正常”和”连接质量正常”是两个不同层级的判断，链路状态灯或状态显示只能回答前一个问题——真正影响体验的很多问题，都发生在”已连接”这个大前提成立之后，光看链路状态无法发现；
2. 自动协商（Auto-Negotiation）在双方设备型号、驱动、线缆质量存在差异时，有一定概率协商出不匹配的速率或双工模式——这类协商失败通常不会被记录为”错误”，因为链路确实建立了，只是效率打了折扣，容易被长期忽略；
3. 排查”时好时坏、但从不彻底坏”的网络问题时，除了检查上层的路由、防火墙策略，也值得往物理层/链路层的协商结果查一次——本例的根因既不在路由表，也不在安全策略，而是在最底层、最容易被跳过检查的双工模式设置上。