504责任归属需依据日志与实测：先查Nginx error.log中“upstream timed out”后的阶段描述——“while reading response header”指向后端阻塞，“while connecting”指向连接失败，“while sending”指向发送卡顿；再比对access.log的$upstream_response_time字段，结合直连curl测试与超时链梯度验证，精准定位打破时间契约的一方。
504 不是后端挂了，而是 Nginx 和后端之间“等不及了”。排查核心就四件事：看日志阶段、比响应时间、绕开 Nginx 测真实耗时、查超时配置是否生效。
看 error.log 里的超时阶段描述
打开 /var/log/nginx/error.log，搜索 upstream timed out，重点看括号里写的阶段：
- while reading response header：请求已发到后端，但后端迟迟不返回响应头 → 后端卡住（如数据库慢查、线程阻塞、算法服务计算中）
- while connecting to upstream：Nginx 连不上后端 → 后端没启动、端口被占、防火墙拦截、网络不通
- while sending request to upstream：Nginx 往后端发请求时卡住 → 后端连接队列满、accept 溢出、中间网络抖动
查 access.log 中的 upstream_response_time
确保 access.log 启用了 $upstream_response_time 字段。典型日志行类似：
"GET /api/export HTTP/1.1" 504 0.002 138.456 0.001
三个数字代表三次重试的上游响应耗时（单位：秒）：
- 若某次记录远超 proxy_read_timeout（比如配置为 60s，却记了 138s）→ 后端真实响应慢，Nginx 是“如实上报”
- 若所有值都接近 0 或显示 - → 请求根本没发出去，问题在连接建立环节
绕过 Nginx 直连后端测真实延迟
在 Nginx 所在服务器上执行：
curl -w "\n%{time_total}\n" -o /dev/null -s http://后端IP:端口/路径
- 如果直连耗时 > proxy_read_timeout（例如测出 92s，而配置是 60s）→ 瓶颈在后端，该优化代码、SQL 或算法逻辑
- 如果直连秒回（如 0.8s），但走 Nginx 就 504 → 问题在 Nginx 配置、负载均衡策略或健康检查误判
确认超时配置是否真生效
别只改了全局 http 块，要确认具体 location 是否覆盖了 timeout：
- 运行 nginx -T | grep -A5 "location.*\/your-path"，检查你关心的接口路径是否命中了带超时设置的 location
- 注意多层链路：CDN → Nginx → 应用 → DB，每层都有独立超时。谁返回的 504，就优先查那一层的日志和响应头（如 Via、Server、X-Cache）
- 常见翻车点：静态页域名调大了超时，但 API 子域仍走默认配置；或 CDN 先超时，Nginx 根本没记日志，用户却看到 504
