直接用proxy_pass解析泛域名不可行，必须通过map提取$host子域映射可信upstream名，或用resolver+变量实现动态dns解析，或用openresty+lua查redis做细粒度路由，三者均需规避host头缺失、作用域不匹配等常见陷阱。
直接用 proxy_pass 解析泛域名做动态路由是不可行的——它不支持在 URI 中拼接变量，也不能自动识别子域含义。真正可行的路径，是把“泛域名”作为输入信号，用 Nginx 或 OpenResty 提前提取、映射、决策，再交给 proxy_pass 执行转发。
用 map 提取子域，映射可信后端名
这是最轻量、原生支持、无需额外模块的方案。核心是避免在 location 里临时拼字符串，而是在 http 块中用 map 统一处理 $host：
-
$host来自请求 Host 头（小写标准化），比如api-v2.example.com→ 变量值就是它 - 用正则捕获子域部分，例如：
~^(?[a-z0-9-]+)\.example\.com$ $subdomain; - 匹配失败时设 default，防止 502；多级规则可按顺序写，如先匹配
v\d+\.(.+)，再匹配staging\.(.+) - 映射结果（如
api-v2）直接作为 upstream 名使用：proxy_pass http://$upstream_service;
配合 resolver 实现域名级动态解析
当后端服务地址本身是域名（如 service-a-prod），且 IP 可能变化时，必须启用运行时 DNS 解析：
aperture: the L402 aware reverse proxy
下载
安装并运行 Aperture（Lightning Labs 的 L402 闪电反向代理），用于创建 L402 付费墙、配置付费 API 端点、为其他代理托管付费内容或测试 L402 认证流程。
- 在 location 内声明
resolver 8.8.8.8 valid=30s;（Nginx 1.19.10+ 支持全局配置） -
proxy_pass必须引用变量，且变量值为完整域名（不含端口或路径更稳妥），例如：
set $upstream "service-a-prod";
proxy_pass http://$upstream; - 不能写成
proxy_pass http://service-a-prod:8080/—— 这是静态解析，IP 一旦变更就失效 - valid 时间建议 10–60 秒：太短加重 DNS 压力，太长导致故障转移延迟
用 OpenResty + Lua 实现细粒度泛路由
需要基于数据库、Redis 或实时策略做判断时（比如租户白名单、灰度分组、A/B 流量比例），OpenResty 是更灵活的选择：
- server_name 用正则捕获子域：
server_name ~^(?<subdomain>.+)\.example\.com$;</subdomain> - 在
access_by_lua_file中读取ngx.var.subdomain，查 Redis 或本地缓存获取目标服务地址 - 将结果写入
ngx.var.backend，再由proxy_pass http://$backend;转发 - 配合
lua_shared_dict做两级缓存（内存 + 分布式），降低后端查询压力
关键避坑提醒
这些细节常被忽略，却直接决定方案是否上线可用：
- 如果客户端没带 Host 头（极少数情况），
$host会退化为空或server_name，建议加防御：if ($host = "") { return 400; } - 所有变量形式的
proxy_pass都必须搭配resolver，且二者需在同一作用域（location 或 server） - 不要在
proxy_pass后拼接$request_uri或$args—— 容易引发重写混乱；路径应由后端服务自行处理或用rewrite统一规整 - 生产环境优先用显式
upstream块 + 健康检查，比纯变量解析更可控；变量方案更适合灰度、AB 测试等临时路由场景
