应使用 Nginx 内置变量 $request_id（1.11.0+ 自动生成 UUID 或 32 位十六进制字符串），在 log_format 中以 "$request_id" 形式引号包裹并追加至日志格式末尾，配合 access_log 引用该格式、重载配置后验证输出，再与后端统一 request_id 字段实现全链路追踪。
要在 Nginx 的 access_log 中稳定记录请求唯一标识，核心是正确使用内置变量 $request_id，并确保它始终存在、非空、格式统一。
确保 $request_id 可用且可靠
$request_id 是 Nginx 1.11.0+ 内置变量，每次请求进入时自动生成一个 UUID（如 e9a8b7c6-d5f4-a3b2-c1e0-f9d8a7b6c5d4）或 32 位小写十六进制字符串（如 e9a8b7c6d5f4a3b2c1e0f9d8a7b6c5d4）。它不依赖客户端输入，也不受重试影响——只要没显式透传或覆盖，就始终可用。
- 无需额外模块或 map 指令来“生成”它，Nginx 在首次引用
$request_id（比如在log_format或proxy_set_header中）时会自动创建 - 不要用
$http_x_request_id替代——它来自请求头，可能为空、被篡改或格式不一致 - 推荐使用标准 UUID 格式（含连字符），便于日志系统识别和解析
修改 log_format 显式包含 $request_id
在 http 块中定义或更新日志格式，把 $request_id 加入末尾，并用引号包裹提升结构化能力：
Web Accessibility (WCAG 2 AA))
下载
将 WCAG 2 AA 无障碍标准应用于设计系统、UI 组件和网页——通过可运行的验证器进行对比度计算，采用设计 token 模式使颜色天生可访问，设定排版和焦点状态规则，并提供语义检查清单。适用于构建或审查 UI。
log_format main '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for" '
'$request_time "$request_id"';- 引号包裹
"$request_id"可避免十六进制字符串被日志收集器（如 Filebeat、Logstash）误切分 - 字段顺序不影响功能，但建议放在靠后位置，方便后续用
awk或正则提取 - 若已定义其他格式（如
log_format json），同样在对应定义里追加"request_id":"$request_id"即可
启用新格式并验证输出
确保 access_log 指令明确引用刚定义的格式名：
access_log /var/log/nginx/access.log main;
- 路径需有写权限；Windows 下路径为
logs/access.log - 执行
nginx -s reload重载配置（不要用stop/start，避免连接中断） - 发起一次请求后，检查日志文件末尾是否出现形如
"e9a8b7c6-d5f4-a3b2-c1e0-f9d8a7b6c5d4"的字段
与后端日志对齐，支撑链路关联
仅 Nginx 记录 ID 不够，必须让下游服务也输出相同值，才能在 ELK、Loki 等平台按 ID 联查全链路：
- 后端日志中统一字段名，例如都叫
request_id或trace_id - 在 Kibana 或 Grafana 中，可用
request_id: "e9a8b7c6-d5f4-a3b2-c1e0-f9d8a7b6c5d4"直接跨索引搜索 - 若后端用 OpenTelemetry 或 Sleuth，建议 Nginx 同时透传
traceparent头（需合规格式），而非仅靠X-Request-ID
