Nginx中proxy_pass写死域名（如https://api.example.com）仅在启动或重载时静态解析一次DNS，后续请求均发往缓存IP，不随DNS变更更新；必须配合变量（如set $backend "api.example.com"; proxy_pass https://$backend;）和同级resolver指令才能触发动态解析，valid参数设定缓存有效期而非直接继承DNS TTL。
proxy_pass 写死域名永远不刷新 DNS
直接写 proxy_pass https://api.example.com;，Nginx 只在启动或 reload 配置时查一次 DNS，之后所有请求都发往缓存下来的 IP。哪怕你把 DNS TTL 设成 5 秒、后端服务已下线、甚至域名解析已返回 NXDOMAIN，Nginx 也完全不会重试——它压根没打算再查。
这不是 bug，是默认行为：为性能牺牲动态性。但生产中这恰恰是 502/连接超时最隐蔽的来源之一。
- 用
nginx -T | grep api.example.com能看到实际解析出的 IP，不是域名 -
ss -tnp | grep :443观察长连接目标 IP 是否随 DNS 变更而更新，是最直接的验证方式 - reload 配置不会触发重新解析，除非你改了
proxy_pass的值本身（比如加个路径）
resolver 指令本身不自动生效
只加 resolver 8.8.8.8 valid=10s; 完全没用。Nginx 不会因为配置了 resolver 就去“监听”你写的域名变化——它只在特定条件下才调用这个解析器。
真正触发 resolver 的唯一条件是：proxy_pass 的值必须是一个变量，且该变量在运行时可变（哪怕只是 set $upstream "api.example.com"; 这种静态赋值）。
- 正确写法：
set $backend "api.example.com"; proxy_pass https://$backend; - 错误写法：
proxy_pass https://api.example.com;（哪怕上面有 resolver） - 变量必须出现在与
resolver同级或更内层的作用域里；放在http块顶层、但在location里用变量，旧版 Nginx 可能不识别
valid 参数不是 DNS TTL 的搬运工
valid=10s 是你给 Nginx 缓存结果设定的“保质期”，和 DNS 记录返回的 TTL 是两回事。Nginx 默认取二者中的较小值作为实际缓存时间，但你主动设了 valid，就等于覆盖了上游 DNS 的 TTL 控制权。
⚠️ 已弃用 — 该技能已拆分为两个独立技能，以提升模块化程度：**webchat-https-proxy**（HTTPS/WSS 反向代理）和 **webchat-voi...**
- CDN 回源、K8s Service、云 LB 等动态后端，建议
valid=10s–30s，兼顾新鲜度与查询压力 - 内网稳定服务可放宽到
valid=60s，避免无谓轮询 - 设成
valid=300s几乎退化为静态解析，失去动态意义 - 务必配
resolver_timeout 5s;，防止 DNS 查询卡住 worker 进程
upstream + resolve 是更稳的生产方案
如果你用的是 Nginx 1.19.9+，直接用 upstream 块的 resolve 参数，比变量 + resolver 更可靠：
upstream origin_backend { server origin.example.com:443 resolve; }
再配合全局 resolver 1.1.1.1 valid=10s;（放在 http 或 events 块），Nginx 就会按 valid 时间主动轮询 DNS，自动剔除失效 IP，并支持多 A/AAAA 记录负载均衡。
-
proxy_pass https://origin_backend;即可，不用变量、不依赖 location 级 resolver 作用域 - 支持 SRV 记录，适合高级服务发现场景
- keepalive、health_check 等 upstream 特性可直接复用，变量模式做不到这点
变量 + resolver 看似简单，但容易漏掉作用域、协议头、缓存一致性等细节；upstream resolve 把 DNS 刷新逻辑收归统一管控，更适合关键链路。
