TP5.1 项目为何总是 502？Nginx 与 PHP-FPM 超时配置全解【运维】
TP5.1项目Nginx下频繁502主因是超时、缓冲、进程数三者未对齐，需同步调大fastcgi_read_timeout与request_terminate_timeout（后者≥前者）、扩充fastcgi_buffers，并修正PATH_INFO传递逻辑。
TP5.1 项目在 Nginx 下频繁报 502 Bad Gateway，大概率不是代码问题，而是 Nginx 与 PHP-FPM 的超时、缓冲、进程数三者没对齐——尤其当请求涉及数据库慢查询、Excel 导出或 Redis 阻塞时，fastcgi_read_timeout 和 request_terminate_timeout 差 1 秒都会触发 502。
为什么 TP5.1 特别容易踩超时坑
ThinkPHP 5.1 默认开启路由自动解析，且大量中间件（如日志写入、权限校验）在请求生命周期早期就执行；一旦某个环节卡住（比如 file_get_contents 调用外部接口没设超时），整个 PHP 进程就会挂住。而 TP5.1 自身不控制脚本执行上限，全依赖 PHP-FPM 层的 request_terminate_timeout 来“强杀”。如果这个值比 Nginx 的 fastcgi_read_timeout 小，Nginx 先断连，PHP-FPM 进程却还僵在那儿，后续请求全排队失败。
- TP5.1 的
app_debug = true会额外增加日志写入开销，高并发下极易拖慢响应 - 框架内部的
Db::transaction()若未正确 commit/rollback，可能长期持有数据库连接，间接导致 FPM worker 被占满 - 宝塔、LNMP 一键包默认的
fastcgi_read_timeout 60和request_terminate_timeout 0组合，在 TP5.1 场景下几乎必出 502
必须同步调整的三个超时参数
只改 Nginx 或只改 PHP-FPM 都没用，必须成对设置，且满足 request_terminate_timeout >= fastcgi_read_timeout。否则 Nginx 等不及，直接发 RST 给 PHP-FPM，后者来不及清理状态。
- 在 Nginx 的
location ~ .php$块中加：fastcgi_connect_timeout 30;fastcgi_send_timeout 300;fastcgi_read_timeout 300;
- 在 PHP-FPM 的 pool 配置（如
/etc/php/8.1/fpm/pool.d/www.conf）中改：request_terminate_timeout = 300; 注意：不要设为 0，TP5.1 下极易积累僵死进程
- 同时检查 PHP 层级限制（虽被 FPM 覆盖，但留作兜底）：
max_execution_time = 240
缓冲区大小直接影响大响应是否截断
TP5.1 导出 Excel、生成 PDF 或返回长 JSON 时，若 Nginx 缓冲区太小，会在读取完响应体前就关闭连接，表现为偶发 502 + upstream prematurely closed connection。
立即学习“PHP免费学习笔记（深入）”；
- 在同一个
location ~ .php$块内补全缓冲配置：fastcgi_buffer_size 128k;fastcgi_buffers 8 256k;fastcgi_busy_buffers_size 512k;
-
fastcgi_buffers总容量不能小于预期最大响应体（例如导出 10MB Excel，至少设为40 256k） - 避免使用
fastcgi_max_temp_file_size 0，临时文件禁用后，超大响应会直接 502
PATH_INFO 配置错误会静默引发 502
TP5.1 仍重度依赖 PATH_INFO 解析 URL 路由（如 /index.php/user/list）。Nginx 若未正确提取并传递该变量，PHP-FPM 收不到路由信息，$_SERVER['PATH_INFO'] 为空，框架路由匹配失败，最终返回空响应 → Nginx 判定 upstream 异常 → 502。
- 确认 Nginx 配置中 PHP location 使用正则匹配：
location ~ .php(.*)?$ { - 里面必须包含这两行（顺序不能错）：
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;fastcgi_param PATH_INFO $1;
- 删掉任何重复定义
SCRIPT_FILENAME或覆盖PATH_INFO的if块（LNMP 一键包的enable-php.conf里常见此类 bug）
真正难排查的 502 往往不出现在日志里——它发生在 PHP-FPM worker 被卡住但尚未超时的那几秒。建议上线前用 strace -p $(pgrep -f 'php-fpm: pool www' | head -1) -e trace=network,io 抓一个真实请求，看它最后停在哪条系统调用上。多数时候，答案不在 Nginx 配置里，而在 TP5.1 某个模型的 save() 方法里。
