套了Cloudflare还被打?源IP泄露的7个隐藏途径与防护指南

引言

上个月有个朋友找我,说他的博客被打到服务器直接连不上,一查流量账单吓了一跳——单日跑了20GB,直接欠费停机。他挺郁闷的:“我明明用了Cloudflare啊,不是说能防DDoS吗?”
我让他看了下服务器日志,发现攻击流量根本没走Cloudflare,全是直连源服务器的IP。说白了,攻击者绕过了CDN,直接打真实服务器。这就是典型的源IP泄露问题。
其实这种情况特别常见。很多人以为配个Cloudflare就万事大吉了,但源站IP早就通过各种渠道暴露了——DNS历史记录、邮件头信息、子域名扫描…你可能压根不知道自己的IP已经被记录在案,只是暂时还没人来攻击而已。
这篇文章我会把源IP泄露的常见途径都讲清楚,然后教你怎么检测自己的网站有没有这个问题,最后给出一套完整的防护方案。说实话,这些都是我自己踩过坑总结出来的经验。

为什么源IP会泄露

什么是源IP泄露及其危害

先解释下什么是源IP泄露。你用Cloudflare这类CDN服务,本质上是让用户访问Cloudflare的节点,再由Cloudflare转发请求到你的真实服务器(源站)。这样一来,攻击者看到的只是Cloudflare的IP,看不到你的真实服务器IP。
但如果攻击者通过某些途径拿到了你的源站IP,那CDN就形同虚设了。他们可以直接攻击你的真实服务器,绕过Cloudflare的所有防护。
这带来的危害挺严重的:

• 服务器瘫痪:DDoS攻击直接打到源站,服务器扛不住就宕机
• 流量费用暴涨:很多云服务器按流量计费,被刷流量账单能让你怀疑人生
• 数据被盗风险:如果有安全漏洞,攻击者绕过CDN的WAF防火墙直接打进来,风险更大
  根据Cloudflare 2024年第四季度的报告,他们观测到了史上最大规模的5.6 Tbps的DDoS攻击。虽然这种攻击普通网站不太可能遇到,但哪怕是几个G的攻击,小服务器也扛不住。
  [图片：CDN工作原理示意图]
  提示词：server behind CDN shield, user traffic flow through cloudflare nodes, simplified diagram, tech blue color scheme, professional illustration

源IP泄露的7个常见途径

好,那源IP到底是怎么泄露的呢?我总结了7个最常见的途径,按风险等级从高到低来讲。
途径1:DNS历史记录(风险等级:高)
这是最常见也是最容易被忽视的泄露途径。
问题在哪?很多人是先把域名解析到真实IP运行了一段时间,然后才想起来要上Cloudflare。但你的DNS解析记录早就被各种第三方服务爬取并永久保存了,比如SecurityTrails、DNSdumpster这类DNS历史查询工具。
我之前就犯过这个错。网站上线的时候直接用真实IP解析,跑了半年才配Cloudflare。结果用SecurityTrails一查,几个月前的DNS记录清清楚楚躺在那里。
途径2:邮件服务器头信息(风险等级:高)
这个特别隐蔽,很多人完全想不到。
网站都会发邮件吧?注册确认邮件、找回密码邮件、RSS订阅通知…这些邮件的头信息(Email Header)里会包含发送服务器的IP地址。如果你用的是自建邮件服务器,或者网站程序直接通过服务器发邮件,那源IP就暴露了。
攻击者怎么利用?很简单,注册个账号触发确认邮件,然后查看邮件原始头信息,搜索Received字段,就能看到发送服务器的真实IP。
老实说我第一次发现这个问题的时候挺吃惊的,完全没想到邮件还能泄露IP。
途径3:子域名扫描(风险等级:中高)
这个问题也挺普遍的。
你可能把主域名example.com配了Cloudflare,但子域名呢?比如mail.example.com(邮件服务)、admin.example.com(后台管理)、dev.example.com(开发环境),这些子域名很可能直接解析到源服务器IP,没走CDN。
攻击者用sublist3r、OneForAll这类子域名扫描工具一跑,把你的所有子域名都扫出来,然后ping一下,只要有一个子域名返回真实IP,源站位置就暴露了。
而且啊,就算主域名和子域名不在同一台服务器上,只要在同一个C段(比如都是192.168.1.x),攻击者也能大概定位你的IP范围。
途径4:网站源码泄露(风险等级:中)
开发的时候留下的测试页面、调试信息,也可能泄露IP。
常见的情况:

