8个常用网络命令详解：从ping到curl的排障实战指南

网线插着、电脑也没报错，但同事就是打不开网页，微信却能正常收发消息。这种场景每个搞网络的人应该都不陌生。我平时做运维和安全自查，面对这类问题从来不会先打开图形化抓包工具，而是先把那8个常用网络命令在命令行里敲一遍。原因很简单：ping、netstat、tracert、nslookup、arp、route、telnet、curl这套组合，能在最短时间内告诉你故障到底发生在物理链路、网络配置、路由转发、DNS解析还是应用服务层。这篇文章我打算把这8个（严格来说是8组）常用网络命令掰开揉碎讲清楚，包括命令参数、输出解读、安全自查思路和真实排障流程，适合刚入门安全的新人、运维同学，也适合自己折腾服务器和虚拟机的人参考。

我发现很多人遇到网络问题只会无脑重启路由器，或者装个网络修复工具点一下，但都不知道这些工具背后到底发了什么数据包、查了哪些表。这就是基本功缺失的体现。网络命令就像是给网络做体检的听诊器，掌握之后哪怕没有专有的监控平台，你也能通过一行行的输出把故障范围从“整个网络”缩小到“某一个请求超时”，这种能力在排查效率和面试面试官面前都非常加分。

1. 内容整体设计与思路拆解

1.1 为什么网络命令是安全排障的第一响应工具

在做安全自查或者网络排障的时候，我特别看重“确定性”。网络不通，到底是哪一段不通？界面工具往往给你一个笼统的“网络连接异常”，但从命令行我们能拿到具体的来源地址、目标地址、跃点列表、端口状态、丢包率、DNS解析IP。这份确定性，是后续所有判断的基础。

举个例子，你用浏览器访问某个网站超时，浏览器只会给你一个“该网页无法访问”。但如果你依次执行：ping 网关、ping 公网IP、nslookup 域名、telnet 域名 80，很快就能判断出是内网链路问题、运营商链路问题、DNS解析问题，还是目标服务器Web服务没响应。这就是行业里常说的“分层排查”，也是这些网络命令最核心的价值所在。

安全自查时也一样。如果怀疑主机被植入了恶意程序，netstat -ano 一下，所有对外建立的TCP连接和本地监听的端口都能拉出来，再结合任务管理器里的 PID 反查进程，基本就能锁定可疑对象。没有这些命令行工具，你只能靠杀毒软件的查杀日志，但那些东西往往都是有特征库才能发现的，而基本的命令排查能帮你捕捉到“异常”本身。

1.2 八组命令如何分层覆盖网络协议栈

我习惯把网络命令按它们工作的协议层来划分，这样记起来不容易乱，用起来也能意识到“我现在在验证哪一层”。

按这个表格来看，其实你只要把八组命令练熟，从网线链路到应用层服务的每一层你都能亲手测一遍。这也是我特别推荐刚入行的人不要一上来就学各种重型扫描工具的原因——你把基础命令练透了，对协议栈的理解会比别人深得多，因为每次敲命令你都在真实地观察数据包的行为。

1.3 先配置、再链路、后应用的排查思路

可能有人会问，碰到问题我先无脑 ping 外网 IP 行不行？我建议不要这样。很多年前我也犯过这种错误，结果 ping 不通外网，我就以为是出口路由问题，查了半天发现其实本机网卡压根没获取到正确IP。所以我现在给自己定了一个排查顺序，也推荐给你：

第一步，用 ipconfig / ifconfig 确认本机网络配置是最起码的，相当于先看清“我是谁、我在哪个网络”。第二步，ping 127.0.0.1 验证本机协议栈是否正常。第三步，ping 默认网关验证二层链路和本机到路由器的连通性。第四步，ping 公网IP验证路由和出口链路。第五步，nslookup 验证DNS。第六步，telnet 或 curl 验证具体服务端口。最后再用 tracert 定位到底是哪一跳出了问题。

这个顺序背后其实是一条依赖链：DNS解析依赖外网路由，外网路由依赖网关链路，网关链路依赖本机配置。先验底层，再验上层，哪一层失败马上就能圈定范围，排查效率至少翻倍。

2. 核心细节解析与实操要点

