只会 ping，就像看病只会量体温——能发现有问题，定位不了病因。这篇不按命令罗列，而是按**排障顺序**把 10 个命令串成一条线：先看自己、再测通不通、再看断在哪一跳、再查域名、最后验端口。每一步告诉你敲什么、看什么、下一步往哪走。
第一步：先看自己 —— ipconfig
排障最容易跳过、也最容易白忙的一步，是先确认自己这台机器的配置是对的。
要看的就四行：IP 地址、子网掩码、默认网关、DNS 服务器。
这一步能直接抓出一类高频故障：
| /release | ||
| /flushdns |
169.254.0.0/16 这个网段值得记一下，它有个正式名字叫 APIPA（自动私有地址）——看到它就等于系统在说“我没要到地址”。原因不止是网线松：DHCP 服务本身异常、地址池被分光、无线认证没通过、接入口划错了 VLAN，都会落到这个结果。
Linux 用 ip addr，macOS 用 ifconfig。
第二步：测通不通 —— ping，但要会读它的失败信息
ping 分四枪，一枪比一枪远：
第一枪的地址别照抄，就用上一步 ipconfig 里“默认网关”那一行。家用常见 192.168.1.1 或 192.168.0.1，公司网络可能是 10.x.x.x 或 172.16.x.x。
四枪打完，故障范围就缩小到一段了。
失败信息不是一种，是三种
很多人看到 ping 不通就下结论，其实它的失败信息分三类，指向完全不同：
“请求超时”和“无法访问目标主机”完全是两回事。前者是包发出去了没回音，后者是有设备明确告诉你“送不到”。
后者还要多看一眼——回绝你的是谁，就写在这句话前面：
这一眼能直接分开“我的问题”和“网关的问题”。
还有一点常被误读：很多服务器默认禁 ping。ping 不通不代表网站挂了，只代表它不理会 ICMP。
TTL 那个数字怎么读
TTL 是数据包剩余的“寿命”，每经过一台路由器减 1——注意是路由器这类三层转发设备，二层交换机只管转发，不动 TTL。用它能粗估中间隔了几跳，但有个坑几乎人人踩：
初始值不是你定的，是应答方的系统定的。常见默认值是 Windows 128、Linux 及类 Unix 系统 64、部分网络设备 255。
所以上面这个例子，对端是 Linux 服务器（初始 64），跳数是 64 − 56 = 8 跳。如果拿 128 去减，会算出 72 跳这种离谱数字。
而且初始值是可以改的，所以这个方法只能粗估，不能当准数。
几个真正有用的参数
| -t | ||
| -n 20 | ||
| -w 1000 | ||
| -l 1472 -f |
最后那条值得单独说：ping -f -l 1472 目标。1472 加上 28 字节的包头正好 1500（IPv4 是 20 字节 IP 头加 8 字节 ICMP 头；IPv6 包头更大，对应的数字是 1452）——如果回的是“需要拆分数据包，但是设置 DF”，说明路径上有一段 MTU 不到 1500。这种情况的典型症状是小网页能开、大文件传不动，只 ping 默认的 32 字节根本发现不了。
第三步：断在哪一跳 —— tracert 和 pathping
ping 说“不通”，tracert 说“断在第几跳”。
原理很巧妙：先发一个 TTL=1 的包，第一台路由器把它减到 0，丢弃并回一条 ICMP 超时消息（Time Exceeded）——第一跳的身份就暴露了。再发 TTL=2 的，第二台回报……逐跳往外探，路径就画出来了。每一跳默认探测三次，所以你会看到三个时间。
最容易误判的一件事
第 3 跳全是 *，但第 4 跳又通了——这不是故障。微软文档写得很明白：有些路由器不回超时消息，对 tracert 来说就是隐形的。
更反直觉的是，连着好几跳全是星号，也未必有问题。微软官方文档给的示例输出里，第 14、15、16 三跳全是星号，第 17 跳照样正常返回、追踪完成。
所以别盯着中间的星号，盯着最后一行：只要末尾出现了目标地址、提示追踪完成，这条路就是通的；只有一路星号打到最大跳数、始终摸不到目标，才更可能是真的断了。
什么时候换 pathping
tracert 每跳只探三次，偶发丢包很容易漏掉。pathping 是 tracert 加 ping 的合体，默认对每一跳发 100 个包，能算出每跳的丢包率。
代价是慢：先跑一遍路径，再进入统计阶段，跳数多的话要等一两分钟，别以为它卡死了。
适用场景很明确：网速时好时坏，ping 平均值看着正常，但就是偶尔卡一下——pathping 跑一遍，哪一跳在丢包一目了然。
第四步：域名对不对 —— nslookup
前三枪里“IP 能通、域名不通”这一种，问题在 DNS。
这两条要连着敲，重点在对比。当前 DNS 查不出来、换一个能查出来，就说明你正在用的那台 DNS 有问题，而不是域名本身有问题。
输出里“非权威应答”这四个字最容易被误读。它不是说结果不可信，而是说：回答你的这台 DNS 不是该域名的权威服务器——结果要么在它缓存里，要么是它刚替你递归查回来的。日常查询看到这四个字，完全正常。
反过来，没有这四个字，说明你这次问的正好就是该域名的权威服务器（比如直接指定它的 NS 去查）。
DNS 的完整原理和“改 DNS 到底能不能提速”，第 45 篇和第 43 篇分别写过，这里不重复。
第五步：端口开没开 —— telnet
这一步藏着全篇最值钱的一条认知：
ping 通 ≠ 服务能用。
ping 走 ICMP，是网络层的事；你要访问的网页、数据库、SSH 走的是 TCP，是传输层的事。防火墙最常见的配置就是放行 ICMP、只拦特定端口——所以 ping 得再欢，端口没开一样连不上。
验端口用 telnet：
| 通了 | |
第一条经常让人以为是卡住了——telnet 连上之后就是一片黑，那就是成功。
两个提醒：Windows 10/11 默认没装 telnet 客户端，要去“启用或关闭 Windows 功能”里勾上。嫌麻烦的话，PowerShell 自带 Test-NetConnection 目标 -Port 80，Linux 上用 nc -zv 目标 80，都不用额外装。
还有 4 个，用得少但关键时刻能救命
前面五步覆盖了绝大多数情况。剩下这四个不常用，但遇上对应的场景没有替代品。
| netstat -ano | ||
| arp -a | ||
| route print | ||
| netsh |
几条最实用的具体用法：
netstat -ano 拿到 PID 之后，接一句 tasklist | findstr PID号 就能看出是哪个程序占着端口。另外补一句：Windows 下 netstat -r 和 route print 输出的是同一张表。
netsh 那两条 reset 放在最后是有原因的。前九个命令都只是“看”，netsh 是直接“改”。它能修的是协议栈或 Winsock 损坏这一类故障，不是万能钥匙——网线没插好、DNS 填错了，reset 一百遍也没用；而且它会把你现有的网络配置一并清掉。当最后一招用，别当第一招。
一张图串起来
这套流程的逻辑是由近及远、由低到高：先排除自己，再排除本网段，再排除路由，最后才怀疑对端。反过来查——一上来就怀疑对方服务器有问题——十次有九次绕远路。
顺带一提，企业网络里在交换机、路由器上排障是另一套思路和另一套命令，第 24 篇专门写过。
最后三句话收住整篇：