用了CDN为什么还能看到源站IP？源站隐藏应该做到哪一步

CdnChart 技术团队发布于 2026-10-2017 分钟阅读

网站已经接入CDN，域名解析返回的也是CDN节点，为什么在历史DNS、某个子域名或服务器记录中，仍然能找到疑似源站IP？

原因在于，接入CDN和保护源站不是同一件事。

CDN代理生效后，正常用户访问主域名时会先连接CDN边缘节点。当前DNS不再直接返回源站地址，但CDN不会自动清理过去的DNS记录，也不会替你关闭未代理的子域名、邮件服务、管理端口或源站公网入口。

真正可靠的源站保护，不应只追求“别人查不到IP”，而应该做到：

即使源站IP已经被知道，未经授权的请求仍然无法绕过CDN访问业务。

这才是源站隐藏应该达到的最终标准。

先确认：你看到的到底是不是源站IP

很多“源站IP泄露”，其实只是把CDN节点IP当成了源站。

接入反向代理型CDN后，一次正常访问通常经过：

用户 → CDN边缘节点 → 源站或源站负载均衡

浏览器、curl、Ping工具或网站测速平台显示的远程IP，一般只是客户端当前连接的对端。如果域名已经正确代理，这个地址通常属于CDN边缘网络，而不是源站。

可以先查询：

dig www.example.com CNAME +noall +answer
dig www.example.com A +noall +answer
dig www.example.com AAAA +noall +answer

再查看实际连接地址：

curl -sS -o /dev/null \
  -w 'remote_ip=%{remote_ip}\nhttp_code=%{http_code}\n' \
  https://www.example.com/

如果响应IP属于CDN厂商或其合作网络，只能说明当前请求到达了CDN入口，不能据此认定源站已经暴露。

关于这几类地址的区别，可以参考CDN节点IP和源站IP有什么区别？。

真正值得警惕的情况是：某个疑似IP在保留正确域名和TLS SNI的情况下，能够绕过CDN直接返回正常网站内容。

为什么接入CDN以后源站IP仍会暴露

原因一：历史DNS记录已经保存过旧IP

网站接入CDN之前，域名通常直接解析到源站。即使现在已经修改为CDN的CNAME或Anycast地址，过去的DNS答案仍可能出现在：

历史DNS数据库；
搜索引擎缓存；
运维文档和代码仓库；
监控平台记录；
第三方资产管理平台；
旧的截图或故障报告；
本地及递归DNS的短期缓存。

CDN只能改变当前解析结果，无法删除互联网中已经保存的历史记录。

如果接入CDN前后一直使用同一个源站IP，那么旧地址即使不再出现在当前DNS中，也可能已经被长期记录。

原因二：某个子域名没有经过CDN

主域名接入CDN，并不意味着所有子域名都自动受到保护。

常见的旁路入口包括：

origin.example.com
direct.example.com
api.example.com
admin.example.com
test.example.com
dev.example.com
old.example.com
upload.example.com

例如：

www.example.com → CDN
api.example.com → 源站IP
admin.example.com → 源站IP

只要这些域名与网站共用同一个服务器IP，源站就可能被关联出来。

最容易遗漏的不是正式业务域名，而是几年前创建的测试记录、临时回源域名和已经停止使用但没有删除的旧记录。

Cloudflare的源站保护文档也建议检查未代理的DNS记录，包括可能在TXT、SPF等记录中出现的源站地址。

原因三：邮件服务与网站共用同一个IP

邮件系统通常不能像普通网页那样直接放在HTTP CDN后面。

如果下面这些服务与网站源站共用IP，就可能通过邮件相关记录暴露地址：

MX记录；
mail.example.com；
SMTP服务器；
SPF记录中的ip4或ip6；
邮件发送头；
Webmail；
邮件退信或追踪服务。

例如：

example.com.      MX 10 mail.example.com.
mail.example.com. A  203.0.113.10

如果203.0.113.10同时也是网站源站地址，那么即使www.example.com已经接入CDN，邮件记录仍然公开了同一台服务器。

比较稳妥的做法是让邮件服务与Web源站使用不同IP，或者使用独立邮件服务商，不要把邮件、网站、数据库管理和远程登录全部放在同一个公网地址上。

原因四：证书记录暴露了源站主机名

证书透明度日志会公开记录受信任证书的签发信息，其中可能包含证书覆盖的域名。

证书透明度本身通常不会直接告诉查询者“源站IP是什么”，但它可能暴露以前不知道的子域名，例如：