2.1 ping：连通性测试与ICMP报文怎么看

ping 应该算网络命令里最基础的一个，它通过发送 ICMP Echo Request 报文，等待目标主机回复 ICMP Echo Reply 来判断连通性。我实测下来，它可以快速测出三层连通性、往返时间和丢包率，三个指标足够判断网络链路“通不通、快不快、稳不稳”。

Windows 下我常用这几个参数：

• ping -t 目标IP：持续 ping 直到按 Ctrl+C 结束，适合长时间观察链路稳定性。
• ping -n 10 目标IP：指定发送 10 个包，适合短时间定量测试。
• ping -l 1024 目标IP：指定发送数据包大小为 1024 字节，测大包是否会分片或丢包。
• ping 目标IP /?：查看完整参数说明。

Linux 下的写法有一点点区别，常用的是：

• ping -c 4 目标IP：发送 4 个包后自动停止。
• ping -i 0.5 目标IP：每 0.5 秒发送一个包。
• ping -s 1024 目标IP：指定数据包大小。

很多人不会看 ping 的输出。举个例子，ping 返回 “来自 192.168.1.1 的回复: 字节=32 时间=1ms TTL=64”。这里“时间=1ms”代表往返时间；“TTL=64”代表数据包经过的设备还没把它减到0。TTL 值一般表示数据包最长能经过多少个路由器，每经过一跳 TTL 会减1，如果减到0，路由器就会丢弃报文并通知源主机“超时”。这也造成一个常见误区：不要单纯依据 TTL 值判断对方是什么操作系统，因为现在很多系统允许手工修改TTL，而且不同系统的初始TTL并不统一。

我在排障时通常会先 ping 127.0.0.1 验证本机协议栈，再 ping 网关验证二层链路，最后 ping 外网IP验证路由。如果 ping 网关丢包多，问题大概率在局域网内部，比如网线接触不良、局域网广播风暴；如果 ping 网关正常但 ping 外网IP丢包，那问题就在出口路由器到运营商这一段。

2.2 ipconfig / ifconfig：本机网络身份的第一步检查

拿到一台有网络故障的电脑，我第一件事就是看它的网络配置。Windows 下是 ipconfig，Linux 下是 ifconfig 或 ip addr。这一步能看出非常多问题：IP 地址是不是 169.254.x.x（Windows 的 APIPA 自动私有地址，说明DHCP没分配成功）、网关地址是否正确、DNS 配置是否指向了不可用的服务器、子网掩码跟实际网段是否匹配。

ipconfig /all 会比普通 ipconfig 输出更多字段：物理地址（MAC）、IPv4地址、子网掩码、默认网关、DHCP服务器、DNS服务器等。如果公司电脑用的是固定IP，你还能核对是不是跟网管规划的VLAN段一致。

Linux 下 ip addr 是更现代的命令，信息比 ifconfig 更全，输出里 “inet 192.168.1.100/24” 表示IP地址和前缀长度，/24 等价于掩码 255.255.255.0。如果你想看更详细的路由信息，还可以配合 ip route。

还有一个容易被忽略的地方：Windows 本地 DNS 缓存。如果域名解析被改过或者缓存出错，即使 DNS 服务器是正常的，系统也可能一直用旧的解析结果。这时候可以执行 ipconfig /flushdns 把本地 DNS 缓存清掉，再重新 nslookup 验证。很多“网页突然打不开”的问题，靠这一条就能解决。

2.3 netstat：端口与连接状态的显微镜

netstat 是我在安全排查里使用频率最高的命令之一。它的作用简单说就是“看一下这台机器当前有哪些网络连接、哪些端口在监听”。Windows 下我最常用的组合是 netstat -ano，“-a”显示所有连接和监听端口，“-n”用数字显示IP和端口而不是反解域名，“-o”显示对应的进程PID。Linux 下我习惯用 netstat -tunlp，其中“-t”显示TCP、“-u”显示UDP、“-l”显示监听端口、“-p”显示进程名和PID。

为什么要看连接状态？因为 TCP 连接状态能透露很多信息。常见状态有：

