源站IP泄露后的应急处理与修复步骤：5步止血顺序

源站IP泄露后的应急处理与修复步骤，先用第0步判定真假泄露，再按“收口→定级→换IP→固定暴露面→验证”五步止血：先确认是不是真泄露，再立即用访问控制收口（比换IP快），然后评估是否降级限流，满足判据才换IP，最后用回源鉴权固定暴露面并验证外部已无法直连。本文只讲事故中的动作顺序、生效快慢与验证信号，不盘点泄漏点——事前自查可参考站内如何防止源站真实IP暴露。

2026年6月，CISA发布BOD 26-04实施指南，要求组织收敛公网暴露面并将防护与访问控制前移至网络边缘，以缩短应急处置窗口。同年8月，Google Cloud Media CDN更新源站架构指南，明确多级缓存与Origin Shield可聚合回源请求、防止惊群效应。这两份官方文档共同支撑一个原则：源站IP泄露后，边缘侧的动作永远比源站侧更快生效。

第0步判定：是源站IP真泄露，还是回源配置把流量引回了源站

先别急着换IP。大量“疑似泄露”其实是回源配置问题——CDN回源时把流量引回了源站，让日志里看起来像被直连。误判的代价是白白中断一次业务。

用四个信号区分：

1. 源站访问日志中的客户端IP是否全部落在CDN回源IP段内？如果是，大概率是回源路径问题，不是泄露。
2. 连接是否带回源标识头（如自定义Header）？缺标识的请求才是外部直连。
3. 目标端口和Host字段是否与CDN配置一致？不一致说明有独立探测。
4. DNS历史解析、证书透明日志里是否出现过源站地址？出现过才算证据确凿的泄露。

如果四个信号都指向“没有外部IP出现”，那问题在回源配置，换个IP只会让业务白断一次。

第1步收口访问控制：只放行回源IP段，比换IP先生效

无论是否真泄露，第一步不是换IP，而是先在源站安全组/防火墙做白名单收口。规则类变更不需要业务重新解析，生效快、回滚也快，先锁定来源能立刻缩窄暴露面。

按这个顺序收口：

1. 先限来源：只放行CDN回源IP段和运维跳板机IP。
2. 再限端口：只保留80/443等业务必需端口，其余全部关闭。
3. 最后处理其他出网服务：邮件、监控、对象存储回调等，逐一收敛。

关键区别在于：在源站防火墙逐条补规则，和让边缘完成连接终止与访问判定，后者更快生效且更隐蔽。CISA在BOD 26-04中强调的“把访问控制前移到边缘”，正是为了缩短这个窗口。配合回源白名单，源站只接受边缘回源IP段的连接，其余来源在源站入口即被拒绝；把连接终止与访问判定前移到边缘后，这类请求还没到源站就已被处理。

第2步定级：区分“还能扛”和“已经打满”，决定是否降级与限流

收口之后，马上评估源站当前承受的压力，决定要不要主动降级。看五个观测项：

必须把四层带宽压制和七层行为清洗分开验收。慢速攻击和低频接口滥用不触发带宽阈值，却能悄悄耗尽连接池和CPU。如果只盯着带宽，可能误判为“还能扛”，实际已濒临打满。若需要明确降级与限流的动作细节，可参考 DDoS应急响应。

第3步换IP：什么情况下才换、换之前必须先做完哪几件事

满足以下任一判据才换IP：

• 收口后仍被直连，说明白名单没能覆盖所有暴露路径；
• 源站地址已出现在公开渠道（如证书透明日志、被动DNS、历史解析记录）；
• 存在无法用白名单解决的暴露面（如第三方回调必须直接访问源站）。

换IP之前，必须先做完四件事：

1. 确认新地址不在任何历史解析记录里，避免换了个“旧IP”。
2. 同步更新CDN回源配置和源站白名单，让新IP立即生效。可参考无感接入高防CDN配置流程。
3. 准备回滚方案：保留旧IP一段时间，出问题能切回。
4. 评估业务中断窗口：换IP涉及DNS解析和连接重建，有些长连接业务会中断。

恢复时长取决于云厂商和业务架构，不同场景差异很大，这里不给统一承诺。但在源站IP泄露后的应急处理与修复步骤里，换IP是最后手段，不是第一动作。

第4步固定暴露面：回源鉴权与分层回源怎么配合

换完IP，必须把暴露面固定在边缘，否则泄露会反复发生。

回源鉴权：源站对不带自定义Header或证书校验的连接直接拒绝。这样即使地址被知道，没有凭据也进不来。

分层回源（Origin Shield）：在边缘汇聚区域回源请求，避免突发流量穿透源站产生惊群效应。Google Cloud Media CDN的架构指南指出，多级缓存能聚合回源流量，同时把回源来源收敛成可白名单化的固定集合。

两者是互补关系：回源鉴权解决“进不来”，分层回源解决“扛得住”。只做鉴权，流量照样能穿透到源站；只做分层，地址被知道后仍可能被直连。配合使用，相当于给源站上了双保险。

