Cloudflare发布了一份详细的事后分析报告，解释了2025年9月12日发生的重大 outage事件，该事件导致其控制台和API中断服务一个多小时。
该公司将这一事件追溯到其控制面板中的一个软件漏洞，该漏洞与一次服务更新结合，在一个关键的内部系统中引发了连锁故障。
这一事件始于Cloudflare仪表板新版本的发布。根据该公司的报告，此次更新的React代码中存在一个漏洞，导致其反复、过度地调用内部租户服务API。该服务是负责处理API请求授权的核心组件。
该漏洞存在于一个useEffect钩子中，该钩子被错误地配置为在每次状态变化时触发API调用，导致在单次仪表板渲染期间出现请求循环。此行为与租户服务API自身更新的部署时间重合。
结果，这个有问题的仪表盘发出的“请求洪流”让新部署的服务不堪重负，导致其出现故障且恢复不当。
由于租户服务需要对API请求进行授权，它的故障导致Cloudflare控制台及其许多API从协调世界时17:57开始出现大面积中断。
事件响应与恢复
Cloudflare的工程团队首先注意到租户服务的负载增加，随后采取措施减轻压力并增加资源以应对。
他们实施了一项临时的全球速率限制规则，并增加了该服务可用的Kubernetes pod数量，以提高吞吐量。虽然这些措施帮助恢复了部分API可用性</b0，但仪表盘仍然处于故障状态。
随后在协调世界时18:58尝试对该服务进行补丁修复，以解决出错的代码路径，但此举反而适得其反，导致API可用性再次受到短暂影响。这一变更很快被撤销，到协调世界时19:12，服务已完全恢复。
值得注意的是，Cloudflare指出，此次中断仅限于其控制平面，该平面负责配置和管理工作。而处理客户流量的数据平面由于严格的隔离未受影响，这意味着终端用户服务仍保持在线状态。
事件发生后，Cloudflare概述了多项措施以防止类似情况再次发生。该公司计划优先将租户服务迁移至Argo Rollouts，这是一款部署工具，若检测到错误会自动回滚版本。
为缓解“惊群”问题，仪表板将进行更新，在其API重试逻辑中加入随机延迟。租户服务本身已分配到显著更多的资源，其容量监控也将得到改进，以提供主动警报。
1. 本版块文章内容及资料部分来源于网络，不代表本站观点，不对其真实性负责，也不构成任何建议。
2. 部分内容由网友自主投稿、编辑整理上传，本站仅提供交流平台，不为该类内容的版权负责。
3. 本版块提供的信息仅作参考，不保证信息的准确性、有效性、及时性和完整性。
4. 若您发现本版块有侵犯您知识产权的内容，请及时与我们联系，我们会尽快修改或删除。
5. 使用者违规、不可抗力（如黑客攻击）或第三方擅自转载引发的争议，联盟不承担责任。
6. 联盟可修订本声明，官网发布即生效，继续使用视为接受新条款。
