ignore_invalid_headers 仅校验 HTTP 请求头字段名是否符合 RFC 7230 的 token 规则，与 URL 路径、query string、body 无关；设为 on 时跳过非法 header 名解析，避免变量生成与透传，off 则可能引发 CGI 风险和日志膨胀。
ignore_invalid_headers 本身不处理“非法路径头部”，它只作用于 HTTP 请求头字段名（header name），比如 User-Agent、X-Forwarded-For 或自定义的 X-API-Key 这类名称，**和 URL 路径、query string、body 内容完全无关**。所谓“非法路径头部”属于概念混淆——路径（如 /api/v1/user?id=1）是请求行的一部分，不是 header；Nginx 对它的解析由 location 匹配和 rewrite 模块负责，不受该指令影响。
它真正影响的是哪些 header 名
该指令仅校验 header 字段名是否符合 RFC 7230 的 token 规则：只能含大小写字母、数字、短横线（-），禁止空格、下划线（_）、控制字符、冒号、斜杠等。常见触发场景包括：
- 客户端误发
My_Header: value（含下划线） - 扫描器注入
Host: example.com\r\nX-Scan: 1（含 CRLF 和非法字符） - 旧 SDK 拼错字段名，如
Contetn-Type（少一个n） - 非标准编码导致 header 名出现不可见字符
设为 on 是省算力的关键
默认值 ignore_invalid_headers on 表示：一旦发现非法 header 名，Nginx 立即跳过该字段，不尝试解析、不映射为变量（如 $http_my_header 为空）、不参与后续 rewrite 或 proxy_pass 判断。这避免了以下开销：
- 跳过对非法字段的 token 分割与规范化处理
- 不生成无效的变量供 if/map 指令反复读取
- 不将错误字段透传给后端或日志模块（除非显式记录原始头）
off 不是“深度解析”，而是强制尝试解析
设为 off 后，Nginx 会保留非法 header 名，并试图将其转为变量（例如 My_Header 可能映射为 $http_my_header）。但这种“解析”并不深入——它仍不校验 header 值内容，也不执行业务逻辑。反而可能引发问题：
- CGI 兼容风险：下划线 header 可能覆盖
HTTP_PROXY等关键环境变量 - 变量污染：多个非法 header 映射后占用更多内存和 CPU 周期
- 日志膨胀：若 log_format 包含
$http_*变量，非法字段可能写入日志造成冗余
真想减少解析开销？关注这些更有效的点
比起纠结 ignore_invalid_headers，以下配置对降低 header 处理负担更直接：
- 缩小
client_header_buffer_size（如设为 1k～2k），避免为单个大 header 预分配过多内存 - 限制最大 header 数量：
large_client_header_buffers 4 8k，防恶意构造海量 header - 禁用无用 header 变量：不在 rewrite/if/map 中引用
$http_xxx，就不用解析它 - 用
map提前归类，避免在每个 location 里重复正则匹配 header 值
