为什么 2026 年 10 月 20 日所有 Revolut 卡都被拒付?故障全解析

如果您的 Revolut 卡今天早上在收银台、加油机或取款机被拒,问题既不在卡,也不在您。2026 年 10 月 20 日星期二上午,Revolut 发生了全公司范围的服务故障。英国、法国、西班牙、德国和希腊以及爱尔兰的用户无法完成刷卡支付、转账、ATM 取现,甚至无法登录应用。Revolut 确认发生了影响多项服务的服务中断,并表示所有客户的资金和数据都是安全的。最可能的诱因是 Google Cloud 伦敦区域的故障,该故障始于 06:08 UTC,即巴黎时间 08:08,Google 此后已将其归因于一次电力事件。一位知情人士向路透社透露,Revolut 的故障与 Google Cloud 的中断有关。两家公司均未公开确认这一关联。

实时报道只告诉您 Revolut 宕机了,却没有说明故障出在支付链的哪个环节,没有解释为什么无人值守的加油机每次都拒绝您的卡而收银台有时能刷过,也没有说明伦敦的一个云区域怎么会让法国加油站里的一张卡失灵。本文将回答这些问题,厘清此次故障与近期俄罗斯数据中心遇袭事件以及一个新披露的 Linux 虚拟机漏洞之间的区别,并列出您应该随身准备什么,让单一发卡机构的故障再也不会把您困住。

为什么我的 Revolut 卡在 10 月 20 日被拒付?

因为负责批准每一笔该卡支付的公司 Revolut,在数小时内无法应答。据 Clubic 报道,从巴黎时间 08:00 左右起,应用显示错误信息,银行卡在商店和出租车上被拒,转账也无法完成。仅在法国,Revolut 就拥有超过 800 万客户。法国科技媒体报道了收银台和 ATM 上的拒付情况。

Revolut 自己的状态页面反应迟缓。巴黎时间 09:42,该页面仍显示所有系统正常运行;随后才列出 31 项服务部分不可用,包括刷卡支付、转账、ATM 取现、高级服务和登录。以下是当天上午的事件经过。

截至 10 月 20 日巴黎时间 13:25,Google 将故障归因于 europe-west2-b 可用区的一次电力事件,表示电力事件已得到缓解,服务正在逐步恢复,但其事故仍未关闭,完整的事故报告尚未发布。Revolut 未发布恢复通知,也未说明故障原因。待 Revolut 或 Google 发布事后分析报告后,我们将更新本文。

问题出在 Revolut、Visa 还是商家?

每一笔银行卡支付都涉及三方。商家的终端及其银行(收单机构)读取银行卡并发送授权请求。卡组织网络,即 Visa、Mastercard 或法国的 CB,负责转发该请求。发卡机构,也就是您银行卡背后的银行,实时给出批准或拒绝的答复。10 月 20 日当天,我们未发现 Visa、Mastercard 或 CB 报告任何事故,也没有其他发卡机构报告银行卡问题,所有证据都表明故障出在作为发卡机构的 Revolut 一方。

所谓发卡机构故障,是指您银行卡背后的银行无法应答支付网络的授权请求,因此所有终端会同时拒绝这张卡,无论在哪家商店、哪个国家。这就是为什么从外部看这种现象如此怪异:您的卡在所有地方同时失灵,而您身旁的人却付款顺畅。

这也解释了为什么无人值守加油机每次都拒绝,而收银台有时还能刷过。法国的 24 小时自动加油机会在您拿起油枪之前,请求发卡机构批准一笔固定的最高金额,通常为 100 到 150 欧元,由加油站设定,事后再替换为实际金额。这笔预授权需要发卡机构的实时应答,所以当发卡机构没有回应时,加油机每次都会说不。加油机只是让发卡机构的故障显形,并不是故障的源头。对于那些确实成功的支付,一种可能的解释是:部分终端可以离线批准小额交易并在事后结算,这或许就是 Clubic 报道中一些 Revolut 客户仍能在部分商店付款而大多数银行卡被拒的原因。

Google Cloud 和我的银行卡有什么关系?

许多银行和金融科技公司把大部分软件运行在租用的云基础设施上,一旦这些基础设施出故障,它们的服务也可能随之瘫痪。Google 表示问题始于 06:08 UTC;其首次状态更新发布于巴黎时间 10:35,约两个半小时之后,报告其伦敦区域 europe-west2 出现错误率升高和间歇性网络故障。对持卡人来说,这段空白至关重要。在约两个半小时里,Google 的状态页面一言不发,而巴黎时间 09:42,Revolut 的状态页面仍显示所有系统正常运行。The Register 指出,europe-west2-b 是该区域三个可用区之一。Google 的事故页面列出 38 项受影响产品,包括 Kubernetes Engine、Cloud Run 和 BigQuery Data Transfer Service,Google 还向所有受影响者发布了致歉声明。巴黎时间 13:12,Google 给出了初步原因,其更新写道:“由于一次电力事件,我们在 europe-west2-b 可用区内发生了故障。电力事件已得到缓解”,服务正在逐步恢复。Google 的声明仅涉及其自身的可用区,并未提及 Revolut。Google 在欧洲的其他区域,包括巴黎和法兰克福,未报告任何问题。