• LISTENING：本地某个端口正在监听，等待连接，正常情况下这是我们启用的服务；异常情况下可能是恶意程序开的隐蔽端口。
• ESTABLISHED：本机跟某个远端地址建立了连接，正在通信。如果发现一个陌生的远端IP长期 ESTABLISHED，而且连接进程名称很可疑，就要重点排查。
• TIME_WAIT：连接已关闭，但为了保证最后的ACK能送达，系统会保留这个状态一段时间。大量 TIME_WAIT 一般见于高并发服务端，不一定代表故障。
• CLOSE_WAIT：远端关闭了连接，但本地程序没主动关闭。如果大量连接堆积在 CLOSE_WAIT，说明应用程序有连接泄漏，得查代码了。

安全自查时，我通常会执行 netstat -ano | findstr "ESTABLISHED" 看一下本机对外建立的连接列表，再执行 netstat -ano | findstr "LISTENING" 看一下本机到底开了哪些端口。如果发现某个端口监听在 0.0.0.0 上且对应进程很可疑，就需要进任务管理器去查这个 PID 到底是什么程序。

2.4 tracert：每一跳都看得见的数据包路径

当网络链路通，但不管是访问什么都慢，或者 ping 某个外网IP有延迟时，用 tracert 可以看到数据包从你电脑到目标主机之间经过的每一跳节点。这对定位“出口绕路”和“路由黑洞”特别有用。

Windows 下命令是 tracert 目标IP或域名，Linux 下是 traceroute。我常用的参数包括：-d 不解析每个跃点的主机名，排查时能大幅提速；-w 指定等待超时时间；-h 指定最大跳数，一般设30就够。

看 tracert 输出时，每一行代表一跳：第几跳、中间路由器IP、三次探测的往返时间。要注意的是，中间某些跳返回“超时”不一定代表链路故障，很多路由器出于安全考虑直接丢弃 ICMP 报文，所以会出现星号，这并不影响后续节点继续响应。但如果你发现从某一跳开始往后的所有节点全部超时，而且目标地址也 ping 不通，那问题大概出在那个节点或它的回程链路。

有一次我排查一个“视频会议卡顿”问题，本机 ping 网关延迟1ms，ping 公司互联网出口延迟2ms，但 ping 对端服务器延迟高达120ms。用 tracert 一看，发现流量绕了大半个网络才到达目标，直接在路由层面把问题定位了。

2.5 nslookup：DNS解析异常一查便知

你可能会说“我明明能用浏览器访问啊，DNS能有什么问题？”但“能访问”和“DNS解析正确”是两码事，比如反查域名解析到旧IP、解析记录返回多个IP，甚至解析超时，这些都会导致细小的访问异常。

nslookup 基本用法是 nslookup 域名。Linux 和 Windows 都支持。如果你想指定某台 DNS 服务器来做解析，就写成 nslookup 域名 DNS服务器IP，比如 nslookup www.example.com 223.5.5.5，也能验证是不是本地DNS服务器的查询结果跟公共DNS不一致。

输出里值得关注的有几个字段：Server 和 Address 表示当前使用的DNS服务器；Non-authoritative answer 表示这是缓存得到的非权威应答；最后 Name 和 Address 就是域名对应的IP。如果同一个域名查询一次一个IP、再查一次又变成另一个IP，而且变化很频繁，那多半是DNS轮询或者存在解析异常，需要结合业务情况判断。

安全场景下，nslookup 还能查特定类型的解析记录。nslookup -type=TXT 域名 可以查TXT记录，nslookup -type=CNAME 域名 可以查别名记录。做安全评估时，确认域名解析到了正确的IP、有没有异常的CNAME指向，往往是排查域名劫持和钓鱼仿冒的第一步。

2.6 arp：局域网地址解析和欺骗自查

ARP 解决的问题是：已知目标IP，怎么找到对应的MAC地址。每台主机会在本地维护一个 ARP 缓存表，记录IP和MAC的映射关系。Windows 下用 arp -a 查看，Linux 下用 ip neigh show 查看。

如果你所在的是办公网或实验室网络，ARP 缓存表非常值得关注。最典型的安全问题是 ARP 欺骗：攻击者通过发送伪造的 ARP 报文，把网关IP映射到攻击者的MAC地址，这样一来，同网段主机的流量就会先发到攻击者的机器上，可以抓包分析或者篡改后再转发，而用户侧很难感知。

