ip_hash是Nginx原生会话保持方案，基于客户端IP哈希将请求固定分发至同一后端服务器，适用于内网IP稳定且无共享存储的场景；需在upstream首行配置，不支持weight、backup，IPv4仅取前三段，代理环境下须配合real_ip_module还原真实IP。
ip_hash 是 Nginx 原生支持的轻量级会话保持方案，它不依赖外部存储，而是把同一客户端 IP 的请求“钉”在固定后端服务器上，让 Session 能自然命中。但它不是 Session 共享，只是缓解 Session 丢失的临时策略——适合内网 IP 稳定、暂无共享存储能力的场景。
基础配置写法
只需在 upstream 块首行添加 ip_hash;，其他保持常规反向代理设置即可：
- upstream 必须显式定义多台后端（不能只写 localhost 或单节点），例如：
upstream backend {
ip_hash;
server 10.0.1.10:8080;
server 10.0.1.11:8080;
server 10.0.1.12:8080;
} - ip_hash 必须紧贴 upstream 块开头，不能缩进，也不能和 hash $cookie_jsessionid 等其他 hash 指令共存
- server 行只写 IP:PORT，不加协议（如 http://）或路径
确保真实客户端 IP 可用
若前端有 CDN、WAF、Nginx 代理或多层负载均衡，$remote_addr 默认是上一跳地址，哈希将全部打到同一个后端。必须启用 real_ip_module 还原原始 IP：
A powerful memory management system powered by ReMe that provides persistent cross-session memory, automatic user preference application, and intelligent context compression for OpenClaw.
下载
由 ReMe 驱动的记忆管理系统，支持跨会话记忆持久化、自动应用用户偏好以及智能上下文压缩...
- 在 http 块中配置可信代理段：
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 中传透真实 IP：
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
避开常见失效陷阱
ip_hash 表面简单，但几个关键限制极易导致“配了等于没配”：
- IPv4 地址仅取前 3 段哈希（192.168.1.x 全视为同一 IP），内网 NAT 环境下易造成单台过载
- 不支持 weight、backup、down 等参数；加了 weight 会导致 Nginx 启动报错
- 后端列表顺序或数量变动（如扩容缩容、临时 down 掉一台），所有哈希映射会整体偏移，大量用户 Session “漂移”
- 仅适用于 HTTP upstream；TCP/UDP 四层转发需改用 hash $remote_addr consistent;
比 ip_hash 更稳的替代思路
当业务要求更高可靠性时，建议跳出“绑定 IP”的思路：
- 用 Cookie 哈希替代 IP 哈希：hash $cookie_JSESSIONID consistent;，抗 NAT 和代理干扰更强
- 后端统一接入 Redis 存储 Session（如 PHP 配
session.save_handler = redis），彻底解耦路由与状态 - MinIO、S3 等对象存储集群可放心用 ip_hash，因其分片上传、断点续传等操作天然需要节点一致性
