504错误是nginx因超时主动断开后端连接，并非崩溃或网络中断；需先直连后端测耗时、查access log的$upstream_response_time字段定位慢源，再按协议类型（http用proxy_read_timeout，php-fpm用fastcgi_read_timeout）及连接/发送阶段（proxy_connect_timeout、proxy_send_timeout）精准配置超时，同时兼顾客户端接收能力（client_header_timeout等）。
504 错误本质是 Nginx 等不到后端响应而主动断开，并非 Nginx 崩溃，也不是网络完全不通。关键要区分：是后端真慢，还是 Nginx 等得太短？不能一概拉长所有超时值，得按请求路径、协议类型和处理阶段精准配置。
先验证后端真实响应耗时
绕过 Nginx 直连后端，才能判断问题根源：
- 在 Nginx 服务器上执行：
curl -w "\n%{time_total}\n" -o /dev/null -s http://127.0.0.1:8080/your-api，看实际耗时是否超过你预设的 timeout - 查 Nginx access log 中的
$upstream_response_time字段，例如"0.002 128.456 0.001"表示某次重试花了 128 秒，说明后端确实慢 - 若直连也慢，需检查后端日志、数据库慢查询、外部依赖调用（如第三方 API）或 CPU/内存瓶颈
按协议类型设置对应超时参数
Nginx 对不同后端协议使用不同超时指令，proxy_* 对 PHP-FPM 完全无效：
- 对接 Java/Node.js 等 HTTP 后端：在
location块中设proxy_read_timeout 180（单位秒），别写在http或server块——作用域不生效 - 对接 PHP-FPM：必须用
fastcgi_read_timeout 180，且同步改 PHP 配置：
–/etc/php/*/fpm/php.ini中max_execution_time = 180
–/etc/php/*/fpm/pool.d/www.conf中request_terminate_timeout = 180 - 禁止设为 0：Nginx 会无限等待，耗尽 worker_connections，引发雪崩
补全连接与发送阶段的超时控制
proxy_read_timeout 只管“等响应”，但前面两个环节卡住也会导致 504，且不会触发它：
-
proxy_connect_timeout 10：Nginx 连后端 TCP 的时限，跨机房或 Java 冷启动建议设为 30–180 -
proxy_send_timeout 300：Nginx 向后端发完全部请求体的时限，大文件上传或弱网环境需调高 - 这三个参数无继承关系，必须在同一 location 块中显式写出，否则沿用默认 60 秒
匹配客户端侧接收能力
有时 504 是因为 Nginx 自己还没收完请求就断了，不是后端的问题：
-
client_header_timeout 60：收请求头的最大间隔，TLS 握手慢时建议提高 -
client_body_timeout 300：收请求体的总时限，与proxy_send_timeout协调，避免提前中断 -
client_max_body_size 100m：确保大文件上传不被直接拒掉（返回 413）