• phpinfo()页面没删除,里面会显示服务器IP和各种配置信息
• .git目录没禁止访问,配置文件里可能有IP地址
• 错误日志开着调试模式,报错信息里包含服务器路径和IP
• 网站源码里硬编码了API接口地址,用的是IP而不是域名
  我见过有人把测试用的info.php忘在服务器上,被搜索引擎收录了,直接就能看到所有服务器信息。这种低级错误其实不少见。
  途径5:SSL证书查询(风险等级:中)
  SSL证书也可能成为泄露源。
  现在有证书透明度日志(Certificate Transparency)这个东西,所有签发的SSL证书都会被记录。你可以通过crt.sh、Censys这类工具查询某个域名的证书历史,找出证书绑定过哪些IP地址。
  如果你在配置Cloudflare之前,SSL证书直接绑定在源服务器IP上,那这条记录就会被保存下来。虽然不是每次都能通过证书查到IP,但确实是一个可行的途径。
  途径6:国外DNS解析差异(风险等级:中低)
  有些CDN服务只做国内线路,国外没节点。
  这种情况下,如果从国外的DNS服务器查询你的域名,可能直接返回源站IP,而不是CDN节点IP。虽然Cloudflare是全球CDN,这个问题不大,但如果你用的是国内小厂的CDN,就要注意了。
  检测方法很简单,用Google的DNS(8.8.8.8)或者Cloudflare的DNS(1.1.1.1)查询域名,看返回的IP是不是CDN节点。
  途径7:C段扫描和同服务器网站(风险等级:低)
  如果你的服务器上跑了多个网站,其中一个没做防护,也可能导致其他网站被定位。
  攻击者可以通过Bing、Google的ip:xxx.xxx.xxx.xxx语法,反查某个IP上托管了哪些网站。或者扫描整个C段,看看附近的IP有没有你的其他网站。
  这个风险相对低一些,但如果你在同一台服务器上跑了很多网站,还是要注意。
  [图片：源IP泄露途径汇总图]
  提示词：7 ways of IP leak infographic, DNS history, email headers, subdomain scan, source code leak, SSL certificate, colorful icons, flat design

如何检测源IP是否泄露

说了这么多泄露途径,那怎么检查自己的网站有没有中招呢?我整理了一套自检清单,照着做一遍基本就能发现问题。

检测工具汇总表

详细检测步骤

检查1:DNS历史记录查询
打开这几个网站,输入你的域名查一查:

• SecurityTrails (securitytrails.com) - 可以查看域名的历史DNS解析记录
• DNSdumpster (dnsdumpster.com) - DNS枚举工具,能看到子域名和历史记录
• Netcraft (sitereport.netcraft.com) - 也会记录网站的历史IP
  如果查到了你配Cloudflare之前的真实IP记录,那基本确定已经泄露了。
  检查2:邮件头信息测试
  这个方法特别实用:

1. 如果你的网站有注册功能,注册个测试账号,触发确认邮件
2. 或者用找回密码功能,给自己发个重置邮件
3. 收到邮件后,查看”邮件原始信息”或”显示原始邮件”(不同邮箱客户端叫法不一样)
4. 搜索Received或X-Originating-IP字段
5. 看看里面的IP地址是不是你的源站IP
   如果邮件是通过第三方服务(SendGrid、Amazon SES)发的,那显示的是第三方的IP,这种就没问题。
   检查3:子域名扫描
   手动检查所有子域名的DNS解析,看看有没有直接指向源IP的:

# 用dig命令查询子域名
dig mail.yourdomain.com
dig admin.yourdomain.com
dig api.yourdomain.com

或者用在线工具自动扫描:

• Sublist3r - Python工具,可以扫出很多子域名
• OneForAll - 国内大佬开发的子域名收集工具
  把扫出来的子域名逐个ping一下,看返回的IP是Cloudflare的还是你自己的。
  检查4:全球多地ping测试
  从不同国家和地区ping你的域名,看返回的IP是否一致:
• 用ping.pe这个网站,可以从全球多个节点同时ping
• 或者用17ce.com(国内的多地ping测试工具)
  如果国内国外返回的IP不一样,可能就有问题了。正常情况下,Cloudflare是全球CDN,各地ping应该返回最近的CF节点IP。
  检查5:SSL证书关联查询
  去crt.sh搜索你的域名,查看证书历史记录:

