Nginx 默认对域名仅首次解析并长期缓存IP，导致后端IP变更后出现502或超时；解决核心是实现按需重解析、可控过期与自动容错，可行路径包括变量+resolver动态解析、upstream动态绑定、健康检查自动剔除及服务发现替代方案。
Nginx 在高可用架构中代理后端服务时，若 proxy_pass 或 upstream 直接使用域名（如 api.example.com），默认只在首次请求或 reload 时做一次 DNS 解析，并长期缓存 IP 地址。当后端服务 IP 变更（如云实例伸缩、K8s Pod 重建、CDN 节点轮换），Nginx 仍持续转发到旧 IP，导致 502、超时或部分请求失败——这本质是DNS 缓存未及时更新，而非连接池或健康检查失效。
要真正解决高可用场景下的域名解析缓存失效问题，核心不是“清缓存”，而是让 Nginx 按需重解析、可控过期、自动容错。以下是关键可行路径：
✅ 使用变量 + resolver 实现每次请求级动态解析
这是最轻量、兼容性最好的方案，适用于大多数反向代理场景。
- 必须用变量承载域名（如
set $backend "api.example.com";），再通过proxy_pass http://$backend;触发解析 -
resolver必须与变量同作用域（推荐写在location或server块内，避免旧版本不支持全局 resolver） - 设置合理的
valid时间（建议 10–30 秒），既避免 DNS 频繁查询，又保障 IP 变更快速生效
location /api/ {
resolver 8.8.8.8 valid=20s;
set $backend "api.example.com";
proxy_pass http://$backend:8080;
proxy_http_version 1.1;
}⚠️ 注意：
proxy_pass http://api.example.com;（字面量写法）永远静态；resolver写在http块但变量在location中使用，可能因作用域不匹配而失效。
✅ 用 upstream + 动态 resolver（适合需负载均衡的场景）
单纯变量无法实现权重、健康检查、连接复用等能力。可通过 upstream 块配合 resolver 和 zone 实现有限动态性。
- Nginx 1.19.10+ 支持
upstream内嵌resolver（需开启http_upstream_dynamic模块或使用 OpenResty） - 更通用做法：用变量 +
upstream名间接绑定，或借助lua-resty-dns等模块做运行时解析 - 生产推荐组合：
upstream定义 +keepalive+health_check（需ngx_http_upstream_health_check_module或商业版）
upstream dynamic_backend {
zone backend 64k;
# 不直接写 server 域名！留空或用 placeholder，由 resolver + 变量控制
}
server {
location / {
resolver 10.96.0.10 valid=5s; # K8s CoreDNS
set $svc "user-svc.default.svc.cluster.local";
proxy_pass http://dynamic_backend;
# 后续通过 Lua 或外部服务注入真实地址
}
}✅ 启用上游健康检查 + 失败自动剔除
即使 DNS 解析滞后，也能靠运行时探测规避故障节点。
-
max_fails=3 fail_timeout=10s可让 Nginx 在连续失败后临时屏蔽该 IP（注意：仅对已解析出的 IP 生效） - 配合
slow_start=30s避免新 IP 上线即遭洪峰冲击 - 若用
upstream，还可加least_conn或ip_hash提升分发合理性
upstream legacy_backend {
server api.example.com:8080 max_fails=3 fail_timeout=10s slow_start=30s;
keepalive 32;
}? 提示：该方式不能解决“解析到已下线 IP”的根本问题，但能显著降低影响窗口，是动态 DNS 的重要补充。
✅ 替代方案：放弃域名，改用服务发现机制
在云原生或微服务环境中，硬编码域名本身就不符合高可用设计原则。
- Kubernetes：直接用 ClusterIP Service 名 + CoreDNS，配合短
valid=5s - Consul/Etcd：集成
nginx-upstream-controller或用 Lua 调用/v1/health/service/xxx接口刷新 upstream - API 网关层统一处理服务注册与发现，Nginx 仅作流量入口，不参与服务寻址
不复杂但容易忽略