origin.example.com
backend.example.com
server01.example.com
direct.example.com

如果这些主机名仍然解析到源站公网IP，最终就会形成暴露链：

证书透明度记录
→ 发现源站子域名
→ 查询当前或历史DNS
→ 找到源站IP

Certificate Transparency官方网站说明，CT日志是公开可查询的追加式证书记录，可以查看哪些证书机构在什么时间为哪些域名签发了证书。

因此，证书资产审计不应只看主域名，还应检查历史证书中出现过的全部子域名。

但需要注意：隐藏证书名称不是核心防线。即使源站域名被发现，源站也应该通过防火墙、mTLS或私有连接拒绝未经授权的访问。

原因五：源站允许任何公网地址直接访问

这是最关键的问题。

很多网站接入CDN后，只修改了DNS，却没有调整云安全组、主机防火墙或Web服务器访问策略。于是请求路径变成了两条：

正常路径：用户 → CDN → 源站
旁路路径：用户 → 源站IP

攻击者只要找到源站地址，就可以绕过CDN的：

DDoS清洗；
WAF规则；
Bot管理；
访问频率限制；
地域限制；
身份验证；
缓存与流量削峰。

Cloudflare的官方说明明确建议：源站只允许Cloudflare官方地址及受信任合作方访问，并阻止其他公网来源。如果源站IP因历史DNS或邮件配置被发现，未限制的公网入口会让请求直接绕过Cloudflare。

只修改DNS、没有限制源站入口，只能叫“把正常用户引向CDN”，不能叫“完成源站保护”。

原因六：源站还开放了其他公网服务

即使80和443端口已经限制，其他公网服务仍可能暴露同一个IP：

SSH；
RDP；
FTP；
数据库端口；
Redis；
Elasticsearch；
运维面板；
Kubernetes管理接口；
监控系统；
开发测试服务；
对象存储管理入口。

这些服务可能出现在资产测绘、日志、错误页面或公开配置中。

源站隐藏不能只检查网站端口。应该从云账号、安全组、负载均衡、主机监听端口和管理网络几个层面确认，哪些服务真的需要公网访问。

管理端口更适合通过VPN、堡垒机、零信任访问或专用管理网络开放，而不是与网站共用一个面向全球互联网的入口。

“查不到源站IP”为什么不是最终目标

把源站安全完全建立在IP保密上，本质上属于“依赖秘密不被发现”。

这个秘密可能因为以下任何变化再次泄露：

新增了一条DNS记录；
运维人员创建了临时测试域名；
邮件服务迁回源站；
证书新增源站主机名；
应用主动连接外部服务；
日志或错误页面带出内部信息；
CDN切换期间短暂直连；
云平台分配了新的公网入口；
防火墙规则被误修改。

因此，源站保护应该采用两层思路：

尽量减少源站地址出现在公开信息中的机会；
假设IP最终可能被知道，并限制它只能接受可信CDN请求。

第二层比第一层更重要。

源站隐藏应该做到哪一步

可以把源站保护分成五个级别。

级别	已完成的工作	实际保护效果
L0：只开通CDN	CDN控制台已添加域名	可能仍然直连源站
L1：当前DNS代理	主域名解析到CDN	当前查询不直接显示源站
L2：清理公开资产	排查子域、邮件、历史配置和证书资产	降低源站被关联的概率
L3：限制源站访问	防火墙仅允许CDN或可信网络	即使IP泄露也难以绕过CDN
L4：验证回源身份	mTLS、私有连接、隧道或可靠的回源鉴权	不只判断来源IP，还验证请求身份
L5：持续监控与隔离	独立管理网络、规则同步、告警和定期复核	防止后续配置变化重新暴露

对于普通网站，至少应该做到L3。

对于高防CDN、金融、游戏、API、登录系统和容易遭受DDoS攻击的业务，建议做到L4，并建立L5的持续检查机制。

第一步：让所有对外业务域名真正经过CDN

先整理完整的域名清单，而不是只检查www。

至少包括：

裸域；
www；
API；
图片；
-静态资源；
下载；
-上传；
WebSocket；
登录和支付；
管理后台；
旧域名；
测试域名；
IPv4和IPv6记录。

对应该代理的记录，确认它们真正处于代理状态，而不是只使用CDN提供的DNS托管。

可以通过CDNChart CDN检测查看CNAME、响应IP、ASN和响应头证据，再结合CDN加速有没有生效？接入后这样检查确认实际业务请求已经经过CDN。

