proxy_pass支持变量但有限制：仅允许变量出现在URI路径部分，协议和主机名必须固定；动态路由应配合upstream与map指令；复杂逻辑需用NJS或Lua扩展。
proxy_pass 支持变量，但有明确限制：不能在 location 块中直接使用带变量的 proxy_pass 指令指向不同协议或端口（如 http://$backend），否则会触发 502 或配置校验失败。真正可用的动态代理，依赖于变量拼接的合规路径和 upstream 的配合。
支持变量的合法用法
以下写法是 Nginx 官方允许且稳定的：
-
仅替换后端域名或路径部分：例如
proxy_pass http://backend/$uri;或proxy_pass http://$host:8080$request_uri;—— 变量必须出现在 URI 部分，协议+主机名固定 -
搭配 resolver 动态解析域名：当后端地址是可变域名（如服务发现场景），需配合
resolver指令，且proxy_pass中的变量必须是已解析的域名，不能是 IP 字符串 - 使用 $scheme、$host、$request_uri 等内置变量：它们语义明确、运行时安全，适合做路径透传或协议保持
需要 upstream 配合的动态路由
若需根据请求头、参数或路径决定转发到不同后端集群，应优先用 upstream + map 指令 实现逻辑分发：
CPA Update - Secure CLI Proxy API Maintenance
下载
安全更新和维护 CLI Proxy API（CPA）部署与配置。用于 CPA 镜像升级、配置变更、认证目录兼容修复、上线验证与回滚。适用于用户提到“CPA 更新/升级/配置改了/容器重建/回滚”等场景。
- 先用
map将请求特征映射为 upstream 名称（如map $arg_env backend_cluster { "prod" prod_upstream; "test" test_upstream; }） - 再在 location 中写
proxy_pass http://$backend_cluster;—— 此时变量值是预定义的 upstream 名，Nginx 允许这种引用 - 每个 upstream 可配置多台服务器、健康检查、权重等，比纯字符串拼接更可靠
高阶场景：Lua 或 NJS 扩展实现真动态
当规则复杂（如 JWT 解析、灰度标签匹配、数据库查路由），纯配置难以满足，推荐用脚本扩展：
-
NJS（Nginx JavaScript）：在
js_import加载模块后，用js_set或js_var计算目标地址，再交给 proxy_pass -
ngx_lua（Tengine 或 OpenResty）：通过
rewrite_by_lua*设置变量，或直接用balancer_by_lua*控制负载均衡节点选择 - 注意：脚本执行需启用对应模块，且变量必须在 proxy_pass 执行前完成赋值
常见错误与规避方式
这些写法会导致启动失败或行为异常：
-
proxy_pass http://$backend_host:$backend_port/;—— 协议+主机+端口全变量，Nginx 不支持 -
proxy_pass https://$domain/api;—— HTTPS 协议下变量域名未配 resolver，无法解析 - 在 if 块内写 proxy_pass —— Nginx 1.19+ 已废弃该用法，易引发配置歧义
- 变量内容含空格、特殊字符未编码 —— 导致 URL 解析错误，建议用
escape或脚本预处理