https://crt.sh/?q=yourdomain.com

看看证书有没有绑定过你的源站IP。如果有,那IP也算是半公开状态了。
检查6:网络空间搜索引擎
这个方法有点高级,但很有效。用Shodan或Censys这类工具,直接搜索你的域名或网站特征:

• Shodan (shodan.io) - 互联网设备搜索引擎
• Censys (censys.io) - 网络空间扫描工具
• Fofa (fofa.so) - 国内的网络空间测绘工具
  这些工具会扫描全网的服务器,如果你的源站有对外暴露的服务(比如开着80端口),可能会被收录,从而暴露IP。
  检查7:查看服务器日志
  最直接的方法,去服务器上看看访问日志:

# Nginx日志位置一般在
tail -f /var/log/nginx/access.log
# Apache日志
tail -f /var/log/apache2/access.log

如果发现有直连源IP的访问记录,而且来源不是Cloudflare的IP段,那说明有人已经知道你的源IP并在尝试直连了。
Cloudflare的IP段可以在官方文档查到,正常情况下,所有访问请求都应该来自这些IP段。

完整防护方案

配置前的准备工作

如果你还没上Cloudflare,或者发现源IP已经泄露打算重新配置,那先做好这几个准备工作能省不少麻烦。
准备1:更换服务器IP或使用全新服务器
这是最彻底的方案。如果你的源IP已经泄露了,最好的办法就是换个新IP重新开始。
对云服务器来说,有几个选择:

• 重新购买一台新服务器:数据迁移过去,旧服务器直接销毁
• 更换公网IP:有些云服务商(如阿里云、腾讯云)允许更换弹性公网IP,一般免费或收取少量费用
• 换成全新域名:如果域名和IP关联太紧密,甚至可以考虑换域名重新来过(这个成本比较高,不到万不得已不推荐)
  我的建议是,如果网站还在起步阶段,直接换个新服务器最省事。数据不多的话,迁移也就几分钟的事。
  准备2:清理所有可能泄露IP的历史痕迹
  虽然DNS历史记录这种东西你没法删除(已经被第三方服务永久保存了),但至少要把能控制的地方清理干净:
• 删除服务器上的测试页面(phpinfo.php、info.php之类的)
• 关闭网站的调试模式和错误日志输出
• 禁止.git目录的外部访问(在nginx配置里加拒绝规则)
• 检查网站源码,确保没有硬编码IP地址
  准备3:规划域名解析策略
  提前想好哪些域名走Cloudflare,哪些不走:
• 主域名和www:必须走Cloudflare
• 所有对外公开的子域名:也要走Cloudflare(比如blog、api、img)
• 邮件服务器:如果是自建的,建议改用第三方邮件服务
• 内部服务:像后台管理、数据库这种,压根不要配公网DNS,用内网IP访问

Cloudflare配置最佳实践

好,准备工作做完了,现在说说怎么正确配置Cloudflare,把源IP藏得严严实实的。
实践1:全站CDN,所有子域名都走Cloudflare
这是最重要的一条。在Cloudflare的DNS设置里,你会看到每条记录后面有个云朵图标:

• 橙色云朵:流量走Cloudflare代理,会隐藏源IP
• 灰色云朵:流量不走代理,直接解析到源IP
  记住:所有对外的域名都要点成橙色云朵。我见过太多人只把主域名设成橙色,子域名全是灰色的,这完全没意义。
  唯一可以用灰色云朵的,是那种Cloudflare不支持代理的记录,比如MX邮件记录、TXT验证记录这些。
  [图片：Cloudflare DNS设置界面]
  提示词：cloudflare DNS settings screenshot, orange cloud vs gray cloud comparison, highlight the proxy status toggle, clean interface, 16:9
  实践2:邮件服务使用第三方,不要自建
  前面说了,邮件头会泄露发送服务器IP。最简单的解决办法就是不用自己服务器发邮件,改用第三方服务:
• SendGrid:免费额度每天100封,对小网站够用了
• Amazon SES:按量付费,价格便宜,每月前62000封邮件免费(需要AWS账号)
• Mailgun:也有免费额度,接口友好
  这些服务都提供API和SMTP接口,改起来也不麻烦,而且邮件送达率比自建服务器高多了。
  实践3:配置防火墙白名单,只允许Cloudflare IP访问
  这一步是核心防护措施。即使别人知道你的源IP,如果防火墙只允许Cloudflare的IP段访问,攻击流量也进不来。
  Cloudflare官方提供了IP段列表:

