上个月帮一个刚转行的朋友排查网络问题，他发来一长串ping结果，说"网关也通、外网也通，但网页就是打不开"。我让他顺手测一下DNS解析和80端口，结果问题一分钟就定位了——不是"网络断了"，而是内网DNS解析出了一个错误地址。这件事让我意识到，很多刚入门的运维朋友不缺命令，缺的是"在什么场景下该用什么工具、工具输出该怎么解读"的完整认知。
这篇内容就是冲着这个需求来的。我不会把网上能搜到的工具列表原样抄一遍，而是按网络运维实际工作的逻辑，把工具拆成几类：连通性诊断、端口探测、抓包分析、DNS与HTTP排障、远程管理与自动化。每一类下挑使用频率最高、最能说明问题的工具来讲，讲它们的原理、常用参数、输出解读，以及我在真实排障里踩过的坑。适合刚入行的网络管理员、转岗运维的开发同事，以及所有想系统建立网络排查能力的人。收藏当然有用，但更希望你能顺着这篇建立起自己的排查思路。
1. 先搞清楚网络运维在做什么：工具不是万能的，职责才是起点
很多零基础的朋友一上来就搜"网络运维工具大全"，装了一堆软件，结果遇到真实故障还是懵的。问题出在顺序上——你没有先想清楚网络运维这份工作到底由哪些职责组成。工具只是完成职责的手段，先有职责清单，才有工具清单。
1.1 网络运维的五类日常工作
网络运维不是"网断了拉根线"这么简单。按我自己的经验，日常核心工作基本落在五件事上：
第一，连通性保障。用户上不了网、办公系统卡顿、跨地域专线延迟高，这些是最高频的故障，占了排障工作量的一半以上。你要能快速判断是链路问题、设备问题还是应用问题。
第二，地址与配置管理。交换机、路由器、防火墙上的IP规划、VLAN划分、路由表、访问控制策略，都是静态资产，但一旦混乱，后续所有排障都会变得非常痛苦。
第三，安全边界控制。端口开放管理、访问控制规则、异常流量识别。这块和网络安全有交叉，但网络运维至少要做到"知道哪些端口该开、哪些不该开"。
第四，监控与容量规划。带宽利用率、设备CPU和内存、链路丢包率、日志告警。没有监控的网络运维等于闭着眼睛开车，等用户投诉了才知道出问题。
第五，故障响应与复盘。故障发生时快速定位、恢复，事后写复盘报告。这部分最考验对工具的熟练度，也最考验排查思路的条理性。
这五类工作对应着你需要掌握的工具类型。比如连通性保障需要ping、tracert、telnet这类基础命令；监控容量需要Zabbix、Prometheus这类平台；而故障响应需要你把前面所有工具串联起来用。很多人只盯着第三类下面的某个工具拼命学，却忘了工具是服务职责的，这个顺序不能反。
1.2 先给工具分好类，再逐个击破
我建议你把"网络运维工具"理解成五个抽屉，而不是一张长长的清单：
| 抽屉 | 解决什么问题 | 代表性工具 |
|---|---|---|
| 连通性诊断 | 网络通不通、路径通不通、延迟高不高 | ping、tracert/traceroute |
| 端口与服务探测 | 某个IP的某个端口是否开放、服务是否在监听 | telnet、nc、netstat/ss |
| 协议与流量分析 | 数据包层面看到底发生了什么 | Wireshark、tcpdump |
| 域名与HTTP排障 | 解析对不对、网站响应是否正常 | dig/nslookup、curl |
| 远程管理与自动化 | 登录设备改配置、批量巡检、持续监控 | SSH、脚本工具、监控平台 |
这张表里的分类逻辑，就是网络排障的五个层次：链路通不通、端口通不通、包传得对不对、域名解析对不对、应用响应正不正常。后面所有工具详解，我都按这个分类来讲。你只要记住"先确定在哪一层出了问题，再选对应的工具"，就不会陷入"学了工具不知道怎么用"的困境。
2. 零基础的优先清单：先学这五样，胜过把工具全装一遍
我见过不少新人，第一天就把Wireshark、Nmap、Zabbix全装上了，然后对着满屏的窗口发呆。工具装得再多，不如先把最核心的几样练熟。
2.1 为什么不能"全都要"
学网络运维工具和学做饭很像。你不会第一天就把八大菜系的菜谱全背下来，而是先学会煮饭、炒青菜、做个番茄蛋汤，能养活自己了再去琢磨硬菜。工具也一样，零基础阶段你的目标是：遇到一个网络故障能独立排查，而不是把所有工具的参数都背下来。
另外一个现实原因是：很多工具需要组合使用才会产生价值。你先学会了ping，再学tracert，会发现"哦，原来ping通只是起点，路径上的每一跳才透露真正的信息"；你先会telnet测端口，再学Wireshark，会发现端口通了不代表握手没问题。工具是互相嵌套的，按顺序学才能形成知识体系。
2.2 按使用频率排出的入门优先级
我根据自己带新人的经验，按"使用频率"和"学习成本"两个维度排了一个顺序，零基础照着走就行：
| 学习顺序 | 工具/命令 | 主要用途 | 学习成本 | 使用频率 |
|---|---|---|---|---|
| 1 | ping、tracert/traceroute | 判断网络通不通、路径通不通 | 低 | 每天 |
| 2 | netstat/ss、telnet/nc | 看本机连接状态、测远程端口 | 低 | 每天 |
| 3 | ipconfig/ifconfig/ip、arp | 查看本机地址、网关、ARP表 | 低 | 每天 |
| 4 | dig/nslookup、curl | DNS解析排查、HTTP接口查看 | 中 | 每周 |
| 5 | Wireshark、tcpdump | 抓包分析协议交互 | 高 | 按需 |
为什么把Wireshark排到第五？因为它虽然强大，却需要一定的协议基础才能看懂。我建议零基础的你先练熟前四个，遇到问题能快速定位到"端口通不通""解析对不对"这一层，再往"数据包层面发生了什么"去深入学习，这样会有茅塞顿开的感觉。
前四个工具加起来，一个周末就能掌握基本用法。真正花时间的是练习"组合使用"：比如用户说上网慢，你先ping网关看内网延迟，再ping外部地址看公网延迟，对比一下就能把问题缩小到内网还是外网。这种组合思路，不是靠单独学某个工具能获得的，得靠多练。
3. 逐个拆解：命令行工具与图形化工具的实战笔记
这一章是核心干货。我会按工具分类逐个讲，每条都包含"基本用法"和"输出解读"，并且尽量用真实场景里的例子来说明。你会发现，工具本身不复杂，复杂的永远是输出怎么读。
3.1 ping、tracert、netstat：连通性三件套
先说ping。它发送ICMP回显请求，目标主机回应的话就说明IP层连通。我实际用的时候，重点看三个信息：
time值：内网环境一般 <1ms，跨运营商或公网链路一般 10-50ms；如果持续在 100ms 以上，该考虑链路质量问题。- 丢包率：连续ping 100个包，丢包超过1%就要重视，超过5%基本能断定链路不稳定。
TTL值：TTL=128 大概率是Windows设备，TTL=64 大概率是Linux或网络设备。每次经过一台路由器TTL减1，所以从TTL能粗略猜出中间隔了几跳。
比如你ping一台服务器看到 TTL=56，那说明中间大概经过了8跳（64-56），网络路径基本正常。如果对于某些跨域链路，TTL只是参考，因为初始TTL可以被服务器修改，别把它当铁证。
再说tracert（Windows）和traceroute（Linux）。它用来查看数据包从你这里到目标经过哪些路由节点。我常用的参数是tracert -d 目标IP，-d表示不做反向DNS解析，速度会快很多。看结果时注意：
- 前三跳一般是你所在网络的网关和运营商接入设备，延迟在 1-10ms 正常。
- 中间跳延迟增大通常说明跨区域传输，但要结合丢包判断。如果某一跳持续"请求超时"，不要立刻断定故障，很多设备出于安全考虑不回应ICMP。
- 最后一跳的延迟和丢包最有价值。前面都稳、最后一跳丢包，大概率是目标服务器自身或它所在机房的入口问题。
netstat（Windows）和ss（Linux）用来查看本机当前的TCP/UDP连接状态。我最常用的两种姿势：
netstat -ano：列出所有连接和监听端口，-o还能看到占用连接的进程PID，再用tasklist | findstr PID反查是哪个程序。排查"端口被谁占了"就靠它。ss -tnp：Linux下查看TCP连接状态，-t只看TCP，-n数字显示端口，-p显示进程信息。看ESTABLISHED和TIME_WAIT数量能初步判断连接是否异常堆积。
一个小经验：Windows 10/11默认没有telnet命令，但netstat是系统自带的，所以排查本机端口占用时netstat更顺手。telnet的问题我下面会专门讲。
ping -n 10 192.168.1.1 # Windows，连续ping 10次 ping -c 10 192.168.1.1 # Linux，连续ping 10次 tracert -d 8.8.8.8 # 常见用法（示例仅演示），-d 不做域名反解需要说明的是，上面的8.8.8.8是公共DNS地址，我在实际排障中也经常用本地的223.5.5.5这些国内公共DNS来测试外网连通性。原理都一样，关键看你习惯用哪个。
3.2 telnet、nc：端口探测的正确姿势
网络排障里有个经典问题："IP通了，但业务连不上。"这时候就要测端口。telnet是最简单的端口测试工具：telnet 目标IP 端口。如果端口开放，你会看到连接成功的提示或光标变化；如果端口关闭，会立刻报"无法打开到主机的连接"。
但注意两个坑。第一，Windows默认不装telnet客户端，需要去"启用或关闭Windows功能"里勾选，或者直接用PowerShell的Test-NetConnection 目标IP -Port 端口，功能一样。第二，telnet测的是"端口通不通"，端口通不代表业务正常——你telnet数据库3306端口通了，但账号密码错误照样登录不了，这是应用层的问题，不能怪网络。
Linux下我更喜欢用nc（netcat）：
nc -zv 192.168.1.100 22 # -z 只扫描不发送数据，-v 显示详情 nc -vz 192.168.1.100 20-80 # 测试一段范围内的端口nc -vz在脚本里很好用，批量检查一批主机的端口开放情况时，配合一个for循环就能跑完。另外，用nc还可以做简单的端口监听测试：在一台机器上nc -l 12345，另一台机器连过来，验证两台机器之间的防火墙放行策略是否生效。这个技巧在临时排查防火墙规则时非常管用，我后面讲排障案例还会用到。
3.3 dig、nslookup、curl：从DNS到HTTP的排障视角
DNS解析错误是个让人头疼的问题，因为"网页打不开"往往不是网络断了，而是域名解析出来的IP不对。先看基础命令：
nslookup 域名：Windows和Linux都有，能看出域名解析到哪个IP、用的是哪个DNS服务器。dig 域名：Linux下的增强版，信息更详细。dig 域名 +short可以直接只看解析结果，脚本里很方便。dig 域名 @114.114.114.114是指定用某个DNS服务器来查询，用来对比"用默认DNS解析"和"用公共DNS解析"的结果是否一致。
我在排障"网页打不开"时最常用的一招：分别用两种DNS查询同一域名，如果默认DNS返回的IP和公共DNS返回的不一致，问题基本就是内网DNS缓存或解析记录出错。改一下DNS服务器或刷新缓存通常就解决。
说回curl。它是排查HTTP层问题的利器，常用参数：
curl -I https://example.com # 只看响应头，判断网站是否正常返回200 curl -v https://example.com # 显示完整握手和请求过程，定位卡在哪一步 curl -o /dev/null -s -w '%{time_total}\n' https://example.com # 看总耗时curl -v的输出特别适合定位"连上了但没响应"的问题。你会清晰地看到TCP连接建立、TLS握手、发送请求、接收响应这几个阶段分别耗时多少。如果TCP连接建立了但TLS握手卡住，多半是中间设备拦了证书或存在MTU问题；如果请求发出去了没响应，则要回头检查应用服务器。
我个人的经验：遇到任何"能上网但某个网站打不开"的反馈，先nslookup再curl -v，两步就能把问题从"网络"和"应用"之间切开。比直接抓包高效得多。
3.4 Wireshark 和 tcpdump：把网络"看见"
走到这一步，说明你已经熟练掌握了前面的工具，准备深入数据包层面了。Wireshark是图形化抓包工具，tcpdump是命令行抓包工具，两者相辅相成。
先说tcpdump，它的优势是轻量、适合在服务器上直接抓：
tcpdump -i eth0 -nn host 192.168.1.100 # 抓指定主机的包，不解析域名 tcpdump -i eth0 -nn port 80 # 抓指定端口的包 tcpdump -i eth0 -nn -c 100 -w /tmp/a.pcap # 抓100个包后停止，保存到文件-c限制抓包数量是最实用的习惯之一。很多新人直接在服务器上抓包，忘了加-c，结果几秒钟生成了几百兆的文件，磁盘爆了。你可以在抓包前先想清楚"我要看什么现象"，比如"看看客户端80端口有没有请求进来"，那就port 80加-c，抓到想看的现象就停。
抓完的pcap文件，用Wireshark打开来分析。
Wireshark的重点不是怎么点"开始抓包"，而是抓包前设置过滤条件、抓完后用显示过滤器快速定位。我常用的显示过滤表达式：
tcp.port == 443：只看443端口的流量ip.addr == 192.168.1.100：只看某台主机的流量tcp.flags.syn == 1 && tcp.flags.ack == 0：只看TCP三次握手中的SYN包http.request：只看HTTP请求tcp.analysis.retransmission：只看重传包——重传多基本就是网络质量差
这里有一个很多人没意识到的点：Wireshark不是用来"看所有包"的，而是用来"精准回答一个具体的网络问题"的。比如你怀疑某个客户端连接服务器很慢，那就只抓那个客户端的包，然后观察三次握手的间隔。如果SYN发出后很久才收到SYN-ACK，那是中间链路问题；如果SYN-ACK秒回但客户端迟迟不发ACK，那问题出在客户端本身。这种“顺着一个现象抓一条链路”的思路，比漫无目的地抓包高效得多。
3.5 SSH 与自动化工具：远程管理不能只靠手工
前面讲的都是排查工具，但网络运维还有一大块日常工作是"登录设备改配置、批量巡检主机"。这块靠的是SSH和自动化脚本。
SSH的核心用法不多，但有几个细节值得注意：
- 用密钥登录而不是密码登录。
ssh-keygen生成密钥对，再把公钥放到目标机器的~/.ssh/authorized_keys里。以后登录不光免密，更安全。 - 常用参数：
ssh -p 2222 user@host指定端口；ssh -i keyfile user@host指定密钥文件；ssh -o StrictHostKeyChecking=no在脚本里跳过首次连接确认。 - 别在脚本里硬编码密码。要么用密钥，要么用专门的凭据管理方式。这个习惯越早养成越好。
当你需要同时检查几十台设备的磁盘、负载和连接数时，一条条登录太累了。这时候可以用简单脚本封装命令，批量执行。比如用bash写个循环，把IP列表放文件里，逐个SSH执行df -h和uptime并汇总输出。这个阶段不需要上多复杂的工具，先把脚本写顺手，然后再考虑Zabbix、Prometheus这类监控平台的接入。
4. 把工具串起来：一次典型"网页打不开"故障的完整排查链路
工具单独会用，只是一个阶段的结束。真正让运维工作产生价值的，是把工具串联起来形成一套排查方法。下面我用一个真实场景——"某办公区用户反馈网页打不开"——完整演示一次排查过程。
4.1 故障现象与初步范围判断
反馈说"网页打不开"，我先问三句话：是所有人打不开还是个别用户？是所有网站打不开还是某个网站？刚开始就这样还是一直这样？
这个例子里的答案是：整个办公区多台电脑都打不开，但微信收发正常，只是浏览器网页打不开。一听这个范围，我立刻判断：不是物理链路断了，因为微信能通，说明网络链路基本OK；问题大概率出在HTTP/HTTPS访问相关的环节——DNS解析、TCP 80/443端口、或者HTTP应用代理。
这个"先问范围再定方向"的习惯特别重要。范围决定排障起点，方向决定用哪套工具，而不是上来就盲目抓包。
4.2 分层次排查的完整过程
我的排查顺序是"本机→网关→DNS→端口→数据包"。
第一步，看本机网络配置。命令行执行ipconfig，确认IP、掩码、网关、DNS都拿到了。办公区一般自动分配地址，如果IP是169.254开头的，说明没拿到地址，物理接入就有问题。这步正常，排除。
第二步，ping网关。ping 网关IP，时延1ms以内、无丢包，内网二层和三层的访问链路基本健康。然后ping外部地址，比如ping 223.5.5.5，通，但时延稍高，说明出口链路在线。
第三步，查DNS解析。nslookup 用户要访问的域名。结果出来了：解析出的IP看着不太对——正常应该解析到公网某个IP，但返回的却是内网网段的地址。这基本就是问题所在了。再用nslookup 域名 223.5.5.5对比，发现公共DNS解析正常。问题范围锁定：内网DNS服务器或相关记录坏了。
第四步，验证HTTP端口。换个角度，用curl -v访问目标域名，看到TCP连接目标IP的80端口，但连接被拒或超时。这进一步印证：请求被指到了错误的地址。
第五步，抓包确认。在内网某台机器上用tcpdump抓一下DNS请求和响应，确认本机确实发出解析请求、DNS服务器也回了，但回的是一条错误记录。到这一步，根因基本清楚——内网DNS Server上面有条错误的解析记录或缓存，指向了已经失效的地址。
4.3 最终定位与复盘
处理方式不复杂：修正内网DNS的解析记录，刷新缓存，然后在用户电脑上执行ipconfig /flushdns清掉本机DNS缓存。客户端再访问域名，解析到正确地址，网页秒开。
这个案例里工具其实都很基础：ipconfig、ping、nslookup、curl、tcpdump，没有一个是冷门工具。关键是顺序——从最近的本机开始，逐层往外排查，每一层都用该层最适合的工具回答一个具体问题。链路通不通用ping，解析对不对用nslookup，端口通不通用telnet/curl，数据包用什么用tcpdump。当你习惯了这种分层排查的思路，你会发现自己根本不需要多少工具，就能解决绝大多数日常故障。
我自己事后复盘的体会是：如果一开始就用Wireshark抓包，虽然是"专业"的做法，但效率反而低。分层排查的意义在于，每一步都在缩小问题范围，越往后越精准。抓包应该是定位到一定阶段后用来验证假设的手段，而不是第一步就全面铺开的手段。
5. 这些坑我替你踩过了：网络运维工具使用的典型误区
下面这些误区，是我在实际操作中反复见过、也亲身踩过的。每一个背后都是一个"工具输出正常，但结论完全错误"的教训。
5.1 ping通了，不代表网络没问题
这是最常见的误判。ping通只说明ICMP包从A到了B，它不能告诉你带宽是否够用、TCP传输是否丢包、应用层是否正常。
我遇到过一个案例：用户投诉视频会议卡顿，我ping服务器延迟只有2ms，零丢包，差点就下了"网络没问题"的结论。后来用iperf测了下实际TCP吞吐，才发现带宽被某台交换机的广播风暴拖垮，实际可用吞吐只有正常值的十分之一。ping的好成绩掩盖了真实问题。
所以要把ping当成"第一层筛查"而不是"最终鉴定"。凡是涉及"慢""卡"的反馈，只靠ping是不够的，需要结合端口测试、抓包看重传率、甚至直接用测速工具验证实际带宽。
5.2 设备禁ping，导致误判"设备挂了"
很多生产环境的防火墙和网络设备默认丢弃ICMP，这会导致一个现象：你明明知道设备还在正常转发电网，但ping它就是不回。如果你经验不足，很容易误判成"设备宕机"。
正确做法是：ping不通时不要急着下结论，先看它是否还在正常工作。比如ping网关不通，但上网正常，那就说明网关活着，只是不回应ICMP。再比如ping某台服务器不通，但telnet它的22端口是通的，那服务器自然没问题。工具的输出要交叉验证，不能只看一条就定性。
5.3 抓包不设过滤，文件瞬间爆炸
我见过一个新人在核心交换机上直接tcpdump -i eth0没有任何过滤，五分钟不到，磁盘就满了。核心交换机上流量非常大，全量抓包等于自找麻烦。
抓包前先想清楚两个问题：抓哪个网卡、抓什么样的流量。确定了就加过滤条件，再加-c限制包数量或者-w指定保存目录并配合定时清理。抓包永远是为了回答一个具体问题，不是为了"看看有什么流量"。
5.4 忽略工具版本差异，命令行用错
Windows和Linux的同名命令并不完全等价。tracert是Windows，traceroute是Linux；ipconfig是Windows，ifconfig和ip是Linux；Windows自带的telnet默认未启用，Linux下默认有。这些差异对新手来说是很大的坑——在Windows上输了traceroute会提示命令不存在，你以为是系统坏了，其实只是命令叫法不同。
建议你两手准备：在Windows环境练熟一套命令，在Linux环境练熟一套命令，然后记下它们之间的对应关系。我自己的话，Windows下优先用PowerShell的Test-NetConnection，Linux下优先用ss和traceroute，跨平台时尽量用SSH隧道到一台Linux跳板机上操作，这样命令风格统一，不容易混。
6. 收藏之后的进阶路线：怎么把工具变成自己的本事
文章标题说"收藏这篇就够了"，但收藏只是起点。工具列表存在书签里不会自动变成你的能力，关键在于后续的刻意练习和体系建设。
6.1 维护一份个人命令手册
我从入行第三年开始，养成了一个习惯：每遇到一个有用的命令、一次经典的排障过程，就记录到自己的命令手册里，按场景分类。比如"端口不通查什么""DNS解析异常查什么""连接卡顿查什么"各成一节。
记录格式很简单：场景、命令、输出解读、结论。比如"办公区用户访问某系统慢——curl -v 看握手耗时——TCP握手正常但等待应用响应时间长——问题定位到应用层"。这份手册在我后来带新人时起了大作用，因为新人很多问题不是"不懂命令"，而是"不知道在这个场景该用什么命令"。
6.2 从单点命令走向自动化运维
当你单条命令熟练之后，下一步一定是自动化。普通的巡检脚本，能把几十台主机的df -h、uptime、free -m批量拉回来汇总；进一步再学习监控平台，把"主动排查"变成"被动告警"。我常用的一组脚本思路是：定时对关键设备做ping + 端口探测，失败就触发告警，这样很多问题在用户发现之前就已经处理掉了。
这个阶段，你不再需要时刻盯着命令行，而是要学会"怎么让工具自己替你盯"。网络运维的核心价值也从"会修"转向"会预防"。
6.3 深入协议理解，而不是停留在命令记忆
最后一条进阶建议可能和其他文章不一样：不要把精力浪费在背诵工具参数上，而是去理解TCP/IP、HTTP、DNS这些协议本身。工具只是协议的外在表达——你理解了TCP三次握手，自然就理解为什么tcp.flags.syn==1这个过滤条件有意义；理解了DNS解析过程，自然就明白为什么nslookup的结果能定位到"解析记录错误"。
协议基础从哪里补？几个方向供参考：看抓包文件里的交互过程，配合协议文档理解每个字段；读一些网络排障案例，重点关注别人"为什么选择这一步"；有条件的话搭一套小实验环境，自己发请求自己抓包，亲手验证TCP握手和HTTP交互。
我的个人体会是，工具列表是最容易被遗忘的东西，但排查思路和协议理解会一直留在这。你看到这篇内容时可能刚开始接触网络运维，也可能已经工作一两年。无论哪种状态，都建议你少收藏、多动手。把文章里的命令自己敲一遍，把那个"网页打不开"的案例自己模拟一遍，哪怕是在自己电脑上搭个虚拟机环境。工具这东西，只有落到你手上的才算数。
