1. 为什么我放弃了“万能重启法”
先说实话，我以前也是那种一遇到网络卡顿就冲过去拔电源、等十秒、再插回去的人。十年前我刚接触网络运维的时候，前辈教我的第一句话就是“重启解决99%的问题”，当时觉得这话没毛病，光猫重启、路由器重启、电脑重启，三板斧下去确实能救回来一半的场面。但干得越久越发现，重启只是把问题往后推，根本没有定位到故障源头。今天网络断了，你重启好了，明天同一个时间点它又断了，后天你继续重启，那个真正的故障点就像地雷一样埋在你的链路里，早晚要炸。
后来我开始带团队，新人报障最喜欢说的就是“网络不通，我重启过了”。我听到这句话基本等于什么都没听到。重启之后的复现率、重启之前的外围现象、重启那一刻设备指示灯的状态，这些信息全都没有，排查只能从头开始。更麻烦的是，有些故障重启之后短暂恢复，你以为解决了，实际上设备可能正处于“带病运行”的状态，比如光猫的光模块已经老化了，重启只是让它重新协商一次光功率，过几个小时又会掉线。
所以这篇文章我想写的不是“怎么重启”，而是怎么在动手之前先动脑，用分层排查的思路把故障一点点圈定住。这个方法不是我发明的，其实就是把OSI七层模型应用到实际的故障定位里，但我在这里不准备讲那些教科书理论，我只讲你在家里、在小办公室、在机房里真实会遇到的场景和操作。整个过程不复杂，也不需要昂贵的工具，最核心的工具就三样：你的眼睛、一根能用的网线、一台装了Ping和Traceroute命令的电脑。
这篇文章适合谁看？如果你是家庭网络的管理员、小公司的IT兼职人员、或者刚入行想做网络方向的技术人员，都能从这里拿到一套可以直接照做的排查套路。我会讲清楚每一层查什么、怎么查、查到什么结果说明什么，还会把这些年踩过的坑和一些比较隐蔽的故障案例拿出来拆一遍。
2. 分层排查的核心思路：把网络问题装进“柜子”
2.1 为什么分层能帮我们减小排查范围
网络故障最让人头疼的地方在于，表面现象往往不会告诉你问题出在哪一层。你打开网页很慢，这可能是DNS解析慢、可能是TCP握手超时、可能是Wi-Fi信号弱、可能是出口带宽被占满、甚至可能是ISP那条光路本身有问题。如果不对这些可能性做分拣，你只能靠猜，而猜的效率太低了。
分层排查的思路其实很像电工修电路。电工不会一上来就把整栋楼的电闸全拉了，他们会先分清是入户线的问题、还是楼层配电箱的问题、还是房间插座的问题。网络也是同样的道理，我们把从“设备上运行的应用程序”到“物理传输介质”之间拆成几个层次，每一层只管它自己的那点事。从最底层开始查起，底层没问题再往上一层，这样每一轮排查都能排除掉一批可能性，最终剩下的就是真正的故障点。
用生活化的比喻来说，分层的逻辑有点像你收到一个快递包裹，外包装破了、里边的商品也碎了，你总不能直接怪快递员吧。你得先看是箱子破了、还是内部填充物没放够、还是商品本身就存在质量问题。网络的每一层就相当于包裹的每一层缓冲，数据从你的电脑出发，要经过应用层的包装、传输层的分段、网络层的寻址、链路层的封装、物理层的电信号传输，任何一层出了问题，最终表现都是“数据没送达”，但原因可能千差万别。
2.2 最终方案：一张“从底到顶”的排查顺序表
我在实际工作中总结了一套固定的排查顺序，我给它起了个名字叫“从线到端”七步法。这套顺序我用了很多年，也教给了很多同事，只要你严格按照这个顺序走，绝大多数问题都能在二十分钟内定位到具体层级。
第一步，物理层：检查光猫、路由器、网线、接口的物理连接状态，看指示灯是否正常，网线的水晶头是否松动，光纤的弯折半径是否过小。第二步，链路层：检查设备是否成功获取到IP地址，交换机端口是否有协商速率异常，Wi-Fi是否关联成功。第三步，网络层：Ping网关、Ping公网地址，确认路由是否可达，确认IP地址和子网掩码配置是否正确。第四步，传输层：测试TCP和UDP端口是否通，比如用Telnet或者PowerShell的Test-NetConnection检查目标端口。第五步，DNS应用层：测试域名解析是否正常，用nslookup确认解析返回的IP地址是否符合预期。第六步，应用层：验证具体的业务应用是否正常，比如浏览器是否能打开页面、邮件客户端能否收发。第七步，对比验证：如果以上层都正常，但业务还是有问题，就要考虑是否是设备本身的性能瓶颈或者硬件故障。
这套顺序的核心逻辑就是：任何上层功能都依赖下层服务的正常。底层都没通，你花两个小时去调路由器的高级设置就是白费劲。反过来，如果底层完全正常，你一直纠结网线质量也没意义。每一层都要有“通过/不通过”的明确结论，然后再决定是否走向上一层，这样整个排查过程才是有序的，而不是东一榔头西一棒子。
3. 从物理层入手：九成断网都藏在线和口上
3.1 指示灯、网线、水晶头：最便宜也最容易被忽略的环节
我开始正式讲第一层。物理层是整个排查体系的根基，也是我见过翻车率最高的一层。很多人觉得物理层就是看指示灯亮没亮，太简单了，不需要认真对待。但我告诉你，我经手的大大小小的网络故障里，至少有三成最终定位到物理层，而且往往不是你一眼能看出来的那种物理故障。
先说指示灯。光猫和路由器的指示灯其实已经给了你很多信息，只是你没在读。以家用光猫为例，正常的PON指示灯应该常亮或者慢闪，LOS灯绝对不能亮。如果你看到LOS灯亮红色或者闪烁，那基本可以断定是光路的问题，也就是从局端到你家里的这段光纤已经断了或者光衰太大，这种情况你重启光猫八百遍也没用。我有个朋友家里网络一到晚上就断，每次重启就好，持续了半个月才找我，我看了一眼，他家的光猫放在电视柜角落里，光纤被柜门夹出了一个死弯，光信号衰减严重，正午温度高的时候刚好在临界值上，晚上温度一降就彻底断掉。把光纤重新理顺之后，问题再也没出现过。
然后是网线和水晶头。网线最怕的是三件事：压接不规范、线序错误、线缆老化。我见过太多人自己动手做水晶头，线序按照568A和568B混着接，百兆的网口还能勉强通，上了千兆就直接协商不到千兆速率，甚至干脆不通。排查的时候你把网线拔下来重新做一遍水晶头，问题立刻解决，但你之前可能已经为此换过两个路由器了。网线还有一个很容易忽略的问题就是长度，铜缆的标准上限是100米，超过这个长度信号衰减会急剧增大，实际使用中我建议控制在80米以内比较稳妥，如果你家或者办公室的网线是走墙内的，穿线的时候一定要确认线的质量，劣质铜包铝线用个一两年就会开始丢包，那时候你连换线的机会都没有。
这里我分享一下我的检查清单：看接口处的金属弹片是否氧化发黑，看线缆外皮是否有折痕或破损，把水晶头对准光线看里面的金属针脚是否整齐、是否完全压到底，插到设备上之后轻轻晃动网线接头看指示灯是否有闪烁变化。这些操作三十秒就能做完，却能帮你排除掉一大批物理层问题。
3.2 不只是网线：Wi-Fi信号和电磁干扰也是物理层问题
很多人觉得无线的故障应该算“另一层”的问题，但从OSI模型的角度来看，Wi-Fi工作的频段、信号的强弱、射频干扰，这些都属于物理层的范畴。所以排查无线上不了网的时候，你要先把Wi-Fi当成物理层的设备来看待。
Wi-Fi排查里最常见的误区是只看信号格数。一个满格的Wi-Fi信号，实际体验未必好，因为信号强度只代表接收功率，不代表信道质量。如果周围有大量干扰源，比如隔壁的路由器用了和你同一个信道，或者家里有微波炉、无线鼠标接收器、蓝牙设备在同一个频段上工作，你的信号格数可能是满的，但实际丢包率高得吓人。我之前处理过一个案例，用户的笔记本电脑在客厅连着Wi-Fi就正常，拿到书房就频繁掉线。我用无线扫描工具一看，书房的2.4G信道拥堵得一塌糊涂，周边大概有十几个AP在互相抢信道，后来把路由器的2.4G频段固定到相对干净的信道，同时把5G频段的带宽从80MHz降到40MHz，问题立刻缓解。
物理层的核心思想就是：它只管把比特从A点搬到B点，不关心这些比特代表什么含义。所以你判断物理层问题的标准也很简单——链路能不能在稳定速率下正常建立和维持。如果链路不稳定，比如千兆网口协商成了百兆，或者Wi-Fi速率来回跳变，先别急着去改IP、调防火墙，回到物理层找原因是更高效的做法。一条链路，物理层稳定了，后续层级的问题才有可能被准确定位。如果物理层本身都是飘忽的，上层再怎么调都是在一堆流沙上盖房子。
4. 网络层与传输层：用Ping和Traceroute锁定故障方向
4.1 先Ping后Traceroute：从网关到公网的逐跳验证
当物理层确认无恙之后，下一步就进入网络层。这一层最核心的工具就是Ping和Traceroute，它们的作用是告诉你“数据包能否到达目的地、在哪个环节出了问题、时延到底高在哪里”。
我建议的Ping排查顺序是这样：先Ping本机回环地址127.0.0.1，确认TCP/IP协议栈本身没坏；再Ping网关地址，确认局域网内部能通；然后Ping一个公网IP地址，比如223.5.5.5或者114.114.114.114，确认运营商链路是通的；最后再Ping域名，比如www.baidu.com，确认DNS解析和出网都正常。这个过程看起来简单，但每一跳其实都在回答一个关键问题。
举个例子，如果你的电脑能Ping通网关，但Ping不通公网IP，说明局域网内部没问题，问题出在路由器往上，可能是拨号断了、可能是路由器的WAN口没有正常获取到地址、也可能是运营商线路中断。这时候你再去检查路由器的拨号状态和WAN口IP，会比一开始就把路由器恢复出厂设置理智得多。反过来，如果连网关都Ping不通，你就不再需要去看公网了，问题就锁在你自己家里这一段，要么是网线、要么是Wi-Fi、要么是设备IP配置错了。
Traceroute的价值在于观察路径中的每一跳。Windows的用户可以用tracert命令，macOS和Linux的系统可以用traceroute。如果你发现数据包经过某一跳之后时延突然飙升，或者直接从某一跳开始出现大量“请求超时”，那这一跳附近很可能就是问题所在。不过我要提醒一点，不要迷信每一跳的超时就一定是故障。很多运营商的设备不响应Traceroute的探针数据，超时是正常的，真正需要注意的是：到达最终目的地的总时延是否在合理范围。如果前面每一跳都通了，但总时延高得离谱，那大概率是链路存在严重的拥塞或者路由绕路。
4.2 别急着怪路由器：IP地址、子网掩码与网关配置自查
网络层还有一个很大的坑，就是设备本身的IP配置出了问题。尤其是一些开启了DHCP的网络，偶尔会因为租约过期、地址池耗尽、或者设备休眠唤醒后没有重新获取IP，导致出现“网络明明连着，但上不了网”的诡异现象。
遇到这种情况，我第一件事就是打开命令行，输入ipconfig（Windows）或者ifconfig（macOS/Linux），仔细看一下当前网卡获取到的IP地址、子网掩码、默认网关这三项。我之前遇到过一台电脑，明明在家里连Wi-Fi，IP地址却是169.254开头的，这是一个典型的APIPA地址，意味着这台电脑根本没有从路由器那里获取到有效IP。这种问题其实不是路由器坏了，而是网卡驱动或者DHCP客户端服务出了问题。在Windows上你可以尝试禁用再启用一次网卡，或者用ipconfig /release和ipconfig /renew重新获取地址，绝大多数情况下都能解决。
子网掩码也是个容易出问题的点。我在公司处理过一个案例，有人手动把一台打印机的IP地址设置成了192.168.1.25，但子网掩码误填成了255.255.255.0，而整个局域网实际是192.168.0.0/24的网段，结果就是同网段的其他设备根本找不到这台打印机。这类问题靠重启永远发现不了，因为你重启的是设备，而不是配置。你在排查网络层的时候，一定要有“不信任现有配置”的意识，哪怕这个配置是你自己一个月前亲手设置的，它也可能因为各种原因被改动了。
传输层这一块，普通家庭用户可能用到的不多，但做应用联调或者访问公司内网资源时就会碰到。核心关注点就是端口是否通。Windows下可以用Test-NetConnection IP地址 -Port 端口号这条命令来验证，返回TcpTestSucceeded为True说明端口可达。如果端口不通，你就要区分是防火墙拦截、还是目标服务没启动、还是中间路由阻断了，这时候又得回到前面几层去逐个排查。
5. 应用层与设备端：网络通了不等于体验正常
5.1 光通不够用：DNS解析、浏览器缓存与代理配置
网络层都通了，Ping公网也秒回，但用户打开网页就是慢，这是最让人抓狂的场景。到了这一层，你会开始明白，网络层面的连通和用户实际的应用体验是两回事，而多数“感觉网不好”的用户，问题恰恰出在应用层。
DNS是应用层故障的大户。我遇到过不少人，Ping一个IP地址完全正常，但打开浏览器输入域名就是打不开，或者隔一会儿才能打开一个页面。这时候你只要在命令行里输入nslookup，去查一下这个域名解析出来的IP是什么，问题基本就露出来了。典型的故障是系统里被塞进了一个很慢的DNS服务器地址，或者DNS解析返回了一个被污染的IP。解决办法通常是把设备的DNS改成公共DNS，比如国内的223.5.5.5、119.29.29.29，注意这里我只推荐这些本地的公共解析服务，它们的速度和稳定性足够满足日常使用。如果改了DNS依旧不行，那再看浏览器的代理设置。现在很多安全软件、上网行为管理软件会修改系统的代理配置，一旦代理服务器失效，浏览器就会在“尝试连接代理”这个环节卡死。检查方法很简单，Windows在“设置-网络和Internet-代理”里看是否开启了“使用代理服务器”，macOS在“系统偏好设置-网络-高级-代理”里看，把这个勾选去掉，再用系统代理，多数情况下网页访问就恢复了。
很多人不理解为什么网络层全通，应用层却不行。打个比方，你给快递员一个正确的门牌号（IP），快递员也按时送到了楼下，但收件人的手机停机了联系不上，包裹还是签收不了。DNS就是你查门牌号的过程，代理就是那个临时中转的收件人。门牌号再准确，中间某个环节失灵，快递照样送不到手上。
5.2 网速正常但视频卡顿：MTU、带宽占用与无线性能瓶颈
还有一种很典型的情况：测速软件显示带宽跑满，但实际用起来视频卡、游戏延迟高。这时候很多人会陷入“是不是运营商偷工减料”的猜疑，但实际上往往和设备端本身有关。
MTU（最大传输单元）就是一个经常被忽视的参数。家用宽带最常用的PPPoE拨号方式下，MTU建议设置为1492而不是默认的1500。如果MTU设置过大，数据包经过PPPoE封装后超过了运营商允许的最大长度，就会被分片或者直接丢弃，表现就是很多网页能打开，但一些图片加载不出、某些软件连不上服务器。判断MTU问题有个土办法：在命令行里用Ping加上“-f -l”参数，Windows系统下输入Ping 目标地址 -f -l 1472，如果返回“需要拆分数据包”的提示，就说明当前路径上的MTU值低于你的设置。当然家庭网络现在多数是光猫拨号，路由器是自动获取IP的方式，MTU一般不需要手动调，但如果你用了老式的PPPoE方式，这个参数值得去路由器里核对一下。
带宽占用也是一个容易被忽略的点。你要知道，测速软件测出来的往往是瞬时峰值速率，而实际使用中，后台可能有Windows更新在偷偷下载、有网盘在同步文件、有智能电视在预加载视频，这些流量加起来早就把上行或者下行带宽吃满了。你以为“没人用网”，其实设备们都在背着你干活。排查方法就是登录路由器后台，在流量统计或者设备管理列表里看看每台设备的实时速率，找到那个传输速率异常高的设备，该限速的限速，该关后台的关后台。
无线性能瓶颈更是常见。有些路由器位置放得不合理，摆在电视柜最底层，旁边还有金属外壳的功放，信号被遮蔽得严重。你可以用手机装个Wi-Fi分析类的App，站在经常出现卡顿的房间里看一下信号强度和信道占用情况。如果是隔了两堵墙的老房子，5G频段很难穿墙，你可以考虑把路由器换成支持Mesh组网的方案，或者用电力猫、AC+AP做弥补，单纯调设置是救不回物理上的信号衰减问题的。
6. 实战复盘：三个典型网络故障的完整排查过程
6.1 案例一：公司办公室晚上六点准时断网
这个案例我印象很深，因为故障的时间点太规律了，每天晚上六点之后网络开始卡顿，七点左右彻底断线，第二天早上上班又自己恢复了。同事们的第一反应是“有人在下载什么东西”，宿管大爷的第二反应是“运营商晚上限速”，我听完他们的猜测，还是按分层的思路来排查。
周五晚上六点，我拿了一台笔记本，直接插网线接在核心交换机上，先Ping网关，正常；再Ping公网IP，一开始正常，到了某个时间点开始连续丢包。这基本排除了内网的问题，把方向锁在出口链路上。我登录路由器看了日志，发现WAN口在每天这个时间点都会反复断线重拨，拨号日志里有一行“远程服务器无响应”。我怀疑是运营商的光路或者机房端口问题，于是联系了运营商运维，让他们查一下这几个晚上是否有异常告警。结果还真是运营商机房的一台汇聚交换机端口性能劣化，到了晚高峰数据量一大就崩。后来运营商把端口换到另一台设备上，问题彻底解决。
这个案例的关键在于：我没有花时间去内网抓包，也没有怀疑员工的电脑，而是通过Ping测试把故障范围一步步缩小，最终锁定在运营商侧。如果你跳过这些验证直接重启路由器和交换机，这个故障可能永远也定位不了，因为问题根本不在你自己的设备上。
6.2 案例二：家里网络“时好时坏”，换了路由器也没用
这个案例是我一个亲戚家的。他们反映的问题很典型：手机连着Wi-Fi，有时候看视频很流畅，有时候加载半天，而且手机显示Wi-Fi信号是满格的。他们先后换过两台路由器，也把宽带升了千兆，问题依旧。我去他们家之后，没有急着看路由器，而是先问了一句：这个路由器用了多久了？答案是三年多，一直放在客厅角落的弱电箱里。
打开弱电箱我就发现问题了。那个弱电箱是铁的，无线路由器塞在里面，Wi-Fi信号要被铁箱屏蔽掉一大半，加上箱内空间封闭、散热极差，摸一下路由器外壳明显发烫。高温导致路由器芯片降频、无线模块不稳定，所以表现出来的就是“时好时坏”。我建议他们把路由器从弱电箱里拿出来，放到客厅的开放位置，如果嫌难看，就用网线把光猫和路由器连接，把路由器放到电视柜上。他们照做之后，网络稳定性立竿见影。
这个案例里，物理层的散热和摆放位置才是真正的故障根源。如果只是重启路由器、升级固件、换设备，能短暂改善但无法根治。这也验证了一句话：物理层的问题如果用上层的手段去解决，只能靠运气。
6.3 案例三：电脑连不上网但手机可以，问题竟然在内存
这个案例比较特别，把标题里提到的内存颗粒故障也串起来了。一台老台式机，用户反映“开机后经常上不了网”，具体表现是网卡显示已连接，但无法Ping通网关，重启电脑偶发恢复。网线、路由器、交换机、IP配置全部检查过，都没问题，而同一台路由器下，手机和其他电脑上网都是正常的。
我后来发现，这台电脑在网卡工作不正常的那个时间段，整机运行明显卡顿，打开任务管理器看到内存占用非常高，而且系统日志里有大量的“硬件错误”记录。我怀疑是内存故障导致驱动加载异常、网卡DMA传输失败，于是用MemTest86做了一次内存检测。MemTest86是一款独立于操作系统运行的内存测试工具，它把内存划分成多个测试区块，通过写入、读取、校验不同模式的比特数据来定位颗粒级别的故障。跑了大概三个小时，果然在其中一个测试项里报出了错误地址，而且每次都落在同一个内存地址区间。那个区间对应的物理位置后来也确认了——插槽上的某颗内存颗粒已经不稳定了。
更换内存之后，网卡再也没出现过类似问题。这个案例对我们的启发是：分层排查并不局限于网络协议栈的七层，它更是一种系统性的思维。网络业务跑在硬件之上，当网络问题遇到“硬件底子”不稳时，该跨出网络查一下系统、查一下内存和硬盘，也是分层的精髓。物理层不只是网线和光纤，电信号的搬运最终靠的还是设备内部的芯片和总线，内存颗粒坏了，会影响一切依赖它的功能，包括网络协议栈的处理过程。所以遇到这种诡异的网络故障，不要忽略对设备本身硬件健康状况的验证。
7. 常见问题与排查技巧速查表
7.1 六类高频故障现象与快速定位方向
我整理了这些年最常遇到的网络故障现象和它们对应的排查方向，你可以把它当成一份随身速查表来用。需要提醒的是，这里的“定位方向”不是绝对的结论，而是告诉你先往哪一层去看，后续仍然要按步骤验证。
| 故障现象 | 最可能的故障层 | 首选排查动作 |
|---|---|---|
| 完全断网，光猫LOS灯亮 | 物理层（外线光路） | 检查光纤弯折、接头松动，联系运营商 |
| Wi-Fi信号满格但上网慢 | 物理层/链路层（无线干扰） | 换信道、检查路由器摆放位置 |
| 电脑能上微信但打不开网页 | 应用层（DNS/代理） | 检查DNS设置和浏览器代理 |
| 局域网设备互访不通 | 网络层（IP/子网掩码/网关） | 核对IP配置，Ping网关验证 |
| 视频卡顿但测速正常 | 应用层/传输层（MTU/带宽占用） | 检查MTU设置，查看后台流量占用 |
| 设备频繁掉线且系统卡顿 | 硬件层（内存/网卡/主板） | 用MemTest86或类似工具做硬件健康检测 |
看到表格的时候请注意，现象和故障层不是一对一的关系。同一个“上不了网”的表现，背后可能是五种不同的原因，这也是为什么我强调按顺序排查，而不是拿着现象直接跳到某一层。盲目跳到某一层，本质上和盲目重启没有区别，都是赌运气。
7.2 需要学会的几条关键命令
命令不在多，管用就行。我日常工作里用的网络排查命令其实就那么几条。Windows系统下，ipconfig /all查看网卡完整配置，ipconfig /release和ipconfig /renew强制重新获取IP地址，ping -t持续Ping直到手动停止，tracert -d不解析域名显示路径，nslookup查询DNS解析记录，pathping结合了Ping和Tracert的功能可以看每一跳的丢包率。macOS和Linux系统下，ifconfig查看网卡配置，ping -c 4只Ping四次防止无限执行，traceroute -n不做域名反向解析，dig可以更精确地查看DNS解析结果。
这些命令不需要背，但你要理解每一条的输入和输出代表什么。我见过有人拿到故障现场只会执行一个ipconfig，看到IP是正常的就开始发慌，不知道接下来该看什么。这就是没有把命令和分层思维结合起来的典型表现。命令是工具，分层思维是地图，地图在手，工具才有意义。
7.3 我的独家避坑经验
最后分享几个我个人的经验，可能不太会出现在官方文档里，但你实操的时候大概率会用到。
第一，排查之前先拍照记录现状。不管是命令行输出、路由器后台界面、还是指示灯状态，先拍照留存。因为很多故障是间歇性的，等你回头复现的时候它可能已经恢复了，照片能帮你复盘。
第二，不要同时修改多个参数。很多人排查的时候手快，一下子改了IP、改了DNS、关了防火墙，结果问题解决了，但根本不知道是哪个改动起了作用。正确做法是每次只改一个变量，验证有效再改下一个。
第三，把时间点记下来。某些网络故障有很强的时间规律，比如晚高峰出问题、每隔三小时断一次、每小时掉线几十秒。这些时间规律是定位故障的重要线索。我处理过的一例就是设备定时重启，原因是一个机房的定时脚本每周四凌晨执行维护，而某个交换机的自动恢复策略刚好在那个时间点判断失误，不记录时间点根本发现不了这种巧合。
第四，内存检测这类硬件工具要常备一个。作为运维或重度用户，电脑上常备一个MemTest86的启动U盘不亏，遇到那种解释不通的诡异故障，花几个小时排除掉硬件因素，比你在软件上瞎折腾一整天要高效得多。特别是那种重启后短暂恢复、随后又出问题的网络故障，硬件不稳定的嫌疑很高，给它跑一遍内存检测，数据会告诉你答案。
8. 写在最后：分层排查是一种习惯
做网络故障排查这些年，我最大的体会是：工具和命令都是死的，人脑里的排查框架才是活的。你甚至可以不懂那些高深的协议细节，只要掌握“从底层往上层一层层验证”这个习惯，面对任何网络故障都会有底气。盲目重启只是暂时把问题掩盖了，分层排查才是真正把问题挖出来。
我不提倡你死记硬背任何排查顺序，因为每个网络环境都不一样。但“先物理后逻辑、先内网后外网、先连通后体验”这个原则，放在任何场景下都通用。遇到问题的时候，先深呼吸，按顺序走一遍，绝大多数故障都能在你到达应用层之前就露出真面目。
如果你现在正在为一个反复出现的网络问题头疼，不妨试着不急着拔电，拿起电脑，敲下一条Ping命令，从最底层开始，一层一层往上排查。方法就在这篇文章里，过程可能会多花一点时间，但它能帮你真正解决问题，而不是暂时把它赶走。
