核心是地理识别、动态解析、分组路由三步协同：用geo或map识别用户地域，upstream中域名加resolve实现运行时dns解析，再通过变量proxy_pass动态路由至对应地域集群。

要用动态DNS解析配合 upstream 实现跨地域集群分流，核心不是堆配置，而是让 Nginx 在运行时“看懂”用户从哪来、“知道”后端在哪、还能“自动换路”。关键在于三步协同：地理识别 + 动态解析 + 分组路由，缺一不可。

按地域划分 upstream 组，而非写死 IP

直接在 upstream 里写死各区域后端地址，会失去弹性。正确做法是为每个地域建独立 upstream 块，并用变量驱动流量走向：

• 例如定义 upstream bj_backend 和 upstream us_backend，各自只包含北京或美国可用的服务域名（如 api-bj.internal、api-us.internal）
• 每个 server 行末尾必须加 resolve，比如：server api-bj.internal:8080 resolve;
• 确保 http 块顶层已声明 resolver，且 valid 值匹配后端变更节奏（云环境建议 valid=15s–30s）

用 geo 或 map 模块识别客户端来源

仅靠 DNS 解析无法区分用户地域，需结合请求上下文做决策：

Nginx Config Linter

对 Nginx 配置文件进行语法检查、验证和安全、性能审计。

下载

• 使用 geo 指令基于客户端 IP 归属地打标，例如：geo $client_region { default ""; 202.96.0.0/16 "cn"; 192.0.2.0/24 "us"; }
• 更灵活的方式是用 map 结合请求头（如 X-Forwarded-For 或 CDN 注入的 X-Real-IP）映射目标 upstream 变量：map $client_region $upstream_group { "cn" "bj_backend"; "us" "us_backend"; default "bj_backend"; }
• 最终在 proxy_pass 中引用变量：proxy_pass http://$upstream_group;

启用健康检查与故障兜底机制

跨地域场景下网络抖动、DNS 延迟、后端临时不可达更常见，不能只靠 resolve：

• 每个 server 行加上 max_fails=2 fail_timeout=15s，让 Nginx 主动剔除短时失联节点
• 配置 proxy_next_upstream error timeout http_502 http_504，失败时自动切到同组其他节点
• 若某地域所有节点都不可达，可设置 fallback upstream（同样带 resolve），避免全局中断
• 慎用 backup：它不参与负载均衡，但若其后端域名未配 resolve，就可能长期指向过期 IP

验证是否真正生效，别只看配置对不对

很多问题出在“以为跑起来了”，其实没动：

• 确认 Nginx 版本 ≥ 1.19.9：nginx -v
• reload 后观察 error.log：tail -f /var/log/nginx/error.log | grep resolving，应看到类似 resolving "api-bj.internal", resolver: 114.114.114.114:53
• 手动触发一次 DNS 变更（如改 CoreDNS 配置并 reload），等待 valid 时间后，用 curl -I 测试响应头中 X-Upstream-Addr 是否更新