Nginx 中健康检查怎么在安全审计中提供完整的后端节点状态日志-Nginx-PHP中文网

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

nginx 中健康检查怎么在安全审计中提供完整的后端节点状态日志

要在安全审计中提供完整的后端节点状态日志，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

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