自查方法其实很简单：在故障时间内连续多次执行 arp -a 查看网关IP对应的MAC地址，如果发现网关的MAC一直在变，或者一个IP对应了多个MAC，就要高度怀疑局域网存在ARP欺骗。如果确认是ARP欺骗，常规处理是用 arp -d 清空缓存、重新获取正确的ARP映射，然后从接入层交换机排查是谁在发异常ARP报文。

注意，Windows 下 arp 命令本身也能手工添加静态映射，但在家庭或办公网环境下我不建议你手工指定，因为一旦 IP 或 MAC 变化，静态表会导致网络完全不通，反而引入新的故障。

2.7 route：路由表决定流量怎么走

路由表是每个主机的“方向感”，它决定一个数据包到达某个IP段时，应该交给哪个网关。Windows 下输入 route print，Linux 下输入 ip route，就可以看到完整路由表。

我一般在第一次配置服务器或者修复多网卡主机时非常依赖 route。如果一台机器有多个网卡，比如一个连内网、一个连外网，系统默认只会用第一个符合条件的网关，这就可能导致“内网能通、外网不通”或者反过来。这时候就需要手动往路由表里加一条指定的静态路由，告诉系统“去某个网段的流量走某个网关”。

添加静态路由的格式在 Windows 下是：route add 目标网段 mask 掩码 网关 -p，最后带上 -p 表示持久化，重启不会丢。Linux 下则是 ip route add 目标网段/前缀 via 网关。

查看路由表时最需要注意的是 Default Route（默认路由）。如果默认路由缺失或指向了不可达的网关，即使IP和DNS配置都正常，你也上不了外网，因为系统根本不知道该把数据包交给谁。很多人排查外网不通的时候会漏掉这一步，直接用 ping 外网IP，结果怎么都不通，其实检查一下默认路由，一秒就能发现问题。

2.8 telnet / curl：应用层端口连通性的一次“握手”

网络层和传输层都通了，不代表应用层就一定正常。举个例子，你能 ping 通一台服务器，但访问它的 8080 端口却白屏，这时候就要用 telnet 或 curl 来验证端口和服务响应。

telnet 的经典用法是 telnet 目标IP 端口，如果端口开放，你会进入一个黑窗口或者看到服务的Banner信息；如果端口拒绝连接或超时，说明服务没监听该端口或防火墙拦截了。不过 Windows 默认可能没有安装 telnet 客户端，如果不想装组件，可以用 PowerShell 的 Test-NetConnection 目标IP -Port 端口来替代。

curl 是更偏应用层的工具，它能直接发起HTTP请求，看到完整响应头和状态码。排查 Web 服务时，我常执行 curl -v http://域名 或者 curl -I http://域名，前者能显示SSL握手、请求头、响应体的全过程，后者只取响应头。看到 HTTP 200 说明服务正常；返回 500 说明服务端代码异常；返回 403 可能是权限问题。在这个意义上，curl 算是一个轻量级的接口自测工具。

有一点要专门提醒：telnet 和 curl 都只能证明“端口通、服务有响应”，并不能证明应用功能完全正常。曾经有个同事拿 telnet 测试一个端口，显示能连接，就认为服务没问题，结果其实那个端口上是一个坏进程在监听，业务根本不可用。所以端口探测通常要和业务自身的健康检查接口配合使用。

3. 实操过程与核心环节实现

3.1 一次真实的“浏览器打不开网页”排查实录

下面我用一个实际遇到的排查过程，把这些命令串起来。场景是这样的：某天下午，办公网里一位同事反馈浏览器打不开网页，但微信和钉钉收发消息正常。我先记录下当前时间，然后开始命令行排查。

第一步，ipconfig /all。我看到本机IP是 192.168.1.108，掩码 255.255.255.0，默认网关 192.168.1.1，DNS 也是 192.168.1.1。这是很常见的小型办公网配置，说明DHCP有正常分配地址，本机网络配置没问题。

第二步，ping 127.0.0.1。返回正常，说明本机TCP/IP协议栈没有异常，网卡驱动层面基本正常。

