间歇性网络故障排查实录：从光模块光功率到链路误码的完整复盘

1. 项目背景：一次让我差点放弃的间歇性网络故障

大概在一个多月前，公司内部陆续有同事反馈说网络"卡得不正常"，尤其是研发部和产品部的部分终端，表现非常诡异——不是说完全断网，而是每隔几分钟到十几分钟不等，网页打开突然变慢、SSH连接断掉、内网共享文件夹访问干脆转圈圈。最头疼的是，你刚跑过去准备排查，它又自己恢复了，现场怎么测试都是正常的，人一走故障又冒出来。

做运维的朋友都懂，这种间歇性故障是所有网络问题里最磨人的一种。相比彻底断网，它没有明确的"故障时刻"，你需要花大量时间蹲守、抓包、对比，才能从一堆正常数据里捞出那几条异常的。这次故障前前后后折腾了将近两周，中途我一度在项目群里打下"太复杂了没搞定"这几个字，后来咬着牙换了个排查思路才终于把问题按在地上摩擦了。

这篇文章不是讲什么高深理论的，就是把我这次踩过的坑、走过的弯路、最终定位问题的全过程复盘一遍。如果你的企业网络里也出现过"部分终端间歇性抽风"的情况，这篇文章应该能给你省下至少两三个通宵的时间。

2. 故障表象与初步判断：为什么"看起来很简单"却差点翻车

2.1 故障的具体表现与影响范围

先说故障的触发范围。并不是全公司所有电脑都有问题，主要集中在研发部（大概20多台终端）和产品部（10来台），其他部门偶尔有一两台零星中招。故障周期很不规律，通常在上午10点到下午4点这个工作时间段内出现得比较频繁，晚班人员基本没遇到过。这个时间规律让我一开始怀疑过是不是上网高峰期的带宽瓶颈，但很快被我排除了——公司出口带宽明明还有大量富余，流量监控上也没看到打满的情况。

具体表现可以分为三类，我列个表方便大家对照：

有几个同事被我拉来现场配合测试时，还出现过一种很诡异的状况：终端上ping内网网关是通的，ping外网IP（比如223.5.5.5）也是通的，但就是打不开网页。这种情况让我一度怀疑是DNS的问题，后来证明完全不是——因为内网IP的访问也不正常，所以问题出在更底层的地方。

2.2 我最初的排查方向与走过的弯路

刚开始排查的时候，我的思路很常规：先看接入层的交换机，再看核心设备，最后查出口。按照这个顺序，我先登录了研发部那台48口的接入交换机，看了CPU利用率、内存占用、端口错误计数，结果一切正常。端口上的CRC错误和丢包统计也没有异常增长，当时我还挺高兴，想着可能是个别终端网卡的问题。

于是我又回到终端侧。我把出问题的电脑挨个检查了一遍：网卡驱动更新到最新版本、电源管理里的"允许计算机关闭此设备以节约电源"取消勾选、检查是否有P2P下载软件在后台跑、查ARP表看有没有地址冲突。这一套操作做下来，花了两天时间，结果是——故障依然我行我素地出现，该卡的还是卡，该断的还是断。

这时候我才意识到问题的复杂性。因为故障终端不固定，今天这几台有问题，明天另外几台有问题，没有任何规律可循，怀疑终端本身有问题也站不住脚。我甚至把一台故障终端搬到自己的工位（换了一个完全不同的网口）测试，结果一整天都没有复现问题。这说明问题根本不在终端上，而是在这个终端所处的那条网络路径上的某个点。

2.3 为什么这类故障最难排查

这类间歇性网络故障最难的地方在于三件事：第一，无法稳定复现。你准备好抓包工具的时候，网络就已经恢复正常了，你得等下一次故障出现，而且不知道它什么时候会出现。第二，故障窗口时间太短。最长只有几分钟，最短只有十几秒，要用命令行工具定位问题根本来不及。第三，涉及链路环节多。从终端到接入交换机、再到汇聚、再到核心，任何一个环节出现偶发问题都可能表现为"部分终端间歇性故障"。

这也解释了为什么我前期一直在原地打转。如果你也遇到类似的情况，我的建议是别急着动手，先把排查策略想清楚。当时的我就是因为太着急了，才做了很多无用功。接下来我把后续真正有效的排查过程完整写出来，希望能帮你跳过那些坑。

