$request_id是nginx 1.11.0+原生内置变量，每次请求自动生成32位十六进制唯一id，无需模块或lua；需用proxy_set_header x-request-id $request_id透传，并在log_format中直接记录$request_id确保日志不为空。
$request_id 是 Nginx 1.11.0+ 原生支持的内置变量，无需编译模块、无需 Lua，直接配置就能用；低版本（如 1.10.x）才需要额外处理。
确认 Nginx 版本是否原生支持 $request_id
执行 nginx -v 查看版本。若输出为 nginx version: nginx/1.11.0 或更高，$request_id 已就绪，无需任何初始化 —— 它在每个请求进入 worker 时自动产生一个 32 位十六进制字符串（如 e9a8b7c6d5f4a3b2c1e0f9d8a7b6c5d4）。
常见误判点：
- 看到
nginx -V输出里没出现set_misc或lua模块，就以为不支持 —— 错，$request_id属于ngx_http_core_module，只要版本够，它就在 - 在
log_format中写$http_x_request_id却发现日志里为空 —— 因为客户端根本没带这个头，应改用$request_id直接落盘
proxy_set_header X-Request-ID $request_id 的正确写法
这是透传 ID 到后端服务的核心动作，必须放在 location 或 server 块内，且需确保下游能接收并解析该 header。
典型配置片段：
location /api/ {
proxy_set_header X-Request-ID $request_id;
proxy_set_header X-Trace-ID $request_id;
proxy_pass http://backend;
proxy_set_header Host $host;
}
注意点：
-
proxy_set_header必须在proxy_pass之前，否则无效 - 不要写成
proxy_set_header X-Request-ID "$request_id"—— 双引号在部分旧版 Nginx 中会触发变量不展开 - 若后端是 Spring Boot，默认不读
X-Request-ID，需配合 Filter + MDC 手动提取并注入日志上下文 - 多个 upstream 时，每个
location都要单独配，http块里全局写无效（Nginx 设计如此）
access_log 中稳定记录 request_id 的两种方式
日志是链路追踪的第一手证据，必须确保 Nginx 自身日志里有可靠、非空的 ID 字段。
推荐方案（直接使用 $request_id）：
log_format main '$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent" "$request_id"';
不推荐方案（依赖 $http_x_request_id）：
log_format bad '$http_x_request_id'; # 客户端不带该 header 时，这一段就是空字符串
关键差异：
-
$request_id每次请求必生成，100% 可靠 -
$http_x_request_id是从请求头读取的，客户端或上游代理没传，就为空，导致日志断链 - 如果同时想记录原始 header（用于调试是否被篡改），可加一列：
"$http_x_request_id"，但主链路 ID 必须用$request_id
request_id 在跨服务调用中容易丢失的三个环节
即便 Nginx 配对了，ID 仍可能在后续链路中消失，常见于：
- 后端服务发起 HTTP 调用时，未将
X-Request-ID显式复制到新请求头中（例如 Go 的http.NewRequest不自动继承 header） - 消息队列（如 Kafka/RabbitMQ）生产消息时，没把
request_id写入消息 headers 或 payload 字段，导致消费端无法关联 - 异步任务（如 Celery、Sidekiq）从 HTTP 上下文派生出后台 job，但未显式传递 ID，导致 job 日志无链路标识
这些环节都得靠业务代码主动携带，Nginx 只管第一跳。最易被忽略的是：Nginx 日志里 ID 存在，但后端某次 RPC 调用后，下游服务日志里突然没了这个 ID —— 往往就是 header 透传漏写了。
