接入高防后源站日志看不到真实客户端，根因是高防节点回源时用自己的IP重建连接，解决办法是让高防在回源请求里携带原始客户端IP，并在源站侧通过XFF或TOA把真实IP解析出来写进日志。
接入高防后源站日志看不到真实客户端怎么办先从回源方式查起
接入高防以后，源站Nginx日志里清一色都是高防节点IP，这种现象相当普遍，用户请求先到高防清洗中心，清洗后的流量再转发到源站，源站跟高防之间是一条全新的TCP连接，$remote_addr自然就成了高防节点的出口IP。
这不是配置错误，是高防回源机制本身决定的，想解决,得先搞清楚你买的高防IP是哪种回源模式。
- 七层HTTP回源：高防把用户请求完整转发给源站，真实IP可以放在
X-Forwarded-For头里带过来。 - 四层TCP转发：高防只转包，不改应用层数据，拿真实IP得靠TOA或Proxy Protocol这类底层协议辅助。
排查时打开高防控制台，找到“回源配置”或“转发规则”页面，看有没有类似“传递客户端IP”“回源带XFF”的开关，大多数高防厂商默认不开启这个选项，需要手动打开，如果控制台找不到相关功能，直接提单问技术支持要回源IP段和“是否支持携带客户端IP”的明确答复。
确认完回源模式,再按下面章节操作。
高防回源X-Forwarded-For配置方法：nginx与Apache实操
HTTP业务场景下，最通用的方案就是让高防在回源时把客户端IP写进X-Forwarded-For请求头,源站再通过解析这个头把真实IP记录进访问日志。
nginx使用realip模块恢复真实客户端IP
Nginx默认编译多数带了http_realip_module,先确认一下：
nginx -V 2>&1 | grep realip
有输出就说明模块可用,然后在nginx配置的http块里加上以下内容：
set_real_ip_from 1.2.3.0/24; # 换成你高防厂商的回源网段 real_ip_header X-Forwarded-For; real_ip_recursive on;
这里set_real_ip_from是关键，它告诉nginx哪些来源的请求是可信的，只有来自高防回源网段的请求，才允许用XFF里的值覆盖
$remote_addr。real_ip_recursive on的作用是从右往左逐级剥离代理地址,取第一个非可信IP作为真实客户端IP。
日志格式也要同步调整，默认的combined格式不记录XFF头：
log_format main '$http_x_forwarded_for - $remote_addr - [$time_local] "$request" "$http_user_agent"'; access_log /var/log/nginx/access.log main;
保存配置后执行nginx -t检查语法，没问题再nginx -s reload，这时候再看日志，$remote_addr已经能显示真实用户IP了。
Apache使用mod_remoteip恢复真实客户端IP
Apache服务器用mod_remoteip模块实现类似效果，Ubuntu/Debian系统执行：
a2enmod remoteip
然后在虚拟主机配置里加：
RemoteIPHeader X-Forwarded-For RemoteIPTrustedProxy 1.2.3.0/24
日志格式把%h改成%a，%a会输出经过remoteip模块处理后的真实IP：
LogFormat "%a %l %u %t "%r" %>s %b "%{Referer}i" "%{User-Agent}i"" combined
重启Apache后验证,日志中的客户端地址就恢复正常了。
高防IP转发模式下拿真实IP还得靠TOA或Proxy Protocol
很多高防套餐走的是四层转发，端口映射到源站IP，源站收到的HTTP请求本身没有经过高防的应用层改写，XFF头根本不存在，行业共识认为,这种场景下能用TOA就优先用TOA。
TOA的原理是在TCP握手时通过自定义option字段携带客户端IP，源站侧加载TOA内核模块后，内核会自动把连接的真实来源IP写入socket，应用层不用改任何代码,日志里直接就是真实IP。
加载TOA模块的通用思路如下：
# 查看当前是否已加载 lsmod | grep toa # 加载模块（路径以厂商提供的模块包为准） insmod toa.ko
不过TOA对服务器内核有要求，多数云主机默认内核不支持直接加载自定义模块，部分高防厂商提供预编译好的内核模块或专用镜像，操作前先跟高防技术支持确认模块包是否适配你的操作系统版本,避免内核panic。
如果高防和源站之间支持Proxy Protocol协议,也可以在nginx里这样配置：
listen 80 proxy_protocol; set_real_ip_from 1.2.3.0/24; real_ip_header proxy_protocol;
两种方式实现层面不同,选型可以参考下表：
| 实现方式 | 工作层级 | 服务器要求 | 适用场景 |
|---|---|---|---|
| XFF头部 | 七层应用 | 无需内核改动 | HTTP/HTTPS业务 |
| TOA模块 | 四层传输 | 需加载内核模块 | TCP转发，无法改应用 |
| Proxy Protocol | 四层传输 | 源站网关和应用同时支持 | LVS/Nginx四层代理架构 |
高防叠加CDN时源站日志IP怎么处理
不少站点是高防套CDN的多层架构，用户流量先到CDN，再到高防，最后回源，这种情况下，XFF头经过两次代理转发，格式会变成一串IP列表，例如用户IP, CDN节点IP, 高防节点IP。
如果直接在源站用$remote_addr取IP，看到的还是高防节点IP，配置realip模块后，real_ip_recursive on会自动从右往左跳过所有可信回源IP,命中用户真实IP。
需要注意，高防厂商和CDN厂商的回源网段都要加进set_real_ip_from，少了任何一个，解析结果都会出错，去工单系统把两份回源IP段列表都拿到,逐一填入配置。
如果拿不到完整回源网段，备用方案是双重记录：日志格式中同时保留XFF头和$remote_addr,后续做日志分析时从XFF字段里提取第一个IP作为真实用户IP。
log_format main '$http_x_forwarded_for - $remote_addr - [$time_local] "$request" $status';
如何验证高防回源配置已经生效
配置改完不能光看不报错，要实际验证,最直接的方式是模拟真实用户请求：
curl -H "X-Forwarded-For: 1.2.3.4" http://你的域名/
然后查看源站Nginx日志：
tail -f /var/log/nginx/access.log
如果日志里出现了2.3.4，说明XFF解析生效，注意测试用的IP要避开高防回源网段，否则会被
set_real_ip_from当成可信代理跳过。
更严谨一点，在源站抓回源流量,确认高防是否真的在回源请求里带了XFF头：
tcpdump -A -s 0 -i eth0 port 80 | grep -i x-forwarded-for
抓到包里有X-Forwarded-For字段，且值包含用户IP，说明链路是通的，抓不到的话，再回高防控制台检查“回源携带真实IP”开关有没有打开。
高防接入后源站日志看不到真实客户端的常见问题
Q：XFF头会被客户端伪造吗？配置后日志里的IP可信吗？
XFF头本身可以被客户端伪造，直接信任不安全，但配置了set_real_ip_from并限定高防回源网段后，源站只接受来自高防的连接，外部伪造的XFF值不会覆盖$remote_addr，日志中记录的是高防回源时携带的值，可信度有保障，业务侧如需更高安全等级,可再结合WAF规则过滤明显异常的XFF值。
Q：云主机不支持TOA模块，四层转发业务拿不到真实IP怎么办？
如果高防支持HTTP回源，把四层转发改为七层回源，用XFF方案解决，高防只支持四层转发时，可以在源站前加一台Nginx做反向代理，由这台Nginx解析高防传来的连接并写入自定义头部，之后内部服务读取该头记录日志，这种方案对源站集群结构有一定要求，如果以上条件都不具备,只能依赖高防控制台自带的访问日志做数据补充。
Q：配置后日志里出现多个IP逗号分隔，哪个才是真实客户端IP？
多个IP是XFF头逐级叠加的正常表现，格式为客户端IP, 代理1IP, 代理2IP，开启real_ip_recursive on并把所有可信回源网段加入set_real_ip_from后，nginx会选取最左侧第一个不在可信列表中的IP作为真实客户端IP，配置无误的话，$remote_addr输出的就是最终结果,日志里不会再出现逗号分隔的原始XFF串。
接入高防后源站日志看不到真实客户端，本质是回源链路的IP转发机制问题，先确认回源方式，再选择XFF或TOA对应的配置方案，最后用模拟请求验证,三步走完基本就能解决。