proxy_pass_request_headers 控制客户端请求头是否透传给后端，on 时默认透传标准头（不含下划线头），off 时仅传递 nginx 显式设置的头；需配合 underscores_in_headers on 才能透传 x_user_id 类自定义头。

proxy_pass_request_headers 是 Nginx 控制客户端请求头是否批量透传给后端的开关指令，用法极简但影响深远。它不用于“过滤”或“重写”，只决定是否启用默认透传机制——开启后，Nginx 会把客户端发来的绝大多数标准请求头（如 User-Agent、Accept、Authorization）原样转发；关闭后，则仅传递 Nginx 自身生成或显式设置的头（如 proxy_set_header 定义的），原始头全部丢弃。

直接控制透传行为：on 或 off

该指令只有两个取值，无需复杂配置：

• proxy_pass_request_headers on;
  默认行为，无需显式书写。此时 Nginx 会透传常见 RFC 标准头，但仍不透传含下划线的头（如 X_User_ID）或部分非标头（如 X-Trace-ID），这些需额外配合 underscores_in_headers on 或 proxy_set_header 显式处理。

• proxy_pass_request_headers off;
  彻底禁用原始请求头透传。适合高安全场景，例如：

  • 后端完全不依赖客户端头，所有上下文由 Nginx 统一注入；
  • 需严格防止 Origin、Referer、Authorization 等敏感头被意外转发；
  • 配合 proxy_set_header 构建干净、可控的请求环境。

关键注意事项：它不解决“自定义头丢失”问题

很多人误以为关掉再打开就能修复 X-User-Token 拿不到的问题，其实不能：

FastAPI Flask Proxy

FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。

下载

• proxy_pass_request_headers off 会让所有原始头消失，包括你想要的 X-User-Token；
• proxy_pass_request_headers on（默认）也不能让 X_User_Token 出现——因为下划线头默认被忽略，必须加 underscores_in_headers on; 才行；
• 即使开了 on，Nginx 也不会透传空值或非法格式的头，也不会恢复已被 proxy_hide_header 影响的响应头（那是响应阶段的事）。

推荐组合用法（兼顾安全与可用）

若业务需要部分自定义头 + 防御恶意头，不建议全开或全关，而是：

• 保持 proxy_pass_request_headers on;（默认即可）；
• 显式覆盖关键头，避免风险透传：

  proxy_set_header Host $host;
  proxy_set_header X-Real-IP $remote_addr;
  proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
  proxy_set_header X-Forwarded-Proto $scheme;
  proxy_set_header Origin "";      # 清空原始 Origin，由 Nginx 控制 CORS
  proxy_set_header User-Agent "";   # 减少指纹暴露

• 对含下划线的自定义头，确保全局或 location 级开启：

  underscores_in_headers on;

这样既保留必要信息，又主动剥离/重写高风险字段，比单纯开关更可靠。