phpEnv本身不解决502错误，它仅是PHP多版本管理工具；真正需调优的是nginx、php-fpm及系统资源三者协同配置，包括php-fpm进程监听地址与nginx fastcgi_pass一致性、fastcgi_buffer大小、request_terminate_timeout与fastcgi_read_timeout匹配、以及/tmp磁盘空间等。
phpEnv 本身不解决 502 错误，它只是个 PHP 多版本管理工具；真正要调的是 nginx、php-fpm 和系统资源三者的协同配置。
为什么 phpEnv 启动后还是报 502
phpEnv 安装完 PHP 后，默认不会自动配置 php-fpm 的 pm.max_children 或 nginx 的 fastcgi_pass 地址。常见现象是：nginx 日志里反复出现 connect() failed (111: Connection refused) while connecting to upstream，说明 nginx 根本连不上 php-fpm。
检查点包括：
- 确认 php-fpm 是否真的在运行：
ps aux | grep php-fpm，看有没有 master 进程 - 确认 phpEnv 切换的 PHP 版本对应的 php-fpm 配置路径（如
~/.phpenv/versions/8.2.12/etc/php-fpm.d/www.conf）是否启用了listen = 127.0.0.1:9000或 socket 路径 - 确认 nginx 的
fastcgi_pass值和 php-fpm 的listen完全一致（IP+端口 或 socket 文件路径） - 如果用 socket，确保 nginx worker 进程用户（如
www-data）对 socket 文件有读写权限
phpEnv 环境下 fastcgi_buffer 不够导致 502
phpEnv 不影响 nginx 缓冲区设置，但多版本 PHP 下容易忽略这个硬性限制。当 PHP 脚本输出 header 过大（比如含大量 Cookie、重定向 Location、或调试信息），而 nginx 默认 fastcgi_buffer_size 只有 4k，就会触发 502。
立即学习“PHP免费学习笔记（深入）”；
典型错误日志：upstream sent too big header while reading response header from upstream
实操建议：
- 在 nginx server 或 location 块中显式加大缓冲：
fastcgi_buffer_size 32k;fastcgi_buffers 8 32k; - 不要只改
fastcgi_buffer_size，必须同步调大fastcgi_buffers，否则无效 - 如果用了 opcache + xdebug，某些调试头会撑爆 buffer，临时关掉 xdebug 更快定位
phpEnv 切换版本后 request_terminate_timeout 不匹配
phpEnv 切换 PHP 版本时，php-fpm.conf 或 www.conf 中的超时参数不会自动继承或重置。老版本可能设了 request_terminate_timeout = 0，新版本若没配，就沿用默认值（通常是 0s 或 30s），一旦脚本卡住，php-fpm 主动 kill 进程，nginx 收不到响应就报 502。
OpenClaw Gateway 重启性能分析工具：分析重启速度、定位启动慢原因、生成性能报告、诊断启动问题。支持 Windows (PowerShell) 与 Linux (Bash)。触发场景：分析 gateway 重启、检查启动时间、生成报告、诊断异常。
关键参数位置：
-
request_terminate_timeout（php-fpm 配置，控制单个请求最大执行时间） -
fastcgi_read_timeout（nginx 配置，控制等待 php-fpm 返回响应的最长时间）
二者必须满足：fastcgi_read_timeout ≥ request_terminate_timeout，否则 nginx 先超时断连，报 502。
建议值（平衡稳定性与体验）：
- 开发环境：
request_terminate_timeout = 300，fastcgi_read_timeout 300 - 生产 API 接口：
request_terminate_timeout = 60，fastcgi_read_timeout 90
磁盘满或 tmpfs 溢出引发的隐性 502
phpEnv 自身不占磁盘，但它跑起来的 PHP 脚本（尤其是 Composer、上传临时文件、opcache file cache）会往 /tmp 或 sys_temp_dir 写数据。ECS 实例或 Docker 容器里 /tmp 常挂载为 tmpfs，内存有限，写满后 PHP 进程直接失败，nginx 就收不到任何响应。
排查命令：
-
df -h /tmp（看是否 100%） -
df -h | grep -E "(tmp|var)"（顺带查/var/log、/var/lib/php/sessions） -
php -i | grep "sys_temp_dir"（确认 PHP 实际用的临时目录）
临时缓解：
- 清空
/tmp：find /tmp -type f -mmin +60 -delete（删 1 小时前的临时文件） - 改 PHP 临时目录到更大分区：
sys_temp_dir = /data/tmp（写进 php.ini）
真正复杂的是：这类问题不会在 nginx error.log 里明确说“disk full”，只会报模糊的 upstream prematurely closed connection，得结合系统日志 dmesg -T | tail 看 OOM 或 ext4 write errors 才能确认。
