nginx 默认禁用下划线请求头解析，需在http或server块中配置underscores_in_headers on；配置后注意变量命名冲突、哈希性能及后端兼容性，生产环境建议推动客户端改用连字符标准命名。
要让 Nginx 正确接收带下划线的请求头（比如 X_User_ID、Auth_Token），同时避免因 header 处理不当引发哈希冲突或性能下降，关键不在“开开关”本身，而在于配置位置、作用范围和配套优化。默认关闭是安全设计，开启后若不注意细节，反而可能引入变量覆盖、无效 header 重复计算等隐性开销。
必须在 http 或 server 块中启用，禁用 location 级配置
指令 underscores_in_headers on 只允许出现在 http 或 server 上下文中，不能写在 location 里——Nginx 会直接报错。生产环境建议统一放在 http 块顶层，确保所有虚拟主机一致生效，也便于后续审计：
- 编辑
nginx.conf，在http { ... }内添加一行：underscores_in_headers on; - 不要为每个
server单独配，除非明确需要隔离策略（如部分服务严格遵循 RFC） - 配置后需重载（
nginx -s reload），而非重启，避免连接中断
避免 location 内高频操作加剧哈希压力
启用下划线支持后，Nginx 会把所有含下划线的 header 原样解析并生成对应变量（如 $http_x_user_id）。但若在大量 location 中反复使用 add_header 或 proxy_hide_header，每次都会触发额外的哈希键构建与比对，容易放大哈希桶冲突，尤其在高并发 header 种类多时：
- 把通用 header 操作（如统一加
X-Request-ID）提到server或http块，减少重复计算 - 慎用
proxy_hide_header隐藏非必要响应头，它会强制重建 header 列表，影响 proxy_pass 路径哈希效率 - 若只需透传某几个带下划线的请求头给后端，优先用
proxy_set_header显式设置，而非依赖自动映射
注意变量命名冲突与后端兼容性
即使启用了该选项，Nginx 内部仍按“小写 + 下划线替代连字符”规则生成变量名。这意味着 X-User-ID 和 X_User_ID 会映射到同一个 $http_x_user_id，后者覆盖前者——这不是 bug，而是设计行为：
- 检查客户端实际发送的 header 名：用
curl -v或日志log_format中加入$http_x_user_id验证是否命中 - 后端服务（如 Spring Boot、FastAPI）需确认是否原生支持下划线 header；Go 的
net/http默认转下划线为连字符，可能收不到预期值 - 临时调试可用：
add_header X-Debug-X-User-ID "$http_x_user_id";输出到响应头，确认值存在且未被截断
不建议公网全局开启，优先推动客户端改用标准命名
从协议演进看，RFC 7230 已明确允许下划线，但 Nginx 保留默认 off 是出于历史兼容与安全兜底。真实风险不在于功能本身，而在于：
- 恶意构造如
Content_Length（注意大小写+下划线）可能干扰请求体长度解析 - 部分 WAF、API 网关或 CDN 会将含下划线 header 视为异常流量直接拦截
- 长期依赖该配置会阻碍服务向标准 header（
x-api-key、x-request-id）收敛
所以更可持续的做法是：内部测试环境开启验证逻辑，同步推动客户端将 X_User_ID 改为 X-User-ID，既符合 RFC，又免去配置维护成本。
