504根本原因是Nginx或PHP-FPM某层超时切断连接；需同步调整nginx.conf中fastcgi_read_timeout等三项、php-fpm.conf中request_terminate_timeout和pm.max_children，并排除浏览器/代理、set_time_limit()、磁盘满等干扰因素。
phpEnv 环境下出现 504 Gateway Timeout，根本原因通常不是 phpEnv 本身，而是它默认封装的 Nginx + PHP-FPM 链路中某一层提前切断了连接 —— 你改了 php.ini 却没动 php-fpm.conf，或者改了 Nginx 却漏掉了 fastcgi_read_timeout，这类操作基本白忙。
phpEnv 的 Nginx 配置在哪改、改哪几项
phpEnv 自带的 Nginx 配置文件路径通常是 C:\phpEnv\nginx\conf\nginx.conf（Windows）或 /usr/local/phpenv/nginx/conf/nginx.conf（Linux/macOS）。别去改全局 http 块，直接定位到你站点对应的 server 块里加：
-
fastcgi_connect_timeout 300：PHP-FPM 连接建立超时，设太小会连不上 -
fastcgi_send_timeout 300：Nginx 向 PHP-FPM 发数据的超时，大文件上传或 POST 数据多时容易触发 -
fastcgi_read_timeout 300：最关键的项 —— PHP-FPM 执行完返回响应的等待上限，504 大部分卡在这儿 -
fastcgi_buffer_size 128k和fastcgi_buffers 8 128k：缓冲区太小会导致 Nginx 挂起等待，间接引发 504（尤其输出大量 HTML 或 JSON 时）
改完必须执行 phpenv nginx reload 或手动 nginx -s reload，否则不生效。
phpEnv 的 php-fpm.conf 必须同步调
phpEnv 的 PHP-FPM 配置文件一般在 C:\phpEnv\php\php-fpm.conf（Windows）或 /usr/local/phpenv/php/etc/php-fpm.conf（Linux/macOS）。只改 max_execution_time 在 php.ini 里是不够的，FPM 层有独立熔断机制：
立即学习“PHP免费学习笔记（深入）”；
-
request_terminate_timeout = 300：这是 PHP-FPM 进程级硬超时，设为0表示不限制（慎用，脚本死循环会卡死进程） -
request_slowlog_timeout = 10：配合 slowlog 查慢脚本，避免盲目调高超时掩盖性能问题 -
pm.max_children = 32：如果并发请求多但子进程数太少，请求排队等不到 worker，也会表现为 504（看phpenv fpm status的 active processes 是否长期满）
改完要重启 FPM：phpenv fpm restart，不是 reload。
为什么改了所有配置还是 504？检查这三处
常见“明明都设了 300 秒却仍 60 秒就报错”的真实原因：
- 浏览器或代理层超时：比如你用 Chrome 访问，背后经过公司 Proxy 或阿里云 SLB，它们有自己的
proxy_read_timeout，和你的 phpEnv 完全无关 —— 用curl -v http://localhost/your-script.php直连本地验证 - PHP 脚本里写了
set_time_limit(60)：这个函数会覆盖 php.ini 的max_execution_time，优先级更高 - 磁盘满导致 Nginx error.log 写不进日志，Nginx 自身异常降级 —— 查
df -h或 Windows 磁盘空间，再看error.log最后一行是否卡在 “open() “/path/to/log” failed (28: No space left on device)”
phpEnv 下调试 504 的最小闭环方法
别一上来就调所有 timeout，先用一个可控脚本快速定位瓶颈：
```php <?php // test_timeout.php sleep(70); // 故意拖过 60 秒 echo "done"; ?>
然后分步验证：
- 用
curl -v http://localhost/test_timeout.php：如果 70 秒后返回，说明 phpEnv 链路没问题，问题在外围 - 如果 60 秒返回 504，立刻查
error.log，看有没有 “upstream timed out (110: Connection timed out)” —— 有则确认是 Nginx 的fastcgi_read_timeout生效了 - 如果 curl 成功但浏览器失败，开浏览器 DevTools → Network → 查看 Headers 里的
X-Response-Time或直接看 Timing 标签页，确认是哪一层断开
真正卡住的地方，往往不在你最先怀疑的配置文件里。比如改了 10 处 timeout，结果发现是 hosts 文件里域名解析绕了一圈 CDN，实际请求压根没走到你的 phpEnv —— 这种情况在本地开发环境特别容易忽略。
