网络排障方法论：ping/traceroute/mtr
网络故障排查不是乱试命令——是有系统方法的。从 OSI 物理层往上逐层排查，用 ping/traceroute/mtr 三板斧定位问题所在层级，再深入分析。
排障基本原则
1. 先分层，后深挖
按 OSI 从底层（物理层）往上排查，确认哪层出了问题
2. 先局部，后全局
先 ping 网关（同网段） → 再 ping 公网 IP → 再 ping 域名
3. 先简单，后复杂
先看接口状态 → 再看路由表 → 再抓包
4. 对比法
"之前能用，现在不能" → 找出变化点（什么时间？改了什么？）
"这台能用，那台不能" → 找出两台的配置差异
5. 记录过程
每一步的命令和输出都要记录，方便回溯和向他人求助
ping：连通性验证
# 基本用法
ping 8.8.8.8 # 默认无限发送（Linux）
ping -c 4 8.8.8.8 # 发 4 个包后停止
ping -n 4 8.8.8.8 # Windows
# 常用选项
ping -c 10 -i 0.2 8.8.8.8 # 发 10 个包，间隔 0.2 秒（快速测试）
ping -M do -s 1472 8.8.8.8 # 测试 MTU（DF bit 不分片，1472+28=1500）
ping -t 3 8.8.8.8 # 设置 TTL=3（只经过 3 跳）
# 解读输出：
# 64 bytes from 8.8.8.8: icmp_seq=1 ttl=118 time=3.14 ms
# ↑大小 ↑来源 ↑序号 ↑剩余TTL ↑往返延迟
# ping 统计：
# 5 packets transmitted, 5 received, 0% packet loss, time 4005ms
# rtt min/avg/max/mdev = 2.8/3.1/3.5/0.2 ms
# 重要指标：
# packet loss > 0% → 丢包（链路质量问题）
# time 波动大 → 网络抖动（jitter）
# time 突然变大 → 路由变更或拥塞
ping 的局限性
ping 不通 ≠ 服务不通：
很多服务器/防火墙会丢弃 ICMP 但 TCP 服务正常
例：ping 10.0.50.10 不通，但 curl http://10.0.50.10 能用
ping 通 ≠ 服务正常：
ICMP 通了，但 TCP 8080 被防火墙拦截
→ 用 nc/telnet 测试具体端口：
nc -zv 10.0.50.10 8080
curl -m 5 http://10.0.50.10:8080/health
traceroute：路径追踪
# Linux
traceroute 8.8.8.8
traceroute -n 8.8.8.8 # 不做 DNS 反查，更快
traceroute -p 80 8.8.8.8 # 用 TCP 80（穿防火墙）
traceroute -T -p 443 8.8.8.8 # TCP 443（穿防火墙）
# Windows
tracert 8.8.8.8
# 解读输出：
# 1 192.168.1.1 1.2 ms 1.0 ms 1.1 ms ← 网关（1跳）
# 2 10.0.0.1 2.3 ms 2.1 ms 2.4 ms
# 3 * * * ← 该跳不响应（防火墙丢弃 ICMP TTL=0）
# 4 172.16.0.1 15.2 ms 14.9 ms 15.1 ms
# 5 8.8.8.8 20.3 ms 20.1 ms 20.4 ms
# * * * 的含义：
# 不一定是故障！可能是中间路由器配置不响应 ICMP Time Exceeded
# 如果后续跳数恢复正常 → 中间节点只是不响应，流量正常转发
# 如果一直 * * * 到结束 → 可能是路由黑洞或目标不可达
mtr：ping + traceroute 的结合体
mtr（My TraceRoute）持续发包，同时显示每跳的延迟和丢包率——是排查间歇性网络问题的最佳工具。
# 安装
apt install mtr-tiny
# 基本用法（交互模式）
mtr 8.8.8.8
# 运行 100 个包后输出报告（适合给运维团队看）
mtr --report -c 100 8.8.8.8
# 输出示例：
# Start: 2024-03-22T10:00:00+0800
# HOST: myserver Loss% Snt Last Avg Best Wrst StDev
# 1.|-- 192.168.1.1 0.0% 100 1.2 1.1 0.9 2.1 0.2
# 2.|-- 10.0.0.1 0.0% 100 2.3 2.2 2.0 3.1 0.2
# 3.|-- 203.0.113.1 0.0% 100 15.2 15.1 14.8 16.0 0.3
# 4.|-- 8.8.8.8 0.0% 100 20.3 20.1 19.8 21.5 0.4
# 关键列：
# Loss% = 丢包率（某跳 >0% 但后续跳正常 = 该路由器限速ICMP，非故障）
# Avg = 平均延迟
# StDev = 延迟标准差（越大 = 抖动越大）
系统性排障 SOP
故障：无法访问 https://api.example.com
步骤 1：检查物理/链路层
────────────────────────
ip link show
# eth0: state UP → 物理连接正常
# eth0: state DOWN → 检查网线/网卡/接口
步骤 2：检查本机 IP 配置
────────────────────────
ip addr show
# 有 IP 地址？IP 在正确的网段？
步骤 3：检查网关可达性
────────────────────────
GATEWAY=$(ip route show default | awk '{print $3}')
ping -c 3 $GATEWAY
# 通 → 二层/三层正常
# 不通 → 检查 ARP：ip neigh show
步骤 4：检查公网 IP 可达性
────────────────────────────
ping -c 3 8.8.8.8
# 通 → 路由和 NAT 正常
# 不通但网关通 → 路由问题或上游防火墙
步骤 5：检查 DNS 解析
─────────────────────
dig api.example.com
nslookup api.example.com
# 有解析结果？IP 正确？
步骤 6：检查端口连通性
─────────────────────
nc -zv api.example.com 443
curl -v --connect-timeout 5 https://api.example.com/health
# 连接超时 → 端口被拦截
# 连接拒绝 → 服务未启动
# TLS 错误 → 证书问题
步骤 7：路径追踪定位丢包节点
──────────────────────────────
mtr --report -c 20 api.example.com
# 找到哪一跳开始丢包
网络连接状态速查
# 查看当前连接（类似 netstat）
ss -tnp
# 查看监听端口
ss -tlnp
# 查看指定端口连接数
ss -tn | grep ':443' | wc -l
# 查看 TIME_WAIT 连接数（高说明短连接太多）
ss -tn state time-wait | wc -l
# 查看连接到某个 IP 的所有连接
ss -tn dst 8.8.8.8
# 实时监控网络流量
nethogs eth0 # 按进程显示流量
iftop -i eth0 # 按连接显示流量
CCNA 对应考点
考纲位置：Domain 6.1 — Utilize Cisco IOS troubleshooting tools
高频考题： - traceroute 的 TTL 递增原理 - * * * 的含义（不一定是故障） - ping 成功但 traceroute 失败（或反之）的原因 - 从哪一跳开始丢包/延迟增大，判断故障点位置
下一节：tcpdump 抓包分析——ping/traceroute 定位了问题在哪一跳，tcpdump 帮你看清楚数据包的内容——真正"听"到网络在说什么。