Nginx 本身不直接输出节点上下线事件日志，但可通过三层证据链实现可审计状态记录：①自定义 access_log 记录请求转发路径与结果（含 $upstream_addr、$upstream_status）；②启用 upstream_check_module 并配置 error_log notice 级别，捕获“is up/down”状态变更事件；③暴露 /status 接口并定时快照归档 JSON 状态。

要在安全审计中提供完整的后端节点状态日志，Nginx 本身不直接输出“节点上下线事件”的结构化日志，但可通过组合配置实现可审计、可回溯、带时间戳和明确因果的状态记录。关键不是单条日志，而是构建一套包含请求转发痕迹 + 主动探测结果 + 状态变更信号的三层日志证据链。

用自定义 access_log 记录每次请求的实际转发路径与结果

这是审计最基础也最关键的证据：每笔流量到底去了哪台机器、耗时多少、返回什么状态码，必须可查。

• 在 http 块中定义含上游信息的日志格式：

log_format upstream_log '$remote_addr - $remote_user [$time_local] "$request" ' '
'$status $body_bytes_sent "$http_referer" "$http_user_agent" ' '
'$upstream_addr $upstream_status $upstream_response_time $request_time';

其中：$upstream_addr 显示实际转发的 IP:PORT（如 192.168.1.10:8080），$upstream_status 是后端真实返回码（如 200 或 502），$upstream_response_time 可识别慢节点。

• 在 server 或 location 中启用该格式：

access_log /var/log/nginx/upstream_access.log upstream_log;

这条日志能证明“某时刻某请求被发往哪个节点并得到何种响应”，是故障定责和行为溯源的第一手依据。

用 error_log + upstream_check_module 捕获节点状态变更事件

纯被动检查（max_fails）不会写入 error_log；只有启用 nginx_upstream_check_module 并开启其探测后，状态切换才会以明确文本形式落进 error_log，满足审计对“状态变更可记录”的要求。

• 确保 upstream 块中启用主动探测，并设置 default_down on（防止启动时误判）：

upstream app {
  server 192.168.1.10:8080;
  server 192.168.1.11:8080;
  check interval=5 rise=2 fall=5 timeout=1 type=http;
  check_http_send "GET /ready HTTP/1.1\r\nHost: check\r\n\r\n";
  check_http_expect_alive http_2xx;
  default_down on;
}

• 在全局或 http 块中提高 error_log 级别，并单独切分日志：

error_log /var/log/nginx/upstream_error.log notice;

当节点从 up → down 或 down → up 时，Nginx 会写入类似：

Nginx Hosting

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

下载

2026/08/20 14:22:33 [notice] 12345#0: *6789 upstream check: server 192.168.1.10:8080 is down
2026/08/20 14:27:11 [notice] 12345#0: *7890 upstream check: server 192.168.1.10:8080 is up

这些带精确时间戳和动作描述的行，是审计报告中“节点何时失效/恢复”的核心证据。

暴露 /status 接口并定期快照留存

仅靠日志流不够——审计常需“某一时刻全量状态快照”。nginx_upstream_check_module 提供 /status 接口（需 location 显式配置），返回 JSON 格式的实时节点列表及状态（up/down、rise/fall计数、上次检查时间等）。

• 添加 status 路由（注意加访问控制）：

location /status {
  check_status;
  allow 127.0.0.1;
  allow 10.0.0.0/8;
  deny all;
}

• 配合 cron 定期抓取并归档：

# 每5分钟保存一次快照
*/5 * * * * curl -s http://localhost/status | jq '.' > /var/log/nginx/status-$(date +\%Y\%m\%d-\%H\%M).json

这些带时间戳的 JSON 文件可作为审计附件，验证“在X时间点，哪些节点被标记为 down，是否符合预期策略”。

补充：防火墙与中间件日志交叉验证

安全审计强调多源印证。如果发现某节点频繁被标记为 down，但应用日志无异常，应检查：

• iptables 或云平台安全组是否拦截了健康检查探针（特别是 /ready 路径）
• WAF 是否将探测请求识别为扫描并阻断
• 网络设备（如交换机 ACL）是否丢弃了特定源端口的 TCP 包

建议将防火墙日志（如 iptables -L -v -n 输出）、WAF 告警日志与 Nginx 的 upstream_error.log 时间轴对齐，形成完整链路证据，避免把网络层问题误判为后端故障。