1. 从“能上网”到“会排查”差的是一套分层的脑子今天抽空把最近整理的网络排查笔记重新捋了一遍标题就叫“记一下”因为它确实不是什么体系化的教程更多是我在实际工作中踩坑、试错、查资料之后留下的记录。但整理完发现这些散落的知识点串起来之后恰恰能回答一个很核心的问题为什么明明“能上网”出问题的时候却连问题出在哪都不知道。先说我能做什么。这篇文章覆盖的内容包括网络分层的底层逻辑、日常排查工具的详细用法、IP地址与子网的快速计算、Wireshark抓包看TCP握手、以及几类最常见的断网故障的完整排查实录。适合谁看如果你平时的工作要碰网络——不管是运维、开发、测试还是经常被亲戚朋友喊去修路由器的“IT热心人”这篇都能给你一套可以照着做的排查思路。别说你都会真正遇到“微信能发但网页打不开”这种问题时很多人第一反应是清缓存而不是先判断是DNS、MTU还是代理的锅。网络这东西表面上是“插根网线就能用”但一旦出问题入口其实只有两三条物理链路、地址解析、数据转发。只要把这几个环节的排查逻辑理顺了绝大多数问题都能在十分钟内定位到根因。这也是我写这篇笔记的初衷——把无序的经验变成有序的方法。我自己的体会是搞网络最忌讳一上来就“猜”。哪怕你经验再丰富没有证据链的猜测都是玄学。真正靠谱的排查一定是自下而上、逐层验证的每一步都有命令输出做依据每一步都能排除一类可能。下面我就把这套完整的方法论拆开讲。2. 排查网络的底层逻辑先定位再动手2.1 网络是分层协作的不是一根线从头通到尾很多非科班出身的朋友学网络第一个卡住的概念就是“分层”。我打个比方网络传数据就像寄快递。你写好了包裹应用层贴上地址IP层交给快递公司传输层快递公司开车走公路链路层和物理层。每一层只负责自己的事但任何一层出了问题包裹都到不了。这个类比放在排查里非常重要。因为绝大多数故障本质上是“某一层坏了”而不同层坏掉的表现形式完全不同。比如物理层断了表现是“完全没网”IP层配错了表现是“内网通外网不通”DNS出问题表现是“能上QQ但打不开网页”TCP端口被封表现是“能ping通但连不上服务”。你只有知道每一层负责什么才能通过现象反推问题在哪一层。具体的分层模型大家背过OSI七层、TCP/IP四层但我更建议你直接用TCP/IP四层来思考问题因为实际排查看的就是这四层链路层网线、Wi-Fi、交换机、网络层IP、路由、传输层TCP/UDP端口、应用层HTTP、DNS、DHCP。四层之间是严格的依赖关系下层不通上层一定不通但下层通了上层也未必通。2.2 排查顺序为什么必须是“从底到顶”知道了分层排查顺序就呼之欲出了从底层开始逐层往上验证。很多新手喜欢直接抓包看应用层报文折腾半天发现是网线松了这就是顺序错了。先确认物理层和链路层通不通再谈IP和端口最后才看应用。我总结了一个五步定位法实测下来非常稳第一步看物理链路状态网线灯亮不亮、Wi-Fi信号强不强第二步验证本机IP配置IP、掩码、网关有没有问题第三步ping网关和公网地址确认网络层是否通第四步查DNS解析看域名能不能正确解析成IP第五步验证端口和服务状态确认传输层和应用层是否正常。每一步的命令几乎都是固定的ipconfig、ping、nslookup、telnet、tracert。把这些命令的输出读明白你就能像医生看化验单一样一项项排除病因。我见过最典型的案例是某台服务器从外地迁回来后应用一直报超时所有人都在调应用配置最后我用tracert一看数据包到运营商骨干网就断了纯粹是路由绕路的问题跟应用半毛钱关系没有。3. 高频排查工具ping、tracert、DNS解析的进阶用法3.1 ping不只是“通不通”延迟和丢包才是关键ping可能是大家用得最多的命令但大多数人只会在“通”和“不通”之间判断浪费了大量信息。实际上ping输出里的延迟time和丢包率loss才是真正有价值的指标。延迟高意味着链路质量差。比如内网ping网关延迟在1ms左右是正常的如果到了10ms甚至更高说明链路存在拥塞或者无线干扰。丢包则更严重丢包率超过1%就值得警惕超过5%基本可以断定链路不稳定。我在排查网络卡顿问题时第一件事就是在服务器上持续ping网关和公网IP各100个包对比两者的延迟和丢包率就能快速区分是内网问题还是运营商问题。ping的命令参数也值得记一下Windows和Linux略有差异。Windows下ping -t是持续pingping -n 100是发100个包Linux下对应的是ping -c 100。还有个大坑默认ping包很小测不出带宽瓶颈真要测大流量下的稳定性用ping -l 1400Windows或ping -s 1400Linux来模拟接近MTU上限的包这样才能暴露出分片或者MTU不匹配的问题。注意ping通不代表服务正常。ICMP协议和业务端口是两回事很多服务器禁ping但服务完全正常。判断服务是否可用必须验证具体端口后面会细说。3.2 tracert/traceroute定位“断在哪一跳”当ping公网IP不通时下一步就该用tracertWindows或tracerouteLinux了。它的原理是利用IP包的TTL生存时间字段每经过一个路由器TTL减一当TTL减为0时路由器会返回一个ICMP超时消息这样就能逐跳记录路径。tracert的作用非常直接如果数据包在内网就断了比如卡在网关那一跳问题在自己这边如果前几跳正常、到运营商骨干网断了很可能就是运营商线路问题如果全部超时则要考虑防火墙封了ICMP或者路由黑洞。我遇到过一种很有意思的情况tracert到了第10跳开始全是*但最终目的地其实是通的这就是因为中间路由器不响应ICMP属于正常现象别被吓到。tracert还有一个冷门但实用的功能看路由绕路。正常情况从国内访问某地10跳左右能到如果发现路径绕了二三十跳甚至出国再回来延迟一定会高。做跨地域应用优化时我经常先用tracert对比不同机房的线路质量绕路少的那个延迟和稳定性都会更好。3.3 DNS解析前端排障中最容易被忽略的环节DNS可以说是“看起来简单、坑最多”的服务。它解决的问题只有一个把域名翻译成IP地址。翻译失败或者翻译错误表现非常迷惑——你以为网络不通其实网络好好的是“地址本”出了问题。查DNS最基础的命令是nslookup。在Windows下输入nslookup 域名会返回域名解析到的IPnslookup 域名 8.8.8.8则可以指定DNS服务器来查询。这里有个关键技巧如果本机解析不了但用8.8.8.8能解析说明问题出在你配置的DNS服务器上而不是网络本身。我遇到过最典型的DNS坑是缓存污染。某用户反馈“网站打不开”但我用手机流量访问一切正常。一看他电脑nslookup解析出来一个陌生的IP明显是之前中过病毒或者手动配过错误的DNS。这种问题清DNS缓存ipconfig /flushdns只是治标要把DNS服务器改成可信的地址才治本。还有一类更隐蔽路由器强行下发错误的DNS给所有设备导致全家所有设备都上不了网排查时经常被忽略。4. IP配置与子网计算手算比看教程快得多4.1 为什么“/24”比“255.255.255.0”更直观很多人配置IP时看到子网掩码是255.255.255.0但换成/24就懵了。其实/24就是子网掩码的简化写法它表示IP地址前24位是网络位后8位是主机位。记住一个公式2^(32-前缀长度) - 2就是可用IP数。比如/24主机位是8位可用IP是2^8-2254个减去的2个是网络地址和广播地址。我在配置服务器静态IP时最常用的三段是/24254个IP、/25126个、/302个。/30在点对点链路里非常常用刚好够一条线路两端用的IP。很多人不理解为什么不用/24省事非要抠那点地址——在公网IP紧缺的场景下一个/30和/24的差价可能就是几千块一个月这不是小事。4.2 手算子网靠“256-掩码值”解决90%的场景有个土办法我用了很多年比任何子网计算器都快用256减去掩码的最后一个非零字节就能得到这个子网的“块大小”。比如掩码是255.255.255.192256-19264说明这个子网是每64个IP一段。0到63是一个网段64到127是一个网段以此类推。举例来说IP是192.168.1.100掩码是255.255.255.192那么100落在64到127这一段网络地址就是192.168.1.64广播地址是192.168.1.127可用IP是65到126。整个过程30秒心算完成。这个方法在排查“IP冲突”“网段划分错误”时特别好使因为很多配置错误都是因为网段算错了导致的。注意配置WAN口连接光猫和LAN口连接内网的网段时务必让两端不在同一个子网。我见过有人把WAN口和LAN口都配成192.168.1.x结果内网数据包的下一跳直接走错接口造成整个网络瘫痪。这是新手配置路由器时最高频的坑没有之一。4.3 DHCP到底怎么选地址从客户端视角看IP分配静态IP适合服务器和打印机普通设备还是交给DHCP省心。但DHCP出问题时的表现是挺迷惑的设备显示“已连接但无法访问互联网”或者IP地址变成了169.254.x.x。这个169.254.x.x是APIPA自动私有IP地址只有一种含义设备发出DHCP请求后没有得到服务器的响应。排查DHCP问题时我通常分三步第一步确认设备能不能拿到IP用ipconfig /release然后ipconfig /renew重新获取一次第二步看DHCP服务器的地址池是否耗尽很多路由器默认就分配100个IP设备一多就遭殃第三步检查是不是有人手动配了静态IP和DHCP地址池冲突了。这个“静态IP和DHCP打架”的情况在企业里天天发生靠的是做一个规范的IP地址分配表而不是出了问题才去查。5. 抓包与协议分析把看不见的流量拉到明面上5.1 Wireshark三大过滤器掌握这三个就能干活抓包听起来很高大上其实日常工作用到的功能就那么几个。Wireshark的复杂度在于它给的信息太多反而让人不知道看什么。我的建议是先掌握三个过滤器就能解决九成的分析需求。第一个是IP过滤器在过滤栏输入ip.addr 192.168.1.100只看指定IP的流量适合排查单台设备的通信问题。第二个是端口过滤器tcp.port 443只看某个端口的流量适合排查服务连接问题。第三个是协议过滤器直接输入dns、http、arp只看对应协议的报文适合排查DNS劫持、ARP攻击这类问题。我举个例子。实际分析“网页很慢”的问题时用http过滤器抓包如果发现大量TCP重传TCP Retransmission基本可以判定链路丢包严重不是服务器慢。如果看到“TCP Dup ACK”频繁出现则说明网络存在乱序或者丢包。这些特征不看包是根本没法判断的全靠猜的话永远找不到真相。5.2 三次握手到底长什么样从抓包里认识TCPTCP三次握手是面试必考但只有真正在Wireshark里看过一遍你才算学会。三次握手的过程是客户端发SYN包服务器回SYNACK包客户端再回ACK包。在Wireshark里这个顺序清晰可见正常连接的标志是这三个包之间有明确的前后关系并且源端口和目标端口正确对应。排查连接问题时最有效的办法就是看握手的完成度。如果只看到SYN包没有回应说明服务器根本没收到或者被防火墙拦了如果看到SYN和SYNACK都正常但最后的ACK没发出问题多半出在客户端。有一次我排查两台服务器之间连接超时抓包看到服务器回了SYNACK但客户端一直没有响应后来发现是客户端的防火墙把入站连接给拦了典型的“单通”问题。提示抓包时最好使用抓包过滤器而不是显示过滤器。抓包过滤器在抓包前就生效可以减少无用数据显示过滤器只是暂时隐藏数据还是占内存。比如host 192.168.1.100 and port 8080就是抓包过滤器的语法。5.3 TCP重传与RST两种最常见的异常信号抓包经验多了之后你会发现TCP异常其实就两类重传Retransmission和连接重置RST。重传意味着包发出去了但对方没确认可能丢了也可能延迟太大超时了。频繁重传会带来一个直观后果页面加载慢、文件传输效率低。判断重传严重程度有个简单标准看抓包文件里重传包占总包数的比例如果超过1%就要认真查链路质量了。RST则代表连接被强制终止。两种情况最多一是端口没服务目标机器直接回RST表示“这里没人听电话”二是防火墙主动干预比如安全组规则禁止了该端口的访问。我曾经排查过一个诡异问题内网访问某服务偶尔成功偶尔失败抓包后发现失败时服务器回了RST往上查发现在服务前面挂了台负载均衡它的健康检查把异常后端的连接直接重置了。这是典型的“不是网络问题是应用架构问题”的案例抓包一锤定音。6. 断网故障排查实录与速查表6.1 四个最常见场景的快速定位表把日常工作中遇到的断网问题整理一通我发现高频率故障基本上就四大类单台设备无法上网、多台设备同时断网、能上内网不能上外网、能发消息但打不开网页。每种问题对应的排查起点完全不同。故障现象优先排查点核心命令常见根因单台设备无法上网本机IP配置、DNSipconfig /allIP冲突、DNS配置错误多台设备同时断网路由器/网关、运营商线路ping 网关、tracert路由器死机、运营商故障内网通外网不通默认网关、NATroute print、ping 114.114.114.114网关丢失、路由错误能发消息但网页打不开DNS解析、代理设置nslookup 域名DNS污染、代理异常这张表的价值在于它给了你一个最优先的检查项。网络故障的根因成千上万但现象和根因之间是有强关联的先处理概率最高的可能性绝大多数问题可以在两分钟内解决。6.2 案例一电脑能上微信但打不开网页这个案例我处理过不下十次每次都有新发现。先说最典型的原因DNS配置错误。微信用的是IP直连和固定的服务器端口不走域名解析而浏览器打开网页的第一步就是解析域名DNS坏了网页自然打不开。很多人一遇到这种问题就重装系统其实一条nslookup命令就能查到真相。排查流程是先ping一下www.baidu.com看看能不能解析成IP如果提示找不到主机再用nslookup指定公共DNS解析试试。能解析就说明是本地DNS服务器问题改一下DNS地址就好。另外还有一个隐藏原因系统代理被修改。不少软件安装时会顺手把系统代理改成127.0.0.1:端口如果端口没有对应服务浏览器就开不了网页而微信不走代理表现就是“微信正常网页全挂”。这种问题直接在Windows设置里关闭“使用代理服务器”即可。6.3 案例二无线网络频繁掉线无线掉线是个混合型问题涉及物理层、链路层和射频环境。我遇到最典型的场景是办公区几十台设备挤在几个AP无线接入点上2.4GHz频段信道全是邻居的路由器信号互相干扰严重。表现是信号满格但网速很慢时不时掉线重连。排查无线问题第一步是确认信道干扰。手机上装个Wi-Fi分析工具看看周围哪些信道最拥挤然后把AP固定到相对空闲的信道。多数人用默认配置2.4G全挤在1、6、11这三个信道里完全是互相伤害。第二步是检查AP的带机量。入门级家用路由器带机量可能只有10到20台企业里一台AP接了50个终端不卡才怪。第三步看漫游设置如果办公区有多个AP终端频繁在不同AP之间切换掉线率会明显上升这种情况要调整漫游阈值。注意Wi-Fi信号“满格”不等于“质量好”。信号强度和信号质量是两回事满格可能只是离得近但同频干扰严重的话照样卡成狗。看质量要看信噪比SNR一般要高于25dB才算干净。6.4 案例三内网一切正常外网全部不通这类故障多数出在网关或者路由上。我的排查顺序是先ping网关确认内网通再ping一个公网IP地址比如114.114.114.114确认有没有去外网的路由如果公网IP能通但域名不通问题在DNS如果公网IP都不通就要查NAT和默认路由。在Windows下用route print看一下默认路由是否存在很多时候故障原因是默认网关被改掉了——比如手动配置IP时忘了填网关或者有设备在局域网里“抢”网关IP。在Linux服务器上则要看ip route确认默认路由指向了正确的网关接口。另外还有一种隐蔽情况路由器WAN口拨号断了但LAN口还是通的表现就是“内网互访正常出不去外网”登录路由器看一眼拨号状态就知道了。7. 写在最后把每次排障都变成自己的笔记我不是科班网工出身这些知识全是靠一次次故障“喂”出来的。干了这些年我最大的体会是网络排查这个技能真正值钱的不是背了多少协议而是有没有一套稳定的方法论。遇到问题不慌、按层排查、用证据说话、记录下来形成自己的知识库——这套流程比任何单点知识都重要。具体到做笔记这件事我现在的习惯是每次处理完一个故障就按“现象描述、排查过程、根因分析、解决方案、预防措施”五段式记录下来存在本地笔记里。时间久了这就是属于你自己的故障排查手册。下次再遇到类似问题搜一下关键词十分钟内基本能定位。这个方法我推荐给所有做运维、开发、甚至只是喜欢折腾网络的朋友刚开始会觉得麻烦坚持半年后会发现自己排查效率翻了一倍不止。最后分享一个小技巧排查网络问题时永远记得“一变一验”。每做一次修改就重新验证一次现象不要连着改三个地方再一起验证。这样即使最终修好了你也知道到底是哪一步起了作用。这个习惯能让你的排查记录变成真正有价值的知识积累而不是一笔糊涂账。