phpEnv 下 Nginx error_log 级别不能一键调高，需手动修改配置并确认编译含 --with-debug；若不支持 debug，则改用 notice 级别排查启动、reload 及 worker 异常，且 main 级日志才记录 Nginx 自身错误。
phpEnv 环境下 Nginx 的 error_log 级别不能靠“一键开关”调高，必须手动改配置并确认编译支持——否则设成 debug 也白搭。
确认 phpEnv 编译时是否含 --with-debug
phpEnv 自带的 Nginx 多数是精简版，默认不带 debug 支持。直接设 error_log /path/debug.log debug 不报错，但实际只按 info 甚至更低级别写日志。
- 运行
nginx -V 2>&1 | grep -o with-debug，有输出才表示支持；没输出就说明 debug 不可用 - 若不支持，临时方案是降级用
notice或warn：它们无需额外编译，能覆盖重定向循环、证书过期、upstream 连接拒绝等关键线索 - 不要依赖 phpEnv 的图形界面或快捷命令修改日志级别——它通常只改
access_log或 PHP 配置，对 Nginx 全局error_log无效
全局 error_log 和 server 块 error_log 的作用完全不同
在 phpEnv 的 nginx.conf 里，你可能看到两处 error_log：一处在最外层（main 级），一处在某个 server 块里。它们记录的东西根本不是一回事。
- main 级
error_log（位于events和http块之外）只管 Nginx 自身：主进程启动失败、配置加载崩溃、bind()被拒、worker 初始化异常——这些才是“隐藏系统 Bug”的高发区 -
server块里的error_log只影响该虚拟主机的请求错误，比如upstream timed out或client intended to send too large body，和 phpEnv 的底层调度无关 - 排查 phpEnv 启动后 Nginx 没反应、reload 失败、或某些 PHP 路由完全不进 fastcgi —— 必须盯紧 main 级
error_log，而不是去看/var/log/nginx/access.log
临时升到 notice 看 reload 和 worker 行为
生产环境不敢开 debug，但 notice 是安全的折中点：它不刷屏，却能暴露 reload 是否真正生效、worker 是否被意外 kill、甚至 php-fpm socket 是否被拒绝连接。
立即学习“PHP免费学习笔记（深入）”；
- 编辑
/usr/local/phpenv/nginx/conf/nginx.conf（路径依 phpEnv 实际安装位置而定），找到最顶部的error_log行，改成：error_log /var/log/nginx/error.log notice; - 执行
nginx -t确认语法，再nginx -s reload生效——此时日志里会出现reconfiguring、cycle finished等字样 - 如果 reload 后日志里没出现这些词，说明 reload 根本没成功，可能是配置被 phpEnv 的模板覆盖，或权限问题导致新配置未加载
- 配合
ps aux | grep nginx看 worker 进程 PID 是否变化，交叉验证 reload 是否真实发生
PHP 错误不进 Nginx error_log？这不是 Nginx 的锅
很多人以为把 Nginx error_log 设成 debug 就能看到 PHP 报错，其实完全误解了职责边界。
- Nginx 的
error_log永远不会记录PHP Parse error或Fatal error—— 它只记录自己跟 PHP 交互过程中的失败，比如：connect() failed (111: Connection refused) while connecting to upstream - 真正的 PHP 错误必须由 PHP 自己写入，靠的是
log_errors = On+error_log = /var/log/php/error.log（在php.ini或 php-fpm pool 配置里） - phpEnv 下常见陷阱：多个 PHP 版本共存，改了
/etc/php/8.1/fpm/php.ini，但实际跑的是 8.2，结果日志还是空的——查php-fpm -i | grep "Loaded Configuration File"确认真实生效的 ini 路径
真正难啃的系统 Bug 往往藏在 reload 行为、worker 生命周期、或 Nginx 与 php-fpm 的 socket 权限链路里——这些细节只有 main 级 error_log 在 notice 或更高时才会吐露，且必须和 ps、lsof、journalctl -u php-fpm 联动看，单盯一个文件永远漏关键环。
