ip_hash不支持多域名共享会话保持，需共用同一upstream块并统一还原真实IP；若后端Session未共享或CDN/HTTPS配置不一致，仍会导致会话分裂；推荐改用cookie哈希、Redis共享Session或JWT无状态方案。
ip_hash 本身不支持“多域名共享会话保持”——它按客户端 IP 绑定后端，和域名无关。不同域名只要走同一个 upstream 块，就能复用同一套 ip_hash 映射规则；但若各域名用了独立的 upstream，则彼此隔离，无法共享会话逻辑。
让多个域名共用一套 ip_hash 路由
关键不是配置“跨域名”，而是确保它们指向同一个 upstream 块：
- 所有域名的 proxy_pass 必须指向同一个 upstream 名称（例如
http://shared_backend） - 该 upstream 块只定义一次，且开头明确写
ip_hash; - 避免为每个 server 块单独定义同名但内容不同的 upstream，Nginx 不会合并，实际生效的是最后加载的那个
真实 IP 必须统一还原
多个域名可能经过不同路径（如 www.example.com 走 CDN，api.example.com 直连），若 $remote_addr 不一致，ip_hash 映射就会分裂：
- 在 http 块顶层 配置统一的 real_ip 规则：
set_real_ip_from 192.168.0.0/16;set_real_ip_from 10.0.0.0/8;real_ip_header X-Forwarded-For; - 所有涉及 proxy_pass 的 location 中，透传头信息：
proxy_set_header X-Real-IP $remote_addr;proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
注意域名差异带来的副作用
看似共享，但以下情况仍会导致会话“不一致”：
- 用户用 www.example.com 登录，又用 api.example.com 请求接口——如果后端应用未打通 Session 存储（如没共用 Redis），即使路由到同一台机器，Session 数据也不互通
- HTTP 和 HTTPS 的 server 块若未共用 upstream，或启用了不同 proxy_set_header，可能导致部分请求的真实 IP 解析失败
- 某些 CDN 对不同子域设置不同缓存策略或 header 过滤，意外丢弃了 X-Forwarded-For
更可靠的替代方案
当真正需要“多域名间用户态一致”时，ip_hash 是治标不治本：
- 改用 cookie 哈希：
hash $cookie_session_id consistent;，依赖后端写入的标准 session cookie，天然跨子域（需 Cookie Path 和 Domain 设置合理） - 后端统一接入 Redis 或数据库存储 Session，所有域名后端读写同一份状态，路由方式可彻底放开（轮询、least_conn 等）
- 前端统一管理登录态（如 JWT 存 localStorage + 全域 API 请求带 Authorization header），后端无状态，完全规避会话保持问题
