nginx 的 proxy_pass 本身不支持直接过滤 url 参数，必须在转发前通过 map 白名单或 rewrite 正则等方式净化参数；推荐 map 方案性能高、易维护，可精准保留 id/token 等必要参数，清除 debug、secret_key 等敏感参数，并需同步清理敏感请求头与 cookie。
Nginx 的 proxy_pass 本身不支持直接过滤或删除 URL 参数，敏感参数（如 token、debug、secret_key）若未清理，会原样透传至后端，造成泄露风险。关键是在请求转发前完成参数净化，而不是依赖 proxy_pass 处理。
用 map 指令构建参数白名单（推荐）
性能高、可读性强、易于维护，适合中高并发场景：
- 在
http块中定义白名单逻辑，预计算是否需要清理：
map $args $clean_args {
default "";
~^(id=[^&]+)&(token=[^&]+)(?:&.*)?$ "$1&$2";
~^(token=[^&]+)&(id=[^&]+)(?:&.*)?$ "$1&$2";
~^(id=[^&]+)(?:&.*)?$ "$1";
~^(token=[^&]+)(?:&.*)?$ "$1";
}- 在
location中使用该变量重写 URI：
location /api/ {
rewrite ^(.*)$ $1?$clean_args? break;
proxy_pass https://backend;
}- 这样只保留
id和token，其余参数（包括敏感的debug=1、admin=true）全部丢弃
用 rewrite + 正则提取关键参数（灵活可控）
适合参数组合固定、需精确控制顺序或做简单转换的场景：
linux-performance-analyzer
下载
Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。
- 匹配并重组 URI，强制只带指定参数：
location /api/ {
if ($args ~* "id=([^&]+)&token=([^&]+)") {
set $id $1;
set $token $2;
rewrite ^/api/(.*)$ /api/$1?id=$id&token=$token? break;
}
if ($args ~* "token=([^&]+)&id=([^&]+)") {
set $token $1;
set $id $2;
rewrite ^/api/(.*)$ /api/$1?token=$token&id=$id? break;
}
# 其他情况清空参数
rewrite ^/api/(.*)$ /api/$1? break;
proxy_pass https://backend;
}- 注意：
if在 location 中可用，但避免嵌套；建议配合break防止重复匹配 - 末尾的
?表示清空原始参数，否则 Nginx 会自动拼接
同步清理敏感请求头与 Cookie
参数清理只是第一步，还需防止敏感信息通过 Header 或 Cookie 泄露：
- 清除客户端可能携带的危险头：
proxy_set_header X-Forwarded-For ""; proxy_set_header X-Real-IP ""; proxy_set_header X-Original-Args $args; # 如需审计，可记录原始参数（脱敏后）
- 禁止透传含密 Cookie（如
session_secret）：
proxy_cookie_path / "/; HttpOnly; Secure"; # 若需彻底移除某 Cookie，用 map + proxy_set_header Set-Cookie "" 不可行，应由后端控制； # Nginx 层可借助 lua 模块（如 header_filter_by_lua）精细操作，但非必需时优先后端处理
验证是否生效的简单方法
用 curl 模拟带多参数请求，观察后端收到的 URI：
- 测试命令：
curl -v 'https://example.com/api/user?id=123&token=abc&debug=1&secret=x'
- 检查 Nginx access log 中的
$request_uri字段，确认只有/api/user?id=123&token=abc - 也可在后端加日志打印原始 query string，交叉验证
