怎么利用 $sent_http_server 变量在多层嵌套网关日志中精准追踪当前状态码是由哪一层网关吐出-Nginx-PHP中文网

$sent_http_server 仅反映最外层 nginx 设置的 server 头，无法标识状态码真实来源；需结合 x-gateway-id、x-status-origin 响应头、$upstream_status、$upstream_http_x_gateway_id 及 x-request-id 日志关联，才能精准追踪多层网关中状态码的生成源头。

怎么利用 $sent_http_server 变量在多层嵌套网关日志中精准追踪当前状态码是由哪一层网关吐出

直接看 $sent_http_server 无法精准定位哪一层网关返回了当前状态码，因为它只反映最外层 Nginx 实际发出响应时设置的 Server 头值，而非状态码的真实来源。要实现多层网关（如 CDN → API 网关 → 边缘网关 → 应用网关）中对状态码来源的精准追踪，需配合其他机制协同实现。

明确 $sent_http_server 的局限性

$sent_http_server 是 Nginx 在准备发送响应给客户端前，从当前配置中 server 指令或 add_header Server ... 设置的值读取的。它不记录上游响应头中的 Server 字段，也不感知上游返回的状态码来源。例如：

CDN 层（Nginx）转发请求到后端网关，后端返回 502，CDN 自己生成响应并设 Server: CDN-Nginx/1.22 → $sent_http_server 是 CDN 的标识；
但若 CDN 透传后端响应（未改写 Server 头），而自身又没设 add_header Server，则 $sent_http_server 默认为 nginx，完全丢失后端信息。

用自定义响应头传递网关身份与状态来源

在每一层网关的 Nginx 配置中，统一约定添加可追溯的响应头，例如 X-Gateway-ID 和 X-Status-Origin：

Nginx Hosting

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

下载

每层网关在 location 或 upstream 块中，用 proxy_pass_request_headers off（可选）+ proxy_set_header 控制请求头；
在 proxy_intercept_errors on + error_page 或 if ($upstream_status ~ ^5) { ... } 分支里，显式设置：
add_header X-Gateway-ID "edge-gw-v2" always;
add_header X-Status-Origin "edge-gw-v2" always;
对于正常透传的响应，在 location 中统一加：
add_header X-Gateway-ID "api-gw-prod" always;
add_header X-Status-Origin "$upstream_http_x_gateway_id" always;（前提是上游也按规范返回 X-Gateway-ID）。

结合 $upstream_status 与 $upstream_http_* 变量做上下文判断

真正决定状态码来源的关键变量是 $upstream_status（上游返回的状态码）和 $upstream_http_x_gateway_id（上游响应头）：

若 $upstream_status == $status 且非 5xx/4xx 错误拦截路径，则当前状态码大概率来自上游，此时 $upstream_http_x_gateway_id 就是源头；
若 $upstream_status 为空或为 000（连接失败）、或 $status 是由本层 error_page 触发（如 502/504），则 $sent_http_server 对应的网关就是状态码生成者；
日志格式中建议同时记录：
log_format trace '$remote_addr - $upstream_addr [$time_local] "$request" $status $upstream_status "$upstream_http_x_gateway_id" "$sent_http_server"';

在日志中结构化输出并做后处理关联

单靠一条日志行难以直接看出调用链，需让每层网关注入唯一请求 ID 并记录完整跳转路径：

所有网关在入口处统一设置：proxy_set_header X-Request-ID $request_id;，并在响应头回传：add_header X-Request-ID $request_id always;；
每层在日志中记录：$request_id $upstream_http_x_request_id $upstream_addr $upstream_status $sent_http_server；
通过 ELK 或 Loki 按 X-Request-ID 聚合多层日志，就能还原出：CDN（504）← 边缘网关（无响应）← API 网关（502）← 应用网关（超时）的完整状态码传播链。