1. 排障之前先想清楚为什么是这10个命令干网络运维这行十几年我越来越觉得排障这件事本质上不是比谁命令记得多而是比谁的排查路径最短、最快定位到故障域。你手里攥着几十条命令真到了客户机房或者远程跳板机上能条件反射敲出来的来来回回就那么十来条。这不是偷懒是经验收敛的结果——高频命令之所以高频是因为它们覆盖了从物理层到应用层最常见的故障面。我见过不少刚入行的兄弟遇到“网络不通”四个字就懵要么上来就重启设备要么把能敲的命令全敲一遍输出刷了一屏最后自己都不知道在看什么。问题出在没有建立“分层排查”的思维模型。网络排障最忌讳的就是无头苍蝇式乱撞你得先判断故障大概落在哪一层再选对应的命令去验证或排除。这篇文章我打算把网络工程师运维排障里最常用的10个命令掰开揉碎讲一遍。不是那种“命令大全”式的罗列而是结合我实际踩过的坑讲清楚每个命令什么时候用、怎么读输出、输出异常说明什么、下一步该往哪查。涉及到的命令包括 ping、tracert/traceroute、ipconfig/ifconfig、netstat/ss、nslookup/dig、arp、route、telnet/nc、tcpdump、curl。这些命令在 Windows、Linux、macOS 上略有差异我会分别说明。适合谁看刚入行的网络运维、系统管理员、技术支持以及需要经常处理“连不上”“时通时断”“访问慢”这类问题的开发同学。如果你已经是有经验的老手也可以看看我在“输出解读”和“避坑经验”部分有没有你还没注意到的细节。提示本文所有命令示例均在合法授权的自有实验环境中执行请勿在未授权的网络环境中进行扫描或探测。2. 第一梯队连通性验证三件套2.1 ping最基础也最容易被误读的命令ping 排第一没有任何争议。它基于 ICMP 协议向目标发送 Echo Request等待对方回 Echo Reply从而判断IP 层是否可达以及往返时延。很多人以为 ping 通就代表网络没问题ping 不通就代表网络断了这两种理解都不准确。先说 ping 通的情况。ping 通只能说明你的机器到目标 IP 的 ICMP 报文能来回不代表目标服务在监听、不代表端口开放、不代表应用层正常。我遇到过太多次“ping 得通但网站打不开”的案例最后查出来是目标服务器 80 端口没起、防火墙拦了 TCP、或者 DNS 解析错了。所以 ping 通只是排除了“IP 层完全不可达”这一种可能别把它当成万能通行证。再说 ping 不通。ping 不通的原因太多了目标主机宕机、中间路由不可达、防火墙丢弃了 ICMP、目标禁 ping、源地址选错、甚至你自己网卡没配好。ping 不通不等于网络断只等于“ICMP 这条路走不通”。这时候你要做的不是反复 ping而是换工具、换源地址、换目标去缩小范围。几个我常用的 ping 参数值得记牢# Linux/macOS ping -c 4 192.168.1.1 # 发4个包就停避免无限刷屏 ping -i 0.2 192.168.1.1 # 间隔0.2秒快速探测 ping -s 1472 192.168.1.1 # 指定payload大小配合MTU排查分片问题 ping -I eth0 192.168.1.1 # 指定源接口多网卡环境必用 ping -M do -s 1472 目标IP # 禁止分片探测路径MTU:: Windows ping -n 4 192.168.1.1 ping -l 1472 192.168.1.1 ping -S 192.168.1.100 目标IP :: 指定源地址 ping -t 192.168.1.1 :: 持续pingCtrlC停止关于 MTU 探测这里有个计算过程值得说清楚。以太网默认 MTU 是 1500 字节其中 IP 头 20 字节、ICMP 头 8 字节所以 payload 最大是 1500 - 20 - 8 1472 字节。如果你ping -s 1472能通说明路径 MTU 至少 1500如果提示“需要分片但设置了 DF 标志”说明路径上某段 MTU 小于 1500通常是 PPPoE 环境1492或者隧道环境。这个技巧在排查“小包能通、大包卡死”的问题时特别管用。输出解读方面重点看几个指标丢包率、时延抖动、是否有 dup。丢包率持续大于 0 就要警惕偶尔一个丢包可能是正常拥塞。时延突然从 5ms 跳到 200ms说明路径上出现了拥塞或绕行。至于dup!这个提示意思是收到了重复的 Echo Reply通常意味着网络里存在环路或者重复的响应比如有人做了 ARP 欺骗、或者链路层出现了广播风暴。我遇到过一次 dup 泛滥最后查出来是两台交换机之间网线接成了环路STP 没生效。注意有些云服务器默认禁 ping你 ping 不通不代表机器挂了去控制台看监控或者用 telnet 测端口更靠谱。2.2 tracert / traceroute看清数据包走了哪条路ping 告诉你“通不通”tracert 告诉你“怎么通的”。它利用 IP 头的 TTL 字段逐跳递增 TTL让路径上每一跳路由器回一个 ICMP 超时报文从而画出完整路径。Windows 叫tracertLinux/macOS 叫traceroute。# Linux traceroute -n 8.8.8.8 # -n 不解析域名速度快 traceroute -T -p 443 目标IP # 用TCP探测443端口绕过ICMP封锁 traceroute -I 目标IP # 用ICMP探测:: Windows tracert -d 8.8.8.8 :: -d 不解析域名 tracert -h 10 8.8.8.8 :: 最多10跳读 tracert 输出重点看三件事。第一在哪一跳开始出现超时或延迟骤增。如果前几跳正常第 5 跳开始全是*说明问题大概率出在第 5 跳附近。第二路径是否符合预期。比如你访问同城服务器结果路径绕到了外省甚至境外那延迟高就有解释了。第三是否有环路。如果 IP 地址反复出现说明路由配置有问题。这里有个常见误区tracert 中间某几跳显示*不代表故障。很多路由器出于安全策略不回应 ICMP 超时但会正常转发数据。所以判断标准是最终能否到达目标而不是中间每一跳都有响应。我一般会结合-T参数用 TCP 探测因为很多网络对 ICMP 限速甚至丢弃但对 TCP 443 放行。还有一个实战技巧带源地址 tracert。多网卡或者有多个出口的机器默认走的路由可能不是你想要的。用traceroute -s 源IP 目标IP指定源地址能验证特定出口的路径质量。这个在排查“走专线慢、走公网快”这类问题时非常有用。2.3 ipconfig / ifconfig / ip先确认自己站在哪排障第一步永远是确认本机网络配置。你连自己 IP、网关、DNS 是什么都不知道后面全是瞎猜。Windows 用ipconfigLinux 老版本用ifconfig新版本推荐ip命令。:: Windows ipconfig /all :: 看全部网卡详情包括MAC、DHCP、DNS ipconfig /release :: 释放DHCP ipconfig /renew :: 重新获取 ipconfig /flushdns :: 清DNS缓存改hosts后必做# Linux ip addr show # 看IP和网卡状态 ip route show # 看路由表 ip -s link show eth0 # 看网卡收发包统计和错误计数 ifconfig eth0 # 老命令看RX/TX errors我特别想强调ip -s link这个命令。它输出的RX errors、TX errors、dropped计数能直接告诉你物理层和链路层有没有问题。如果 errors 持续增长大概率是网线质量差、光模块故障、双工不匹配。有一次客户反馈“时通时断”我上去一看ip -s link里 errors 每秒都在涨换了根网线立马好了。这种问题你用 ping 和 tracert 是看不出来的因为丢包是间歇性的。另外ipconfig /all里的DHCP 租约时间和DNS 服务器也值得关注。如果租约快到期且续租失败IP 可能会变导致连接中断。DNS 配错则会出现“能 ping 通 IP 但域名解析不了”的经典问题也就是热搜里那个temporary failure in name resolution。3. 第二梯队端口与服务层排查3.1 telnet / nc测端口通不通的利器ping 通只证明 IP 可达要确认某个端口是否开放得用 telnet 或 nc。这两个命令的本质是尝试建立 TCP 连接连上了说明端口开放且服务在监听连不上说明端口关闭或被防火墙拦截。# telnet 方式 telnet 192.168.1.100 80 # nc 方式更推荐功能更强 nc -zv 192.168.1.100 80 # -z 只扫描不发送数据-v 显示详情 nc -zv 192.168.1.100 20-30 # 扫描端口范围 nc -zv -w 3 192.168.1.100 443 # -w 3 超时3秒Windows 默认没装 telnet 客户端需要在“启用或关闭 Windows 功能”里勾选或者用 PowerShell 的Test-NetConnectionTest-NetConnection -ComputerName 192.168.1.100 -Port 80这里有个关键区别要讲清楚telnet 连不上可能是端口没开也可能是防火墙拦了还可能是服务没起。怎么区分如果 telnet 提示Connection refused通常是目标机器可达但端口没监听服务没起如果一直卡住最后Connection timed out通常是防火墙丢包或者网络不通。这个区别在排障时能帮你快速定位是“服务问题”还是“网络问题”。我踩过的一个坑有次排查一个“SSH 连不上”的问题ping 通、telnet 22 端口超时我以为是防火墙查了半天发现是目标机器的 sshd 配置里ListenAddress绑定了错误的网卡。所以 telnet 超时不一定就是网络设备拦的也可能是服务端配置问题。注意部分系统出于安全考虑默认不安装 telnet 客户端生产环境建议用 nc 或 ssh 替代避免明文传输。3.2 netstat / ss看清本机连接状态netstat 是老牌命令ss 是它的现代替代品速度更快、信息更全。它们能告诉你本机有哪些连接、监听哪些端口、连接处于什么状态。# ss 常用组合 ss -tulnp # 看所有TCP/UDP监听端口及对应进程 ss -tan state established # 看已建立的连接 ss -tan state time-wait | wc -l # 统计TIME_WAIT数量 ss -s # 连接状态汇总:: Windows netstat -ano :: 显示所有连接和PID netstat -ano | findstr :80 :: 过滤80端口 netstat -ano | findstr LISTENING排障时我最常看的是TIME_WAIT 和 CLOSE_WAIT 的数量。TIME_WAIT 多是正常的主动关闭连接的一方会进入这个状态持续 2MSL通常 60 秒。但如果 TIME_WAIT 数量爆炸到几万可能会耗尽本地端口导致新连接建不起来。CLOSE_WAIT 多则是应用层没正确关闭连接的信号通常是代码 bug比如没调 close()。我遇到过一次 CLOSE_WAIT 堆积到上千最后查出来是某个服务处理完请求后忘了关闭 socket。另一个高频场景是端口被占用。启动服务时报Address already in use用ss -tulnp | grep 端口号找到占用进程的 PID再决定是 kill 还是换端口。Windows 上用netstat -ano | findstr :端口找到 PID再去任务管理器对。3.3 curl应用层排障的终极武器curl 严格来说不算“网络命令”但在运维排障里它的使用频率极高。它能模拟 HTTP 请求看到状态码、响应头、响应时间、重定向链路是判断应用层是否正常的直接手段。curl -I https://example.com # 只看响应头 curl -v https://example.com # 看完整请求响应过程 curl -o /dev/null -s -w DNS:%{time_namelookup} 连接:%{time_connect} 首字节:%{time_starttransfer} 总计:%{time_total}\n https://example.com curl --resolve example.com:443:1.2.3.4 https://example.com # 指定解析IP绕过DNS最后那个--resolve参数是我排查 DNS 问题时最常用的技巧。当你不确定是 DNS 解析错了还是服务器本身有问题用--resolve强制指定 IP如果通了说明是 DNS 问题如果不通说明是服务器或网络问题。这一招能省下大量扯皮时间。-w参数输出的时间分解也很有价值time_namelookup是 DNS 解析耗时time_connect是 TCP 握手耗时time_starttransfer是首字节时间。如果 DNS 耗时特别长说明 DNS 服务器慢或配置有问题如果 connect 耗时长说明网络延迟高或丢包如果 starttransfer 耗时长说明服务端处理慢。4. 第三梯队路由、ARP 与 DNS 深挖4.1 arp局域网排障绕不开的一环ARP 负责把 IP 地址解析成 MAC 地址是局域网通信的基础。很多“同网段不通”的问题根子就在 ARP。arp -a # 查看ARP缓存表 arp -d 192.168.1.1 # 删除某条ARP记录 arp -s 192.168.1.1 00:11:22:33:44:55 # 静态绑定:: Windows arp -a netsh interface ip delete arpcache :: 清空ARP缓存排障时看 ARP 表重点确认网关的 MAC 地址是否正确。如果网关 IP 对应的 MAC 地址变了可能是 ARP 欺骗也可能是网关设备换了。我遇到过一次内网大面积断网最后查出来是有人接了台路由器LAN 口 IP 配成了网关地址导致 ARP 冲突。用arp -a看到网关 MAC 频繁变化基本就能锁定问题。另外如果arp -a里目标 IP 显示incomplete或全零 MAC说明 ARP 请求没得到响应可能是目标不在线、或者中间有隔离。这时候可以配合arping命令进一步确认。4.2 route路由表决定数据包往哪走路由表是数据包转发的“导航地图”。本机路由配错数据包就会走错出口表现为“能 ping 通内网、上不了外网”或者“走错网卡导致时通时断”。ip route show # Linux 查看路由表 route -n # 老命令 ip route get 8.8.8.8 # 查看到某目标走哪条路由非常实用:: Windows route print route print -4 # 只看IPv4ip route get 目标IP这个命令我要重点推荐。它直接告诉你内核会选哪条路由、从哪个源接口出去比你自己对着路由表算要快得多。多网卡环境下默认路由可能走了你不期望的网卡用这个命令一查便知。路由排障的经典问题是默认路由缺失或冲突。如果ip route show里没有default via 网关这一条外网肯定不通。如果有两条默认路由且 metric 相同可能会出现负载不均或时通时断。这时候要检查是不是 DHCP 和静态配置打架了。4.3 nslookup / digDNS 问题一查便知DNS 是“能上 QQ 但打不开网页”这类问题的头号嫌疑犯。nslookup 和 dig 是排查 DNS 的标准工具。dig example.com # 完整解析过程 dig 8.8.8.8 example.com # 指定DNS服务器 dig short example.com # 只看结果 dig -x 1.2.3.4 # 反向解析 nslookup example.com # 交互式查询 nslookup example.com 8.8.8.8:: Windows nslookup example.com nslookup example.com 8.8.8.8 ipconfig /displaydns :: 查看本地DNS缓存 ipconfig /flushdns :: 清缓存排障思路是这样的先用nslookup 域名看默认 DNS 能不能解析。如果解析失败换nslookup 域名 8.8.8.8用公共 DNS 试。如果公共 DNS 能解析而默认 DNS 不能说明是你配置的 DNS 服务器有问题。如果都解析不了说明域名本身有问题或者网络到 DNS 服务器不通。dig的输出里重点看status字段。NOERROR是正常NXDOMAIN是域名不存在SERVFAIL是 DNS 服务器故障REFUSED是被拒绝。这几个状态码能帮你快速判断问题性质。另外ANSWER SECTION里的 TTL 值也值得看TTL 太短会导致频繁解析影响性能。5. 第四梯队抓包与深度分析5.1 tcpdump网络排障的“显微镜”前面所有命令都是“间接推断”tcpdump 是“直接看包”。当其他命令都无法定位问题时抓包是最后的手段也是最有力的手段。tcpdump -i eth0 -nn # 抓eth0所有包不解析域名和端口 tcpdump -i eth0 -nn port 80 # 只抓80端口 tcpdump -i eth0 -nn host 192.168.1.100 # 只抓某主机 tcpdump -i eth0 -nn -w capture.pcap # 写入文件用Wireshark分析 tcpdump -i eth0 -nn -c 100 # 抓100个包就停 tcpdump -i eth0 -nn tcp[tcpflags] tcp-syn ! 0 # 只抓SYN包抓包的核心是过滤表达式不然输出会淹没你。常用过滤维度有host主机、port端口、net网段、协议tcp/udp/icmp。组合起来用and、or、not。我排查“TCP 连接建立失败”时的标准流程先抓 SYN 包看有没有发出去再看有没有 SYN-ACK 回来如果 SYN 发出去了但没 SYN-ACK说明被中间设备拦了或者目标没监听如果 SYN-ACK 回来了但客户端没回 ACK说明客户端侧有问题。这一套下来问题基本就锁定了。注意tcpdump 需要 root 权限生产环境抓包要注意磁盘空间和性能影响建议加-c限制包数或-w写文件后离线分析。5.2 命令组合拳一个真实排障案例光讲单个命令不够我拿一个真实案例串一遍。客户反馈“内网某台服务器访问外网时通时断访问内网正常。”第一步ipconfig /all确认本机 IP、网关、DNS 配置正常。第二步ping 网关正常ping 外网IP时通时断丢包率 30%。第三步tracert 外网IP发现第一跳网关正常第二跳开始丢包。第四步arp -a看网关 MAC 正常排除 ARP 问题。第五步ip route get 外网IP确认走的是正确网卡。第六步tcpdump -i eth0 -nn host 外网IP抓包发现发出的包和回来的包数量对不上回来的少。第七步检查网卡ip -s link发现 TX errors 持续增长。结论网卡或网线物理层有问题导致部分包发送失败。换网线后恢复正常。这个案例里ping 和 tracert 定位了故障域tcpdump 和 ip -s link 确认了根因。排障不是靠一个命令而是靠命令之间的逻辑衔接。6. 常见问题速查与避坑经验6.1 高频问题速查表现象优先排查命令常见原因ping 不通 IPping、ipconfig、arpIP 配错、网关错、ARP 冲突ping 通但域名解析失败nslookup、dig、ipconfig /flushdnsDNS 配错、DNS 服务器故障ping 通但端口连不上telnet、nc、ss服务没起、防火墙拦截时通时断ping -t、ip -s link、tcpdump物理层故障、环路、拥塞访问慢tracert、curl -w、dig路径绕行、DNS 慢、服务端慢大量 dupping、arp、tcpdumpARP 欺骗、网络环路连接建立失败tcpdump、ss、netstat防火墙、服务未监听、端口耗尽TIME_WAIT 过多ss -tan state time-wait短连接频繁、端口耗尽风险6.2 我踩过的坑与实操心得坑一ping 通就以为万事大吉。前面说过ping 通只代表 ICMP 可达。有次客户说“网络没问题ping 都通”结果一测端口全被防火墙拦了。所以排障一定要分层验证IP 层、传输层、应用层逐层确认。坑二忽略源地址选择。多网卡机器上ping 和 tracert 默认走的源地址可能不是你期望的。用-ILinux或-SWindows指定源接口用traceroute -s指定源 IP能避免很多误判。坑三tracert 中间跳超时就慌了。中间路由器不回 ICMP 是常态只要最终能到达目标就没问题。判断标准是终点不是中间每一跳。坑四DNS 缓存没清。改了 hosts 或者 DNS 记录后本地缓存可能导致解析结果不对。Windows 用ipconfig /flushdnsLinux 看systemd-resolved或nscd状态该重启就重启。坑五抓包不看时间戳。tcpdump 默认输出时间戳分析时一定要结合时间看。比如 SYN 发出后 3 秒才收到 SYN-ACK说明网络延迟高如果一直没收到说明被拦了。时间维度是抓包分析的关键。坑六生产环境乱敲命令。有些命令有副作用比如arp -d会清缓存导致短暂中断ip route del可能直接断网。生产环境操作前一定要确认影响范围能只读就别写。6.3 命令速记口诀最后分享一个我自己总结的排查顺序口诀方便记忆先看自己ipconfig/ip再探连通ping后查路径tracert端口服务telnet/nc连接状态ss/netstat路由 ARProute/arpDNS 解析nslookup/dig抓包兜底tcpdump应用验证curl。这个顺序基本覆盖了从底层到应用层的完整排查链路遇到问题按这个顺序走大概率能快速定位。这套命令和思路我在实际工作中用了很多年从传统机房到云环境都适用。工具会更新命令会变化但分层排查、逐层验证的核心逻辑不会变。把这条逻辑刻进脑子里比背一百条命令都管用。
