真实客户端IP不能直接取XFF第一个值，因其可被任意伪造；必须由最外层可信代理用$remote_addr覆盖XFF，后续代理仅追加，后端应优先读X-Real-IP或严格校验XFF链路。
真实客户端 IP 不能靠 X-Forwarded-For（XFF）头直接取第一个值，因为这个头可被任意篡改。关键在于信任链的起点——最外层代理必须用 $remote_addr 覆盖 XFF，后续每一层只追加、不采信前端传来的 XFF 值。
为什么 X-Forwarded-For 容易被伪造
X-Forwarded-For 是 HTTP 扩展头，RFC 并未强制校验，客户端或中间人可在请求发出前手动添加或修改它。比如用 Postman 发起请求时带上：
X-Forwarded-For: 192.168.1.100, 203.0.113.5
如果后端无防护，直接取第一个 IP，就会把伪造地址当作真实来源。而 $remote_addr 是 Nginx 与上游建立 TCP 连接时获取的对端地址，无法在应用层伪造——三次握手失败就根本发不出 HTTP 请求。
单层代理：最外层必须重置 XFF
当 Nginx 直接面向公网（如作为 CDN 或 WAF 后的第一跳），它收到的 $remote_addr 就是真实客户端 IP（或上一级可信代理 IP）。此时应强制覆盖 XFF，丢弃客户端可能提交的任何伪造值：
proxy_set_header X-Forwarded-For $remote_addr;- 同时建议设置
proxy_set_header X-Real-IP $remote_addr;，供后端程序直接读取 - 禁用
$proxy_add_x_forwarded_for——它会拼接原始 XFF，引入风险
多层代理：逐级构建可信链
典型内网架构如：用户 → CDN → WAF → Nginx1（接入层） → Nginx2（业务层） → 应用。只有最外层（CDN/WAF）能接触真实用户 IP；中间每层都只能信任其直连上游的 $remote_addr。
-
第一层代理（对外）：用
$remote_addr设置 XFF，例如proxy_set_header X-Forwarded-For $remote_addr; -
第二层及以内代理：使用
$proxy_add_x_forwarded_for，即“把上游传来的 XFF 拼上自己的$remote_addr”，格式为：client_ip, proxy1_ip, proxy2_ip - 后端应用应只取 XFF 头中最左边第一个 IP（前提是第一层代理已严格覆盖），或更稳妥地读取
X-Real-IP
后端代码如何安全取 IP
不要写“先读 XFF，再 fallback 到 RemoteAddr”这类兜底逻辑——那会让伪造头生效。正确做法是明确信任来源：
- Java 示例：
request.getHeader("X-Real-IP")（前提是 Nginx 已设X-Real-IP $remote_addr） - PHP 示例：
$_SERVER['HTTP_X_REAL_IP'] ?? $_SERVER['REMOTE_ADDR']，但注意REMOTE_ADDR在代理后是上一跳 IP，仅作兜底 - 禁止解析 XFF 字符串并 split 取首项——除非你控制了全链路所有代理且确认首项不可篡改
