Nginx proxy_pass 不支持直接在 URL 路径中使用变量，但可通过 map 指令映射参数值到后端地址实现安全动态寻址，推荐优先使用 map + upstream 方式，避免注入风险。
Nginx 的 proxy_pass 本身不支持直接在 URL 路径中使用变量（如 $arg_xxx）来动态拼接后端地址，但可以通过合理组合 Nginx 内置变量、map 指令和 rewrite 或 set 等模块，安全、高效地实现基于请求参数的动态后端寻址。
用 map 提前映射参数值到后端地址
这是最推荐、最安全的方式。它把参数值与后端服务的映射关系提前定义好，避免运行时拼接带来的注入风险或语法错误。
- 在
http块中定义映射表，例如根据cluster参数选择不同集群：
map $arg_cluster $backend_upstream {
default "backend_default";
"prod" "backend_prod";
"staging" "backend_staging";
"dev" "backend_dev";
}
- 在
location中直接引用该变量：
location /api/ {
proxy_pass http://$backend_upstream;
proxy_set_header Host $host;
}
注意：proxy_pass 后必须带协议和斜杠（如 http://$backend_upstream/），否则路径传递行为异常；且 $backend_upstream 必须是已定义的 upstream 名称或合法域名/IP。
用 set + rewrite 实现更灵活的路径级路由
当需要根据参数拼接完整后端 URL（如 http://host:port/v1/$arg_service），可借助 set 和 rewrite 构造目标地址，再交由 proxy_pass 使用。
- 启用
ngx_http_rewrite_module（默认已编译）； - 用
set构建后端地址（注意：不能在if中用set赋值给新变量，需配合map或放在location外）； - 更稳妥的做法是先用
map定义基础 host，再用rewrite改写 URI，让proxy_pass指向固定 upstream，由 URI 触发后端分发：
map $arg_service $service_host {
default "10.0.1.100";
"user" "10.0.1.101";
"order" "10.0.1.102";
}
upstream dynamic_backend {
server $service_host:8080;
}
location /api/ {
rewrite ^/api/(.*)$ /$arg_service/$1 break;
proxy_pass http://dynamic_backend;
}
⚠️ 注意：upstream 中不能直接用变量（Nginx 1.19+ 支持变量 upstream，但需开启 resolver 并谨慎配置）；上述写法仅作示意，生产环境建议用第一种 map → upstream 方式。
安装并运行 Aperture（Lightning Labs 的 L402 闪电反向代理），用于创建 L402 付费墙、配置付费 API 端点、为其他代理托管付费内容或测试 L402 认证流程。
用 resolver + 变量 upstream（高级场景）
若后端地址来自 DNS（如 Kubernetes Service 名），且需按参数动态解析不同服务名，可启用动态 upstream：
- 定义
resolver（必须，否则变量 upstream 不生效）； - 用
map构造服务域名； -
proxy_pass直接使用变量（Nginx ≥ 1.3.13 & ≥ 1.9.0）：
resolver 10.96.0.10 valid=5s;
map $arg_svc $backend_host {
default "default.svc.cluster.local";
"auth" "auth.svc.cluster.local";
"payment" "payment.svc.cluster.local";
}
location / {
proxy_pass http://$backend_host:$arg_port;
proxy_set_header Host $backend_host;
}
✅ 关键点：必须配置 resolver；$arg_port 需确保可信（建议设默认值并白名单校验）；不建议将用户输入直接拼入端口或路径，防止 SSRF 或绕过。
安全与稳定性提醒
动态寻址易引入风险，务必注意：
- 所有参数值应做白名单校验（用
map默认兜底是最简单有效的手段）； - 避免在
proxy_pass中直接拼接未过滤的$args、$request_uri； - 不要在
if块中设置proxy_pass—— Nginx 官方明确不推荐； - 启用
proxy_next_upstream和健康检查，提升容错能力； - 记录
$arg_*和$backend_upstream到 access log，便于排障。
不复杂但容易忽略。核心是“用 map 控制输入范围，用 upstream 或 resolver 保障解析安全”，而不是在 proxy_pass 里硬拼字符串。
