新IP已经生效，主域名也解析到了高防CDN，接下来要检查两件事：新地址有没有从其他地方公开，源站是否还接受外部网络的直接请求。

防止源站IP再次暴露，需要清理DNS和业务配置，限制回源来源，核对IPv6与旁路服务，再用保留域名信息的直连请求验收。

换IP处理了旧地址已经被知道的问题，这些配置决定新地址会不会再次成为可用的攻击入口。

验收时应分别留下两类证据：公开配置没有继续泄露新地址，未经授权的请求也无法绕过CDN访问业务。

新IP有没有被重新写回公开配置？

换IP后，最先检查的应该是自己维护的资产清单。

主域名接入了CDN，上传接口却直接指向新源站；生产环境已经调整，测试域名还和生产共用一台机器。这些遗漏不需要复杂的探测，就可能让新地址重新公开。

Cloudflare的 源站保护指南 也把仅提供DNS解析的记录、邮件基础设施和历史解析列入检查范围。即使使用其他CDN，这些位置仍值得核对。

从完整DNS清单开始，不只查首页

先在DNS管理平台导出或查看完整记录，检查子域名、通配符记录、分地区解析和故障切换配置，再用外部查询确认实际返回值。

下面的命令适用于已经安装 dig的Linux、macOS或Windows WSL环境。按照 BIND的dig使用说明 ，可以分别查询IPv4对应的A记录和IPv6对应的AAAA记录：

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

把示例域名替换成自己的资产，继续检查上传、下载、管理、测试及备用域名。

重点是返回结果中有没有出现新源站地址，或者能够继续解析到源站的名称。看到A记录，并不能直接判断没有使用CDN，因为CDN入口本身也可能以A或AAAA记录返回地址。

没有输出同样不能当作“没有风险”的证明。这组参数只显示回答部分；遇到空结果，可以去掉 +noall +answer查看查询状态，并结合DNS控制台、权威解析和其他网络的结果判断。

如果业务使用双栈，还可以对照 IPv6源站与IPv4访问的接入关系 检查客户端入口与CDN回源。客户端能通过IPv6访问CDN，并不意味着应该公开源站的IPv6地址。

回源域名换个名字，地址仍可能公开

为了方便管理，有些团队会给新源站设置一个很长的随机域名，再把它填进CDN控制台。

只要这个名称能在公网DNS中解析到源站，它就仍然是一个公开可查询的入口。名字难猜，可以减少偶然发现的机会，但不能承担访问认证的作用。

如果服务商支持直接配置源站IP，就不必为了回源额外创建公开解析。如果必须使用回源域名，则继续通过来源限制和回源认证保护业务，不应只依赖名称保密。

也不要为了测试新地址，短暂把生产域名公开解析到源站。临时解析可能被缓存或记录，后面改回CDN并不能撤回已经公开的信息。

检查源站主动对外连接时使用的地址

网站发邮件、发送业务回调、下载外部资源时，对方可能看到服务器使用的出口地址。

这个地址有可能与源站公网入口相同，也可能属于独立出口、NAT网关或代理服务，需要按实际网络结构确认。不能看到一条外联IP，就断言它一定是网站源站。

对于需要保护公网入口的业务，可以核对是否应使用独立邮件服务或出口。即使做了出口分离，源站入站访问限制仍要保留。

源站只允许CDN访问，规则应该加在哪里？

DNS清理完成后，应继续收紧源站业务端口。

目标是让通过既定CDN配置转发的请求正常回源，同时拒绝不需要的直接访问。这里最容易出错的是：放行范围不准确，或者规则加在了没有经过实际流量的位置。

使用正式回源范围，不用测速得到的节点IP

用户访问CDN时连接到的地址，与CDN向源站建立连接时使用的地址，未必相同。

回源允许名单应采用服务商提供的正式回源出口范围或专用出口信息，并确认：

• IPv4、IPv6是否都有对应范围。
• 健康检查是否使用不同来源。
• 增加节点或切换线路后，出口范围会不会变化。
• 多CDN、负载均衡和必要合作系统是否还有独立入口。

不要只放行一次测试中看到的几个地址，也不要为了省事放行整家云平台的大量无关网段。

配置前，要保留可信的运维通道和恢复方式。先验证允许规则可以承接正常回源，再逐步拒绝其他来源；同时检查登录、上传、接口调用和健康检查，避免只测首页。

访问限制要覆盖实际流量路径

源站前面如果还有负载均衡，主机看到的连接来源可能是负载均衡设备，而不是CDN出口。限制通常需要在能够识别真实连接来源的适当位置实施，并继续约束后端链路。

应用日志中显示的“客户端IP”也不一定是网络连接的对端地址。

NGINX的 Real IP模块说明 介绍了如何从可信代理提供的请求头还原客户端地址。开启这类配置后，应区分还原出的访客IP与原始连接来源，避免把访客地址拿去匹配CDN回源允许名单。