第三步，ping 192.168.1.1。延迟小于1ms，没有丢包，说明本机到网关的链路物理层和二层都正常。到这里，内网基础链路已经排除。

第四步，ping 223.5.5.5。结果请求超时。看到这个结果时，第一个怀疑对象变成了出口路由或运营商链路。但注意，这里不能立刻下“外网不通”的结论，因为很多网络设备会拦截 ICMP 报文，导致 ping 不通但实际TCP业务正常，微信能正常收发正好印证了“出口可能没有完全断”。

第五步，nslookup www.example.com。返回了正常解析地址。所谓打不开网页，DNS解析不是罪魁祸首。于是我把重点放在“TCP 443端口到目标服务器是否可以连通”。

第六步，用 curl -v https://www.example.com 测试。结果一直卡在连接阶段，最后超时。再用 telnet www.example.com 443 测试，同样无法建立连接。这说明从本机到目标网站的443端口存在通信阻断，而出于微信正常，说明并不是所有外网流量都被阻断，更像是针对某些目标IP或端口段的访问异常。

第七步，为了看看到底是哪一跳的问题，我执行 tracert -d www.example.com。发现前几跳都能正常响应，但到第三跳之后就开始超时，之后的跳数也全部星号。综合前面“微信正常、网页超时”的现象，能大概判断问题出在出口路由策略或运营商互联链路对特定目的地址的限制。

第八步，用 netstat -ano 看了一眼当前浏览器进程有没有建立到目标IP的 TCP 连接，果然没有任何 ESTABLISHED 记录，进一步确认浏览器不是连接成功后被服务器主动断开，而是压根没连上。

最后结论是：本机网络、DNS、网关、基础出口都正常，问题更可能出在特定链路段的策略限制上。后续我把traCert和curl结果反馈给出口网络负责人，他们排查后在防火墙上做了对应调整，网页访问恢复正常。

这套流程，从开始排查到定位问题大概10分钟。如果一上来就盲目重装浏览器或者把电脑重启几遍，大概率仍然解决不了问题。

3.2 一份可以直接抄的排查顺序表

为了方便你以后照葫芦画瓢，我整理了一份通用排查顺序表：

这张表基本覆盖了从物理层到应用层的所有检查项。遇到情况时按顺序执行，把每一步的结果记录下来，会比满脑子乱猜高效得多。

3.3 把常用命令组合成自动化巡检脚本

平时如果不想每次出问题都手动一条条敲命令，可以把上面这些命令写成一个脚本，在计划任务里定时跑，每次输出带时间戳的日志。这样事后回溯时就有一份“当时的网络状态现场记录”。

Windows 下可以写一个简单的批处理脚本，思路是逐条执行命令并重定向到日志文件：

@echo off set LOGFILE=C:\logs\netcheck_%date:~0,10%.log echo ================= %date% %time% =================>> %LOGFILE% ipconfig /all>> %LOGFILE% 2>&1 ping -n 4 127.0.0.1>> %LOGFILE% 2>&1 ping -n 4 192.168.1.1>> %LOGFILE% 2>&1 ping -n 4 223.5.5.5>> %LOGFILE% 2>&1 nslookup www.example.com>> %LOGFILE% 2>&1 netstat -ano>> %LOGFILE% 2>&1 route print>> %LOGFILE% 2>&1

Linux 下可以用 Shell 脚本：

#!/bin/bash LOG="/var/log/netcheck_$(date +%F).log" echo "================= $(date '+%F %T') =================" >> $LOG ip addr >> $LOG 2>&1 ip route >> $LOG 2>&1 ping -c 4 127.0.0.1 >> $LOG 2>&1 ping -c 4 192.168.1.1 >> $LOG 2>&1 ping -c 4 223.5.5.5 >> $LOG 2>&1 nslookup www.example.com >> $LOG 2>&1 ss -tunlp >> $LOG 2>&1

把这些脚本放进定时任务里，每天跑几次，一旦收到“上午10点网络出过问题”的反馈，直接把对应时间点的日志拉出来，看到的不是用户的主观感受，而是真实的IP、延迟、丢包、端口状态数据，定位效率完全不一样。

4. 常见问题与排查技巧实录

