用了CDN为什么还能看到源站IP？源站隐藏与防绕过检查指南

域名已经接入CDN，执行dig或nslookup时看到的也是CDN节点IP，可是在历史DNS记录、某个子域名、邮件配置或云平台地址中，仍然能找到源站IP。

这并不矛盾。

CDN代理能够让正常访客连接CDN节点，而不是直接访问源站，但它不会自动删除过去留下的DNS记录，也不会替你保护未接入CDN的子域名、邮件服务器、管理后台和其他公网入口。

更重要的是，“别人能不能查到源站IP”和“别人能不能绕过CDN访问源站”是两个不同问题。

真正可靠的源站保护标准应该是：

即使源站地址已经被知道，未经CDN转发或认证的公网请求仍然不能取得业务内容，也不能绕过CDN的WAF、限速和DDoS防护直接消耗源站资源。

因此，隐藏IP只能算第一层。限制访问和验证回源身份，才是源站保护的核心。

接入CDN后，正常DNS查询应该看到什么

对于反向代理型CDN，公开业务域名通常指向CDN提供的CNAME或边缘地址：

www.example.com
        ↓
www.example.com.cdn-provider.example
        ↓
CDN边缘IP

用户连接的是CDN边缘节点：

访客 → CDN边缘节点 → 源站

此时查询业务域名：

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

通常看到的是CDN入口地址，而不是源站地址。

但这只能证明当前业务域名的公开DNS已经指向CDN，不能证明源站没有通过其他路径暴露。

CDN节点IP、源站IP和测速探针IP的区别，可以先参考CDN节点IP和源站IP有什么区别？。

为什么接入CDN后还能查到源站IP

历史DNS记录已经留下源站地址

网站接入CDN之前，业务域名可能直接使用A或AAAA记录指向源站：

www.example.com → 203.0.113.10

后来虽然改成了CDN：

www.example.com → CDN CNAME

但旧记录可能已经被被动DNS、资产搜索平台、监控系统或第三方数据库保存。删除当前记录不能让这些历史数据自动消失。

如果旧IP仍然承载相同网站，并允许公网直接访问，攻击者仍可能绕过CDN。

这种情况下，最重要的不是继续要求第三方删除记录，而是让旧地址不再能够直接提供业务：

• 在源站防火墙或安全组限制访问来源；

• 启用认证回源或mTLS；

• 必要时更换源站公网地址；

• 确认旧地址已经停止监听或不再指向业务服务器。

仅更换IP而不增加访问控制，新的地址以后仍可能再次暴露。

有子域名没有接入CDN

主域名和www接入CDN，不代表所有子域名都已代理。

常见的遗漏包括：

origin.example.com
direct.example.com
api.example.com
admin.example.com
staging.example.com
download.example.com
mail.example.com

其中某个子域名只要直接解析到源站，就可能暴露地址。

可以检查自己管理的域名：

dig www.example.com A +short
dig api.example.com A +short
dig admin.example.com A +short
dig mail.example.com A +short

如果源站同时启用了IPv6，还要检查AAAA记录：

dig www.example.com AAAA +short
dig api.example.com AAAA +short

不少网站只限制了IPv4，却忘记源站仍有一个可公网访问的IPv6地址。攻击者即使无法通过IPv4直连，也可能通过IPv6绕过CDN。

不建议依靠猜测子域名名称完成检查。更可靠的方式是维护完整的DNS资产清单，逐项确认哪些记录应该通过CDN、哪些应该迁移到独立服务、哪些不应继续存在。

邮件服务和网站共用同一个IP

如果网站和邮件服务器部署在同一公网IP上，MX、SPF或邮件传输记录可能间接公开源站地址。

检查MX和TXT记录：

dig example.com MX +noall +answer
dig example.com TXT +noall +answer

需要关注：

• MX目标是否最终解析到网站源站IP；

• SPF记录中是否直接出现源站IP；

• 邮件头是否暴露与网站相同的公网出口地址；

• mail.example.com是否与Web源站共用服务器。

更稳妥的做法通常是把邮件发送和接收迁移到独立邮件服务或独立IP，不让Web源站同时承担公网邮件入口。

需要注意，邮件中看到的出口IP不一定就是Web源站入口IP。如果网站和邮件通过同一个公网NAT或同一台服务器出网，才可能形成直接关联。

源站专用域名使用了公共解析

为了让CDN回源，管理员可能创建：

