CDN开了之后，源站IP还要不要藏

CDN上线以后，很多人会下意识觉得源站安全了：用户访问域名，DNS解析到CDN节点，源站只跟CDN回源通信，外面看不到真实服务器IP。这个理解方向没错，但在实际环境里，只要源站IP曾经暴露过，或者业务架构里还有旁路入口，攻击流量就可能绕过CDN直接打到源站。

所以这个问题不能只看“有没有开CDN”，要看源站有没有能力承受被直接访问、有没有历史暴露记录、有没有做访问控制。CDN挡的是入口，不是自动把源站变成隐身服务器。

CDN能挡住什么，挡不住什么

CDN主要解决两类问题：加速和边缘防护。静态资源缓存到边缘节点，用户就近访问；遇到常见的CC、HTTP Flood、部分DDoS流量，CDN边缘节点可以先过滤一轮。

但CDN的工作前提是：攻击者走你的域名访问。如果攻击者拿到了源站IP，直接访问 http://源站IP 或者把Host头伪造成你的业务域名，请求就可能绕开CDN，直接落到源站Nginx、Apache、应用端口或者数据库旁路服务上。

实际使用中发现，很多源站被打穿，不是CDN防护能力不够，而是源站IP早就泄漏了。CDN前面挡得很努力，源站后门却开着。

源站IP常见泄漏位置

历史DNS记录

域名在接入CDN之前，A记录通常直接指向源站IP。很多安全平台、DNS历史查询库、搜索引擎缓存都会记录这些解析结果。哪怕后面改成CNAME到CDN，历史记录依然可能查到。

比如一个站点2023年用过1.2.3.4做源站，2024年接入CDN。攻击者查历史DNS，发现这个IP，再用Host头测试：

curl -H "Host: www.example.com" http://1.2.3.4

如果还能返回正常页面，基本就说明源站没藏住。

邮件、FTP、面板、API接口混在同一台机器

这里补充一点，很多中小项目为了省事，会把Web、邮件、宝塔面板、FTP、API、监控端口都放在一台服务器上。Web域名接了CDN，但mail.example.com、ftp.example.com、panel.example.com可能还是A记录直连同一个IP。

攻击者不一定从www域名入手，扫子域名、查证书、看MX记录，都可能把源站IP带出来。

源站主动外连留下痕迹

源站访问第三方接口、推送日志、回调支付、请求对象存储，有时会在对方日志里留下公网IP。这个风险在多人协作项目里很常见，开发、运维、安全各看一段，没人专门检查源站出口暴露。

证书透明日志和默认站点

HTTPS证书会进入Certificate Transparency日志。攻击者可以通过证书记录枚举子域名，再结合端口扫描找到可能的源站。

另外，Nginx默认站点配置不严谨也会暴露信息。访问源站IP直接返回业务页面、后台登录页、错误堆栈，这类情况在应急排查里很常见。

源站IP不隐藏会有什么实际风险

CDN防护被绕过

假设CDN套餐能抗100G DDoS，源站服务器只有10Mbps或者50Mbps带宽。攻击者不打CDN节点，直接对源站IP发起流量攻击，源站带宽很快被打满。用户访问域名时，CDN回源失败，最终表现还是网站打不开。

这类故障很容易误判成“CDN不稳定”。实际抓包和看监控会发现，CDN节点访问没问题，回源超时、源站CPU飙高、带宽跑满才是真正原因。

源站安全策略被直接测试

CDN一般会做WAF、Bot识别、频率限制、黑白名单。如果源站IP开放给公网，攻击者可以绕开这些边缘规则，直接对源站跑目录扫描、SQL注入测试、弱口令爆破。

很多业务在CDN侧配置了严格规则，但源站Nginx没有限速，应用本身也没有完整风控。这样CDN入口看起来很安全，源站入口却是裸奔状态。

真实业务容量被打穿

CDN节点抗压能力和源站抗压能力不是一个量级。边缘节点可以承接大量并发，但源站可能只有4核4G、10Mbps、数据库也在本机。攻击者只要让CDN缓存失效，或者直接打动态接口，就能把源站拖垮。

比如商品详情页、登录接口、搜索接口、订单接口，这些通常无法长期缓存。CDN能缓解一部分，但源站必须扛住回源压力。

哪些场景必须隐藏源站IP

游戏、支付、金融、企业后台

这类业务不适合把源站暴露在公网里。游戏业务怕DDoS和CC，支付业务怕接口被撞库和重放，企业后台怕弱口令、越权和0day扫描。CDN只能算入口层，源站层还要单独收口。

尤其是游戏服，玩家访问入口、API、更新包、公告站看起来是Web业务，但后面经常关联登录服、网关服、数据库同步。如果真实IP被扫出来，攻击者可能不只打Web，还会顺着端口找游戏协议服务。

源站带宽很小，但访问量不低

