nginx的ip_hash完全不关心端口号，仅基于$remote_addr（客户端ip）做哈希计算，ipv4取前三段，端口仅用于转发目标，不影响哈希逻辑。
Nginx 的 ip_hash 负载均衡完全不关心端口号，无论后端服务监听的是 80、443、8080 还是其他任意非标准端口，它都只基于客户端 IP 地址（即 $remote_addr）做哈希计算。
也就是说：
✅ 端口信息不会参与哈希运算
✅ ip_hash 的结果只由客户端真实 IP 决定（默认取前三段，C 类网络粒度）
✅ 后端 server 配置中的端口（如 192.168.1.10:8080）仅用于转发目标，不影响哈希逻辑
ip_hash 的哈希输入来源很明确
- 使用变量
$remote_addr，即 Nginx 接收到请求时记录的客户端源 IP - 如果前端有代理（如 CDN、WAF、LB），需确保已通过
X-Forwarded-For或real_ip模块还原真实 IP，否则$remote_addr可能是上一跳地址（如 10.x.x.x），导致哈希失效或集中
常见误解澄清
- ❌ “不同端口会算出不同 hash” → 错误。端口不在哈希 key 中
- ❌ “配置
server 1.1.1.1:3000和server 1.1.1.1:4000会影响 ip_hash 分布” → 不影响。它们只是两个独立 upstream 成员，hash 仍按 client IP 映射到其中一台 - ✅ 若你用
hash $remote_addr;（非ip_hash指令）自定义哈希，也依然不包含端口——除非你手动拼接，比如hash "$remote_addr:$server_port"，但这已不属于ip_hash行为
实际配置中要注意的点
-
ip_hash指令本身不能和weight、backup共存，否则配置校验失败 - 当上游服务器数量变动（如某台 down 掉），原有哈希映射关系会整体偏移，部分客户端可能被重定向到新节点（这是哈希类算法固有缺陷，非端口导致）
- 若业务依赖严格会话保持，且客户端 IP 大量复用（如企业出口 NAT、校园网），建议配合
hash指令 + 更稳定的 key（如cookie SESSIONID或arg_token）替代ip_hash
简单说：端口怎么写，对 ip_hash 来说都是透明的。
