DDoS防护中启用源站隐藏通过CDN代理真实IP

在DDoS防护体系中，源站隐藏的核心逻辑就是让攻击者无法直接获取你真实服务器的IP地址，所有流量先经过CDN节点清洗和代理，再由CDN回源到你的源站。具体怎么做？简单说就是：你的源站服务器只允许CDN的回源IP段访问，防火墙拒绝一切非CDN节点的直接连接，同时在DNS层面把域名解析到CDN的IP上，而不是你自己的服务器IP。这样一来，攻击者拿到的永远是CDN的边缘节点IP，真正的源站IP被完全隐藏在CDN背后，DDoS攻击流量全部打在CDN上，你的源站只接收经过清洗的正常业务流量。

很多人以为开了CDN就等于有了DDoS防护，这是一个巨大的误区。CDN本身是内容分发网络，它的核心能力是加速和缓存，不是安全防护。只有把CDN和源站隐藏策略结合起来，配合WAF、高防IP、流量清洗等手段，才能构成一套完整的DDoS防御体系。下面我会从原理、配置步骤、常见坑点、进阶策略四个层面，把这件事讲透。

DDoS攻击的第一步往往是探测目标的真实IP。攻击者通过子域名扫描、历史DNS记录查询、邮件头分析、SSL证书信息泄露等手段，试图绕过CDN直接找到你的源站服务器。一旦真实IP暴露，攻击者就可以绕过CDN，直接对源站发起大流量攻击，CDN的防护能力瞬间失效。

源站隐藏解决的就是这个问题。它的本质是一种"网络层隔离"策略：让你的源站在互联网上"不可见"，只有CDN节点知道怎么找到你。攻击者即便扫描全网IP段，也找不到你的真实服务器在哪里。这不是什么高深技术，而是网络架构设计的基本功。

第一步，DNS解析指向CDN。登录你的域名DNS管理后台，把A记录或者CNAME记录指向CDN服务商提供的接入域名。比如你用的是某云厂商的CDN，就把域名CNAME到他们给你分配的CDN域名上。这一步做完，用户访问你的网站时，DNS会返回CDN边缘节点的IP，而不是你源站的IP。

第二步，配置CDN回源。在CDN控制台里设置回源地址为你的源站IP和端口。这里有个关键点：回源地址尽量不要直接写IP，而是用一个内部域名或者内网IP，这样即使CDN配置被泄露，攻击者也拿不到公网可达的源站地址。

第三步，源站防火墙策略。这是最核心的一步。在你的源站服务器上配置防火墙规则，只允许CDN回源IP段的流量进入。以Linux服务器的iptables为例，配置大致如下：

# 只允许CDN回源IP段访问80和443端口
iptables -A INPUT -p tcp --dport 80 -s CDN_IP_RANGE -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -s CDN_IP_RANGE -j ACCEPT
# 拒绝其他所有来源的80和443请求
iptables -A INPUT -p tcp --dport 80 -j DROP
iptables -A INPUT -p tcp --dport 443 -j DROP
# 允许SSH管理端口（限制来源IP更安全）
iptables -A INPUT -p tcp --dport 22 -s YOUR_OFFICE_IP -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -j DROP

如果你用的是云服务器的安全组，操作逻辑一样：入站规则只放CDN的IP段，其他全部拒绝。注意，CDN回源IP段不是固定的，你需要从CDN服务商那里获取最新的回源IP列表，并且定期更新，因为CDN厂商可能会调整节点。

第四步，隐藏邮件和其他信息中的真实IP。很多人忽略了这一点。你的邮件服务器如果直接从源站发信，邮件头里会暴露源站IP。解决方案是通过第三方邮件服务发送，或者让邮件也走CDN中转。另外，SSL证书申请时使用的验证方式也要注意，尽量用DNS验证而不是HTTP文件验证，避免在源站上暴露额外信息。

CDN回源有两种常见方式：域名回源和IP回源。域名回源是指CDN通过解析一个内部域名来找到源站，IP回源是直接配置源站IP。从安全角度看，域名回源更优，因为你可以把这个内部域名的DNS解析也做限制，只在CDN内部网络可解析，外部根本查不到。

