CDN开了之后，源站IP还要不要做防火墙策略隐藏

要做，而且大多数线上故障和攻击绕过，问题就出在这里。

CDN的作用不是让源站天然隐身，它只是让用户访问域名时，流量先到CDN节点，再由CDN回源。这个链路成立的前提是：用户不知道源站IP，或者知道了也打不进去。如果源站IP暴露，并且源站80、443、SSH、数据库端口还对公网开放，那CDN前面挡得再漂亮，攻击流量也可以直接打源站。

实际使用中发现，很多人开了CDN以后，只改了DNS解析，把www.example.com指向CDN的CNAME，源站安全组还是0.0.0.0/0放行80和443。看起来访问路径走CDN，实际上源站仍然是裸奔状态。

CDN挡的是入口，不是源站本身

CDN比较像门口的保安亭，正常访客会先到保安亭登记，再进入办公区。但如果后门没有锁，知道后门位置的人可以直接进去。源站IP就是这个后门。

CDN能处理的主要是经过CDN节点的流量，比如静态资源缓存、HTTP Flood清洗、CC策略、WAF规则、TLS卸载、回源压缩等。可如果攻击者直接访问源站IP，CDN节点根本看不到这部分流量，自然也谈不上防护。

比较典型的场景是：网站开了CDN，页面访问没问题，CDN面板也能看到请求量。某天源站IP被扫出来，攻击者直接对源站IP发起DDoS。源站只有1Gbps网卡，机房上游没有高防清洗，几分钟后机器还能ping通一会儿，但HTTP已经不可用，再严重一点直接黑洞。

这里要分清两个概念：CDN隐藏的是域名解析结果，防火墙控制的是源站可达性。只做前者，不做后者，安全边界是不完整的。

源站IP是怎么暴露的

历史DNS记录

很多域名在接入CDN之前，A记录直接指向过源站IP。被动DNS、历史解析库、搜索引擎缓存里都可能留下记录。后面即使改成CNAME到CDN，也不能假设以前的记录没人看得到。

实际排查时，经常能在安全平台、DNS历史查询工具里看到几个月前甚至几年前的A记录。攻击者不需要入侵你的系统，只要把历史IP拿出来扫一下，80、443还开着，就能确认是不是源站。

子域名没接CDN

主站www接了CDN，但api、admin、static、upload、test、old、dev这些子域名还是直连源站。这种情况非常常见。

尤其是api.example.com和admin.example.com，很多团队为了调试方便直接解析到源站公网IP。结果主站藏得很好，后台入口把源站暴露了。

邮件头、回调地址、第三方配置泄露

如果源站同时跑邮件服务，邮件头里可能带出真实IP。业务系统给第三方做支付回调、Webhook、图片抓取，也可能把源站地址写成IP形式。还有一些老系统会在错误页、接口返回、跳转Location里暴露内部域名或公网IP。

这里补充一点，证书透明日志CT也值得看。虽然它不一定直接暴露IP，但能把你申请过证书的子域名列出来。攻击者拿到子域名列表以后，再逐个解析、扫描，源站暴露概率会明显提高。

回源配置不严谨

有些CDN支持自定义回源Host，也支持源站IP回源。如果源站不校验Host，不限制CDN回源IP，那别人直接访问源站IP，再手动带上Host头，也可能拿到完整页面。

例如源站Nginx里只配置了server_name example.com，但默认站点也指向同一套业务。攻击者访问http://源站IP，虽然没有走CDN，但仍然返回真实网站内容，这就等于告诉对方：这个IP就是源站。

防火墙应该怎么做才算有效

源站80和443只允许CDN回源IP访问

这是最关键的动作。源站安全组、iptables、nftables、云防火墙都可以做，思路就是：公网80、443不再对所有IP开放，只允许CDN厂商公布的回源IP段访问。

例如源站安全组里，HTTP和HTTPS入站规则不要写0.0.0.0/0，而是写CDN回源IP段。不同CDN厂商会提供IP段列表，有些还会提供API用于同步。节点IP会变动，所以这件事不能只配一次就不管。

如果CDN厂商没有固定回源IP，或者IP池变化频繁，就要看它是否支持Origin Pull、Authenticated Origin Pull、mTLS、回源鉴权Header等能力。但多说一句，只靠一个自定义Header并不稳，因为Header可以伪造。真正有效的前提仍然是网络层先限制来源，应用层鉴权作为补充。