https://www.cloudflare.com/ips/

下载下来后,配置服务器防火墙。以iptables为例:

# ⚠️ 重要提示：配置前请先确保SSH端口不受影响
# 建议先在测试环境验证,避免把自己锁在外面
# 先清空现有规则
iptables -F
# 允许本地回环
iptables -A INPUT -i lo -j ACCEPT
# 允许已建立的连接
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# 允许SSH(改成你自己的SSH端口)
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
# 只允许Cloudflare IP段访问80和443端口
# 这里列举几个IPv4段,完整列表去官网下载
iptables -A INPUT -p tcp -m multiport --dports 80,443 -s 173.245.48.0/20 -j ACCEPT
iptables -A INPUT -p tcp -m multiport --dports 80,443 -s 103.21.244.0/22 -j ACCEPT
iptables -A INPUT -p tcp -m multiport --dports 80,443 -s 103.22.200.0/22 -j ACCEPT
# ... 添加所有CF的IP段 ...
# 拒绝其他所有80/443访问
iptables -A INPUT -p tcp -m multiport --dports 80,443 -j DROP
# 保存规则
iptables-save > /etc/iptables/rules.v4

配置注意事项：

1. 操作前建议先在测试环境试一遍
2. 务必保留SSH端口(22)的访问权限
3. 配置完用其他设备(如手机)测试一下
4. 云服务器建议使用控制台的安全组功能,更安全便捷
   如果你用的是云服务器,大部分都有安全组功能,在控制台直接配置会更方便,而且不怕误操作把自己锁外面。
   配置完之后,可以用手机流量直接访问源IP测试一下,应该是连不上的。
   [图片：防火墙配置示意图]
   提示词：firewall protection layers diagram, cloudflare IP whitelist, block non-cloudflare traffic, security shield icon, professional tech illustration
   实践4:禁用服务器ping响应
   防止攻击者通过扫描IP段来定位你的服务器:

# 禁止ping
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_all
# 永久生效,编辑 /etc/sysctl.conf
net.ipv4.icmp_echo_ignore_all = 1
# 然后执行
sysctl -p

这样攻击者扫描IP段的时候,你的服务器不会响应,看起来就像是无效IP。

高级防护措施

如果你的网站比较重要,或者已经被攻击过,可以考虑这些更高级的防护手段。
措施1:使用Cloudflare Tunnel(原Argo Tunnel)
这是Cloudflare提供的一个功能,可以让你完全不暴露源IP。
原理是在你的服务器上运行一个cloudflared程序,它会主动连接到Cloudflare的网络,形成一个安全隧道。这样一来:

• 你的服务器不需要开放80/443端口
• 外网完全访问不到源IP
• 所有流量通过隧道从Cloudflare转发过来
  配置步骤(简化版):

# 安装cloudflared
wget https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-amd64.deb
dpkg -i cloudflared-linux-amd64.deb
# 登录Cloudflare
cloudflared tunnel login
# 创建隧道
cloudflared tunnel create mytunnel
# 配置路由
cloudflared tunnel route dns mytunnel yourdomain.com
# 运行隧道
cloudflared tunnel run mytunnel

这个方案几乎是完美的IP隐藏方案,缺点是配置稍微复杂一点,而且Cloudflare Tunnel的付费版才能用某些高级特性。
措施2:定期更换源IP
对高风险网站来说,定期轮换IP是个好习惯。
比如每隔3-6个月换一次服务器或IP,即使之前的IP泄露了,攻击者打过来也是打空气。当然这个成本比较高,要看你的网站重要程度来决定。
措施3:监控异常流量
在服务器上配置监控,如果发现有非Cloudflare IP的访问,立即告警:

# 简单的监控脚本示例
tail -f /var/log/nginx/access.log | grep -v -E "(173\.245\.|103\.21\.|103\.22\.)" | while read line
do
    echo "Alert: Non-CF IP访问! $line"
    # 可以配合邮件或短信告警
done

这样一旦有人尝试直连源IP,你能第一时间知道。
措施4:不要在网站源码中硬编码IP地址
这个算是基本素养了,但还是要提一下。
网站代码里所有的API调用、资源加载,都用域名而不是IP。比如:

