当前位置:首页>Linux>Linux 基础实战课 ⑨网络不通了?这几个命令能帮你找到原因

Linux 基础实战课 ⑨网络不通了?这几个命令能帮你找到原因

  • 2026-09-24 19:27:41
Linux 基础实战课 ⑨网络不通了?这几个命令能帮你找到原因

Linux 基础实战课 ⑨

网络不通了?这几个命令能帮你找到原因

Linux基础  实战课 

Linux 基础实战课 · 第 9 篇

————————————————

📌 收藏这篇,下次遇到网络问题再也不慌

同事遇到这个问题来找我:新部署的服务器,Nginx 装好了、service 跑着、防火墙也开了——但外面就是访问不到。

「你有没有用 netstat 确认端口在监听?」——他愣了一下。没用过。

「你有没有 curl 测一下本地能不能通?」——也没。

最后查了十分钟:监听地址写的是 127.0.0.1,只对本机开放,外部当然进不来。改成 0.0.0.0,立刻好了。

如果早会这几个命令,5 秒就能定位,不用折腾半小时。

这篇把排查网络问题的核心命令一次性讲完。

————————————————

一、ping:网络通不通,先问它

最简单但最基础。ping 用来测试目标主机是否可达,以及网络延迟。

ping baidu.com

测试到百度的网络连通性(Ctrl+C 停止)

ping -c 4 baidu.com

只发 4 个包就停(Linux 默认不停)

ping -i 0.2 baidu.com

每 0.2 秒发一个包(默认 1 秒)

ping 192.168.1.1

测试局域网内的机器是否在线

看输出里这两个指标:

● time=xxx ms ——延迟,正常局域网 < 1ms,公网 < 50ms

● packet loss —— 丢包率,超过 1% 就要注意了

⚠️ ping 不通不等于服务不通。有些服务器会屏蔽 ICMP 包(即 ping 的协议),ping 不通但 HTTP/SSH 可能完全正常。所以 ping 只是第一步,不是定论。

二、curl:最好用的 HTTP 调试工具

curl 能模拟 HTTP 请求,是排查 Web 服务最直接的工具。比用浏览器开 F12 快得多。

curl http://localhost

测试本机 Web 服务是否响应

curl -I http://example.com

只看响应头(-I = HEAD 请求),看状态码

curl -v http://example.com

详细模式:看完整请求和响应过程(排查 SSL/重定向)

curl -o /dev/null -s -w '%{http_code}' http://example.com

只输出状态码,自动化脚本里常用

curl -X POST -d 'key=val' http://api.example.com/test

发 POST 请求

💡 排查 Nginx 502 的时候,我第一步就是 curl -v http://127.0.0.1 —— 看本机 Nginx 能不能响应,再判断是网络问题还是服务本身的问题。

curl 测接口也常用,比浏览器直观:

curl -H 'Authorization: Bearer token' http://api/user

带请求头

curl -k https://自签名证书的地址

忽略 SSL 证书验证(测试用)

三、ss / netstat:端口谁在监听?

服务起了但访问不到——十有八九是端口没在监听,或者监听地址不对。这时候用 ss 或 netstat 确认。

ss 是新版系统推荐用的(更快),netstat 是老命令:

ss -tlnp

查看所有 TCP 监听端口 + 对应进程

ss -tlnp | grep 80

确认 80 端口有没有在监听

ss -s

网络连接统计摘要(总连接数、TCP状态分布)

ss -tlnp 的输出重点看两列:

● Local Address —— 监听地址。127.0.0.1:80 只对本机开放,0.0.0.0:80 对所有网卡开放

● Process —— 哪个进程在监听(需要 sudo 才能看到)

⚠️ 这是最常见的坑:Nginx / MySQL 配置的 bind-address 是 127.0.0.1,外部永远连不上。用 ss -tlnp 一眼看穿。

老系统 ss 没有的话用 netstat:

netstat -tlnp

同 ss -tlnp,看 TCP 监听

netstat -anp | grep :3306

查 3306 端口(MySQL)的连接状态

四、traceroute:网络到底卡在哪一跳?

ping 告诉你通不通,traceroute 告诉你卡在哪一段。排查跨机房、云服务器访问慢的问题时,traceroute 是神器。

traceroute baidu.com

追踪到百度的路由路径(可能需要 apt install traceroute)

tracepath baidu.com

类似,大部分系统自带,不用额外安装

traceroute -n baidu.com

不解析域名,纯 IP 输出(更快)

输出里每一行是一跳(一台路由器),格式是:

跳数IP地址延迟1延迟2延迟3

如果某一跳突然延迟飙高,或者出现 * * *(超时),就说明网络瓶颈在那里。

💡 云服务器访问外网慢,traceroute 跑一遍经常能发现是出口网关或运营商节点的问题,拿着这份报告去找云服务商客服,效率高多了。

五、六大常见网络故障场景速查

把上面的命令组合起来,覆盖最高频的 6 种场景:

外部访问不到服务

ss -tlnp | grep 80

确认端口是否监听,以及监听地址是 0.0.0.0 还是 127.0.0.1

服务能跑但 502

curl -v http://127.0.0.1

本机直接测 Nginx,排除网络因素,定位是服务本身问题

不知道服务跑在哪个端口

ss -tlnp | grep 进程名

找到进程对应的监听端口

服务器连不上外网

ping -c 4 8.8.8.8

测 Google DNS,如果通了说明网络本身没问题,再排查 DNS

访问某个地址很慢

traceroute 目标地址

找出延迟飙高的那一跳,定位网络瓶颈

API 接口调不通

curl -v http://接口地址

看完整请求响应,状态码、重定向、SSL 一目了然

六、网络命令速查表

命令

用途

ping -c 4 host

测试连通性,发 4 个包

curl http://localhost

测试本机 Web 服务响应

curl -I http://url

只看 HTTP 响应头/状态码

curl -v http://url

查看完整请求响应过程

ss -tlnp

查所有 TCP 监听端口

ss -tlnp | grep 80

确认某端口是否在监听

ss -s

网络连接数统计摘要

netstat -tlnp

同 ss -tlnp(老系统用)

traceroute host

追踪路由路径,找延迟节点

tracepath host

系统自带版 traceroute

curl -o /dev/null -s -w '%{http_code}' url

脚本中只取 HTTP 状态码

ping -i 0.2 -c 20 host

快速发 20 包测网络稳定性

总结

遇到网络问题,按这个顺序走:

① ping —— 能不能到目标机器?

② ss -tlnp —— 端口有没有在监听?监听地址对不对?

③ curl -v —— HTTP 服务本身有没有响应?

④ traceroute —— 网络路径哪里慢了?

这四条命令走一遍,80% 的网络故障都能定位。剩下的复杂情况(iptables 防火墙、云安全组),等下篇再聊。

————————————————

下篇预告:《Linux 基础实战课⑩|Shell 脚本入门:把你每天重复的操作,写成一条命令自动搞定》

⭐ 建议收藏这篇,下次遇到网络问题直接翻速查表

💬 你遇到过最离谱的网络问题是什么?最后怎么查出来的?

评论区说说,说不定你的经历能帮到其他人

👍 点赞⭐ 收藏🔄 转发给踩过坑的朋友

有问题欢迎评论区留言,看到都会回复

最新文章

随机文章