是的，proxy_pass不支持URI部分拼接变量；因其URI解析在配置加载时进行，而变量仅在请求处理时可用，故需用map+upstream、resolver+域名或Lua等方案实现动态转发。
proxy_pass 后面不能直接拼接变量？先确认这个限制
是的，proxy_pass 指令**不支持在 URI 部分使用任意变量拼接**。比如 proxy_pass http://$backend_host:$backend_port/api; 这种写法会触发 Nginx 启动失败，报错 "invalid URL prefix" 或直接拒绝加载配置。
根本原因是 proxy_pass 的 URI 解析发生在配置加载阶段（compile-time），而普通变量（如 $host、$arg_backend）只在请求处理时（run-time）才可求值。Nginx 为安全和性能，默认禁止这种动态解析。
但别急——不是完全不能做动态后端，只是得绕开这个限制：
- 用
map+upstream名称间接实现“逻辑路由” - 用
resolver+ 变量域名 +proxy_pass http://$var/（仅限无端口、无路径的简单形式） - 用 Lua（OpenResty）或第三方模块（如
nginx-upstream-dynamic）接管转发逻辑
用 map + upstream 实现基于请求参数的服务发现路由
这是最轻量、原生支持、无需编译扩展的方案。核心思路：把动态决策提前到 map 块，在请求进入 location 前就把后端组名映射好，再交给 proxy_pass http://$upstream_name ——注意，这里变量必须是已定义的 upstream 名称，且 proxy_pass 后不能带 URI 路径（否则变量失效）。
示例：按查询参数 ?env=prod 或 ?env=staging 切流量
http {
map $arg_env $backend_upstream {
default prod_backend;
"prod" prod_backend;
"staging" staging_backend;
"canary" canary_backend;
}
<pre class="brush:php;toolbar:false;">upstream prod_backend {
server 192.168.1.10:3000;
server 192.168.1.11:3000;
}
upstream staging_backend {
server 192.168.1.20:3000;
}
upstream canary_backend {
server 192.168.1.30:3000 weight=1;
server 192.168.1.10:3000 weight=9; # 主流 prod 流量中混入 10% canary
}
server {
location /api/ {
proxy_pass http://$backend_upstream; # ✅ 合法：变量值是已定义的 upstream 名
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
}
}
⚠️ 容易踩的坑：
-
proxy_pass http://$backend_upstream/末尾加了/→ 变量会被忽略，Nginx 当作字面量处理，报unknown upstream -
map块必须定义在http级，不能放在server或location内 -
map的 key 是字符串匹配（区分大小写），不支持正则或通配符；如需模糊匹配，得换 Lua
resolver + 变量域名实现 DNS 服务发现（适合容器/云环境）
当后端服务通过 DNS 名称注册（如 Kubernetes Headless Service、Consul DNS、或 Docker 自动 DNS），可用 resolver 搭配变量域名做动态解析。前提是：proxy_pass 必须写成 http://$domain 形式（无端口、无路径），且 Nginx 编译时启用了 resolver 支持（默认都有）。
示例：根据请求头 X-Service-Name 动态解析并转发
http {
resolver 127.0.0.11 valid=5s; # Docker 内置 DNS；K8s 可填 coredns 地址
<pre class="brush:php;toolbar:false;">server {
location / {
set $backend "default-service.default.svc.cluster.local";
if ($http_x_service_name) {
set $backend "$http_x_service_name.default.svc.cluster.local";
}
proxy_pass http://$backend; # ✅ 合法：纯域名变量，由 resolver 异步解析
proxy_set_header Host $host;
# 注意：无法指定端口，依赖后端服务监听标准端口（80/443），或用 SRV 记录（需额外模块）
}
}
}
⚠️ 关键限制与风险：
- 不支持
proxy_pass http://$domain:8080/—— 带端口就报错 - DNS 解析失败时，Nginx 默认返回 502；可通过
resolver_timeout和重试机制缓解 - 每次请求都触发 DNS 查询？不会。Nginx 会缓存
valid=5s时间，但若后端 IP 变更频繁（如滚动更新），仍可能短暂路由到旧实例 - 没有健康检查，DNS 返回的 IP 不代表服务可达；建议配合主动健康检查（
health_check）或上层服务网格
为什么不用 rewrite + proxy_pass 拼接？后果很现实
有人试图用 rewrite 把变量注入到 URI，再交给 proxy_pass，例如：
location / {
rewrite ^/(.*)$ /$1 break;
proxy_pass http://$backend_host:$backend_port;
}
这行不通。因为 rewrite ... break 不会改变 proxy_pass 的上下文；Nginx 仍按原始 location 匹配规则处理，变量未被识别，最终报 invalid URL 或静默 fallback 到默认 upstream。
真正能生效的“动态转发”只有三条路：
-
map→ 固定 upstream 名 →proxy_pass http://$name（推荐用于灰度、多环境） -
resolver+ 变量域名 →proxy_pass http://$domain（推荐用于容器化 DNS 服务发现） - 引入 OpenResty 或 NJS，用脚本控制
proxy_pass目标（适合复杂路由逻辑，但运维成本上升）
实际部署时，map 方案最容易验证、调试成本最低，也最符合 Nginx 的设计哲学：配置即策略，运行时只做高效转发。真要对接 Consul/Etcd 做实时服务发现，不如把这层逻辑交给专用 sidecar（如 Envoy）或平台层，Nginx 安心做好它最擅长的事：稳定、低延迟、高并发的七层代理。
