网络工程师这个行当干久了你会发现一个规律真正拉开排障效率差距的往往不是谁背的路由协议多而是谁能在最短时间内用最朴素的工具把问题范围圈定下来。我见过太多同行一遇到网络抖动就急着翻日志、抓包、上监控大屏折腾半小时才想起来——连ping都没跑一遍。这十个命令说白了就是网络排障的听诊器看着简单但每一个都有它的脾气和适用边界。用对了三分钟定位问题用错了或者只知其一不知其二反而会被误导。这篇文章我按实际排障场景来拆不讲手册式的参数罗列重点说清楚每个命令在什么情况下用、怎么读结果、以及那些文档里不会写的坑。1. ping最熟悉的陌生人你真的会读它的输出吗1.1 ping的底层逻辑决定了它的能力边界ping这个命令几乎每个接触网络的人都用过但很多人对它的理解停留在通不通这个层面。它的工作原理是发送ICMP Echo Request报文等待目标返回ICMP Echo Reply。这里有个关键点ICMP是网络层协议它不依赖TCP或UDP所以ping通只能说明IP层可达不代表目标端口开放、不代表应用层正常。我遇到过好几次运维新人ping通了服务器就认为服务没问题结果用户反馈打不开页面——因为Web服务根本没起来但主机是活的。另一个容易被忽略的是很多防火墙和云平台的安全组默认丢弃ICMP报文。你ping不通一台主机不代表它挂了可能只是ICMP被策略拦截了。这时候需要换用TCP层面的探测手段比如telnet或nc去探端口。所以我的习惯是ping不通先别下结论结合其他信息判断。1.2 那些让人抓狂的ping报错信息怎么解读排障时最常遇到的几种ping返回每一种背后指向的问题完全不同Request Timed Out请求超时数据包发出去了但在超时时间内没收到回复。可能原因包括目标主机宕机、中间路由丢弃了ICMP、防火墙拦截、或者回程路由有问题。注意超时和不可达是两回事。Destination Host Unreachable目标主机不可达通常是本地路由表里没有到达目标的路径或者ARP解析失败。这个报错往往指向本地网络配置问题。Temporary Failure in Name Resolution这是DNS解析失败压根没到网络层。先检查DNS配置和域名是否正确。大量DUP!说明收到了重复的回复。这通常意味着网络中存在环路或者有设备在做异常的二层转发。我碰到过一次交换机端口镜像配置错误导致ICMP回复被复制了两份排查了半天才发现是镜像口的问题。提示ping的时候养成带参数的习惯。ping -c 10指定次数ping -i 0.2加快发送频率ping -s 1472测试MTU1472281500。这些参数在特定场景下能帮你快速验证假设。1.3 带源地址ping多网卡环境下的必备技能服务器有多块网卡、多个IP的时候默认ping会从路由表选一个源地址出去。但路由表选的未必是你想测的那条路径。比如一台机器同时有内网IP和公网IP你想验证从内网接口到某台内网设备的连通性就得用ping -I eth1或ping -S 192.168.1.100来指定源接口或源地址。Windows下用ping -S指定源地址。这个技巧在排查策略路由、多线路负载均衡问题时特别有用因为不同源地址走的路由策略可能完全不同。2. tracert/traceroute路径探测的利器但别被星号骗了2.1 tracert和traceroute的机制差异Windows下叫tracertLinux和macOS下叫traceroute功能类似但实现机制有区别。tracert默认用ICMP Echo Request而traceroute默认用UDP高端口通常是33434起。这个差异导致在某些网络环境下tracert能看到完整路径traceroute却全是星号反过来也有。原因是中间设备对ICMP和UDP的处理策略不同。traceroute在Linux下可以加-I参数改用ICMP加-T参数改用TCP SYN。当你发现默认的UDP探测被拦截时试试traceroute -T -p 80 target用TCP 80端口探测往往能穿透那些只放行TCP的防火墙策略。2.2 星号不代表断点要结合前后跳判断很多人看到tracert输出里某一跳是星号就慌了以为那里断了。实际上星号只表示那一跳的设备没有返回ICMP超时报文可能只是该设备配置了不响应但数据包照样转发。判断是否真的断了要看星号之后还有没有后续跳。如果星号之后还有正常的跳数说明路径是通的只是中间某台设备不回应而已。真正需要警惕的是从某一跳开始全是星号直到结束。这才可能意味着路径在那个位置中断了。但即便如此也要考虑目标是否只是屏蔽了ICMP。2.3 路径中的延迟突增怎么分析tracert输出里每一跳有三个延迟值这是发三个探测包的结果。如果某一跳延迟突然从几毫秒跳到几百毫秒而后续跳的延迟又降回来了那这一跳的高延迟很可能是该设备自身处理ICMP探测包的优先级低导致的不代表转发性能差。真正说明问题的是延迟从某一跳开始持续升高且不再回落这才指向该段链路存在拥塞或质量问题。我一般会结合mtrMy Traceroute来做持续探测它相当于tracert加ping的组合能实时看到每一跳的丢包率和延迟变化比单次tracert更有说服力。3. ipconfig/ifconfig本机网络状态的第一手情报3.1 ipconfig /all里那些容易被跳过的关键字段Windows下ipconfig /all输出的信息量很大但很多人只看IPv4地址就完事了。其实有几个字段在排障时非常关键DHCP已启用/否确认是静态配置还是动态获取。如果是DHCP还要看租约获取时间和过期时间。默认网关本机出网的下一跳。如果网关地址不对或者为空外部通信肯定有问题。DNS服务器域名解析依赖它。DNS配错是能ping通IP但打不开网页的头号原因。媒体状态显示已断开连接说明物理链路或驱动层面有问题这时候查IP配置没有意义得先解决链路问题。3.2 隧道适配器是什么要不要管它在Windows的ipconfig输出里经常能看到一堆隧道适配器条目比如isatap、Teredo、6to4等。这些是IPv6过渡技术产生的虚拟接口正常情况下不影响IPv4通信。但如果它们获取到了异常地址偶尔会干扰路由选择。我遇到过一台Windows 11机器Teredo隧道适配器获取了一个地址后导致部分网站访问异常禁用Teredo后恢复正常。排查方法是在设备管理器里显示隐藏设备找到对应的隧道适配器禁用即可。3.3 Linux下ifconfig逐渐被ip命令取代但还没到淘汰的时候现在主流Linux发行版推荐用ip addr和ip link替代ifconfig因为ifconfig属于net-tools包很多新系统默认不装了。但实际排障中ifconfig的输出更直观尤其是查看RX/TX errors和dropped计数时一眼就能看出网卡是否有丢包。ip -s link也能看统计但格式没那么友好。在CentOS 7上如果提示ifconfig命令找不到装一下net-tools就行yum install -y net-tools。openSUSE上则是zypper install net-tools。这个没什么技术含量但新手经常卡在这里。4. netstat/ss连接状态和端口监听的全景图4.1 netstat -anp的输出怎么快速定位问题netstat -anpLinux或netstat -anoWindows能列出所有连接和监听端口。排障时我主要关注几个状态LISTEN服务正在监听正常。ESTABLISHED已建立的连接。如果某个服务连接数异常多可能是被攻击或者有连接泄漏。TIME_WAIT连接正常关闭后的等待状态。大量TIME_WAIT说明短连接频繁可能需要调整内核参数。CLOSE_WAIT这个状态大量出现说明应用程序没有正确关闭连接是代码层面的问题不是网络问题。Windows下用netstat -ano拿到PID后再去任务管理器里对照是哪个进程这个流程虽然笨但很实用。4.2 ss命令为什么比netstat快ss是net-tools套件中netstat的替代品它直接读取内核的socket信息不走/proc文件系统所以在连接数很多的时候速度优势明显。常用组合是ss -tulnpt表示TCPu表示UDPl表示监听n表示不解析域名p表示显示进程。一条命令就能看到所有监听端口和对应的进程比netstat利索得多。注意ss的-p参数需要root权限才能看到所有进程信息普通用户只能看到自己的进程。4.3 如何判断端口是否真的在监听有时候服务配置文件改了端口重启后却连不上。先用ss -tulnp | grep 端口号确认端口是否在监听。如果没监听问题在服务端配置如果监听了但外部连不上问题可能在防火墙或安全组。这个二分法能帮你快速缩小排查范围。5. telnet/nc端口连通性测试的轻量级方案5.1 telnet虽然老但测端口是真好用telnet 目标IP 端口号能直接测试TCP端口是否开放。连上了说明端口通连不上或者超时说明被拦截或服务没起来。Windows默认没开telnet客户端需要在启用或关闭Windows功能里勾选。Linux上装telnet包即可。但telnet有个问题它不支持UDP端口测试也不支持超时设置。遇到防火墙丢包的情况telnet会卡很久才返回。这时候用nc更好。5.2 nc的灵活用法nc -zv 目标IP 端口是测试TCP端口的经典用法-z表示只扫描不发送数据-v表示输出详细信息。加-w 3设置超时3秒避免卡死。UDP端口用nc -zuv 目标IP 端口但UDP的探测结果不如TCP可靠因为UDP本身无连接没有回复不代表端口关闭。nc还能用来快速传输文件、做临时监听但在排障场景下端口探测是它最高频的用途。6. nslookup/digDNS问题排查的标准入口6.1 nslookup的交互式用法nslookup 域名能快速看域名解析到哪个IP。但更实用的是交互模式直接输入nslookup回车然后server 8.8.8.8指定DNS服务器再输入域名查询。这样可以对比不同DNS服务器的解析结果判断是本地DNS问题还是权威DNS问题。如果本地DNS解析异常但指定公共DNS正常说明本地DNS服务器或缓存有问题。Windows下可以用ipconfig /flushdns清缓存Linux下根据发行版不同用systemd-resolve --flush-caches或重启nscd服务。6.2 dig的输出更专业dig 域名返回的信息比nslookup详细得多包括ANSWER SECTION、AUTHORITY SECTION、查询耗时等。dig short 域名只返回解析结果适合脚本调用。dig 8.8.8.8 域名指定DNS服务器查询。dig -x IP做反向解析。排查DNS问题时我习惯用dig trace 域名来追踪整个解析链路从根域名服务器开始一步步看到最终的A记录能精确定位是哪一级解析出了问题。7. arp局域网内IP和MAC的映射关系7.1 arp -a看什么arp -a列出本机ARP缓存表显示IP和MAC的对应关系。在局域网排障中如果ping不通同一网段的主机先看ARP表里有没有对方的MAC。如果没有说明ARP解析失败可能是对方关机、IP冲突、或者VLAN配置有问题。如果ARP表里同一个IP对应了两个不同的MAC那基本可以确定是IP冲突或者ARP欺骗。这时候需要找到冲突的设备可以通过交换机管理界面查MAC地址表来定位端口。7.2 清空ARP缓存有时候ARP缓存里的条目过期或错误会导致通信异常。Windows下arp -d *清空所有条目Linux下ip neigh flush all。清空后系统会重新发起ARP请求往往能解决一些莫名其妙的连通性问题。8. route/ip route路由表的查看与临时调整8.1 路由表决定了数据包往哪走route printWindows或ip route showLinux显示本机路由表。排障时重点关注默认路由0.0.0.0/0指向哪里以及特定网段的路由是否正确。如果一台机器有两个网卡分别连不同网络路由表的优先级决定了数据包从哪个接口出去。Windows下route add可以临时添加路由Linux下ip route add。这些命令在测试阶段很有用但重启后会失效永久路由需要写配置文件。8.2 路由环路怎么发现如果tracert显示数据包在两三个IP之间来回跳那就是路由环路。这种情况通常出现在动态路由协议配置错误时。临时解决办法是在其中一台设备上添加一条静态路由打破环路根本解决需要检查路由协议配置。9. tcpdump抓包是终极手段但别一上来就用9.1 什么时候该抓包抓包是排障的终极武器但也是最耗时的。我的原则是ping、tracert、端口测试都做完问题范围缩小到某个具体环节后再针对性地抓包。比如确认TCP三次握手是否完成、是否有RST包、TLS握手是否正常等。tcpdump -i eth0 host 目标IP and port 目标端口 -w capture.pcap是最常用的组合。抓完用Wireshark分析比在命令行里硬看效率高得多。9.2 抓包时的过滤技巧不加过滤的抓包会产生海量数据根本看不过来。常用过滤条件host 192.168.1.1只抓与该IP相关的包port 80只抓80端口的包tcp[tcpflags] (tcp-syn|tcp-fin) ! 0只抓SYN和FIN包看连接建立和断开icmp只抓ICMP包提示生产环境抓包要注意磁盘空间和性能影响加-c 1000限制抓包数量或者用-w写到文件后及时分析清理。10. mtr把ping和tracert合二为一的持续探测工具10.1 mtr为什么比单独用ping和tracert强mtrMy Traceroute结合了tracert的路径发现和ping的持续探测能实时显示每一跳的丢包率和延迟统计。单次tracert只能看到某一时刻的快照而mtr跑几分钟后你能清楚看到哪一跳持续丢包、哪一跳只是偶尔抖动。mtr -r -c 100 目标IP以报告模式跑100次探测输出每一跳的Loss%、Snt、Last、Avg、Best、Wrst、StDev。这个报告拿给运营商或上游网络团队看比你说网络卡有说服力得多。10.2 丢包出现在哪一跳才算真问题mtr报告里如果中间某一跳有丢包但后续跳没有丢包那这个丢包很可能是该设备对ICMP探测的限速策略导致的不影响实际转发。真正需要关注的是从某一跳开始后续所有跳都有丢包且丢包率相近。这说明丢包发生在该跳之前的链路或该设备本身。这个判断逻辑和tracert的星号分析类似核心思想是中间设备的控制面响应不代表数据面的转发能力。11. 命令组合使用的实战排障思路11.1 从用户报障到定位问题的标准流程用户说上不了网我的排查顺序通常是ipconfig /all看本机IP、网关、DNS是否正常ping 网关确认局域网连通性ping 8.8.8.8确认外网IP层连通性nslookup 域名确认DNS解析是否正常tracert 目标确认路径是否正常如果以上都正常但应用打不开telnet 目标 端口测端口端口不通则检查防火墙策略端口通但应用异常则抓包分析这个流程覆盖了从物理层到应用层的完整链路每一步都能排除一类问题。11.2 几个典型故障场景的命令组合场景一能ping通IP但打不开网页nslookup 域名确认DNS解析ping 域名看解析出的IP是否可达如果DNS解析正常但网页打不开telnet 域名 443测HTTPS端口场景二网络时断时续mtr -r -c 200 目标跑长时间探测观察丢包是集中在某一跳还是分散结合ping -t持续ping观察断线规律场景三虚拟机ping不通宿主机检查虚拟机网络模式NAT/桥接/仅主机ipconfig确认虚拟机IP和宿主机是否同网段检查宿主机防火墙是否拦截了ICMP桥接模式下确认虚拟网卡是否绑定到正确的物理网卡11.3 那些年我踩过的坑说几个实际经历。有一次一台CentOS 7服务器突然无法ping通百度但ping内网正常。检查发现是/etc/resolv.conf被清空了DNS服务器地址丢失。原因是NetworkManager和手动配置冲突重启后覆盖了配置。解决办法是在网卡配置文件里加上DNS18.8.8.8让NetworkManager接管。还有一次Windows 11的机器ping 127.0.0.1报一般故障检查发现是hosts文件被修改127.0.0.1的映射被删了。恢复hosts文件后正常。这个案例说明排障时不要忽略hosts文件这个最基础的环节。再有一次交换机ping回环地址丢包但业务正常。后来发现是交换机CPU对ICMP的处理优先级低在CPU负载高时丢ICMP包但不影响转发。这种情况不需要处理知道原因就行。这些经验归结起来就是一句话命令的输出要结合上下文解读不能孤立地看某一个结果就下结论。网络排障没有银弹靠的是对每个工具能力边界的清晰认知以及一套有条理的排查方法论。把这十个命令用熟、用透大部分日常问题都能在十分钟内定位到方向。
