CDN怎么防止源站IP泄露

CDN接入后，正常访问链路应该是用户请求打到CDN节点，CDN再回源到源站。外部用户只看到CDN节点IP，看不到源站IP。问题在于，很多站点虽然上了CDN，但源站IP还是能通过各种旁路被摸出来。

实际使用中发现，源站IP泄露不是CDN本身“没防住”，更多是接入方式、DNS历史记录、源站安全组、业务旁路暴露导致的。CDN只负责代理流量，不会自动帮你清理历史解析，也不会替你禁止用户直连源站。

源站IP最常见的泄露位置

最容易被忽略的是DNS历史记录。很多站点在接CDN之前，A记录直接解析到源站IP。后面虽然改成了CNAME到CDN，但历史解析可能已经被第三方DNS数据库、搜索引擎、资产测绘平台记录下来。攻击者查一下历史DNS，就能看到旧IP。

第二类是子域名泄露。主站 www.example.com 上了CDN，但 api.example.com、admin.example.com、test.example.com 还直连源站。攻击者不一定非要打主站，只要某个子域名和主站在同一台机器或同一段内网出口，就可能顺着找到源站。

第三类是邮件、FTP、SSH、数据库等服务暴露。比如同一台服务器既跑Web，又跑SMTP，邮件头里带了真实IP；或者22端口、3306端口暴露在公网，资产扫描工具能直接识别。CDN只代理HTTP/HTTPS，不会保护这些端口。

第四类是源站主动对外请求留下痕迹。常见于Web应用访问第三方API、拉取图片、回调支付接口、请求日志系统。如果对方能看到请求来源IP，源站IP就可能出现在第三方日志里。

源站不要允许公网随便访问

防源站IP泄露，最关键的一步不是“藏”，而是“就算知道了也打不进去”。源站安全组、防火墙、WAF策略要限制只允许CDN回源IP访问80和443端口。攻击者即使拿到源站IP，直接访问也应该被拒绝。

这里补充一点，很多人只在云厂商安全组里放行了CDN IP，但服务器本机防火墙没配，或者Nginx层没有做校验。实际排障时经常看到安全组规则被临时放开，后面忘了收回。建议安全组和系统防火墙都做一层限制，Nginx再根据Host、Header、证书校验做辅助判断。

如果CDN厂商提供固定回源IP段，就把这些IP段加入白名单。如果CDN回源IP会变，要关注厂商公告或使用自动同步脚本。不要手工维护一份几年不更新的白名单，后面CDN节点变更时很容易出现回源失败。

源站端口只暴露必要服务

Web源站对公网开放的端口越少越好。80和443即使需要开放，也应该只对CDN回源IP开放。SSH管理端口建议限制办公出口IP、堡垒机IP或VPN网段访问，不建议全网开放。

数据库、Redis、Elasticsearch、RabbitMQ这类服务不要直接放公网。即使有密码，也不应该暴露。真实环境里见过不少源站IP不是通过Web泄露的，而是因为3306、6379端口在资产测绘里被扫出来，IP和业务域名再一关联，源站就暴露了。

多说一句，端口改成非标准端口不是防护，只能降低一点低级扫描命中率。真正可靠的是访问控制、私网通信、VPN、堡垒机、最小暴露面。

DNS记录要重新梳理

接入CDN之后，要把所有对外域名重新检查一遍。主域名、www、api、static、upload、admin、m、test、dev、cdn、img 这些都要查。不要只看当前DNS控制台，还要查历史解析、证书透明日志、搜索引擎缓存、资产测绘结果。

证书透明日志也很容易暴露子域名。只要签发过公开SSL证书，很多子域名就能被查到。如果这些子域名没有接CDN，或者直接指向源站，风险就出来了。

比较稳的做法是：业务域名统一走CDN；内部管理域名不放公网DNS；临时测试域名用完删除；管理后台绑定VPN或办公网访问；源站A记录不要出现在任何公开解析里。

回源Host和源站站点要做隔离

很多Nginx配置里，默认站点直接返回业务页面。攻击者拿到源站IP后，访问 http://源站IP/ 也能打开网站，这种配置非常危险。源站应该拒绝IP直接访问，只允许正确的Host访问。

Nginx里可以配置默认server返回444或403，把真实业务站点绑定到指定server_name。这样直接打IP不会返回业务内容。虽然这不能替代防火墙白名单，但能减少误暴露。

如果CDN支持自定义回源Host，可以让CDN使用一个不公开的回源域名，例如 origin-xxxxx.example.com，并且这个域名不公开解析给普通用户，只在CDN侧配置。源站只接受这个Host，普通业务域名只在CDN上对外服务。

用Header校验辅助判断回源请求

不少CDN支持给回源请求添加自定义Header，比如 X-CDN-Token、X-Origin-Verify。源站Nginx或应用层校验这个Header，不匹配就拒绝访问。

