启用 underscores_in_headers on 即可让 Nginx 接收并透传带下划线的请求头，该指令仅控制是否丢弃非法头，不影响哈希性能，因内部键标准化（小写+连字符转下划线）后哈希检索本就是 O(1)。
直接在 http 块中启用 underscores_in_headers on 即可让 Nginx 接收并透传带下划线的请求头，但“兼顾高性能哈希检索对齐”这个说法存在概念混淆——Nginx 的哈希检索（如变量映射、map 指令、header 解析）本身不依赖下划线是否允许，而是基于标准化后的字段名（小写 + 连字符转下划线）构建内部键。开启该指令不会提升哈希性能，也不会破坏对齐；它只改变“是否丢弃非法头”的行为。
为什么不需要为哈希性能额外配置
Nginx 内部对请求头的处理流程固定：
- 收到原始 header（如
X-User_ID或X_Api_Key）后，先按规则标准化：全部转小写，连字符（-）统一替换为下划线（_）； - 下划线本身保留（启用
underscores_in_headers on时），不被过滤也不被转换； - 标准化后的字符串（如
x_user_id、x_api_key）作为哈希键，用于快速查找对应变量（$http_x_user_id）或匹配 map 规则； - 该哈希过程是 O(1) 均摊复杂度，与是否含下划线无关，也无需手动“对齐”。
正确配置方式（仅需一步）
编辑 nginx.conf，在 http { ... } 块内添加：
✅ 作用范围覆盖全部 server；
✅ 不影响变量哈希效率；
✅ 后端能接收到原始含下划线的 header（前提是 upstream 支持）。
避免常见误解和副作用
以下操作**不能**提升哈希性能，反而引入风险或冗余：
- 在
location块里重复设置——该指令不支持 location 级别，会报错； - 试图用
map手动重映射下划线头来“优化检索”——map 本身基于哈希，且变量已由 Nginx 自动映射完成，纯属多此一举； - 开启后未约束来源——公网暴露此配置可能绕过 WAF 或触发后端变量污染，应配合 IP 白名单或仅限内网 server 使用。
更健壮的替代方案（推荐优先采用）
若目标是稳定传递自定义头，而非硬扛下划线，建议从源头规范命名：
- 客户端统一用中划线：把
X_User_ID改为X-User-ID，Nginx 默认支持且完全合规； - 必要时用
map做兼容性转换（非性能优化）：map $http_x_user_id $safe_user_id { default $http_x_user_id; }
再通过proxy_set_header X-User-ID $safe_user_id转发标准格式； - 日志中加
$http_x_user_id字段，便于监控异常头使用情况。