另外，回源协议也有讲究。建议使用HTTPS回源，这样即使CDN和源站之间的流量被截获，攻击者也拿不到有用信息。同时在源站上配置SSL证书，只接受来自CDN的合法请求。有些高级配置还会加上回源Token验证，CDN每次回源都携带一个动态Token，源站验证通过才响应，进一步防止伪造回源请求。

# Nginx源站配置示例：验证回源Token
server {
    listen 443 ssl;
    server_name origin.yourdomain.com;
    
    # 只允许带有正确Token的请求
    if ($http_cdn_token != "YOUR_SECRET_TOKEN") {
        return 403;
    }
    
    location / {
        proxy_pass http://127.0.0.1:8080;
    }
}

场景一：SSL证书信息泄露。你在某个公开的证书透明度日志里查一下自己的域名，如果证书里绑定了源站IP或者子域名指向了源站IP，攻击者就能拿到真实地址。解决办法是用通配符证书或者只在CDN层部署证书，源站用自签名证书或者不部署。

场景二：历史DNS记录未清理。如果你之前直接把域名解析到源站IP过，这些历史记录可能被DNS扫描工具抓取到。要定期检查DNS历史解析记录，确保没有残留的直接解析。

场景三：源站主动对外发起连接。有些应用会主动向外部API发请求，如果这些请求从源站IP发出，对方服务器的日志里就会记录你的真实IP。解决方案是让这些外联请求也通过代理或者CDN出去，或者使用NAT网关统一出口。

场景四：CDN配置失误导致IP泄露。比如你在CDN上配置了多个域名，其中某个域名没有正确走CDN，或者CDN的某个节点配置错误直接暴露了源站。需要定期做全站扫描，确认所有入口都走了CDN。

源站隐藏只是DDoS防护的第一层。在实际生产环境中，你需要叠加多层防御。第一层是CDN边缘节点的流量清洗，CDN本身就具备一定的抗DDoS能力，能过滤掉大部分SYN Flood、UDP Flood等攻击。第二层是高防IP或者高防CDN，当攻击流量超过CDN清洗能力时，流量会被牵引到高防节点进一步清洗。第三层才是源站本身的防火墙和限流策略。

另外，建议部署任何cast（Anycast）网络架构。Anycast的原理是同一个IP地址在全球多个节点同时存在，攻击流量会被自动分散到最近的节点，单个节点承受的压力大幅降低。主流的CDN和高防服务基本都基于Anycast架构，这也是为什么选对CDN厂商很重要。

还有一个容易被忽视的点：源站本身的性能也影响抗DDoS能力。如果你的源站是一台2核4G的小服务器，即使CDN帮你挡住了99%的攻击流量，剩下1%的正常业务请求也可能把源站打垮。所以源站要有足够的带宽和计算资源，或者做好弹性扩容，流量大时自动加机器。

小型网站或者个人博客：用免费或低价CDN加上源站防火墙规则就够了。重点是把DNS指向CDN，服务器防火墙只放CDN的IP段。成本几乎为零，防护效果却很明显。

中型电商或者SaaS平台：需要专业的高防CDN服务，配合WAF做应用层防护，源站隐藏要做到IP段+Token双重验证。同时建议用独立的回源域名，DNS解析做内网隔离。这个级别的防护月成本在几千到几万不等，但能扛住大部分DDoS攻击。

大型互联网业务：需要自建或者采购专业的DDoS清洗中心，CDN只是其中一环。源站隐藏要做到完全的网络隔离，源站放在内网，通过多层代理才能到达。同时要有7x24小时的安全运营团队实时监控和响应。这种级别的投入是百万级的，但对于业务连续性来说是必要的。

源站隐藏不是一个单一的技术动作，而是一套完整的安全架构思维。核心原则就三条：第一，让外部永远看不到你的真实IP；第二，所有入口流量必须经过可控的中间层；第三，任何可能泄露IP的渠道都要堵死。做到这三点，你的DDoS防护能力会有质的提升。

最后给一个实操清单：检查DNS解析是否全部指向CDN、获取并配置CDN最新回源IP段、源站防火墙只放CDN IP、SSL证书不在源站暴露、邮件和外联不走源站IP、定期扫描确认没有IP泄露渠道。把这六件事做完，你的源站隐藏就基本到位了。