X-Forwarded-For等请求头也不能单独作为可信来源证明。只有请求来自已确认的可信代理，并且代理正确处理了相关字段时，应用才能按约定使用它们。

Docker端口和IPv6规则需要单独核对

使用容器部署时，“主机防火墙已经拒绝了这个端口”不一定就是最终结果。

Docker的 防火墙与端口发布文档 说明，在相关Linux网络配置下，发布到宿主机的容器端口会经过Docker创建的转发规则，可能在流量进入ufw预期处理的位置之前就被转走。

检查时要把容器端口映射、云端安全规则和主机实际过滤路径放在一起看。某个应用端口仍直接发布到公网，就可能形成绕过网站反向代理的入口。

IPv6也一样。IPv4规则生效，并不说明IPv6已经受到相同限制。应根据实际业务保留所需监听和访问范围，清理不需要的公网入口。

只有CDN网段白名单，为什么还要考虑回源认证？

允许某家CDN的共享出口网段，通常能限制请求来自哪些网络；它不一定能证明请求经过了你自己的网站配置。

在具备相应转发能力的共享平台中，其他账户的请求也可能使用同一批出口。业务需要更严格的隔离时，可以进一步确认是否支持绑定到本站的回源验证。

一种方式是双向TLS，也叫mTLS：CDN验证源站的服务器证书，源站同时验证CDN出示的客户端证书。这样不仅加密连接，还能检查连接方的身份。

Cloudflare的 Authenticated Origin Pulls说明 就区分了共享证书与自定义证书：全局共享证书只能证明请求来自Cloudflare网络；需要更严格地区分自己的账户或主机名时，应采用相应的自定义配置。其他厂商的验证范围、开通方式和套餐条件，需要分别确认。

如果方案使用秘密回源请求头，也要同时满足几个条件：通过HTTPS传输，由可信CDN配置设置或覆盖该字段，源站在提供业务内容前完成校验，并避免把凭据写进公开日志、前端代码或响应中。

固定秘密一旦泄露，就可能被重放。它适合作为额外的一层控制，不能代替源站网络限制。

还有两个容易混淆的配置：

源站装了HTTPS证书，不等于源站已经验证CDN身份。

限制Host域名，也不等于限制了请求来源。

正常域名通常是公开信息。知道IP的人可以在请求里携带相同域名，默认站点不返回内容只能解决一部分误访问问题。

怎样验证外网确实绕不过CDN？

浏览器直接打开 https://源站IP失败，可能只是证书名称不匹配，或者请求没有进入正确的虚拟主机。这样的结果不足以证明源站已经禁止直接访问。

更有意义的测试，是连接指定源站IP，同时保留业务域名。

以下操作仅用于自己管理或获准测试的服务器。应从未加入允许名单的外部网络执行，不要使用本来就被授权的运维出口。

先确认正常入口能够完成真实回源

示例适用于安装了curl的Linux、macOS或Windows WSL环境：

curl -q --noproxy '*' -sS -D - -o /dev/null \
  --connect-timeout 5 --max-time 15 \
  -w '\nhttp=%{http_code} peer=%{remote_ip}\n' \
  'https://example.com/'

这里使用根路径演示。正式验收时，应替换成已经确认存在、只读，并在CDN中明确不缓存的测试路径，同时查看新源站日志。

如果返回的是CDN缓存内容，只能说明边缘节点还能响应，不能证明新源站已经正常工作。给URL随便加一个参数，也未必能保证绕过缓存，仍要以实际规则和日志为准。

再保留域名，定向连接新源站

假设新源站IPv4为 203.0.113.10，可以这样测试：

curl -q --noproxy '*' -sS -D - -o /dev/null \
  --connect-timeout 5 --max-time 15 \
  --resolve 'example.com:443:203.0.113.10' \
  -w '\nhttp=%{http_code} peer=%{remote_ip}\n' \
  'https://example.com/'

如果源站还有公网IPv6，再从具备正常IPv6连通性的网络测试：

curl -q --noproxy '*' -sS -D - -o /dev/null \
  --connect-timeout 5 --max-time 15 \
  --resolve 'example.com:443:[2001:db8::10]' \
  -w '\nhttp=%{http_code} peer=%{remote_ip}\n' \
  'https://example.com/'

上述IP均为文档示例地址，执行时需要替换。

按照 curl的 --resolve 说明 ，这个参数为指定主机名和端口提供连接地址。URL仍使用业务域名，HTTP的Host以及HTTPS握手中的SNI域名信息也会按URL处理，更接近针对该站点的实际请求。

-q用于跳过默认curl配置文件， --noproxy '*'用于关闭curl代理设置带来的影响；它不会改变系统VPN或网络路由。 peer显示本次连接的对端IP， http显示取得的HTTP状态码。

命令默认只展示响应头。需要核对返回的是否为真实业务内容时，可以去掉 -o /dev/null。

