nginx动态dns解析需满足三要素：nginx≥1.19.9、http块配置resolver及valid、upstream中server域名后紧接resolve；否则仍为静态解析，ip变更后流量无法自动更新。

Nginx轮询负载均衡本身不直接参与DNS解析，它只是按`upstream`中定义的静态IP或域名列表转发请求。但当你在`upstream`里用了`resolve`（如`server backend.example.com resolve;`），就进入了**动态域名解析场景**——这时排查IP变更问题，核心不是“轮询逻辑出错”，而是**DNS缓存、解析时效性与后端实际IP是否同步**。 下面从三个关键环节讲清楚怎么查、怎么看、怎么稳住：

确认Nginx是否真启用了动态DNS解析

先看配置有没有真正触发动态行为：

• 必须在server行末尾加resolve，例如：server api.prod.example.com resolve;，光写域名不加这个参数，Nginx启动时只做一次解析并固化IP
• resolver指令必须存在且有效，比如resolver 8.8.8.8 valid=10s;；没配或配错（如写成resolver 127.0.0.1但本地没DNS服务），会导致解析失败或超时回退到旧IP
• valid值不能大于后端DNS记录的TTL，建议设为TTL的1/3～1/2（如TTL=30s，就设valid=10s），否则Nginx会“假装不知道”新IP

验证DNS解析是否真的刷新了

别只信日志或curl结果，要抓底层行为：

Nginx Config Linter

对 Nginx 配置文件进行语法检查、验证和安全、性能审计。

下载

• 用nginx -t检查配置语法，再nginx -s reload确保生效；注意：reload不会清空DNS缓存，只有重启或等valid过期才更新
• 查Nginx错误日志：tail -f /var/log/nginx/error.log，关注含resolver、failed to resolve、no address的报错，这是解析失败的第一信号
• 手动模拟Nginx的解析行为：dig api.prod.example.com @8.8.8.8 +short，对比返回的IP和你当前upstream实际使用的IP（可通过ss -tnp | grep :80或抓包看Nginx建连目标）

观察流量是否落到新IP、旧IP是否被及时剔除

即使DNS解析对了，Nginx也可能继续往已下线的IP发请求：

• 默认情况下，Nginx不会主动探测后端是否存活，除非你配了max_fails和fail_timeout，例如：server api.prod.example.com resolve max_fails=2 fail_timeout=15s;
• 健康检查依赖proxy_next_upstream（如error timeout http_502）触发重试，但不会自动从DNS缓存里删掉IP；所以得靠valid到期+失败计数双保险
• 想实时看到当前解析结果，可用OpenResty的lua-resty-dns模块或自定义Lua打印缓存内容；原生Nginx无命令行查DNS缓存，只能靠日志+外部dig交叉验证