网站源站暴露的风险比多数人想象得更直接。攻击者不需要攻破CDN节点，只要找到真实服务器IP，就能绕过所有边缘防护直接对源站发起CC攻击、漏洞扫描、暴力破解甚至篡改源站内容。很多站点虽然接了CDN，但源站IP仍能从历史DNS记录、邮件头、证书透明日志、子域名或未同步的解析记录中被提取出来。CDN配置的核心目标，就是让源站只接受来自CDN节点的回源请求，其他一切直连行为全部拒绝。

最基础的配置是在源站防火墙或安全组层面做IP白名单。只允许你所使用的CDN服务商的回源IP段访问源站的80和443端口，其余来源全部丢弃。这一步能挡住绝大多数直连探测，但前提是你拿到的回源IP段是完整且持续更新的。部分CDN服务商会在控制台提供回源IP段列表，也有通过API动态获取的方式。如果源站部署在云服务器上，直接在安全组里配置白名单规则即可，不需要在系统内部再写复杂的iptables规则。

如果源站前面还有一层自建反向代理，比如Nginx，可以在server段里增加来源校验。下面这段配置只允许指定的回源IP访问，其他来源直接返回444状态码，不暴露任何服务信息。

server {
    listen 80;
    server_name origin.example.com;

    # 只允许CDN回源IP段访问
    allow 192.0.2.0/24;
    allow 198.51.100.0/24;
    deny all;

    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

光有IP白名单还不够，因为有些攻击者会伪造X-Forwarded-For头来绕过基于IP的访问限制。源站如果直接信任这个头，就会把伪造的地址当成真实客户端IP。正确做法是只信任来自CDN回源IP的X-Forwarded-For，并且明确指定信任的代理层数。Nginx里可以用real_ip模块来处理，但必须把set_real_ip_from设置为CDN的回源IP段，否则攻击者自己发一个X-Forwarded-For就能伪装成白名单IP。

set_real_ip_from 192.0.2.0/24;
set_real_ip_from 198.51.100.0/24;
real_ip_header X-Forwarded-For;
real_ip_recursive on;

另一个容易被忽略的暴露点是源站的TLS证书。如果源站443端口直接对外开放，即使防火墙只允许CDN回源IP，证书信息仍可能在证书透明日志中被检索到。攻击者可以通过证书序列号、域名关联关系反查源站IP。解决办法是源站使用自签名证书或仅用于回源通信的内部证书，CDN节点与源站之间走HTTPS时使用独立的回源证书，不暴露公网证书信息。同时源站的TLS配置里关闭对外的证书链展示，避免泄露主机名。

源站暴露还经常来自DNS解析历史。很多站点在上CDN之前，A记录直接指向真实服务器IP，这些记录会被第三方DNS历史数据库长期保存。即使后来切换到CDN，攻击者依然可以查询历史解析记录拿到源站IP。应对方式是切换CDN后更换源站公网IP，如果使用云服务器，可以通过弹性公网IP的释放与重新分配来实现。更换IP后，旧IP上的所有服务立即关闭，避免历史记录指向的地址仍然能访问到源站。

子域名也是源站泄露的重灾区。主站可能配置了CDN，但某些子域名比如mail、ftp、direct、origin、api-backup等仍然直接解析到源站IP。攻击者通过子域名枚举很容易发现这些直连地址。解决方法是所有子域名统一走CDN，或者将不需要公网访问的子域名直接解析到内网地址或停止解析。对于必须直连的后台管理域名，建议单独使用高防IP或独立的访问入口，不与主源站共用同一IP。

邮件服务头信息泄露同样常见。如果源站服务器上运行了邮件发送服务，比如通过PHP的mail函数发送注册邮件或通知邮件，邮件头里可能包含服务器的主机名和真实IP。攻击者注册一个账号，触发邮件发送，查看邮件原始头就能提取出源站信息。解决方法是源站发信统一通过第三方邮件服务或独立的邮件中继，不让Web服务器直接发送邮件，或者在邮件网关层剥离源站IP信息。

CDN配置里还有一个关键点：回源Host的设置。有些站点在CDN控制台配置回源时，回源Host填写的是源站IP而不是域名，这样源站收到的Host头就是IP地址。如果源站Nginx没有配置默认server或者默认server直接返回站点内容，攻击者就可以通过直接访问源站IP加Host头的方式绕过CDN。正确做法是源站只允许特定的Host头访问，其他Host一律拒绝。Nginx里可以配置多个server块，默认server返回444，只有匹配正确域名的server才处理请求。

server {
    listen 80 default_server;
    server_name _;
    return 444;
}

server {
    listen 80;
    server_name www.example.com;
    # 正常站点配置
}

对于使用云WAF或CDN的站点，还需要注意源站与CDN之间的回源协议。如果回源走HTTP，源站80端口必须只对CDN回源IP开放，同时源站内部服务监听在非标准端口上也能增加一层隐蔽性。比如源站应用监听在8081端口，CDN回源地址配置为http://origin.example.com:8081，这样即使攻击者发现源站IP，直接访问80或443端口也得不到任何有效响应。

源站暴露后的应急处理同样重要。一旦发现源站IP泄露，第一件事不是立刻封IP，而是评估泄露范围。如果只是单个IP被记录，可以更换IP并同步更新CDN回源配置。如果源站已经遭受持续攻击，需要先接入高防服务或流量清洗设备，再逐步切换。切换过程中要保证CDN回源配置同步更新，否则会出现源站拒绝CDN回源导致网站大面积不可用的情况。

长期来看，源站防护需要形成一套固定流程。新服务器上线时默认不分配公网IP，只通过内网与CDN节点通信。必须使用公网IP的场景，比如源站需要主动外联，可以通过NAT网关或代理服务器出口，不让源站直接暴露在公网上。对于已经上线的业务，定期检查DNS解析记录、证书透明日志、子域名解析情况以及防火墙规则是否仍然有效，把源站暴露风险控制在最低水平。

CDN配置减少源站暴露风险，本质上是一个纵深防御的过程。IP白名单、Host校验、证书隔离、DNS历史清理、子域名收敛、邮件头处理，每一项单独看都不复杂，但组合起来就能让攻击者难以找到并直连源站。安全防护没有一劳永逸的方案，持续监控和定期复查才是关键。