搞网络维护或者经常帮人处理电脑问题的人，应该都见过这种场景：打开命令行，敲字母，回车，屏幕滚出一堆数字和英文，懂的人三秒定位问题，不懂的人只能截图到处问。其实这些网络命令就是操作系统自带的调试工具，Windows和Linux都内置了全套，不用装任何第三方软件，也不需要花钱。这篇我就把日常排查中用得最多的8个命令摊开来讲：它们各自解决什么问题、参数怎么组合、输出结果怎么读、真实排障时怎么配合使用。内容不绕弯子，偏实操偏底层，适合刚入行的网络工程师、运维新人、安全测试同学，也适合经常需要远程处理同事电脑问题的普通技术爱好者，看完可以直接套到实际场景里用。
1. 网络命令的通用基础：先搞清楚这些东西在哪里跑
1.1 为什么这些命令不需要单独安装
很多人有误解，以为这些命令是什么高深工具，其实它们本质上是操作系统内置的协议栈工具集。Windows下这些程序一般躺在System32目录里，Linux下则分散在/bin、/usr/bin这些位置，分别来自net-tools或iproute2等基础软件包。它们做的事，就是直接调用操作系统底层的网络API，把网络状态以纯文本的形式反馈给你。
没有界面、不消耗多少资源、输出可以被脚本处理，这三个特性决定了它们非常适合做自动化排查。我习惯在出问题的时候先把它们组合成一条命令批量跑，再逐条分析结果，比打开图形界面点来点去快得多。
1.2 权限、帮助信息与跨平台差异
用这些命令时有两个最容易忽略的点：
第一，一部分命令需要管理员权限才能看到完整信息。比如Windows下netstat -b要管理员权限才能显示进程名，添加路由表项route add也要管理员权限，否则会报“请求的操作需要提升”。Linux下用sudo是常态。
第二，Windows和Linux命令名有差异。下表是我常用的对照，建议直接收藏：
| 功能 | Windows | Linux |
|---|---|---|
| 连通性测试 | ping | ping |
| 本机IP查看 | ipconfig | ip addr / ifconfig |
| 路径追踪 | tracert | traceroute |
| DNS查询 | nslookup | nslookup / dig |
| 连接状态 | netstat | netstat / ss |
| ARP缓存 | arp -a | arp / ip neigh |
| 路由表 | route print | route / ip route |
| 端口测试 | telnet | telnet / nc |
每个命令后面加 /?（Windows）或 --help（Linux）都能看到官方参数说明。我碰到记不清参数的时候，永远是先把帮助文档拉出来看一遍，这比硬背参数表靠谱。
2. ping：连通性诊断的第一课
2.1 ping 的原理和它真正能证明的事
ping命令基于ICMP协议。它向目标主机发送一个ICMP Echo请求报文，目标主机收到后，如果允许响应，就回一个Echo Reply。发送端通过能否收到回复、回复用了多长时间，就可以判断本机到目标主机的网络路径通不通。
但这里有个误区必须说清楚：ping通只代表ICMP层面的网络路径是通的，不代表TCP端口就通，不代表服务就一定可用。很多云服务器和站点为了防止探测，会禁止ICMP响应，这时候你ping不通，但访问网站却是正常的。所以ping的结果要结合场景判断，别一看到ping不通就断定网断了。
2.2 Windows 下 ping 的常用参数组合
Windows的ping参数和Linux略有差异，我把最常用的整理成一个表：
| 参数 | 作用 | 例子 |
|---|---|---|
| -t | 持续ping直到手动停止 | ping -t 192.168.1.1 |
| -n 次数 | 指定发送多少次 | ping -n 5 192.168.1.1 |
| -l 字节 | 指定数据包大小 | ping -l 1024 192.168.1.1 |
| -a | 将IP地址解析为主机名 | ping -a 192.168.1.1 |
| -S 源地址 | 指定源IP，多网卡机器用 | ping -S 10.0.0.2 8.8.8.8 |
Linux下常用的是 -c 指定次数、-s 指定包大小、-W 指定超时秒数。我在Windows上排查时基本都是“先 -t 观察一会儿，再Ctrl+C停掉，看看整体丢包和延迟表现”。
2.3 输出结果怎么看：TTL 值是有用的线索
每次ping通之后，结果里都有一个TTL值。TTL（Time To Live）是IP报文里的一个字段，每经过一个路由器减1。系统在发送时会给一个初始值，常见的有Windows默认128、Linux默认64、某些网络设备默认255。所以看到TTL接近128，对方大概率是Windows设备；接近64，大概率是Linux或路由类设备。
实际排查中这个值能帮我们判断到对方隔了几跳。比如你ping一台服务器TTL显示53，拿128减53等于75，说明中间隔了70多跳？不一定准确，因为不同的设备初始TTL不一样。更靠谱的做法是把它当辅助信息，不能当精确依据。
2.4 ping 排障的实战技巧与避坑
排查链路时我习惯按顺序ping四个目标：先ping 127.0.0.1（本机回环地址，确认网卡协议栈正常），再ping本机IP（确认网卡有IP配置），再ping网关（确认局域网链路通），最后ping外网地址（确认到公网的路由通）。从内向外一层层排查，哪一层断了就在哪一层处理。
注意：ping外网地址建议用IP地址测，不要用域名，否则披上了DNS解析的干扰因素。如果你知道一个稳定的公共IP，比如运营商DNS服务器的IP，用它来测最有说服力。
还有一个很多人踩过的坑：用 -l 65500 这种超大包去ping，很多防火墙会对异常大包直接丢弃，导致你误判链路质量问题。实测下来，常规的32字节和1000字节包就够用了，没必要故意用大包。
3. ipconfig 与 route：本机网络参数和路由表一次看懂
3.1 ipconfig 不带参数的日常用法
ipconfig是最被我忽视但最高频用到的命令。不带任何参数，执行一下，就能看到每块网卡的IPv4地址、子网掩码和默认网关。这三项是判断一台电脑有没有正常拿到网络配置的基础。
记住一个危险的IP段：169.254.x.x。如果Windows机器的IP地址出现在这个段里，说明DHCP自动获取地址失败了，网卡给自己分配了一个临时地址。遇到这个情况，什么重启、杀毒都不用先干，直接走下面的renew流程。
3.2 ipconfig 的进阶参数和处理流程
ipconfig /all 是最常用的详细模式，可以看到MAC地址、DHCP服务器地址、DNS服务器地址、租约时间等完整信息。我自己接到“上不了网”的报障电话时，头两步必然是ipconfig /all看清楚配置，再决定下一步怎么走。
如果在公司或者家里用的DHCP动态获取，遇到获取不到地址的情况，流程是这样的：
- 运行 ipconfig /release，把当前错误的IP配置释放掉；
- 运行 ipconfig /renew，重新向DHCP服务器申请地址。
这两条命令需要在管理员权限下运行。有一次同事反馈网络频繁掉线，我远程执行了这两条命令后，就重新拿到了一个正确的IP，问题解决了。如果renew失败，再看是不是网线、交换机端口或者DHCP服务端的问题，这就把范围缩小了很多。
还有两个和DNS有关的参数也值得掌握。ipconfig /flushdns 用来清空本机DNS缓存，改了域名解析记录或本地解析不正常时先清它；ipconfig /displaydns 用来查看当前DNS缓存内容，能看到每个域名对应缓存了哪些记录，排查“为什么我这个域名打开的还是旧地址”这类问题时，它就是最直接的证据。
3.3 route 命令：看懂路由表才能懂流量走向
路由表是网络通信的“导航地图”。route print 查看完整路由表，最上面有一条 0.0.0.0 0.0.0.0 0.0.0.0 开头的默认路由，代表所有未匹配更精确路由的流量都走这个默认网关。只要默认路由在，且网关配置正确，到外网的流量就会往网关送。
路由表关键字段有四个：网络目标、网络掩码、网关、接口，还有跃点数（Metric）。跃点数越小优先级越高，多网关时会选择跃点数小的路径。
实际配置中，用得最多的场景是双网卡或双网关。比如一台电脑同时接了办公内网和外部专线，访问A网段走内网，访问其他地址走专线，那就要加一条静态路由：
route add 192.168.10.0 mask 255.255.255.0 192.168.1.1 -p上面命令的意思是把192.168.10.0这个网段的流量，交给192.168.1.1这个网关处理。-p参数表示永久生效，重启后还在。注意：不写-p的话，重启就丢失了，这是我踩过的坑。
3.4 修改路由表的安全意识和恢复方法
修改路由表必须很谨慎，因为一条错误的路由可能让整台机器断网。我建议在改动之前先执行一次 route print 备份当前的完整路由表，把输出保存成一个文本文件，改动不对时能对照恢复。
如果加的静态路由导致网络异常，用 route delete 192.168.10.0 mask 255.255.255.0 192.168.1.1 删掉它，就能恢复原来的默认配置。还有，Windows系统在命令行里做这些操作时，建议用管理员身份的终端打开，否则会提示权限不足。
4. tracert：跟着数据包走一遍网络路径
4.1 tracert 的逐跳追踪原理
tracert的原理很简单，核心是IP头里的TTL字段。它先发出一个TTL等于1的探测包，数据包到达第一个路由器后TTL减1变成0，路由器就会丢弃这个包，同时回一个ICMP超时消息给发送端。发送端根据这个回应记录下第一跳的地址。接着发送TTL等于2的包，第二个路由器回超时消息，记录第二跳。依此类推，直到目标主机收到探测包并返回ICMP Echo Reply，路径上的所有节点就都被记录下来了。
这个过程用一句话概括就是：让路上的每个路由器都“被迫”报个到，从而还原出数据包走的完整路径。
4.2 参数怎么选，避免被噪音干扰
tracert的默认参数下，每个节点会发三个探测包，显示三次响应时间。最常用的参数有两个：
| 参数 | 作用 |
|---|---|
| -d | 不做IP到域名的反向解析，速度快、结果干净 |
| -h 最大跳数 | 限制最多追踪多少跳，默认30 |
| -w 毫秒 | 指定每次探测的等待时间 |
我实际用的时候几乎一律加 -d。原因很简单：反向解析domains要超时等待，尤其在跨运营商路径上，每个节点都解析一次的话，整个命令会慢得让人怀疑人生。去掉域名解析，输出就是一行行干净的IP地址，问题也更容易定位。
4.3 结果解读：星号不一定是故障
tracert输出里经常出现 * * *，这代表这一跳没有收到回应。很多人一看到星号就紧张，其实中间节点的星号非常常见，原因大多是路由器出于性能和安全考虑，主动丢弃了ICMP超时消息，或者路径上存在负载均衡设备，导致不同探测走了不同路径。
判断标准就一条：如果最终能到达目标地址，说明整体链路是通的，中间的星号无需太在意。但如果从中间某一跳开始持续星号，而且最终也到不了目标，那大概率问题就出在这个节点往后这一段。
4.4 定位高延迟和丢包点的实测心得
有一回用户反馈访问某台服务器特别卡，页面经常打不开。我先ping服务器，发现延迟在80毫秒左右，没有明显丢包。紧接着tracert -d到服务器，发现前面几跳都在几毫秒以内，但从某一跳开始延迟突然跳到100毫秒以上，而且持续到终点。这样一来问题区间就锁定了，联系拥堵段对应的运营商处理，很快就恢复了。这就是tracert的核心价值：它不是用来直接修故障的，而是用来给你切分问题边界的。
5. nslookup：把域名解析问题看得明明白白
5.1 域名解析到底发生了什么
访问任何域名，系统都要先把域名翻译成IP，这个翻译过程叫DNS解析。日常出问题最多的场景是：QQ能登录、网页却打不开；或者同一个域名别人能打开你打不开。这些八成跟DNS设置有关。nslookup就是绕过浏览器的隐藏逻辑，直接手动向DNS服务器发出查询，让你清清楚楚看到解析过程到底卡在哪里。
5.2 基础用法与两种模式
最基本的使用方式：
nslookup www.某域名.com回车后会有两段关键信息：第一段是当前正在使用的DNS服务器地址；第二段是该域名的解析结果。如果显示“DNS request timed out”，说明当前DNS服务器没有在超时时间内响应。
nslookup还有交互模式，直接输入nslookup回车，就进入一个提示符>状态，在里面输入域名继续查询，输入exit退出。交互模式适合连续查多个域名或多个记录类型，不用一遍遍敲命令。
5.3 查询不同类型记录的参数
在交互模式里可以切换查询类型，这是排查邮件和验证类问题的关键方法：
| 命令 | 查什么 |
|---|---|
| set type=a | IPv4地址记录 |
| set type=aaaa | IPv6地址记录 |
| set type=mx | 邮件交换记录，判断邮件服务器是哪台 |
| set type=ns | 该域名的权威DNS服务器列表 |
| set type=txt | 文本记录，常用于SPF和验证信息 |
实际用到mx记录的场景很多。比如某个客户说公司邮箱老是被退信，我就会先查一下他们公司域名的mx记录，确认是否指向了正确的邮件服务器。如果指向错了，或者出现过期记录，一些邮件服务商就可能拒收邮件。
5.4 用公共DNS做对比判断
排查DNS问题时，最有效的一招是用不同的DNS服务器做对比查询。同样是查一个域名，先用本机配置的DNS查一次，再用公共DNS查一次，如果结果不一样，说明问题出在本地DNS服务商的解析数据上。
命令格式是这样：
nslookup www.某域名.com 223.5.5.5这是指定用223.5.5.5这个公共DNS服务器来解析域名。我遇到“本地解析错误、公共DNS正常”的情况，一般会把本机的DNS服务器地址改成公共DNS，或者清空本地DNS缓存后再查一次，问题通常就能定位到是DNS缓存污染还是配置错误。
补充一个细节：nslookup刚查完的结果显示“Non-authoritative answer”，意思是这个答案来自DNS服务器的缓存，不是权威服务器直接返回的。这非常正常，绝大多数查询都是非权威应答，除非你查的是域名ns记录时用了权威模式。
6. netstat：端口与连接状态全审计
6.1 netstat 参数组合，看日常要什么
netstat是一个信息量非常大的命令，我自己的习惯是从最多到最少、从细节到整体来看它。最常用的是这一条组合拳：
netstat -ano-a显示所有连接和监听端口，-n用数字形式显示IP和端口不做反向解析，-o同时显示进程PID。这一条命令下来，本机上谁在监听、哪些连接是建立的、外部IP是什么、对应哪个进程，全部一目了然。
需要精确知道是哪个程序的时候，在管理员终端里用 netstat -b 能显示可执行文件的名字。一开图形界面工具太慢，一条命令知道是哪个进程占用了端口，排查效率高很多。
6.2 查端口被占用的完整流程
开发或启动某些服务时经常遇到端口冲突提示，比如启动Tomcat时提示8080端口被占。操作步骤：
- 执行 netstat -ano | findstr 8080，找到监听8080端口的记录，最后一列就是PID；
- 在任务管理器里对照PID找进程，或者用 tasklist /fi "pid eq 端口对应的PID" 直接看进程名；
- 确认是没用的残留进程，执行 taskkill /pid 对应PID /f 结束它。
注意：第3步强制结束进程要慎重，先确认这个PID不是正在使用的业务进程，尤其是服务器上，千万别手滑。
6.3 看懂各种连接状态
netstat输出里会出现大量英文状态，我整理一个速查表：
| 状态 | 含义 |
|---|---|
| LISTENING | 端口正在监听，等待连接 |
| ESTABLISHED | 已建立连接，正在通信 |
| TIME_WAIT | 主动关闭连接后的等待状态 |
| CLOSE_WAIT | 被动关闭，等待应用层调用close |
| SYN_SENT | 正在发送连接请求，尚未完成握手 |
| FIN_WAIT_1 / FIN_WAIT_2 | 正在正常关闭连接的过程 |
| CLOSED | 连接完全关闭 |
实际工作中，大量TIME_WAIT状态很常见，这通常是短连接过多导致的，比如服务端同时处理大量请求，每次处理完主动断开。大量TIME_WAIT不代表有故障，但如果你的服务性能下降，又看到TIME_WAIT堆积，就要考虑调整连接复用参数。
CLOSE_WAIT堆积是我在Java程序上遇到过最头疼的问题。一个程序每处理完一笔业务就卡住了一个连接，CLOSE_WAIT越积越多，把连接数耗完，最后整个服务不可用。排查时先用netstat -ano | findstr CLOSE_WAIT统计数量，数量持续增长，基本就是程序代码里连接没有正确关闭。
6.4 安全视角：盯住可疑外联
从网络安全角度看，netstat的价值在于发现异常连接。正常电脑的外联数量是有限的，如果发现有连接到大量陌生IP、尤其是源端口异常的情况，可以进一步配合进程信息判断。但我要提醒一句：不要单凭一条连接就下结论，先确认是否是系统更新、软件自动升级、CDN访问等正常行为。
7. arp：局域网里的 IP-MAC 对照表
7.1 ARP 协议和它在同一网络里的位置
在同一个局域网内，两台机器通信时，真正被交换机用来转发数据的是MAC地址，而不是IP地址。IP地址是逻辑层，MAC地址是物理层。ARP协议就是解决“我知道对方IP，但还不知道对方MAC”这个问题。每台电脑上都会维护一张ARP缓存表，记录了最近通信过的IP和MAC对应关系。
7.2 arp 命令的常用参数
| 参数 | 作用 |
|---|---|
| arp -a | 查看本机完整的ARP缓存表 |
| arp -d 具体IP | 删除某一个ARP条目 |
| arp -s IP MAC地址 | 手动添加静态ARP绑定 |
arp -a 执行后，输出的每一行是一个IP对应的MAC地址以及该条目的类型。动态条目会随着时间自动过期，静态条目手动指定后一直保留。
7.3 排查IP冲突和定位设备的实战
IP地址冲突的场景，相信做网管的人都碰到过：办公室有人手工填了跟别人一样的IP，导致其中一台电脑上不了网。排查思路是这样的：
先用 arp -a 查一下这个冲突IP对应的MAC地址，然后到交换机上根据MAC地址找到对应的端口，再顺着端口找到物理位置，就能知道是哪台设备在搞事。一个小细节：拿到手里的MAC可能对不上找过的任何一台配置记录，那就要查这个MAC最开始的来源，方向基本就定位了。
7.4 网关静态绑定的防欺骗用法
还有一种常见操作是把网关的IP和MAC静态绑定，用来防止ARP欺骗。绑定命令是这样的：
arp -s 192.168.1.1 00-0c-29-aa-bb-cc手动指定网关IP对应的MAC地址之后，本机就不会接受网络里其他设备广播的“我就是网关”的ARP响应，这能有效防止局域网内的ARP欺骗攻击。但这个操作的代价也很明显：换路由器、换网卡、重启，静态绑定都有可能失效，导致无法上网。我的经验是：这种绑定适合安全要求较高的内部网络，并且要有配套的管理手段，普通家庭环境不建议用，动态学习就够了。
8. telnet：低调但好用的端口连通性测试工具
8.1 telnet 为什么能测端口
telnet本身是一款历史悠久的远程登录协议，用来连接远程主机上的终端。但今天它更常被用在一个场景——测试某个TCP端口是否开放且可达。原理很简单：telnet客户端去连接目标IP的指定端口，如果TCP握手成功，命令窗口会进入一个等待状态，出现登录提示或者直接光标空白等待输入；如果握手失败，就会提示连接失败或超时。
8.2 Windows 启用 Telnet 客户端
Windows默认没有启用Telnet客户端，需要手动开启。路径是：控制面板 → 程序和功能 → 启用或关闭Windows功能 → 勾选“Telnet客户端” → 确定。没有图形界面权限的远程服务器上，也可以在PowerShell里用以下命令替代测试端口连通性：
Test-NetConnection -ComputerName 192.168.1.10 -Port 8080这条PowerShell命令要是能返回TcpTestSucceeded : True，就代表端口通。个人建议，如果你Windows上没启用telnet，直接用这个替代方案更省事。
8.3 端口测试的实际展示与判断
测试一个Web服务器的80端口：
telnet 192.168.1.10 80如果端口开放，屏幕上会显示类似这样的响应：
HTTP/1.1 200 OK或者光标在空白处闪烁，等待你输入内容。如果端口不通，会提示：
正在连接192.168.1.10...无法打开到主机的连接，在端口 80: 连接失败这个判断非常直观。常见场景包括：验证两台服务器之间的某个服务端口有没有放开、测试远端数据库端口是否可达、确认云服务器安全组规则是否生效等。可以说telnet是网络层之下、业务探测之上的一个高效工具。
需要特别提醒：telnet是明文协议，千万不要用来做实际的远程登录操作，尤其是涉及账号密码的场景。只在没有加密环境或者临时测试的时候用一下没问题，日常远程管理请使用更安全的协议。
9. 把这些命令串起来：一次典型断网故障排查实录
9.1 故障表象与初步判断
某个工作日的下午，某办公室一位同事反馈：“电脑屏幕右下角网络图标一直转圈，打不开网页，邮件也收发不了。”我的第一反应不是冲到工位上看，而是问他旁边同事网络是否正常，回复说一切正常。那就说明问题大概率出在他这台电脑上，而不在交换机或总出口。接下来就是按照已总结的排查路径走。
9.2 从本机一层层往外查的完整路径
第一步，在该电脑的CMD里执行 ipconfig /all。关键信息是IP地址段。正常情况下应该是DHCP下发的，而我看到的IP却是169.254.x.x，这个地址段之前提过，是DHCP获取失败后Windows自分配的临时地址。问题方向很清楚：这台电脑没有从DHCP服务器拿到正确地址。
第二步，执行 ipconfig /release，再执行 ipconfig /renew。renew之后再看IP，发现还是169.254.x.x。这就说明不是缓存导致的问题，而是DHCP交互失败了。确定这一步，就要想是网线错位、交换机端口问题，还是网卡故障。
第三步，看物理层面。先确认网线插没插牢，指示灯亮不亮，指示灯正常就继续。换一个交换机端口，不行就禁用再启用网卡。这一套操作下来，renew成功了，IP地址恢复正常，网页也能正常打开。故障全过程从开始到结束不到10分钟。
9.3 另一个DNS类故障的分层排查
换一个案例。某台电脑能够打开微信、能ping通很多IP，但浏览器就是打不开网页。这个现象很容易误导人，因为“看起来网络是通的”。
排查过程是这样的：先 ping 一个公网IP，比如223.5.5.5，发现完全通，说明物理链路和公网路由没问题。再执行 nslookup www.某站点.com，发现了请求超时，这时基本可以判断DNS解析环节出了问题。接着执行 ipconfig /flushdns 清空缓存，问题依旧。再用 nslookup www.某站点.com 223.5.5.5 指定公共DNS重新查询，发现可以正常解析，说明是本地DNS服务器的问题或本地配置被改动了。
最终处理办法是把网卡配置里的DNS改一下，先改成公共DNS测试，确认正常后再联系相关管理员恢复公司内部的DNS设置。整个过程用到的命令就四条：ping、ipconfig、nslookup、flushdns，一层层排除，没有碰任何多余的设置。这就是命令组合拳的意义：快速缩小问题范围，避免在界面里瞎点。
10. 常见报错与排查技巧速查
10.1 高频报错对照表
把这几年积累的常见报错整理成一张表，遇到问题先对着查：
| 现象 | 可能原因 | 排查命令 |
|---|---|---|
| ping超时或丢包 | ICMP被禁、链路中断、防火墙拦截 | ping网关确认链路 |
| IP是169.254.x.x | DHCP获取失败 | ipconfig /release 后 /renew |
| 能ping通不能上网 | DNS配置错误或DNS服务器故障 | nslookup域名、换DNS再查 |
| 域名能解析但打不开 | 端口不通、服务未启动 | telnet IP 端口、netstat -ano |
| 端口被占用 | 进程残留或冲突 | netstat -ano | findstr 端口 |
| 添加路由报权限错误 | 非管理员终端 | 用管理员身份重新打开终端 |
| tracert全是星号 | 中间设备不响应ICMP | 加-d参数重试，看能否到终点 |
| ARP表里网关MAC异常 | ARP欺骗或网关更换 | arp -d 网关IP 后重新获取 |
| 修改DNS不生效 | 未清DNS缓存 | ipconfig /flushdns |
10.2 提升效率的几个实用习惯
第一个习惯，命令输出用findstr过滤。比如netstat -ano命令输出几百行，我永远只找关心的那几行，不会整屏翻：
netstat -ano | findstr 8080Linux下对应的是管道后加grep，思路一模一样。
第二个习惯，把输出重定向到文件。排障过程中需要留存证据或者慢慢分析时，执行 netstat -ano > D:\netstat.txt，全部输出保存到文件里，再用文本编辑器搜索，比在命令行界面里翻屏稳得多。
第三个习惯，备份路由表和完整网络配置。改之前先执行 route.print、ipconfig /all，把输出保存下来作为基准，后续有问题可以对照。
第四个习惯，Windows下优先考虑用PowerShell里的Test-NetConnection替代telnet测端口，使用上更方便，输出也更友好。
10.3 一套通用的排障心法
不管碰到什么奇怪的现象，我的排查顺序基本是不变的：确认本机网卡状态（ipconfig）→ 确认本机协议栈（ping 127.0.0.1）→ 确认默认网关（ping网关）→ 确认公网链路（ping公网IP）→ 确认域名解析（nslookup）→ 确认应用端口（telnet / netstat）。严格按照这个顺序，大多数问题都能在5分钟内定位到某一个具体环节。
核心思路其实就一句话：从物理层到网络层到传输层到应用层，逐层分层排查。这个思路比记住一万条具体的命令更有用，也让你在面对陌生问题时不会慌。命令只是工具，真正值钱的是你对“数据包从本机出发到目标服务器，中间会发生什么”的理解。
最后说句掏心窝的话，这8个命令我用了快十年，每次遇到“上不了网”这种报障，心里惦记的还是最初的这套排查顺序。命令不停在升级，新工具也越来越方便，但底层这层“分层排查、逐层验证”的思路从来没变过。就算哪一天所有图形化工具都用不了了，只要手里还有一个终端，有这些命令，就永远能找到问题的方向。这也是我为什么建议每个跟网络打交道的人，都踏踏实实把这几个基础命令练熟的原因。
