干这行久了你会发现一个很残酷的事实大家排查网络问题的时候命令都会敲工具都会用但真正到了判断结果这一步很多人是靠感觉的。ping一下网关通着就觉得网络没事tracert看到星号就觉得运营商有问题nslookup能解析出IP就觉得DNS正常。可是延迟35ms算快还是慢丢包3%要不要报障解析耗时200ms正不正常这些细节如果不搞清楚你发出的每一句网络没问题都可能是在给自己埋雷。这篇文章不打算重复那些工具怎么安装、参数怎么敲的基础教学重点是讲清楚一件事每个常用网络工具的输出结果到底按什么标准去判断。我会结合自己做过的实际排查项目把延迟、丢包、路由、DNS、端口这些维度一条一条拆开讲也会给出一些我平时自己用的阈值和经验值。准备接手网络运维的、刚从开发转过来做基础设施的、或者公司网络经常出问题但说不清楚原因的朋友这篇应该能帮你把判断网络正不正常这件事变成一个可量化的动作。1. 先说清一个前提通不通和快不快是两套完全不同的判断逻辑很多排查之所以混乱是因为把两个维度混在一起了。ping能通说明的是路径通着但它回答不了这条路径适不适合跑当前业务。反过来一个接口偶发超时也可能是链路质量抖动而不是端口不通。所以拿着工具判断网络之前先想清楚你现在查的是哪类问题。1.1 连通性故障判断标准是能不能建立通信这类问题最典型的表现就是业务报错、网页打不开、服务器连不上。排查目标很简单数据包能不能从A走到B中间有没有断点。这时候你该关注的是ping目标地址通不通能不能ping通内网、公网网关、目标服务器telnet或nc测试端口TCP层握手成不成功curl接口或网页HTTP层拿没拿到响应tracert路由路径从哪一跳开始数据包不再有回应。这一环节的判断逻辑是非黑即白的要么通要么不通。中间状态比如有时通有时不通通常说明链路质量差但这已经进入第二类问题了。1.2 性能质量故障判断标准是延迟、丢包、抖动三个量化指标链路明明是连着的但业务就是卡。在线会议掉帧、视频转圈、数据同步慢、音频断续这些都属于性能类问题。判断标准有三个核心数字延迟Latency一个数据包从发出到收到回应的时间单位毫秒。它决定了一个交互要等多久。丢包Packet Loss发出的数据包中丢失的比例。它决定了链路靠不靠谱TCP遇丢包会降速重传UDP遇丢包就直接丢内容了。抖动Jitter相邻两个数据包延迟的差值波动。它决定了实时音视频的稳定程度延迟高但稳定还能忍抖动大才是画面卡顿的元凶。有了这三把标尺你再去跑ping、tracert、测速工具就知道自己盯着哪些数字看了。下面每一节我都会围绕这些阈值展开。2. ping命令的判断标准不是通了就算正常要看延迟、丢包、TTL三层数据ping是所有人最熟悉的排查工具但它恰恰是被误读得最严重的一个。你以为ping通了就OK其实它输出的每一栏都有含义尤其是ICMP回显请求的往返时间、丢包统计以及TTL值这三点。2.1 延迟的区间判断从网关到跨地域不同场景的正常值不一样延迟是分场景的不能拿一个固定值套到所有环境里。我自己平时常用的判断区间大致是这样的网络范围正常延迟区间需要关注的阈值可能的原因局域网内ping网关/交换机0-5ms大于10ms且持续内网环路、设备CPU占用高、无线干扰同城网络ping同城服务器5-20ms大于30ms运营商链路拥塞、路由绕路国内跨省如北京到广州30-60ms大于80ms骨干网拥塞、路由异常绕行国际链路120-200ms大于250ms海底光缆拥塞、国际出口带宽不足卫星/特殊链路500ms以上稳定即可物理特性决定不适合实时业务注意上面说的是持续两个字。单次ping延迟高说明不了太多路由设备对第一个包的处理本身就偏慢ICMP响应优先级也经常被调低。我见过很多人看到第一次ping出现300ms就紧张其实连续跑到几十个包再下结论比较稳妥。ping -c 100目标地址或者Windows下ping -n 100跑完再看平均值和最大值才有参考价值。另外延迟的稳定性比绝对值更重要。如果平均值50ms但最大和最小之间差了80ms这条链路做远程桌面、视频会议一样会卡。所以看ping的结果我会按顺序看三个数平均延迟、丢包率、最大延迟。最大延迟如果远超平均值说明链路里有间歇性的拥塞或队列缓存积压。2.2 丢包率的分档0.5%就能感觉到卡1%就该查了ping命令结束前会统计丢包率比如Windows下显示Lost 0 (0% loss)。很多人看到不是100%丢包就觉得没事这是最常见的认知误区。对于语音和视频这类实时应用来说丢包率非常敏感0% - 0.5%链路基本健康日常网页浏览、邮件、文件传输无感。0.5% - 1%TCP应用会开始出现轻微重传连续大量数据的传输速度会打折扣语音通话开始出现可闻的杂音。1% - 5%明显的链路质量问题。视频会议会卡顿、掉线数据库长连接可能出现中断下载速度明显低于带宽上限。5%以上基本属于严重故障HTTP访问都可能超时任何实时应用都无法工作。这里有个经验点ping的丢包和业务丢包并不完全相同。因为ICMP是独立于TCP的一些网络设备为了保CPU会把ICMP的优先级调低或者在繁忙时直接丢弃ICMP。所以如果ping出现小比例丢包不要急着下结论再用TCP层面的测试去验证一下。反过来ping完全正常也不能证明业务稳定某些防火墙规则会放行ICMP但对特定端口做限速这种情况我后面讲到端口工具时会再展开。2.3 TTL值变化不是只有减1还有起始值的判断逻辑TTLTime To Live本意是防止数据包在网络里无限循环每经过一个路由器就减1减到0就丢包。但TTL的实际价值远不止防环它还能帮你判断对方的操作系统类型和路径距离。首先要记住不同系统的默认TTL起始值Windows系统默认TTL为128Linux系统默认TTL为64各类网络设备Cisco等常用255某些老版本Unix系统默认255。假设你ping一台服务器返回的TTL是52。按最常见的64作为起始值来算64 - 52 12说明中途经过了大概12跳。如果返回值是112多数对应的起始值128那就是Windows主机经过了16跳。这个推理在跨设备多厂商环境里不能当成铁证但作为初期判断已经够用。更关键的是当你在同一个目标上观察到TTL突然变小可能意味着路由路径变了。比如原来ping过去TTL是52过了一阵变成45中间多了7跳那多半是出口链路切换了或者发生了路由绕行。特别是跨国链路这种TTL跳数变化往往对应着延迟的明显恶化及时对比有助于发现线路切换问题。3. DNS解析工具的判断标准解析出IP不代表解析过程是健康的nslookup和dig是排查域名解析问题的主力工具但不少人看见命令返回了一个IP地址就直接关掉窗口认为DNS没问题。实际上一个完整的解析过程有很多可以出问题的地方需要关注的维度包括解析耗时、返回状态码、使用的服务器、以及缓存情况。3.1 nslookup和dig的字段里哪些值得细看先看一个典型的nslookup输出Server: 114.114.114.114 Address: 114.114.114.114#53 Non-authoritative answer: Name: www.example.com Address: 93.184.216.34这里有两处关键信息需要判断第一Server和Address是不是你预期的DNS服务器。很多人排查的时候根本没注意当前用的是哪个服务器搞了半天其实是公司强制下发的DNS配置覆盖了手动设置。如果解析结果来自一个你不认识的服务器优先怀疑DHCP下发的配置是否被篡改或者有个网关地址在劫持DNS。第二Non-authoritative answer说明这是一个非权威应答也就是从缓存或其他递归服务器拿到的结果不代表域名本身的真实记录状态。如果怀疑解析数据被缓存污染就要直接查询权威服务器上的记录。这时候用dig 目标权威服务器 域名 A来指定权威服务器发查询对比权威服务器返回的IP和本地解析的IP是不是同一个值。dig输出里还有几个判断要点status字段NOERROR表示正常NXDOMAIN表示域名不存在Query time本次查询耗时ANSWER SECTION里的TTL缓存还能生效多久SERVER实际响应的DNS服务器IP。3.2 解析耗时的判断标准什么区间算正常什么算拉胯DNS解析耗时这个指标很容易被忽略但它直接影响用户访问网站的首屏速度。解析快慢要分两种情况看缓存命中如果域名在本地DNS缓存里解析几乎是毫秒级应在0-10ms内返回。如果超过20ms大概率不是缓存命中而是走了递归查询。递归解析完整的递归流程需要从根服务器逐级查下来正常一般在10-100ms之间。国内访问公共DNS如223.5.5.5、114.114.114.114解析一个没有缓存的域名50ms左右都算正常。异常范围单次解析超过200ms或者反复波动就需要警惕了。解析慢的原因通常有几个配置的DNS服务器本身响应慢、上游递归链路拥堵、网络到DNS服务器路径延迟大。判断标准还有一条隐藏逻辑如果本地解析很快但用dig 8.8.8.8指定其他服务器解析却慢问题多半出在你这边网络到这个公共DNS的链路上而不是域名本身。反过来如果本地和公共DNS都慢那域名所属的权威服务器响应慢的概率更大。3.3 DNS返回码的归属判断不是所有失败都叫解析失败DNS的故障表现五花八门不同返回码对应的问题完全不同处理方向也完全不同。常见的几类返回码/现象含义优先排查方向NOERROR但无记录请求成功但查询类型下无资源记录确认查询类型是否写错域名是否真的没有这个记录NXDOMAIN域名本身不存在域名是否拼错DNS配置是否遗漏SERVFAIL服务器处理查询失败上游权威服务器异常、区域传送失败、服务器配置错误REFUSED服务器拒绝查询是否用了非法的递归源地址权限配置问题超时服务器没有响应网络链路到DNS服务器不通、防火墙拦截UDP53、DNS服务器过载返回IP与预期不符解析成功但数据异常DNS劫持、缓存污染、DNS服务器被篡改这里分享一个我自己踩过的坑公司某业务域名突然大量解析到海外IP页面打开极慢。当时先用nslookup解析返回正常IP没细看就排除DNS原因。后来用dig查了一次才发现本地用的是缓存服务器的结果权威服务器上解析出的根本不是同一批IP。在混合云和多DNS服务商环境下本地缓存的结果和权威记录不一致的情况并不少见所以任何DNS异常判断都应该加一步权威查询来对照。4. 路由追踪类工具定位延迟拐点与丢包衔接点的读图术tracertWindows和tracerouteLinux/macOS是定位延迟到底是从哪一段开始恶化的关键工具。但很多人只是看一眼哪一跳打了星号就报障运营商链路有故障这种判断过于粗放也很容易误判。4.1 每一跳的数值应该怎么读星号到底是不是故障看一下典型输出1 1ms 1ms 1ms 192.168.1.1 2 8ms * 9ms 10.10.0.1 3 12ms 11ms 13ms 61.148.3.1 4 * * * Request timed out. 5 50ms 48ms 52ms 202.97.40.1这里有几个常见误读第一某一跳出现*不一定是故障。很多骨干路由器出于安全或性能考虑直接不对ICMP做响应但这不代表数据包没经它转发。判断链路的依据要看后续跳数是否仍然有响应。只要后续跳数能继续返回数据前面跳数的星号多半只是设备不回应探测包不需要紧张。第二如果某一跳三个包全部超时且之后的每一跳也全部超时那么问题就出现在这条链路上了。这往往是运营商节点防火墙拦截ICMP导致的但更严谨的做法是同时跑TCP层的路径探测如tcptraceroute或mtr的TCP模式来二次确认。第三第一跳延迟就很高。有人用tracert发现第一跳跳到网关就花了10ms以上就开始怀疑路由器坏了。这个结论不可靠因为家用宽带的光猫或路由器可能做了限速某些设备对ICMP处理慢。我建议以多次采样的中位数来综合判断。4.2 延迟拐点的判断从哪一跳开始延迟骤增问题就从哪一段开始算延迟拐点latency spike point是路由追踪最核心的信息。看一个例子1 1ms 网关 2 8ms 城域网A 3 12ms 城域网B 4 11ms 城域网C 5 80ms 省骨干节点 6 80ms 省骨干节点2 7 79ms 目标服务器运营商这个场景里第4跳到第5跳延迟从11ms跳到80ms之后一直稳定在80ms左右。说明链路在第4跳到第5跳之间进入了一条高延迟的骨干线路。如果目标服务器在另一个城市这个80ms尚可接受但如果第4跳是本地运营商的节点而第5跳到省骨干就多了70ms那可能出现了路由绕行比如本该直连的骨干路径走了备用线路。判断延迟拐点还要警惕一种倒挂现象。有时候第3跳显示100ms第4跳降到20ms后边都很正常。这种情况更多是设备对探测包的响应策略不同如CPU处理拥塞时ICMP排队延迟不一定代表链路真实延迟有先高后低。所以我不会单独依赖一次tracert就判断拐点至少跑两到三次取一个稳定形态专业一点的做法是叠加使用pathping或mtr统计每个节点的丢包率并持续采样。4.3 丢包衔接点的定位孤立丢包和连续丢包是两种不同的信号丢包在路由追踪里的读法和延迟一样要看发生位置和延续性某一跳出现少量丢包但后续跳数丢包率降到0多数是当前设备对ICMP做了限速数据转发本身没有受影响。从某一跳开始丢包率持续上升且后续所有跳数都持续丢包故障点在当前跳数和上一跳之间基本可以锁定是这段链路的问题。目标节点本身丢包中间节点都正常问题大概率在最后一公里也就是目标服务器本机负载、带宽跑满或者其前置防火墙的会话表满导致丢弃。mtr命令在Linux环境很常用它会持续发送探测包并统计各跳的丢包率和延迟中位数比tracert的三次采样可靠得多。我处理跨机房断连时通常让mtr跑300秒然后看每一跳的Loss列。如果源机房出口那一跳Loss是0但中间某通Loss突然到了30%而且在同一区间持续那么这一段就是真正需要报障和重点排查的目标。5. 端口与协议层工具连通性判断要穿透到TCP和HTTP层ping和tracert停留在网络层它们证明了有路可走但证明不了门是开的。业务访问一个服务器真正决定成败的是TCP端口能否完成握手、HTTP层能不能返回预期状态码。这一层用到的工具看似简单判断标准却有不少讲究。5.1 用telnet或nc测试端口的三种结果对应三种结论telnet 目标IP 端口或nc -vz 目标IP 端口是判断TCP层连通性最直接的手段。结果只有三类立即连接成功Connected to/succeeded目标端口正常监听且防火墙放行三层四层都通畅。目标不可达No route to host说明三层即网络层就打不通跟端口无关先回头查路由、链路。连接被拒绝Connection refused网络层通了但是目标端口没有服务在监听。常见原因包括应用没有启动、服务绑定了其他IP、防火墙用RST直接拒绝。一直卡住直到超时timed out这是最需要小心的。通常意味着防火墙把包静默丢弃了也就是DROP策略。主机可能活着端口也可能活着但中间的安全设备不放行这个端口。我举一个实际案例某业务无法登录ping目标IP通了但telnet 目标IP 443超时。当时开发判断是应用挂了但SSH登录服务器后发现服务进程正常监听443只是试了从服务器本机curl https://127.0.0.1也正常。问题定位在安全组对源IP的限制上属于云平台网络ACL拦截。这个案例提醒我们端口超时大多数时候要查中间安全设备而不是查服务器本身先看本机回环访问是否正常能快速切割问题范围。5.2 curl的返回码和耗时HTTP层面的健康判断现代网络排查里curl其实是比ping更贴近真实业务的工具。因为业务走的是HTTP不是你发多少个ICMP包。判断标准分两部分状态码层面2xx正常响应。3xx发生了重定向如果请求的是API接口却拿到302多半是鉴权中间件或者域名跳转配置问题。401/403鉴权或者权限问题链路健康业务配置层面的故障。404请求路径不存在检查访问的URL和网关路由规则。5xx服务端异常。此时链路和端口都是通的问题在应用或服务依赖上。耗时层面curl -w可以输出详细的时间拆解重点看两个字段time_connectTCP握手耗时这个值超过200ms就说明TCP链路本身不快可能是跨地域或拥塞。time_total整个请求完成时间。如果time_connect只有20ms但time_total到了1500ms问题不在网络而在服务端处理或后端依赖这能帮你把判断依据从网络层切换到应用层。这就是为什么我说curl的判断标准要基于分布TCP握手快是网络好整体响应慢是服务慢。单看一个time_total无法区分必须拆开看。5.3 netstat和ss的本地状态怎么看端口处于什么状态也算正常在服务器本机排查时netstat -anptLinux或ss -ant输出中的状态枚举也很关键。判断标准不只是端口有没有LISTEN还包括连接状态的合理性LISTEN服务正常监听这是预期的状态。ESTABLISHED有活跃TCP连接属于正常现象但如果数量暴增则需要看是不是连接泄漏。TIME_WAIT主动关闭连接的一方会进入这个状态通常2分钟左右由内核回收。TIME_WAIT大量积压并不直接等于故障但对高并发短连接场景比如Nginx频繁连后端可能耗尽端口资源Linux下数万个TIME_WAIT时值得优化keepalive和FIN_WAIT超时参数。SYN_SENT本机在发起连接但没收到回应对应的就是前面说的超时状态链路或对端防火墙有拦截。CLOSE_WAIT对端关闭了连接但本地应用没调用close通常是程序没处理对端断开积压多了会耗尽文件描述符。判断ss输出时要结合业务场景不能看到TIME_WAIT就喊有问题。一个标准的HTTP短连接服务TIME_WAIT多恰恰说明连接正常关闭了真正要警惕的是CLOSE_WAIT只增不减那才是代码层面忘记关闭连接的特征。6. 带宽、抖动和真实体验测速工具的数字要怎么换算成实际感受测速网站和下载工具是普通人判断网络最常用的方式但也是最容易被误解的。下载速度达到预期相当于网络没问题不一定。反过来测速低就一定是运营商问题也不一定。测速工具的数字需要一套自己的判断标准。6.1 测速结果的判断要区分瞬时速率和稳定速率运营商宣传的100M宽带是指100Mbps换算成字节是12.5MB/s。但实际能跑到多少受很多因素约束其中就包括测速服务器的远近、无线干扰和并发能力。这里有一个很关键的判断方法看单线程还是多线程。大多数测速网页为了跑出高数字会开多个并发连接同时下载。多线程跑满带宽不代表真实体验好因为很多应用比如网页加载主文件、远程桌面协议依赖单连接的速率。判断方法很简单用一种同时能看到单线程和多线程的测速工具或者下载一个热门资源文件观察单连接速度。如果多线程能跑到100Mbps而单线程只有20Mbps说明带宽本身够但网络时延或中间设备的流控影响了单连接速率这对实际业务的影响比带宽数字更直接。另外测速至少跑30秒以上。很多瞬时测速工具的峰值数字会在5秒内拉满但随后由于TCP拥塞收敛或运营商限速策略稳定速率会掉下来。判断网络有没有达标应该看30秒左右的中后段稳定速率而不是一开始那个脉冲。6.2 jitter抖动实时音视频体验的真正主导指标前面讲的是延迟和带宽但实际开会、打语音电话的时候抖动的影响比延迟大得多。判断抖动的标准从实时应用的角度去定义抖动低于10ms音视频通话体验很稳几乎感觉不到卡顿。抖动10ms-30ms偶发可感知的延迟波动但大多数情况下不影响理解。抖动超过30ms视频会议会明显出现卡顿声、画面冻结或频繁缓冲语音断续需要重点排查。测抖动的方法连续ping几千个包把相邻两次延迟的差值求平均或者使用iperf配合-u和-i参数直接测UDP抖动。很多人忽略这一点只看平均延迟说60ms还行但实际上抖动到了40ms用在视频会议里一样难受。所以遇到明明带宽和延迟都正常但开会卡成PPT的情况把抖动这个指标加进去问题往往立刻浮出水面。6.3 测速数字正常但体验依然差要去看路由器NAT表、无线信道和DNS这是很多家庭和办公室的经典谜案测速显示带宽很高但打开网页明显慢、视频加载卡。判断这种问题要把测速结果和业务特征对照起来看测速用的是就近CDN节点地理位置近延迟低所以跑满了带宽但业务访问的目标服务器在另一个很远的地方链路延迟和丢包才是短板。这时候该做的是curl -w去测目标服务器而不是继续纠结在测速网站的数字上。无线网络场景下测速端和真实终端可能处于不同信道。同一个路由器5GHz信号能跑满宽带但2.4GHz信道拥塞时连一半都达不到。别急着骂运营商先换频段、换测速终端对比。路由器NAT会话表耗尽也会导致测速偶尔正常、日常频繁卡。这种问题单靠测速发现不了得看路由器的连接数统计或者在高并发时用netstat观察大量连接处于SYN_SENT来判断。7. 几个容易误判的实战教训和我的交叉验证顺序工具分析到最后一节我想分享一些个人经历都是实打实翻过车的判断错误。网络排查里最怕的不是网络有问题而是工具跑了半天最后结论给错了方向。7.1 单工具结论导致误判的真实案例有一回处理某办公室网速慢的工单我一开始用测速软件测下载速度达标延迟也稳定于是判断网络没问题结果业务方坚持说访问内网OA系统奇卡无比。后来用curl -w去测OA服务器的time_total和time_connect发现TCP握手只要几毫秒但time_total飙到三秒以上。问题根本不在网络链路而是OA服务器后端数据库响应极慢连接被拖住了。这就是单工具结论带来的误判——测速软件只证明了你到测速节点的链路好证明不了你到业务节点的端到端质量。另一个翻车案例是判断Wi-Fi问题时我盯着路由器管理页面的信号强度看显示-55dBm觉得信号很好。但实际上周边信道干扰严重空口冲突导致实际吞吐掉到不足1Mbps。从这之后我判断无线网络一定会做两件事同时看信道占用情况和丢包重传率而不是只看信号强度一格两格。判断标准要跟具体场景绑定不同场景对应不同的正常区间。7.2 多工具交叉验证的通用顺序经过这些教训后我自己总结了一套交叉验证的顺序平时排查问题基本是这个套路ping网关和ping公网IP确认基础链路和默认路由正常。如果网关都丢包先解决局域网问题。nslookup/dig查域名解析确认解析IP正确、解析耗时正常并且用权威服务器二次对照。telnet或nc测目标端口确认TCP握手能完成把网络层和传输层连通性一次打通。curl -w测HTTP确认业务层响应时间是否合理拆解time_connect和time_total。最后用mtr或tracert跑一下完整路径如果前面哪一步有问题这步来定位是哪个环节的延迟拐点和丢包点。这五步的顺序是有讲究的先快后慢先近后远先层后业务。每一步都有明确的判断标准对应前面几节讲过的阈值区间。每步正常则继续往下某步异常就知道问题卡在哪一层不用盲目全链路排查。7.3 记录基线数据是最高效的长期判断方式最后分享一个容易被忽略但价值极高的习惯给网络环境建立基线baseline。平时在网络正常的时候就把ping延迟、DNS解析耗时、curl接口耗时这些数据记录下来存上几组历史快照。真正出故障的时候拿着基线去对比判断标准就不再是网上说多少毫秒算正常而是比正常时候多了多少倍。比如正常时候ping网关稳定1ms某天突然变成8ms不用等什么丢包率超阈值这个变化本身已经足够触发排查。建立基线前可能反应迟钝建立基线后你往往能在用户感知到问题之前就发现异常。有条件的团队可以把这个过程自动化没条件的话每次主动做一次小规模巡检把结果存成文本记录也比出了问题才靠感觉去猜强太多。说到底网络工具的判断标准并不是一张写满数字的表而是一套知道每层该看什么、每个数字代表什么、每个场景正常值大概是什么区间的思维框架。工具书和搜索引擎能告诉你怎么敲命令但判断力只能来自一次次背着基线去对比、去复盘、去推翻自己。下次再有人说网络时好时坏你至少可以理直气壮地问一句你说的好和坏具体是延迟多少毫秒、丢了多少个包、哪一跳开始断的能问出这一句判断标准这件事你基本就算过关了。