Nginx自定义请求头应统一采用X-前缀、短横分隔、首字母大写的驼峰格式（如X-User-ID），因其被客户端广泛支持、Nginx能稳定透传并生成可预测变量，且符合RFC规范；禁用下划线，避免因underscores_in_headers默认关闭导致头被静默丢弃；跨域时Header名须与Access-Control-Allow-Headers及后端读取名严格一致。
自定义请求头命名规范直接影响Nginx能否正确识别、透传和记录这些头字段。核心问题不在“加不加”，而在于“怎么命名才能被Nginx稳定接收并转发给后端”。
统一用短横分隔的驼峰格式（X-User-ID、X-Trace-ID）
这是最稳妥的实践方式，原因有三：
- 浏览器、curl、主流前端框架（如Axios、Fetch）原生支持该格式，不会被静默过滤
- Nginx内部将短横自动转为下划线用于变量引用（如
X-User-ID→$http_x_user_id），避免命名歧义 - 符合RFC 7230对字段名的推荐写法：以字母开头，仅含字母、数字、短横，且不以
X-以外前缀滥用（现代建议用语义化前缀如Sec-或Content-，但X-仍广泛兼容）
避免在Header名中使用下划线
Nginx默认启用underscores_in_headers off（关闭状态），这意味着如果客户端发送X_User_ID，Nginx会直接丢弃该头，且不报错、不记录——这是最隐蔽的丢失原因。
若必须用下划线（如旧系统强依赖），需在http或server块中显式开启：
但强烈不建议：开启后可能引发安全风险（如绕过某些基于短横规则的过滤逻辑），且与多数客户端/标准工具行为不一致。
大小写保持首字母大写，不全小写也不全大写
Nginx对Header名不区分大小写，但变量映射严格按小写+下划线生成。例如：
-
X-Api-Key→ 可用$http_x_api_key -
x-api-key→ 同样映射为$http_x_api_key，但可读性差、易出错 -
X-API-KEY→ 映射仍为$http_x_api_key，但前端调试时难以快速对应
统一采用X-开头 + 首字母大写的单词 + 短横连接（如X-Request-ID、X-Correlation-ID），既保证Nginx变量可预测，也便于前后端协作排查。
命名需与Access-Control-Allow-Headers列表完全一致
跨域场景下，若前端携带X-User-Token，而Nginx的add_header Access-Control-Allow-Headers里写的是x-usertoken或X-UserToken，浏览器会拒绝实际请求。
务必确保：
- 前端发送的Header名（区分大小写仅用于可读性，实际传输不敏感）
- Nginx配置中
add_header Access-Control-Allow-Headers列出的字符串 - 后端代码中读取的Header名（如Spring Boot用
@RequestHeader("X-User-Token")）
三者拼写（包括短横位置和大小写风格）完全一致，否则CORS预检失败或后端取不到值。
