高防回源后源站日志通常拿不到访客真实IP，除非正确配置X-Forwarded-For（XFF）头传递，否则日志中只会显示高防节点IP或CDN节点IP。
这个结论背后牵扯到回源协议、中间节点处理逻辑、源站Web软件配置三个层面的问题，很多站长买了高防IP或高防CDN后，兴致勃勃去翻源站访问日志做数据分析，结果发现所有访客IP都指向同一个或少数几个IP段，瞬间慌了神，别急，这篇文章把来龙去脉拆开揉碎讲清楚。
为什么源站日志默认拿不到真实IP
高防服务的核心工作模式是“中间人”，访客请求先打到高防节点，高防节点过滤掉攻击流量后，再把正常请求转发给你的源站服务器，这个转发过程叫“回源”。
在这个链路中,源站服务器直面的连接发起方是高防节点，不是访客，操作系统层面记录TCP连接来源时，拿到的自然就是高防节点的出口IP，Web服务器（Nginx、Apache、IIS）默认记录的remote_addr字段，对应的就是TCP连接对端IP，也就是高防节点IP。
如果高防节点在转发时不做任何处理，源站日志里所有访客IP都会是高防节点的IP。 这种情况在一些低成本的透明转发高防中比较常见，特别是纯TCP四层转发场景。
先判断你用的是哪种回源模式
不同回源模式对真实IP的保留能力天差地别,先搞清楚自己的部署方式，再谈解决方案。
七层HTTP回源模式
高防节点以HTTP协议请求源站,此时高防节点会在请求头中追加标准字段，最常见的是X-Forwarded-For，部分厂商还会附带X-Real-IP和CF-Connecting-IP，这种模式下，只要源站Web软件正确解析这些头字段，就能还原真实IP。
四层TCP透明转发模式
高防节点将TCP数据包原封不动地转发给源站,不修改任何HTTP头信息，这种模式下，源站拿到的TCP连接来源是高防节点IP，HTTP层也没有额外头字段。除非高防厂商实现了TCP Options透传或Proxy Protocol协议，否则四层转发模式下源站几乎无法获取真实IP。
端口映射模式
高防IP把特定端口（如80、443）映射到源站端口，本质是NAT转发，多数情况下同样不携带原始IP信息。
快速自查方法：登录源站服务器，用netstat -anp | grep :80查看当前活跃连接，如果所有连接的对端IP都集中在某个IP段（高防机房段），且你确定网站有外部访问流量，那基本可以判定当前没有透传真实IP。
配置X-Forwarded-For后源站如何取回真实IP
绝大多数高防厂商在七层模式下默认启用XFF头传递,但源站默认配置不会自动信任这个头，你需要在Web服务器层面做两件事：
读取XFF头、覆盖remote_addr变量。
Nginx场景
Nginx需要编译http_realip_module模块，多数发行版默认已包含，在nginx.conf的server或http块中增加：
set_real_ip_from 高防节点IP段;
real_ip_header X-Forwarded-For;
real_ip_recursive on;其中set_real_ip_from必须填写你所用高防厂商的节点IP段，否则所有客户端都能伪造XFF头来污染你的日志，IP段信息向高防服务商客服要，或者在控制台文档中查询。
配置完成后执行nginx -s reload生效，此时$remote_addr变量和$http_x_forwarded_for变量都能拿到真实IP。
Apache场景
Apache使用mod_remoteip模块，启用后在配置文件中添加：
RemoteIPHeader X-Forwarded-For
RemoteIPTrustedProxy 高防节点IP段然后重启Apache,此模块会把XFF头中的最右端非信任IP写入客户端IP字段。
IIS场景
IIS需要安装ARR（Application Request Routing）模块，并在URL Rewrite规则中启用“X-Forwarded-For”透传，随后在日志字段中选择client_ip时可以看到真实IP。
验证配置是否生效的三种方法
配完别急着下结论,验证一下更稳妥。
- 查看实时日志：
tail -f /var/log/nginx/access.log，然后用手机流量访问网站，观察日志中出现的IP是否为你手机的出口IP。 - 写一个临时PHP探针文件,内容为
<?php echo $_SERVER['REMOTE_ADDR']; ?>，手机访问后直接显示IP，对比即可。 - 用在线工具或本地curl加自定义XFF头测试：
curl -H "X-Forwarded-For: 1.2.3.4" http://你的域名/，如果日志中记录了1.2.3.4，说明配置生效，但此时要注意是否误信任了客户端传入的头。
不配置的话会损失哪些关键信息
真实IP丢失不只是影响“知道谁来过”这么简单。
地域分析失效，高防节点IP通常集中在少数几个城市机房，访客地理位置会错误地汇聚到机房所在地，做本地化运营的站点会收到完全错误的地域分布报告，比如你的客户都在上海，但日志显示访问来源集中在江苏宿迁（某高防机房所在地）。
频控策略失效，基于IP的访问频率限制会误伤所有用户，因为大家共享高防节点出口IP，反过来，恶意用户也可以通过频繁更换高防节点来绕过IP维度的封禁。
安全审计失真，攻击溯源时会发现所有恶意请求都来自高防IP段，无法定位到具体攻击者，如果攻击者伪造XFF头且源站未正确配置
set_real_ip_from，还可能被误导到错误的目标上。
GEO数据污染，百度统计、CNZZ等第三方统计工具依赖JS采集，不受回源影响，但服务端日志分析的GEO工具（如一些爬虫日志分析软件）会看到大量来自高防节点IP的“伪访客”，导致爬虫抓取分析完全不可信。
那些拿不到真实IP的特殊场景
HTTPS回源
如果高防到源站走的是HTTPS协议,且高防节点没有解密流量，那么它无法读取或修改HTTP头，XFF头自然无从谈起，此时需要高防厂商支持SSL卸载或在TCP层透传，部分厂商提供“HTTPS回源+自定义头”的选项，本质是高防节点先解密再重新加密，源站配置方式与HTTP回源相同。
WebSocket长连接
WebSocket握手阶段会携带XFF头,但升级为长连接后，后续帧不再包含HTTP头信息，不过源站日志记录的是握手阶段的IP，所以影响不大。
源站本身套了多层CDN
比如高防前面又套了一层CDN,或者源站后面还有一层CDN（这种架构不太常见），每一层都可能覆盖或追加XFF头，最终取到的IP取决于链路中最后一层是否信任前序传递，多数CDN会在XFF头中追加自身看到的客户端IP，所以真实IP通常还能保留，但如果某层做了IP清洗，链路就断了。
高防回源真实IP泄露怎么办
这是一个反向问题,但也值得关注，有站长问：日志里拿到真实IP了，但担心真实IP暴露被绕过高防直接攻击，这确实是个矛盾点。
业界通行做法是源站防火墙只允许高防节点IP段访问，配置方式有两种：
- 服务器安全组（简米云、酷番云等）中设置源IP白名单，仅放行高防回源段。
- 源站本地防火墙（iptables/firewalld）设置白名单。
这样做之后,即使有人拿到了源站IP，也无法绕过高防直接访问源站，日志中依然可以记录真实IP，但外部探测无法触达源站。
另一个做法是修改回源端口，高防控制台中设置回源到源站的非标准端口（如8443），源站Web服务监听该端口，外部扫描默认端口时无法直接命中，不过这种方法防御效果有限，毕竟端口扫描工具遍地都是。
高防CDN回源日志怎么看真实IP
用高防CDN时,链路变成“访客 → CDN节点 → 高防节点 → 源站”，XFF头会逐层追加，默认情况下，XFF头格式为：X-Forwarded-For: 访客IP, CDN节点IP, 高防节点IP。
Nginx的real_ip_recursive on配合set_real_ip_from多个IP段，会自动剥离所有信任的中间节点IP，只保留最左侧的访客IP，这是标准做法，适用于绝大多数CDN+高防叠加场景。
需要注意的是,不同厂商CDN对XFF的处理略有差异。简米云CDN默认透传XFF，酷番云CDN默认透传，百度云加速（已并入百度智能云CDN）默认透传，只要源站配置了正确的信任IP段，取到的就是真实访客IP。
用统计工具配合日志做双重校验
光看日志还不够,建议配置一个第三方统计工具做交叉验证，百度统计或51LA的JS代码采集的是访客浏览器环境中的IP，不受回源链路影响，对比统计工具中的IP和源站日志中的IP，如果两者一致，说明日志配置正确；如果统计工具显示真实IP而日志全是节点IP，那说明回源配置有问题。
这个验证方法还能顺便发现另一个问题：搜索引擎蜘蛛的真实IP在日志中是否可见，百度爬虫的IP段是公开的（百度官方文档可查），如果日志中能看到百度爬虫的UA但IP显示为高防节点，那说明蜘蛛IP也被覆盖了，这会影响基于IP的GEO日志分析工具（如光年实验室的日志分析工具）对抓取频率的准确判断。
高防回源后源站日志常见问题解答
高防回源后源站日志里的IP全是高防节点IP，正常吗？
正常,如果没有正确配置XFF头解析，这是必然现象，高防节点作为中间代理，TCP连接层面就是源站的直接对端，配置set_real_ip_from和real_ip_header后即可恢复显示真实IP。
高防回源后源站日志怎么看真实IP访问量？
配置好XFF头解析后,直接查看access_log中的$remote_addr字段即可，如果需要按IP维度统计访问量，可以结合GoAccess或ELK等日志分析工具，按IP字段聚合统计，对于历史日志，如果当时未配置XFF透传，这些日志中的IP信息已经丢失，无法恢复。
高防回源真实IP泄露会被攻击吗？
有风险,真实IP泄露后，攻击者可以绕过高防直接对源站发起DDoS或CC攻击。务必在源站防火墙配置仅允许高防回源IP段访问的规则，同时修改回源端口为非标准端口，双管齐下降低风险，对于Web层面的攻击，源站Web应用防火墙（WAF）也能起到一定拦截作用。
高防回源后源站日志能不能拿到访客真实信息,取决于回源模式和Web服务器配置，七层HTTP回源模式下，配置XFF头解析后可以拿到真实IP；四层透明转发模式下，基本拿不到，配置过程中注意信任IP段的准确性，防止被伪造头欺骗，真实IP的获取和源站IP的隐藏并不冲突，通过防火墙白名单可以同时兼顾日志分析和安全防护。