很多网站在上线后，都会选择使用CDN服务来提升访问速度和增强安全性。CDN能够在全球范围内部署节点，把用户的请求就近分发，从而减少延迟，同时还能在源站和用户之间形成一层保护屏障，隐藏源站IP，抵御直接攻击。按理来说，如果配置正确，用户和攻击者都应该只能看到CDN节点的IP，而无法得知源站的真实地址。然而，在实际运维中，我们经常发现即便网站接入了CDN，源站IP依然会被曝光。攻击者通过一些手段依然能够绕过CDN，直连服务器，对业务造成威胁。为什么会出现这种情况?这背后既有技术层面的原因，也有配置和习惯上的问题。

　　首先需要明确的是，CDN本质上是一个代理层，它通过在DNS解析中返回节点IP，把请求转发到距离用户最近的缓存节点，再由缓存节点去获取源站的数据。如果源站暴露在公网，并且缺乏严格的访问控制，那么只要攻击者绕过DNS解析环节，直接向真实源站IP发起请求，就等于绕开了CDN的保护。换句话说，CDN只能在用户正常访问的链路中隐藏IP，但它无法阻止IP本身在其他途径被泄露。CDN不是防火墙，更不是万能的隐身工具，它能隐藏，但隐藏的前提是源站本身不泄露。

　　最常见的泄露途径就是DNS配置错误。很多站点接入CDN后，只是将主域名交给CDN解析，却忽略了其他子域名。例如，www.example.com 已经走了CDN，但 mail.example.com、api.example.com 仍然直连源站。攻击者只要通过子域名爆破、批量解析，就可以轻易获取真实IP。类似情况还包括企业将部分静态资源托管在CDN上，但登录入口或后台仍直连源站，这类接口往往成为攻击突破口。只要源站域名解析直接指向服务器，隐藏就无从谈起。

　　另一个容易被忽视的泄露来源是邮件。许多网站服务器同时承担着邮件发送的角色，而邮件的头信息中往往包含了邮件服务器的真实IP。如果站点使用的仍是与Web服务同一台服务器，那么攻击者只需查看邮件头部，就能发现被精心隐藏的IP。很多企业忽视了这一点，没有将邮件业务剥离到独立的SMTP服务上，从而导致防护形同虚设。

　　SSL证书也是一个常见的突破口。如今大部分网站都采用HTTPS，而证书信息是公开可查询的。部分第三方服务能够根据证书颁发信息，反查与之绑定的IP地址。如果源站IP直接部署了证书而未进行限制，就会被这些查询平台记录，攻击者可以轻而易举地获取源站信息。类似的，还有搜索引擎爬虫的缓存，有时在站点未接入CDN之前，源站IP已经被收录，攻击者只需通过历史记录就能找到。

　　除了配置和信息泄露，还有主动探测带来的风险。攻击者会使用端口扫描工具在IP段中扫描，寻找特定开放服务。如果企业使用了常见的云服务商IP段，攻击者可以通过批量扫描和服务指纹识别推测目标源站。当他们发现某个IP与目标域名返回的数据一致，就能锁定真实IP。这类手段并不依赖配置错误，而是利用了源站公网暴露的事实，只要源站对外开放了80或443端口，理论上都可能被探测出来。

　　网站自身的代码和应用逻辑也可能成为漏洞。例如某些应用会在错误提示或调试信息中直接暴露服务器IP地址，或者在API响应的header中返回了源站信息。还有的开发者在测试时使用源站直连链接，遗留在前端代码或第三方接口调用中，被敏锐的攻击者发现后，就等于主动把IP送了出去。即使CDN配置得再完善，源站依然会被轻易绕过。

　　面对这些风险，很多站长会困惑，既然CDN不能完全杜绝IP泄露，那它还有什么意义?其实CDN的价值不仅在于隐藏IP，更在于流量调度和抗攻击。但如果想要最大化隐藏效果，源站就必须配合安全策略。最核心的做法，就是在源站防火墙或云厂商安全组中，严格限制只允许CDN节点访问Web服务端口。例如，Cloudflare、Akamai、阿里云CDN都会公开节点IP段，站长可以将这些IP写入白名单，拒绝其他所有来源的直接访问。这样，即使源站IP被发现，也无法被攻击者直接利用。换句话说，IP暴露不可怕，可怕的是源站不做限制。

　　除此之外，企业还需要分离不同的业务。Web服务与邮件服务尽量不要共用同一IP，避免邮件头信息暴露源站。后台管理端口应部署在内网之内，杜绝公网直接暴露。SSL证书的申请可以通过CDN完成，不要在源站重复绑定。对于历史泄露问题，可以使用安全检测工具扫描全网，确认源站IP是否出现在公开数据中，及时申请更换IP。更换IP虽然麻烦，但在安全角度往往是最有效的办法。

　　另外还需要意识到，攻击者并不总是依赖单一途径，而是多种方法结合。例如，他们可能通过历史DNS记录锁定一个旧IP，再通过端口扫描确认服务特征，最后结合邮件头部或SSL证书佐证，从而百分百确定目标源站。因此，防护也必须是全链路的，而不是只盯着某一个配置项。CDN只是第一层屏障，真正的安全依赖于源站本身的架构设计与运维习惯。