nginx worker process 不实现链路追踪，而是通过内置 $request_id 变量（1.11.0+）自动生成、透传（proxy_set_header）、记录（log_format）和条件提取，支撑单请求链路锚定；它不生成 span、不上报、不维护上下文树。
Nginx 的 Worker Process 本身不主动实现链路追踪，它只是执行配置逻辑的轻量级进程。真正的请求链路追踪能力，来自 Nginx 配置层对 $request_id 的稳定生成、透传与记录——而这些操作由 Worker Process 在处理每个请求时自动、无感地完成。
换句话说：Worker Process 是载体，不是追踪引擎；它靠内置机制支撑追踪，而非自己“做追踪”。
$request_id 是 Worker Process 内部天然支持的请求标识
从 Nginx 1.11.0 起，$request_id 是 core 模块提供的请求级变量，每个请求进入 worker 后即生成唯一值（32 位小写十六进制字符串），生命周期覆盖该请求全部阶段（包括子请求、重试、内部重定向）：
- 生成时机：请求解析完成、尚未进入 location 匹配前
- 作用范围：仅限当前请求上下文，不跨请求、不跨 worker 共享，但完全满足单次请求链路锚定需求
- 稳定性：不受 upstream 失败、proxy_redirect、rewrite 等影响，始终一致
✅ 不需要
set_by_lua、不依赖ngx_http_random_module、也不用map模拟——只要版本 ≥1.11.0，直接引用即可。
Worker Process 如何“参与”链路构建？
它通过三类标准行为，把 $request_id 变成链路起点：
-
透传给后端服务
在location块中配置：proxy_set_header X-Request-ID $request_id;
→ Worker Process 将该变量值作为 HTTP Header 注入转发请求，确保下游拿到原始 ID。
-
写入访问日志
自定义log_format显式包含：log_format trace '... req_id:"$request_id" upstream:"$upstream_addr"';
→ Worker Process 在记录日志时自动填充，形成入口时间、目标地址、唯一 ID 三元组。
-
支持 header 提取与条件判断
例如用map复用客户端 ID 或兜底生成：map $http_x_request_id $trace_id { "" $request_id; default $http_x_request_id; }→ Worker Process 在变量解析阶段完成匹配，无需额外模块。
注意：Worker Process 不做这些事
- ❌ 不生成 span、不上报 Jaeger/OTel Collector（需 Lua + HTTP client，且影响性能）
- ❌ 不维护上下文树、不关联 parent/child 关系（那是 OpenTracing SDK 的职责）
- ❌ 不跨 worker 或跨机器保证 ID 全局唯一（集群级一致性需前置网关或统一 UUID v4 生成策略）
实际效果取决于配置是否落地到每个 worker
- 所有 worker 进程共享同一份配置，因此只要
nginx.conf正确，每个 worker 行为一致 - 若某台机器漏配
proxy_set_header或日志格式未含$request_id，对应 worker 处理的请求就会断链 - Kubernetes 中若使用
nginx-ingress，需确认 controller 版本 ≥1.9 并开启enable-request-id: "true"，否则 ingress controller 的 worker 不会注入该头
链路追踪在 Nginx 层的本质，就是让每个 worker 在处理请求时，稳稳地“拿一个 ID、传一次、记一笔”。不复杂，但容易忽略细节。
