ignore_invalid_headers 的核心作用是跳过非法请求头名的解析与变量映射，避免后续冗余处理；默认 on 可在早期“短路”非法输入，不生成变量、不触发条件判断、不透传至后端，从而减少 CPU 开销。
ignore_invalid_headers 的核心作用不是“忽略请求头”，而是跳过非法 header 名的解析与变量映射，从而避免 Nginx 在无效字段上做无意义的处理。它本身不节省 CPU 算力，但合理配置能减少后续环节的冗余操作——比如变量展开、日志拼接、proxy_pass 头透传等。关键在于理解：真正耗资源的不是“识别非法头”，而是“把非法头当作合法头继续处理”。
为什么默认 on 就能降低开销
当 ignore_invalid_headers on（Nginx 默认值）时：
- 遇到含空格、下划线、控制字符或非 token 字符的 header 名（如
X-User_Id、Cookie: a=b\r\nX-Foo:），Nginx 直接丢弃该整行，不进入内部 header 解析流程 - 不生成对应的
$http_x_user_id变量，也就不会触发 map 指令匹配、if 条件判断、log_format 中的变量求值 - 不参与
proxy_set_header的透传逻辑，避免无效头被错误转发给后端
这相当于在解析早期就“短路”了非法输入，省去了后续所有依赖 header 变量的计算路径。
显式设为 on 并配合其他轻量级优化
即使默认是 on，显式声明并搭配以下配置，可进一步收窄处理范围：
- 在
http{}块中统一设置，避免子块意外覆盖：http { ignore_invalid_headers on; # 显式声明，增强可维护性 underscores_in_headers off; # 关闭下划线支持（除非业务强依赖） } - 关闭不必要的 header 变量引用：
- 日志中避免使用
$http_*类变量（尤其未加白名单校验的） - rewrite 或 if 判断中，只引用明确合规的 header（如
$http_user_agent、$http_accept），不写$http_x_*这类易出错的泛用变量
- 日志中避免使用
- 禁用
underscores_in_headers（默认off）：若无历史兼容需求，彻底禁止下划线，让X-API-Key成为唯一合规写法，减少命名歧义带来的解析试探
注意：它不解决真正的“深度解析”负担
ignore_invalid_headers 仅作用于 header 名格式校验（RFC 7230 token 规则），对 header 值内容完全不检查。以下情况它无能为力：
-
X-Forwarded-For: <script>alert(1)</script>→ 值含 XSS，但名字合法，照常透传 -
Cookie: a=very_long_value_..._20KB→ 值超长，仍会进缓冲区、触发client_header_buffer_size分配 -
Host: evil.com%00%0aX-Injection:→ 换行注入，若名字看似合法（如X-Injection），照样被解析
这类问题需靠：
-
map+if+return 400主动校验值中是否含\r、\n、、<code>%00等危险字符 -
client_header_timeout和client_header_buffer_size控制头部接收行为，防 Slow Headers 攻击 - WAF 或 OpenResty 的 Lua 模块做语义级过滤
总结：省算力的关键是“早丢弃、少引用”
ignore_invalid_headers on 的价值，在于让 Nginx 在解析 pipeline 最前端就切断非法输入流，不为其分配变量、不触发条件判断、不写入日志字段。它不是性能开关，而是协议层的快速失败机制。真正想降低 CPU 开销，重点不是调这个指令，而是：
- 保持
on（默认即可，无需改动） - 避免在配置中大量引用
$http_*变量 - 对必须使用的自定义 header，用
map白名单预筛，而非运行时逐个 if 判断 - 把 header 值校验交给更合适的模块（如 Lua、ModSecurity），而不是指望
ignore_invalid_headers