// 错误示例
fetch('http://123.456.78.90/api/data')
// 正确示例
fetch('https://api.yourdomain.com/data')

这样即使有人看你的前端代码,也找不到源IP。

已经泄露怎么办

如果发现源IP已经泄露了,也不用太慌。虽然不能让已经泄露的记录消失,但可以通过一些措施降低风险。
补救步骤1:立即更换服务器IP
这是最有效的办法。前面配置前准备里讲过,重新申请一台服务器或更换公网IP,然后迁移数据。
成本估算:

• 云服务器更换IP:大部分服务商免费或收取少量费用(通常10-20元)
• 购买新服务器:看配置,一般最低配1核2G大概每月30-50元
• 数据迁移时间:小网站一般半小时搞定
  换完IP后,记得旧服务器不要立刻销毁,可以先保留几天观察,确保新服务器运行正常。
  补救步骤2:配置防火墙白名单
  即使IP泄露了,只要配好防火墙,攻击者也打不进来。
  参考前面讲的iptables配置或云服务器安全组配置,只允许Cloudflare IP段访问80/443端口。这样一来,攻击流量全都会被防火墙拦截。
  注意:配置的时候一定要小心,建议:

1. 先在测试环境试一遍
2. 保留SSH端口(22)的访问权限,别把自己锁外面
3. 配置完用其他设备测试一下
   我就因为配置错误把自己锁外面过,最后还得去云服务商控制台通过VNC登录进去修复,挺麻烦的。
   补救步骤3:使用Cloudflare Rate Limiting限流
   Cloudflare提供了Rate Limiting功能,可以限制单个IP的访问频率。
   免费版有限制,但Pro版(每月20美元)可以配置更细致的规则,比如:

• 单IP每10秒最多10个请求
• 超过阈值自动拉黑或Challenge(人机验证)
• 针对特定路径的保护
  这个对抵御小规模攻击挺有效的。
  补救步骤4:考虑使用高防IP服务
  如果你的网站经常被攻击,或者业务比较重要,可以考虑购买高防IP服务。
  国内的云服务商(阿里云、腾讯云、百度云)都有DDoS高防产品:
• 按带宽计费:固定费用,提供一定带宽的防护(比如20G防护)
• 按攻击量计费:平时费用低,有攻击时才收费
• 成本:看防护等级,从几百到几万每月不等
  说实话,对普通个人网站或小企业,高防IP的成本可能有点高。但如果你是电商网站、游戏服务器这种对稳定性要求高的,还是值得投资的。
  补救步骤5:监控并及时响应
  配置监控告警,一旦检测到异常流量或直连源IP的访问,立刻处理:
• 配置Cloudflare的通知功能,流量异常时发邮件告警
• 在服务器上装个监控工具(如zabbix、prometheus)
• 如果发现攻击,可以临时修改DNS把流量切到备用服务器
  反应速度很重要。我见过有人被攻击了好几个小时才发现,那时候流量费已经烧了不少了。

结论

说了这么多,总结一下核心要点:
源IP泄露是个系统性问题,不是配个Cloudflare就能一劳永逸的。从DNS历史记录到邮件头信息,从子域名扫描到SSL证书,泄露途径真的挺多。
最关键的防护措施:

1. 全站CDN - 所有对外域名都走Cloudflare,橙色云朵点起来
2. 防火墙白名单 - 只允许Cloudflare IP段访问,这是最后一道防线
3. 邮件服务外包 - 用SendGrid、SES这些第三方服务,别自己发邮件
4. 定期自检 - 用本文提到的工具查一查,防患于未然
   如果你还没配Cloudflare,那正好,现在开始就按正确的方式来,一步到位省得后面麻烦。如果已经配了但不确定有没有泄露,花十分钟自检一遍,心里有底。
   万一发现IP已经泄露了也别慌,换个新IP,配好防火墙,该防护的防护好,问题也不大。
   最后再强调一次:防护源IP是一个持续的过程,不是一次性工作。新加子域名的时候要记得走CDN,改配置的时候别不小心暴露IP,定期检查一下防护措施有没有失效。
   你现在可以先去检查一下自己的网站,用SecurityTrails查查DNS历史,看看有没有中招。如果有问题,就按这篇文章的步骤一步步加固。虽然麻烦了点,但总比被打到服务器宕机强,对吧?

发布于: 2025年12月1日 · 修改于: 2025年12月8日

Easton

技术开发