ip_hash仅基于客户端ip（如$remote_addr）哈希，与url路径、rewrite无关；若需按语义路径等业务维度路由，应改用hash指令配合map或rewrite预处理变量，并启用consistent实现更稳定的会话保持。
Nginx 的 ip_hash 本身不参与 URL 路径处理，也不接受 rewrite 干预其哈希计算过程。它只基于客户端 IP 地址（如 $remote_addr）做哈希，与请求路径、参数、重写结果完全无关。
所以严格来说：
你不能用 rewrite 指令去“在计算 hash 前规范化 URL 路径”来影响 ip_hash 的行为——因为 ip_hash 根本不看 URL 路径。
但如果你的真实需求是：
✅ 让同一类请求（比如相同语义路径）尽量落到同一台后端，同时又希望 URL 路径干净、可读、可标准化（例如 /zh/about 和 /about?lang=zh 统一处理），那就要换思路：
✅ 正确做法：用 hash 指令替代 ip_hash，并用 rewrite 预处理变量
hash 支持任意 Nginx 变量（包括重写后生成的变量），你可以先用 rewrite 规范化路径或提取关键标识，再用 hash 基于该标识做路由。
1. 先用 rewrite 提取/统一语义标识
比如把多语言路径 /zh/xxx、/en/xxx 映射为标准化参数：
location / {
# 将 /zh/about → /about?lang=zh；/en/contact → /contact?lang=en
rewrite ^/([a-z]{2})/(.*)$ /$2?lang=$1&$args last;
# 注意：$args 保留原始查询参数
}
这样所有请求最终都带 lang=xx 参数，且主路径统一。
2. 在 upstream 中用 hash 基于 lang 参数做路由
upstream api_backend {
hash $arg_lang consistent; # 按 ?lang=xx 的值哈希，加 consistent 减少节点变动影响
server 192.168.1.10:8000;
server 192.168.1.11:8000;
server 192.168.1.12:8000;
}
✅ 效果：所有
lang=zh请求固定打到同一台后端，适合语言相关缓存或状态隔离。
3. 更进一步：用 map 提前标准化，避免 rewrite 循环
比 rewrite 更安全、更高效的方式是用 map 提取语言标识：
map $uri $route_lang {
~^/([a-z]{2})/ $1;
default "default";
}
upstream api_backend {
hash $route_lang consistent;
server 192.168.1.10:8000;
server 192.168.1.11:8000;
}
这样无需 rewrite，直接从 URI 提取语言码，性能更好，逻辑更清晰。
❌ 为什么 ip_hash + rewrite 不起作用？
-
ip_hash在请求刚进入 upstream 阶段时就已完成计算，只依赖$remote_addr（或你显式指定的$http_x_forwarded_for等）； -
rewrite发生在location匹配之后、proxy_pass 之前，此时ip_hash已确定目标服务器； - 即使你 rewrite 了 URI，也不会改变
ip_hash的输入源。
⚠️ 补充提醒
-
如果你仍需会话保持（如登录态），但又想按业务维度（而非 IP）路由，建议：
- 用
hash $cookie_session_id（如果前端带 session cookie）； - 或
hash $arg_user_id（API 场景下透传用户 ID）； - 避免强依赖 IP，尤其在 NAT、移动网络环境下 IP 易变。
- 用
ip_hash不支持权重，也不能和weight共存；若需兼顾稳定性与负载能力，hash+consistent是更现代的选择。
不复杂但容易忽略。
