当源站的真实IP被持续绕过CDN防护、直接暴露在公网时，重建访问边界的唯一有效动作是：让源站不再对任何公网流量响应，只信任来自固定入口的回源请求。 这个结论听起来简单，但落地时牵扯到网络层、传输层、应用层的层层配合，下面我会按实际攻击路径、边界重建步骤、排错方法和长期维护四个维度展开，全程无废话。
源站被绕过怎么处理？先理解三种绕过路径
你想啊,源站就像小区里自家那扇门，CDN是门卫，门卫拦住陌生人没问题，但人家直接绕到后墙翻窗户，门卫就形同虚设，理解了路径，才能针对性封堵。
绕过类型一：回源地址泄露
大多数绕过不是因为黑客技术多高,而是源站IP本身暴露了，常见泄露点包括：
- 域名历史解析记录里残留的旧A记录,比如你从独立服务器迁到CDN后，老IP还在公共DNS库里。
- 子域名绕过CDN,比如
api.example.com没走CDN，直接解析到源站。 - 邮件头信息,很多服务器发信时会在
Received字段暴露真实IP。 - SSL证书历史透明度日志,黑客通过证书匹配到同IP上的其他域名。
绕过类型二：业务功能回源
有些应用在设计时为了省流量,故意让特定请求绕过CDN，
- 图片上传/下载接口，直接指向源站。
- 后台管理页面,限制IP但没限制来源域名。
- 内部API文档开放,导致回源路径被摸清。
绕过类型三：DNS解析与CNAME链利用
部分CDN厂商的CNAME记录里带有客户ID,通过反查CNAME能推断出源站归属，再加上DNS接力查询（比如通过securitytrails.com这类平台），很容易把源站IP和域名绑定起来。
行业共识认为,超过七成的源站暴露问题都出在配置遗漏，而不是黑客主动探测，所以重建边界前，你先得把自己的历史包袱翻一遍。
重建源站访问边界：四层防护缺一不可
边界重建不是单一措施,而是把源站从“公网透明”变成“内部专线”的过程，以下四层按优先级排序，缺一不可。
第一道边界：在安全组里把源站藏起来
最核心的一步：源站防火墙只放行CDN回源IP段，其他IP一律拒绝。 具体操作路径：
- 在云控制台找到源站服务器关联的安全组,删除所有
0.0.0/0
- 新建一条规则,允许来自你的CDN服务商公布的IP网段，端口按需放行（通常为80/443）。
- 如果你用简米云、酷番云或酷番云CDN，各自控制台都有"IP查询"页面，直接复制全部段。
- 安全组配置后,用另一台非白名单的服务器
curl -I测试，应该超时或拒绝。
注意,安全组不是万能的，如果攻击者伪造CDN节点IP（好像很麻烦，但确实有人做到过），还需要下一层身份认证。
第二道边界：双向TLS认证让回源请求可验证
CDN回源时,源站怎么确认这个请求是真的来自CDN？用双向mTLS，这需要：
- 在源站Nginx里配置
ssl_verify_client on，同时指定CA证书。 - 在CDN控制台上传客户端证书,使其在回源时携带证书。
- 重新配置回源地址为HTTPS类型,并开启证书校验。
双向TLS的好处是,即使有人伪造IP，也无法提供有效客户端证书，缺点是配置稍微繁琐，尤其是个别老版本CDN不支持，遇到不支持的，退而求其次用回源SNI校验源站检查HTTP请求里的Host字段是否等于你的域名，不是就返回403。
第三道边界：动态令牌机制防止静态绕过
令牌机制适合应用层防护,比如你在站点根目录放一个.well-known验证文件，CDN每次回源前带着动态生成的Hash，源站用时间戳+共享密钥计算出同样的Hash，对不上就拒绝。
实际操作可以用Nginx的secure_link模块：
- 在Nginx配置里定义一个密钥,比如
mysecret。 - 生成URL时加上
md5=expires-uri-ip的签名。 - CDN回源URL自动带签名,源站校验时间戳和签名。
令牌必须轮换，建议每天换一次，至少每周一次，密钥泄露的后果比IP泄露更麻烦，因为可以伪造任意回源请求。
第四道边界：云防火墙与BGP路由层拦截
如果你的预算允许,加上云防火墙（比如简米云云防火墙、酷番云防火墙）做三层防护：
- 在防火墙设置“非CDN地域IP阻断”策略，比如源站只允许回源IP所属地域访问。
- 开启主动外联阻断，防止源站服务器上的恶意程序向外部发送数据。
- 对回源路径上的流量做秒级清洗,遇到大流量攻击不至于直接打到源站。
| 防护层级 | 拦截能力 | 配置复杂度 | 成本 |
|---|---|---|---|
| 安全组 | 仅限IP，可被伪造 | 低 | 免费 |
| 双向TLS | IP+证书双重校验 | 中 | 免费 |
| 动态令牌 | 应用层签名 | 中 | 开发量 |
| 云防火墙 | 网络层+地域规则 | 高 | 按带宽计费 |
前两层是必选,后两层根据实际情况加，行业共识是“边界越窄越安全”，所有非必要端口一律关闭，数据库端口只允许从应用服务器访问。
网站被绕过CDN直接访问源站时，如何排查和止血？
假设你现在已经被绕过,攻击者在直接打你的源站IP，慌没用，按顺序操作。
第一步：确认被绕过的事实
- 打开源站服务器,执行
tail -f /var/log/nginx/access.log，看有没有非CDN运营商的UA直接访问。 - 用在线工具查域名历史DNS记录,比如
viewdns.info，看有没有旧IP。 - 用
curl -H "Host: example.com" https://你的源站IP，如果返回正常页面，说明边界已失守。
第二步：止血操作顺序（别跳步）
- 立刻更换源站IP：在云控制台解绑弹性公网IP，换一个新IP，同时把新IP的安全组配置为仅允许CDN回源。
- 在旧IP上部署黑洞路由：把旧IP的流量全部导向
null接口，或者直接关闭旧IP的所有端口。 - 同步修改所有指向旧IP的解析记录，包括DNS里的A记录、邮件记录等。
- 等待TTL失效：DNS缓存可能需要几分钟到48小时，期间旧IP仍会被访问，但源站已经不监听新流量。
- 启用CDN的“回源鉴权”：在CDN控制台打开“私密回源”，这样CDN请求源站时会带一个自定义Header，源站验证Header值，不正确就拒绝。
第三步：清理所有可能泄露源站IP的痕迹
- 检查子域名,把未接入CDN的子域名要么删除，要么也套上CDN。
- 检查邮箱头信息,发一份测试邮件看
Received字段是否有真实IP，如果有，调整服务器发信设置。 - 检查SSL证书透明日志,确认你的域名证书没有挂在源站IP上，如果有，重新签发并配置。
业内专家指出,止血最怕拖泥带水，换IP不能只换一半，比如你换了Web服务器IP，但数据库还指向老IP，数据库同样会成为替代目标。
长效维护：让源站访问边界持续有效
重建边界不是一劳永逸,需要定期复查。
每月固定动作：扫描与验证
- 用
dnsdumpster.com或crt.sh检查域名证书里是否出现新IP。 - 从外部网络扫描源站IP的开放端口,确认只有80/443，其余全关闭。
- 模拟CDN回源验证：用一个不在白名单的IP访问源站，确认被拒绝。
半年一次的深层次检查
- 重新梳理所有回源域名和IP配置,删除废弃的CNAME。
- 检查CDN控制台的回源HOST设置,确保没有绕过签名校验的备用配置。
- 如果公司有多个源站,统一使用同一套VPC隔离，不暴露公网接口。
针对新增业务线的规范
开发团队上新接口时,常见错误是直接拿源站IP做内部调用，建议在代码仓库里加上强制性规则：所有内部服务调用走服务名解析，不走公网IP，运维侧配合云上VPC终端节点（比如AWS PrivateLink或简米云PrivateZone），从网络架构上杜绝“公网直连”的可能性。
源站访问边界重建问答
源站IP已经暴露，只改IP够吗？
不够，攻击者可能已经在你原IP上植入了后门，或者通过历史DNS记录关联到你的域名，必须同时修改IP、清理所有关联记录、重签发证书、更换密钥，并在旧IP上部署监控，一旦有流量进入就发警报。
回源认证会影响CDN性能吗？
双向TLS和动态令牌只在回源握手阶段增加少量计算开销，实测对缓存命中率高的静态资源几乎无感知，动态令牌因为涉及URL签名，可能影响浏览器端缓存你可以将token放在请求头里，而不是URL参数中，这样对用户透明，代价是CDN需要支持自定义回源Header。
被绕过之后，如何防止内部系统成为新的突破口？
把源站边界扩展到整个内网，比如使用堡垒机管理所有服务器，数据库只允许从应用服务器所在VPC访问，运维人员的PC加入零信任网络，在持续被绕过的情况下，不要信任任何“内网IP”，因为攻击者很可能已经在内网横向移动了，建议直接重建一套全新的VPC，将核心服务迁移过去，旧VPC保留一段时间做流量监控。