与 Revolut 的关联仍属于有消息来源的说法,而非已证实的事实。一位知情人士向路透社透露,Revolut 的故障与 Google Cloud 的中断有关,而 Revolut 自己的声明并未提及 Google。The Journal 报道称,据了解此次中断源于某第三方服务商的故障,但未指明是哪一家。同一上午,Downdetector 英国站显示 Lloyds、Halifax、Bank of Scotland、HSBC、NatWest、Santander UK 和 MBNA 的报告激增,此外还有 Royal Mail、Rightmove 和 GOV.UK,而 ING 德国的客户也遇到了无法登录网上银行和应用的问题。目前没有人正式将这些报告与 Google Cloud 挂钩,而且 Downdetector 的激增可能产生误导,因为担心的用户会去检查实际运行正常的服务。

无论最终的事后分析得出什么结论,这类事件的形态并不陌生。今年 9 月,当 ChatGPT、Claude 和 Grok 同时瘫痪时,共享云是头号嫌疑,结果却证明并非原因;这一次,单个云区域是目前最主要的解释,尽管仍未得到证实。当许多公司租用同一栋大楼时,这栋楼里的一个故障可能瞬间变成所有人的故障,而这一次,出问题的服务正是您口袋里的那张卡。

这是网络攻击吗?是否与俄罗斯数据中心遇袭有关?

就现有证据而言,不是。自 2026 年 10 月 8 日起,乌克兰无人机袭击了 Yandex 位于萨索沃、卡卢加和弗拉基米尔的数据中心,扰乱了 Yandex 在俄罗斯及邻国的服务;我们在这篇文章中详细报道了那些袭击。关于袭击的报道没有提及对欧洲银行、银行卡支付或西方云服务商的任何影响。Revolut 不在俄罗斯运营。Revolut 的故障恰逢 Google 伦敦设施出现问题,没有任何消息来源将这两件事联系起来。它们只在一点上形成呼应:两者都表明关键服务集中在为数不多的物理建筑里。但一个是针对基础设施的军事打击,另一个是普通的云故障,把两者混为一谈对谁都没有好处。

同样,没有任何迹象指向黑客入侵。没有消息来源报告系统入侵,Revolut 表示客户的资金和数据都是安全的,今晨同样受影响的预算管理应用 Emma 称其自身的问题是技术故障而非安全漏洞。在事后分析报告出炉之前,无法正式排除网络攻击,但今天可见的一切都指向云端事故而非攻击,而且 Google 自己现在也将其伦敦故障归因于 europe-west2-b 可用区的一次电力事件,其完整的事故报告尚待发布。

是 PwnEscape Linux 漏洞造成的吗?还是连串云故障的一部分?

第二个问题值得同样严谨的对待。会不会是一个新披露的 Linux 漏洞在作怪?2026 年 10 月 15 日,也就是故障发生前五天,Linux 内核的 CVE 团队发布了 CVE-2026-99999,绰号 PwnEscape,这是内核网络代码中的一个严重漏洞,位于其 IPv4 校验和处理部分,按 CVSS 3.1 标准评为 9.3 分(满分 10 分)。评分之所以这么高,是因为这个漏洞能做的事。恶意的客户虚拟机可以发送特制网络数据包,破坏其所在宿主机的内核,研究人员在自己的实验室中演示了宿主机内存泄露、宿主机崩溃以及在宿主机上以 root 身份执行代码。该漏洞位于处理客户机流量的 Linux 网络栈中,而非某个特定的虚拟机管理程序。

漏洞的发现过程本身是有序的。研究团队 PWN.AI 在 Vercel 的沙箱安全挑战赛中发现了这个漏洞,于 9 月 4 日私下报告给内核维护者,修复补丁于 10 月 14 日并入 Linux 主线内核。更关键的是,目前没有任何在野利用的报告。CISA 于 10 月 16 日的评估(记录在该 CVE 条目中)写明“Exploitation: none”(利用情况:无),该漏洞也不在 CISA 的已知被利用漏洞目录中。Google 未就此发布任何安全公告,其截至 10 月 19 日的公告中也没有提及它。Google 将伦敦故障归因于 europe-west2-b 可用区的一次电力事件,Revolut 的声明既未提及 Google 也未提及任何漏洞,Emma 则称自身问题是技术故障而非安全漏洞。没有任何可信消息来源把 PwnEscape 与此次故障联系起来。