SSH、RDP、数据库端口不要暴露给公网

CDN只代理HTTP/HTTPS流量，SSH 22、RDP 3389、MySQL 3306、Redis 6379、PostgreSQL 5432这些端口跟CDN没关系。源站如果这些端口对公网开放，攻击者不需要绕CDN，直接扫端口就行。

管理端口建议只允许固定办公IP、VPN出口IP、堡垒机IP访问。数据库、Redis、MQ这类组件尽量走内网地址，不要给公网IP。很多入侵不是从Web打进去的，而是Redis无密码、MySQL弱口令、SSH爆破成功。

源站默认站点要处理掉

Nginx或Apache的默认server不要返回业务内容。访问源站IP时，最好直接返回403、444，或者空响应。这样即使有人扫到IP，也不容易通过HTTP响应确认它就是某个域名的源站。

Nginx里常见做法是把default_server单独写出来，直接return 444；业务server只响应指定Host。这样直接访问IP、乱带Host、扫目录，都会被挡在默认站点。

回源Host和证书也要对齐

如果CDN回源走HTTPS，源站证书、SNI、回源Host要配置正确。不要为了省事把源站HTTPS校验关掉，也不要让源站同时接受一堆无关Host。

有些故障就是这里引起的：防火墙限制CDN IP以后，CDN回源报502，排查半天发现源站证书只签了www，但CDN回源Host写成origin.example.com。安全策略和回源配置要一起改，不然上线时容易误伤。

不同业务场景下的处理方式

普通企业站、内容站

这类站点最适合用CDN隐藏源站。页面、图片、CSS、JS走CDN，源站只允许CDN回源IP访问。管理后台单独放到admin域名，并且限制办公IP或VPN访问，不要让后台也裸在公网。

如果访问主要来自国内，源站放香港、美国西海岸、新加坡都有人用。重点看回源延迟和稳定性，不是只看带宽数字。比如香港CN2线路回国内延迟通常更友好，适合源站和国内用户之间还有不少动态请求的场景。

在选源站机器时，如果你也在找这种适合放CDN后端、线路比较稳的海外云服务器，可以看看129云。像香港CN2大宽带-A型，2C、2G DDR4 ECC、SSD、25Mbps峰值、500G流量，适合轻量企业站、落地页、API小流量回源；需要美国大带宽承载图片、下载、视频切片回源的，可以看美国精品大宽带-C型，8C、8G、120G SSD、1Gbps峰值、2.5TB流量。选型拿不准可以直接问客服，热线400-9177118。

API业务

API接CDN要看接口类型。读多写少、可缓存、请求体不大的接口，CDN能明显降低源站压力。登录、支付、下单、鉴权这类动态接口，即使走CDN，也主要依赖WAF、限速、Bot识别，不一定有缓存收益。

API源站同样要限制CDN回源IP。还可以加一层回源鉴权，比如CDN回源时带固定Header，源站只接受带正确Header的请求。注意这个Header不要在前端暴露，也不要让客户端能直接传同名Header覆盖。

更稳的做法是：源站防火墙限制CDN回源IP，应用层校验回源Header，接口层再做签名、时间戳、防重放。不要把所有安全预期都压在CDN WAF上。

游戏、TCP、UDP业务

普通Web CDN不适合直接保护游戏TCP/UDP长连接。游戏服如果是TCP、UDP协议，需要用高防IP、游戏盾、Anycast防护、四层代理这类产品。否则源站IP一旦暴露，DDoS可以直接打到游戏服务器端口。

游戏业务常见攻击量不是几百Mbps，而是几十Gbps起步，遇到反射放大可能更高。1Gbps带宽的普通云服务器扛不住这种流量，哪怕CPU、内存还有余量，入口带宽先满了。

这种场景里，源站最好放内网或白名单后面，公网入口交给高防节点。源站只允许高防转发节点访问游戏端口，运维入口只允许堡垒机或VPN访问。

下载站、图片站、视频切片

这类业务接CDN收益很明显，但源站带宽也不能太小。CDN缓存命中率高时，源站压力很低；一旦缓存刷新、热门资源未命中、批量预热失败，回源流量会突然上来。

举个实际数字：一个100MB安装包，如果缓存未命中，同时有1000个用户从不同CDN节点触发回源，源站可能在短时间内被拉爆。CDN不一定只回源一次，跟节点分布、缓存策略、Range请求、文件分片都有关系。