需要注意：

使用某家CDN的DNS服务，不等于流量一定经过CDN；
域名显示在CDN控制台，不等于配置已经生效；
静态资源经过CDN，不等于API和动态页面也经过CDN；
IPv4经过CDN，不等于IPv6也已经配置正确。

第二步：清理可能关联源站的公开记录

建议从自己管理的资产出发进行审计：

导出当前DNS区域记录；
列出所有A、AAAA、CNAME、MX和TXT记录；
检查未代理子域；
检查SPF中的IP地址；
检查历史证书中的子域名；
检查代码、部署文件和公开文档；
检查旧负载均衡和旧服务器；
检查邮件、FTP及管理服务是否与源站共用IP；
检查旧源站地址是否仍然返回业务内容。

如果某个源站IP过去已经长期公开，仅删除DNS记录并不能让所有历史记录消失。

更稳妥的处理顺序是：

先完成新的源站访问限制；
确认CDN回源正常；
再更换已经暴露的源站公网IP；
关闭旧地址；
检查旧地址不再返回业务内容；
继续监控是否出现新的暴露记录。

不要先换IP、后做防火墙。如果暴露路径没有清理，新IP很快还会再次出现。

第三步：在网络层只允许CDN回源

这是源站保护最重要的一步。

可以在以下位置配置访问控制：

云安全组；
网络ACL；
-硬件或云防火墙；
主机防火墙；
负载均衡访问规则；
Kubernetes入口策略；
Web服务器访问控制。

基本策略通常是：

允许：CDN官方回源地址段
允许：可信运维与监控网络
允许：必要的内部服务
拒绝：其他公网来源访问业务端口

不要从一次DNS查询中随便取出几个CDN边缘IP加入白名单。

用户连接的边缘IP与CDN访问源站使用的出口IP不一定是同一组。应使用厂商正式公布的回源地址范围、专用回源网络或官方自动同步机制。

同时注意：

CDN地址段可能调整；
IPv4和IPv6要分别处理；
多CDN需要允许所有正在使用的厂商；
外部监控、支付回调和合作方需要单独列出；
删除规则前要确认不会中断回源；
修改后应从多个地区检查网站可用性。

第四步：不要只依赖IP白名单

IP白名单很重要，但并不是所有环境都适合只依赖它。

例如：

CDN回源地址范围较大；
多个客户共用回源网络；
企业同时使用多家CDN；
云平台入口IP动态变化；
内部服务需要更强的请求身份验证。

这时可以增加回源鉴权。

方法一：mTLS双向认证

普通HTTPS主要由客户端验证服务器证书。mTLS还要求CDN在连接源站时提供客户端证书，由源站验证请求确实来自受信任的CDN。

Cloudflare的Authenticated Origin Pulls就是一种mTLS回源认证方式。其官方文档说明，该功能用于确保到达源站的请求来自Cloudflare网络。

需要注意，不同级别的mTLS配置所证明的范围可能不同：

共享客户端证书可能只能证明请求来自该CDN网络；
账户、域名或客户专用证书可以提供更强的隔离；
源站必须正确验证客户端证书，不能只要求“存在任意证书”；
证书到期、轮换和吊销需要纳入运维流程。

方法二：回源自定义密钥头

CDN回源时加入一个随机密钥头，源站只响应包含正确值的请求，例如：

X-Origin-Verify: 长随机值

Amazon CloudFront官方文档说明，可以为回源请求添加自定义Header，并让源站只接受包含该Header的请求，从而减少用户绕过CloudFront直接访问源站的可能。

这种方式部署简单，但需要注意：

密钥必须足够随机；
必须通过HTTPS回源；
不要在公开代码和日志中输出；
定期轮换；
源站不能在错误页面中回显；
最好与防火墙规则组合使用。

自定义Header是身份验证补充，不应被当成网络访问控制的完全替代品。

方法三：私有连接或反向隧道

更严格的架构可以让源站根本没有公开的Web入口。

常见形式包括：

CDN到云VPC的私有连接；
专用回源链路；
反向隧道；
源站主动建立出站连接；
私有负载均衡；
对象存储的Origin Access Control；
服务网格或私网入口。

以Cloudflare Tunnel为例，源站通过主动建立的出站隧道连接Cloudflare，不需要开放公网入站端口。

如果业务条件允许，“源站没有公网Web端口”通常比“有公网IP但希望没人发现”更接近真正的源站隐藏。

