排查Nginx请求头问题核心是“看到头、留住头、对上头”：先确认客户端原始头是否传入Nginx，再检查proxy_set_header是否显式透传或改写，最后验证后端是否收到预期值，并通过增强日志（含$http_x_*等变量）反向比对全链路头信息。
排查 Nginx 转发请求头问题，核心是“看到头、留住头、对上头”——即确认客户端原始头是否传入、Nginx 是否正确透传或改写、后端是否收到预期值，再通过日志反向验证。不需要额外装工具，Linux 原生命令 + 合理日志配置就能闭环定位。
一、确认关键请求头是否真正到达 Nginx
很多问题根源在最前端：客户端或上游代理根本没发某个头（比如 X-Real-IP 或 X-Forwarded-For），Nginx 自然无法转发。
- 用 curl -v 模拟请求，显式带自定义头测试：
curl -v -H "X-Trace-ID: abc123" http://your-domain.com/api/test - 检查 Nginx access_log 中是否记录该头内容，需确保 log_format 包含
$http_x_trace_id等变量 - 若日志为空，说明头未送达；若 curl 命令中加了但日志没出现，检查是否被防火墙、WAF 或中间 LB 清洗掉了
二、验证 Nginx 是否按配置透传或重写请求头
Nginx 默认不透传所有客户端头，必须显式用 proxy_set_header 声明。常见错误包括漏配、覆盖、误用 $http_ 变量名。
- 检查 location 或 upstream 块中是否有类似配置：
proxy_set_header X-Forwarded-For $http_x_forwarded_for;proxy_set_header X-Real-IP $remote_addr; - 注意：
$http_x_forwarded_for是客户端发送的原始值，$remote_addr是直连 IP；若前端有可信代理，建议用set_real_ip_from+real_ip_header X-Forwarded-For替代手动赋值 - 用 curl -I 查看响应头中是否返回了你设置的头（如
X-Request-ID），可快速验证add_header是否生效
三、从日志中提取并比对转发链路头信息
启用增强日志格式后，一条请求的日志能同时反映“来路”和“去向”，是排查头丢失/篡改的关键证据。
- 推荐日志格式片段（加到 http 块）：
log_format full '$remote_addr - $http_x_forwarded_for [$time_local] "$request" $status $body_bytes_sent ' '"$http_referer" "$http_user_agent" ' 'req_id="$request_id" ' 'x_real="$http_x_real_ip" ' 'x_fwd="$http_x_forwarded_for" ' 'upstream="$upstream_addr" ' 'up_resp="$upstream_http_x_trace_id"'; - 用 awk 提取某次请求的完整头流转：
grep "abc123" /var/log/nginx/access.log | awk '{print $1, $5, $10, $11, $12}'
输出示例：192.168.1.100 - [24/Sep/2026:23:10:05 +0800] req_id="a1b2c3" x_real="203.0.113.5" x_fwd="203.0.113.5, 192.168.1.50" - 若
$upstream_http_x_trace_id有值，说明后端已返回该头；若为空但$request_id存在，说明后端没生成或没透传，问题出在下游
四、结合错误日志与状态码缩小范围
请求头异常常引发特定错误，不能只盯 access.log。
- 搜索 502/503 错误，配合
$upstream_addr字段看是否固定某台后端失败：awk '$9 == 502 {print $13}' /var/log/nginx/access.log | sort | uniq -c - 查 error.log 中是否报 “no resolver defined”，这往往因
proxy_pass使用域名但未配 resolver，导致 DNS 解析失败，头根本没发出去 - 遇到 400 Bad Request，重点检查
Host、Content-Length、Transfer-Encoding是否被意外改写或缺失