4.1 高频报错速查与处理思路

我把自己在排障过程中经常遇到的几个报错和排查方向整理成了一张表，方便你遇到时快速对照：

我特别提醒一句：出现“请求超时”和“目标主机不可达”不要当作同一个问题，前者说明数据包发出去后没回应，可能是对端丢弃或防火墙限ICMP；后者说明网络栈已经明确告诉你这个目标不可达，通常是路由问题。这两个报错背后的排查方向完全不同。

4.2 三个反直觉的网络排查经验

第一个反直觉经验：TTL值变小不代表链路一定变差。TTL的作用是防止数据包在网络里无限循环，每经过一台路由器就减1。默认TTL一般会是64、128或255，所以你ping一个很远的目标发现TTL是54，只能说明经过了10跳，而不是“目标主机有问题”。

第二个反直觉经验：tracert 输出里的星号并不等于网络中断。很多路由器默认丢弃ICMP，或者接口限速，你会在某一跳看到星号，但后续节点依然正常响应。只有从某一跳开始连续所有跳都星号，而且最终目标也不通，才需要怀疑是那个位置链路中断。

第三个反直觉经验：netstat 看到大量 TIME_WAIT 不一定就是被攻击了。只要你的服务是高并发或短连接模式，比如Web接口被频繁调用，TIME_WAIT 多是非常正常的现象。反而是系统里如果出现大量 ESTABLISHED 连接到同一个陌生IP，或者本机多了若干个非预期监听的端口，才更值得警惕。

4.3 排查习惯比命令本身更值钱

我见过不少新人把命令参数背得很熟，但一到真实故障现场就乱了手脚，原因就是没有形成相对固定的排查动作。我自己踩过几次坑之后，总结出三个非常实用的小习惯。

第一个习惯，先记录后动手。开始排查时，先在记事本或终端里留下一个时间戳，把故障现象原样抄一遍，比如“浏览器打不开 www.example.com，微信正常”。这看起来很简单，但能帮你避免排查到一半忘掉最初的约束条件。很多问题的判断依据就是这些现象之间的细微差别。

第二个习惯，命令输出尽量留档。尤其是做安全自查时，netstat、arp -a 和 route print 的输出都是定位异常的关键证据。把输出保存到文件，或者直接截图留存，既方便事后复盘，也能在需要时跟同事讨论。

第三个习惯，不要一上来就重启。很多人一遇到网络问题第一反应是重启电脑、重启路由器、重装驱动，其实这会破坏现场。换到安全视角也一样，如果怀疑主机被植入恶意程序，第一时间重启会导致内存里的恶意进程消失、可疑连接断掉，留下不了证据。先跑一遍 netstat -ano 和 tasklist 这种基本命令，把“现场”固定下来，再决定怎么处理。

4.4 一条好记的排查线索口诀

把常用的排查顺序编成一个“口诀”，实战中很有帮助：先看网卡配置（ipconfig），再测本机回路（ping 127.0.0.1），网关通不通定内网（ping 网关），公网通不通定出口（ping 公网IP），域名解析靠 nslookup，端口服务用 telnet 和 curl，路径问题 tracert 查，异常连接找 netstat，局域网异常翻 arp，方向不对看 route。

这句话其实就是我平时排查所有网络问题的基本套路。你不需要每次都把整套命令跑完，大多数时候跑到第三步“ping 网关”就能定位故障了。比如网关 ping 不通，再做 tracert 也没意义，直接去查交换机和网线就行。能少跑命令的时候反而说明你对问题层级有准确的判断。

最后再分享一个小技巧。如果你觉得 tracert 每次输出太零散，可以在 Windows 上用 pathping 命令把路径追踪和丢包统计结合在一起，它会先做路由追踪，再对每一跳发送一定数量的探测包做统计，比单独跑 tracert 再跑 ping 高效得多。Linux 下更省事的做法是用 mtr 目标地址，它把 traceroute 和 ping 的动态统计放在一个界面里，刷新实时更新延迟和丢包率，排查“高延迟”“间歇性丢包”这类问题时信息密度非常高。这两个命令本质上都是把前面提到的八组基础命令做了一层组合和封装，我建议你先把基础的跑熟，再借助它们提速。