nginx 不支持直接对 $request_body 做哈希，因其在 upstream 阶段未读取请求体，导致 hash $request_body 失效；应提取关键参数（如 $arg_user_id）进行一致性哈希分流。
Nginx 本身不支持直接对 $request_body 做哈希（因为请求体默认未读取、不可见），所以“hash $request_body”不能直接用在 upstream 的 hash 指令中——这会导致 Nginx 启动失败或哈希值恒为 0。要实现基于请求体内容的稳定哈希分流，必须绕过这个限制，核心思路是：**提前读取并提取关键字段，再用可访问的变量参与哈希**。
为什么 $request_body 在 upstream hash 中不可用
Nginx 在 upstream 块解析阶段（即选择后端服务器时）尚未读取请求体。此时 $request_body 为空或未定义，hash $request_body 实际等价于 hash ""，所有请求都会被分到同一个 upstream server，完全失去分流意义。
替代方案：用 $body_bytes_sent 或 proxy_set_header 传递摘要
这不是真正哈希请求体，而是规避限制的常用折中方式：
- 不推荐：$body_bytes_sent —— 它是响应体大小，与请求体内容无关，无法保证一致性，仅能按体积粗略分流，不满足“参数哈希”需求。
-
可行但需后端配合：用 Lua 或外部模块计算摘要 —— 例如通过
ngx_lua的ngx.req.read_body()读取 body，用ngx.md5()或ngx.sha1()计算哈希，再设为自定义 header（如X-Body-Hash），最后在upstream hash中使用该 header 变量。
实用推荐：提取关键参数做哈希（最稳定可靠）
绝大多数业务场景中，“参数哈希分流”的真实诉求是：相同业务参数（如订单号、用户 ID、商品 SKU）的请求落到同一台后端，保障会话/缓存/幂等性。这时应避免操作整个 $request_body，转而解析结构化参数：
-
POST JSON 请求：启用
lua_need_request_body on;（慎用，影响性能），用 Lua 解析 JSON 并提取字段（如data.userId），存入$my_user_id变量； -
表单或 query-like POST：用
map+ 正则从$request_body提取（需先确保 body 已读取）； -
更稳妥做法：统一要求客户端把关键参数放在 URL query 或 header 中 —— 例如
/api/pay?order_id=20240520123456，直接用hash $arg_order_id，零依赖、高性能、100% 可靠。
完整可运行示例（基于 query 参数哈希）
这是生产环境最推荐的方式：
upstream backend {
hash $arg_user_id consistent; # 一致性哈希，防节点增减抖动
server 10.0.1.10:8080;
server 10.0.1.11:8080;
server 10.0.1.12:8080;
}
<p>server {
location /api/ {
proxy_pass <a href="https://www.php.cn/link/65b5b8d1f89bf53a5713bc3afdd83e9e">https://www.php.cn/link/65b5b8d1f89bf53a5713bc3afdd83e9e</a>;
proxy_set_header Host $host;
}
}</p>
客户端调用：POST /api/order?user_id=10086 → 所有含 user_id=10086 的请求始终打到同一台后端。
不复杂但容易忽略：真正的“基于请求体哈希”不是配置问题，而是架构取舍问题。优先让参数显式暴露，比硬啃 $request_body 更健壮、更易调试、更少踩坑。
