网关上游域名换了IP仍连旧地址，怎样在Nginx核对动态DNS解析

上游地址何时重新解析，取决于配置形式与Nginx版本。开源upstream的resolve参数从1.27.3起可用；需要共享zone与显式resolver，并用实际地址变化证明请求重新派发，不能只看域名现在查到新IP。

核对实际Nginx版本与功能许可

配置加载时解析得到的地址与运行中动态解析是两个阶段。运维终端的DNS结果更新，并不代表已有worker丢掉旧地址。先核对实际二进制版本、upstream写法、解析器和缓存有效期，再设计受控切换；不要把较新文档里的参数直接粘给旧版1.26实例。

区分启动解析与动态resolve

附件使用独立编译的Nginx1.28.0与回环UDP DNS。动态域名先指127.0.0.2，再指127.0.0.3，两上游分别返回A与B；观察到动态组从A转B，固定地址对照仍为A。固定组模拟已经持有旧地址的状态，不冒称实验修改了系统DNS或完整复现外部权威DNS链路。

动态解析实验需要同时保留DNS回答与上游标记，单独dig得到新地址只证明查询工具的结果。Nginx查询用的resolver可能与终端系统解析器不同，valid也可能覆盖DNS TTL。本文把DNS服务放在自建回环高端口，并明确关闭IPv6查询，缩小变量范围，不能据此推断多地址生产域名的全部切换策略。

说明缓存窗口和DNS失败边界

TTL和valid控制缓存并不承诺到点精确切流，解析调度、旧连接和请求时刻都会影响过渡。真实切换还要考虑多条A/AAAA、失败缓存与服务可达性。实验只使用回环高端口，不改/etc/hosts、系统解析器或生产Nginx；版本不足时应先制定升级或适配方案。

适用范围：只用回环DNS高端口与假上游；开源动态参数最低1.27.3，需实际版本核验，不承诺TTL一到精确切换。

配套样本与复核入口

• run.py：独立运行程序，包含合成输入、操作和正反例断言。
• case.json：输入说明、预期任务与适用范围，便于保存和交接。
• observed.json：本次实际执行输出；临时路径、进程号和计时可能随运行变化。

本例强制核对Nginx1.28.0，随后启动本地DNS与两个带A/B标记的假上游。观察dynamic_first、dynamic_after与fixed_after，应依次为A、B、A；dns_queries表明运行中确有解析请求。等待循环保存过渡标记，不使用睡眠一秒就宣称TTL切换完成；不同机器过渡次数可以不同，终态语义应保持。

Linux、Python3.8以上与Nginx1.28.0，设置NGINX_BIN为可执行文件绝对路径；鉴权题还需编译启用http_auth_request_module。程序显式指定新建prefix、配置、pid和日志，所有监听均为回环高端口，绝不向已有master发送控制命令。

python3 -B run.py

阅读输出时，先按case.json中的任务逐项核对Nginx网关上游DNS更新，再与observed.json比较。非零退出表示依赖或断言需要处理，应保留实际错误。

一手依据1（keepalive限制每worker闲置缓存而非总连接；resolve动态DNS需核版本、共享zone与resolver，开源1.27.3前有商业限制。）。

继续阅读：Nginx配置文件已经改了服务仍按旧规则转发，怎样证明reload真正生效；keepalive设成32为什么仍有上百上游连接，怎样区分闲置缓存与并发上限；网关访问本机上游却绕进代理：怎样验证NO_PROXY与环境继承。