? 为什么 Linux 网络诊断命令非得吃透？说多了都是泪
当年我负责维护公司那台老服务器时，就因为不懂 netstat，一次小故障愣是排查了 3 小时，最后被总监在会上点名批评。你想想，用户投诉电话快打爆了，你却对着黑屏发呆 —— 这滋味谁受得住？Linux 网络诊断命令就是系统管理员的手术刀，刀快不快，直接决定你能不能在老板瞪眼前搞定问题。
别以为记几个命令就行，真正的高手都是把这些命令玩出花的。比如同样是查端口占用，新人只会用 netstat -tuln，老手却能一秒切换到 ss -ltnp，效率差十倍不止。更别说遇到复杂的网络延迟问题，traceroute 和 mtr 的组合拳，能让你像 CT 扫描一样看穿数据包的每一步行踪。
? 吃透这几个命令，90% 的网络问题都能秒破
ping 命令：连通性排查的开山斧
这玩意儿简单到新手都能上手，但真正用明白的没几个。默认 ping 四次？太初级了。遇到间歇性丢包，试试 ping -c 100 -i 0.5 目标 IP，连续发 100 个包，间隔 0.5 秒，丢包率一目了然。要是怀疑 DNS 解析问题，直接 ping 域名，看返回的 IP 对不对 —— 对不上？赶紧检查 /etc/resolv.conf 配置去。
这玩意儿简单到新手都能上手，但真正用明白的没几个。默认 ping 四次？太初级了。遇到间歇性丢包，试试 ping -c 100 -i 0.5 目标 IP，连续发 100 个包，间隔 0.5 秒，丢包率一目了然。要是怀疑 DNS 解析问题，直接 ping 域名，看返回的 IP 对不对 —— 对不上？赶紧检查 /etc/resolv.conf 配置去。
不过 ping 也有坑。有些服务器会禁用 ICMP 包，这时候 ping 不通不代表网络断了，得结合 telnet 目标端口来判断。我上次就遇到过，ping 某云服务器一直超时，结果 telnet 80 端口通着，后来才知道对方防火墙封了 ICMP。记着，ping 只是第一步，不是终点。
traceroute 与 mtr：追踪数据包的千里眼
traceroute 能帮你画出数据包从本地到目标的路径，但默认用 UDP 包，有些路由器会过滤，这时候加 - T 参数用 TCP 探测更靠谱。比如 traceroute -T -p 80 www.baidu.com，能模拟 HTTP 请求的路径。
traceroute 能帮你画出数据包从本地到目标的路径，但默认用 UDP 包，有些路由器会过滤，这时候加 - T 参数用 TCP 探测更靠谱。比如 traceroute -T -p 80 www.baidu.com，能模拟 HTTP 请求的路径。
但我更爱用 mtr，这货是 traceroute 和 ping 的结合体，实时显示每一跳的丢包率和延迟。上次排查跨机房访问慢的问题，mtr 一跑就发现第 7 跳路由器延迟突然从 20ms 飙到 300ms，直接把截图甩给运营商，半小时就解决了。mtr 比 traceroute 强在哪？它能看出是偶发还是持续故障，这在排查间歇性问题时太关键了。
netstat 与 ss：端口占用的照妖镜
netstat 虽然老，但在很多老服务器上还在用。查监听端口用 netstat -tuln，查进程对应的端口加 - p 参数（得用 root 权限）。不过现在更推荐 ss，速度比 netstat 快好几倍，特别是服务器连接数多的时候，ss -ltnp 能瞬间列出所有监听的 TCP 端口和对应的进程，爽得一批。
netstat 虽然老，但在很多老服务器上还在用。查监听端口用 netstat -tuln，查进程对应的端口加 - p 参数（得用 root 权限）。不过现在更推荐 ss，速度比 netstat 快好几倍，特别是服务器连接数多的时候，ss -ltnp 能瞬间列出所有监听的 TCP 端口和对应的进程，爽得一批。
记得有次发现服务器带宽异常，用 ss -s 一看，ESTABLISHED 状态的连接数比平时多了三倍，再结合 ss -o state time-wait '(dst 目标 IP)'，直接定位到是某个爬虫在疯狂建连接，kill 掉进程立马恢复正常。端口排查，快一秒都是优势。
tcpdump：抓包分析的终极武器
这工具堪称网络医生的听诊器，能把流过网卡的数据包扒得明明白白。新手可能觉得复杂，但记住几个常用参数就行：tcpdump -i eth0 host 192.168.1.100，只抓和这个 IP 的通信；想存下来慢慢看就加 - w 文件名，之后用 - Wireshark 分析。
这工具堪称网络医生的听诊器，能把流过网卡的数据包扒得明明白白。新手可能觉得复杂，但记住几个常用参数就行：tcpdump -i eth0 host 192.168.1.100，只抓和这个 IP 的通信；想存下来慢慢看就加 - w 文件名，之后用 - Wireshark 分析。
我上次处理邮件发送失败的问题，就是用 tcpdump 抓到了 SMTP 握手包，发现是服务器响应了 550 错误，顺着这条线索查到是域名反向解析没做好。不会抓包的管理员，永远只能看到问题的表面。不过提醒一句，抓包别在高负载服务器上长时间跑，容易拖慢系统。
?️ 交互式学习技巧：光背命令不如动手翻车
用 Linux DO 的在线终端练手，翻车了也不怕
要说练 Linux 命令的好地方，Linux DO 的交互式终端必须提一嘴。它内置了各种故障场景，比如模拟网络不通、端口被占用，让你一步步排查。我当初就在上面练 traceroute，故意设置几个节点丢包，反复试不同参数，直到闭着眼都能看懂结果。
要说练 Linux 命令的好地方，Linux DO 的交互式终端必须提一嘴。它内置了各种故障场景，比如模拟网络不通、端口被占用，让你一步步排查。我当初就在上面练 traceroute，故意设置几个节点丢包，反复试不同参数，直到闭着眼都能看懂结果。
最妙的是它有即时反馈，输错命令会提示哪里不对，比对着手册死记硬背强太多。记得有次我在上面模拟用 nmap 扫描局域网，误打误撞用了 - sV 参数，居然扫出了隔壁虚拟机的操作系统版本 —— 这种实战感，看书是学不来的。
搭个本地故障实验室，把命令玩到脱胎换骨
光在线练不够，自己搭环境才是王道。找台旧电脑装个 CentOS，再用 VirtualBox 开几个虚拟机当客户端，随便造故障：拔根网线模拟断网，改改 iptables 规则拦截端口，甚至用 tc 命令限速玩。
光在线练不够，自己搭环境才是王道。找台旧电脑装个 CentOS，再用 VirtualBox 开几个虚拟机当客户端，随便造故障：拔根网线模拟断网，改改 iptables 规则拦截端口，甚至用 tc 命令限速玩。
我就这么干过，故意在虚拟机里用 netstat -anp 找到 sshd 的端口，然后用 iptables 封掉，再用 telnet 测试连接失败，最后一步步排查解除限制。这种从破坏到修复的过程，比背十遍命令都记得牢。你还别说，有次公司真遇到类似情况，我五分钟就搞定了，全靠当年这么折腾。
加入命令别名战队，效率直接翻倍
玩熟了就该琢磨偷懒技巧了。把常用的长命令设成别名，比如 alias ping4='ping -c 4'，alias trc='traceroute'，敲起来飞快。我还见过更狠的，把 netstat、ss、lsof 组合成一个查端口的脚本，输入端口号直接出结果。
玩熟了就该琢磨偷懒技巧了。把常用的长命令设成别名，比如 alias ping4='ping -c 4'，alias trc='traceroute'，敲起来飞快。我还见过更狠的，把 netstat、ss、lsof 组合成一个查端口的脚本，输入端口号直接出结果。
不过别太依赖别名，基础命令的完整写法必须烂熟于心 —— 万一在别人的服务器上操作，没有你的别名配置，总不能当场懵圈吧？技巧是服务效率的，不是让你变成 “别名依赖症” 患者。
? 这些资源要是早知道，我能少熬三年夜
Linux DO 的命令手册，比教科书靠谱十倍
他们家的手册不是干巴巴列参数，而是每个命令都配实际场景。比如讲 tcpdump，会告诉你 “抓 HTTP 请求头用什么参数”“排查 DNS 污染怎么过滤包”，全是干活能用得上的。我现在遇到生僻参数，第一反应就是去 Linux DO 搜，比 man 命令看得明白。
他们家的手册不是干巴巴列参数，而是每个命令都配实际场景。比如讲 tcpdump，会告诉你 “抓 HTTP 请求头用什么参数”“排查 DNS 污染怎么过滤包”，全是干活能用得上的。我现在遇到生僻参数，第一反应就是去 Linux DO 搜，比 man 命令看得明白。
交互式教程平台，边玩边学才不枯燥
像 Katacoda、LearnShell 这些平台，都是交互式学习的好地方。特别是 Katacoda，有现成的 Linux 环境，让你一步步完成 “诊断网络延迟”“排查端口冲突” 这样的任务，跟玩游戏闯关似的。我当年用它练 nmap，三天就从只会扫端口，到能写出带脚本的扫描命令。
像 Katacoda、LearnShell 这些平台，都是交互式学习的好地方。特别是 Katacoda，有现成的 Linux 环境，让你一步步完成 “诊断网络延迟”“排查端口冲突” 这样的任务，跟玩游戏闯关似的。我当年用它练 nmap，三天就从只会扫端口，到能写出带脚本的扫描命令。
服务器故障案例库，别人踩过的坑别再跳
GitHub 上有个叫 “linux-network-troubleshooting” 的仓库，收集了上百个真实故障案例，从简单的 ping 不通到复杂的 VLAN 配置错误，每个都附排查步骤。我没事就翻着看，相当于提前吃别人的经验亏 —— 这招太值了，能少走超多弯路。
GitHub 上有个叫 “linux-network-troubleshooting” 的仓库，收集了上百个真实故障案例，从简单的 ping 不通到复杂的 VLAN 配置错误，每个都附排查步骤。我没事就翻着看，相当于提前吃别人的经验亏 —— 这招太值了，能少走超多弯路。
? 最后说句掏心窝子的话
Linux 网络诊断命令这东西，不怕你不会，就怕你不练。我见过太多人对着手册背了一星期，真遇到问题还是手忙脚乱。记住，命令是死的，场景是活的，只有在实战里摔过跤，才能把这些命令变成你的本能反应。
Linux 网络诊断命令这东西，不怕你不会，就怕你不练。我见过太多人对着手册背了一星期，真遇到问题还是手忙脚乱。记住，命令是死的，场景是活的，只有在实战里摔过跤，才能把这些命令变成你的本能反应。
现在我排查网络问题，基本能做到 “一看现象就知道用什么命令，一输命令就知道问题在哪”，靠的就是当年疯狂练手、疯狂踩坑。你也别想着一口吃成胖子，每天吃透一个命令，每周模拟一个故障，半年后再回头看，保证自己都惊讶于进步速度。
【该文章由dudu123.com嘟嘟 ai 导航整理，嘟嘟 AI 导航汇集全网优质网址资源和最新优质 AI 工具】
