nginx需结合可信代理配置与realip模块才能获取用户真实ip：七层用x-forwarded-for配合set_real_ip_from和real_ip_recursive；四层必须启用proxy protocol；后端应直接读取getremoteaddr()等修正后变量，而非手动解析头。
在 Nginx 作为负载均衡器或反向代理的场景下，后端服务默认只能拿到 Nginx 自身的 IP（即 $remote_addr），而不是用户真实 IP。这是因为 TCP 连接由 Nginx 与后端重建，原始客户端 IP 在网络层已丢失。要准确还原，需结合协议层级、可信代理范围和头字段处理三方面协同配置。
七层 HTTP/HTTPS：靠 X-Forwarded-For + realip 模块校验
这是最常见也最需谨慎的方案。前端代理（如云 SLB、CDN 或上一级 Nginx）会在请求头中添加 X-Forwarded-For（XFF），格式为：X-Forwarded-For: 203.0.113.5, 198.51.100.2, 192.168.10.1，最左边是用户真实 IP。
但仅读取 XFF 不安全——该头可被客户端随意伪造。必须配合 Nginx 的 http_realip_module 模块做可信链路校验：
- 用 set_real_ip_from 明确声明哪些 IP 是可信代理（例如云厂商 SLB 网段：
100.64.0.0/10或内网 LB 地址） - 用 real_ip_header X-Forwarded-For 指定从哪个头提取 IP
- 开启 real_ip_recursive on，让 Nginx 从 XFF 列表中“剥掉”可信代理 IP 后，取剩余第一个作为真实客户端 IP
- 配置生效后，$remote_addr 就自动变为真实用户 IP，日志、限流、访问控制等逻辑可直接使用，无需改应用代码
四层 TCP/UDP：优先用 Proxy Protocol
当负载均衡工作在四层（如 LVS、阿里云 TCP 型 SLB、腾讯云 CLB 四层模式），无法修改 HTTP 头，XFF 完全不可用。此时必须启用 Proxy Protocol：
- 在负载均衡器侧开启 Proxy Protocol v1 或 v2（文本或二进制格式）
- 在 Nginx 的 listen 指令中添加
proxy_protocol，例如：listen 80 proxy_protocol; - 同时配置 real_ip_header proxy_protocol，并仍需 set_real_ip_from 限定只信任来自 LB 的连接
- 这样 Nginx 能在 TCP 握手阶段解析出原始客户端 IP，并正确覆盖 $remote_addr
后端服务也要配合：不依赖 Header 字符串解析
即使 Nginx 配置正确，如果后端应用（如 Java、Python、Node.js）仍用 request.getHeader("X-Forwarded-For") 手动拆分字符串，就绕过了 realip 模块的安全校验，可能被伪造头欺骗。
推荐做法是：
- Java 应用：使用
request.getRemoteAddr()—— 此时它返回的是 realip 模块修正后的 IP，不是原始 socket 地址 - Python（如 Flask）：用
request.remote_addr，前提是 WSGI 服务器（如 Gunicorn/Nginx）已透传 - 避免在业务代码里解析 XFF 或 X-Real-IP 字符串，除非你自行实现完整的可信代理白名单校验逻辑
额外提醒：CDN 和多层代理的典型陷阱
如果流量路径是「用户 → CDN → WAF → SLB → Nginx → 应用」，注意：
- CDN 和 WAF 通常也会往 XFF 追加自身 IP，导致 XFF 很长；realip 模块的 real_ip_recursive on 就是用来逐层剔除这些可信中间节点的
- 务必确认所有中间设备都属于 set_real_ip_from 列出的网段，漏掉任一环，真实 IP 就可能被污染
- 阿里云 SLB 七层默认不开启 XFF 透传，需在控制台手动打开；四层则默认支持，且更可靠
- 本地测试时，若用 curl 加
-H "X-Forwarded-For: 1.2.3.4"，只要请求来源不在 set_real_ip_from 范围内，realip 模块会直接忽略该头，保障安全
