nginx 日志记录请求链路 id 的关键是确保 $request_id 稳定生成、可靠落盘、格式统一且不受客户端干扰；需版本 ≥1.11.0，log_format 中显式使用 "$request_id"（非 $http_x_request_id），引号包裹防解析错误，并与后端日志字段名及 32 位小写 hex 格式对齐。
Nginx 日志记录请求链路 ID 的关键，不是加个字段就完事，而是确保 $request_id 稳定生成、可靠落盘、格式统一，且不被客户端干扰。
确认 Nginx 版本支持 $request_id
该变量从 1.11.0 起原生内置，无需模块或 Lua。执行 nginx -v，输出必须是 nginx/1.11.0 或更高（如 nginx/1.22.1）。低于此版本会把 $request_id 当作普通字符串处理，日志中显示为空或字面量。
在 log_format 中显式写入 $request_id
不要用 $http_x_request_id（它来自客户端，可能为空、被清空或被伪造），而应直接使用 Nginx 自生成的 $request_id，它始终存在、唯一、稳定。
推荐配置（放在 http 块内）：
log_format main '$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent '
'"$http_referer" "$http_user_agent" req_id:"$request_id"';
access_log /var/log/nginx/access.log main;
注意引号包裹："$request_id" 而非 $request_id，避免 Logstash/Grok 解析时将 32 位十六进制串截断或误拆为多个字段。
验证是否生效
重启 Nginx 后访问接口，检查 access.log 是否持续输出形如 req_id:"e9a8b7c6d5f4a3b2c1e0f9d8a7b6c5d4" 的字段。若字段为空、重复、或显示为字面量 $request_id，说明版本不达标或配置未加载。
多 location 场景下保持一致性
每个 location 不影响日志格式定义，但若你同时记录上游返回的 ID（用于透传验证），可追加 $upstream_http_x_request_id 字段：
log_format main '... req_id:"$request_id" upstream_req_id:"$upstream_http_x_request_id"';
该字段仅在 proxy_pass 成功后才有值，适合排查透传是否中断。
与后端日志对齐是追踪前提
Nginx 日志里的 req_id 字段名、值格式（32 位小写 hex）、长度，必须和后端服务日志中的对应字段（如 request_id、trace_id）完全一致。ELK 或 Loki 中才能用同一关键词跨服务搜索。
不复杂但容易忽略
