接入边缘之后源站为什么还会被打

边缘防护的思路很朴素：让访客先连接到边缘节点，由节点完成过滤和加速，再把请求转发给源站。源站不再直接对公网提供服务，攻击者也就找不到直接下手的位置。

但接入之后仍然被打的情况并不少见。原因通常不在边缘服务，而在一些遗留的线索上：历史解析记录没有清理、证书里带着真实地址、邮件服务或者其他子域名仍然指向源站，这些都能让人绕开边缘。

所以接入只是开始，接下来要做的是把能指向源站的路径一条条收掉。这项工作不复杂，但需要耐心，漏掉一条，前面的努力就打了折扣。

接入时需要注意的配置

把域名解析指向边缘服务之后，先在边缘侧配置回源地址，确认回源协议和端口跟源站实际提供服务的方式一致。这一步细节不少，配错的表现通常是网站能打开但部分功能异常。

证书建议在边缘侧统一管理，源站只接受来自边缘节点的请求。这样可以避免源站证书里出现真实地址，也省去在多个位置重复续期。

如果有多个子域名，逐个确认它们的解析目标。测试环境、邮件服务、接口域名常常被遗忘，而它们中的任何一个直接暴露，都会成为进入源站的侧门。

怎么确认源站已经藏住

验证的办法是从外部主动去找。换一个没访问过站点的网络环境，尝试直接连接源站地址，看返回的是拒绝还是正常的页面。如果还能直接打开站点，说明暴露依然存在。

也可以从解析历史入手。把域名解析的记录梳理一遍，看看有没有已经不再使用、却仍然指向源站的记录。这类记录在变更时最容易被留下，平时也最难被发现。

还要检查页面内容里的绝对地址。如果引用的图片、脚本写的是源站地址，访客的浏览器就会直接去连它，等于把真实位置公开出来。

隐藏之后的运行维护

源站只允许边缘节点访问之后，运维方式也要跟着调整。日常登录不再走公网，改为通过固定的运维通道；临时开放的入口用完立刻收回，否则一次调试就留下一个新的暴露点。

监控要换个角度看。原来直接看源站的流量，现在更要关注边缘侧的回源数据：回源频率异常升高、回源请求集中在少数地址上，往往说明有人正在试着绕过来。

源站地址一旦被记录过，即使后来做了隐藏，也不能假设它已经被忘掉。访问控制这些东西不是可选项，隐藏只是第一层。

再往后就是常规工作：定期检查解析、证书和访问规则，把这些纳入例行的运维清单，而不是等出了事再来找线索。

长期维持的几件小事

源站地址一旦变化，记得同步更新边缘侧的回源配置，否则表现是网站间歇性不可用，排查起来很费时间。

定期从外部做一次连通性检查，确认源站地址在公网上确实连不通。这件事简单，但隔一段时间做一次很有意义。

边缘侧的规则要和源站的实际能力对上。比如节点允许的请求体大小和源站配置不一致，大文件上传就会失败。

业务用到的邮件、接口对接这类不走边缘的服务，它们的地址要单独保护，不能因为主站藏好了就放松。

监控要覆盖回源链路。回源失败、回源变慢，这些指标比访客侧的响应时间更早地反映问题。

把配置改动记录下来。解析、回源、证书这些环节相互关联，改动一处往往要确认其他几处。

团队里最好有一个人清楚整条链路是怎么走的，交接时能省下大量时间。

遇到无法解释的访问异常，先确认流量走的哪条链路，再往下查。

把这些检查排进例行清单，比出了问题再回头找要轻松。隐藏源站是长期动作，不是一次配置。

把链路上每个环节的配置都留一份备份，改坏的时候能快速对照出差异。

更换证书、调整回源这类操作尽量安排在访问低谷，给自己留出验证的时间。

如果站点有海外访问的需求，边缘节点的选择会影响实际速度，这一点和防护同样重要。

遇到问题先确认现象的范围：是所有地区都异常，还是只有部分来源，这个信息能迅速缩小排查范围。