不过,大背景确实存在。今年秋天出现了一连串大型云事故。9 月 1 日,例行路由器维护期间断开的网络光缆,使 Google Cloud 位于爱荷华州的 us-central1 区域中两个可用区的部分设施隔离了约四小时,从美国太平洋时间 07:41 到 11:52,影响 16 项产品。9 月 30 日至 10 月 1 日,Microsoft Azure 的网关服务,包括 ExpressRoute、VPN Gateway、Azure Firewall、Application Gateway 和 Azure VMware Solution,自 20:30 UTC 起在 18 个区域受到干扰,微软称其与基础设施操作系统维护活动存在关联。10 月 8 日和 9 日,一次负载均衡配置更新使 us-central1 的 Google Cloud Storage 节点过载,两天内累计造成约 18 小时的写入错误。

从这些报告可以得出公允的结论。这一连串事故是真实的,也表明有多少东西依赖于屈指可数的几家服务商,但报告中指出的原因是维护作业、配置变更和容量问题,没有一份报告提及攻击或漏洞。伦敦这次故障如今也符合这一模式:Google 将其归因于一次电力事件,同样是一个与攻击无关的原因,不过其完整的事故报告仍待发布。

为什么故障之后总会出现钓鱼信息?

因为故障给了骗子一个现成的剧本。成千上万的人刚刚遭遇拒付,正在担心,正在等待银行的消息。一条声称您的卡已被停用、附带验证信息链接的假短信,在今天这样的日子远比平常的星期二更有说服力。未来几天,请做好迎接一波此类信息的准备,渠道包括短信、电子邮件和电话。

对于 Revolut 用户,尤其有理由认真对待这件事。2026 年 9 月,一名冒充意大利政府监管机构的攻击者,通过一个合法的政府域名发送电子邮件,获取了约 650 名客户的数据,包括身份证件、照片、账户对账单和交易记录。Revolut 称其为一场精心策划的外部冒充骗局,表示其系统和客户资金未受影响,并已联系受影响的客户。那次泄露与 10 月 20 日的故障无关,但它意味着部分客户的真实信息已在外流传,这会让钓鱼信息显得格外真实、格外有针对性。

真正的银行客服绝不需要您的 PIN 码、密码、一次性验证码或银行卡信息,也绝不会因为电话是他们打来的就要求您在应用中批准操作;如有疑问,请挂断电话,通过银行的应用与银行联系。不要点击与故障有关的信息中的链接;请直接打开应用查看官方通知。作为一道后备防线,Le VPN 的 Threat Protection 可以在已知钓鱼和恶意软件域名加载之前将其拦截。它无法阻止短信送达,也无法捕捉每一个刚刚注册的诈骗域名,所以您自己的警惕性仍是第一道防线。

下次如何避免被困?

您无法阻止下一次 Revolut 故障,但您可以让它对自己毫无影响。

• 携带另一家发卡机构的第二张卡。第二张 Revolut 卡会和第一张一起失灵。对于居住在法国的人来说,一张走 CB 网络的法国银行卡是很好的补充,因为批准它的是另一家发卡机构。
• 备一些现金。够加油和吃饭即可。此次 Revolut 的 ATM 取现同样瘫痪,所以取现金要趁故障之前,而不是故障期间。
• 在加油站,发卡机构故障期间不妨试试有人值守的柜台,而不是自动加油机,尽管柜台也可能拒付。
• 先查看状态页面和应用内通知。在认定您的卡被封锁或被盗用之前,先看看发卡机构是否正在通报事故。Revolut 还列出了常见的拒付原因,例如卡被冻结、消费限额、待确认的 3-D Secure 验证或被关闭的支付类型,具体原因会显示在应用中。
• 不要在慌乱中冻结、注销或重置银行卡。在发卡机构故障期间,这样做改变不了任何事情,而注销的卡意味着服务恢复后还得等待补发。
• 绝不向任何主动联系您、自称 Revolut 客服的人提供信息,今天尤其如此。
• 保留带时间戳的截图,记录造成损失的拒付交易和失败转账,待服务恢复后通过应用向 Revolut 客服提出。

有一样东西帮不上忙,那就是 VPN,这话出自一家 VPN 服务商之口。银行卡授权发生在终端、卡组织网络和发卡机构之间;您自己的连接,无论是否使用法国 VPN 服务器,都与支付是否获批无关。VPN 保护的是您的网络流量,并通过 Threat Protection 过滤掉许多在这种日子之后涌现的诈骗域名。它无法让一家银行保持运转。

Google 已给出初步原因,即其 europe-west2-b 可用区的一次电力事件,但完整的事故报告尚未发布。等报告发布时,有三件事值得关注:一是这次电力事件究竟使哪些设施失效,二是 Revolut 是否会亲口确认与 Google Cloud 的关联,三是为什么在欧洲各地收银台已经开始拒付的时候,它的状态页面还显示所有系统正常运行。