3. 深入排查：从物理层到数据链路层的逐步剖析

3.1 物理层排查：网线、模块与端口的隐形故障

间歇性网络故障里，物理层的问题是很容易被忽视的。我这次排查的一个转折点，是有一天随手看了下接入交换机上的端口统计信息，发现有两个端口的"CRC对齐错误"和"RUNT帧"数量在持续缓慢增长。虽然增速不快，但与其他端口零错误的状态形成了鲜明对比。

CRC错误通常意味着物理层传输过程中出现了比特位错误。常见的诱因有几种：网线质量差或超过有效长度（超五类线建议不超过100米）、水晶头接触不良、端口或者网卡的光模块/电口老化。我当时的第一反应是检查这两条网线的两端：果然，其中一条线从工位走到地插的时候压在一个机柜底部的直角边下面，线皮已经被压得有些变形了。另一条线的问题更隐蔽——水晶头的弹片断了，只是靠摩擦卡在网口里，轻轻一碰就会出现瞬断。

当时我把这两条线都换掉之后，那两个口对应的终端确实消停了几天。但好景不长，其他终端又开始出现类似的故障。再查端口统计，错误并没有集中出现在某几个端口上，而是分散在不同端口。这说明物理层有局部问题，但绝不是根因所在。

这里我想给各位提个醒：排查物理层时，不仅要看网线本身，还要看配线架、信息模块、面板模块这几个地方。很多办公室为了美观，网线走的是墙内管道，从管道到面板模块的这段线是施工时压接的，如果施工工艺不过关，也存在偶发断连的风险。用福禄克测试仪跑一遍线缆认证当然是最稳妥的，但如果没有这个设备，至少可以用网线测试仪量一下线序和通断，也可以直接换一条已知没问题的成品跳线做A/B测试。

3.2 数据链路层排查：ARP表、MAC泛洪与二层环路

物理层没有解决根本问题，我把目光投向了二层。数据中心或者大一点的办公室里，二层环路是个老生常谈的问题。STP（生成树协议）虽然能防环路，但配置错误或者某些不支持STP的傻瓜交换机接入网络，就可能造成广播风暴，表现为整个广播域里的终端时好时坏。我登录核心交换机查看STP状态，没有发现端口反复切换的迹象，各个交换机的CPU利用率也都在正常范围内。

接着我查了ARP表。ARP是IP地址和MAC地址对应的"户口本"，正常情况下一台终端的IP应该对应唯一的MAC地址。但如果有终端被分配了重复的IP地址，或者有人手动配置了与其他设备相同的IP，ARP表中这个IP的MAC就会在两条记录之间来回漂移，网络自然也是时好时坏。我把故障时间段内核心交换机上的ARP表日志导出，用脚本筛选了重复的IP记录，确实找到过一个IP对应多个MAC的情况。但对比故障终端列表后发现，这两台终端并不是报障最集中的那批，所以IP冲突也只能算个例，不足以解释大面积问题。

二层问题上，我还特意检查了VLAN配置。有些规模大一点的办公网络会按部门划分VLAN，如果某个VLAN的网关配置或者Trunk链路有误，也会导致该VLAN内的终端间歇性断网。不过我们公司网络偏简单，一个网段打天下，所以VLAN这一层反而没什么可查的。

这里再补充一个我后来才知道的排查技巧：看二层问题最好的工具其实是日志和计数器。华三和华为的交换机都有比较完善的日志系统，可以在系统视图下开启debugging或者使用display logbuffer查看历史日志。如果发现某个端口频繁Up/Down，或者出现了"MAC address moving from port X to port Y"这种告警，基本可以锁定二层问题的方向了。我当时就是因为太多时间花在物理层，导致二层排查耽误了几天。

3.3 网络层排查：核心路由、网关与转发路径分析

二层没问题，我开始怀疑是不是核心设备本身有问题。我们公司的网络结构不复杂：接入交换机千兆上联到两台核心交换机（做了堆叠），核心通过防火墙连到运营商路由器。我登录核心交换机，检查了CPU和内存的利用率、路由表是否有异常波动、接口带宽有没有被打满。连续观察了小半天，各项指标都是健康的，连一个丢包都看不到。