origin.example.com → 203.0.113.10

这个域名如果能够被公网DNS解析，就会直接公开源站地址。

源站域名并不一定需要对全互联网公开。根据架构，可以考虑：

• 使用CDN厂商支持的私有源站；

• 使用内网DNS或私有托管区域；

• 通过专线、隧道或私有网络连接；

• 保留公网源站域名，但从网络层只允许CDN访问；

• 使用云负载均衡器域名，并对入口实施认证和访问限制。

把源站域名改得非常随机，只能降低被偶然猜到的概率，不能替代防火墙、mTLS或私有网络。

公共证书暴露了源站域名

如果为origin.example.com申请公共CA证书，该证书及其中的域名可能进入证书透明度日志。

RFC 9162定义的Certificate Transparency使用可审计的追加式日志记录已签发的TLS服务器证书。它的目标是发现错误或未经授权的证书签发，而不是替网站保密证书中的域名。

证书透明度日志通常不会直接写出源站IP，但如果证书中包含的源站域名仍然公开解析到源站，二者就可能被关联起来。

因此：

• 不要把“域名没有在网站页面中出现”当成保密措施；

• 不要为私有源站域名配置不必要的公共解析；

• 可以使用CDN厂商提供的源站证书或私有CA，但必须确认CDN信任方式；

• 即使使用私有证书，也仍要限制源站公网访问。

云负载均衡或托管平台入口仍然公开

使用AWS ALB、云服务器负载均衡、Kubernetes Ingress或托管应用时，源站可能不是固定IP，而是一个公开域名：

project.region.provider.example

即使这个地址不直接显示真实服务器IP，只要外部用户可以通过它取得业务内容，就仍然存在绕过CDN的路径。

源站隐藏的目标不是一定要让所有基础设施都没有公网地址，而是确保公共入口不能未经授权地直接提供业务。

错误页、响应头或程序配置泄露地址

源站地址还可能出现在：

• 调试错误页；

• 应用日志下载；

• HTML注释；

• JavaScript配置文件；

• API返回内容；

• 跳转地址；

• Location响应头；

• 邮件通知模板；

• 监控或状态页面；

• WebSocket、上传和下载接口配置。

例如，错误跳转返回：

Location: https://203.0.113.10/login

或者：

Location: https://origin.example.com/login

都可能暴露源站入口。

处理这类问题时，应修改应用的外部URL、代理信任和跳转配置，而不是简单隐藏错误页面。回源Host与应用域名判断不一致，也可能生成错误跳转，具体可以参考回源HOST填错会发生什么？从404、证书到多站点逐项查。

只隐藏DNS记录够不够

不够。

可以把源站保护分成四个层次：

普通企业网站至少应该做到第三层。

如果用户知道源站IP后仍能使用正确Host直接打开网站，那么CDN的WAF、Bot防护、访问控制和限速策略都可能被绕过。

怎样确认源站是否可以被绕过

不要直接在浏览器里访问：

https://203.0.113.10/

这种测试可能使用错误的Host和TLS SNI。源站返回证书错误或默认404，并不能证明业务域名无法被绕过。

测试自己管理或已获授权的源站时，应保留正确域名：

curl -sS -D - -o /dev/null \
  --resolve www.example.com:443:203.0.113.10 \
  https://www.example.com/

--resolve让curl连接指定IP，同时继续使用www.example.com完成TLS SNI、证书校验和HTTP Host发送，能够更真实地模拟绕过CDN直连源站。

结果可以这样判断：

“返回403”比直接返回业务内容更安全，但它仍说明公网请求已经到达源站。如果目标是抵御大流量攻击，只在应用层返回403可能无法避免带宽、连接数和TLS计算资源被消耗。

测试时不要在文章、工单截图或聊天记录中暴露真实源站IP、私有域名、认证头和Cookie。

源站防火墙应该怎样限制

对于仍有公网地址的源站，最常见的做法是只允许CDN公布的回源地址范围访问80和443端口。

逻辑上可以表示为：

允许：CDN回源地址 → 源站80/443
允许：受控运维网络 → 管理端口
拒绝：其他公网地址 → 源站业务端口

但实施时要注意：

• CDN回源IP范围可能变化；

• 健康检查地址可能与业务回源地址不同；

• IPv4和IPv6需要分别配置；

• 多CDN架构要允许所有当前有效厂商的回源范围；

• 不要把SSH、数据库和管理面板对整个CDN地址段开放；

