理解真实客户端 IP 的重要性与基本概念
为何需要真实 IP 以及常见误区
在 Web 应用的日志、限流与审计中，真实客户端 IP是识别请求来源的关键字段。由于前端存在代理、CDN 或负载均衡器，服务端看到的往往是代理入口的 IP，这会导致日志偏差与限流策略失效。
常见误区包括把 REMOTE_ADDR 直接等同于“真实客户端 IP”，以及盲目信任单一头部字段。实际场景是，代理链存在时需要通过头部信息重建来源，才能更准确地定位用户端。
理解头部传递的顺序与信任边界非常重要：在可控的代理链中，通常要尝试还原出尽量靠近用户端的公开 IP，同时避免把代理地址误当成客户端。
代理/负载均衡环境下的判定要点
识别可信的头部与优先级排序
在代理或负载均衡场景，常见的头部有 X-Forwarded-For、X-Real-IP，以及云厂商提供的专有头部如 CF-Connecting-IP、True-Client-IP 等。头部的可信性取决于前端代理对其的处理与信任范围。
要点在于掌握你所处的代理链及其对头部的处理规则。X-Forwarded-For 通常是一个从客户端到最近代理的地址序列，可能会被多次拼接，因此需要结合信任边界来提取最终的客户端来源。
一个常用的策略是：维护一个可信代理清单，从 X-Forwarded-For 列表中筛选出第一个非私有且非受信代理的地址，或在可信代理链中选取靠近客户端的原始 IP。如果没有可用的头部信息，则回退到 REMOTE_ADDR。
在 PHP 中获取真实客户端 IP 的实现方法
从简单到鲁棒的实现
在 PHP 应用中，通常通过 $_SERVER 超全局变量读取头部信息与远端地址。为了在多层代理/负载均衡下尽量正确，需要把 X-Forwarded-For、X-Real-IP 等头部结合起来进行解析。
下面给出一个示例函数，演示如何从常见头部中提取尽量可信的客户端 IP，并保留对代理透明性的处理能力。
代码中的关键点包括：从候选头部构建 IP 列表、过滤私有地址、考虑可信代理边界，以及在头部无法生效时回退到 REMOTE_ADDR。在实际上线时，可以将 $trustedProxies 配置为你前端代理的实际服务器列表来增强鲁棒性。
服务器配置与对接要点
在 Nginx 代理头部传递与信任边界
在 Nginx 端，通过 real_ip_module 来识别并传递真实 IP 给后端应用，是最普遍的做法之一。需要明确两点：一是设定 set_real_ip_from，将可信代理网段纳入；二是使用 real_ip_header 指定读取的头部，必要时开启 real_ip_recursive 以处理嵌套代理链。
http {# 可信代理网段set_real_ip_from 10.0.0.0/8;set_real_ip_from 192.168.0.0/16;# 读取头部用于获取真实IPreal_ip_header X-Forwarded-For;real_ip_recursive on;# 给后端应用传递的头部proxy_set_header X-Real-IP $remote_addr;proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
对于采用 Cloudflare、Apex、或其他云厂商代理的场景，可以在 real_ip_header 中结合厂商提供的头部，如 CF-Connecting-IP，并在信任代理名单中加入对应的网段与代理节点。这样可以在后端继续通过 getClientIp() 等方法进行统一提取。
安全性考量与校验策略
头部伪造检测与防护
头部伪造是常见的攻击面，因此需要对来自代理链的头部进行严格的校验。核心原则是：只信任来自已知代理的头部，并对头部来源进行鉴权管理。
实现要点包括：维护可信代理白名单、对 X-Forwarded-For 的每个 IP 进行 格式校验、并对 私有地址进行过滤，避免错误地将内部地址记录为客户端来源。
在 IPv6 场景下，前端代理链可能混合使用 IPv4/IPv6 地址，因此解析逻辑应具备对两种地址格式的正确处理能力，确保日志与分析不因地址格式混乱而偏离实际来源。
