关键在于使Nginx的fastcgi_read_timeout、fastcgi_send_timeout和fastcgi_connect_timeout与PHP-FPM的request_terminate_timeout严格对齐：前者控制Nginx端各阶段等待上限，后者决定脚本实际终止时机，必须request_terminate_timeout≥fastcgi_read_timeout，否则Nginx断连而PHP进程仍在运行，导致资源泄漏。
要防止 PHP 类任务（如报表生成、大文件导出、批量处理）在 Nginx + FastCGI 链路中被意外中断，关键不是盲目拉长超时，而是让 FastCGI 三阶段超时参数与 PHP-FPM 实际执行能力严格对齐。Nginx 不会“代理”PHP 执行，它只控制自己这一端的等待行为；若 PHP 层先退出，Nginx 再长的 timeout 也无意义。
明确 fastcgi_read_timeout 和 fastcgi_send_timeout 的分工
这两个参数不是“空闲超时”，而是单次请求全链路的硬性等待上限：
- fastcgi_read_timeout：从 Nginx 发完请求开始计时，等待 PHP-FPM 返回完整响应的最大时长。它是防“卡死”的核心开关——超时即断连、返回 504、释放 worker 进程。
- fastcgi_send_timeout：限制 Nginx 向 PHP-FPM 发送整个请求（含大 POST body、上传文件等）所允许的最长时间。网络抖动或客户端慢速上传时，这里可能先触发断连。
必须成套配置，不能只调其中一个
只改 fastcgi_read_timeout 而忽略其他两个，容易在连接建立或请求发送阶段就失败，根本到不了“读响应”环节：
-
fastcgi_connect_timeout：建连超时，建议设为
5s～10s。太短会误判瞬时故障，太长拖慢错误响应。 -
fastcgi_send_timeout：应 ≥ 客户端上传最大预期耗时（如 200MB 文件上传+网络延迟），常见设为
300s或600s。 -
fastcgi_read_timeout：应 ≥ PHP 脚本最长合理执行时间（如导出接口设
600s），且必须放在location ~ \.php$ { }块内，不能写在 http 级别。
PHP-FPM 层必须同步匹配，否则 Nginx 设置无效
Nginx 断连只是信号，真正终止脚本的是 PHP-FPM：
- 检查
/etc/php/*/fpm/pool.d/www.conf中的 request_terminate_timeout（优先级最高），它必须 ≥ Nginx 的fastcgi_read_timeout，例如设为600。 - 确认
/etc/php/*/fpm/php.ini中的 max_execution_time ≥ 同一数值（至少持平，不建议更小）。 - 修改后执行
sudo systemctl reload php*-fpm，并用ps aux | grep php-fpm或php-fpm -t验证生效。
验证是否真起作用
别只看配置文件，要看运行时实际加载值和日志表现：
- 执行
nginx -T | grep -A 3 "fastcgi.*timeout"，确认输出中对应 location 下的数值是你设置的。 - 观察 Nginx 错误日志（
error.log）：若仍有 504，说明是 Nginx 主动超时；若出现 “upstream prematurely closed” 或 “recv() failed”，大概率是 PHP-FPM 已提前退出，需回头检查 request_terminate_timeout 是否被覆盖或未重载。
