必须三层超时对齐：Nginx设fastcgi_connect/send/read_timeout三值一致（如300），PHP-FPM设request_terminate_timeout≥该值（如300）且不为0，PHP的max_execution_time仅限CPU时间、不主导超时控制。
处理超长耗时请求，关键不是“单点调大某个超时值”，而是让 Nginx、PHP-FPM 和 PHP 三层的超时机制逻辑一致、彼此包容，避免某一层提前切断导致 502/504 或资源残留。
三段超时必须对齐，不能只改 read_timeout
Nginx 与 PHP-FPM 的通信分三个阶段：建立连接（connect）、发送请求（send）、读取响应（read）。任一阶段超时都会中断，且错误表现不同：
- fastcgi_connect_timeout：Nginx 连不上 PHP-FPM（如进程全忙、端口不通），返回 502；
- fastcgi_send_timeout：Nginx 向 PHP-FPM 发送完整请求体（含大文件流）超时，常见于慢网络上传，返回 504；
- fastcgi_read_timeout：Nginx 等待 PHP-FPM 返回响应超时，也返回 504。
这三项建议设为相同值（如 300），并放在 location ~ \.php$ 块内，确保只影响 PHP 请求：
fastcgi_connect_timeout 300;<br>fastcgi_send_timeout 300;<br>fastcgi_read_timeout 300;
PHP-FPM 层必须兜底，request_terminate_timeout 是关键
PHP-FPM 的 request_terminate_timeout 控制整个请求生命周期上限（含 IO 等待），它一旦触发，会直接 kill worker 进程——这是 502 的根源。它必须 ≥ Nginx 的三 timeout，但也不能设为 0（否则进程永不回收）。
立即学习“PHP免费学习笔记（深入）”；
- 在
/www/server/php/81/etc/php-fpm.d/www.conf（路径按实际 PHP 版本调整）中修改：request_terminate_timeout = 300 - 不要依赖
max_execution_time：它只计 CPU 时间，不包含上传接收、数据库等待等 IO 时间，对耗时任务基本无效； - 设为 0 或注释掉该行，等于放弃进程级保护，高并发下易引发内存泄漏和 worker 耗尽。
PHP 层配置要配合，但不能越位
PHP 自身参数不主导超时决策，仅作辅助或兼容：
- max_execution_time（php.ini）：保留合理值（如 300），用于限制纯计算逻辑，不影响 IO；
-
max_input_time：控制接收 POST 数据（包括上传）的最长时间，应 ≥ Nginx 的
client_body_timeout； - ignore_user_abort(true)：仅在脚本需后台持续运行（如发邮件、写日志）时使用，不能解决超时中断问题，反而可能掩盖资源失控。
别忽略缓冲与临时路径，它们会让超时“假性触发”
即使所有 timeout 都设对，Nginx 缓冲区太小或 tmp 目录不可写，也会导致上传卡在中间环节，最终被 timeout 捕获：
- 在 PHP location 块中增加缓冲配置：
fastcgi_buffer_size 128k;<br>fastcgi_buffers 4 256k;<br>fastcgi_busy_buffers_size 512k;<br>fastcgi_temp_file_write_size 512k;
- 确认
fastcgi_temp_path（默认在 Nginx 安装目录下）和 PHP 的upload_tmp_dir对www用户可写、空间充足； - 错误日志若出现
upstream buffer is too small或failed to open stream: Permission denied，就是这里出了问题。
