主题
🔧 网络排故方法论
网络不通的时候，90% 的人瞎猜，10% 的人按顺序排——你是那 10%
分层排故法（核心方法论）
从最底层开始，一层一层往上查：
第 1 层：物理层 网线插了没？灯亮了没？
第 2 层：数据链路层 ARP 能解析吗？MAC 地址对的吗？
第 3 层：网络层 IP 配对了没？ping 能通吗？
第 4 层：传输层 端口开了没？telnet 能连吗？
第 7 层：应用层 curl 能拿到数据吗？铁律：下面不通，上面一定不通。从下往上查。
排故工具全景
| 工具 | 查哪层 | 一句话 |
|---|---|---|
| 看网口灯 | 物理层 | 灯不亮 = 线/口/设备有问题 |
ip link | 链路层 | 网卡起来了没 |
arp -a | 链路层 | IP→MAC 能解析吗 |
ping | 网络层 | 到目标 IP 通了没 |
traceroute | 网络层 | 走到哪个节点断了 |
telnet | 传输层 | 端口能不能连 |
curl | 应用层 | HTTP 能不能通 |
tcpdump | 全部 | 抓包看真相 |
工具用法详解
ping — 网络层可达性
bash
# 基本用法
ping 124.222.126.171
# 指定次数
ping -c 4 124.222.126.171
# 指定包大小（测 MTU）
ping -s 1472 124.222.126.171 # 1500 MTU 下最大 ping 包
# 泛洪模式（测丢包和延迟）
sudo ping -f -c 100 124.222.126.171
# ping 结果怎么看
# rtt min/avg/max/mdev = 延迟抖动
# packet loss = 丢包率（>1% 就是问题）traceroute — 路径追踪
bash
# 看数据包经过了哪些节点
traceroute 124.222.126.171
# 输出示例
# 1 192.168.1.1 1ms ← 网关
# 2 10.0.0.1 3ms ← ISP 第一跳
# 3 61.148.3.1 5ms
# 4 * * * ← 这跳不响应（防火墙）
# 5 124.222.126.171 10ms ← 目标
# 哪一跳开始丢包 → 问题就在那
# 全是 * → 防火墙禁 ICMP 或 TCPss/netstat — 看端口和连接
bash
# 所有监听端口
ss -tlnp
# 所有已建立的连接
ss -tnp state established
# 看某个端口谁在监听
ss -tlnp | grep 8898
# 统计各种状态的连接数
ss -stelnet — 测端口通不通
bash
# 测 HTTP
telnet 124.222.126.171 80
# 测 SSH
telnet 124.222.126.171 22
# 通 → 显示 Connected / Escape character
# 不通 → Connection refused（端口没开/服务没启）
# Connection timed out（被防火墙拦了）tcpdump — 终极武器
bash
# 抓特定端口的包
sudo tcpdump -i eth0 port 8898 -n
# 抓特定主机的包
sudo tcpdump -i eth0 host 124.222.126.171 -n
# 抓 HTTP 请求
sudo tcpdump -i eth0 -A -s 0 'port 80' -n
# 抓并写文件（给 Wireshark 分析）
sudo tcpdump -i eth0 -w capture.pcap
# 抓包常用参数
# -i eth0 指定网卡
# -n 不解析域名（快）
# -A ASCII 模式（看 HTTP 明文）
# -s 0 抓完整包（不截断）
# -c 100 抓 100 个包就停经典排故流程
场景1：服务器连不上
bash
# Step 1: 物理层 — 网口灯亮不亮？
# Step 2: 链路层 — 网卡状态
ip link show eth0
# state UP → 网卡正常
# Step 3: 网络层 — IP 对不对
ip addr show eth0
# inet 124.222.126.171 → IP 对
# Step 4: 网络层 — 能不能出网关
ping -c 4 124.222.126.1
# Step 5: 网络层 — 能不能到公网
ping -c 4 8.8.8.8
# Step 6: 应用层 — DNS 能不能解析
nslookup baidu.com
# 第几步断了 → 问题在那一层场景2：网站 502
bash
# Step 1: nginx 还在跑吗
systemctl status nginx
ss -tlnp | grep -E '80|443' # 端口在吗
# Step 2: 上游服务在吗
systemctl status chat_server
ss -tlnp | grep 8898 # 应用端口在吗
# Step 3: nginx 能连到上游吗
telnet 127.0.0.1 8898
# Step 4: 直接绕过 nginx 调上游
curl http://127.0.0.1:8898/
# Step 5: 看 nginx error log
tail -50 /var/log/nginx/error.log
# 哪步断了就修哪步场景3：间歇性超时
bash
# 长期 ping 观察
ping -c 1000 目标IP > ping.log &
# 过一小时看丢包率
# 或 mtr（ping + traceroute 合体，实时看）
mtr 目标IP
# 同步抓包看超时时的网络状态
sudo tcpdump -i eth0 -w timeout.pcap host 目标IP排故检查清单
□ 网线插了没？灯亮了没？
□ 网卡是 UP 状态？（ip link）
□ IP 地址配得对吗？（ip addr）
□ 能 ping 通网关？（ping 网关IP）
□ 能 ping 通目标？（ping 目标IP）
□ DNS 能解析？（nslookup 域名）
□ 端口是监听状态？（ss -tlnp）
□ telnet 端口能连？（telnet IP PORT）
□ 防火墙挡了吗？（iptables -L / ufw status）
□ nginx/服务日志有报错？（tail /var/log/）🎯 本章要点
- 排故铁律：从下往上查，下层不通上层一定不通
- 工具速记：ping（通不通）、telnet（端口开没开）、curl（应用对不对）、tcpdump（抓包看真相）
- 502 → 先查上游服务在不在 + nginx 能不能连到上游
- 间歇性 → mtr 长期监控 + tcpdump 抓包
- 每次排完故记一下根因——下次同样现象直接秒定位
加载练习题中...