nginx动态解析upstream域名需同时满足：resolver置于http块顶层、配置valid缓存时间、并配合变量proxy_pass或upstream resolve指令（1.19.0+），三者缺一不可；否则仅启动时解析一次，无法响应ip变更。
要让 Nginx 正确解析动态变化的 upstream 域名，核心不是只写 resolver，而是让它“活起来”——即在运行时按需或定时刷新 DNS 结果。静态配置 upstream 或直接写死 proxy_pass http://example.com 都会在启动时解析一次就缓存到底，后端 IP 变了也不会自动更新。
resolver 必须放在 http 块顶层
resolver 指令不能嵌套在 upstream、location 或 events 块里，必须声明在 http 块中（推荐），或至少是 server 块内。否则 Nginx 启动会报错，或者日志里反复出现 no resolver defined。
- 正确写法：
http {
resolver 114.114.114.114 8.8.8.8 valid=30s;
# 其他 server/upstream 配置
} - 错误写法：把
resolver写进upstream块，或只放在某个location里（不继承、易遗漏） -
valid=30s是关键——它控制 DNS 缓存过期时间，超时后才会重新发起查询；不加这个参数，缓存永不更新，等于没用
两种生效路径：变量 proxy_pass 或 upstream resolve
光有 resolver 还不够，必须触发 Nginx 主动走 DNS 查询逻辑。目前主流方式有两种，选其一即可：
-
方式一：用变量 + proxy_pass（兼容老版本）
把域名存在变量里，再让proxy_pass引用该变量：
set $backend "api.example.com";
proxy_pass http://$backend;
注意：proxy_pass后必须带协议（http://或https://），否则不触发解析 -
方式二：upstream 中启用 resolve（Nginx ≥ 1.19.0）
在upstream块中使用resolve参数，并确保server行仍写域名而非 IP：
upstream dynamic_api {
server api.example.com:8080 resolve;
}
同时外层http块已定义resolver，且可额外指定缓存时间：server api.example.com:8080 resolve valid=20s;
验证是否真正动态生效
别只靠 nginx -t，它不执行解析。真实验证要看运行时行为：
- 修改 DNS 记录（比如把
api.example.com指向新 IP），等超过valid设置的时间（如 30 秒）后，观察 Nginx error log：
出现resolving ... to ...或resolved ... to ...日志，说明已重查并更新 - 若 DNS 服务器暂时不可达，Nginx 会继续用旧缓存响应请求，直到缓存过期——这是设计上的容错机制，不是故障
- 频繁看到
resolver not found或getaddrinfo() failed，先检查resolver是否位置错误、DNS 地址是否可达、resolver_timeout是否设得太短（默认 30s，建议调成 3–5s 防阻塞）
增强稳定性的实用建议
生产环境别只依赖单个 DNS：
- 配置多个 DNS 服务器，空格分隔：
resolver 114.114.114.114 8.8.8.8 223.5.5.5 valid=25s; - 搭配
proxy_next_upstream error timeout http_502;，当 DNS 解析失败或后端返回 502 时尝试下一个 upstream（需配合 upstream 块） - 对高频变更场景（如灰度发布），
valid值不宜过小（低于 10s 可能加重 DNS 负载），建议 20–60s 平衡灵敏性与开销 - 本地部署
dnsmasq作 DNS 缓存代理，可显著降低上游 DNS 查询延迟和失败率
