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() 方法里。