• 应保留受控运维通道和回滚方案；

• 修改前确认当前请求来源，避免把CDN一起拦截；

• 最好自动同步厂商官方地址范围，而不是长期维护静态副本。

Cloudflare的源站保护官方说明将限制源站连接、认证请求以及使用出站隧道列为不同强度的保护方式。其中Cloudflare Tunnel通过源站主动建立出站连接，使源站不必具有可公开路由的入站地址。

不同CDN的回源地址、产品能力和配置方式不同，必须以当前厂商官方文档为准，不能直接复制其他厂商的地址段。

只验证一个秘密请求头够不够

CDN可以在回源请求中加入秘密请求头：

X-Origin-Verify: 随机且保密的值

源站只处理携带正确值的请求，其他请求返回403。

这种方法部署相对简单，但不应被视为唯一防线：

• 源站仍然暴露在公网；

• 大流量仍然可以到达源站网络；

• 秘密值可能因日志、调试信息或错误配置泄露；

• 多层代理可能删除或覆盖请求头；

• 需要设计轮换和撤销机制。

AWS在限制CloudFront访问Application Load Balancer的官方方案中也使用自定义源站请求头，同时明确提醒必须保持请求头名称和值的机密性，并建议结合CloudFront托管前缀列表进一步限制网络来源。

更稳妥的做法是组合使用：

网络来源限制
+ HTTPS回源
+ 秘密请求头或签名
+ 源站日志与告警

mTLS认证回源能解决什么

普通HTTPS只验证源站身份：

CDN验证：连接的是正确源站

mTLS，也就是双向TLS，还要求CDN在回源时提供客户端证书：

源站验证：请求来自持有受信任客户端证书的一方

如果源站只接受指定CDN或自有代理的客户端证书，即使攻击者知道源站IP和业务域名，也无法完成受信任的TLS连接。

Cloudflare的Authenticated Origin Pulls官方文档说明，该功能通过mTLS帮助源站确认回源请求来自Cloudflare网络，为普通HTTPS回源增加一层身份验证。

使用mTLS时仍要注意：

• 正确验证客户端证书链；

• 规划证书到期和轮换；

• 不要只判断“客户端提交了证书”，而要验证受信任签发者；

• 多CDN环境需要分别规划证书和信任关系；

• 健康检查与灾备通道也要使用兼容认证；

• 证书私钥不能写入公开代码仓库或日志。

私有源站比隐藏公网IP更彻底

如果架构允许，源站可以不对公网开放，而是通过以下方式连接CDN：

• CDN到云VPC的私有源站功能；

• 源站主动建立的出站隧道；

• 专线或私有网络；

• 私有负载均衡器；

• 对象存储的私有访问控制；

• CDN厂商提供的源站访问身份。

AWS的CloudFront VPC Origins文档允许将部分负载均衡器或EC2源站放在私有子网中，并由服务管理安全组控制访问。

这类架构的优势是公网无法直接向源站业务端口发起连接，不再依赖“源站地址没有被发现”。

但私有源站也会增加运维复杂度，需要提前处理：

• CDN故障时的备用入口；

• 管理与部署通道；

• 健康检查；

• 多CDN接入；

• 日志与监控；

• 紧急回滚。

不能为了隐藏IP而在故障时临时把源站全部开放到公网。

默认站点返回404能不能算隐藏成功

不能。

如果使用正确Host直连源站时返回正常内容，默认站点返回什么都没有意义。攻击者或测试者可以主动发送业务域名作为Host。

即使正确Host直连也返回404，仍然只说明应用层没有找到内容，不能证明源站网络不可达。

默认虚拟主机拒绝未知Host仍然值得配置，因为它可以：

• 避免其他域名误绑定到业务站点；

• 减少默认页面泄露；

• 阻止部分Host头滥用；

• 降低错误站点被搜索引擎收录的概率。

但它只是附加措施，不是源站访问控制。

源站IP已经暴露后要不要立即更换

不一定要先换IP。

如果可以立即通过安全组、防火墙、私有网络或mTLS阻止公网直连，即使旧IP已经公开，攻击者也无法正常绕过CDN取得内容。

以下情况可以考虑更换源站地址：

• 旧IP持续遭受直接DDoS攻击；

• 上游网络在流量到达防火墙前已经拥塞；

• 无法在旧环境实施可靠来源限制；

