源站地址一露，防护就等于没接

接过一次应急处置，防护日志干干净净，主机上却明显有被扫过的痕迹。查下来原因是：站点接了边缘加速，回源地址写的是源站公网地址，而这台机器本身也对公网开着网站端口，攻击者先用历史解析记录找到旧的地址，再直接对它发起请求，绕过了整条边缘链路。防护配置得再细，请求压根没经过它，自然什么都拦不到。所以用边缘加速隐藏源站，关键不在加速本身，而在于让源站只接受来自边缘的流量。

边缘加速是怎么挡住真实地址的

用户请求先解析到边缘节点，由节点终止连接、缓存静态资源、过滤明显的恶意请求，遇到动态内容时再由节点回源取数据。整个过程中，浏览器始终只看到边缘地址，源站地址不出现在任何返回给用户的响应里。

听起来简单，实际漏点很多。解析历史会被第三方数据库存下来，换过地址也查得到；给域名签证书时如果有子域名直连源站，证书透明度日志会把记录公开；邮件头、论坛发帖、代码仓库里的截图都可能带着真实地址；同网段的其他主机被扫到，反查一下也能猜出邻居。所以换地址只是开头一步，把出口收干净才算做完。

回源这一步最容易出问题

正经的做法是让源站只信任来自边缘节点的请求。可以给回源单独配一个域名，在源站按这个域名做虚拟主机，默认站点直接拒绝；再在防火墙或安全组里只放行边缘节点的回源地址段，其余全部丢弃。这样即便地址被猜到，直接访问也会被挡在门外。

还有几个细节：源站不要开放管理之外的多余端口，后台不要挂在公网上；证书申请用 DNS 验证而不是文件验证，避免在源站留下可探测的文件；测试环境和临时域名同样要接进来，它们往往是最先被翻出来的入口。回源链路上如果有多个层级，每一层都要做同样的限制，别让某一跳成为缺口。

怎么自查有没有露

验证方法很直接：在不同的公共解析服务上解析主域名和常用子域名，看返回的是边缘地址还是源站地址；用在线工具查历史解析记录；扫一遍自己的公网地址段，看有哪些机器对外开放了网站端口。如果发现主域名解析正常，但某个子域名直指源站，那就是漏洞。查漏的动作要定期做，新上线一个子域名就可能把之前的努力作废。

自查之外，平时也要留意解析记录的变更。上线新服务、调整测试环境时，很容易顺手加一条直连源站的记录，当时的用意只是方便调试，事后却没人清理。把解析记录纳入变更流程，新增和删除都留个记录，能避免这类临时配置长期留在线上。

接受它的代价

隐藏源站不是免费的。边缘回源要处理真实来源识别，应用拿到的客户端地址会变成节点地址，需要在请求头里取真实地址并做校验，否则限流和风控会失效；静态资源可以大胆缓存，动态接口不能随便缓存；节点异常时回源压力会集中爆发，源站要有基本的承载余量。

另一个代价是排障变复杂了。用户反馈访问异常时，需要同时看边缘日志和源站日志，才能判断是节点问题还是应用本身的问题；如果两边的时间没有对齐，或者请求标识没有贯通，排查会拖很久。接入之前在回源请求里带上一个唯一标识，让边缘与源站的时间保持同步，遇到问题时就能顺着这个标识把两段日志拼起来看。缓存的刷新策略也要提前想好，内容更新之后如果没能及时失效，用户看到的是旧页面，这类反馈很容易被误判成故障。

把这些提前想清楚，比事后被绕过再补要省事得多。真出事时，判断有没有被绕过的方法也很朴素：把源站日志和边缘日志对一下，如果源站出现了边缘日志里没有的请求，那说明有人绕开了边缘，直接打到了源站。