所以下载类源站不仅要隐藏IP，还要设置合理缓存时间、Range回源策略、热点文件预热、回源限速。源站机器最好有足够的峰值带宽，美国精品大宽带-C型这种1Gbps峰值机器就比小带宽VPS更适合做下载回源。

只做CDN不做防火墙，会遇到什么问题

DDoS绕过CDN

最直接的后果就是攻击者打源站IP。CDN节点可能完全正常，监控里CDN命中率、边缘请求量都没异常，但源站CPU飙高、带宽打满、连接数耗尽，用户访问表现为502、504、回源失败。

如果源站所在机房触发黑洞，连SSH都进不去。黑洞时间可能是30分钟、2小时，也可能更久，看机房策略。业务层再怎么扩容都没用，因为流量在网络入口就被处理掉了。

WAF策略被绕开

CDN上配置了SQL注入拦截、XSS拦截、CC限制、地区封禁，但源站公网开放时，攻击者直接请求源站IP就绕过这些规则。很多人以为WAF没拦住，实际是请求根本没经过WAF。

排查方法很简单：看源站日志里的remote_addr。如果大量客户端真实IP直接出现在源站日志，而不是CDN回源IP，说明有人绕过CDN访问了源站。正常情况下，源站看到的remote_addr应该主要是CDN节点IP，用户真实IP通过X-Forwarded-For、CF-Connecting-IP、True-Client-IP这类Header传递。

源站被扫描和爆破

源站IP暴露后，扫描器会很快找到开放端口。SSH爆破、Web目录扫描、Nginx版本探测、PHPMyAdmin探测、Redis探测都会来。哪怕没有真正打穿，也会制造大量无效日志和连接压力。

实际使用中发现，新开的公网IP只要放开22端口，几分钟内就会出现爆破日志。这不是网站出名才会被扫，公网IPv4本来就在被持续扫描。

源站隐藏不是把IP藏到没人知道，而是让它知道了也没用

很多人纠结“源站IP能不能做到完全不泄露”。现实里很难。历史DNS、人员配置、第三方系统、日志、测试域名，都可能留下痕迹。

更可靠的思路是：即使别人知道源站IP，也只能看到端口关闭、403、连接被拒绝，无法直接访问业务。攻击源站IP时，安全组和上游策略能挡掉大部分流量；业务入口仍然只能从CDN或高防节点进来。

这里的关键不是神秘感，而是访问控制。源站IP不是秘密口令，不能把安全性建立在“别人不知道”上。

源站防火墙策略可以按这个方向配置

Web端口

80、443只允许CDN回源IP段。CDN IP段变化时要同步更新。源站Nginx默认站点不返回业务内容。业务server只响应指定Host。回源HTTPS开启证书校验，回源Host配置准确。

管理端口

SSH、RDP只允许固定IP、VPN、堡垒机访问。不要为了临时方便开放0.0.0.0/0。临时放行要设置过期提醒，用完删除。能改端口可以改，但改端口不是安全策略，只是降低扫描噪音。

数据库和中间件

MySQL、Redis、MongoDB、Elasticsearch、RabbitMQ、Kafka不要暴露公网。业务服务器和数据库之间走内网。必须跨地域访问时，用VPN、专线、内网互联或安全隧道，不要直接把数据库端口丢到公网。

监控和日志

源站日志要能区分CDN回源IP和用户真实IP。Nginx可以用real_ip模块，把CDN IP段设为可信代理，再从指定Header取真实客户端IP。否则安全分析时会看到一堆CDN节点IP，没法判断真实来源。

同时要监控源站公网入站流量。如果CDN已经接入，源站公网流量理论上应该主要来自CDN节点。突然出现大量非CDN来源连接，就要检查是否有绕过访问或攻击。

有些情况下，源站还需要高防

CDN适合HTTP/HTTPS防护，但不是所有DDoS都能靠CDN解决。源站IP一旦被打，最终还是看源站所在网络有没有清洗能力。

如果业务对可用性要求高，或者源站IP已经泄露过，单靠安全组白名单还不一定够。攻击流量在到达服务器安全组之前，可能已经把机房入口、云厂商防护阈值或公网带宽打满。安全组能拒绝连接，但不能让你的上游带宽无限变大。

