套了 CDN 为什么还会被打到源站
很多站长以为网站接入 CDN 之后就安全了：访客只看到 CDN 的 IP，攻击者也应该只打到 CDN 节点。但现实是，每天都有大量套了 CDN 的网站源站被直接攻击——网站突然打不开，一查发现是源站 IP 被找到，攻击者绕过 CDN 用大流量直连源站，或者直接把源站打挂。问题就出在：CDN 只隐藏了流量入口，并没有隐藏源站本身。只要源站 IP 暴露，攻击者完全可以绕过 CDN 这层「盾」，直奔你的服务器。
这篇文章先讲清楚源站 IP 最常见的几种泄露途径，再给出从防火墙到 Nginx 配置的完整防护方案。内容面向个人站长，命令都可以在你的服务器上直接操作，不需要额外购买任何商业服务。
源站 IP 是怎么泄露的
要防泄露，先要知道泄露的入口。根据真实案例分析，以下七种途径占了绝大多数：
第一，历史 DNS 记录。很多网站是先直接用服务器 IP 跑了很久，之后才接入 CDN。域名曾经的 A 记录会留在各种 DNS 历史数据库中（比如 SecurityTrails、ViewDNS.info、微步在线等），翻一翻就能找到源站 IP。这类历史记录无法删除，是最常见也最难防的泄露源。
第二，子域名没有走 CDN。站长通常只给 www 和根域名套了 CDN，但 mail、ftp、api、test 这类子域名直接解析到源站 IP。攻击者用 subfinder、OneForAll 之类的工具枚举一遍子域名，随便挑一个没套 CDN 的，源站 IP 就出来了。这是个人站长最容易犯的错误。
第三，证书透明度日志。所有公开签发的 SSL 证书都会被记录到证书透明度（CT）日志里，任何人都可以在 crt.sh 上按域名搜索。如果源站自己用公开 CA 签过证书，或者某个解析到源站的子域名签过证书，证书里记录的 IP 或域名关联信息就可能暴露源站。
第四，邮件头信息。自建邮件服务器的网站，发出的每一封邮件都会在 Received 头里带上服务器的真实 IP。收件人只要看一眼邮件原文，源站 IP 就暴露了。网站和邮局共用一台服务器时尤其危险。
第五，源代码和配置文件泄露。不少站长把服务器 IP、数据库地址写死在代码里，又习惯把代码推到 GitHub 仓库，一个不留神设成公开，攻击者搜配置文件关键词就能找到源站。历史提交里的 IP 即使后来删掉也仍然存在。
第六，IP 直访未被禁止。源站的 Nginx 没有做限制，访问者直接输入源站 IP 也能打开网站（只是 Host 头不对而已），攻击者随便扫一下全网 IP 段，用你的域名特征一匹配就找到了。
第七，网络测绘平台。Shodan、FOFA、Quake 这类测绘平台会持续扫描全网 IP 并记录指纹。网站标题、favicon 图标哈希、SSL 证书指纹都可以作为搜索特征，反查就能定位到源站。
了解了泄露途径之后你会发现，源站 IP 的暴露几乎是不可避免的——历史 DNS 删不掉，测绘平台一直在扫。所以防护思路不是「让 IP 永远不被找到」，而是「即使 IP 被找到，也打不进来」。下面按优先级介绍防护手段。
第一道防线：防火墙只放行 CDN 回源 IP
这是性价比最高、也是最关键的一步：在源站的安全组或防火墙里，把 80 和 443 端口的访问来源限制为 CDN 的回源 IP 段，其它来源一律拒绝。各家云服务商的 CDN 都会公布官方回源 IP 段：Cloudflare 在官网有 IP 列表页面，阿里云、腾讯云、百度云加速的文档里也都有回源 IP 清单。以 Cloudflare 为例，用 ufw 可以这样配置：
# 先拒绝所有外部访问 80/443
ufw default deny incoming
# 只放行 Cloudflare 回源 IP 段（示例，完整列表以官方页面为准）
ufw allow from 173.245.48.0/20 to any port 80 proto tcp
ufw allow from 173.245.48.0/20 to any port 443 proto tcp
ufw allow from 103.21.244.0/22 to any port 80 proto tcp
ufw allow from 103.21.244.0/22 to any port 443 proto tcp
# 再放行自己的管理 IP，SSH 千万别用默认端口裸奔
ufw allow from 你的家庭宽带IP to any port 22 proto tcp如果服务器在云厂商的安全组里（阿里云安全组、腾讯云防火墙），建议在安全组层面就做同样的限制，效果一样且不占用服务器 CPU。用云厂商安全组时注意：安全组规则有数量上限，而 CDN 回源 IP 段可能有好几十条，可以先在服务器自身的防火墙（ufw/iptables）里配，安全组只做粗粒度控制。配置完成后，用手机流量（不要用家里宽带，避免误伤）访问一下网站确认 CDN 回源正常，再试着直接访问源站 IP 的 80/443 端口，应该会连接超时——这就说明直连已经被挡住了。
第二道防线：Nginx 禁止 IP 直访
防火墙之外，Nginx 也要做一层防护，防止两种情况：一是防火墙规则写错导致漏放行，二是攻击者用源站 IP 加上伪造的 Host 头来试探。在 Nginx 配置里单独建一个默认站点，把所有未匹配到具体域名的请求全部丢弃：
server {
listen 80 default_server;
listen 443 ssl default_server;
server_name _;
# 直接返回 444（Nginx 特有的「不响应直接断开连接」）
return 444;
}再在真正的站点配置里加一道 Host 校验，只有域名匹配才继续处理，防止有人用 IP 加 Host 头的方式访问：
server {
listen 80;
server_name www.example.com example.com;
# 非白名单 Host 一律断开
if ($host !~* ^(www\.)?example\.com$) {
return 444;
}
# ...其余配置
}注意 CDN 回源时默认会用源站域名作为 Host 头，所以这道校验不影响正常回源。配完后 reload Nginx：nginx -t 先检查语法，再 nginx -s reload 生效。用 curl 直接访问源站 IP 验证：
curl -k -H 'Host: www.example.com' https://源站IP/
# 期望结果：连接被重置或超时，而不是返回网站内容如果返回了网站内容，说明 IP 直访仍然通，需要回头检查防火墙规则和 default_server 配置。
第三道防线：回源双向认证（以 Cloudflare 为例）
如果你用的是 Cloudflare，它提供 Authenticated Origin Pulls（回源双向认证）功能：源站要求 CDN 回源时必须出示客户端证书，没有证书的请求一律拒绝。这样即使源站 IP 暴露、防火墙规则被绕过，攻击者直连也无法建立正常的 HTTPS 连接。开启步骤大致是：先从 Cloudflare 下载源站 CA 证书，配置到 Nginx，然后开启客户端证书校验：
# 下载 Cloudflare 源站 CA 证书后放到 /etc/nginx/certs/
server {
listen 443 ssl;
server_name www.example.com;
ssl_certificate /etc/nginx/certs/example.pem;
ssl_certificate_key /etc/nginx/certs/example.key;
# 回源双向认证：要求客户端出示 Cloudflare 签发的证书
ssl_client_certificate /etc/nginx/certs/cloudflare-origin-ca.pem;
ssl_verify_client on;
}改完先 nginx -t 验证语法，再 reload。此时直接访问源站 IP 会报证书校验失败，而 Cloudflare 回源一切正常。其它 CDN 也有类似能力（阿里云有回源鉴权，腾讯云有回源 SNI 校验），原理相同：让源站只认自家 CDN 的「暗号」。这套方案对自建 CDN 不适用，但绝大多数个人站长用的都是云 CDN，完全够用。
收尾工作：堵住子域名和邮件这两个洞
防火墙和双向认证做好之后，再回头处理最容易忽略的两个泄露点。第一，检查所有子域名：把 DNS 解析记录全部列出来，凡是没走 CDN 的、且不需要对外提供服务的子域名，直接删掉解析；必须要用的子域名（比如邮件服务器的 MX 记录），要么把对应服务迁到别的机器，要么接受风险并加强源站防火墙。一个实用的习惯是：源站上只跑网站，其它服务能分开就分开。第二，邮件服务：如果网站和邮局在同一台服务器，要么把邮局迁走，要么换用第三方邮件服务（腾讯企业邮、阿里企业邮对个人站都有免费额度），从根上避免邮件头泄露服务器 IP。
另外两个辅助手段也建议顺手做掉：一是把源站 SSH 端口改掉并只允许你自己的 IP 登录，配合 fail2ban 防止爆破（这也是攻击者拿到 IP 后的第一目标）；二是定期查看源站访问日志，筛选非 CDN IP 段的直接请求，一旦发现来自陌生 IP 的直连探测，说明 IP 可能已经泄露，及时在防火墙里封禁并检查有没有新的暴露途径。
验证防护是否到位
全部配置完成后，做一次完整的自测，按以下清单逐项确认：
# 1. 从外网直连源站 IP（用手机流量或在线工具）
curl -k https://源站IP/ # 期望：超时/拒绝
curl -k -H 'Host: www.example.com' https://源站IP/ # 期望：超时/拒绝
# 2. 检查 crt.sh 上有没有新的证书关联到源站
# 浏览器打开 crt.sh 搜索你的域名，逐个核对
# 3. 访问网站确认 CDN 加速正常
curl -I https://www.example.com/ # 期望：返回 CDN 节点 IP 和缓存相关响应头如果第 1 步仍然能连通，按顺序排查：防火墙规则是否真的加载了、default_server 是否生效、有没有其它端口（比如 8080）没被保护。自测通过后，把「防火墙白名单 + 禁 IP 直访 + 回源认证 + 子域名/邮件清理」这套组合保持下去，并每隔几个月复查一次——CDN 的回源 IP 段可能调整，你的域名解析也可能新增子域名，防护配置需要跟着更新。
最后总结一句：源站 IP 泄露不可怕，可怕的是泄露之后源站毫无防备。把上面三道防线配齐，即使 IP 被翻出来，攻击者面对的也只是一台「只认 CDN、其它请求一律断开」的服务器，CDN 这层盾才真正发挥价值。