ignore_invalid_headers 仅控制Nginx对非法请求头名称的处理：on时跳过非法头继续处理，off时立即返回400；它不校验头值、不防注入、不替代WAF，仅按RFC 7230检查头名格式。
ignore_invalid_headers 本身不增强“协议安全过滤”，它只是控制 Nginx 对非法请求头名称的处理方式——默认 on 时跳过非法头继续处理，设为 off 时立即返回 400。它不能拦截恶意内容、防注入或替代 WAF，但在静态服务场景中，合理配置可提升协议合规性与基础过滤强度。
明确它的作用边界
该指令只校验请求头 名称 是否符合 RFC 7230：仅允许大小写字母、数字、短划线（-），默认禁止下划线（_）、空格、控制字符等。它不检查头值内容，也不影响响应头或请求体。
- 设为 on（默认）：遇到 X-User_ID 或 Host: a.com\r\nX-Foo: 1，Nginx 直接丢弃该头，不参与变量映射（如 $http_x_user_id 为空），但请求仍被正常处理
- 设为 off：只要头名含非法字符，Nginx 立即返回 400 Bad Request，不进入 location 匹配、日志记录或文件服务流程
- 必须在
http{}块中配置，写在 server 或 location 内会报错
静态服务中启用 strict 模式（off）的适用场景
对纯静态资源（HTML/CSS/JS/图片）提供服务时，客户端本不该发送复杂自定义头。若业务无兼容旧 SDK 或测试工具的需求，可设为 off，让网关更早暴露非法请求，减少无效处理。
- 防止爬虫或扫描器用畸形头试探（如 X-Forwarded-For: %00、Host: example.com%20X）
- 避免因非法头触发 CGI 变量污染（如 HTTP_PROXY 被下划线头覆盖，导致 SSRF）
- 配合 error_log info 级别，快速定位异常来源（日志中会出现 client sent invalid header line）
不能单独依赖它实现安全过滤
想真正拦截恶意请求，需结合其他机制：
- 用
map + if + return 400主动校验头名或头值中的危险模式（如含控制字符、script 标签、路径遍历符号） - 限制 HTTP 方法：只允许 GET、HEAD，禁用 PUT、DELETE、TRACE 等非必要方法
- 关闭版本泄露：
server_tokens off;，减少攻击面 - 静态资源建议加
add_header X-Content-Type-Options nosniff;和X-Frame-Options DENY
配套处理下划线兼容问题
若后端静态服务（如某些 PHP 或 Node.js 工具链）依赖下划线头（X_API_KEY），不能简单设 ignore_invalid_headers off 就放行，而应：
- 确认是否真需下划线：优先推动前端改用连字符（X-Api-Key），从源头合规
- 如必须支持，显式开启
underscores_in_headers on;，并确保静态服务运行环境（如 PHP-FPM、Node.js 中间件）能正确识别该头 - 注意：underscores_in_headers 和 ignore_invalid_headers 是两个独立开关，后者生效前提是前者已允许下划线