• 历史服务和端口过多，难以确认是否清理完整；

• 正在迁移到私有源站或新的云网络；

• 需要让旧入口彻底退役。

正确顺序通常是：

建立新源站或新入口
→ 配置网络限制和认证回源
→ 验证CDN回源正常
→ 切换CDN源站配置
→ 关闭旧源站业务端口
→ 再处理旧地址退役

如果先更换IP、后考虑保护，新IP仍然可能通过DNS、日志、证书域名或应用配置再次暴露。

防火墙限制后为什么仍要考虑上游DDoS

服务器本机防火墙可以丢弃不允许的请求，但攻击流量仍可能先经过机房或云厂商的公网链路。

如果攻击流量已经占满上游带宽，即使服务器最终丢包，正常CDN回源请求也可能无法到达。

因此，高风险业务还需要确认：

• 云厂商或机房是否提供上游清洗；

• 源站公网带宽是否会被直接打满；

• 是否能够使用私有源站或隧道；

• 旧源站IP是否仍在对外广播；

• CDN回源是否经过独立链路；

• 遭受攻击时能否更换或撤销入口；

• 多源站是否具备隔离能力。

“服务器防火墙只允许CDN IP”主要解决直接访问和部分应用层绕过，并不等于自动获得上游大流量防护。

源站隐藏完成后怎样验收

可以按下面的顺序检查：

1. 公开业务域名只返回CDN入口
2. 所有A、AAAA、CNAME、MX和TXT记录完成审计
3. 未代理子域名不再指向Web源站
4. IPv4和IPv6都实施来源限制
5. 使用正确Host和SNI直连源站无法取得业务内容
6. 源站只接受CDN地址、mTLS或其他认证请求
7. 未知Host进入拒绝型默认站点
8. 管理端口不向CDN地址段或整个公网开放
9. 历史源站地址已经关闭或完成访问限制
10. CDN正常回源、健康检查和证书续期不受影响
11. 防火墙规则变更和认证失败都有监控
12. CDN故障时已有受控灾备方案

还可以使用CDNChart的CDN检测工具确认业务域名当前的CNAME、响应IP、ASN及CDN厂商线索，并结合CDN节点查询方法检查不同地区看到的公开入口。

但外部CDN检测只能观察当前公开路径，不能证明源站防火墙、mTLS或私有网络已经正确配置。这部分必须通过自有源站测试、日志和云安全组配置验收。

常见问题

接入CDN后还能查到源站IP，说明CDN没有生效吗？

不一定。业务域名可能已经正常经过CDN，但源站地址通过历史DNS、未代理子域、邮件记录或云平台入口暴露。应分别检查当前访问路径和源站防绕过配置。

源站IP泄露后，CDN的缓存和加速还有效吗？

正常用户通过CDN访问时，缓存和加速仍可能有效。风险在于其他人可以绕过CDN直接访问源站，使WAF、限速、Bot防护和DDoS防护失去作用。

把源站域名改成随机字符串就安全了吗？

不够。随机域名只能降低被猜中的概率，无法阻止历史记录、证书日志、配置泄露或网络扫描。即使地址已知，源站也应该拒绝未认证的公网请求。

源站返回403，算不算隐藏成功？

说明应用层可能已经阻止访问，但源站网络仍然可达。对于防止普通绕过有一定作用，对带宽消耗和连接攻击的防护有限。更稳妥的方案是叠加网络来源限制或mTLS。

只允许CDN IP后，还需要秘密请求头吗？

建议作为纵深防护保留。IP限制解决来源范围，秘密请求头或mTLS进一步验证回源身份。多层措施可以降低单项配置失误带来的风险。

为什么不能直接用HTTPS访问源站IP测试？

HTTPS需要正确的TLS SNI和HTTP Host。直接访问IP可能得到证书错误或默认站点，不能模拟真实业务。应在已授权环境中使用curl --resolve保留正确域名。

源站隐藏后还能保留直接访问的灾备入口吗？

可以，但不能把一个完全公开、长期可用的直连域名当作灾备。更合理的方式是使用备用CDN、受控VPN、身份认证网关或临时启用且有严格授权的应急入口。

多CDN架构怎样限制源站访问？

需要允许所有当前使用的CDN回源网络，并尽量为不同CDN配置独立的mTLS证书、签名或秘密请求头。切换前还要确认备用CDN能够通过源站防火墙和认证规则，否则DNS切换成功后仍会回源失败。