单纯开启ip_hash不能防IP伪造，它仅实现请求路由；真正防护需构建“真实IP还原+请求头净化+后端强校验”三层防线，包括启用real_ip_module声明可信代理段、首层代理强制覆盖X-Real-IP/X-Forwarded-For、中间层只追加、后端校验Session中IP一致性。
单纯开启 ip_hash 不能防 IP 伪造，它只做请求路由；真正要解决高可用场景下的 IP 伪造风险，必须构建“真实 IP 还原 + 请求头净化 + 后端强校验”三层防线。
确保 $remote_addr 是真实客户端 IP
这是整个防护链的起点。若 Nginx 前面有 CDN、WAF 或内网 LB，它收到的 $remote_addr 往往是代理的内网地址（如 10.0.1.5），此时 ip_hash 会把所有用户哈希到同一台后端，既失效又放大风险。
- 启用
real_ip_module，在http块中明确声明可信代理段：
set_real_ip_from 192.168.0.0/16;<br> set_real_ip_from 10.0.0.0/8;<br> set_real_ip_from 172.16.0.0/12;<br> real_ip_header X-Forwarded-For;<br> real_ip_recursive on;
- 验证是否生效：临时加一条日志格式，检查
access.log中$remote_addr是否已变为公网 IP
透传与净化关键请求头
攻击者可随意伪造 X-Forwarded-For、X-Real-IP 等头，Nginx 默认不校验，必须主动切断滥用路径。
- 最外层代理（如 CDN 回源节点或首跳 Nginx）应强制覆盖：
proxy_set_header X-Real-IP $remote_addr;<br> proxy_set_header X-Forwarded-For $remote_addr;
- 中间层代理只追加、不采信原始值：
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; - 清除不可信头（若后端完全不需要）：
proxy_hide_header X-Forwarded-For;<br> proxy_set_header X-Forwarded-For "";
后端服务必须做 IP 一致性校验
ip_hash 解决的是“请求发给谁”，不是“谁发的请求是真的”。登录、支付、敏感操作等环节，必须由后端独立验证。
- 登录成功后，在 Session 或 JWT 中固化记录
X-Real-IP（即 Nginx 写入的值） - 后续每次关键请求，比对当前请求头中的
X-Real-IP与存储值是否一致 - 不一致时直接拒绝（返回 403），并记录告警；不刷新 Session，不降级处理
- 对运维跳板机等内网固定来源，可配置白名单 IP 段绕过校验
规避 ip_hash 自身的安全盲区
它不是安全机制，几个固有特性反而可能引入新风险：
- IPv4 下仅取前 3 段哈希（
192.168.1.x全视为同一 IP），NAT 环境下大量用户被绑死单台后端 - 一旦某台后端故障，该 IP 段所有用户全部失败，无容错能力
- 建议在严格风控场景中，用
hash $http_x_real_ip consistent;替代ip_hash，提升分布均匀性与稳定性
