拿到状态码先判断责任侧
排查 HTTP 问题的第一步不是翻代码，而是判断这个状态码指向哪一侧：4xx 表示请求方需要调整，5xx 表示服务端出了问题，3xx 说明链路里还有一次跳转没走完。判断完责任侧，再按固定路径收集证据，避免在无关的层级上消耗时间。状态码本身已经给出了很强的前提，忽略它直接猜原因是最常见的低效做法。
排障索引
| 状态码 | 大概率责任 | 先看什么 |
|---|---|---|
| 400 与 422 | 请求方 | 请求体字段与服务端校验日志 |
| 401 与 403 | 凭证与策略 | WWW-Authenticate、权限模型、WAF 日志 |
| 404 与 405 | 路由与方法 | 网关路由表、框架路由注册、Allow 头 |
| 408 与 429 | 链路与限流 | 超时配置、限流阈值与 Retry-After |
| 413 与 414 与 431 | 大小限制 | 网关与框架各自的阈值配置 |
| 500 | 应用 | 应用日志与堆栈 |
| 502 与 503 与 504 | 网关与上游 | 网关错误日志、上游健康状态与耗时 |
三步定位法（以偶发 502 为例）
三步定位法（以偶发 502 为例）
# 1 用户侧证据：记录时间戳与请求标识
curl -sv -o /dev/null -w '%{time_total} %{http_code}\n' https://api.example.com/x
# 2 网关侧证据：按时间窗过滤错误日志
grep -i 'upstream' /var/log/nginx/error.log | tail -20
# 3 上游侧证据：确认进程与端口，再看应用日志
ss -lntp | grep 8080
journalctl -u app --since '10 min ago' | tail -50排障时要记下什么
| 证据 | 作用 | 怎么取 |
|---|---|---|
| 精确时间戳 | 把各方日志对齐 | curl 输出加上时间，或记录请求 ID |
| 请求标识 | 串联网关与上游日志 | 响应头里的 request id 类字段 |
| 网关访问与错误日志 | 判断请求到了哪一层 | 按状态码与时间窗过滤 |
| 上游健康与耗时 | 区分超时与崩溃 | 网关里上游响应时间字段 |
| 变更记录 | 判断是否由发布引起 | 对照发布时间与故障起始时间 |
典型使用场景
- 用户报错时快速定位责任侧，避免上下游互相推诿
- 偶发 502 排查：把用户侧、网关侧与上游侧证据按时间对齐
- 发布后验证：确认错误码分布是否出现新的异常取值
- 限流问题定位：区分是调用方超频还是服务端阈值设置过低
- 排查 404 激增：判断是路由变更还是域名解析到了旧服务
提高效率的关键是固定证据收集顺序：先拿到能复现的请求，再按时间窗去各层日志里搜同一时间点，最后才去读代码。顺序反了往往会在无关代码上耗掉大量时间。