CDN 不能把源站 IP “自动藏起来”。它只会把用户访问的主要入口放到边缘网络；真正减少源站直连风险，还要让公开 DNS 不再直接指向源站、让源站只接受可信回源流量，并检查备用域名、响应信息和历史记录有没有留下旁路。最可靠的判断方法不是看控制台是否显示“已接入”，而是逐段验证外部请求是否只能经由预期入口到达应用。
源站 IP 是服务器在网络中的地址。即使主域名已经切到 CDN，未纳管的子域名、临时环境、邮件或管理服务仍可能使用同一台服务器，外部请求就有可能绕过 CDN。保护工作的目标是缩小不必要的公开路径，而不是假设一个地址永远不会被发现。
| 检查环节 | 要确认什么 | 常见遗漏 |
|---|---|---|
| DNS | 面向访客的域名解析到 CDN 提供的入口，而非直接解析到源站。 | 旧 A/AAAA 记录、泛解析、测试子域名和备用域名未清理。 |
| 回源访问 | 网站端口只接受预期的 CDN 回源地址或私网链路。 | 安全组仍允许任意公网地址访问 80/443。 |
| 应用响应 | 错误页、跳转、调试信息和下载链接不暴露内部地址。 | 临时跳转、日志截图或响应头留下了不该公开的信息。 |
| 变更记录 | 历史 DNS、旧环境和迁移前入口已经评估与下线。 | 切换完成后只测主站，没有复查遗留入口。 |
先列出主域名、常用子域名、API、静态资源、下载、后台、预发布和已经停用的名称，再逐个确认谁对外服务、谁必须经 CDN、谁可以关闭。只检查 www 往往不够：某个遗留域名如果仍直接解析到同一台源站，就会让整个入口隔离失去意义。
DNS 变更前要记录现有解析、TTL、证书与回滚方式；变更后应从真实用户路径验证页面、登录和接口是否正常，而不是只确认首页能打开。若你的业务需要区分静态资源、动态接口与不同地区访客，可先理解CDN 与高防服务器的职责边界，再决定哪些请求应该经过哪一层入口。
DNS 正确不代表源站已经受限。源站的安全组、防火墙或反向代理规则仍需要控制入站访问：网站回源端口应只开放给经过核验的 CDN 回源地址范围，或通过私有网络、负载均衡和服务间认证建立固定路径；SSH、数据库和运维面板则应与网站回源规则分开处理。
各 CDN 的回源地址范围、认证方式和产品能力会变化，配置时应以使用当天的官方文档和控制台信息为准，不能长期沿用截图或旧表格。规则更新后，至少验证两件事：正常域名访问和缓存未命中的动态请求仍能到达源站；不经过预期入口的公网直连应按设计被拒绝或不提供业务响应。
对于必须对外提供的非 HTTP 服务，也不应把“接了 CDN”当作保护结论。应另行设计专用入口、来源限制、身份校验和监控；如果这些条件无法满足，先明确风险边界和应急方案，再决定是否上线。
源站地址不只会出现在 DNS 中。迁移过程中的临时跳转、错误页、调试页面、下载地址、公开配置文件或不当的响应头，都可能让用户接触到与预期入口不同的地址。这里的重点不是收集更多信息，而是从自己的站点和运维记录中排查不必要的公开内容，并及时下线失效页面与测试服务。
同时注意虚拟主机配置：直接以 IP 访问时不应返回默认站点、管理页面或可识别的业务内容；域名校验、Host 处理和 HTTPS 配置也应与实际入口一致。出现异常时，结合访问日志区分 CDN 回源、正常用户和未知来源，比只看总访问量更容易定位问题。
一次 DNS 切换无法自动抹去旧路径。域名曾经直连源站、迁移前环境仍在运行、第三方监控或文档引用了旧地址，都可能成为后续排查对象。更稳妥的做法是把这些记录列入变更单：哪些入口已关闭、哪些仍需保留、保留的业务理由是什么、何时复查。
如果本次同时调整服务器、网络或区域，建议把入口改动与数据和业务切换放进同一份回滚计划，参考云服务器迁移的盘点、切换与回滚清单明确验证顺序。这样即使需要恢复，也不会因为临时开放过多端口或旧 DNS 记录而制造新的暴露面。
不一定。CDN 只改变主要访问入口；若 DNS、备用域名、防火墙或旧记录仍允许绕过 CDN 直连源站，地址仍可能暴露。
需要用真实接口验证。动态请求同样应通过受信任的回源路径到达源站，但各服务的回源范围、认证方式和配置细节不同，应按当前官方文档和实际日志核对。
先确认它没有承载下载、回调、证书验证、邮件或运维任务。对仍有依赖的旧环境，应制定迁移、访问限制和下线窗口，而不是在不清楚依赖时直接停止服务。