$request_id在Nginx 1.11.0+是开箱即用的内置变量，无需额外模块或Lua脚本，只需版本达标、location块内配置proxy_set_header X-Request-ID $request_id并记录于log_format，即可生成唯一32位十六进制ID并透传下游，构成轻量级全链路追踪起点。
直接说结论：$request_id 在 Nginx 1.11.0+ 是开箱即用的内置变量，不用装模块、不需 Lua 脚本，只要版本够、配置对，就能生成唯一 ID 并透传到下游服务——这是实现轻量级全链路追踪最省力的起点。
确认 Nginx 版本是否支持 $request_id
低于 1.11.0 的 Nginx 不带这个变量，强行写 $request_id 会导致启动失败或日志中显示空值。
- 执行
nginx -v查看版本；若输出是nginx version: nginx/1.10.3这类，必须升级 - 1.11.0+ 不需要
load_module或set_by_lua，直接在配置里用就生效 - 验证是否真可用：在
log_format中加入$request_id，重启后查 access 日志，看字段是否稳定输出 32 位十六进制字符串（如a1b2c3d4e5f678901234567890abcdef）
proxy_set_header X-Request-ID $request_id 必须放在 location 块内
很多人把这行丢在 http 或 server 块顶层，结果 downstream 拿不到——Nginx 的 proxy_set_header 只在 location 级别生效，且仅对该 location 下的 proxy_pass 生效。
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 错误写法：
http { proxy_set_header X-Request-ID $request_id; }→ 无效 - 正确写法：
location /api { proxy_set_header X-Request-ID $request_id; proxy_pass http://backend; } - 如果用了多个 upstream，每个
location都得单独配，不能靠继承 - 若后端服务同时接收来自其他网关（如 API Gateway）的请求，建议统一 header 名为
X-Request-ID，避免混用X-Trace-ID或traceparent导致解析错乱
日志格式中必须显式记录 $request_id，别依赖 $http_x_request_id
$http_x_request_id 是从客户端请求头读的，不是 Nginx 自己生成的 ID。如果前端没带、或者被中间层清掉了，这个变量就是空，但 $request_id 永远有值。
- 推荐 log_format：
log_format main '$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent" req_id:"$request_id"'; - ELK 场景下，这个字段要和后端日志里的
requestId字段对齐，才能用 Kibana 的Discover或Search跨服务关联 - 别漏掉引号 ——
req_id:"$request_id"比req_id:$request_id更利于 Logstash 的 grok 解析，避免十六进制字符串被截断或误识别
下游服务必须主动读取并延续 X-Request-ID，Nginx 不会自动“续命”
Nginx 只管发出去，不管下游怎么用。如果后端没提取、没注入日志、没透传给下一级调用，那这条链就断在第一跳。
- Spring Boot：用
Filter+MDC.put("requestId", request.getHeader("X-Request-ID"))，再在logback-spring.xmlpattern 里加%X{requestId} - Go Gin：中间件中用
c.Request.Header.Get("X-Request-ID")获取，写入zerolog.Ctx(c.Request.Context()).Str("request_id", id) - 关键细节：所有出站 HTTP 请求（比如调第三方 API），必须手动把当前
X-Request-ID复制到新请求的 header 里，否则链路在第二跳就消失了 - Zipkin/Jaeger 后端默认不认
X-Request-ID，需在服务端做映射（例如 Spring Cloud Sleuth 会自动 fallback 到该 header 作为 traceId）
最容易被忽略的一点：ID 全程不变 ≠ 链路完整。即便 Nginx 和第一个后端都打了 ID，只要第二个服务发起 RPC 时没透传、MQ 消费时没携带、异步任务没继承上下文，那这个 ID 就只是半截链条。真正闭环，靠的是每一跳都主动接住、记录、再扔出去。