有些站点源站只有5Mbps、10Mbps，靠CDN缓存撑起日常访问。正常情况下没问题，一旦源站IP暴露，几十Mbps的恶意流量就能让机器变得很难用。

这种场景比较适合把源站放在精品线路或者高防线路上，再配合CDN。比如面向国内用户的企业站、下载站、跨境业务，可以考虑香港CN2、CMI、CU这类回国质量更稳的线路。如果你也在找这类云服务器，可以看看129云的香港综合-B型，4C 4G、90G SSD、10Mbps峰值，适合做轻量源站、企业官网、API源站，线路是CN2+CMI+CU，网络稳定性比普通国际线路好不少。

已经被打过的业务

被打过一次的源站，不要只换CDN规则。攻击者手里很可能已经有真实IP、旁路域名、历史解析、端口信息。继续沿用原IP，后面还会被重复点名。

实际处理时，比较稳妥的做法是换源站IP，清理历史入口，源站只允许CDN回源IP访问。否则CDN配置再多，源站还是会被直连。

源站IP应该怎么隐藏

源站防火墙只放行CDN回源IP

这是最关键的一步。不是“希望别人不知道源站IP”，而是“就算别人知道，也访问不了”。

源站安全组或iptables只允许CDN厂商回源IP段访问80、443端口，其他公网IP全部拒绝。这样攻击者拿到源站IP后，直接访问也会被丢弃。

常见规则大概是这样：

允许 CDN回源IP段 -> 源站 80/443

拒绝 0.0.0.0/0 -> 源站 80/443

允许 运维固定IP -> SSH 22 或管理端口

拒绝 其他所有管理端口公网访问

这里不要忘了CDN厂商的IP段会更新，最好定期同步。如果是多家CDN、备用CDN、海外节点回源，IP段要统一整理，不能凭感觉加。

源站Nginx校验Host

即使做了防火墙，也建议在Nginx层做Host校验。默认站点不要返回业务内容，未知Host直接444或403。

例如只允许 www.example.com 和 api.example.com，其他Host全部拒绝。这样即使有误放行，也不至于访问IP就看到业务页面。

多说一句，很多扫描器会直接扫IP段，看到80、443开着就访问。如果默认站点返回了公司名称、后台路径、框架报错，就等于给对方做资产识别。

回源使用独立域名，不和公网业务域名混用

建议准备一个专门的回源域名，比如 origin-example.internal-domain.com，只给CDN配置回源使用，不公开解析，不写在页面源码里，不给业务客户端调用。

公网用户访问 www.example.com，解析到CDN。CDN回源到独立源站地址。源站侧只信任CDN IP和指定Host。

这样排查问题也更清楚：用户入口、CDN入口、源站入口分开，不会所有东西都揉在一个域名里。

换掉已经暴露的源站IP

如果历史DNS、搜索引擎、攻击日志里已经能看到源站IP，单纯改防火墙可以挡直连，但长期来看还是建议换IP。尤其是经常被DDoS盯上的站点，旧IP会持续收到垃圾流量。

换IP时要注意几个动作同时做：

新源站IP不要直接绑定公网A记录

CDN回源改到新IP或新回源域名

安全组提前限制CDN回源IP

旧IP保留一段时间观察攻击流量，不要直接复用到新业务

检查子域名、邮件记录、面板入口是否还指向新源站

CDN加源站防护的常见架构

普通企业站和内容站

这类站点通常访问以静态内容为主，动态接口不多。CDN缓存命中率能做到70%到95%，源站压力不大。源站IP仍然建议隐藏，但可以不一定上高防源站。

典型配置：

用户 -> CDN -> 源站Nginx -> 应用服务

源站安全组：只允许CDN回源IP访问80/443

SSH：只允许公司固定IP或VPN访问

后台：单独域名，最好走VPN或零信任访问

如果访问群体在国内，源站放香港比放美国延迟更低。普通香港线路到大陆可能80ms到150ms不等，CN2、CMI、CU优化线路通常能压到30ms到80ms，晚高峰抖动也少一些。

跨境电商、TikTok、亚马逊相关业务

这类业务经常会考虑美国节点，原因是账号环境、平台访问、海外用户链路都更匹配。CDN可以加速前端资源，但源站IP也不能随便暴露，尤其是涉及后台、账号系统、素材管理时。

如果业务需要美国双ISP环境，可以看129云的美国双ISP-A型，2C 2G、40G SSD、25Mbps峰值，适合轻量电商、游戏辅助业务、TikTok和亚马逊相关场景。源站上云后，同样建议把Web入口放到CDN后面，管理端口只给固定IP访问。

高风险业务和经常被打的业务

如果业务本身容易被攻击，比如游戏、棋牌、直播、灰度发布平台、热门活动页，源站最好不要只依赖普通云服务器。CDN能吸收一部分边缘流量，但源站被直连攻击时，需要有高防能力兜住。

这种场景可以用：

用户 -> 高防CDN或普通CDN -> 高防源站 -> 应用集群

