nginx的ip_hash无法跨越cdn生效是设计使然，因cdn隐藏真实ip导致所有请求看似来自同一边缘节点；需通过set_real_ip_from和real_ip_header信任cdn网段并提取x-forwarded-for中的原始ip，再用map提取后配合hash指令实现基于真实客户端ip的一致性哈希。
ip_hash 本身无法跨越 CDN 边缘节点生效，这不是故障，而是设计使然 —— 它只作用于 Nginx 接收到的真实客户端 IP，而 CDN 会隐藏真实 IP，导致所有请求看起来都来自同一个边缘节点 IP，ip_hash 失效。
确认真实客户端 IP 是否被正确传递
CDN 通常通过 X-Forwarded-For 或 X-Real-IP 头携带原始客户端 IP。Nginx 默认不会用这些头做 ip_hash，需显式配置：
- 在 upstream 块中不能直接用 $remote_addr（这是 CDN 节点 IP），必须改用从请求头提取的原始 IP
- 先在 http 或 server 块中用 set_real_ip_from 声明可信 CDN 网段，并启用 real_ip_header
- 例如：若 Cloudflare 的可信 IP 段已知，添加：
set_real_ip_from 173.245.48.0/20;
set_real_ip_from 103.21.244.0/22;
real_ip_header X-Forwarded-For;
改用基于真实 IP 的 hash 策略（非 ip_hash）
ip_hash 是硬编码逻辑，不支持变量。要实现“按原始客户端 IP 哈希”，需换用 hash 指令：
- 定义 upstream 时，使用 hash $remote_addr consistent; 不行（仍是 CDN IP）
- 正确做法：先用 map 提取可信原始 IP，再 hash
map $http_x_forwarded_for $client_ip {
~^(\d+\.\d+\.\d+\.\d+) $1;
default $remote_addr;
}
upstream backend {
hash $client_ip consistent;
server 192.168.1.10:8080;
server 192.168.1.11:8080;
} - 注意：X-Forwarded-For 可能被伪造，务必配合 set_real_ip_from + real_ip_recursive on 保证只信任 CDN 添加的最左 IP
验证是否生效的实操方法
别只看日志或后端 session，要端到端确认：
- 用 curl 模拟不同客户端，带上不同 X-Forwarded-For：
curl -H "X-Forwarded-For: 1.2.3.4" https://yoursite.com/api
curl -H "X-Forwarded-For: 5.6.7.8" https://yoursite.com/api - 在 Nginx access_log 中记录 $client_ip 和 upstream_addr：
log_format debug '$client_ip → $upstream_addr'; - 检查两次请求是否命中同一台后端；若始终打到同一台，说明 hash 生效；若随机，则 map 或 real_ip 配置有误
替代方案：用 Cookie 或 JWT 实现会话粘性
如果客户端 IP 不稳定（如移动网络出口频繁变化），基于 IP 的一致性哈希仍可能抖动。更健壮的做法是：
- 用 sticky cookie（需 nginx-plus）或开源模块 nginx-sticky-module-ng
- 或由业务层签发带用户标识的 JWT，在 Nginx 中用 auth_request 或 lua-resty-jwt 解析后 hash uid 字段
- CDN 自身也常提供“会话保持”功能（如 Cloudflare Load Balancing 的 Session Affinity），优先查 CDN 控制台设置
