2025年10月20日，亚马逊AWS（云计算服务）发生了大规模宕机事故，影响范围遍及全球。此次故障波及多个知名平台及应用，暴露了全球互联网服务对云基础设施的高度依赖，并引发了对云服务容灾能力与高可用性设计的广泛讨论。
事件发生在美东时间2025年10月20日，AWS的US-East-1区域（弗吉尼亚州）因DNS解析故障导致多个核心服务中断，包括DynamoDB、EC2、CloudFront等关键服务。
此故障导致亚马逊平台的卖家中心功能瘫痪，用户无法创建货件、编辑A+页面或访问结算中心等，且移动端APP频繁出现白屏或订单加载失败。此外，多个知名第三方平台，包括Snapchat、Robinhood、Coinbase、Venmo等，也出现了无法访问的情况，部分银行APP、游戏平台（如Fortnite）和智能设备（如Alexa）也受到波及，服务中断影响了数百万用户。
AWS官方发布声明，表示故障源自配置更新引发的DNS解析异常。由于AWS平台在US-East-1区域的DNS系统出现问题，导致多个数据库和服务无法正常访问。AWS已启动修复，并逐步恢复服务，但具体恢复时间尚未明确。
根据实时监测网站Downdetector的数据显示，故障发生后，故障报告数量急剧上升，最高达50,000份，其中亚马逊主站的报告占据了其中的15,000份。全球范围内，包括美国、英国、荷兰、澳大利亚等多国用户均受到影响。企业和消费者纷纷面临无法访问平台、丢失数据或无法进行交易的困境。
亚马逊的 AWS 刚“崩”完没多久，微软的 Azure 也崩了......
日前，大量用户在 X（原 Twitter）、Hacker News、Reddit 等社交平台上报告称，微软 Azure 出现大规模故障，连 Azure 官网、microsoft.com 都一度无法访问。
根据故障追踪网站 Downdetector 的统计，仅数小时内，全球多个地区的报告就累计上千起报告，显示这次中断影响范围之广，堪称一次全球性事件。
微软确认，Azure 自 2025 年 10 月 29 日（周三）UTC 时间 16:00（太平洋时间 09:00）起出现大范围中断，预计要到当日 UTC 时间 23:20（太平洋时间 16:20）才能完全恢复。
尴尬的是，这次宕机恰逢微软发布 2026 财年第一季度财报之际（微软的财年并不与日历年同步，其 2026 财年从 2025 年 7 月 1 日开始到 2026 年 6 月 30 日结束）。财报显示，Azure 及其他云服务的收入较去年同期增长了 40%，成为微软在季度财报中披露的增速最快的业务板块。
而此时 Azure 的全球性宕机事件的发生，似乎有些“打脸”。
据微软自己公布的影响范围显示，微软自家的核心业务是“重灾区”，包括 Office 365、Minecraft、Xbox Live 和 Copilot 在内的多项服务均出现不同程度的中断。
微软随后在声明中列出了受影响的 Azure 服务清单，范围之广令人咋舌：
“受影响的服务包括但不限于：App Service、Azure Active Directory B2C、Azure Communication Services、Azure Databricks、Azure Healthcare APIs、Azure Maps、Azure Portal、Azure SQL Database、Container Registry、Media Services、Microsoft Defender External Attack Surface Management、Microsoft Entra ID、Microsoft Purview、Microsoft Sentinel、Video Indexer、Virtual Desktop 等。”
这些项服务几乎涵盖了微软云生态的大半边天。
不仅如此，依赖 Azure 的企业服务也遭殃。
其中，阿拉斯加航空（Alaska Airlines）在其网上上发表声明称，由于微软 Azure 平台发生全球性宕机，托管在其上的阿拉斯加航空和夏威夷航空多项服务中断。航空公司提醒乘客：“无法在线值机的旅客请前往机场柜台领取登机牌，并在候机大厅预留更多时间。”
开源社区同样受波及。当打开 Kubernetes 管理工具 Helm 的官网（get.helm.sh）时，其页面一度返回 “ResourceNotFound” 错误，显示资源无法访问。截至发稿，仍未恢复。
加拿大魁北克的医疗机构 Santé Québec 也报告部分病患访问系统暂停运行——“由于微软 Azure 全球服务中断，一线接入点和虚拟护理平台目前无法使用。”
此外，DownDetector 显示星巴克、克罗格、Costco 等网站都出现了服务中断高峰。
原因揭秘：Azure 的一次意外配置变更
随后，微软发布了初步调查报告，称这次事故的核心在于 Azure Front Door（微软的内容分发网络服务）。
微软表示，在 Azure Front Door（AFD）中，一次意外的租户配置更改引发了广泛的服务中断，影响了依赖 AFD 进行全球内容分发的微软自家服务和客户应用。
这次更改引入了一个无效或不一致的配置状态，导致大量 AFD 节点无法正常加载，从而引发下游服务的延迟增加、超时和连接错误。
随着这些异常节点陆续从全球节点池中掉线，健康节点之间的流量分配出现了严重失衡，放大了故障影响，甚至让部分“健康”区域也出现了间歇性可用的问题。
谈到故障影响范围，外媒 Tom’s Hardware 整理了微软确认的受影响服务和地区，最后甚至调侃道：“微软下次或许可以直接说‘无处不在’就行了！”
而后，微软紧急阻止所有新的配置更改，以防止错误状态继续传播，并开始在全球范围内部署“最后一次已知正常”的配置版本。
恢复过程采取了分阶段、渐进式策略，以确保系统稳定，并防止再次宕机。
最终，问题被追溯到租户配置部署流程中的缺陷：原本用于验证并阻止错误部署的防护机制因软件缺陷失效，导致异常配置绕过安全校验。
微软表示，目前已审查相关防护措施，并紧急增加了新的验证与回滚机制，以防止类似问题在未来重演。
然而，更有戏剧性的宕机事故再次发生……一场席卷全球的网络大面积故障，悄然让半个互联网再次陷入了罕见的混乱：
X（原 Twitter）打不开、ChatGPT 无法响应、连监控宕机的 Downdetector 自己都挂了……而这场风暴的中心，正是那个几乎包裹了全球五分之一互联网的基础设施服务商：Cloudflare。
一觉醒来，互联网“碎了一地”：从社交媒体到游戏服务器全面崩溃
根据媒体报道，Cloudflare 故障在美东时间11月18日早上 6:20（北京时间 19:20）左右开始，最先爆出来的是大量应用访问延迟、白屏、无法登录等问题。
受影响的名单长到令人咋舌——不仅有 X、ChatGPT，这场崩溃还几乎跨越了社交网络、生产力工具、流媒体、在线游戏、交通服务等所有类别：
● X：报错信息显示“内部服务器错误源于 Cloudflare 的异常”；
● ChatGPT：弹出提示“请解除对 cloudflare.com challenge 的拦截后继续访问”；
● Canva（在线设计工具）、Indeed（招聘平台）、Uber（打车软件）、Spotify（音乐播放平台）均出现访问异常；
● 《英雄联盟》服务器出现连接问题；
● Archive of Our Own（AO3）短暂无法访问；
● 大量媒体网站也全部挂掉，包括但不限于Axios、The Information和Politico。
甚至，连人们用来确认网站是否挂掉的 Downdetector 本身都无法正常加载——这无疑是本次事件最为戏剧性的一幕。
数不清的用户在社交媒体上不断发出抱怨，有人甚至调侃：“这已经不只是网站挂了，是我的一天也跟着宕机了。”
Cloudflare 作为目前全球最大的互联网安全与 CDN（内容分发网络）提供商之一，它负责的事情主要包括：
● WAF、防火墙、DDoS 防护
● 验证访问者是否为人类（Bot Mitigation）
● CDN 加速
● 边缘网络与 Zero Trust 服务
● 网站流量代理与高级缓存
Cloudflare 官方称，全球 20% 的网站都在使用它的服务。换句话说：互联网的很大一部分流量，都要经过 Cloudflare 的基础设施，而它一旦出问题，成千上万个网站就会同时“受牵连”。
正因如此，网络服务监测机构 NetBlocks 负责人 Alp Toker 才会说这次事故表示 Cloudflare 基础设施遭遇了“灾难级的中断”：“令人震惊的是，这几年为了躲避 DDoS 攻击，互联网越来越多的服务都把 Cloudflare 作为前置层，这同时也让它成为了整个互联网的最大单点故障之一。”
故障爆发后，Cloudflare 很快进行了技术调查。
Cloudflare 官方发言人 Jackie Dutton 表示，这次宕机源于一个用于管理威胁流量的自动生成配置文件：“该文件的体积超出了预期，引发了处理流量的软件系统崩溃，从而影响了 Cloudflare 多项核心服务。”
听起来是“小问题”？但在 Cloudflare 这种体量下，小问题可以瞬间变成“超级多米诺骨牌”。
在后续的技术复盘中，Cloudflare 解释这个“体积变大的文件”源于一次数据库权限变更：在一次 ClickHouse 权限的变更中，团队原本希望“让所有用户都能准确看到自己有权访问的数据表元数据”。而这个本该是常规的权限完善，却引发了一场蝴蝶效应。
据了解，Cloudflare 的“机器人管理（Bot Management）”系统，需要依赖一份不断更新的“特征配置文件”。这份特征文件每几分钟更新一次，并自动同步至整个网络，使其能够应对互联网流量的变化。但问题来了：由于底层 ClickHouse 查询行为的权限变更，导致生成的文件中出现了大量重复的“特征”行。
“该特征文件的大小随后翻倍，而这超出预期的特征文件被传播至构成我们网络的所有机器。这些设备上运行的网络流量路由软件会读取这份特征文件，确保机器人管理系统能及时应对不断变化的威胁。但该软件对特征文件的大小设有限制，而此次文件大小翻倍后超出了这一限制，最终导致了软件故障。”
于是灾难链条启动：“过大的配置文件”→Cloudflare 处理威胁流量的模块开始崩溃→相关服务陆续降级→故障波及整个网络层→大量依赖 Cloudflare 的网站出现连锁访问异常。
事后，Cloudflare CTO Dane Knecht 在 X 上公开道歉，并承认此次事件是他们的问题：
“我不会拐弯抹角：我知道，我们辜负了客户和整个互联网的信任。一个隐藏的 Bug 在我们进行一次例行配置变更后被触发，引发崩溃，最终导致我们的大量网络与服务大面积降级。这不是攻击，是我们的失误。”
Dane Knecht 还强调，这是一次“不可接受的事故”。
故障持续三个多小时后，Cloudflare 于美东时间上午 9:42在状态页发布更新：“修复已实施，我们认为事件已经得到解决。但我们仍在持续监控，确保所有服务完全恢复正常。”
虽然服务陆续恢复，但全球部分地区依然出现访问波动，一些企业的 API 业务也在恢复期遇到零星错误，这在大型服务“重启”过程中并不少见。值得注意的是，受影响的还包括部分企业的内部服务与自动化流程，因此要真正恢复正常可能还需要花费一点时间。
然后，Cloudflare 于 12 月 5 日又又又突发网络故障，导致部分服务在全球范围内出现约 25 分钟中断。
该起事故从 08:47 UTC 开始，至 09:12 完全恢复，约 28% 的 HTTP 流量受到影响。
此次故障并非由网络攻击或恶意活动引发，而是在应对 React Server Components 相关的行业级安全漏洞时，内部对请求体解析逻辑进行调整，引发连锁错误。
Cloudflare 也回顾了 11 月 18 日发生的类似事故。公司表示，两次故障均由全网快速传播的配置更改触发，这暴露出部署机制在安全更新场景下的脆弱性。Cloudflare 强调，目前正在推进多项系统性工程，包括增强发布机制、完善故障旁路流程、在关键数据平面启用更安全的“Fail-Open”模式等，但这些改进尚未完全落地。官方计划在下周公布更详尽的韧性建设方案。
一个多月来，云平台服务商技术事故引发的三次互联网大规模瘫痪，引发了企业对信息技术自主控制权的思考
云计算带来了便利，但也让全球互联网更脆弱。AWS 、Azure和Cloudflare的接连“罢工”，提醒我们：当少数几家巨头掌控了互联网的大部分神经时，一次配置错误、一次网络异常，就可能引发全球性连锁反应。企业在享受云服务带来的弹性与便捷时，是否也该考虑冗余、多云部署，甚至更多自主控制权？
随着云服务的普及，容灾能力和高可用性架构已经成为保障企业数据安全和持续运营的基础。在全球互联网生态中，任何平台的宕机都可能对数百万用户产生巨大影响，企业必须充分认识到这一点，并为可能的故障做好充分准备。
未来的技术架构必须更加关注灾难恢复与业务连续性管理。企业应当借此机会重新审视自身的云服务策略，确保在面临突发故障时，能够快速恢复并减少损失。
云服务容灾与高可用性：企业应对突发事件的关键
企业若希望避免因单一云平台出现故障而导致的重大影响，必须采取一系列应对措施：
1.多区域部署与容灾设计：通过在不同地理位置的云数据中心部署业务系统，确保即便某一地区发生故障，其他区域的服务能够自动接管，最大限度减少服务中断。
2.高可用性架构：采用负载均衡、自动扩展和冗余系统等技术，确保在突发流量或服务故障时，能够自动切换到备用系统，确保业务系统持续运行。
3.定期备份与数据同步：关键数据应定期进行备份，并通过实时同步技术确保备份数据与生产数据的一致性，以便在出现故障时能够迅速恢复。
4.灾难恢复预案：建立并定期演练应急预案，确保在发生系统故障时能够迅速响应，并采取适当的措施恢复业务。
