关键在于安全稳定传递识别真实IP：仅信任负载均衡器网段请求，LB覆写X-Forwarded-For，后端按可信跳数反向解析（如取X-Real-IP或X-Forwarded-For倒数第N个IP），云环境需适配厂商规则并禁用客户端伪造头。
在使用负载均衡器（如 Nginx、HAProxy、云厂商 SLB/ALB）后，客户端真实 IP 往往被隐藏，后端服务默认只能看到负载均衡器的内网 IP。要实现基于真实 IP 的访问控制（如限流、黑白名单、地域拦截），关键不是“能不能拿到”，而是“如何安全、稳定、一致地传递和识别真实 IP”。
真实 IP 的来源与可信边界
客户端真实 IP 通常通过 HTTP 头字段（如 X-Forwarded-For、X-Real-IP）由负载均衡器添加。但这些头可被客户端伪造，因此不能直接信任——必须结合连接来源做校验：
- 只接受来自负载均衡器所在网段（如 10.0.0.0/8、172.16.0.0/12 或云厂商指定内网段）的请求，并丢弃其他来源的流量；
- 配置负载均衡器始终覆写 X-Forwarded-For（而非追加），避免客户端注入恶意 IP；
- 若有多层代理（如 CDN → 负载均衡 → 应用），需明确每层只追加自身上游 IP，并约定可信头链（如 Cloudflare 用 Cf-Connecting-IP，阿里云用 X-Forwarded-For + X-Real-IP 组合）。
后端服务中正确提取真实 IP
应用代码不能简单取 X-Forwarded-For 的第一个值。应按“可信跳数”反向解析：
- 若负载均衡器是唯一可信代理（即客户端直连 LB，无 CDN），取 X-Real-IP 最可靠（LB 设置时主动填充）；
- 若存在一层 CDN，则从 X-Forwarded-For 中取倒数第 N 个 IP（N = 可信代理层数），例如：CDN → LB → App，可信跳数为 2，取 X-Forwarded-For 中倒数第二个 IP；
- 推荐在 Web 框架层统一做 IP 解析（如 Spring Cloud Gateway 的 RemoteAddressResolver，或 Django 的 SECURE_PROXY_SSL_HEADER + USE_X_FORWARDED_FOR 配置），避免业务代码重复处理。
基于真实 IP 的访问控制落地要点
拿到可信真实 IP 后，访问控制策略才能生效。实践中需注意：
- 限流组件（如 Redis RateLimiter）键名必须基于真实 IP，而非 socket 远程地址；
- IP 黑白名单应支持 CIDR 格式，并定期更新（如对接威胁情报库）；
- 日志系统需记录真实 IP（替换掉 remote_addr），便于审计与关联分析；
- 对登录、支付等敏感接口，建议叠加设备指纹或行为验证，不单依赖 IP 控制——IP 可能共享（如 NAT 环境）或动态分配（如移动网络）。
云环境下的特殊注意事项
公有云负载均衡器行为与自建不同，需针对性适配：
- 阿里云 SLB 默认不透传客户端 IP，需开启“获取客户端真实 IP”并配合 X-Forwarded-For 使用；
- 腾讯云 CLB 支持直接在监听规则中启用“获取真实 IP”，后端可读取 X-Real-IP；
- AWS ALB 自动设置 X-Forwarded-For，且保证其首项为客户端真实 IP（前提是未开启额外代理）；
- 所有云厂商都建议关闭客户端可写的头字段（如禁用 X-Forwarded-For 的客户端提交），通过 WAF 或 LB 规则拦截非法头。
不复杂但容易忽略：真实 IP 控制的本质是建立可信代理链路，而不是拼凑头字段。每多一层不可信代理，IP 可靠性就下降一级。设计之初就要明确谁是最后一跳可信入口，并围绕它构建整个访问控制体系。