如果CDN回源时改写了Host或SNI，还应按实际回源名称补充检查，不能只测一个业务域名。

不同结果，分别能证明什么？

http=000表示没有取得HTTP状态码，并不是服务器返回了一个叫“000”的状态。

源站使用私有CA或专用源站证书时，应在受控测试中配置正确的信任链，例如使用合适的 --cacert文件，再继续判断访问控制。客户端不信任服务器证书，与服务器要求客户端提供认证证书，是两个不同方向的验证。

验收应同时对照外部请求、CDN记录和源站日志。一次超时、一个403或者一张测试截图，都不足以覆盖全部入口。

旧IP、临时白名单和回滚方案怎样收尾？

新源站工作正常后，旧环境还可能继续影响安全。

一种容易留下的配置，是让旧IP上的反向代理继续转发到新源站，方便旧客户端“再过渡一段时间”。这种转发不一定公开新IP，却可能把旧入口收到的恶意请求继续送进新源站。

如果旧地址返回的是包含新IP的重定向，或者直接暴露新源站域名，则又增加了明确的信息泄露路径。

收尾前，应核对旧地址是否仍承接客户端、定时任务、支付回调、上传任务或其他系统调用。需要过渡的入口，应纳入正式防护与认证，并明确下线条件；不再使用的转发和监听，应在确认依赖迁移后关闭。

回滚方案也要提前准备。

CDN配置出现问题时，可以回退已验证的配置，或者切换到受保护的备用源站。不要把“临时公开解析到新源站”当作默认回滚方式，否则一次故障处理就可能重新公开地址。

临时允许的办公IP、测试机和第三方监控同样要登记用途与有效期。后续新增回源出口时，先验证来源和配置，再更新允许名单；更新失败不能自动退化成向所有来源开放。

每次发布后，还应重新检查三个位置：DNS记录、容器或负载均衡的公网端口，以及客户端下发的备用地址。它们最容易随着一次常规变更重新出现。

地址被知道之后，源站还需要哪些防护？

即使上述检查全部完成，也不宜承诺公网源站IP永远无法被发现。

来源限制和回源认证能够减少绕过CDN的业务请求，但如果攻击流量已经占满源站上游链路，服务器再丢弃数据也无法恢复被占用的带宽。源站所在平台的过滤位置、机房清洗能力与链路容量，需要单独确认。

遇到这种情况，可以结合 源站暴露后的防护选择 判断是否需要补充IP层面的保护。对于还承载其他端口或持续遭受直达攻击的服务器，也可以评估 高防服务器方案 能否覆盖相应协议和攻击范围。

在确认CDN07的 高防CDN接入方案 时，建议把源站地址、全部业务域名、协议端口、IPv6使用情况和现有访问限制一起提供。我们的节点、带宽及安全策略支持按业务需求调整；回源出口范围、健康检查来源和可用验证方式，则需要在具体方案中逐项确认。

如果准备采用私有回源或隧道，也应确认产品是否支持，以及故障恢复和运维如何安排。不能因为接入了高防CDN，就默认源站已经具备这些能力。

常见问题

换IP后，历史DNS记录会直接暴露新IP吗？

历史记录通常反映过去公开过的地址，不会自动知道新IP。但如果新地址再次出现在公开解析中，或者仍与其他可识别的服务共用，就可能被重新关联。检查重点应放在新地址有没有重新公开，以及公开后能否被直接利用。

回源域名改成随机字符串，有用吗？

可以减少简单猜测，但不能作为安全保证。只要名称能公开解析到源站，它仍然可能被发现。回源域名应配合来源限制和身份验证使用。

只允许正确Host访问，能不能挡住绕过CDN的请求？

不能单独依靠它。请求方可以携带公开的业务域名，HTTPS客户端也可以发送对应的SNI。Host限制适合减少错误站点访问，回源来源和身份仍需另外校验。

新IP刚换完就收到扫描，是否说明已经泄露？

不能仅凭扫描就下结论。公网地址可能遇到与具体网站无关的探测。应进一步检查请求是否准确对应业务域名、是否能获得真实业务内容，以及公开配置中是否存在新地址。

购买独立CDN IP，能代替源站访问限制吗？

不能。面向用户的独立接入IP、CDN回源出口和源站IP是不同位置的地址。独立接入IP的作用取决于产品方案，源站仍要检查旁路入口、回源权限和自身的网络防护。

完成接入后，保留这四项验收结果：

• 公开解析和客户端配置没有重新指向新源站。
• 正常CDN请求确实能够到达新源站。
• 未授权网络无法直接取得受保护的业务内容。
• 旧入口、临时规则和IPv6配置均已完成核对。

如果目前只完成了换IP和修改解析，可以通过 CDN07技术咨询 提交现有域名、协议和部署情况，先确认回源范围与接入条件，再安排源站侧加固和验证。