关键在于分阶段设限并同步配置三个FastCGI超时参数：fastcgi_connect_timeout、fastcgi_send_timeout、fastcgi_read_timeout，三者须同置于location ~ \.php$块内，且需与PHP层max_execution_time和request_terminate_timeout严格对齐，禁用proxy_*参数，启用keepalive与least_conn调度优化连接复用。
关键不是一味拉长超时，而是分阶段设限、精准控制连接生命周期，防止慢请求长期占住后端连接。
三个 FastCGI 超时必须同步配齐
只调 fastcgi_read_timeout 是常见误区。它只管“等 PHP 返回响应”的阶段，而建连和发请求同样可能卡住：
- fastcgi_connect_timeout：Nginx 连上 PHP-FPM socket 的时间上限，默认 60s；跨机房或冷启动场景建议设为 10–30s
- fastcgi_send_timeout：Nginx 把完整请求（含大 body）发给 PHP-FPM 的耗时上限；上传大文件或网络抖动时需调高，如 300s
- fastcgi_read_timeout：PHP 执行完并把响应返回给 Nginx 的全程上限；99% 的 504 错误由它触发，长任务如导出报表建议设为 600–900s
三者必须同时配置，且都写在 location ~ \.php$ 块内——放在 http 或 upstream 块会报错或失效。
必须与 PHP 层超时严格对齐
Nginx 先断，PHP 后报错，会导致日志里看不到真实异常。务必检查并统一以下三项：
-
/etc/php/*/fpm/php.ini中的 max_execution_time（如设为 600） -
/etc/php/*/fpm/pool.d/www.conf中的 request_terminate_timeout（优先级更高，必须 ≥ Nginx 的fastcgi_read_timeout）
改完后执行 sudo systemctl reload php*-fpm 生效。
禁用 proxy_* 参数，它们对 PHP-FPM 完全无效
只要用了 fastcgi_pass（比如 fastcgi_pass unix:/var/run/php/php8.1-fpm.sock），所有 proxy_* 系列参数（proxy_read_timeout、proxy_connect_timeout 等）都不起作用。FastCGI 和 HTTP 代理是两套协议通道，不能混用。别在 PHP location 块里写 proxy_read_timeout，它会被忽略。
配合连接复用与调度策略降低资源占用
长事务不可避免，但可避免每个请求都新建后端连接：
- 在
upstream块中启用 keepalive（如keepalive 32），值参考后端连接池大小 ×1.2 - 对应 location 中配齐：
proxy_http_version 1.1+proxy_set_header Connection ""，否则后端可能因收到Connection: close而拒绝复用 - 使用 least_conn 调度算法，避免某台 PHP-FPM 被长请求“锁死”
- 在 upstream server 行加 max_conns=150（按后端线程池上限的 80%～90% 设），超限时自动跳过该节点
这样既保障长任务能完成，又不让单个慢请求拖垮整条通道。
