nginx 中处理带问号的 get 请求参数，核心在于理解 $args 变量与 location 匹配机制。默认情况下，nginx 会将 uri 中的查询字符串（即问号后的内容）剥离并赋值给内置变量 $args，而 location 的匹配仅针对 uri 路径部分进行。因此，若需基于参数值进行路由或重写，应使用 if 指令配合正则表达式检查 $args，或在反向代理时通过 proxy_pass 显式拼接参数。
location 匹配是否受查询字符串影响
结论是：标准的 location 块匹配完全忽略查询字符串。无论 URL 后是否带有 ?key=value，Nginx 在确定进入哪个 location 时，只看斜杠分隔的路径部分。这意味着 /api/data 和 /api/data?status=active 会进入同一个 location 配置块。
server {
listen 80;
server_name example.com;
# 无论是否有参数，都进入此块
location /api/data {
# 这里无法直接通过 location 语法区分参数
proxy_pass http://backend_server;
}
}上述配置中，访问 /api/data?id=1 和 /api/data 均命中 location /api/data。若希望不同参数走不同后端，不能依赖 location 前缀匹配，必须结合 if 判断或修改后端逻辑。
如何根据参数值动态路由
当需要根据查询参数决定转发目标时，需在 location 内部使用 if 指令解析 $args。由于 $args 包含所有参数且无分隔符保证，通常使用正则表达式提取特定键值对。例如，根据 type 参数将请求分发到不同的 upstream。
server {
listen 80;
server_name example.com;
location /api/ {
# 检查 type 参数是否为 mobile
if ($args ~* "^.*&type=mobile(&.*)?$|^type=mobile(&.*)?$") {
proxy_pass http://mobile_backend;
}
# 检查 type 参数是否为 desktop
if ($args ~* "^.*&type=desktop(&.*)?$|^type=desktop(&.*)?$") {
proxy_pass http://desktop_backend;
}
# 默认后端
proxy_pass http://default_backend;
}
}该配置展示了如何通过正则匹配 $args 实现基于参数的动态路由。注意 if 在 Nginx 中的特殊性，它仅在当前上下文生效，且可能引发意外行为，建议在生产环境中谨慎使用，或考虑将逻辑移至应用层处理。
proxy_pass 保留原始参数的条件
在使用 proxy_pass 时，URI 部分的写法决定了查询字符串是否被保留。如果 proxy_pass 后面只跟了协议和主机名（如 http://backend），Nginx 会将原始请求的完整 URI（包括查询字符串）原样传递给后端。但如果 proxy_pass 后面跟了路径（如 http://backend/api），则只有路径部分被替换，查询字符串依然会被附加到新的 URI 上。然而，若在 proxy_pass 中显式指定了带参数的 URI，则原始参数会被丢弃。
# 情况1：保留原始参数
location /old-api/ {
proxy_pass http://new-backend/; # 注意末尾斜杠
}
# 访问 /old-api/test?key=val -> 转发至 http://new-backend/test?key=val
# 情况2：丢弃原始参数
location /old-api/ {
proxy_pass http://new-backend/new-path; # 无末尾斜杠，且指定了新路径
}
# 访问 /old-api/test?key=val -> 转发至 http://new-backend/new-path (无参数)关键在于 proxy_pass 的目标 URI 是否包含变量或固定路径。若目标是固定的且不含变量，Nginx 会用目标 URI 替换匹配的 location 前缀，并追加原始查询字符串。若目标是变量或包含复杂表达式，需谨慎测试参数传递行为。最佳实践是明确指定 proxy_pass 的目标，并在必要时使用 $query_string 变量手动拼接参数，以确保行为可控。
