使用 ip_hash 策略解决多服务器登录态丢失的核心做法是：在 nginx 的 upstream 块中配置 ip_hash，确保来自同一客户端 ip 的请求始终被转发到同一台后端服务器。这样后端服务器可以基于本地存储（如内存或本地文件）维护会话状态，从而避免因为请求分散到不同服务器而导致的登录态失效。
Nginx upstream 中如何配置 ip_hash
在 Nginx 配置文件中的 upstream 模块内添加 ip_hash 指令即可启用该策略。这会将客户端 IP 地址作为哈希键，计算后映射到固定的后端节点。配置完成后，Nginx 会维持这种映射关系，除非后端节点状态发生剧烈变化（如全部宕机重启）。
# nginx.conf
http {
upstream backend_servers {
ip_hash;
server 192.168.1.10:8080;
server 192.168.1.11:8080;
server 192.168.1.12:8080;
}
server {
listen 80;
location / {
proxy_pass http://backend_servers;
}
}
}
上述配置中，ip_hash 位于 upstream 块的第一行。当用户访问时，Nginx 会根据其源 IP 计算哈希值，并固定选择列表中的某一台服务器。例如，IP 为 10.0.0.5 的用户可能始终被路由到 192.168.1.10。只要该服务器在线，用户的会话数据（如存储在内存中的 Session ID）就能保持一致。
ip_hash 对 IPv6 和负载均衡的影响
ip_hash 默认支持 IPv4 和 IPv6。对于 IPv6，它通常使用前 96 位地址进行哈希计算，以避免因动态 IP 分配导致的前缀变化影响稳定性。然而，这种策略会导致负载不均，因为某些 IP 段的用户可能更集中地映射到少数几台服务器。此外，如果后端服务器宕机，Nginx 会将受影响的用户重新哈希到其他可用服务器，导致这部分用户的登录态暂时丢失。
# 验证 ip_hash 行为 # 假设后端有三个节点 A, B, C # 用户 X (IP: 1.1.1.1) -> 哈希计算 -> 节点 A # 用户 Y (IP: 2.2.2.2) -> 哈希计算 -> 节点 B # 用户 Z (IP: 3.3.3.3) -> 哈希计算 -> 节点 A # 如果节点 A 宕机： # 用户 X 和 Z 的请求将被重新分配到 B 或 C # 此时，如果后端依赖本地内存存储 Session，X 和 Z 将丢失登录态
在实际部署中，建议监控后端服务器的负载情况。如果发现负载严重不均，可以考虑结合 least_conn 或其他负载均衡算法，或者使用外部会话存储（如 Redis）来共享会话数据，从而彻底消除对 ip_hash 的依赖。
后端服务器宕机时的具体表现与恢复
当使用 ip_hash 且后端服务器依赖本地会话存储时，一旦某台服务器宕机，原本映射到该服务器的用户会被重新分配到其他服务器。由于新服务器没有这些用户的会话数据，用户会表现为“突然退出登录”。Nginx 会在检测到后端节点不可用后，自动将流量切换到其他健康节点，但这个过程是瞬时的，用户无感知，只是会话状态不连续。