第五步：正确处理访客真实IP

源站只允许CDN访问后，源站日志中的网络对端通常变成CDN回源节点，而不是最终访客。

此时可以使用厂商提供的可信请求头恢复访客IP，例如不同厂商可能使用：

CF-Connecting-IP
True-Client-IP
X-Forwarded-For

但不能无条件信任这些头。

如果源站仍允许公网直连，客户端完全可以自行伪造X-Forwarded-For。正确顺序应该是：

先限制只有可信CDN能够访问源站；
在Web服务器中配置可信代理地址范围；
只接受可信代理写入的真实IP字段；
再用恢复后的地址进行日志、限流和风控。

否则，源站保护虽然完成了一半，日志和安全策略却可能被伪造请求误导。

怎么验证源站是否真的无法绕过CDN

以下操作只应用于自己管理或明确获得授权的服务器。

验证一：确认正常域名经过CDN

curl -sS -o /dev/null \
  -w 'remote_ip=%{remote_ip}\nstatus=%{http_code}\n' \
  https://www.example.com/

结果中的远程IP应当是CDN入口，而不是已知源站地址。

验证二：保留域名和SNI测试源站

不要直接运行：

curl https://203.0.113.10/

直接访问IP可能因为Host和TLS SNI不匹配而得到默认站点，这不能准确验证真实业务是否可直连。

应该使用：

curl -I \
  --resolve www.example.com:443:203.0.113.10 \
  https://www.example.com/

其中203.0.113.10是文档示例地址，测试时替换为自己已知且有权验证的源站IP。

这个命令会：

连接指定源站IP；
保留www.example.com作为Host；
使用正确的TLS SNI；
更接近绕过CDN的真实访问方式。

什么结果才算通过

从一个不在源站白名单中的外部网络测试时，合理结果包括：

连接超时；
连接被拒绝；
返回403；
返回专用拒绝页面；
TLS客户端证书验证失败；
返回不包含真实业务内容的默认响应。

下面这些结果通常说明仍可绕过CDN：

返回200和正常首页；
能正常调用登录或API；
静态与动态内容都完整可用；
只依赖一个容易伪造的Host判断；
CDN关闭后源站公网入口仍能直接承载业务。

不要只测首页。还应检查：

API；
登录；
上传；
WebSocket；
动态页面；
IPv4和IPv6；
HTTP和HTTPS；
备用端口；
主备源站。

验证三：查看源站日志

完成限制后，源站业务端口的请求来源应该主要包括：

CDN官方回源网络；
内部负载均衡；
授权监控系统；
明确列入白名单的合作方；
受控运维网络。

如果仍然出现大量未知公网IP直接访问源站，需要检查是否有端口、IPv6规则或备用入口遗漏。

最容易漏掉的IPv6问题

很多源站只限制了IPv4，却忘记IPv6。

可能出现：

www.example.com 的IPv4 → CDN
www.example.com 的IPv6 → 源站

也可能主域名没有源站AAAA记录，但服务器本身拥有公网IPv6，并通过某个子域或其他资产被发现。

审计时要同时检查：

dig www.example.com A +noall +answer
dig www.example.com AAAA +noall +answer

云安全组和主机防火墙也需要分别检查IPv4与IPv6规则。只在IPv4上执行“仅允许CDN回源”，不能算完成源站保护。

使用多CDN时怎么保护源站

多CDN环境下，源站需要接受多家厂商的回源请求，访问控制会更复杂。

需要处理：

多家CDN回源IP段；
地址范围自动更新；
每家CDN独立的回源鉴权；
不同的真实访客IP请求头；
主备切换期间的规则一致性；
健康检查来源；
临时扩容或故障回切；
退出某家CDN后的规则清理。

建议为每家CDN使用独立的鉴权凭据，不要让所有厂商共用一个永久密钥。这样某一家停止使用时，可以单独撤销，不影响其他路径。

同时保留一套受控的紧急访问方式，但不要为了“故障时方便直连”，长期向整个公网开放源站。

源站隐藏的验收清单

上线前可以逐项确认：

