陈振玥这次要记录的断网问题，是我这两年遇到的最诡异的一次。故障从表面看非常常规：办公室网络不定时中断，重启光猫就好，但过上几个小时又会再犯。真正排查起来才发现，既不是路由器配置问题，也不是线路物理断开，运营商上门测光功率也完全正常。那段时间我一度怀疑自己的排查基本功是不是退步了。如果你也遇到过“设备指示灯全正常，网却莫名断了”的情况，这篇记录应该能帮你少走好几天的弯路。
1. 先说结论：这不是一次普通的“重启就好”的断网
1.1 故障现场与基础拓扑
先说下现场环境。办公室面积不大，大约三十平米，网络拓扑也非常基础：运营商入户光纤接一台GPON光猫，光猫设置为桥接模式，LAN1口出来接一台x86软路由负责PPPoE拨号，软路由再往下接一台8口千兆交换机，交换机上挂着NAS、两台台式机，另外还有两个无线AP给手机和笔记本提供Wi-Fi。
这套网络稳定跑了差不多两年，平时很少出问题。故障是在六月中旬开始出现的，刚开始频率很低，两三天才犯一次，到后面越来越频繁，几乎每天下午都会断一回。最让人头疼的是，断网的时间点没有明显规律：有时候是下午三点，有时候是晚上八点，完全没有周期性。
故障出现时的表现倒是很“标准”：电脑上所有网页打不开，微信的图片加载不出来，但局域网内访问NAS、打印机完全正常，软路由的管理页面也可以正常登录。手机连Wi-Fi同样上不了外网，但内网设备之间互相 ping 都通。
1.2 三个自相矛盾的现象
最能说明问题不简单的地方，在于几个现象放在一起是自相矛盾的。我整理成了一张表：
| 故障现象 | 表面判断 | 实际矛盾点 |
|---|---|---|
| 软路由WAN口显示已连接，公网IP正常 | 说明拨号链路没断 | 但出网流量几乎为0，所有外网请求全部超时 |
| 光猫PON指示灯常亮，没有LOS告警 | 说明光路在线 | 但数据转发就是不正常，远程查光猫状态也是在线 |
| 重启光猫后立即恢复 | 像是设备死机 | 但过几个小时必复发，且故障期间CPU/内存占用都不高 |
这三个现象放在一起，基本可以得出一个反直觉的结论：问题不在“网线有没有连通”，而在“数据到底有没有被正确转发”。线路上看起来一切正常，实际上数据流转已经出了偏差。这就是为什么按常规思路排查，很容易被带到沟里去。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 排查过程：从软件到硬件，一次彻底的推倒重来
2.1 常规三板斧全试了一遍
遇到这类间歇性故障，我的第一反应还是先做常规操作。毕竟多数情况下，断网问题翻来覆去就是那几个原因：路由器死机、网线接触不良、DNS配置错误、ARP攻击。所以一开始我也按这个顺序来。
首先是重启软路由，拔电等一分钟再插上，结果没用，故障依旧。接着换网线，把光猫LAN1口到软路由WAN口之间的成品网线换成另一根，也没用。然后我又试过在电脑上手动把DNS改成公共DNS地址，例如 223.5.5.5 和 119.29.29.29，依然无法打开网页。为了排除路由器固件的问题，我甚至把软路由暂时换回原来的华硕家用路由器，用同样的PPPoE账号拨号，结果到了故障时间点照样断。
到这里基本可以排除终端设备、网线、DNS和路由器固件的因素。但有一个有意思的细节：故障期间在软路由上直接 ping 内网网关，延迟正常；ping 外部IP，比如 223.5.5.5，完全不通。这说明内网二层通信没问题，问题出在往上走的这一段。
2.2 抓包定位：请求出去了，响应没回来
常规手段排除得差不多以后，我决定上抓包工具。在软路由上用 tcpdump 直接抓WAN口流量，命令很简单：
bash复制tcpdump -i eth0 -nn 'icmp or tcp port 443' -c 2000
正常时段抓到的包是双向的：既有内网设备发出去的SYN请求，也有公网服务器回过来的SYN-ACK响应。但故障时段再抓，特征非常明显——内网设备不停地发SYN包出去，一遍又一遍地重传，而外部服务器的响应几乎一个都看不到。ping外网IP也是一样的现象：ICMP request 一直在发，reply 始终没回来。
这里我用 Wireshark 看抓包结果时，重点看了两个过滤器：
text复制tcp.analysis.retransmission
icmp
结果是非常典型的“有去无回”。也就是说，数据包从软路由WAN口出去是没有问题的，软路由已经把请求交给了上游，但上游没有任何应答。问题区间被锁定在软路由WAN口往上，直到运营商侧的某一段链路。
2.3 差点被误导的“内网风暴”
排查到这里的时候，我一度被另一个现象带偏了。因为办公室的交换机是一台可网管千兆交换机，我在故障期间顺手登录上去查端口统计，发现两个信息：一是某个端口的广播包数量暴涨，二是接口上有不少CRC错误和FCS错误。日志里甚至出现过“broadcast storm”相关的提示。
当时我的第一反应是：坏了，这是二层环路。环形拓扑一旦出现，广播帧会在交换机之间无限循环，轻则网速骤降，重则整个网络瘫痪。而且这个故障现象确实很像——外网全断、内网互通正常、广播包激增。
于是我开始排查可能存在的环路。把交换机下面每个设备都过了一遍，查了所有网线的接法，确认没有一根线会形成物理环路。又检查了STP生成树状态，各端口都正常，没有出现端口被Block的情况。折腾了一个多小时，什么都没发现。
后来冷静下来重新看数据，才发现广播包暴涨是结果而不是原因。当WAN口数据不通时，各种网络协议会反复重传，试图恢复会话，这本身就会在二层产生大量广播和组播报文。真正的根因，还是在那条“有去无回”的上行链路上。交换机上的CRC错误，反倒是一个重要的物理层线索，当时差点被当成灵异事件放过去了。
3. 真相：光猫的“光模块误码”才是幕后黑手
3.1 光功率正常≠链路正常
后来和运营商师傅约了上门，他先用光功率计测了入户光纤，读数在正常范围，又用后台查了一下光猫的在线状态和注册信息，显示一切正常。到了这一步，大部分人可能会觉得“运营商线路没问题，回家再排查路由器吧”。但我和师傅说，要不查一下光猫的误码统计，尤其是误码秒和严重误码秒。
这里有一个特别容易忽略的知识点：光功率正常，只能说明光的强度够，不代表数据是干净的。光模块接收到的光信号可能因为温度过高、器件老化等原因出现劣化，导致信号波形畸变，接收端解调出来的数据全是错的。也就是说，链路在物理层仍然“在线”，但实际承载的数据已经在传输中损坏了。
举个容易理解的类比：光功率就像水管里的水压，水压正常只能说明水能流过来，但水质是不是干净、里面有没有杂质，那是另一回事。误码就是水里的杂质。运营商后台如果只看光功率，不会发现水质问题，但只要一看误码率，问题就藏不住了。
GPON链路上，光猫收到的每个数据帧都带有FCS校验，接收端如果校验失败，整帧直接丢弃。当误码率高到一定程度，对于用户来说就是“断网”——光猫还连着，但数据全丢了。
3.2 现场确认：从日志和统计里找到“实锤”
和运营商师傅一起查了光猫诊断信息后，证据终于浮出水面。主要看了三项数据：
| 检查项 | 实测值 | 正常参考范围 |
|---|---|---|
| 接收光功率 | -21.5dBm | -8到-27dBm 之间，指标正常 |
| 光模块温度 | 79度 | 通常建议低于70度，上限约85度 |
| 误码秒 | 故障时段出现大量计数 | 正常应为0或接近0 |
接收光功率确实在正常范围内，这一点没有骗人。但光模块温度79度已经非常接近临界值，误码秒的数据也很难看，说明链路早就处于“带病工作”状态。
之后我仔细回想整个故障过程，所有现象都能解释通了：夏季六月中旬温度升高，弱电箱本身又不通风，光猫长时间满载运行后光模块温度迅速上升，接收灵敏度下降，误码开始出现。刚重启时温度降下来，链路恢复正常，所以表现出“重启即好”。运行几小时后温度重新累积到临界点，误码率飙升，下行数据大量丢失，从用户角度看就是断网。
3.3 最终处理与验证
根因定位到这一步，解决方案就很明确了：光模块集成在光猫内部，个人没法单独更换，只能联系运营商换光猫。师傅也痛快，直接拿了一个新的光猫换上，重新注册、测速、观察了二十分钟，一切正常。
除了换设备，我还顺手做了一件事——把光猫从弱电箱里挪到了外面的通风位置。机箱里那种闷罐环境对光模块和电源都是慢性折磨，挪出来之后光模块温度从79度降到了六十度出头，散热压力小了很多。
换完光猫之后，我特意留了两个星期没有做任何额外操作，网络没有再断过一次。包括后面几天室外温度明显升高的时候，也一直稳定。至此故障真正解决，之前的“重启就好、过几个小时又断”彻底消失。
很多人觉得断网问题无非就是重启一下，但我这次的经验是：如果同一个故障反复出现，并且重启某种设备后能恢复，那不要把重启当成解决办法，而是要问一句“到底是什么状态被重启重置了”。在我这个案例里，重启重置的不是路由器配置，而是光模块的温度和内部状态。
4. 事后复盘：这套排查方法对任何断网都有用
4.1 断网问题排查速查表
这次排查走了一些弯路，尤其是被广播风暴带偏的那一段。事后我把整个思路整理成了一张速查表，以后再遇到断网问题，可以直接按表索骥：
| 故障特征 | 优先怀疑方向 | 验证手段 |
|---|---|---|
| 管理界面进不去、WAN口无IP | 路由器拨号、WAN口物理链路 | 看WAN口协商速率、换网线、重新拨号 |
| WAN口有IP，但外网全部不通 | 上游链路、光猫、运营商侧 | WAN口抓包，看是否只有出包没有回包 |
| 局域网完全正常，外网时好时坏 | DNS、MTU、重复网关地址 | 改公共DNS、直连IP访问、traceroute |
| 光猫PON灯常亮但网速忽快忽慢 | 光模块温度、误码率、端口CRC错误 | 查误码秒、光模块诊断、交换机端口统计 |
| 重启光猫后恢复，但反复发作 | 光猫散热、电源适配器老化 | 测量光模块温度、更换光猫测试 |
这张表里每一条我都踩过对应的问题。尤其是最后一条，“重启后恢复”这个现象太有迷惑性，很容易让人以为是软件状态卡死，实际上很多时候是硬件进入了不稳定状态，重启只是让硬件重新初始化而已。
4.2 两个容易漏掉的检查点：误码率和端口统计
这次故障之后，我在自己带的运维小团队里反复强调两个检查点，因为它们平时实在太容易被忽略。
第一是误码率。很多人查光路只看“光功率正常”，但光功率只是平均值，瞬时抖动和信号劣化根本反映不出来。现在只要遇到间歇性网络异常，我会先看看有没有误码秒、严重误码秒这类指标。光猫管理页面里如果找不到，可以直接联系运营商后台查询，专业网管系统里都有记录。
第二是交换机端口统计。像CRC错误、FCS错误、Runts、Giants这类计数器，初看只是数字，但它们在告诉我物理层的信号质量正在恶化。我这次看到端口上有CRC错误时，其实就应该更早联想到光猫光模块，而不是先去查二层环路。正确的思路是：只要交换机端口有大量CRC错误，先怀疑物理层，再考虑协议问题。
区分方法也很简单：用一根短网线把设备直连，排除长网线和中间跳线的干扰。如果CRC错误依然存在，问题大概率在设备本身的网口或光模块上。这个套路在排查“时断时续”的网络故障时非常有用。
4.3 怎样跟运营商高效沟通
最后说一个大多数人都吃亏的沟通问题。很多用户遇到断网，打电话就是一句“上不了网了”，运营商后台能看到的只有光猫在线状态和光功率，查完发现正常，然后就让你重启，问题反复几次也解决不了。
我的建议是，在打电话之前先自己多查一步，把故障边界压缩到最小。比如这次，我已经抓包确定了“WAN口有去无回”，而且光功率正常但误码率高，那么打电话时就可以直接说：光猫是亮的，光功率正常，但麻烦帮我查一下这台ONU的误码秒和光模块温度，我怀疑光模块热衰。
这句话一出来，运营商师傅就知道你是懂行的，不会继续让你反复重启。事实证明，证据到位之后，换光猫从头到尾只花了不到半小时。直接说“断网”只能触发标准流程，给出关键指标才能真正解决问题。
这次排查给我最大的收获，是重新认识了“物理层正常”和“数据层正常”之间的差别。很多看上去很复杂的网络故障，其实卡在一个很小的地方，只不过这地方藏在容易被忽略的指标里。如果你也遇到断网，先别急着怀疑路由器，想一想自己有没有漏掉误码率、光模块温度和端口CRC这类“隐藏指标”，答案可能就在里面。