nginx 通过 $request_id 变量自动生成唯一 id 并用 proxy_set_header x-request-id $request_id 透传至上游，支持全链路追踪；若客户端已提供则优先使用 map 指令实现“有则用之、无则生成”，确保多级代理下 id 一致。
在 Nginx 作为反向代理时，可通过 proxy_set_header 指令为上游服务添加 X-Request-ID 请求头，实现全链路追踪的标识传递。关键在于生成唯一 ID 并确保它在请求生命周期内保持一致（例如同一请求经过多级代理时不重复生成）。
使用 $request_id 自动生成唯一 ID
Nginx 内置变量 $request_id 在每个请求开始时自动生成一个 16 字节的随机十六进制字符串（如 1a2b3c4d5e6f7g8h），天然适合作为全链路追踪 ID。它在请求整个生命周期中稳定不变，即使启用 gzip、chunked 编码或被多个 location 处理也保持一致。
只需在 proxy 配置块中添加：
location / {
proxy_pass http://backend;
proxy_set_header X-Request-ID $request_id;
}若上游已带 X-Request-ID，优先透传而非覆盖
为支持多级代理链路（如 CDN → Nginx → Service），应避免覆盖已有 ID。Nginx 不支持条件式 proxy_set_header，但可用 map 指令构造“有则用之、无则生成”的逻辑：
在 http 块中定义：
map $http_x_request_id $pass_request_id {
"" $request_id; # 客户端未提供时，用 Nginx 自生成
default $http_x_request_id; # 客户端/上游已提供，则直接透传
}然后在 location 中使用：
proxy_set_header X-Request-ID $pass_request_id;
确保下游服务能正确接收并透传该头
仅设置 proxy_set_header 不够——还需确认上游服务（如 Node.js、Java Spring Boot）未过滤该头，且其自身转发请求时也携带它。常见问题包括：
- 后端框架默认不透传自定义 header（如 Spring Cloud Gateway 需配置
spring.cloud.gateway.globalcors.add-to-preflight-response-headers或显式设置路由 filter） - 某些语言客户端库（如 Python requests）默认不发送非标准 header，需显式启用
- 若启用 HTTPS 终止，确保 SSL 配置不影响 header 传递（一般无影响）
验证是否生效
部署后可通过 curl 直接测试：
curl -H "X-Request-ID: abc123" -I http://your-nginx-domain/api/test
检查响应头或后端日志中是否收到 X-Request-ID；也可临时在 upstream 服务中打印所有 headers 做确认。注意：浏览器开发者工具的 Network 标签页通常不显示 request headers 的自定义字段，建议用 curl 或后端日志验证。
