FastCGI场景下Nginx忽略proxy_*参数，仅fastcgi_connect_timeout、fastcgi_send_timeout、fastcgi_read_timeout生效，三者须成套配置且PHP层max_execution_time和request_terminate_timeout需对齐。
FastCGI 场景下没有“代理超时”概念，Nginx 不走 proxy_* 系列参数——只要用了 fastcgi_pass（比如连 PHP-FPM），所有 proxy_connect_timeout、proxy_read_timeout 都会被忽略。真正起作用的是 FastCGI 专用的三个 timeout 参数，它们各自管一段，必须成套配置、协同生效。
fastcgi_read_timeout 是核心断连开关
它决定 Nginx 等待 PHP-FPM 返回完整响应的最大时长。一旦超时，Nginx 主动关闭连接，返回 504，并释放 worker 资源。注意：
- 只允许写在
server或location块里，放在http块会启动失败 - 推荐精准落在
location ~ \.php$内，避免影响静态资源 - 默认值未设置（即用系统级默认），实际常为 60 秒，对报表、导出等长任务明显不足
必须同步配齐另外两个配套参数
单调 fastcgi_read_timeout 无法解决死连接问题，因为卡在前置环节时根本到不了“读响应”阶段：
- fastcgi_connect_timeout：Nginx 连上 PHP-FPM socket 的时限。跨网络或冷启动服务（如刚启的 PHP-FPM）容易超时
- fastcgi_send_timeout：Nginx 把整个请求（含大 body）发给 PHP-FPM 的耗时上限。上传文件时若网络抖动，这里可能先触发断连
三者建议按场景统一设值，例如导出接口可设为：
fastcgi_connect_timeout 300;<br>fastcgi_send_timeout 300;<br>fastcgi_read_timeout 600;
PHP 层超时必须对齐，否则白配
Nginx 断连不是终点，而是信号链的一环。如果 PHP 层自己更早终止，Nginx 可能还来不及触发 timeout 就收到 RST：
- 检查
/etc/php/*/fpm/php.ini中max_execution_time，至少等于fastcgi_read_timeout - 重点确认
/etc/php/*/fpm/pool.d/www.conf中request_terminate_timeout，它优先级最高，必须 ≥ Nginx 所设值 - 改完 PHP 配置后，务必执行
sudo systemctl reload php*-fpm
验证是否生效，别只看配置文件
参数是否真被加载，得看运行时实际值：
- 执行
nginx -T | grep -A 3 "fastcgi.*timeout"，确认输出中目标location块下的数值是你设的 - 检查错误日志中是否还有
upstream prematurely closed connection—— 若仍有，大概率是 PHP 层已先退出 - 用
curl -v模拟长请求，观察是否在预期秒数后断开，而非更早返回 504