源站安全组只放行CDN回源IP

高防源站承接异常回源和绕源攻击

动态接口加限流、验证码、行为风控

129云的美国高防-D型配置是8C 16G、80Mbps峰值、300G防御，适合需要高防服务器租用、游戏接口、海外业务抗攻击的场景。购买前可以直接联系400-9177118，让技术确认线路、清洗策略、业务端口和防护模型，避免机器买了以后发现协议或端口不匹配。

不同做法的风险对比

怎么判断源站有没有藏好

直接访问源站IP测试

拿非CDN节点的普通网络环境测试源站IP。如果访问 http://源站IP 或 https://源站IP 能打开业务页面，说明没藏好。

再用Host头测试：

curl -H "Host: www.example.com" http://源站IP

如果返回200并且内容正常，源站对公网开放了业务入口。正确状态应该是连接被拒绝、超时、403、444，具体看安全组和Nginx配置。

查历史DNS和子域名

可以查域名历史A记录、子域名解析、MX记录、TXT记录、证书记录。重点看有没有子域名直接指向源站IP，尤其是这些：

origin.example.com

admin.example.com

api.example.com

test.example.com

mail.example.com

ftp.example.com

panel.example.com

很多源站不是从主域名泄漏的，而是从测试域名、后台域名、邮件域名泄漏的。

检查CDN回源配置

CDN回源地址如果直接填IP，本身没有问题，但要配合安全组限制。如果回源填域名，要确认这个回源域名不会被公开解析到公网，也不要被搜索引擎收录。

缓存规则也要检查。动态接口不要为了省事全站缓存，登录态、订单、用户中心缓存错了会出严重问题。源站隐藏是安全问题，缓存规则是业务正确性问题，两边都要看。

源站隐藏时容易踩的坑

只限制80和443，忘了其他端口

攻击者不一定只打Web端口。常见的SSH 22、Redis 6379、MySQL 3306、MongoDB 27017、面板8888、宝塔888、phpMyAdmin路径，都要收口。

公网服务器的默认策略建议是全部拒绝，再按需放行。不要全部开放后再慢慢关，这种配置在业务忙的时候很容易漏。

CDN回源IP段没更新

CDN厂商扩容节点后，回源IP段可能变化。如果安全组写死很久不维护，可能出现部分地区访问正常、部分地区回源失败。排查时看CDN日志，会发现某些节点被源站防火墙拦了。

比较稳的做法是关注厂商公告，或者用自动化脚本定期拉取CDN IP段更新安全组。业务量大时，不建议人工复制粘贴维护几十个IP段。

源站和管理后台放在同一个公网入口

管理后台最好不要跟用户业务共用入口。后台域名即使接了CDN，也容易被扫描和爆破。更稳的方式是后台走VPN、堡垒机、零信任网关，或者至少限制固定办公IP。

如果后台必须公网访问，至少要加MFA、IP白名单、登录频率限制、异常告警。不要只靠一个复杂路径，比如 /admin-2024-login，这种隐藏路径迟早会被日志、前端代码或人员沟通暴露。

源站IP已经暴露时怎么处理

先挡直连，再考虑换IP

遇到正在被打的情况，不要一上来就改一堆DNS。先在源站安全组限制访问来源，只允许CDN回源IP和运维IP。这样能快速判断攻击是不是绕过CDN直连源站。

如果限制后源站带宽下降、CPU恢复、CDN回源正常，基本可以确认问题在绕源访问。

换IP时同步清理入口

换源站IP不是改一个A记录就结束。要同步检查：

CDN回源地址

DNS所有A记录

后台域名

邮件服务

监控系统

第三方回调白名单

对象存储回源配置

负载均衡后端配置

有些业务换完IP后，支付回调失败、短信回调失败、监控误报，就是因为第三方平台还绑着旧IP或旧出口。

旧IP不要马上复用

旧IP如果已经进了攻击者目标库，短时间内还会持续收到扫描和攻击。不要马上把旧IP绑定到新业务，也不要拿去做数据库、管理机。至少观察一段时间，看流量是否还在打。

CDN不是源站安全的替代品

CDN适合做入口加速、边缘缓存、基础防护，但源站仍然要按公网服务器的标准来加固。安全组、最小开放端口、Host校验、管理面隔离、日志告警，这些不能因为前面有CDN就省掉。

比较常见的健康状态是：用户只知道业务域名，DNS只暴露CDN地址；源站只接受CDN回源IP；管理端只接受固定IP或VPN；数据库、缓存、消息队列不暴露公网；历史暴露过的IP不继续承载核心业务。

如果业务对可用性要求高，源站本身也要选稳定线路和合适防护。香港CN2、CMI、CU适合国内访问体验，美国双ISP适合跨境平台业务，美国高防适合海外抗攻击业务。服务器规格、带宽、防御值、线路质量要跟业务流量匹配，别让CDN前面很强，后面的源站只有一点点带宽在硬扛。