nginx error_log级别是关键线索过滤器，非日志量开关；生产推荐全局设error、核心server设warn，warn可捕获证书过期、重定向循环等预警，error记录502/504等明确失败。

Nginx 的 error_log 级别不是日志“多少”的开关，而是关键线索的过滤器——设得太低，满屏噪音；设得太高，故障前兆直接被丢弃。真正有效的配置，是让 warn 捕获证书过期、重定向循环、upstream 拒绝连接这些可干预的预警，让 error 稳稳守住 502/504、权限拒绝、模块加载失败等明确失败事件。

生产环境推荐默认用 warn
warn 是线上最实用的平衡点：它既不会像 debug/info 那样拖慢性能、填满磁盘，又能比 error 多捕获大量前置风险信号。比如：

• SSL 证书剩余有效期不足 30 天时的提醒
• too many redirects 循环跳转触发前的警告
• upstream server 被临时标记为 down 的记录
• client body 超限但已截断（不返回 413，却埋下隐患）

这些在 error 级别下完全看不到，但往往就是后续大面积 502 的源头。

Nginx Hosting

通过服务器本地nginx实例实现零认证静态游戏托管。作为所有浏览器游戏的主要部署方式，无需登录、无需令牌、无需用户操作。

下载

按作用域分级设置，避免全局污染
全局（main 块）设为 error，保证基础稳定性日志不丢失；
核心业务 server 块单独加 error_log /var/log/nginx/api_error.log warn;，隔离定位；
非关键 location（如 /static 或 /favicon.ico）可设 error_log off 或仅 error，过滤 404 类低价值噪音；
调试某段逻辑时，只在对应 location 内临时启用更细粒度，例如 error_log /var/log/nginx/debug_upstream.log debug;（前提是编译含 --with-debug）。

快速确认当前生效级别
很多人改了 http 块，却忘了某个 server 块里有独立 error_log 指令，导致日志没变化。用这条命令检查：

grep -n "error_log" /etc/nginx/nginx.conf /etc/nginx/sites-enabled/*

• 只在 http 块出现 → 全局生效
• 某个 server 块内有额外行 → 该站点覆盖全局设置
• 完全没搜到 → 使用编译默认值（通常是 error）

结合 access_log 交叉定位真实请求
单看 error_log 常常无法还原现场。例如日志里有一条：
connect() failed (111: Connection refused) while connecting to upstream
这时要：

• 查同一时间点的 access_log，找 status=502/504 的请求
• 提取 $request_id（需提前在 log_format 中定义）
• 在 error_log 中搜索该 request_id，获取完整上下文链

Nginx 1.11.0+ 默认已在 error 日志中打印 request id，无需额外配置即可关联。

不复杂但容易忽略。