504错误源于Nginx、PHP-FPM、PHP脚本三层超时未对齐，需同步调整fastcgi_read_timeout、request_terminate_timeout及脚本内主动超时判断。
ThinkPHP 6.0 本身不接管 HTTP 请求超时控制，504 Gateway Timeout 错误本质是 Nginx 等待 PHP-FPM 响应超时后主动关闭连接所致。问题不在框架代码，而在 Nginx → PHP-FPM → PHP 脚本三层超时未对齐，导致某一层先断开，上层误判为网关超时。
Nginx 层必须同步调整的 timeout 参数
504 错误通常对应 fastcgi_read_timeout 触发（Nginx 等 PHP-FPM 返回响应超时），但仅调这一项远远不够：
-
fastcgi_read_timeout 300;—— Nginx 等待 PHP-FPM 输出响应的总空闲时间（推荐设为 PHP 最大执行时间的 1.2 倍） -
fastcgi_connect_timeout 60;—— 建立到 PHP-FPM 的连接不能太慢（尤其用 TCP 监听时） -
fastcgi_send_timeout 300;—— Nginx 向 PHP-FPM 发送完整请求体（如大文件上传）期间的写入间隔超时 - 若使用
proxy_pass转发而非fastcgi_pass，则需改用proxy_read_timeout 300;等 proxy 系列参数
这些参数应放在 location ~ \.php$ { ... } 块内，或 server 级别，避免被继承覆盖。
PHP-FPM 层需匹配的关键配置
PHP-FPM 不会自动感知 Nginx 超时，必须手动对齐：
- 编辑
/etc/php/*/fpm/pool.d/www.conf，确认以下三项：-
request_terminate_timeout = 300—— 强制终止超时请求（单位秒，必须 ≥ Nginx fastcgi_read_timeout） -
request_slowlog_timeout = 10s—— 配合 slowlog 定位卡点（建议开启） -
slowlog = /var/log/php-fpm/www-slow.log—— 日志路径需可写
-
⚠️ 注意：request_terminate_timeout 默认为 0（不限制），若未显式设置，PHP-FPM 可能无限等待，而 Nginx 先超时返回 504。
PHP 脚本层要主动兜底
ThinkPHP 6.0 无法自动中断超时脚本，但可通过以下方式提前响应、避免拖累：
- 在全局中间件
handle()开头记录起始时间：$start = microtime(true);
- 在关键业务逻辑前插入判断：
if (microtime(true) - $start > 280) { // 留 20 秒余量给 Nginx/FPM 处理 return json(['code' => 504, 'msg' => 'Request timeout']); } - 对数据库查询加会话级超时（MySQL 5.7.8+）：
Db::execute('SET SESSION max_execution_time = 250000'); // 250 秒
验证与排查要点
立即学习“PHP免费学习笔记（深入）”；
- 执行
sudo nginx -t && sudo systemctl reload nginx和sudo systemctl restart php*-fpm（注意服务名，如php8.1-fpm） - 查看 Nginx error log 中是否含
upstream timed out；PHP-FPM slowlog 是否有长耗时记录 - 用
curl -v http://your-domain/test-timeout.php模拟慢请求，观察返回状态码与耗时 - 确保
max_execution_time（php.ini）、request_terminate_timeout（FPM）、fastcgi_read_timeout（Nginx）三者数值梯度合理，且 FPM 的值 ≥ Nginx 的值
不复杂但容易忽略
