nginx通过geo模块识别ip地域并动态proxy_pass至对应upstream集群，实现海内外流量分发，再结合dns地理解析兜底，形成“dns就近+nginx路由”双层区域化架构。
Nginx 本身不直接识别用户地理位置，但结合 geo 模块、map 指令和反向代理，就能实现海外节点与国内节点的区域化多站点管理——核心是“DNS 兜底 + Nginx 路由决策”，不是靠单台 Nginx 跑所有地域服务，而是让它智能分发请求到对应地域的后端集群。
用 geo 指令区分国内/海外流量
Nginx 的 geo 模块可基于客户端 IP 归属地设置变量（如 $region），无需外部数据库。常见做法是：
- 把中国主流公网 IP 段（如
1.0.1.0/24、110.0.0.0/8、120.0.0.0/8等）归为cn - 其余 IP 默认设为
overseas - 注意：IP 库需定期更新，生产环境建议配合 MaxMind GeoLite2 或商业 IP 库做离线导入
示例配置（放在 http { } 块顶层）：
geo $region {
default overseas;
1.0.1.0/24 cn;
110.0.0.0/8 cn;
120.0.0.0/8 cn;
202.96.0.0/16 cn;
# 更多 CN 段可从 APNIC 或 CNNIC 获取
}
按地域定义 upstream 后端集群
每个地域对应一个 upstream 组，指向部署在该区域的真实服务节点（可以是物理机、容器或云函数）：
-
upstream cn_backend→ 指向华东、华北、华南的 Nginx 或应用服务器（如10.10.1.10:8080,10.10.2.20:8080） -
upstream overseas_backend→ 指向新加坡、东京、法兰克福等海外节点（如172.20.5.100:8080,172.20.6.200:8080）
关键点：
- 各
upstream内支持健康检查（max_fails=3 fail_timeout=30s） - 推荐启用
keepalive 32复用长连接，降低 TLS 握手开销 - 若后端是 HTTPS，
proxy_pass https://...需额外配证书信任链
主 server 块中动态 proxy_pass
不再为每个地域写独立 server，而是在统一域名（如 app.example.com）下，根据 $region 变量路由：
server {
listen 80;
listen 443 ssl;
server_name app.example.com;
ssl_certificate /etc/nginx/ssl/app.example.com.crt;
ssl_certificate_key /etc/nginx/ssl/app.example.com.key;
location / {
proxy_pass http://$region;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
}
这里 proxy_pass http://$region 会自动展开为 http://cn_backend 或 http://overseas_backend，Nginx 在运行时完成解析。
补充建议：DNS 层协同更稳
单靠 Nginx geo 有局限（比如用户走代理、IP 归属不准、首次请求延迟）。实际高可用架构通常叠加 DNS 策略：
- 主域名
app.example.com在 DNS 服务商（如 Cloudflare、阿里云云解析、AWS Route 53）开启「地理就近解析」 - 将中国用户解析到「国内主 Nginx 入口 IP」，海外用户解析到「海外主 Nginx 入口 IP」
- Nginx 层作为第二道路由，兜底处理跨区异常（如海外用户误连国内入口，仍可被
geo重定向到海外后端）
这样既减少单点压力，又提升首屏加载速度和故障隔离能力。
不复杂但容易忽略
