server块本身无法解决dns缓存导致的后端下线延迟，因其仅定义虚拟主机和路由规则，不参与dns解析、缓存管理或健康检查；真正需调整的是upstream块配合resolver、resolve参数（1.19+）、健康检查及服务发现机制实现动态解析与节点剔除。

server 块本身无法解决 DNS 缓存导致的后端下线延迟。 它只负责定义虚拟主机和请求路由规则，不参与 DNS 解析、缓存管理或上游节点健康状态判断。真正需要调整的是 upstream 块及相关机制。

为什么 server 块不起作用

当 Nginx 配置中在 proxy_pass 指令里直接写域名（如 proxy_pass http://backend.example.com;），Nginx 实际上会在启动或 reload 时做一次 DNS 查询，并将结果长期缓存——这个行为由 resolver 和 upstream 的解析策略控制，与 server 块无关。即使你在多个 server 块里重复使用相同域名，也不会触发额外解析或刷新。

正确解法：用 upstream + resolver + resolve

必须把后端地址移到 upstream 块中，并启用动态解析能力：

IntoDNS.ai

免费 DNS 与邮件安全分析（IntoDNS.ai）：包括 DNSSEC、SPF、DKIM、DMARC、MTA-STS、BIMI、SMTP STARTTLS、FCrDNS、黑名单、发件人要求及报告。

下载

• 确保 Nginx 版本 ≥ 1.19（开源版支持基础动态解析）
• 在 http 或 stream 上下文中配置 resolver，例如：
  resolver 8.8.8.8 valid=30s;
• 在 upstream 中使用 resolve 参数：
  

  upstream backend {<br>  server backend.example.com:80 resolve;<br>}

• proxy_pass 指向该 upstream 名称，而非直接写域名

必须搭配健康检查才能快速剔除失效节点

DNS 刷新有最小时间粒度（如 30 秒），不能替代运行时探测：

• 开源版推荐接入 nginx_upstream_check_module，配置轻量健康接口（如 /healthz）
• 设置合理参数：interval=3s fall=3 rise=2，避免误判
• 健康检查路径应直连 IP，不依赖域名解析，否则形成循环依赖

更稳妥的替代方案

若无法升级 Nginx 或对稳定性要求极高，建议绕开 DNS 解析环节：

• upstream 中直接写后端真实 IP 列表，通过外部工具（Ansible、K8s Endpoints、Consul Template）自动更新配置并 reload
• 接入服务发现系统：Nginx Plus 支持 Consul/Etcd；开源可用 nginx-upsync-module 同步动态 IP 列表
• 避免在生产环境长期依赖域名作为 upstream 地址