自上而下排查是什么
自上而下（top-down）从业务现象出发反向定位：先看应用报什么错、状态码与耗时分布，再倒推是 DNS、连接、TLS 还是传输问题。它比自下而上省时间，因为错误信息本身就能砍掉大半个搜索空间；代价是要求操作者能读懂应用层输出。适合「能用但慢」「部分请求报错」「切了环境之后才异常」这类故障。
基本信息
| 排查方向 | 应用 → 传输 → 网络 → 链路 |
|---|---|
| 适用 | 域名访问异常、部分功能报错、时快时慢 |
| 优势 | 直接得到业务可用性结论，收敛速度快 |
| 依赖 | 客户端有 curl / dig 等工具，能取到完整错误信息 |
| 注意 | 错误信息只能缩小范围，最终仍需下层证据确认 |
典型使用场景
- 页面能打开但图片和接口加载慢，需要判断卡在 DNS 还是服务端
- 只在部分客户端复现，需要在异常客户端上抓到完整请求链路
- 发布新版之后出现报错，需要确认是应用改动还是依赖变更
- 第三方 API 调用失败，需要区分网络层不可达与应用层拒绝
- 电话报障信息残缺，需要用一条 curl 同时拿到状态码与各阶段耗时
从应用往下剥
从应用往下剥
curl -v --connect-timeout 3 https://<域名>/ 2>&1 | head -40 # 应用层：错误与握手过程
dig +short <域名> # DNS：解析结果是否符合预期
nc -zv -w3 <IP> 443 || echo 端口层不通 # 传输层：TCP 能否完成握手
ping -c3 <IP> # 网络层：IP 是否可达
curl -o /dev/null -s -w '%{http_code} %{time_total}\n' <URL> # 只取状态码与总耗时错误信息判读
| 错误信息 | 含义 | 下一步 |
|---|---|---|
| Connection refused | 目标端口没有监听或被主动拒绝 | 查服务进程、监听地址与防火墙拒绝规则 |
| Connection timed out | 握手包有去无回，多被中间设备丢弃 | 抓包看 SYN 是否发出、有无应答 |
| Connection reset by peer | 对端或中间设备主动发 RST | 查对端连接数上限、WAF 与负载均衡会话 |
| Could not resolve host | DNS 解析失败 | 查 resolv.conf、DNS 服务器与域名记录 |
| SSL certificate problem | 证书校验失败 | 查证书有效期、链完整性与系统时间 |
| Empty reply from server | 连接建立但应用未返回数据 | 查后端进程、超时配置与访问日志 |
先固定证据再动手：把 curl -v 的完整输出、报错时间点与客户端来源保存下来。自上而下的价值在于「用现象描述问题」，如果中途跳去改网络设备，这一步的收获就丢失了。