这个方法适合做辅助防护。原因很简单，Header本身可以伪造。如果源站IP已经暴露，并且防火墙没有限制CDN IP，攻击者也可以带同样的Header访问。所以Header校验要和IP白名单一起用，不要单独依赖。

实际配置里可以这样理解：安全组限制“谁能连上来”，Header校验限制“连上来的请求是不是CDN带来的”。两层都做，误放行的概率会低很多。

源站不要和其他业务混在一起

源站服务器最好只跑被CDN保护的Web业务，不要同时承担邮件、管理后台、数据库、下载中转、监控面板等职责。混在一起后，任何一个旁路服务都有可能把IP带出去。

如果业务量不大，很多人为了省机器，会把一堆服务放在同一台云服务器上。这个阶段能跑，但安全边界很差。尤其是被DDoS盯上后，攻击者不一定从CDN入口打，直接打源站IP就能绕过前面的清洗节点。

购买服务器时可以按角色拆开：Web源站一台，数据库走内网，管理入口走VPN或堡垒机，高防入口或CDN入口单独规划。如果你也在找这种高防服务器、海外云服务器或大带宽节点，可以看看129云，像宁波高防-特惠提供100Gbps防御，适合国内高防场景；香港大宽带-E型有300Mbps峰值带宽，适合静态资源、下载、跨境访问；日本BGP-B型走精品网络，本地原生IP，适合日本方向低延迟业务。需要确认线路和防护策略时，可以直接打客服热线400-9177118问清楚回源、防护和带宽细节。

CDN回源地址不要用真实公网IP

很多人在CDN控制台里直接填源站公网IP，功能上没问题，但从管理角度看不够灵活。更推荐使用一个专门的回源域名，比如 origin.example.net，后面再把这个域名解析到源站IP。

这样做的好处是，源站迁移时只改回源域名解析，不用每个CDN配置都改一遍。更重要的是，可以把业务公开域名和源站管理域名分开，减少误配置。

注意，这个回源域名不要被公开使用，不要写进前端代码，不要出现在页面资源里，也不要拿它申请容易被外部枚举到的证书。回源域名最好只存在于CDN配置和内部运维文档里。

历史IP要废弃或换掉

如果源站IP已经在历史DNS、资产测绘、攻击日志里出现过，继续使用这个IP就很被动。即使现在套了CDN，攻击者照样可以直连旧IP试探。

这种情况下，比较干脆的处理方式是更换源站IP。新IP上线前先配置好安全组，只允许CDN回源IP访问，再切换CDN回源。旧IP保留一段观察期，但不要继续承载业务。确认没有正常流量后释放或改作无关用途。

实际迁移时要注意TTL。旧DNS记录如果TTL很长，部分递归DNS可能还会缓存旧结果。可以提前把TTL调低，比如从3600秒降到300秒，再做切换。切换完成后观察CDN回源状态、源站日志、错误率。

源站日志能看出很多问题

源站防护不是配完就结束，日志里会直接暴露问题。正常情况下，源站访问日志里的客户端IP应该主要是CDN回源IP。如果看到大量陌生公网IP直接请求业务路径，说明源站被直连了，或者白名单没生效。

还可以重点看这些特征：直接访问IP的请求、Host不匹配的请求、扫描器User-Agent、访问/wp-admin、/phpmyadmin、/.env这类路径的请求。如果这些请求能到达源站应用层，说明前面至少有一层访问控制没收紧。

Nginx可以单独记录Host、X-Forwarded-For、真实remote_addr、CDN节点Header。排查时不要只看业务日志，系统层的连接日志、防火墙日志、云安全组命中记录都要看。

不要让错误页面暴露源站信息

源站的错误页面、默认页、调试信息也可能泄露IP或服务器信息。比如PHP报错里带绝对路径，Nginx默认页显示版本，应用异常返回内网地址，后端接口报错打印连接串。

生产环境要关闭debug，隐藏Server版本，统一错误页。后端接口不要把上游地址、内网IP、数据库连接信息直接返回给前端。很多泄露不是被“攻破”的，而是错误信息自己写出来的。

邮件和回调场景要单独处理

如果Web源站需要发邮件，不建议直接用源站服务器的公网IP发。邮件头可能包含发送服务器IP，收件方日志也能看到来源。可以使用第三方邮件服务，或者让邮件系统独立部署，不要和Web源站共用IP。

支付回调、短信回调、Webhook也是类似。源站访问第三方服务时，对方日志会记录请求来源。如果业务敏感，可以通过固定出口网关、NAT网关或代理出口访问外部服务，不要直接暴露Web源站出口IP。

高防CDN和普通CDN的区别要看清

普通CDN主要解决加速、缓存、就近访问问题，对抗小规模恶意请求也有帮助。但如果源站IP泄露，攻击者直接打源站，普通CDN基本拦不住。

高防CDN或高防IP更关注DDoS清洗和攻击流量牵引。常见做法是业务域名解析到高防入口，高防节点清洗后再回源。这里源站白名单更重要，必须只允许高防回源IP访问，否则攻击流量绕过高防入口，源站还是会被打死。