这类业务可以把源站放到高防后面，或者使用高防服务器、高防IP、四层转发。Web业务是CDN加源站白名单，高风险业务是CDN、高防、源站访问控制一起用。游戏、金融活动页、营销投放页、下载分发站点，尤其要提前评估攻击面。

迁移到CDN后，容易漏掉的配置

DNS里残留直连记录

检查根域、www、api、admin、static、upload、old、test等记录。能走CDN的走CDN，不能走CDN的限制访问来源。废弃子域名直接删除解析，别留着指向源站。

源站还绑定公网回调地址

支付平台、短信平台、对象存储回调、CI/CD Webhook、监控探针，有时写的是源站IP或origin域名。迁移后要统一梳理，不然这些入口会继续暴露源站。

CDN回源协议和源站跳转冲突

CDN用HTTP回源，源站强制跳HTTPS；CDN再跟着跳，配置不当会循环跳转。还有一种是CDN访问HTTPS，源站证书不匹配，导致502。改防火墙之前，先把回源协议、Host、证书、跳转规则测通。

真实IP获取配置错误

接CDN后，源站看到的直接连接IP变成CDN节点。如果应用还用remote_addr做登录风控、限速、审计，就会误判。要配置可信代理IP段，从CDN传递的Header里取真实IP。

但不要无条件信任X-Forwarded-For。只有请求来源是CDN IP时，才读取这个Header。否则攻击者直连源站时可以伪造X-Forwarded-For，把日志和风控都绕乱。

测试源站是否还裸露

可以从外部网络直接访问源站IP，看80、443是否能打开业务页面。正常结果应该是连接拒绝、超时、403、444，不能返回真实站点内容。

再用curl带Host测试，例如curl -H "Host: www.example.com" http://源站IP。如果这样能打开页面，说明只靠Host区分还不够，防火墙没有挡住直连请求。

还要从非CDN IP访问管理端口，确认SSH、RDP、数据库端口没有对公网开放。用nmap扫自己的源站IP，能看到哪些端口就处理哪些端口。

CDN侧可以临时看回源日志，确认回源正常。源站侧看access log，确认访问来源主要是CDN回源IP。两边日志对得上，才说明链路按预期工作。

源站放哪里也会影响防护效果

源站线路不是只看延迟。CDN回源稳定性、带宽峰值、机房防护阈值、国际出口质量都会影响线上体验。国内用户访问香港CN2、美国CN2 GIA、优质BGP线路，体感差异会很明显。

如果源站在普通海外线路，CDN节点回源时可能遇到丢包和抖动。页面静态资源命中缓存时没感觉，一旦动态请求或缓存未命中，502、504就会冒出来。香港CN2适合面向国内的轻动态业务，美国大带宽适合内容分发回源，德国GTT直连和双ISP更适合欧洲访问和跨境业务部署。

选机器时不要只看“带宽1Gbps”这一个数字，还要看流量包、峰值策略、线路质量、是否有基础防御。129云的产品线里，美国精品大宽带-C型适合大文件、图片、下载类源站；德国双ISP-C型适合欧洲方向业务；香港CN2大宽带-A型适合国内访问延迟敏感的小型站点或API源站。

防火墙策略上线时别直接一刀切

建议先把CDN回源IP段整理出来，加入源站安全组。然后在业务低峰期切换规则，观察CDN回源状态、源站日志、错误率、502数量。确认没有异常后，再删除0.0.0.0/0的80、443放行规则。

如果业务有多个CDN、备用CDN、监控探针、第三方回调，都要提前加入白名单或改造访问路径。否则一收紧防火墙，主站没问题，监控报警、回调失败、备用链路不可用这些问题会一起出现。

更稳一点的做法是先记录不拦截，观察一段时间源站真实访问来源，把合法来源梳理清楚，再改成阻断。对于已经被攻击的源站，就不能慢慢观察了，要先收口入口，再补日志和规则。

CDN开了，源站IP仍然要做隐藏和访问控制

源站公网入口只留给CDN或高防节点，管理入口只留给运维网络，数据库和中间件走内网。历史解析、子域名、回调配置、默认站点、真实IP Header这些地方都要一起检查。

如果源站IP已经暴露，换IP可以做，但换完以后必须同步收紧防火墙。不然新IP迟早还会因为子域名、日志、回调、扫描再次暴露。换IP只是把后门换了个位置，防火墙才是把门锁上。