Nginx 1.11.0+ 默认支持 $request_id，通过 proxy_set_header X-Request-ID $request_id 透传，并配合 log_format 和下游服务适配，可实现轻量级全链路追踪。
在 Nginx 接入层生成并透传 $request_id 是实现轻量级全链路追踪的关键起点。它不依赖额外模块，也不要求后端服务立即改造，就能为 Zipkin 或 Jaeger 提供可靠的 trace 上下文锚点。
确保 Nginx 版本与 request_id 可用性
Nginx 1.11.0+ 默认启用 $request_id，无需手动加载模块或初始化。确认方式很简单：
- 执行
nginx -v查看版本，若低于 1.11.0，需升级 - 在配置中直接使用
$request_id（如写入日志或 header），无报错即表示可用 - 该变量为 32 位十六进制字符串，例如
a1b2c3d4e5f678901234567890abcdef，每次请求唯一且线程安全
在 Nginx 中注入并透传 request_id
只需两处关键配置，即可让 ID 进入下游链路：
- 在
location块中添加：proxy_set_header X-Request-ID $request_id; - 如需兼容 Zipkin/Jaeger 的 OpenTracing 上下文，建议同步透传标准字段：
proxy_set_header traceparent "00-$request_id-0000000000000001-01";（简化版 traceparent，适用于未启用完整 W3C Trace Context 的场景） - 若日志用于原始排查，更新
log_format，加入$request_id字段，便于快速关联
与 Zipkin/Jaeger 后端协同对齐
仅靠 Nginx 透传还不够，需下游服务识别并延续该 ID：
- Spring Boot 项目可借助
spring-cloud-starter-sleuth自动读取X-Request-ID并作为 traceId fallback，无需代码改动 - Go Gin、Node.js 等框架可通过中间件提取 header，并注入到 OpenTelemetry 的
trace.SpanContext中 - Zipkin Collector 或 Jaeger Agent 不会自动解析
X-Request-ID，需在服务端做适配：将该值映射为traceId字段（注意长度对齐：Zipkin 要求 16 字节 hex，$request_id 是 32 字符，可取前 16 位或保持原长并配置后端接受）
验证是否生效
最直接的验证方式是抓包 + 查看链路系统 UI：
- 用
curl -v http://your-api/xxx观察响应头是否含X-Request-ID - 在 Zipkin UI 搜索该 ID（或其子串），确认能否查到对应 trace
- 检查后端服务日志，确认每条日志都带相同 ID，且与 Nginx 日志中的 ID 一致
- 若调用经过多个服务，逐跳比对
X-Request-ID是否全程未变