随后我做了个关键的测试：在故障时间段内，从核心交换机上持续ping外网地址，连续跑了2000个包，结果是零丢包。从核心层面看，网络完全是正常的。那我怀疑的焦点就缩小到了"接入到核心"之间的链路，以及终端到接入交换机的这一段。

这里我需要解释一个概念：网络故障定位其实就是在做"分段排除法"。这就好比家里水管漏水，你不可能马上知道是楼下的主阀、楼道的分阀、还是自己家水龙头的问题，只能一段一段地关阀测试。网络排查也是一样的逻辑，从核心往外ping没问题，那就从终端往外ping，然后把问题锁定在"终端到核心"这一段。当时我让手下的工程师从报障终端上长ping网关和核心交换机的管理地址，同时让另一个人盯着核心交换机的接口统计。测试结果表明：终端到接入交换机这一段非常稳定，但终端到核心这一段时延波动明显。问题大概率出在接入交换机的上联，也就是这根千兆光纤链路上。

3.4 物理链路的"隐形杀手"：光模块与光纤衰耗

说到上联链路，就不得不提一个特别容易踩坑的地方：光纤和光模块。我们公司的接入交换机到核心走的是千兆光纤，光纤两端分别插了一个千兆光模块。光模块这东西，平时看着工作正常，但可能已经处于"亚健康"状态——光功率衰减严重、收发能力不稳定，导致流量一大就偶发丢包，流量小的时候又一切正常。

我当时做了一件事：登录接入交换机，查看上联端口的光模块信息，命令大概是这样的（不同厂商命令略有差异，我们用的是华三的设备）：

display transceiver interface GigabitEthernet 1/0/25 verbose

这条命令能看到的参数主要有这几个：

• 光功率（Tx Power / Rx Power）：发射光和接收光的功率。
• 温度（Temperature）：光模块的工作温度。
• 电压（Voltage）：模块供电电压。
• 偏置电流（Bias Current）：激光器的偏置电流。

正常来说，千兆多模光模块的接收光功率应该在-17dBm到-3dBm之间，低于-20dBm就意味着信号已经非常微弱了。而我看到的数值是多少呢？接收光功率稳定在-18.5dBm左右，在边缘徘徊。当时我还没有完全确定是这里的问题，因为这个光功率虽然不理想，但也没到完全不通的程度。直到后来我查到一条关于"error on input"的计数器持续增长，才确认这根光纤链路确实存在严重的误码问题。

误码这个东西很阴险。误码率低的时候，网络基本不受影响；一旦误码率累积到一定程度，数据帧校验失败，就会被协议栈静默丢弃，表现出来就是"间歇性丢包→TCP重传→应用卡顿"。而且因为误码率不稳定，所以故障也是时有时无。这完美地解释了为什么我们前面做的各种测试有时候正常、有时候异常。

3.5 光模块更换实操：一次立竿见影的修复

确定了问题方向之后，修复操作其实很简单：更换光模块和光纤跳线。由于是工作日白天，不能长时间中断业务，我选择了在午休时间操作，提前准备好了备用的光模块（同样规格的千兆多模模块）和一根新的LC-LC多模跳线。

具体的操作步骤是这样的：

