要记录Nginx反向代理完整交互日志，需注入可追溯的代理路径头（如X-Forwarded-By、X-Proxy-Path），扩展access_log格式捕获$upstream_addr等关键字段，并区分HTTP与TCP代理的日志机制，最后通过curl测试和nginx -t验证配置准确性。
要记录 Nginx 反向代理过程中的完整交互日志，核心是把“请求从哪来、经过哪几层、发给谁、改了什么、响应如何”这些关键链路信息都捕获下来。不是只记客户端访问，而是让每条日志能还原一次完整的代理旅程。
注入可追溯的代理路径头
在每次代理转发时，用 proxy_set_header 主动添加标识性请求头，形成逐跳累积的路径链：
- 用
X-Forwarded-By "$hostname"标记当前代理节点名（如edge-lb），比 IP 更易识别和维护 - 用
X-Proxy-Path "$http_x_proxy_path, $hostname"实现路径叠加，下游收到后会看到类似edge-lb, api-gw, svc-user的完整跳转序列 - 若需关联上游服务身份，配合
map指令将$upstream_addr（如10.2.3.4:8080）映射为服务名（如user-service-v2），避免日志里全是难读的 IP+端口
扩展 access_log 格式，捕获代理关键字段
默认日志不包含上游信息，必须自定义 log_format 并启用它：
- 在
http块中定义格式，例如：log_format trace '$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent" "$upstream_addr" "$upstream_http_x_trace_id" "$http_x_proxy_path"'; - 关键变量说明：
$upstream_addr记录实际转发到的上游地址；$upstream_http_x_trace_id提取上游返回的 trace ID（需后端配合输出）；$http_x_proxy_path读取客户端或上一层传来的路径标记 - 在
server或location中启用：access_log /var/log/nginx/trace.log trace;
区分 HTTP 与 TCP 代理的日志机制
HTTP 和 TCP 层代理的日志行为不同，不能混用配置：
- HTTP 代理日志在每次请求结束时立即写入，可记录 URI、状态码、响应时间等细粒度字段
- TCP 代理需在
stream块中单独配置日志格式，例如：log_format proxy '$remote_addr [$time_local] $protocol $status $bytes_sent $bytes_received "session_time:$session_time" "$upstream_addr"'; - TCP 日志是 session 级别的，只有连接断开后才落盘，且不包含应用层内容（如 HTTP 路径或 header），内部通信需由业务应用自行打点
验证与调试建议
配置生效后，别只看日志有没有生成，重点确认内容是否准确：
- 用
curl -H "X-Proxy-Path: init"手动发起测试请求，检查日志中X-Proxy-Path是否被正确追加 - 查看
$upstream_addr是否显示真实后端地址，而非-或空值（常见于proxy_pass写错或未命中 upstream） - 重启后执行
nginx -t验证语法，并用tail -f实时观察日志输出，避免配置未加载
