504错误源于Nginx、PHP-FPM、fastcgi三层超时配置未对齐：需同步设置fastcgi_read_timeout、request_terminate_timeout及max_execution_time≥300秒，并重启对应服务。
phpEnv 下 PHP 脚本执行耗时触发 504 Gateway Timeout，核心问题不在 phpEnv 本身，而在于它默认启用的 Nginx + PHP-FPM 组合中三处超时配置未对齐——改错一处，其他两处仍会掐断请求。
确认 phpEnv 使用的是 Nginx + PHP-FPM 模式
phpEnv 是多环境切换工具，但其底层 Web 服务默认走 Nginx（非 Apache）+ PHP-FPM FastCGI。这意味着你面对的是典型的「Nginx → FastCGI → PHP-FPM」三层链路，每层都有独立超时控制。若只调 max_execution_time，而 request_terminate_timeout 或 fastcgi_read_timeout 仍为默认值（常是 30–60 秒），请求必在中间某层被强制中断。
- 运行
ps aux | grep php-fpm确认进程存在，且版本与 phpEnv 当前激活环境一致（如/usr/local/phpenv/versions/8.1.27/sbin/php-fpm） - 检查 Nginx 配置中是否包含
fastcgi_pass指向 phpEnv 的 sock 文件（路径类似unix:/usr/local/phpenv/versions/8.1.27/var/run/php-fpm.sock） - 不建议强行切换为 Apache 模式——phpEnv 对 Apache 支持弱，且无法规避 FastCGI 层超时问题
同步修改 Nginx 的 fastcgi_* 超时参数
phpEnv 的 Nginx 配置通常位于 ~/.phpenv/versions/*/etc/nginx.conf 或全局 /usr/local/phpenv/etc/nginx.conf。关键不是加 proxy_*（那是反向代理模式用的），而是定位到 location ~ \.php$ 块内、include fastcgi.conf 之前的位置：
- 必须添加或修正这三项（单位为秒，数值需一致且 ≥ 300）：
fastcgi_connect_timeout 300、fastcgi_send_timeout 300、fastcgi_read_timeout 300 -
fastcgi_read_timeout最关键：它控制 Nginx 等待 PHP-FPM 返回响应的总时长；设太小，脚本还没输出就断连，直接 504 - 不要只改
http块顶层——phpEnv 的站点配置常走server块内联配置，顶层设置可能不生效
调整 PHP-FPM 的 request_terminate_timeout
这是最容易被忽略的一环。即使 php.ini 里 max_execution_time = 0，PHP-FPM 进程自身仍会按 request_terminate_timeout 强制杀掉 worker。该值在 phpEnv 中通常位于：~/.phpenv/versions/*/etc/php-fpm.d/www.conf（或 www.pool.conf）
立即学习“PHP免费学习笔记（深入）”；
- 找到
request_terminate_timeout行，改为request_terminate_timeout = 300（不推荐设为 0，易导致僵死进程） - 同时确认
request_slowlog_timeout已启用（如request_slowlog_timeout = 10s），便于后续定位真瓶颈 - 改完后必须重启对应版本的 PHP-FPM：
~/.phpenv/versions/8.1.27/sbin/php-fpm -t校验语法，再kill -USR2 $(cat ~/.phpenv/versions/8.1.27/var/run/php-fpm.pid)平滑重启
php.ini 中 max_execution_time 不是万能的
max_execution_time 只限制脚本级 CPU 时间，对 I/O 等待（如 MySQL 查询、curl 请求、sleep）无效。而 request_terminate_timeout 和 fastcgi_read_timeout 才真正决定“从 Nginx 接收请求到返回响应”的全程上限。
- 设
max_execution_time = 0后，仍需同步调高另两个超时值，否则毫无意义 - 代码中调用
set_time_limit(0)仅对当前请求生效，无法绕过 PHP-FPM 层的request_terminate_timeout - 若脚本实际耗时来自外部依赖（如慢 SQL、第三方 API），优化代码比调超时更治本——超时只是兜底，不是解决方案
真正卡住的地方往往不是「哪里没改」，而是「改了但没重载对应服务」——phpEnv 环境下，Nginx、PHP-FPM、甚至 shell 当前加载的 phpenv 版本都可能不同步，务必逐个验证进程 PID 和配置文件时间戳。
