upstream中resolve参数是动态解析的关键开关：需Nginx≥1.19.9、http块配置resolver及valid参数，并在server行末紧接resolve，配合proxy_next_upstream等容错机制方可生效。
upstream 中的 resolve 参数是动态解析的关键开关
从 Nginx 1.19.9 版本起，开源版已原生支持 server 域名后加 resolve 的语法，无需第三方模块。它让 upstream 内每个 server 条目在运行时按需解析 DNS，而非仅启动时静态固化 IP。启用方式很简单：
- 在 upstream 块中写：
server api.example.com:80 resolve; - 必须配合 http 块顶层的
resolver指令，例如：resolver 1.1.1.1 8.8.8.8 valid=30s; -
resolve必须紧贴在server行末，不能换行或加空格，否则被忽略
valid 参数决定刷新节奏，要匹配后端变更频率
valid= 不是读取 DNS 记录的 TTL，而是你强制设定的本地缓存上限。设得太长，IP 变更后流量仍打向旧地址；设得太短，高频查询可能拖慢请求或压垮 DNS 服务。
- 云主机/容器漂移场景（如 ACK、EKS）：建议
valid=10s–30s - Kubernetes Service ClusterIP 后端（稳定但偶尔滚动）：可放宽至
valid=60s - CDN 回源或 SLB 地址（变更极少）：
valid=300s更稳妥 - 避免设为
valid=1s——实测会显著增加 resolver 负载，且无实际收益
搭配健康检查与故障转移，避免 DNS 刷新期间出错
DNS 解析本身有延迟和失败可能，单纯靠 resolve 不足以保障可用性。需叠加基础容错机制：
- 每个
server行加上max_fails=2 fail_timeout=15s，快速剔除暂时不可达节点 - 配置
proxy_next_upstream error timeout http_502 http_504，让失败请求自动转发到其他节点 - 若后端域名解析失败（如 DNS 服务器全不可用），Nginx 默认会返回 502；可通过
proxy_next_upstream_tries 3提升重试韧性 - 慎用
backup：DNS 动态解析下，backup 节点也需带resolve，否则它可能长期指向过期 IP
验证是否真正生效，别只看配置
光写对配置不等于动态解析就跑起来了。真实生效需满足三个条件：Nginx 版本 ≥ 1.19.9、resolver 已声明、日志里能看到解析动作。
- 检查版本：
nginx -v确认不低于nginx version: nginx/1.19.9 - reload 后观察错误日志：
tail -f /var/log/nginx/error.log | grep "resolving"，应出现类似resolving "api.example.com", resolver: 1.1.1.1:53 - 手动触发一次 DNS 变更（如修改 CoreDNS 配置并 reload），等待
valid时间后，用curl -I测试响应头中的X-Upstream-Addr（需自定义 log_format）确认 IP 是否更新
