Nginx 通过 $request_id 变量（≥1.11.0）生成唯一 UUID 并用 proxy_set_header X-Request-ID 透传，后端需优先读取并复用该 ID 实现全链路追踪，兼容无头请求可借助 map 指令 fallback。
要在 Nginx 中通过 proxy_set_header X-Request-ID 支持全链路追踪，核心是确保每个请求在入口处生成唯一 ID，并透传给后端服务，再由后端服务继续向下游传递。Nginx 本身不生成 ID，需借助模块或变量配合实现。
启用 ngx_http_realip_module 并确保 $request_id 可用
Nginx 自带的 $request_id 变量（从 1.11.0 开始引入）会在每个请求初始化时自动生成一个唯一 UUID（如 9e4d7a2c5b1f4a8e9c0d1e2f3a4b5c6d），无需额外安装模块，但需确认你使用的 Nginx 版本 ≥ 1.11.0：
- 运行
nginx -v检查版本 - 若版本过低，需升级或改用
map + $pid + $msec + $connection组合模拟唯一性（不推荐用于生产追踪）
在 proxy_pass 前设置 X-Request-ID 请求头
在 location 或 upstream 配置块中添加如下指令，将 Nginx 内置 ID 注入请求头：
location / {
proxy_set_header X-Request-ID $request_id;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_pass https://www.php.cn/link/65b5b8d1f89bf53a5713bc3afdd83e9e;
}⚠️ 注意：proxy_set_header 必须写在 proxy_pass 之前，否则不生效；且该 header 仅对本次转发有效，不会自动继承到下一级代理（需后端服务主动读取并复用）。
与后端服务协同：透传而非覆盖
全链路追踪依赖 ID 在整个调用链中保持一致。因此后端服务（如 Go/Java/Python 应用）需做到：
- 优先读取上游传来的
X-Request-ID，而非自己新生成 - 在调用下游服务时，将该 ID 作为
X-Request-ID再次透传 - 日志、监控、链路系统（如 Jaeger、SkyWalking）均以该 ID 为 traceId 关联各环节
例如，在 Spring Cloud Gateway 中可配置 GlobalFilter 自动提取并透传；在 Gin 中可用中间件检查 c.Request.Header.Get("X-Request-ID") 并设入 context。
可选：兼容无 X-Request-ID 的上游请求
若部分流量可能绕过 Nginx（如直连测试），可在 Nginx 中补充 fallback 逻辑：
map $http_x_request_id $req_id {
"" $request_id; # 若上游没传，用 Nginx 自己的
default $http_x_request_id; # 否则沿用上游的
}
<p>server {
location / {
proxy_set_header X-Request-ID $req_id;
proxy_pass <a href="https://www.php.cn/link/65b5b8d1f89bf53a5713bc3afdd83e9e">https://www.php.cn/link/65b5b8d1f89bf53a5713bc3afdd83e9e</a>;
}
}这样既支持“边缘生成”，也支持“源头注入”，提升链路完整性。