游戏、金融活动页、促销站、私服、棋牌、跨境电商这类业务，源站IP一旦泄露，攻击成本很低。带宽打满、连接数打满、CPU打满都可能发生。选择线路时还要看用户分布，比如国内用户多关注BGP和高防能力，香港方向关注CN2、GIA、国际出口质量，日本方向关注本地原生和回国延迟。

源站IP泄露后的处理节奏

发现源站IP泄露后，不建议只改Nginx规则就结束。先确认泄露范围：哪些域名解析过这个IP，哪些端口暴露，哪些第三方平台能查到，攻击流量有没有直连源站。

然后收紧访问控制：安全组只放行CDN回源IP，SSH只放行办公网或堡垒机，数据库只走内网。接着检查CDN配置，确认所有业务域名都经过CDN，回源Host正确，HTTPS证书和强制跳转没有绕路。

如果泄露已经进入公开数据库，换IP更省事。换IP前先在新源站上完成白名单、防火墙、默认站点拒绝、日志记录，再切CDN回源。不要先切业务再补安全策略，窗口期很容易被扫到。

日常检查可以按访问链路来跑

从用户侧看，dig业务域名应该返回CDN CNAME或CDN节点IP，而不是源站IP。curl业务域名时，响应Header里不要出现源站内网地址、真实机器名、调试字段。

从源站侧看，访问日志里的remote_addr应该是CDN回源IP。直接curl源站IP应该返回403、444、连接超时，不能正常打开业务页面。用错误Host访问源站，也应该被拒绝。

从资产侧看，搜索业务域名、历史DNS、证书透明日志、子域名扫描结果，不能发现未接CDN但指向源站的记录。服务器公网端口扫描结果里，只应该看到被允许的管理入口，而且管理入口要有限制来源。

配置示例：Nginx拒绝直接IP访问

默认站点可以单独处理，避免IP直连返回业务页面。示例思路如下：默认server监听80和443，对未知Host直接返回444或403；真实业务server只绑定业务域名或回源Host。

如果只靠Nginx做这件事，攻击流量仍然会到达服务器，所以它不是DDoS防护。它的作用是减少信息暴露和误访问。真正抗打还是要靠CDN、高防入口、源站白名单、带宽和清洗能力。

配置示例：只允许CDN回源IP

Linux本机防火墙可以使用iptables、nftables或firewalld。云服务器还要在安全组里同步配置。规则思路是：允许CDN回源IP访问80/443，允许办公IP访问22，拒绝其他公网来源访问这些端口。

这里最容易踩坑的是CDN IP段更新。CDN厂商节点扩容或调整后，旧白名单可能导致部分地区回源失败。建议把CDN IP段维护成配置文件，通过脚本定期拉取并更新规则，更新后做回源探测。

别把源站IP写进前端和接口

有些站点为了临时调试，会在前端代码里写 http://源站IP:端口/api，或者在App配置里内置源站IP。上线后忘了改，抓包一看就暴露。移动端App尤其麻烦，一旦发版，旧版本配置可能长期存在。

前端、App、小程序、桌面客户端都应该访问业务域名，不要访问源站IP。内部测试也尽量用测试域名和内网环境，不要把生产源站IP散落在代码仓库、配置中心、CI/CD日志里。

多CDN场景也要保护源站

有些业务会接多个CDN做调度，比如国内一个、海外一个，或者正常CDN加高防CDN。多CDN时源站白名单会更复杂，但原则不变：源站只接受这些CDN的回源IP，不接受普通公网直连。

多CDN还要注意回源Host一致性。不同CDN默认回源Host可能不同，有的用用户访问Host，有的允许自定义。如果源站只接受某个Host，另一个CDN没配好就会502。上线前要逐线路测试，不要只测一个地区。

源站和CDN之间尽量用HTTPS回源

用户到CDN开HTTPS，不代表CDN到源站也是HTTPS。有些配置默认HTTP回源，虽然访问能通，但中间链路明文传输，不适合登录、支付、用户资料这类业务。

HTTPS回源可以降低链路中间被嗅探和篡改的风险，也方便源站基于SNI、证书、Host做更严格的校验。源站证书可以使用公开证书，也可以按CDN支持情况使用自签或私有证书，但证书校验策略要确认清楚，别出现“看起来HTTPS，实际不校验证书”的情况。

源站IP保护要从建站阶段就开始

如果新业务一开始就准备上CDN，源站公网IP不要先裸奔上线。服务器创建后先配安全组、系统防火墙、Nginx默认拒绝、管理入口限制，再接CDN。业务域名从第一天就解析到CDN，不要经历“先A到源站，后面再切CDN”的过程。

老业务改造时，重点是清理历史包袱。旧解析、旧子域名、旧测试环境、旧服务器、旧证书记录，都可能成为泄露入口。源站IP防护不是CDN控制台里点一下开关，而是把所有能绕过CDN的路径都堵住。