最可靠的是$_SERVER['REMOTE_ADDR']，但经代理后变为内网IP；需结合可信代理下的HTTP_X_FORWARDED_FOR（取最后可信IP）或HTTP_X_REAL_IP，并对IPv4/IPv6做合规匿名化（如IPv4掩码/24），同时严格校验IP合法性并全程脱敏日志。
PHP获取客户端IP时，$_SERVER['REMOTE_ADDR']最可靠但不够用
它确实是唯一由Web服务器直接传递、无法被客户端伪造的IP，但遇上Nginx反向代理、CDN或负载均衡，$_SERVER['REMOTE_ADDR']就变成中间节点的内网IP（比如10.0.2.3），完全不是用户真实出口IP。
真正要拿到用户侧IP，得组合读取$_SERVER['HTTP_X_FORWARDED_FOR']或$_SERVER['HTTP_X_REAL_IP']——但这两个字段可被任意篡改，直接信任等于把隐私和风控大门敞开。
- 只在可信代理链环境下才解析
HTTP_X_FORWARDED_FOR，比如你明确知道Nginx配置了proxy_set_header X-Forwarded-For $remote_addr; - 永远不要从
HTTP_X_FORWARDED_FOR取逗号分隔的第一个值（1.2.3.4, 5.6.7.8里的1.2.3.4），攻击者可伪造整个字段；应只取最后一个“可信跳数”后的IP - 用
$_SERVER['HTTP_X_REAL_IP']前，确认上游代理（如Cloudflare）是否开启真实IP透传且该Header不可被客户端设置（部分CDN需配合set_real_ip_from指令）
GDPR/CCPA下，记录IP前必须做匿名化处理
纯IPv4地址（如192.168.1.1）在欧盟被明确认定为个人数据，未经同意存储即违规；IPv6更敏感（通常含设备标识信息）。不匿名就存，等于主动埋雷。
匿名化不是简单删掉最后一位，而是要确保不可逆还原：
立即学习“PHP免费学习笔记（深入）”；
- IPv4：推荐截断最后8位（即掩码
/24），例如192.168.1.123→192.168.1.0；用ip2long()+ 位运算比字符串截取更安全 - IPv6：至少清除最低64位（
/64前缀保留），否则可能残留MAC地址哈希痕迹；PHP可用inet_pton()+unpack()手动清零后半段 - 别用哈希加盐替代匿名化——监管机构已明确指出，可逆/可碰撞的哈希仍属个人数据
filter_var($ip, FILTER_VALIDATE_IP)不能代替IP合法性校验
这个函数只检查格式，不防恶意构造。比如127.0.0.1, 8.8.8.8整体过校验，但实际是攻击者注入的伪造链；再比如0xdeadc0de（十六进制表示）或2130706433（十进制整数）也能通过FILTER_VALIDATE_IP，却可能绕过你的白名单逻辑。
真实场景中必须叠加判断：
- 先用
filter_var()筛出基础格式合法的单个IP（注意传FILTER_FLAG_IPV4或FILTER_FLAG_IPV6） - 再用
ip2long()（IPv4）或inet_pton()（IPv6）验证是否为真实网络地址，排除私有网段（10.0.0.0/8、127.0.0.0/8等）或保留地址 - 若来自
HTTP_X_FORWARDED_FOR，必须限制解析次数（如最多取第3跳之后的IP），并拒绝含IPv6压缩格式（::1）或CIDR标记（192.168.1.1/24）的输入
日志里记IP，比代码里用IP更危险
开发者常忽略：哪怕你在业务逻辑里没存IP，只要Web服务器（Apache/Nginx）或PHP错误日志默认记录$_SERVER['REMOTE_ADDR']，就已构成持续性隐私暴露。尤其当错误日志包含堆栈+请求头时，IP会和用户行为强绑定。
必须立刻检查并调整：
- Nginx中关闭
log_format里的$remote_addr，改用$http_x_real_ip（前提是已做可信代理配置） - PHP-FPM的
access.log默认记IP，需在www.conf里设access.format = "%R - %u %t \"%m %r%Q%q\" %s %f %{mili}d %{kilo}M %C%%"（去掉%a） - 应用层日志（如Monolog）写入前，对
context数组中的IP字段做实时匿名化，别依赖“后期脱敏”
最麻烦的点在于：IP匿名化必须贯穿整个请求生命周期——从入口解析、中间件过滤、数据库写入，到日志落盘，漏掉任一环都可能让合规努力归零。
