结合我们之前所有的讨论（从基础的 IP/DNS 概念，到 ping/telnet/mtr 的实战，再到应用层排查和故障模拟），我把网络排查的完整步骤重新梳理成一套系统化、由底向上、逻辑闭环的 SOP（标准作业程序）。
这套流程分为 七个阶段，你可以把它当成一份"网络故障排查清单"，遇到问题直接按顺序往下走。
🗺️ 网络排查完整步骤 SOP
阶段 0：明确现象与范围（不要上来就敲命令）
在动手之前，先问清楚：
-
谁的问题？ 是单个客户端、所有客户端，还是服务端本身？
-
什么现象？ 是连不上（超时/拒绝）、速度慢（延迟/丢包），还是偶发断连？
-
必现还是偶发？ 必现通常配置错，偶发通常网络抖动或资源耗尽。
-
范围多大？ 只有特定接口/域名有问题，还是全网都挂了？
阶段 1：检查本机基础配置（确认"我在哪"）
目标：排除本地网卡、IP、路由、DNS 的配置错误。
-
网卡状态 ：
ip addr/ifconfig（看网卡是否 UP，IP 是否正确）。 -
路由表 ：
ip route/route -n（看默认网关是否存在，default via 192.168.159.2是否正确）。 -
DNS 配置 ：
cat /etc/resolv.conf（看nameserver是否可用）。 -
DNS 解析测试 ：
nslookup www.baidu.com或dig www.baidu.com（看能否把域名解析成 IP。如果这一步就卡住，后面的都别测了，先修 DNS）。 -
本机资源 ：
top/free -h（确认不是本机 CPU 打满或内存溢出导致发不出包）。
阶段 2：网络层连通性排查（确认"路通不通"）
目标：测试 IP 层连通性，定位丢包和延迟发生在哪一段。
-
基础连通性 ：
ping -c 10 目标IP。- 注意 ：
ping不通不代表网络断了，大厂（如百度、Google）经常屏蔽 ICMP。只要telnet能通，网络就是通的。
- 注意 ：
-
逐跳路由追踪 ：
mtr -rwzc 100 目标IP。-
核心法则 ：只看最后一跳！ 中间节点显示 100% 丢包是正常的（路由器为了防攻击不回复 ICMP）。
-
判断：如果最后一跳丢包率 > 0%，说明链路真实丢包；如果最后一跳延迟高但丢包为 0，说明链路拥塞。
-
-
带宽与抖动测试 ：
iperf3 -c 服务端IP -t 30（测试真实带宽是否跑满，UDP 测试看抖动,一般服务端不会开放这个服务）。
阶段 3：传输层端口排查（确认"门开没开"）
目标：绕过 ICMP 限制，直接测试业务端口的 TCP/UDP 连通性。
-
TCP 端口测试 ：
telnet 目标IP 端口或nc -vz 目标IP 端口或tcping 目标IP 端口。-
Connected：端口开放，网络通。 -
Connection refused：网络通，但服务没启动。 -
Connection timed out：防火墙 DROP 了包，或者 IP 不可达。
-
-
TCP 连接细节 ：
ss -ti（看 RTT、重传次数retrans、拥塞窗口cwnd）。如果重传率很高，说明链路有丢包。 -
抓包确认 ：
tcpdump -i any host 目标IP and port 端口 -w /tmp/net.pcap。- Wireshark 过滤
tcp.analysis.retransmission（重传）、tcp.analysis.duplicate_ack（重复 ACK）。
- Wireshark 过滤
阶段 4：应用层排查（确认"能不能办成事"）
目标：网络和端口都通了，但业务报错或慢，问题在应用层。
-
协议层耗时拆解 ：
curl -o /dev/null -s -w 'dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total}\n' https://域名/接口。-
time_connect高：TCP 握手慢（网络/防火墙）。 -
time_appconnect高：TLS 握手慢（证书问题）。 -
ttfb高：服务端处理慢（应用层核心瓶颈）。
-
-
HTTP 状态码：
-
4xx：客户端请求错误（参数、鉴权、被限流 429）。 -
5xx：服务端错误（500 代码异常，502/504 网关超时或后端挂掉）。
-
-
服务端日志 ：
tail -f /var/log/应用/error.log（找异常堆栈、慢查询、连接池耗尽警告）。 -
服务端资源 ：
top（CPU）、free（内存）、iostat（磁盘 I/O）、jstack（Java 线程死锁）。 -
微服务链路追踪：SkyWalking / Jaeger（通过 Trace ID 定位是哪个下游服务拖慢了整体）。
阶段 5：网关与代理层排查（如果是微服务/公网入口）
目标：排查 Nginx、API 网关、WAF 的拦截或超时。
-
Nginx 日志 ：查
upstream timed out、connection refused。 -
WAF 拦截：返回 403/406，检查是否触发了 SQL 注入/XSS 规则。
-
负载均衡：后端有 3 台机器，是否有一台挂了，Nginx 还在往那台转发？（检查健康检查）。
-
请求体限制 ：Nginx
client_max_body_size默认 1M，上传大文件会报 413。
阶段 6：模拟与故障注入（测试阶段，验证容错）
目标：主动制造故障，验证客户端/服务端的容错机制。
-
客户端模拟断网/弱网：
-
Windows：
clumsy（Drop 100% 丢包、Lag 延迟）。 -
macOS：
Network Link Conditioner（100% Loss）。 -
Linux：
iptables -A OUTPUT -p tcp --dport 端口 -j DROP或tc qdisc add dev eth0 root netem delay 1000ms loss 30%。
-
-
服务端模拟异常：
-
零代码：
Mockoon（模拟 500、延迟）、Charles（断点拦截不放行）。 -
代理层：
Toxiproxy（注入延迟、切断连接）。 -
代码级：Python Flask / Node.js 写 Mock 接口（
sleep(10)、直接socket.close()）。 -
混沌工程：
ChaosBlade（针对 K8s Pod 注入网络丢包、进程崩溃）。
-
-
观察客户端表现：超时设置是否合理？重试机制有没有指数退避？UI 是否有友好提示？数据是否本地缓存并补发？
阶段 7：终极手段（抓包与复盘）
目标：当所有工具都测不出问题时，抓取原始数据包，看底层到底发生了什么。
-
双向抓包 ：在客户端和服务端同时
tcpdump。 -
Wireshark 分析：Follow TCP Stream，看应用层载荷是否被截断、乱码，或者是否有 RST 包。
-
复盘归档：记录故障时间线、排查路径、根因和解决方案，形成团队知识库。
💡 一句话总结排查心法：
先查自己（配置），再查路（ping/mtr），后查门（telnet/端口），最后查人（应用层日志/资源）。
遇到 ping 不通别慌张，telnet 一试便知；遇到 mtr 中间 100% 丢包别害怕，只看最后一跳；遇到网络全通但业务报错，直接去服务端 tail -f 看日志。