做网络工程师这些年我一直觉得网络故障排查才是这个行业真正拉开差距的地方。设备配置表可以背命令可以抄但一张网络出问题的时候你脑子里有没有清晰的排查思路直接决定你是十分钟解决问题还是一下午被人当成“重启路由器的人型按钮”。尤其到了面试、软考网络工程师或者真正进企业做运维的时候别人问的不是“你配过什么”而是“故障在你面前你第一步干什么”。这篇文章我就把网络故障排查这事掰开揉碎讲透不堆理论全按实际运维场景来。标题里说“100个常见网络故障排查案例”我的态度是案例本身不用背但案例背后的分类思路、排查顺序、工具用法你必须变成肌肉记忆。只要把这些掌握了别说99%的故障剩下那1%你也知道该怎么一步步把它逼出来。1. 先想清楚网络工程师的差距到底差在哪1.1 会配置不等于会排障很多人一开始学网络都是从配路由、配交换机、划VLAN开始的。这个阶段其实是“照着说明书搭积木”设备选型、模板配置、接口地址一填网络基本就通了。但真实的网络环境根本不是“配完就完事”尤其是企业网络上午还能正常收发文件下午某个办公室集体掉线路由器一断电重启几百个终端全断了光是“用户说网卡”这一句话背后就可能藏着十几种完全不同的原因。配置能力解决的是“从无到有”排查能力解决的是“从坏到好”。两者的思维模式完全不同。配置时你是设计者一切按规划走排查时你是侦探面对的线索可能相互矛盾用户描述可能不准确监控数据可能滞后。很多刚入职的年轻工程师配置文档写得漂漂亮亮一遇到故障就慌了最大的原因就是脑子里没有建立排查坐标系不知道该从哪一端先下手。1.2 故障排查本质上是一个决策过程我以前带过一个新人办公室报“网很卡”他第一反应跑过去把交换机重启了。结果业务全部重连比之前更乱。这个操作错在哪错在他在没有收集任何数据的情况下直接做了不可逆的决策。故障排查其实就是一个持续提出假设、验证假设、排除假设的循环。你手里能用的资源无非就这几样网络拓扑、设备日志、报文抓取、连通性测试工具。每一次操作都应该有明确的目的——这次ping是为了确认哪一段链路通不通这次看ARP表是为了判断二层转发有没有问题。只要操作有依据就算方向错了你也能快速退回来换一条路最怕的就是“重启大法”式排查把网络当玄学。1.3 我建议先建立三个习惯第一个习惯画拓扑。别管公司网络多大哪怕只有一台路由器加两台交换机也把图画出来。没有拓扑排查时你连“从哪到哪”都说不清别人也没法帮你。第二个习惯留底稿。每次配置变更前先把当前配置导出一份。很多故障根本不是“突然发生的”而是“被前一天晚上的改动触发的”。有底稿你就能做对比快速找出变化点。第三个习惯记录时间线。用户说“上午10点开始卡”那你要问“10点之前有没有人动过机房”“有没有新设备接入”“有没有升级软件”。时间线是排查故障最便宜也最有效的线索可惜很多人从来不记。2. 建立自己的排查方法论四步定位法2.1 第一步问对问题缩小范围故障一报过来不要急着上工具先把范围圈出来。我一般会问五个问题是全网都不通还是只有某一个区域、某一栋楼、某一个部门不通是一台电脑的问题还是多台电脑同时出问题是完全不通还是慢、丢包、时断时续故障是从什么时候开始的之前做过什么变更吗有线正常吗还是只有无线受影响这一组问题问完故障范围基本能缩小一半。比如“只有无线慢有线正常”那核心问题大概率出在无线侧而不是出口带宽“只有财务部不通其他部门正常”那就优先查财务部到核心之间的链路、端口VLAN和交换机配置。这个阶段最忌讳的就是用户说什么你信什么。用户说“网断了”但不一定是物理断网可能只是某个应用服务器卡住。用户说“全公司都上不了网”结果你一看只有他那台电脑的网线没插好。所以问问题不是走流程是为了形成初步判断。2.2 第二步从物理层到应用层自下而上过一遍OSI七层模型在学校里是考试重点在工作中就是排查路线图。网络故障90%都能用“自下而上”的顺序找出来物理层网线、光模块、光纤、端口状态。Link灯亮不亮CRC错误多不多光功率是否在正常范围。数据链路层MAC地址表、ARP表、VLAN划分、STP状态。有没有非法DHCP服务器有没有二层环路端口是否被阻塞。网络层IP地址是否冲突路由表是否正常ping网关通不通丢包率是多少。传输层TCP连接能否建立端口是否被防火墙或ACL拦截有没有半连接耗尽。应用层DNS解析对不对代理设置对不对服务器进程是否在监听证书过期没有。我见过不少人一上来就抓包看HTTP状态码查了半天才发现是光纤被老鼠咬了。自下而上的好处是一层层推进每层都能用低成本工具验证不会把时间浪费在错误层面。2.3 第三步用工具验证不要靠猜排查不是靠感觉而是靠证据。最常用的工具其实就那几样但它们能组合出非常多的判断ping测连通性、延迟、丢包判断三层通不通。tracert / traceroute定位路径上哪一跳出问题。ipconfig / ifconfig / ip addr看本机IP、掩码、网关、DNS配置。nslookup / dig验证DNS解析是否正常。telnet / nc / Test-NetConnection测试TCP端口是否可达绕过ping的限制。display / show 系列命令查接口状态、MAC表、路由表、CPU使用率。Wireshark / tcpdump抓包分析适合问题和深层协议相关时使用。这里我特别提醒一点ping通了不代表网络就是好的。很多初学者看到“能ping通网关”就觉得链路没问题但实际业务走的是TCP端口UDP流量状态又不一样。所以我一般会把“ping网关”“ping服务器IP”“ping域名”“访问具体应用端口”分开测每一层都拿到了证据才敢下结论。2.4 第四步记录和复盘把故障变成经验排完一个故障不要急着庆祝花十分钟把过程记录成一条案例故障现象、影响范围、排查路径、根因、临时措施、根治措施。这看起来麻烦但三个月后你手里就有一份属于你自己的故障库。下次再遇到相似问题你不是从零开始而是直接调取历史方案。我在内部培训时经常说一句话故障排查能力就是你的案例数量乘以你的总结深度。遇到100个问题不总结等于白遇到总结成体系10个问题就能覆盖80%的常见场景。3. 100个案例不是让你背而是让你建分类库“100个常见网络故障排查案例汇总”这个说法听起来很吓人其实把案例按故障层面分类以后每一类里的排查思路高度相似。下面我就按七个层面拆解在一个层面里你只需要掌握几个核心排查点大部分案例都能套进去。3.1 物理与链路层故障先看灯再看光最后查线这一类故障的现象很统一设备完全不通或者时通时断。排查点也很固定典型现象可能原因快速验证方法端口灯不亮网线松动、线序错误、对端设备未供电重新插拔换一根已知好用的网线端口灯亮但协商速率低网线质量差、长度超100米查看端口协商速度更换六类线光口不通光模块收发光功率异常、光纤损坏查光功率用光功率计或设备自带命令CRC错误持续增长链路干扰、双工不匹配、网线老化show interface观察CRC计数变化时通时断水晶头触点氧化、PoE供电不足换线、换端口确认PoE预算物理层的坑在于“看起来通了不等于链路是健康的”。比如端口能起来但CRC错误一大堆数据包一直在底层被丢弃上层业务就会表现为“特别卡”。这种故障靠ping不一定看得出来必须去设备上翻接口统计。所以只要排查大流量业务卡顿我习惯性先看一眼接口的CRC和流量趋势排除物理层因素再去查上层。另外一个容易被忽略的是光模块。很多网络工程师看到光口灯亮就放心了但实际上光模块的发送功率、接收功率是有阈值的。接收光功率接近临界值时平时没问题温度一高或者光纤接头脏了立刻开始丢包。这一类故障非常阴间因为它不是稳定的不通而是间歇性出问题。你到场的时候它可能就是好的所以一定要在设备上拉历史告警和光功率记录。3.2 IP与路由层故障地址、掩码、网关、路由表一项项对IP层问题最常见的四个来源IP地址冲突、掩码配置错误、网关错误、路由表缺失或错误。IP地址冲突的现象很有迷惑性——有时候能用有时候不能用过一会儿又恢复了。因为两台设备抢同一个地址ARP表被频繁刷新流量就跟着飘。排查方法很直接ping一个不存在的同网段地址然后查看本地ARP缓存有没有变化更靠谱的是在交换机上查IP对应的MAC再在接入交换机上定位端口逮住冲突设备。掩码和网关配错往往出现在“手动配置IP”的终端上。比如用户把/24写成了/16网关照样能通但是访问其他网段时行为会非常奇怪很多包会直接走二层转发结果发到错误的地方。这种问题用ipconfig看一眼就能发现属于标准送分题。路由层的排查就要看设备了。常见场景是“核心能ping通但办公网访问服务器业务不通”。这时你需要在核心路由器/交换机上看路由表确认有没有到达服务器网段的路由再看下一跳设备的路由表逐跳排查。路由缺失经常是因为新加了一段网段却没有写静态路由或者动态路由协议没有宣告。我的习惯是先梳理三层转发路径把每一跳的入接口、出接口、下一跳列出来再逐台验证。3.3 DNS与域名解析故障能ping通IP就是打不开网页如果说有一个故障类型最容易让人绕远路那就是DNS问题。现象很典型用户说“上不了网”但你ping公网IP比如114.114.114.114是通的ping域名却提示找不到主机。这说明根本不是网络断了而是域名解析失败了。排查顺序先确认DNS服务器地址本身配没配对。查看自动获取还是手动填写会不会填了一个已经失效的地址。用nslookup查解析结果。如果返回的IP明显不对比如本应解析到某个公网IP却返回内网地址或者一个陌生地址那就要怀疑DNS劫持或污染。看DNS服务器到上游的通信是否正常。企业内部有时自建DNS服务器如果它向外部递归解析的链路出了问题终端指定它作为DNS应用自然全挂。注意域名解析超时和解析结果缓存的问题。有时域名解析记录已经改了但终端缓存了旧记录有时本地hosts文件里写了一条错误映射。Windows排查时直接执行ipconfig /flushdns清缓存再看hosts文件有没有被改过。一个容易踩的坑是某些高可用方案会配置多个DNS服务器其中一个失效终端解析时快时慢。这时候用户体感是“网页打开很慢转半天然后失败”。你抓包会看到终端连续向多个DNS服务器发送查询请求直到超时才切换。这类问题靠手工配置固定一个可用的DNS地址就能快速验证。3.4 DHCP与地址分配故障设备拿不到地址时的套路化排查终端显示“未识别的网络”“没有有效IP配置”是网络工程师最常遇到的一类故障。DHCP本身很简单但出问题的地方非常多。地址池耗尽新增了一批终端DHCP可分配地址不足老设备续租正常新设备一个地址都拿不到。地址池配置错误网段、掩码、网关、DNS参数填错导致分出去的地址没法正常上网。DHCP服务器不可达中继配置错误、VLAN间路由不通、服务器防火墙拦截了UDP 67/68端口。非法DHCP干扰有人在办公区私自接了一个小路由器LAN口接到了公司网络它自己开启DHCP向终端分发错误的网关和DNS地址。这个现象很经典——一部分电脑能上网一部分不能分到的网关IP还特别奇怪。租约时间过短个别场景下租约设置成几分钟终端频繁续租造成网络抖动。排查时我会先看终端拿到的IP是什么169.254开头说明DHCP根本没有响应拿到一个IP但网关不对说明有多个DHCP服务器在抢答拿到IP也正确但无法上网那就继续查网关和路由。企业网络里我推荐在接入交换机上开启DHCP Snooping它能拦截非信任端口的DHCP响应包从根源上解决“私接路由导致全楼断网”的奇葩问题。虽然配置有点繁琐但绝对值得。3.5 交换、VLAN与环路故障从MAC表和STP状态开始查交换网络是很多网络工程师的“主战场”也是故障最多发的地方。三大类问题最常见VLAN配错、MAC表漂移、二层环路。先说VLAN。接入端口划错VLAN典型症状是终端能被交换机管理但访问不了对应VLAN里的服务器或网关。排查时用display vlan查端口归属同时确认对端交换机上相同VLAN是否打通了Trunk链路。Trunk的Native VLAN如果不一致也可能造成VLAN标记错乱表现为“几个VLAN之间能互通但很怪”。MAC表飘移是个隐蔽问题。交换机上同一个MAC地址在不同端口之间反复跳变通常意味着下面有环路或者有人把两台交换机用两根线连起来了又或者一个傻瓜交换机接到了两个不同上联端口。这个会造成广播风暴、CPU飙升严重时整个网络瘫痪。用命令查MAC地址表的历史记录能看到它跳变的时间和端口顺藤摸瓜就能找到环路设备。二层环路的经典表现是全网或者某个广播域突然变得极慢设备CPU占用很高所有端口流量疯狂上涨。这时候第一件事不是抓包而是找到环路物理位置把人解开。如果没有STP或者STP配置不当环路可以直接让网络瘫痪。我处理过最夸张的一次整个机房的交换机全部被广播包打满拔掉一根跳线后网络在五秒内恢复正常。所以核心链路最好开RSTP或MSTP边缘端口开边缘端口特性防止误接环路。3.6 安全策略与ACL故障业务不通先查有没有被“静默丢弃”防火墙和ACL引起的故障是最容易让人误判的一类因为设备很多时候“看着都是好的”接口也up路由也通但业务就是不通。问题出在安全策略上防火墙默认丢弃ACL显式拒绝或会话表被清。排查技巧先看会话表。一个TCP连接如果出现过但现在状态异常可能是会话老化机制或负载均衡策略的问题。再查策略命中计数。防火墙/ACL一般都有匹配计数你可以在策略上加一个计数器或者直接查看已有计数的变化。如果某个deny规则一直在涨凶手就是它。检查优先级顺序。ACL默认按顺序匹配前面的permit/deny规则决定了后面规则的命运。有时候加了一条范围很大的“拒绝所有”把业务流量全拒掉了。别忘了回程流量。在防火墙场景不仅要放行入口方向的流量还要放行回程方向的流量特别是非对称路由环境中很容易只做单向策略导致“只能发不能收”。安全策略这块最考验工程师的细节能力。很多故障不是配置写错而是策略顺序不合理、日志没开、会话表老化时间不合适。排查时把策略、路由、NAT三条线分开看哪条线断了就在哪里处理。3.7 无线网络故障从信号、漫游、频段干扰三个维度定位无线故障是另一个重灾区。办公区Wi-Fi不稳定用户报障最多。常见的根因有信号覆盖弱、同频干扰严重、漫游切换不及时、DHCP请求被拒、无线控制器上认证策略异常。初步排查时先用无线扫描工具看一下现场信号强度和信道占用。2.4GHz频段只有三个完全不重叠信道办公环境一般很拥挤5GHz频段信道多但穿墙能力弱。很多“网速慢”其实只是因为在某一区域内同信道AP太多无线报文互相碰撞。此时可以调整AP功率、改信道、开启DFS等特性。漫游问题也很常见。用户从办公室走到会议室手机始终连着远处那个弱信号AP不切换到近处AP结果就是“看着有信号实际连不上”。这类问题需要检查漫游阈值和AP间负载均衡配置还要确认终端和AP是否支持802.11k/v/r快速漫游。无线排查的体验是相比有线无线网络的不确定性更大受环境、终端、射频干扰影响很大。所以千万别只看无线控制器的配置建议实际走到现场看信号强度、测速、抓空口报文用数据说话。3.8 应用与性能类故障链路都通业务却卡这类故障最考验综合能力。链路没什么问题路由也通端口也通但用户打开业务系统就是慢或者频繁超时。通常要从这几方面入手带宽跑满看出口流量和核心设备接口流量是否存在大流量下载或异常业务占用。TCP重传率过高抓包看是否有大量重传、零窗口、乱序说明链路丢包或设备性能不足。MTU不一致某些链路MTU设置过小或过大导致大包不通小包正常表现为“网页能打开但文件传不了”。服务器侧瓶颈CPU、内存、数据库连接池、日志磁盘满了都会导致应用响应慢网络再快也没用。链路拥塞和QoS缺失视频会议、语音流量被大流量挤占表现为声音断断续续。处理这类性能问题我会同时打开流量监控、抓包工具和服务器性能面板把网络侧和应用侧的数据对照起来看。能证明“网络侧没丢包、延迟稳定”就能理直气壮地把问题推给应用团队——当然你自己要先确认确实没丢包。4. 四个高频故障案例的完整排查实录方法论讲再多也得落到具体操作上。下面我把我实际处理过的四个案例完整复盘一遍你可以直接照着这个思路走。4.1 案例一整个部门间歇性断网从光模块查到UPS现象技术部30多台电脑频繁出现“网络时通时断”每次断几秒钟或几分钟然后自己恢复。交换机上没有报警服务器也正常。排查过程我先在核心交换机上ping技术部网关结果丢包率在0%到20%之间来回跳说明问题不在终端而在链路或设备。再看接入交换机的接口统计发现技术部上联口的CRC错误在持续增长物理层有隐患。查光模块收发光功率接收功率只有-24dBm接近临界值光路衰减明显。顺着光纤线缆检查发现连接收发器的光纤插头有明显折弯重新整理线缆并清洁光纤接头后接收功率恢复到-14dBm丢包消失。这个案例的教训是链路质量导致的间歇性故障靠ping一次很难覆盖到“坏事发生的那几秒”。要利用设备本身的告警记录和接口统计把“偶尔发生”的证据找出来。后来我在两边都加了光功率监控告警低于阈值自动通知没有再出现类似问题。4.2 案例二能上微信却打不开网页现象用户说所有浏览器都打不开网页但微信、邮件客户端能正常收发消息。刚排查时我也愣了一下如果网络全断微信不可能在线。排查过程先ping公网IP通再ping域名不通。问题指向DNS。看终端DNS设置显示自动获取。nslookup www.example.com结果请求超时。查核心路由器的DNS转发配置发现内网DNS服务器指向了一个已经不存在的上游DNS地址。简单验证临时把终端DNS改成公共DNS网页秒开。然后在DNS服务器上修改上游转发配置并测试多轮解析正常后恢复自动获取。为什么微信和邮件没问题因为它们用的是服务器IP或者固定解析好的长连接对DNS的依赖不像浏览器那么高。所以“别把应用正常当成网络正常”DNS坏了只会影响需要域名解析的应用这个场景特别典型。4.3 案例三交换机端口up但业务不通现象服务器双网卡做bond接到交换机两个端口交换机端口都是up状态但服务器对外服务一直时通时断。配置看起来没问题。排查过程我先把服务器bond模式确认了一下发现是mode 1主备模式但交换机侧两个端口都配成了普通access口没有做链路聚合或相关配置。继续看交换机日志发现两个端口频繁收到MAC地址漂移告警同一个MAC在两个端口间跳来跳去。这是双网卡bond和交换机配置不匹配时很常见的现象。处理方案把服务器bond改为mode 4LACP交换机两个端口做链路聚合模式为active/passive问题解决。这个案例说明端口up只是“物理层通”不代表“转发正常”。排查这类问题必须结合日志、MAC表、流量走向一起看。很多人看到端口up就排除物理层这是不对的二层配置错误同样可能造成业务异常。4.4 案例四无线网络频繁掉线最终发现是信道干扰现象办公楼会议室无线信号满格但每隔几分钟就会出现卡顿和掉线尤其是中午人多的时候特别严重。无线控制器里AP没有任何异常。排查过程现场用无线勘察工具扫描发现周围几十个AP全挤在2.4GHz信道上同一个信道上的AP数量超过15个信道占用率接近100%。再检查AP配置发现固定使用了2.4GHz的1信道附近的AP互相干扰严重。临时措施将会议室AP切换到5GHz频段掉线现象立刻缓解。长期方案使用无线控制器开启自动信道调优和负载均衡并把2.4GHz和5GHz的SSID做band steering让支持5GHz的终端主动优先连5GHz。无线问题的排查一定要现场测量不能只看控制器。会议室满格但是不好用很可能是“信号能看到但信道太挤”这时候再完美的配置也没用。5. 我踩过的坑和想分享给你的实用技巧5.1 四个容易翻车的直觉判断“能ping通就代表网络好的”——不一定TCP端口和应用层可能完全不正常。“重启一下就好” ——重启是验证手段不是根治方案。不找到根因问题一定会再回来。“设备上看着没告警就没事”——很多问题在数据面不走控制面控制面根本不会产生告警。“用户说断了就信了”——先问清范围、时间、有线无线再开始排障能省下大把时间。以上每一条我都吃过亏。尤其“ping通就完事”这个误区新人最容易犯。后来我给自己定了一个规矩任何排障结论必须至少有两个独立证据支撑比如“端口没报错抓包正常”“路由表有路由ping对端通”。证据链越完整结论越稳。5.2 五个值得长期保留的习惯所有变更前备份配置变更后做记录。很多“神秘故障”就是变更后没有留痕导致的。给网络设备开启时间同步开启日志服务器。日志是事后追查最有力的工具但如果设备时间不准日志等于失效。定期看接口CRC错误、光功率、CPU和内存使用率。这些数据平时不起眼故障时却是金矿。从第一次接触网络开始就坚持写排障笔记。这比任何培训资料都值钱。对重复出现的故障主动做永久改进不要让临时方案变成永久方案。5.3 排查工具和命令速查清单我给自己整理过一张“排查急救卡”现在放出来给大家参考场景推荐命令/工具重点看什么终端网络配置ipconfig /all、ip addrIP、掩码、网关、DNS是不是预期值连通性ping、tracert、mtr哪一跳丢包延迟多少端口监听netstat -an、ss -lntp端口是否在监听是否有半连接DNS解析nslookup、dig解析结果、服务器响应时间端口连通性telnet、Test-NetConnection特定TCP端口是否可达交换机接口display interfaceup/down、速率、CRC、收发流量MAC地址表display mac-addressMAC在哪端口是否有漂移路由表display ip routing-table目标网段路由是否存在设备CPUdisplay cpu-usage是否被广播、软件转发拖垮抓包分析tcpdump、Wireshark会话建立、重传、DNS请求等这套清单不是让你死记硬背而是由于故障类型不同你手上要有一个“从终端到接入再到核心”的排查顺序。命令记不牢没关系记住“工具和目的要匹配”这个原则更重要。5.4 面试和软考里故障排查题到底想考你什么不管你是准备软考网络工程师还是面试网络工程师岗位故障排查题型出现的频率都非常高。最开始我也以为考官只是想知道“你会不会配网络”后来自己带人、帮别人做模拟面试时才发现对方真正想看的是你面对不确定问题时的逻辑路径。面试官抛出“用户反映网页打不开”他们期待的回答不是一个命令而是一套思维链先判断影响范围是单点还是全网再分层排查从物理层到应用层逐层验证每走一步都要说明“我在验证什么”“这个结果说明什么”。能把思维链说清楚哪怕最后没找到根因考官都会认为你有排障意识。软考网络工程师的案例分析题更像“给你一个拓扑、一堆现象让你挑错”。这种题虽然以纸面形式出现但考察的依然是分层定位能力。比如给出“核心交换机到接入交换机聚合链路中一条链路老丢包”你就要能联想到物理层光模块、二层STP、三层路由策略多个可能原因再逐一排除。备考时建议把每个协议的重点故障现象整理成表格现象、原因、排查点。这样复习效率最高。现在很多教材已经更新到第六版网络运维的考查内容也越来越偏实战。像“2026年上半年软考网络工程师真题”这类高频搜索词大家都会关注但与其押题不如把每个协议的原理和排查思想学扎实。故障现象千变万化但底层的“分层定位、逐层验证”的底层逻辑是不变的。最后再分享一个小经验平时遇到故障先别急着求助别人。给自己安排一个“必须独立排查30分钟”的规则30分钟内查不到再开口问。你会发现很多知识不是看书学会的而是被问题和报错逼出来的。网络工程这一行真正的成长从来不是敲了多少命令而是你独自面对过一次又一次“全网瘫痪”之后还能冷静地说出“别慌我们先看日志”。