unix socket下ip_hash必然失效，因uds不经过tcp/ip栈，$remote_addr恒为127.0.0.1或unix:，无法提取真实客户端ip；应改用hash $http_x_user_id consistent等业务标识哈希，或转向least_conn+redis共享session。
Unix Socket 请求在 Nginx 中不会产生传统意义上的客户端 IP 地址，$remote_addr 的值默认是 127.0.0.1 或空字符串（取决于监听方式），因此 ip_hash 无法正常工作——所有请求会被哈希到同一台后端，或直接退化为轮询（Nginx 会静默忽略 ip_hash 并记录 warn 日志）。
Unix Socket 下 ip_hash 失效的根本原因
ip_hash 依赖客户端网络层源地址参与哈希计算。而 Unix Domain Socket（UDS）是本地进程间通信机制，不经过 TCP/IP 协议栈，Nginx 无法从中提取有意义的“客户端 IP”。即使配置了 set_real_ip_from，也无法还原不存在的远程地址。
- Nginx 日志中
$remote_addr显示为127.0.0.1或unix:（取决于listen unix:/path.sock写法） -
ip_hash指令仍会加载，但哈希输入恒定，导致所有请求映射到同一台 server（例如：3 台后端时，hash("127.0.0.1") % 3 == 0总成立） - 若 upstream 中有
down或节点变动，哈希结果可能波动，但毫无业务意义
可行的替代方案
不能靠 IP，就换可识别、稳定、可控的哈希键：
-
用请求头做 hash：如果上游代理（如另一层 Nginx 或网关）能透传唯一标识（如
X-Request-ID、X-User-ID），在 upstream 中改用hash $http_x_user_id consistent; -
用 URI 或参数做 hash：适用于有明确路由键的场景，例如
hash $request_uri consistent;或hash $arg_uid consistent; - 改用 least_conn 或 round-robin + 共享 Session：既然无法做 IP 粘性，就放弃粘性，转而用 Redis 存 session、JWT 无状态鉴权等后端方案
-
避免 Unix Socket 做负载入口：若必须用 UDS（如容器内高性能通信），建议只用于单实例直连；负载均衡层仍走 TCP 监听（
listen 80），由它接收真实 IP 请求再转发至后端 UDS
验证是否真走 Unix Socket
检查 Nginx 配置中的 listen 指令：
- ✅
listen unix:/var/run/backend.sock;→ 是 UDS，ip_hash 无效 - ✅
listen 127.0.0.1:8000;或listen 80;→ 是 TCP，可正常使用 ip_hash（前提：IP 可还原） - ⚠️ 若同时存在两者，需确认 client 实际连接的是哪个 endpoint
本质上，ip_hash 和 Unix Socket 是互斥的设计场景。选了 UDS，就得接受“无源地址”这一事实，并转向变量哈希或无状态架构。
