nginx 的 server 块不解决 dns 缓存问题，需用 upstream 块配合 resolver、resolve 参数（1.19+）、健康检查及服务发现机制实现动态解析与节点剔除。
直接用 server 块本身无法解决 DNS 缓存导致的后端节点下线延迟——因为 server 是 Nginx 配置中定义虚拟主机的指令，不参与 DNS 解析或缓存管理。真正起作用的是 upstream 块配合健康检查与 DNS 解析策略。
关键问题定位：DNS 缓存让 Nginx 一直连已下线的 IP
当 upstream 中使用域名（如 backend.example.com）定义服务器时，Nginx 在启动或重载时做一次 DNS 解析，并将结果长期缓存（默认不自动刷新）。若后端节点下线、IP 变更或 DNS 记录已更新，Nginx 仍会持续向旧 IP 发起请求，造成连接超时、502 或请求堆积。
启用动态 DNS 解析（Nginx Plus 或开源版 1.19+）
确保你使用的是 Nginx 1.19 或更高版本（开源版支持基本动态解析），并在 upstream 中配置：
IntoDNS.ai
下载
免费 DNS 与邮件安全分析（IntoDNS.ai）：包括 DNSSEC、SPF、DKIM、DMARC、MTA-STS、BIMI、SMTP STARTTLS、FCrDNS、黑名单、发件人要求及报告。
- 用
resolver指令声明可信 DNS 服务器（如resolver 8.8.8.8 valid=30s;） - 在
server行中使用resolve参数（仅限 Nginx Plus）或改用变量 +proxy_pass动态转发（开源版常用技巧） - 推荐写法（开源版兼容）：
upstream backend {
server backend.example.com:80 resolve;
# 注意：需搭配 resolver 使用，且 Nginx 必须支持 resolver + resolve
}
配合主动健康检查快速剔除失效节点
DNS 刷新有滞后，必须叠加运行时探测：
- 启用
health_check（Nginx Plus）或使用开源模块如nginx_upstream_check_module - 设置合理间隔（如
interval=3s）、失败阈值（rise=2 fall=3） - 检查路径应为轻量接口（如
/healthz），避免依赖 DNS 的后端域名
规避 DNS 缓存的务实替代方案
如果环境受限（如旧版 Nginx 或无法控制 DNS 更新时效），建议绕过域名解析：
- 将后端节点 IP 直接写入
upstream，通过外部编排工具（如 Ansible、K8s Endpoints、Consul Template）实时更新配置并 reload - 使用服务发现集成：Nginx Plus 支持 Consul/Etcd 动态上游；开源生态可用
nginx-upsync-module同步 VIP 或 IP 列表 - 对云环境，优先走内网 SLB 或服务网格 Sidecar，由平台层处理节点生命周期，Nginx 仅面向稳定入口
