Nginx动态域名代理需用变量+resolver实现运行时DNS解析：set $backend "api.example.com"; proxy_pass http://$backend; 并在同location/server块配resolver 114.114.114.114 valid=30s；高稳场景推荐upstream显式定义后端。

直接在 proxy_pass 后写死域名（如 proxy_pass http://api.example.com;），Nginx 会在启动或重载时强制解析该域名。一旦 DNS 不可达、域名无效或客户环境无公网，就会报错退出，服务根本起不来。

用变量绕过启动期解析

核心思路是让 Nginx 启动时不触碰 DNS，把解析动作推迟到第一次实际请求时发生：

• 用 set 指令定义变量，例如 set $backend "api.example.com";
• proxy_pass 必须引用该变量，写成 proxy_pass http://$backend;（不能混用字面量）
• 这样启动阶段只做语法检查，不发起任何 DNS 查询

必须配 resolver，且位置要对

仅用变量还不够——Nginx 运行时需要知道找谁去查 DNS：

Umbrel Proxy Manager

高效管理与交互 Umbrel 代理服务，支持 Docker 容器。自动发现运行服务，将内部 Docker IP 映射为可访问的外部地址。

下载

• 在同一个 location 或 server 块内添加 resolver 指令，例如 resolver 114.114.114.114 valid=30s;
• 不要放在 http 全局块（旧版本不支持，且作用域失效）
• valid 时间建议设为 10–60 秒：太短加重 DNS 压力，太长无法及时感知后端 IP 变更
• 若客户内网有自建 DNS，优先填内网地址，避免依赖公网

生产环境更稳的替代方案

对稳定性要求高的场景，建议放弃动态域名代理，改用显式 upstream：

• 定义 upstream 块，列出具体 IP 或内部 Service 名（如 Kubernetes 中用 my-service.default.svc.cluster.local）
• 配合 keepalive 复用连接，减少握手开销
• 启用健康检查（health_check），自动剔除不可用节点（注意：流式模块或商业版才支持 HTTP 层健康检查）
• IP 变更时，只需更新 upstream 配置并执行 nginx -s reload，不中断服务

快速验证是否生效

别等出问题才排查，上线前就确认动态解析已就位：

• 修改本地 DNS 返回一个新 IP，观察 Nginx error 日志中是否出现 resolving 或 could not be resolved 相关记录
• 等 valid 时间过后，用 strace -p $(pgrep nginx) -e trace=connect 抓 worker 进程的连接目标，看是否切换到了新 IP
• 临时把 resolver 指向一个不可达地址，应看到超时日志，证明解析逻辑确实在运行时触发