直接用 hash $request_uri consistent 是最简有效的手段，确保相同 uri 请求始终落到同一后端节点，使各节点缓存资源子集、避免重复回源；实测商品详情页缓存命中率可从 65% 提升至 92% 以上。
直接用 hash $request_uri consistent 是最简、最有效的手段。它让相同 URI 请求始终落到同一台后端，使每台机器只缓存自己负责的资源子集，避免多节点重复回源和缓存浪费。实测中，商品详情页集群命中率可从 65% 提升至 92% 以上。
选对哈希键：$request_uri 是静态资源的黄金选择
静态资源的缓存价值取决于“相同 URL 是否总打到同一台后端”，而非“同一用户是否连同一台”。
$request_uri（含路径与查询参数）天然绑定资源粒度，只要字符串一致（注意大小写、编码、参数顺序），哈希结果就稳定。
需规避以下变量：
• $remote_addr：NAT 环境下大量用户共用 IP，易导致负载倾斜，且同一资源被不同用户反复请求时分散打到多台，无法复用缓存
• $time_iso8601、$request_id：每次请求都变，完全失去一致性意义
• $host 或 $http_referer：前者在多域名共用 upstream 时造成资源重复缓存；后者极不稳定
配置必须合规：官方 hash 与第三方 consistent_hash 不兼容
二者是完全不同的模块，不能混用：
• 官方原生支持：hash $request_uri consistent;（来自 ngx_http_upstream_hash_module）
• 第三方模块：consistent_hash $request_uri;（需编译 ngx_http_upstream_consistent_hash）
常见错误：
• 在同一 upstream 块里同时写 hash 和 consistent_hash → Nginx 配置校验报错
• 写成 hash $request_uri consistent_hash 或 consistent_hash$request_uri → 语法错误或静默失效
确认模块已加载：运行 nginx -V 2>&1 | grep -o with-http_upstream_consistent_hash，无输出即未编译进
应对真实场景：参数归一化 + 虚拟节点 + 健康检查
真实流量中，URI 常带干扰参数（如 utm_source、_t=1623456789），导致哈希散列失效：
• 用 map 指令提前过滤：剔除所有 _t=、utm_* 类参数，生成干净的 $clean_uri 再哈希
• 小文件（JS/CSS/图片）用 $uri 足够；大文件（视频分片）建议保留关键 range 参数，否则断点续传可能跨节点失败
• 官方 hash 模式下 weight、backup、max_fails 等参数会被忽略，不可混用
• 第三方 consistent_hash 支持 weight：weight=2 的服务器会自动分配更多虚拟节点，缓解负载不均
• 必须配合主动健康检查（如 check interval=3 rise=2 fall=3 timeout=1），防止异常节点长期滞留哈希环，引发局部缓存失效
