504错误是Nginx因超时主动断开后端连接，并非崩溃；需先直连后端测耗时、查access log的$upstream_response_time定位慢源，再按协议类型（HTTP用proxy_read_timeout，PHP-FPM用fastcgi_read_timeout）及连接/发送/读取阶段精准配置超时参数，并确保作用域正确、避免设为0。
504 错误不是 Nginx 崩溃，而是它主动断开后端连接——根源一定在“等不到响应”这个动作里。排查代理超时配置是否不当，关键不在于盲目拉长 timeout，而在于验证每个环节的耗时是否匹配真实行为，并确认参数是否生效、作用域是否正确。
先绕过 Nginx 直连后端测真实耗时
这是判断问题归属的第一步：如果后端自己就慢，调 Nginx 超时只是掩耳盗铃。
- 在 Nginx 所在服务器上执行：curl -w "\n%{time_total}\n" -o /dev/null -s http://127.0.0.1:8080/your-api，看实际响应时间是否稳定超过你设的 proxy_read_timeout
- 查 Nginx access log 中的 $upstream_response_time 字段，例如日志里出现 "0.002 128.456 0.001"，说明某次重试花了 128 秒，基本可断定后端处理异常
- 若直连也慢，需立刻检查后端日志、数据库慢查询、外部 API 调用延迟或进程资源（CPU/内存）是否打满
确认超时参数是否写对了位置和协议类型
Nginx 的超时指令严格区分协议和作用域，写错地方或用错指令等于没配。
- 对接 HTTP 后端（如 Java、Node.js）：必须在 location 块内设置 proxy_read_timeout，写在 http 或 server 块无效
- 对接 PHP-FPM：必须用 fastcgi_read_timeout，且要同步调整 PHP 配置：
– /etc/php/*/fpm/php.ini 中 max_execution_time ≥ timeout 值
– /etc/php/*/fpm/pool.d/www.conf 中 request_terminate_timeout ≥ timeout 值 - 禁止设为 0：Nginx 会无限等待，快速耗尽 worker_connections，引发级联雪崩
补全连接与发送阶段的超时控制
proxy_read_timeout 只管“等响应”，但前面两个环节卡住也会导致 504，且不会触发它。
- proxy_connect_timeout：Nginx 连后端 TCP 的时限，默认 60 秒。跨机房部署或 Java 应用冷启动建议设为 30–180
- proxy_send_timeout：Nginx 向后端发完全部请求体的时限，默认 60 秒。大文件上传或弱网环境需调高，避免请求未发完就被中断
- 这三个参数无继承关系，必须在同一 location 块中显式写出，否则沿用默认值
检查客户端侧接收能力是否形成瓶颈
有时 504 并非后端慢，而是 Nginx 自己还没收完请求就断了。
- client_header_timeout：收请求头的最大间隔，TLS 握手慢时建议提高到 90–120
- client_body_timeout：收请求体的总时限，需与 proxy_send_timeout 协调，避免 Nginx 收一半就放弃
- client_max_body_size：确保大文件上传不被直接拒掉（返回 413），否则后续流程根本不会走到 upstream
