必须同时记录 $request_id 和 $upstream_http_x_request_id，因为前者标识网关接收请求，后者反映后端是否真实接收并回传该ID，二者比对可验证透传完整性、发现缺失或篡改。

直接在 Nginx 日志中记录 $upstream_http_x_request_id，就能把后端服务返回的请求 ID 原样捕获下来，形成网关与后端之间的双向 ID 对照关系，这是实现透传审计最轻量、最可靠的方式。

为什么必须同时记录 $request_id 和 $upstream_http_x_request_id

单靠入口生成的 $request_id 只能标识“网关收到了什么”，无法验证后端是否真正接收并使用了它。而 $upstream_http_x_request_id 是 Nginx 从上游响应头里自动提取的字段——只要后端服务在响应中写了 X-Request-ID，Nginx 就能拿到它。两者并存，才能做一致性比对：

• 若两者相同，说明 ID 成功透传且未被篡改或覆盖
• 若 $upstream_http_x_request_id 为空，说明后端未返回该 header，需检查日志注入逻辑
• 若两者不同（且后端确认未主动重写），可能中间有代理层修改或 header 被截断

在 log_format 中正确引用这两个变量

在 http 块中定义日志格式时，将两个变量都纳入，便于后续日志分析平台关联和比对：

log_format trace_log '$remote_addr - $remote_user [$time_local] ' '"$request" $status $body_bytes_sent ' '"$http_referer" "$http_user_agent" ' '$request_id ' '$upstream_http_x_request_id ';

然后启用该格式：

access_log /var/log/nginx/access-trace.log trace_log;

这样每条日志末尾会输出类似：7a2b3c4d-... - 7a2b3c4d-...（一致）或 7a2b3c4d-... - -（后端未返回）。

Upload audio to AIOZ Stream

快速上传音频至 AIOZ Stream API。支持默认或自定义编码配置创建音频对象，上传文件并完成处理后返回音频链接。

下载

用 Nginx map 实现透传链路完整性校验

可以借助 map 指令构造一个校验字段，让日志自带“透传状态”语义：

map $upstream_http_x_request_id $trace_status { default "ok"; "" "missing"; }
log_format audit_log '$request_id $trace_status $upstream_http_x_request_id';

这样日志中直接出现 7a2b3c4d-... ok 7a2b3c4d-... 或 7a2b3c4d-... missing -，审计人员无需二次解析即可识别异常环节。

配合后端日志做反向验证

后端服务应在处理完请求后，主动在响应头中回写接收到的 X-Request-ID（即使不做业务逻辑处理，也应原样 echo）。例如 Spring Boot 可在拦截器中添加：

response.setHeader("X-Request-ID", MDC.get("request_id"));

这样网关日志里的 $upstream_http_x_request_id 就不是“后端随便生成的 ID”，而是明确表明“后端已收到并认可该链路标识”。结合后端结构化日志中的 request_id 字段，就能完成端到端的可审计闭环。