核心是用 Nginx 原生 $request_id 变量（≥1.11.0 版本自动生成 32 位小写十六进制 ID），在 log_format 中显式记录、通过 proxy_set_header X-Request-ID $request_id 透传至后端，并确保各服务复用该 ID 实现全链路日志聚合检索。
在 Nginx 日志中记录请求的唯一 Trace ID，核心是**让这个 ID 从入口就稳定存在、不被客户端干扰、全程可追溯**。最推荐的方式是直接使用 Nginx 原生的 $request_id 变量——它从 1.11.0 版本起内置支持，每次请求自动生成一个 32 位小写十六进制字符串（如 a1b2c3d4e5f678901234567890abcdef），无需 Lua、无需额外模块。
确保 Nginx 版本支持并启用 $request_id
执行 nginx -v 确认版本 ≥ 1.11.0。低于该版本会把 $request_id 当作普通字符串处理，日志中显示为空或字面值。升级后无需任何加载模块操作，变量即开即用。
- 检查是否生效：临时在
log_format中加入$request_id，重启 Nginx 后查 access.log，确认每行开头都有稳定的 32 位 hex 字符串 - 避免混淆：
$http_x_request_id是从客户端读取的，可能为空、被篡改、格式不一；而$request_id由 Nginx 自主生成，始终可信、唯一、存在
在日志格式中显式记录 $request_id
必须在 http 块中定义含 $request_id 的日志格式，并用引号包裹，防止空格或特殊字符导致解析异常：
log_format trace '$request_id - $remote_addr [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent"';
然后在 server 或 location 块中启用：
linux-performance-analyzer
下载
Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。
access_log /var/log/nginx/access.log trace;- 不要只依赖默认
combined格式，它不含$request_id
透传到下游服务，保持链路不断
仅记录不够，必须让后端服务也能拿到同一 ID 并复用。关键配置在 location 块内（proxy_set_header 不在 http 或 server 顶层生效）：
proxy_set_header X-Request-ID $request_id;- 若上游已带
X-Request-ID（如 API 网关），应优先复用而非覆盖：map $http_x_request_id $forwarded_id { "" $request_id; default $http_x_request_id; }
再写proxy_set_header X-Request-ID $forwarded_id; - 确保
underscores_in_headers on;已加在http块开头，否则 Nginx 默认忽略含下划线的自定义 header
验证链路是否真正贯通
配置完不能假设成功，必须实测：
- 用
curl -I http://your-domain/api查响应头，确认返回了X-Request-ID，且值与 access.log 中对应行的$request_id完全一致 - 检查 Nginx error.log 是否有
upstream sent too big header报错——可能是透传 header 导致响应头超长，需调大large_client_header_buffers - 后端服务（Spring Boot/Go/Node.js）必须实际读取该 header，并注入日志上下文（如 MDC、Zap 字段），而不是自行生成新 ID
拿到用户投诉对应的 $request_id 后，不是只查 Nginx 日志，而是并行搜索所有环节：WAF 拦截日志、限流模块、应用错误日志、数据库慢查询日志——只要它们都记录了同一个 X-Request-ID 字段，就能一键聚合还原完整链路。
