Linux 网络排查必备命令全解析
在网络运维或日常开发中，"连不上服务器"、"接口报错"、"网页打不开" 这类问题几乎每天都可能遇到。很多人排查网络问题时，第一反应只有一个命令：ping。但现实往往没这么简单，ping 通了，不代表服务一定正常；ping 不通，也不代表机器一定挂了。
真正高效的排查，不是反复猜，而是按层次定位问题：链路通不通、端口开没开、应用有没有响应、DNS 解析对不对。
这篇文章把 Linux 下最常用的几个网络排查命令整理成一套实战指南：ping、telnet、curl、dig、nslookup。目标很直接，帮你从"只会试一试"变成"知道下一步该查什么"。
先建立一个排查思路
遇到网络问题时，可以先别急着重启服务，按下面这个顺序排查：
- 用
ping看基础链路是否可达。 - 用
telnet看目标端口是否开放。 - 用
curl看应用层服务是否真的正常响应。 - 用
dig或nslookup看域名解析是否正确。
这个顺序的好处是：每一步都在缩小问题范围。你不是在碰运气，而是在逐层排除。
第一层：基础连通性检查 ping
ping 是网络排查最常见的起点。它基于 ICMP 协议，主要用于测试当前主机到目标主机之间的网络链路是否通畅。
它能回答几个最基础的问题：
- 当前机器是否具备对外通信能力
- 目标主机是否在线
- 网络是否存在明显丢包
- 时延是否异常升高
常用参数
-c <次数>：指定发送请求的次数，发完自动停止-t <数值>：设置TTL，有时可辅助判断经过了多少跳-s <包大小>：指定数据包大小，常用于排查MTU问题-i <秒数>：设置发送间隔-W <秒数>：设置单次等待超时时间
常见用法
# 发送 5 个包后自动结束
ping -c 5 www.example.com
# 测试大包传输，常用于排查 MTU 问题
ping -s 1472 www.example.com怎么看结果
- 能收到回复：说明链路大概率是通的，至少网络层没有完全中断
- 延迟很高：说明网络可能拥塞，或者链路绕行严重
- 有明显丢包：说明链路质量存在问题
- 完全超时：可能是目标机器不通，也可能是
ICMP被拦截
一个很常见的误区
现在很多云服务器和企业网络环境里，安全组或防火墙会直接禁掉 ICMP。这意味着：
ping不通，不一定代表服务挂了ping通了，也不代表80、443、3306这些业务端口一定正常
所以 ping 更像一个"第一眼检查"，不能当最终结论。
第二层：端口与服务检查 telnet 和 curl
如果 ping 不通，或者 ping 虽然通了但网页、接口、数据库依然访问失败，就需要继续看传输层和应用层。
telnet：看端口到底开没开
虽然 telnet 作为远程登录协议早已不推荐继续使用，但作为一个快速测试 TCP 端口连通性的工具，它依然非常直接。
它最适合回答这个问题：目标机器能到，但对应端口到底有没有监听、有没有被拦住？
基本用法
telnet <IP或域名> <端口号>
# 示例
telnet 192.168.1.100 80典型结果解读
Connected to ...：说明目标端口开放，链路可达Connection refused：说明机器可达，但端口没开，通常是服务没启动Trying ...长时间卡住：通常意味着中间被防火墙丢弃，或者网络路径不通
适合排查哪些问题
- Web 服务端口是否开放
- Redis、MySQL、SSH 等服务是否监听
- 是应用没启动，还是网络策略把流量挡住了
一个补充
很多新系统默认不安装 telnet。如果你的环境里没有这个命令，实际排查时也常用 nc 或 curl 做替代。但如果只是理解网络排查思路，telnet 仍然是最容易入门的例子。
curl：看服务是不是"真正常"
如果说 telnet 只是帮你确认"门开了没"，那 curl 就是在进一步确认：门开了之后，屋里到底有没有人、回的话对不对。
curl 是命令行里最实用的 HTTP 调试工具之一。它不只是判断通不通，还能直接看到响应头、响应体、状态码、重定向、认证、SSL 握手等信息。
常用参数
-I：只请求响应头，适合快速看状态码-i：显示响应头和响应体-v：输出详细交互过程，调试时非常好用-X：指定请求方法，如POST、PUT、DELETE-d：发送请求体，常配合POST-H：自定义请求头-o/-O：下载文件-L：自动跟随重定向-k：忽略 SSL 证书校验错误-u：传递基本认证用户名密码-s：静默模式，适合脚本
常见用法
# 快速检查网站状态
curl -I https://www.example.com
# 查看完整响应头和响应体
curl -i https://www.example.com
# 调试请求细节
curl -v https://www.example.com
# 模拟 POST JSON 请求
curl -X POST \
-H "Content-Type: application/json" \
-d '{"key":"value"}' \
http://api.example.com/login
# 测试自签名 HTTPS 接口
curl -k https://internal-api.example.comcurl 能帮你判断什么
- 接口是否返回了正确状态码
- 服务是否发生了重定向
- 网关、反向代理是否配置异常
- 证书问题是不是导致 HTTPS 请求失败
- 请求头、认证信息、参数格式是否正确
很多"浏览器打不开"的问题，本质上并不是网络断了，而是服务返回了 301、403、404、500，或者 HTTPS 握手失败。这个阶段，curl 的价值就远高于 ping。
第三层：域名解析检查 dig 和 nslookup
如果你发现直接访问 IP 没问题，但换成域名就不行，大概率问题已经不在链路和端口，而是在 DNS。
这时候就应该看域名解析。
nslookup：简单直接，适合快速确认
nslookup 的特点就是上手简单，适合快速确认一个域名到底解析到了哪个 IP。
常见用法
# 查询默认 DNS 的解析结果
nslookup www.example.com
# 指定 DNS 服务器查询
nslookup www.example.com 8.8.8.8适用场景
- 快速确认域名当前解析结果
- 对比不同 DNS 服务器的返回值
- 检查本地 DNS 是否生效
如果你只是想快速看一眼"这个域名现在指向哪台机器"，nslookup 已经够用了。
dig：信息更全，适合深入排查
和 nslookup 相比，dig 更适合运维和正式排障场景，因为它返回的信息更完整，能看到记录类型、TTL、权威应答、解析链路等更多细节。
常见用法
# 查询 A 记录
dig www.example.com
# 只看结果 IP，输出更简洁
dig www.example.com +short
# 追踪完整解析链路
dig www.example.com +tracedig 特别适合排查这些问题
- 域名是否已经正确生效
TTL是否导致旧记录还在缓存中- 解析是否被 DNS 劫持
- 权威 DNS 配置是否有误
- 解析链路中哪一层出现了问题
如果线上出现"有些地方能访问，有些地方不能访问"，或者"我本地可以，别人不行"，dig 往往比 nslookup 更容易给出线索。
一张表看懂这几个命令的区别
| 命令 | 工作层级 | 核心功能 | 常见场景 |
|---|---|---|---|
ping | 网络层（ICMP） | 测基础连通性 | 检查断网、主机是否在线、丢包和延迟 |
telnet | 传输层（TCP） | 测端口是否开放 | 检查 80、443、3306、22 等端口 |
curl | 应用层（HTTP/HTTPS） | 测服务是否正常响应 | 检查 API、网页、证书、重定向、状态码 |
dig / nslookup | DNS 解析层 | 测域名解析 | 检查域名是否解析正确、DNS 是否生效 |
一套更实用的标准排查流程
很多时候，网络问题并不是真的"断网"，而是卡在某一层。一个更实用的问诊顺序是：
第一步：先 ping 域名或 IP
确认基础链路是否通畅，顺便观察是否存在明显丢包和高延迟。
第二步：再 telnet 到目标端口
如果链路没问题，就继续判断业务端口是不是开放，服务有没有在监听。
第三步：用 curl 请求真实地址
如果端口开放，再进一步确认服务是否真正返回了正确结果，而不是返回错误页、重定向或证书异常。
第四步：如果 IP 可以、域名不行，就查 dig
这一步通常能快速定位到 DNS 记录错误、缓存延迟、生效不一致等问题。
一个简单的记忆方式
你可以把这几个命令理解成在排查一栋房子：
ping：先看这条路能不能走通telnet：再看门有没有开curl：进门后看里面的人是否正常回应dig/nslookup：最后确认你找的门牌号是不是写错了
这么记住之后，很多排查步骤就不会乱。
最后
网络排查最怕的不是不会命令，而是只会一个命令。真正有效的方式，是建立一套按层定位问题的思路。
当你下次再遇到"连不上"、"打不开"、"接口超时"时，不妨按这条路径来：
ping -> telnet -> curl -> dig这四步不一定覆盖所有问题，但足够解决大多数日常网络排障场景。把它练熟，很多问题你都能在几分钟内判断出是网络、端口、服务，还是 DNS。