1. 提前在交换机上查看上联端口是哪个（本例中是GigabitEthernet 1/0/25），确认对端也是同一个接口。
2. 写好配置备份和回滚预案：`

display current-configuration interface GigabitEthernet 1/0/25 save

3. 通知网络受影响范围内的同事，告知会有1-2分钟的网络中断。
4. 将端口shutdown，并在线拔出旧光模块和光纤跳线：

system-view interface GigabitEthernet 1/0/25 shutdown

5. 换上新的光模块和跳线，重新插好，undo shutdown恢复端口：

undo shutdown quit save

6. 再次执行display transceiver interface GigabitEthernet 1/0/25 verbose，确认光功率恢复到了正常范围。

更换完成之后，接收光功率从-18.5dBm恢复到了-7.2dBm，整整提升了11个dB，效果立竿见影。当天下午直到下班，报障数量骤降为零。这里有个小技巧要分享给大家：操作之前一定要先拍照记录旧模块的插拔方向，光模块是分收发方向的，插反了光纤虽然也能插进去，但链路就是不通，到时候排查起来又是一通折腾。

4. 工具选型与终端命令行实践：排障过程中最好用的几个工具

4.1 ping和mtr：快速判断故障区间的基础工具

排查网络故障，有几个命令行工具是绕不开的。很多新手喜欢一上来就用一大堆复杂工具，但我的经验是，先把基础的玩透，很多问题就已经能解决了。工具在精不在多。

ping就不用多说了，它用的是ICMP协议，能帮你快速判断目标主机是否可达、时延大致多少。但ping有一个局限性：它的统计比较粗糙，尤其是短时间的ping，很难看出间歇性的丢包规律。所以我会建议用一个长ping + 时间戳的方式，把结果记录到文件里，后面分析故障时间段时特别有用。

ping -c 1000 -i 0.2 192.168.1.1 | tee ping_result.txt

mtr（My TraceRoute）是我个人特别偏爱的一个工具，它结合了ping和traceroute的功能，能持续显示从你本机到目标地址整条链路上每一跳的丢包率和时延。它最大的价值是：如果丢包只出现在中间某几跳，而后面几跳又恢复正常，基本可以判断是路径上某个节点的问题；如果从某一跳开始持续丢包一直到终点，那问题点很可能就在这一跳。

使用的时候一条命令就够了：

mtr -n -r -c 100 8.8.8.8

-n表示不做反向DNS解析，-r是report模式（输出一次完整报告后退出），-c指定发包数。不过这里要提醒一句：如果在办公网环境里，mtr的输出会经过核心设备、防火墙等多个节点，部分节点的ICMP限速可能导致误报，需要结合内网具体环境判断。

4.2 Wireshark抓包分析：间歇性故障的"照妖镜"

如果说ping和mtr是在"盲人摸象"，那么抓包分析就是让你亲眼看到数据包在网络上的流转过程。遇到间歇性故障，Wireshark绝对是定位问题的大杀器。

不过抓包这件事，时机很重要。因为故障是不定时出现的，如果你只抓个一两分钟，很可能什么也抓不到。我的做法是：选几台频繁出问题的终端，在它们上面启动Wireshark，设置一个合适的抓包过滤器，让它在后台持续抓取，如果存储空间足够的话，我建议抓满一整个工作时间段，比如6-8个小时。抓到之后再看故障时间段对应的数据包。

抓包过滤器的设置可以参考这个：

icmp or tcp.port == 80 or tcp.port == 443 or arp

这个过滤器会把ICMP、HTTP/HTTPS和ARP协议的数据包都录下来。为什么要抓ARP？因为前面提到过，ARP表漂移和二层问题是间歇性故障的常见诱因，抓下来方便一起分析。

抓包完成后的分析重点有几个：

• 看TCP重传的比例。如果大量TCP包出现快速重传或超时重传，说明网络存在丢包。
• 看TCP窗口是否经常缩为0。这个现象说明接收方的缓冲区满了，可能和网络拥塞或中间设备缓存不足有关。
• 看是否出现DUP ACK。连续三个重复ACK说明网络可能出现了乱序丢包。

在本次故障中，我当时在其中一台故障终端上跑了大概4个小时的抓包，抓到故障发生时段，发现TCP重传率明显偏高，而且有很多"TCP Previous segment lost"的提示。结合后面的光模块问题，可以确定这就是因为链路误码导致数据帧在传输过程中损坏，TCP层被迫反复重传，从而引发应用层的卡顿和连接中断。可以说，抓包是最终确定光模块问题的关键依据之一。

4.3 终端工具使用心得：tabby、多个窗口与高效排查姿势

排障工作往往需要同时登录好几台设备——核心交换机开一个窗口、接入交换机开一个窗口、某台终端再开一个窗口。用系统自带的终端工具开多个标签页不是不行，但窗口一多管理起来就很乱。这里推荐一个我在实际排障中高频使用的终端工具：Tabby（一个基于Web技术的开源终端模拟器）。它同时支持Windows、macOS和Linux，能保存SSH会话、支持SFTP传输，而且界面很干净，还可以随意调整配色主题。

它的核心用法其实很简单：

1. 安装后，在设置里配置SSH连接信息，把公司常用的几台交换机和服务器都保存下来。
2. 需要并发操作时，可以用它的"Split Pane"功能，把终端窗口分成上下或者左右多个面板，同时监控多台设备的日志或ping结果。

不过这里我想说一句：工具再高效，也得靠人脑判断。Tabby只是帮我把多台设备的窗口整理得清爽了，让我能在同一个屏幕上盯着多个会话的输出，不用来回切换窗口。如果你手头没有这类工具，用Windows Terminal或者纯命令行终端开几个标签页也完全够用，重点是思路清晰。

4.4 Linux终端操作技巧：查看日志、杀进程与网络排查常用命令

这次排查因为涉及部分Linux服务器（公司的GitLab和Jira装在内网的CentOS机器上），我也经常要跑一些Linux命令。这里把我在处理"网络故障"时常用的Linux终端命令整理一下，对不熟悉Linux终端的朋友应该会有帮助。

查看系统网络配置和连通性：

# 查看网卡信息 ip addr show # 查看路由表 ip route # 查看ARP缓存 ip neigh show

查看历史登录记录和会话——排查是否有人误操作：

last who w

查看系统日志里和网络相关的报错：

# 查看系统日志尾部，带关键字过滤 journalctl -f | grep -i network # 查看网卡是否报错 dmesg | grep -i eth

有一件事值得单独提出来：排查故障期间，我在一台机器上跑过一个脚本，持续每隔5秒把网络连接数打个快照，看有没有异常进程在大量建连。如果你的服务器也在间歇性出问题，可以这样操作：

# 每5秒输出当前TCP连接数，按状态分组 while true; do ss -ant | awk 'NR>1{print $1}' | sort | uniq -c; sleep 5; done

如果发现SYN_SENT状态的连接特别多，说明可能有外部连接无法建立或者半连接队列溢出；如果ESTABLISHED连接数异常大，可能存在异常流量。这种排查方式不起眼，但在很多场景下真的能救命。

5. 从实战中总结：间歇性网络故障排查的标准作业流程

5.1 一套我验证过的排障思路

踩了这么多坑之后，我渐渐梳理出了一套针对"部分终端间歇性网络故障"的排障流程。不敢说放之四海而皆准，但至少在我这次的案例里，如果一开始就按这个流程走，大概率能少花一半时间。

整个流程的核心可以概括为四句话：

1. 先看现象，不要急着换设备。搞清楚故障只在某些终端出现、还是所有终端都会出现；是内网访问故障、还是外网访问故障；故障是固定时间出现、还是随机出现。把这些信息整理清楚，再决定下一步。

2. 按链路分段测试，缩小故障范围。从终端ping网关、ping核心、ping出口、ping外网，逐条链路ping过去，看丢包和延迟出现在哪一段。也可以用mtr观察全路径。这一步能快速区分问题出在"终端本身""接入链路""核心转发"还是"出口线路"。

3. 重点检查物理层和二层。如果故障段锁定在接入层，优先排查物理层（网线、模块、端口）和二层（ARP、VLAN、STP）。尤其是光模块的光功率、端口错误计数、ARP表是否漂移，这些都是低成本就能查的。

4. 必要时抓包定位。当网络设备的计数器、日志都没有明确指向时，不要犹豫，直接抓包。抓包是最接近事实真相的手段，它能告诉你数据包到底是在哪一层、以什么方式被丢弃的。

5.2 排查工单节点表：像追剧一样逐集排障

前面光说流程，可能不够直观。我准备做一个"排障工单节点表"，把这次实战中每一个关键步骤、使用的命令、观察到的现象和得出的结论填进去，你可以直接对照着用。

这张表我建议每个做网络运维的朋友都存一份。很多人排障的时候喜欢凭感觉东看西看，最后时间花了，问题还没定位。做一张表格，把每一步的输入输出都记录下来，不仅能帮自己理清思路，汇报给领导的时候也更有说服力——到底哪一个环节出了问题、你做了哪些验证、结论是什么，一目了然。

5.3 故障复盘要做的三件事

故障修复只是第一步，真正的"收尾工作"是复盘。我当年刚干这行的时候，前辈就跟我讲："网络故障不可怕，可怕的是同样的故障犯了两次。"所以这次修完光模块之后，我还做了几件沉淀的事情：

第一，把所有接入交换机的光模块光功率都巡检了一遍。凡是接收光功率低于-15dBm的模块，都列入了重点观察名单，并购买了几个备用模块放在机房里备用。顺便设置了一个每周自动巡检的脚本，通过SNMP协议定时拉取光模块数据，低于阈值就直接告警。

第二，把接入层交换机的端口错误计数监控加上了。之前只看了CPU和内存，忽略了端口层面的错误。现在监控系统每个小时会自动检查一次所有端口的CRC错误、丢包计数，一旦有异常增长就会生成告警事件，避免类似问题再次"潜伏"。

第三，更新了网络拓扑文档和排障手册。把这次排查的经验、用到的命令、判断标准都整理成了一个内部文档，分享给了团队的同事。后来有一次其他分部也遇到了类似的问题，同事照着这个手册排查，半天就锁定了光模块故障。

6. 常见问题速查与避坑指南

6.1 间歇性故障排查中的常见问题

把这次排障过程中的经验压缩一下，我整理了一批"既是问题也可能是答案"的速查表，希望对你有用。

6.2 我在光模块问题上踩过的坑，希望你不用再踩

关于光模块和光纤链路，这里有几个特别容易被忽略的坑，我挨个说一下吧。

第一个坑是"光功率正常不等于链路没问题"。我见过不少运维同行检查光模块，只看收发光功率在正常范围就觉得没问题了。实际上，光模块还有一个重要指标是偏置电流（Bias Current）。这个值如果异常升高，说明激光器正在老化，即使当前光功率还能维持在正常范围，随时可能"猝死"。所以查看光模块状态的时候，一定要把偏置电流也列入检查项。

第二个坑是"光纤跳线弯曲半径过小"。光纤虽然可以弯曲，但过度弯折会导致光信号衰减加剧。我见过有人为了走线好看，把光纤跳线绕成一个小圈绑起来，这种做法对单模光纤的影响尤其明显。更换跳线的时候，最好选择长度合适的，避免多余的线缠绕在机柜里。

第三个坑是"光模块和光纤类型不匹配"。多模光纤要用多模模块，单模光纤要用单模模块，接反了虽然偶尔也能通，但距离一长或者速率一高就会出问题。之前遇到过有同事把一对单模模块插到多模光纤上，结果光功率低到-25dBm，链路时通时断。还有，光模块的接口类型也要注意，LC、SC、ST这些接口外形不同，千万别插错。

6.3 关于"间歇性故障"的几条原则性经验

最后写几条原则性经验，算是我送给各位同行的一句话心得：

1. 现场复现不了的问题，不要轻易下"已解决"的结论。像这种间歇性故障，可能你今天换了网线、明天换了模块，其实其中一项确实解决了大部分问题，但如果不持续观测两三天，你根本不知道是否真的有其他隐藏问题。

2. 排查时不要同时更换多个变量。很多人修网络喜欢"顺手"把光模块换了、把网线也换了、把交换机端口也换到另一个口上，最后问题确实好了，但到底是谁治好的，谁也不知道。下次再出问题时，你还是得从头开始排查。正确的做法是每次只动一个变量，验证生效后再动下一个。

3. 维护好你的监控工具。没有监控的网络运维就像闭着眼睛开车。SNMP、日志采集、端口状态监控、光功率监控……这些工具平时看着不起眼，但真正的排障效率差距，恰恰是在这些"不起眼"的日常积累中拉开的。

7. 写在最后的个人体会

这次故障从接手到彻底解决，前前后后大约用了两周，中间我一度真的想放弃了。现在回头看，问题本身并不复杂，就是一个被忽视的光模块光功率衰减，再加上链路误码引发的连锁反应。但是"不复杂"三个字，是站在已经知道答案的角度说的。在不知道答案的时候，每一个环节看起来都正常，每一段链路测起来都通，这种"一切正常"本身就是最折磨人的地方。

我个人的体会是，做网络运维，心态往往比技术更关键。遇到这种故障，不能急着一口气吃成胖子，也不能因为一两次测试正常就放松警惕。把链路一段一段拆开，把问题一层一层剥掉，该抓包就抓包，该换设备就换设备，每一步都留下记录和证据，最后答案自然会浮出来。

如果你正在为类似的间歇性网络故障焦头烂额，希望这篇文章能帮你少走一些弯路。如果最后你也遇到了测了半天全都正常的情况，别崩溃，那不是你的问题——是你离真相还差最后一步。回去看看光模块，看看光纤跳线，看看端口计数器，答案往往就藏在这些最不起眼的角落里。