504错误本质是Nginx等待php-fpm响应超时，需同步调优Nginx的fastcgi_read_timeout和php-fpm的request_terminate_timeout，且后者必须≥前者，否则仍报504。
phpEnv 的 Nginx 504 错误本质是反向代理超时，不是 PHP 脚本执行超时
504 Gateway Timeout 表示 Nginx 等待上游（这里是 php-fpm）响应超时，和 max_execution_time 无关。phpEnv 封装了 Nginx + php-fpm，需同时调优两端：Nginx 的代理超时参数、php-fpm 的响应等待上限。
修改 Nginx 的 fastcgi_read_timeout 和 proxy_read_timeout
phpEnv 的 Nginx 配置文件通常位于 C:\phpEnv\nginx\conf\vhost\your-site.conf（Windows）或 /usr/local/phpenv/nginx/conf/vhost/xxx.conf（Linux/macOS）。在 location ~ \.php$ 块内添加或修改以下两项：
fastcgi_read_timeout 300; proxy_read_timeout 300;
注意：fastcgi_read_timeout 适用于 fastcgi 协议（php-fpm 默认模式），proxy_read_timeout 仅在你手动改用 proxy_pass 转发到 php-fpm 时才生效 —— phpEnv 默认用 fastcgi_pass，所以优先确认并设置 fastcgi_read_timeout。
同步调整 php-fpm 的 request_terminate_timeout
phpEnv 的 php-fpm 配置路径一般为 C:\phpEnv\php\php-fpm.conf 或 C:\phpEnv\php\etc\php-fpm.conf。找到并取消注释或新增：
立即学习“PHP免费学习笔记（深入）”；
request_terminate_timeout = 300s
这个值必须 ≥ Nginx 的 fastcgi_read_timeout，否则 php-fpm 会主动杀掉进程，Nginx 收不到响应，仍报 504。常见错误是只调大 Nginx 超时却忽略 php-fpm 侧限制。
-
request_terminate_timeout控制单个请求最大存活时间（含排队+执行） - 若使用
ondemand或dynamic进程管理，还需检查pm.process_idle_timeout，它不直接影响 504，但空闲超时过短会导致 worker 频繁启停，间接增加响应延迟
验证修改是否生效 & 容易踩的坑
改完配置后必须重启服务：先 phpenv stop，再 phpenv start（Windows）；Linux/macOS 下对应 sudo systemctl restart phpenv-nginx 和 sudo systemctl restart phpenv-phpfpm。别只 reload。
验证方式：写一个测试脚本 sleep.php：
<?php sleep(250); echo 'done'; ?>
访问它，看是否返回 504 或成功。如果仍 504，检查：
- 配置文件路径是否改对了 —— phpEnv 多版本共存时，容易编辑了旧版本的
php-fpm.conf - Windows 下某些 phpEnv 版本会读取
php.ini中的max_execution_time并覆盖 php-fpm 行为，此时需一并设为 ≥300 - Nginx error log（
logs/error.log）里是否有upstream timed out明确提示，以及对应 upstream 是127.0.0.1:9000还是 unix socket —— 若是 socket，超时逻辑一致，但路径权限问题也可能伪装成超时
真正卡住的地方往往不在 timeout 数值本身，而在 php-fpm worker 是否真能被调度到、有没有被其他长任务占满、磁盘 I/O 或数据库锁导致响应停滞 —— 504 是表象，背后可能是资源瓶颈或死锁。
