nginx 不会直接记录 header 丢失，需通过后端报错（如“missing access_token”）、curl 模拟、access_log 中 $http_authorization 等变量为空、underscores_in_headers on 配置缺失或位置错误（须在 http/server 块）、未显式 proxy_set_header 透传等线索综合排查。
直接看 Nginx 错误日志本身，通常 不会直接记录“某个 header 丢失”，因为 header 丢失不是错误事件，而是静默行为。真正要查的，是通过日志线索反推 header 是否缺失，再结合配置和测试验证。
确认后端报错是否与 header 相关
先排除其他原因：后端日志里如果明确提示类似 "missing access_token"、"Origin not provided"、"Authorization header empty"，就高度指向 header 未送达。此时再回头查 Nginx 配置和日志才有意义。
- 用
curl -v -H "Authorization: Bearer xxx" http://your-nginx/api/test模拟请求，同时抓取后端收到的实际 header（如打印request.headers）做比对 - 在 Nginx 的
log_format中加入关键 header 变量，例如：log_format main '$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent" "$http_authorization" "$http_origin" "$http_access_token"'; - 重启 Nginx 后访问，再查
access.log—— 如果某项（如$http_authorization）始终为空，而 curl 明确带了，说明它在进 Nginx 时就被过滤或没传进来
重点检查 underscores_in_headers 配置位置
带下划线的 header（如 access_token、x_api_key）会被 Nginx 默认丢弃，且不报错、不记录。这是最隐蔽的丢失原因。
- 必须在
http{}或server{}块顶层启用：underscores_in_headers on; - 不能放在
location{}里——放了也无效 - 启用后仍需在 location 中显式透传：
proxy_set_header access_token $http_access_token;
验证 Host、Authorization 等关键头是否被覆盖
Nginx 默认不自动转发所有 header；很多关键头需要手动设置，否则就是空的。
- Host 头错写成
$host（客户端发的）而非$proxy_host（后端期望的），可能导致后端路由失败或权限拒绝 - Authorization 默认不透传，必须加：
proxy_set_header Authorization $http_authorization; - 确保
proxy_pass_request_headers on;已开启（默认是 on，但显式写出更稳妥）
借助 error.log 辅助定位间接线索
虽然 error.log 不记 header 丢失，但能暴露关联问题：
- 出现
upstream sent too big header→ 说明响应头过大，可能触发了缓冲区截断，连带头部解析异常 - 出现
client intended to send too large body→ 请求体被拦，有时也伴随 header 解析中断 - 大量
connect() failed (111: Connection refused)→ 后端根本没收到请求，说明转发链路中断，header 自然无法抵达