第5步验证泄露已切断：直连测试、日志比对与持续观测项

“配置成功”不等于“外部已探测不到”，这是两个独立验收点。

验证清单：

1. 绕过CDN直接请求源站地址，应被拒绝或超时。
2. 源站日志中非回源IP段的请求数应归零。
3. 带缺失鉴权头的请求应被源站拒绝。
4. DNS历史解析、证书透明日志、被动DNS中不再出现源站地址。
5. 保留一段跨越业务高峰的观测期，持续看日志与解析记录，直到非回源IP段请求连续为零且被动DNS无新记录，而不是配置完就收工。

如果第1、2项没过，说明泄露没切断；第3项没过，说明鉴权没生效；第4项没过，说明地址还在公开渠道扩散，需要扩展收敛范围。

换完IP仍被直连的复盘顺序：还有哪些服务在替源站说话

换完IP后仍被直连，别急着怀疑CDN配置，先按顺序排查这些“替源站说话”的出网面：

1. 邮件与告警发信：很多服务器会用源站IP直接发信，IP出现在邮件头里。
2. 独立子域与旧解析记录：历史DNS记录没清干净，或被子域泄露。
3. 回源以外的管理端口：SSH、数据库端口直接暴露在公网。
4. 对象存储与第三方回调：回调URL里可能带源站IP。
5. 监控探针与SDK出网：监控系统主动探测源站，暴露地址。
6. 镜像仓库与容器构建流量：CI/CD过程中源站IP出现在日志里。

每一项都要收敛：邮件走第三方发送服务、子域与旧记录清理、管理端口走堡垒机、回调走边缘函数、探针改走代理。详细的事前排查方法可参考站内如何防止源站真实IP暴露。

边缘承载与源站保护的分工：RockCloud 在这几步的落位方式

在“收口访问控制”和“固定暴露面”两步，RockCloud高防CDN的落位方式很直接：

• 回源IP段白名单：把源站安全组只放行边缘节点回源IP段，外部请求在边缘就被拦下。
• 回源鉴权：给回源请求加自定义Header，源站只认带凭据的请求，地址泄露也进不来。
• 源站保护：所有回源流量先经过边缘清洗，源站只对CDN可见。

这样做的差别在于：源站防火墙逐条补规则，要手工维护、容易漏；边缘做连接终止和访问判定，规则统一、生效快。换IP后，边缘承载业务流量，源站保持隐蔽，这是职责的自然分工。

需要评估回源收口与回源鉴权如何落到现有架构，可联系RockCloud技术支持一起过一遍配置。

可打印的源站IP泄露处置清单

这份源站IP泄露后的应急处理与修复步骤清单可以直接打印，事故中照做。也建议把清单固化为值班SOP，并在下一次演练中验证一次直连拦截与日志归零。

常见问题

源站IP泄露了要不要先停机？

大多数情况不需要先停机。先做访问控制收口，把非回源IP段全部拒绝，业务可以继续跑。只有当攻击已打满源站资源、收口无法生效，或者源站服务本身被攻破时才考虑停机。停机是最后手段，会直接造成业务中断。

回源白名单配了还是被直连怎么排查？

先检查安全组是否真的只放行了白名单IP，很多情况是规则没删干净。再看是不是有旁路绕过，比如其他服务（邮件、监控）直接出网暴露了源站IP。还要确认CDN回源IP段是否准确，有些厂商的IP段会变动。最后看日志，确认直连请求的来源IP和端口，判断是外部扫描还是内部服务泄露。

更换源站IP的正确顺序是什么？

先更新CDN回源配置，再改源站白名单，最后才切换DNS。顺序不能乱：如果先切DNS，旧IP还没被CDN接管，流量会直接打到源站。换完IP后，要等DNS缓存过期，再用直连测试和日志比对验证。整个过程要保留旧IP一段时间，作为回滚方案。

只做回源鉴权不换IP够不够？

不够。回源鉴权能挡住不带凭据的直连，但攻击者如果拿到鉴权头（比如通过日志泄露），照样能进。换IP是切断源头，回源鉴权是加固防线，两者要配合。如果地址已经在公开渠道扩散，必须先换IP再配鉴权。

怎么确认源站IP是不是真的泄露了？

看三个地方：一是CDN源站日志，如果出现非回源IP段的请求，大概率真泄露；二是证书透明日志，搜一下域名是否出现过源站IP；三是被动DNS，用在线工具查历史解析记录。如果都没有，那可能是回源配置问题，别急着换IP。

接入高防CDN后源站IP是否就不可能再被发现？

不是绝对的。高防CDN能大幅增加探测难度，但如果源站还有其他出网路径（邮件、监控、第三方回调），IP照样会暴露。回源白名单和鉴权能限制直接访问，但无法保证100%隐藏。所以还要持续监控解析记录和日志，定期做暴露面检查。