在Nginx的server块中设置error_log指令可为虚拟主机指定专属错误日志路径，覆盖全局配置但仅捕获该站点相关错误（如upstream失败、SSL异常），需用绝对路径并确保Nginx进程有写权限，不支持location块内配置。
在 Nginx 的 server 块中设置独立站点的专属错误日志路径，只需直接写入 error_log 指令即可。它会覆盖全局（http 块）配置，只记录该虚拟主机范围内发生的 error 及更高级别错误。
在 server 块内直接指定路径
把 error_log 指令放在对应站点的 server { ... } 内部，路径必须是绝对路径，且需确保 Nginx 工作进程（如 nginx 或 www-data 用户）对该目录有写权限：
error_log /data/logs/example.com/error.log error;- 支持的日志级别包括：
debug、info、notice、warn、error、crit、alert、emerg；生产环境常用error或warn，减少冗余 - 多个
error_log指令可共存于同一server块，消息会同时写入所有指定文件（Nginx 1.5.2+ 支持）
注意作用范围和继承规则
error_log 在 server 级生效时，仅捕获该虚拟主机相关的运行时错误，例如：
- upstream 连接失败（如后端服务不可达）
- SSL 握手异常（针对 HTTPS server）
- rewrite 规则循环或重定向过多
但底层核心错误（如 worker 进程崩溃、配置加载失败、磁盘满导致日志无法写入）仍会记入全局 error_log，不会被 server 级配置覆盖。
配套操作不能少
光写配置还不够，得让路径真正可用：
- 手动创建目录：比如
sudo mkdir -p /data/logs/example.com - 赋予权限：比如
sudo chown nginx:nginx /data/logs/example.com（用户组名依实际部署而定） - 验证语法：运行
nginx -t确保无报错 - 重载生效：执行
nginx -s reload或systemctl reload nginx
不建议在 location 块里配 error_log
error_log 不支持在 location 块中使用（Nginx 官方未定义该作用域）。若需要按路径区分错误行为，应通过应用层日志或 upstream 健康检查等机制间接实现，而非依赖 location 级 error_log。
