核心是地理识别、动态解析、分组路由三步协同：用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 解析无法区分用户地域，需结合请求上下文做决策：
- 使用
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是否更新