主域名、www、API、图片和静态资源域名都按设计经过CDN；
A、AAAA和CNAME记录中没有意外直连源站；
已检查未代理子域和旧测试域名；
邮件服务没有与Web源站共用公网IP；
SPF、MX和TXT记录没有意外暴露源站地址；
已检查历史证书中出现的域名资产；
已评估历史DNS是否记录过当前源站IP；
源站防火墙只允许CDN及可信网络访问；
IPv4和IPv6规则均已配置；
管理端口不直接暴露给整个公网；
源站使用HTTPS回源；
已配置mTLS、专用回源Header或私有连接；
真实访客IP只从可信代理头恢复；
外部网络使用curl --resolve无法直接获取正常业务内容；
旧源站IP已经停用或不再返回业务；
CDN地址段、证书和回源密钥有更新机制；
配置变更和异常直连请求有日志及告警。

如果这些检查只完成了前两项，说明CDN代理可能已经生效，但源站保护仍然没有完成。

什么程度才算源站真正隐藏

绝对意义上的“任何人永远无法知道源站IP”很难承诺，尤其是源站仍然保留公网地址和开放端口时。

更现实、也更安全的验收标准是：

正常DNS只展示CDN入口；
公开子域、邮件和证书资产不再直接关联源站；
管理与业务入口相互隔离；
源站只接受CDN或可信网络连接；
回源请求具备额外身份验证；
即使已知IP，也无法绕过CDN访问正常业务；
IPv4、IPv6、主备源站和备用端口都使用相同保护原则；
后续新增DNS、证书和服务器时会继续检查。

对于高防CDN，这一点尤其重要。如果攻击流量能够绕过清洗节点直接到达源站，再高的标称防护容量也保护不了旁路入口。选择高防服务时，还应结合高防CDN怎么选？防护能力、节点与测试方法检查厂商是否提供回源IP白名单、mTLS、私网回源和源站保护指导。

源站隐藏做得是否合格，最终不看“查询工具能不能找到一个IP”，而看这个IP即使被找到，能不能直接访问业务。

常见问题

1. 接入CDN以后，DNS还能查到源站IP吗？

正常代理配置下，主业务域名通常返回CDN节点IP或CDN调度域名。但未代理子域、邮件记录、历史DNS和错误配置仍可能暴露源站。

2. 更换源站IP就能解决泄露吗？

只能解决当前地址已经暴露的问题。如果未代理子域、邮件共用IP或防火墙开放等原因没有处理，新IP仍可能再次暴露。

3. 源站只允许CDN IP访问就足够了吗？

这是最重要的基础措施，但高安全业务还应增加mTLS、专用回源Header、私有连接或隧道，并建立CDN地址段更新和异常访问监控。

4. 为什么直接访问源站IP打不开，但加Host后可以打开？

Web服务器可能根据Host选择虚拟主机。直接访问IP只进入默认站点，而保留正确Host和TLS SNI后，才会命中真实业务。因此验证时应使用curl --resolve。

5. 源站使用HTTPS证书会不会暴露IP？

证书透明度日志通常公开证书中的域名，而不是直接公布源站IP。但其中的源站子域名可能进一步解析到公网地址，因此仍需进行证书资产审计。

6. 邮件服务器为什么会暴露网站源站？

如果邮件和网站共用同一个IP，MX记录、邮件子域、SPF记录或邮件头都可能公开这个地址。最好将邮件系统与Web源站分开部署。

7. 源站没有公网IP，还需要防火墙吗？

仍然需要。私网安全组、隧道身份验证、内部访问控制和最小权限策略同样重要。没有公网IP减少了公开攻击面，但不代表内部访问可以完全放开。

8. CDNChart能直接查询真实源站IP吗？

CDNChart的CDN检测主要用于查看域名是否经过CDN、可能使用哪家CDN，以及CNAME、响应IP、ASN和响应头等公开证据。它不是绕过CDN查找真实源站的工具；源站配置正确时，公开检测通常只能看到CDN入口。

用了CDN还能看到源站IP
源站IP暴露
CDN源站保护
源站防火墙
禁止绕过CDN
隐藏服务器真实IP

网站速度测试：换了CDN，怎么确认访问真的变快了？

更换CDN后不能只在本地刷新首页判断速度。本文提供迁移前后对照测速方法，说明如何控制节点、运营商、URL、缓存和测试时段，并结合成功率、响应IP、解析、连接、下载及真实用户数据确认网站是否真的变快。

13 分钟阅读

网站测速怎么测？用CDNChart查出哪些地区访问慢

网站测速不能只在自己的电脑上打开一次。本文讲解如何使用CDNChart进行全国三网及海外多节点测速，并结合状态码、响应IP、解析时间、连接时间、下载耗时和失败节点，判断网站究竟在哪些地区、哪些运营商访问较慢。