网络层排查的顺序
客户端侧怀疑网络时按顺序推进：ping 看基础连通与往返时间，再确认端口可达，然后用 mtr 看逐跳丢包与抖动，必要时两端抓包看重传、零窗口与握手延迟。目的是先证伪网络问题，再回服务端找原因——反过来做，往往在 Redis 侧空转很久，最后发现问题在链路上。
基本信息
| 基础连通 | ping -c 10 目标主机 |
|---|---|
| 端口可达 | nc -vz 目标 6379 或 telnet |
| 路径质量 | mtr -rw 目标，看逐跳丢包与抖动 |
| 深度分析 | tcpdump 抓包后用 Wireshark 看重传与零窗口 |
| 本机统计 | ss -s 看套接字与重传计数 |
| 客户端延迟 | redis-cli --latency、--latency-history |
典型使用场景
- 排除网络嫌疑：延迟升高时先证明链路干净，避免在服务端空转
- 多源对比：从不同客户端测同一实例，判断是链路问题还是实例问题
- 新链路验收：跨机房或跨云访问前先量往返延迟与丢包
- 偶发超时定位：抓包看重传与零窗口，区分带宽不足和丢包
- 合规前置：确认抓包范围、授权与脱敏方式后再动手
最小示例
最小示例
ping -c 10 redis-host # 基础连通与 RTT
nc -vz redis-host 6379 # 端口是否可达，比 ICMP 更贴近业务
mtr -rw -c 20 redis-host # 逐跳丢包与抖动
sudo tcpdump -i any -nn port 6379 -c 200 -w /tmp/redis.pcap # 限量抓包
ss -s # 本机套接字与重传统计
redis-cli --latency -h redis-host # 客户端视角的延迟对比排查顺序与注意
| 步骤 | 目的 | 注意 |
|---|---|---|
| ping | 确认基础连通与往返时间 | ICMP 常被限速或禁用，不通不代表服务不可达 |
| 端口探测 | 确认目标端口可达 | TCP 可达性比 ICMP 更贴近真实业务 |
| mtr | 看逐跳丢包与抖动 | 多跑几次，单次结果容易误判 |
| 抓包 | 看重传、零窗口与握手延迟 | 会包含数据内容，必须限时限量并脱敏 |
| 客户端延迟测试 | 得到业务视角的延迟 | 要和服务端基线对照才有意义 |
顺序本身就是方法：先网络、后服务端。把 ICMP 与 TCP 两种证据都拿到，结论才站得住。
ICMP 被限速的环境里丢包率会明显失真，判断链路质量要看逐跳数据与 TCP 层统计，而不是只看 ping 的汇总行。
抓包会记录命令与数据内容：必须在授权范围内执行、限制抓包时长与文件大小，并及时脱敏与删除。