应使用$upstream_status变量记录上游服务器返回的真实HTTP状态码，该变量在Nginx≥1.7.10中稳定支持，多个upstream时以逗号分隔，未转发时显示为“-”。

要让 Nginx 日志准确记录后端 Upstream 服务器返回的真实 HTTP 状态码（即上游实际响应的状态码，而非 Nginx 自身生成的如 502、503 等代理层状态码），关键在于使用 $upstream_status 变量，并确保它在日志格式中被正确引用、且 Nginx 配置逻辑不会覆盖或干扰其取值。

确认 $upstream_status 的行为特点

$upstream_status 是 Nginx 内置变量，表示与当前请求匹配的 upstream server 实际返回的 HTTP 状态码。它的取值有以下要点：

• 仅在成功从 upstream 接收到响应时才有意义；若连接失败（如超时、拒绝连接）、Nginx 自行返回错误（如 502/504），该变量值为 “-” 或空字符串
• 当启用 proxy_next_upstream 并发生重试时，$upstream_status 记录的是**最终成功响应的那个 upstream 的状态码**，不是第一次失败的
• 它不等于 $status（Nginx 发送给客户端的响应状态码），后者可能被 error_page、rewrite 或内部跳转修改

定义含 $upstream_status 的自定义日志格式

在 http 块中定义日志格式，显式包含 $upstream_status：

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

注意：$upstream_status 在无 upstream 响应时会输出“-”，这是正常行为，可用于识别失败场景。

Nginx Hosting

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

下载

确保 upstream 配置和 proxy 设置不干扰状态码传递

以下配置要点可避免 $upstream_status 失效或失真：

• 不要用 error_page 502 503 504 = @fallback 类重写方式掩盖原始 upstream 状态 —— 这会导致 $upstream_status 无法记录（因未真正收到 upstream 响应）
• 如需容错，建议用 proxy_next_upstream error timeout http_500 http_502 http_503 http_504; 触发重试，这样仍能捕获最终成功节点的状态码
• 禁用 proxy_intercept_errors on（默认 off），否则 Nginx 可能拦截并替换 upstream 的错误响应，导致 $upstream_status 不再反映真实值

验证日志输出是否符合预期

通过 curl 或压测工具发起请求，同时查看 access log 输出：

• 后端返回 200 → 日志中 upstream_status:200，status:200
• 后端返回 500 → 日志中 upstream_status:500，status:500（前提是未配 error_page 拦截）
• 后端宕机触发 502 → 日志中 upstream_status:-，status:502
• 启用重试后某节点返回 200 → upstream_status:200，即使第一个节点返回了 503

可配合 tail -f /path/to/access.log | grep upstream_status 实时观察。