Nginx在server块中处理畸形请求参数的核心是在upstream前拦截或标准化，不依赖后端：用map预分类$bad_args匹配union、select、etc/passwd等指纹，再if统一return 403；清理debug等干扰参数；校验api_key存在性与长度；限制URI总长防资源耗尽；透传X-Args-Clean等清洗标记头。
在 Nginx 的 server 块中处理畸形请求参数，核心是“在进入 upstream 前拦截或标准化”，不依赖后端、不触发代理转发。重点不是解析语义，而是识别典型攻击模式（如 SQL 注入、路径遍历、空字节、编码混淆）并快速响应。
用 map + if 拦截高危参数特征
避免使用 if 直接匹配复杂正则，应先用 map 提前归类，再统一处置：
- 定义参数黑名单：匹配
union select、select%20from、etc/passwd、..%2f、%00等典型指纹 - 示例配置：
map $args $bad_args {
~*(union|select|insert|delete|drop|load_file|etc/passwd|./|.\|%00) 1;
default 0;
}
if ($bad_args) { return 403; } - 注意：该规则放在
location内、proxy_pass之前；不要在server级直接写if，易引发变量作用域问题
剥离调试与干扰参数，强制标准化
非恶意但影响日志、缓存或后端逻辑的参数，应清理而非拦截：
- 删除常见调试参数：
rewrite ^(.*)?[^#]*debug=[^&]*&?(.*)$ $1?$2? permanent; - 清除重复或无效参数（如多个
utm_source）需配合 OpenResty 或 Lua，纯 Nginx 仅能做简单重写 - 对关键参数做存在性校验，例如要求
api_key必须存在且长度 ≥ 24：
if ($arg_api_key = "") { return 400; }
if ($arg_api_key ~ "^.{0,23}$") { return 400; }
限制参数整体长度与数量，防资源耗尽
畸形参数常表现为超长值或海量键值对，需从协议层设限：
- 单个请求参数总长度不宜超过 4KB，通过
client_header_buffer_size和large_client_header_buffers间接约束（因$args存于 header 缓冲区） - 显式限制 URI 总长（含参数）：
if ($request_uri ~ "^.{{8192,}}$") { return 414; } - Nginx 本身不校验参数个数，但可通过自定义日志标记高频异常请求，后续用限流模块（如
limit_req）压制
清洗后透传可信参数，避免污染下游
清洗不是删光，而是让后端收到干净、一致、可预期的输入：
- 用
proxy_set_header X-Args-Clean $args;将清洗后的参数透传（需先确保$args已被 rewrite 处理） - 对敏感参数（如
token、signature）不透传，改用内部鉴权头：proxy_set_header X-Auth-Valid "1"; - 添加清洗标记：
proxy_set_header X-Param-Scrubbed "true";，便于后端区分原始请求与网关处理后请求
