上游丢包 - 部分路径(in-maa/in-bom-2 至美国区域)
我们的团队正在调查从 in-maa 和 in-bom-2 数据中心到美国区域的某些路径上的数据包丢失问题。在此期间,用户可能会遇到印度与美国区域之间传输的服务出现连接超时和错误。一旦我们获得更多信息,将分享更多更新。
- 处理进展
- 2 条公开更新
Linode(Akamai Cloud)
我们的团队正在调查从 in-maa 和 in-bom-2 数据中心到美国区域的某些路径上的数据包丢失问题。在此期间,用户可能会遇到印度与美国区域之间传输的服务出现连接超时和错误。一旦我们获得更多信息,将分享更多更新。
我们的团队正在调查一个影响多个数据中心区域的 Block Storage 服务的问题。该问题主要影响 Block Storage 卷的挂载和卸载。在此期间,用户在使用此服务时可能会遇到卷挂载/卸载卡住、超时和错误。当我们获得更多信息时,将分享进一步的更新。
原因:在 27 July 2026 at 3:30 UTC,Akamai 观察到连接 Linode 托管数据库时错误增多,主要影响 Block Storage 卷挂载。这导致了主机作业失败,对客户影响有限,部分用户遇到了错误消息和工作流中断。 日志中注意到某些数据中心位置出现较高超时率,这与新 feature flag 的增量发布相吻合。 初步调查显示,在 TLS 握手期间,数据库代理到客户端主机之间存在间歇性数据包丢失。当前的理论认为,可能达到了与路径 MTU 数据包过大 ICMP 消息相关的 DDoS 防护限制。 当代理以较大的 MTU 发送 TCP 数据包时,预期的 ICMP 消息因超过配置的允许速率而被 Dallas 网关路由器…
修复:修复已实施,我们正在监控结果。
我们的团队目前正在调查一个影响意大利(米兰)区域 Linodes 的连接问题。在此期间,该位置的现有 Linodes 可能无法访问。请注意,创建新的 Linodes 功能正常,且不受影响。
原因:大约从 2026 年 7 月 20 日 00:33 UTC 开始,意大利米兰数据中心中的一些主机变得不可用,影响了客户对 Linodes 的访问。调查发现,此问题发生在计划中的路由器固件更新期间。 虽然我们遵循分阶段升级流程以防止服务中断,但并发维护活动的意外交叉导致受影响主机暂时失去网络连接。服务已于 2026 年 7 月 20 日 02:16 UTC 完全恢复,所有系统目前均正常运行。 在内部,我们正在审查变更管理和维护调度流程,以确保更好的协调,并防止将来再出现类似问题。我们对造成的影响深表歉意,感谢您的耐心和持续支持。我们致力于持续改进,使我们的系统更加完善,并防止问题再次发生。 本摘要基于现有信息概述了我们目前对事件的了解…
修复:目前,我们已经能够修复影响我们米兰(意大利)数据中心连接的问题。我们将对此进行监控,以确保其保持稳定。如果您仍然遇到问题,请<a href="https://cloud.linode.com/support/tickets">提交支持工单</a>以获取帮助。
我们的团队正在调查一个影响 Object Storage 服务的问题。在此期间,用户可能会遇到此服务的连接超时和错误。
原因:2026 年 7 月 18 日,大约在 00:30 UTC 至 04:00 UTC 之间,用户尝试在以下端点的 Object Storage 中创建新存储桶时,可能会遇到 5xx 错误。 * [us-ord-1.linodeobjects.com](http://us-ord-1.linodeobjects.com) * [us-lax-1.linodeobjects.com](http://us-lax-1.linodeobjects.com) * [us-iad-1.linodeobjects.com](http://us-iad-1.linodeobjects.com) * [us-sea-1.linodeobjects.c…
我们的团队调查了一个影响我们位于US-MIA(Miami)数据中心连接性的问题,时间为2026年7月15日21:20 UTC至约23:28 UTC。在此期间,部署在该区域的Compute服务的用户可能遇到了网络性能下降和数据包丢失的情况。 该问题在我们实施修复后已解决。 我们继续与第三方服务提供商合作,以确认根本原因,因为初步证据表明其基础设施上存在园区交叉连接(暗光纤)中断。
我们的团队正在调查一个新出现的服务问题,影响 API 和 CLI。我们将随着更多信息的获得分享额外更新。
原因:2026 年 7 月 14 日 10:57 UTC,Akamai 发现影响使用 Linode API、CLI 和 Cloud Manager 的客户的 502 错误和延迟增加。此中断造成了中等程度的影响,客户报告错误率上升。我们的初步调查将问题追溯到 IAM 服务的延迟,该问题已解决,但错误率仍然偏高。 相关主题专家的进一步分析确定,该事件是由手动从辅助负载均衡器故障恢复到 Cloud IAM 主负载均衡器触发的。此操作是由于警告警报提示辅助负载均衡器正在充当 keepalived 主节点而采取的。手动启动和停止服务以启动故障恢复的过程与自动化过程不同,导致了一系列过时的 GRPC 连接,从而增加了延迟和 API 错误。重启 AP…
修复:目前,我们已经能够修复影响 Cloud Manager 和 API 的问题。我们将持续监控以确保服务保持稳定。如果您仍然遇到问题且无法<a href="https://cloud.linode.com/support/tickets">提交支持工单</a>,请致电 855-454-6633(国际:+1-609-380-7100),或发送电子邮件至 support@linode.com。
我们的团队已识别出一个正在出现的服务问题,影响所有区域中部分主机的宿主作业。Linode 连接*不受影响*,但某些主机级作业(例如备份或尝试开启或关闭您的服务)可能会延迟。当我们获得更多信息时,将分享进一步的更新。
我们的团队正在调查一个影响 Cloud Manager 登录的新出现的服务问题。在获得更多信息后,我们将分享更多更新。
原因:2026年7月9日15:43 UTC,客户无法使用用户名和密码登录 [cloud.linode.com](http://cloud.linode.com)。客户收到“密码错误”错误消息。 调查发现,该问题是由于内部证书问题造成的。 为减轻影响,我们在2026年7月9日17:24 UTC修复了受影响服务器上的证书问题。在监控系统一段时间后,我们确认该问题已完全解决。 Akamai 将部署永久修复程序,以防止问题再次发生。
修复:目前我们已经能够纠正影响 Cloud Manager 登录的问题。我们将对此进行监控,以确保服务保持稳定。如果您仍然遇到问题且无法 <a href="https://cloud.linode.com/support/tickets">打开支持工单</a>,请致电 855-454-6633(+1-609-380-7100 国际),或发送电子邮件至 support@linode.com。
我们的团队正在调查一个新出现的服务问题,该问题影响所有区域的 Managed Databases。客户在配置新数据库或删除现有数据库时可能会遇到延迟。目前未观察到对正在运行的活动数据库的性能或可用性造成影响。我们将在获得更多信息后提供更新。
我们的团队正在调查一个服务问题,该问题导致Network Helper自动配置Linode网络失败。在那段时间,一些用户可能已配置Linode,但看起来没有连接性。这也可能影响由Linode Kubernetes Engine创建的Linode,并影响集群的自动扩缩或配置。客户仍可通过LISH控制台手动配置网络以缓解此问题。请参阅我们的指南<a href="https://techdocs.akamai.com/cloud-computing/docs/manual-network-configuration-on-a-compute-instance">计算实例上的手动网络配置</a>。 有更多信息时我们会分享更多更新。
修复:已实施修复,以解决使用 Network Helper 的 Linode 上的自动网络配置问题。我们建议重启您的 Linode 以恢复完整的网络功能。我们正在积极监控结果,以确保持续稳定。
我们的团队正在调查一个新兴问题,该问题影响位于新加坡扩展区 SP (sg-sin-2) 数据中心的块存储服务。在此期间,用户在使用此服务时可能会遇到连接超时和错误。我们将在获得更多信息后分享进一步的更新。
原因:2026年6月30日,大约17:30 UTC至21:45 UTC之间,用户可能遇到了与新加坡扩展区、SP(sg-sin-2)的块存储服务相关的连接超时和错误。 问题始于集群中的一台主机因维护而停机,同时另一台主机意外遇到网络问题。一个配置问题也加剧了影响。 这些因素导致了降级状态,影响了性能以及(在有限程度上)数据可用性。我们通过纠正网络、配置和集群问题,于 2026 年 6 月 30 日 21:45 UTC 减轻了对客户的影响。 我们对造成的影响深表歉意,并感谢您的耐心与持续支持。 我们正在对系统进行配置和运维变更,以帮助防止此类情况再次发生,并持续致力于不断改进。 鉴于现有信息,本摘要概述了我们目前对事件的了解。我们的调查…
修复:目前我们已能够修复影响 Block Storage 服务的问题。我们将持续监控以确保其保持稳定。如果您继续遇到问题,请<a href="https://cloud.linode.com/support/tickets">提交支持工单</a>寻求帮助。
我们的团队正在调查一个影响 Cloud Pulse Metrics (ACLP Metrics) 的问题,具体影响 Managed Database Metrics(托管数据库指标)的报告。该问题似乎是间歇性的。我们将在获得更多信息后提供进一步更新。
修复:我们已经连续数小时未观察到影响 Cloud Pulse Metrics(ACLP Metrics)的问题再次出现。我们的团队将在调查根本原因的同时继续密切监控该服务。如果您仍然遇到问题,请<a href="https://cloud.linode.com/support/tickets">提交支持工单</a>以获取帮助。
我们的团队正在调查影响我们US-IAD数据中心连接性的问题。在此期间,用户可能会遇到部署在该数据中心的服务的间歇性连接超时和错误。我们将分享更多更新,一旦我们获得更多信息。
我们的团队正在调查一个新出现的服务问题,该问题影响所有区域的迁移和调整大小。目前,Linode 迁移和套餐调整大小可能会延迟。我们将在获得更多信息后分享进一步的更新。
修复:修复已实施,我们正在监控结果。
我们的团队正在调查一个新出现的服务问题,该问题导致所有区域中的 GPU 实例间歇性启动失败。我们将在获得更多信息后分享进一步更新。
原因:2026年6月23日,在一次全球软件部署之后,我们发现了一个导致 GPU Linodes 间歇性启动故障的问题。影响仅限于多个 GPU Linodes 同时尝试启动的实例。 在影响窗口期间,客户可能会遇到局部中断或错误率升高,尤其是在自动节点回收或扩缩容事件期间。 调查发现,最近的软件更新在多个 GPU 服务器尝试在同一时间启动时造成了冲突。 这些服务器实质上互相阻止了加载,我们的系统没有自动触发重试。这种特定交互仅在高并发负载下才会发生,这就是为什么在标准预发布测试中没有被发现。 为了缓解该问题,我们已于 2026 年 6 月 24 日 20:32 UTC 成功将热修复程序直接部署到我们整个集群中的所有活跃 GPU 主机。受影…
修复:2026 年 6 月 24 日 20:32 UTC,我们已经修复了导致所有区域中 GPU 实例间歇性启动失败的问题。我们将持续监控,确保其保持稳定。如果您仍遇到问题,请<a href="https://cloud.linode.com/support/tickets">提交支持工单</a>以获取帮助。
在2026年6月24日约08:12 UTC至12:35 UTC期间,使用Debian发行版创建/自动扩缩容Linodes的尝试可能因上游仓库中的过期InRelease文件而失败。我们已通过将镜像端点更新为健康仓库来缓解该问题。 如果您继续遇到问题,请<a href="https://cloud.linode.com/support/tickets">提交支持工单</a>以获得帮助。
原因:我们的上游第三方 Debian 仓库因未知原因无法与其自身的上游仓库链同步。Debian 软件包的 InRelease 文件自 2026 年 6 月 24 日约 08:12 UTC 起过期,导致任何 Debian 软件包都无法安装。 当时我们没有程序化的可见性,无法得知这些文件无法下载,或者 InRelease 文件中的到期日期是否已到。我们于 2026 年 6 月 24 日大约 12:35 UTC 通过更新我们同步 Debian 软件包的仓库来源,并从缓存中清除过期的 InRelease 文件,缓解了该问题。 我们正在致力于将这些文件的过期日期纳入系统可见性和告警范围,同时切换到更可靠的上游仓库,即 Debian 的官方仓库。…
我们的团队正在调查影响US-MIA (Miami)网络的新出现的服务问题。我们将在获得更多信息后分享更多更新。
原因:2026年6月16日,Akamai调查了一个影响迈阿密计算环境内应用程序的性能降级和连接缓慢的实例。该事件发生在2026年6月16日约13:37 UTC至14:20 UTC之间。调查发现,迈阿密一台Akamai设备上的配置更改触发了路由平台操作系统中的底层供应商软件缺陷。已采取措施减轻影响并恢复预期的路由路径。 为防止再次发生,我们已暂时暂停相关的配置更改。 根本原因:在例行的、计划内的聚合网络链路配置更新期间,触发了路由平台操作系统中的底层供应商软件缺陷。 虽然配置更改本身是标准且正确的,但该软件错误导致路由器错误地处理内部MPLS(多协议标签交换)路由表。软件不是仅将更改应用于目标链路,而是无意中清除了无关网络接口的路由指…
我们的团队正在调查影响 Longview 服务的问题。在此期间,用户可能会在 cloud manager 中遇到"waiting for data"的情况,并且可能无法看到预期的指标。我们将在获得更多信息后分享进一步的更新。
原因:大约从 2026 年 6 月 15 日 23:15 UTC 开始,部分客户无法访问 Longview 图表仪表盘。调查发现,Linodes 无法连接 Longview 端点,且未能上报数据。影响仅限于读取现有上报数据,且此次问题未导致任何永久性上报数据丢失。 为减轻影响,我们手动重启了已识别的虚拟机以使其生效并解决 Gateway 错误。执行此操作后,影响已于 2026 年 6 月 16 日 9:00 UTC 得到缓解。缓解后,所有预期数据均可在 Longview 图形仪表板中查看。我们将继续调查根本原因,并采取适当的预防措施。 我们对造成的影响深表歉意,感谢您的耐心与持续支持。我们致力于持续改进,让我们的系统变得更好并防止问题再…
修复:修复已实施,我们正在监控结果。
我们的团队正在调查一个影响所有区域中 Linode Migrations 的新出现服务问题。迁移可能会变慢或长时间处于待处理状态。当我们获得更多信息时,我们将分享更多更新。
修复:修复已实施,我们正在监控结果。
我们目前正在调查一个影响所有区域 LKE Enterprise 集群的新出现服务问题。在此期间,用户可能遇到部署新集群或升级现有集群失败的情况。我们的团队正在努力解决此问题,并将在获得进展后在此发布更新。
我们的团队正在调查一个上游新出现的服务问题,由于上游提供商的问题,影响了我们的支持电话线路。一旦有更多信息,我们将分享更多更新。在此期间,如果您通过电话联系我们有困难,请通过工单联系我们。
我们的团队正在调查影响我们位于美国纽瓦克数据中心中 Block Storage 服务的一个问题。在此期间,用户可能会遇到该服务的连接超时、延迟和错误。我们将在获得更多信息后分享更多更新。
原因:在2026年6月2日22:50 UTC至2026年6月3日19:00 UTC之间,一些客户在与美国纽瓦克的计算块存储集群交互时遇到间歇性性能下降和长时间访问。在此期间,间歇性组件不稳定触发了密集的后台恢复操作。这种系统负载升高导致受影响卷的数据冗余暂时降低、读写延迟升高和吞吐量下降。为了减轻影响,Akamai成功恢复了受影响的存储驱动器运行,稳定了集群并消除了活跃的客户影响。此后,额外的行动旨在完全恢复标准系统冗余。此摘要基于可用信息概述了我们目前对事件的了解。我们的调查正在进行中,此处任何信息如有更改,恕不另行通知。
修复:目前我们已能够修复影响 Block Storage 服务的问题。我们将持续监控以确保其保持稳定。如果您继续遇到问题,请<a href="https://cloud.linode.com/support/tickets">提交支持工单</a>寻求帮助。
我们的团队已发现社区网站(https://www.linode.com/community/questions/)存在问题。在此期间,该页面已进入维护模式。我们将根据更多信息提供进一步更新。
修复:目前我们已经能够修复影响社区站点连接的问题。我们将对此进行监控,以确保连接保持稳定。如果您继续遇到问题,请<a href="https://cloud.linode.com/support/tickets">打开支持工单</a>寻求帮助。
自2026年5月29日10:07 UTC左右起,伦敦的Object Storage不可用。在此期间,受影响的客户无法访问Object Storage,并可能看到500或类似的错误。 这是由一项计划中的路由器升级问题导致的。 该路由器此后已重新上线,我们可以确认该问题已于 2026 年 5 月 29 日 10:19 UTC 得到缓解,且不再发生。 我们对造成的影响深表歉意,感谢您的耐心等待和持续支持。我们致力于持续改进,使我们的系统更加完善,并防止问题再次发生。 如果您继续遇到问题,请<a href="https://cloud.linode.com/support/tickets">提交支持工单</a>以获得帮助。
原因:在May 29, 2026的10:13 UTC至10:22 UTC期间,使用Object Storage(OBJ)的London客户在尝试访问存储在该位置的内容时遇到5xx错误。在尝试隔离单独的丢包问题时,Akamai依次升级了2对路由器。 第一对路由器升级成功,但由于人为失误,第二对路由器的升级命令在第一对路由器完成路由收敛之前就被执行了。这导致London数据中心中OBJ流量的路由路径暂时丢失。 该问题通过自动警报被迅速检测到,一旦固件升级和路由收敛完成,服务便自动恢复。 Akamai 的变更管理政策要求所有路由器升级活动必须按照既定流程和预定的实施说明执行。 Akamai 将就变更管理政策开展复习培训,以强化对所需流程的合…
我们正在调查影响巴黎数据中心流量的一项服务问题。获得更多信息后,我们将分享更多更新。
原因:2026年5月22日大约09:10至11:30 UTC期间,巴黎(FR-PAR3)数据中心出现连接问题。在影响窗口内,客户可能会遇到部署在巴黎数据中心的服务的间歇性连接超时和错误。 我们的调查确认,由于我们在 FRA3 的两条 transit 恰好同时发生 flapped,触发了频繁的路由变化,最终导致数据包丢失,从而影响了主机的连接。 在进一步分析为何我们两条传输线路在同一时间发生抖动时,我们联系了数据中心供应商,经确认,在数据中心计划维护期间,为网络连接提供支持的两个运维机房断电数分钟,导致可用区完全隔离。 我们为造成的影响深表歉意,并感谢您的耐心与持续支持。我们致力于不断改进,使我们的系统更加完善,并防止此类问题再次发生。…
修复:该问题截至 2026 年 5 月 22 日 11:30 UTC 已消退,影响在 2026 年 5 月 22 日 09:10 UTC 至 11:30 UTC 期间被观察到。我们正在积极监控,以确保服务保持稳定。如果您继续遇到问题,请<a href="https://cloud.linode.com/support/tickets">打开支持工单</a>寻求帮助。
我们的团队正在调查一个影响所有区域 GPU 供应的新出现服务问题。目前,RTX PRO 6000 Blackwell 计划的部署不可用。我们将在获得更多信息后分享更多更新。
原因:2026年5月19日18:26 UTC,我们发现了一个影响使用四个 RTX PRO 6000 Blackwell (g3-gpu-rtxpro6000-blackwell) 套餐中的任意一种来创建和重新配置 Linode 实例的问题,导致出现 API 错误。这些故障导致尝试通过 Cloud Manager 或 API 部署 g3-gpu-rtxpro6000-blackwell 实例的客户遭遇拒绝服务。 经过初步调查,SMEs 确定问题的原因是近期 APIv4 更新中的一个逻辑错误。具体而言,一项仅适用于支持 RDMA 的网络的校验检查被错误地应用到了标准 Blackwell GPU 方案上。 这导致 API 拒绝了不符合特定 R…
修复:目前,截至 2026 年 5 月 19 日 21:27 UTC,我们已能够修复影响所有区域 GPU 预置的问题。我们将持续监控以确保其保持稳定。如果您仍遇到问题,请<a href="https://cloud.linode.com/support/tickets">打开支持工单</a>以获取帮助。
我们的团队正在调查一个新出现的服务问题,该问题影响所有区域的 Linode 启动。我们将在获得更多信息后分享进一步的更新。
原因:在 May 15, 2026, at 18:18 UTC,我们发现了一个影响依赖 StackScripts 的 Linodes 部署的问题(包括所有新建的 Linode Kubernetes Engine (LKE) 和 (LKE-E) 节点),导致部署失败。这些部署失败导致使用 StackScripts 创建的 Linodes 无法启动,并且 LKE 的自动扩缩容或回收活动失败。 主题专家确定,问题的原因是最近一次更新中在计算主机上移除了一个凭据解析器。该凭据解析器用于解码 StackScripts 的过程中,其移除导致依赖 StackScripts 的 Linode 部署失败。 问题确认后,我们于 UTC 时间 2026 年…
我们目前正在调查一个导致全球范围内冷迁移和在线迁移延迟的问题。部分迁移已停滞,且所有区域中还有更多迁移正处于排队和待处理状态。 客户影响:冷迁移、在线迁移以及 Linode resize(调整大小)操作可能会延迟或无响应。我们建议在问题解决之前,避免发起新的迁移和调整大小操作。 我们正在积极调查根本原因,并将尽快提供最新进展。
原因:2026年5月14日约04:00 UTC起,Akamai发现一个问题影响Linode迁移操作,包括热迁移、冷迁移和计划迁移。因此,部分客户遇到迁移处理延迟,正在进行特定迁移的客户在恢复处理前暂时无法访问其实例。 该问题是由处理迁移所需的内部服务意外重启引起的。重启后,这些服务未能按预期自动恢复,导致迁移任务无法启动,并造成了停滞操作的积压。 Akamai 工程师恢复了受影响的服务,迁移处理已恢复。 服务已于 2026 年 5 月 15 日约 03:15 UTC 基本恢复。 Akamai 正在继续调查意外服务重启的根本原因,并正在审查监控和恢复流程,以帮助防止未来出现类似问题。 本摘要反映了我们基于现有信息对该事件的当前理解。…
Akamai 已获悉近期披露的 “Fragnesia”[1] 漏洞,此前已有 “DirtyFrag”[2] 和 “CopyFail”[3] 的相关披露。该漏洞在性质上非常相似,影响、利用途径和缓解方法也类似。 我们尚未观察到任何针对我们基础设施的相关恶意利用,并且正在继续处理我们产品组合和内部系统中的漏洞。 与“CopyFail”和“DirtyFrag”一样,我们建议客户在修补完成之前,将大多数 Linux 发行版视为存在风险。 由于“Fragnesia”漏洞在可用的上游补丁发布之前就已披露,我们不得不等待各操作系统提供商发布新版本或补丁,之后才能将其集成到我们提供给客户的版本中。 由于这是一起快速发展的故障事件,我们将为所有可能受影响的客户提供关于建议措施、可能的缓解方案以及OS更新的进一步信息。 [1…
我们的团队正在调查影响 NL-AMS 数据中心连接的问题。在此期间,用户可能会遇到部署在该数据中心的所有服务出现间歇性连接超时和错误。我们将在获得更多信息后分享进一步的更新。
修复:目前我们已能够确认,没有客户应受到影响 NL-AMS 数据中心连接问题的影响。我们将进行监控以确保其保持稳定。如果您仍遇到问题,请<a href="https://cloud.linode.com/support/tickets">打开支持工单</a>寻求帮助。
我们的团队注意到,2026年5月12日和5月14日有两个短暂时段影响了托管数据库的 Cloud Pulse 指标(ACLP Metrics),目前已应用修复。我们未再观察到 ACLP Metrics 服务出现任何其他问题,现将此事件视为已解决。 如果您继续遇到问题,请<a href="https://cloud.linode.com/support/tickets">提交支持工单</a>以获得帮助。
原因:在2026年5月12日至5月14日期间,Akamai Cloud Pulse (ACLP) 经历了两次相关的服务中断,暂时中断了专门针对Managed Databases的遥测指标的数据摄取和显示。 * 窗口 1:5 月 12 日 23:15 UTC – 5 月 13 日 00:11 UTC * 窗口 2:5 月 14 日 06:47 UTC – 07:33 UTC 在这些窗口期间,客户无法在 Akamai Cloud Manager 仪表板中查看 Managed Database 性能指标,也无法通过外部 API 和 Collector 流获取这些指标。在两个影响窗口期间,Managed Database 基于指标的告警功能也…
我们的团队正在调查一个影响我们 AP-West(孟买)和 IN-MAA(金奈)数据中心连接的问题。在此期间,用户可能会遇到部署在这些数据中心的所有服务间歇性连接超时和错误。我们将在获得更多信息后分享额外更新。
原因:2026年5月12日约14:50 UTC,Akamai 开始出现网络拥塞和数据包丢失,影响了经由服务于我们孟买和金奈数据中心的多条互联网服务提供商网络路径在印度与欧洲之间传输的流量。受影响地区的客户可能遇到了间歇性连接超时和错误。 该问题是由于印度与欧洲之间的传输路径拥塞所致。Akamai 与相关互联网服务提供商及其上游提供商合作,确定了问题原因。为减轻影响,Akamai 将流量从受影响的路径转移,在调查继续进行期间稳定了服务。 服务已于 2026 年 5 月 12 日 19:23 UTC 在孟买数据中心恢复,并于 2026 年 5 月 13 日 00:25 UTC 在钦奈数据中心恢复。 Akamai 将继续与相关互联网服务提…
Akamai 已注意到近期披露的“DirtyFrag”[1] 漏洞,该漏洞紧随“CopyFail”[2] 披露之后出现。此漏洞在本质上非常相似,具有相似的影响、利用路径和缓解方法。 我们尚未观察到任何针对我们基础设施的相关恶意利用,并且正在继续解决我们产品组合和内部系统中的漏洞。 与“CopyFail”一样,我们建议客户在打补丁之前,将大多数Linux发行版视为存在风险。 由于“DirtyFrag”漏洞在上游补丁可用之前就已披露,我们被迫等待不同的操作系统提供商发布新版本或补丁,然后才能将其集成到我们向客户提供的版本中。 由于这是一起快速演变的事件,我们将为所有可能受影响的客户提供关于建议操作、可能的缓解措施和 OS 更新的进一步信息。 [1] https://github.com/V4bel/dirty…
Akamai 已注意到近期披露的“Copy Fail”漏洞(CVE-2026-31431)。我们正在评估该问题,并致力于在我们的产品组合和内部系统中解决此问题。虽然我们尚未观察到任何针对我们基础设施的相关恶意利用,但 Akamai 持续努力降低风险并增强我们的安全态势。 我们正在采取即时和更长期的措施,以减轻潜在影响,并帮助确保客户持续的信任。 根据我们的共享安全模型[1],客户有责任确保其服务上安装的应用程序和代码已进行安全配置和修补。 鉴于该漏洞的性质,在完成修补之前,应假定所有运行 Linux 的虚拟机都面临风险。随着补丁被纳入我们提供的基础镜像,我们将发布更多详细信息,但我们强烈建议客户在所有实例上部署缓解措施。 此外,该漏洞的性质表明容器逃逸是可能的,因此允许不受信任的工作负载在其容器中执行的客户可…
我们注意到,自昨晚起,部分客户在尝试访问对象存储时遇到 403(InvalidAccessKeyId)错误。我们将在获得更多信息后分享进一步的更新。
原因:在 2026 年 4 月 28 日约 09:15 UTC 至 2026 年 4 月 29 日 16:54 UTC 期间,客户可能遇到与其 Object Storage 密钥对相关的问题,包括:密钥创建和验证、使用其密钥访问 Object Storage。影响遍及多个数据中心。 我们的调查确定,该问题是由多种因素共同导致的,包括:一个后台进程从一个集群到其他集群的级联故障,以及一个 reconciler 设备因缺少指标而未运行,加上导致调用失败的异常系统负载。 为解决该问题,我们已重启了 reconciler,并已为客户处理了关键操作。 为帮助防止未来出现类似问题,Akamai 将处理级联故障场景,增加协调器(reconcile…
我们的团队正在调查一个新出现的服务问题,该问题影响我们 Chennai(IN-MAA)数据中心中的网络和连接。在该地区的流量高峰时段,客户可能会遇到间歇性延迟和超时。 如果您看到可能与此相关的服务影响,请<a href="https://cloud.linode.com/support/tickets?dialogOpen=true">提交支持工单</a>。
原因:大约在 2026 年 4 月 28 日 3:30 UTC,我们在金奈数据中心遇到了一次路由器故障,该故障与另一个临时以降低容量运行的网络硬件组件叠加后,导致 Compute 客户在高峰时段(约 09:00 UTC - 18:00 UTC)访问金奈(MAA)区域的 Linode 和其他资源时出现间歇性延迟或超时,在 2026 年 4 月 28 日。 2026 年 4 月 29 日 11:40UTC,我们取消了对受限网络组件的限流,从而恢复了足够的区域容量,可有效降低未来区域高峰流量时段内客户影响再次发生的风险。 2026年5月2日12:11 UTC,我们成功更换了性能下降的路由器并使新路由器上线,恢复了该区域的全部容量。 我们将…
我们的团队正在调查一个影响多个区域中 Linode Kubernetes Engine (LKE) 服务的新出现的服务问题。我们将在获得更多信息后分享更多更新。
原因:2026年4月24日17:57 UTC至23:36 UTC期间,NodeBalancer基础设施经历了一次服务降级,原因是NodeBalancer配置标识符超过了程序设定的限制。此问题导致新创建和更新的NodeBalancer功能降级,并使通过UI访问Linode Kubernetes Engine \(LKE\)集群的功能不可用。 任何自动扩缩容活动、NodeBalancer的创建或修改 \(如添加或移除节点\) 都会触发生成超出支持阈值的配置标识符,从而导致进一步恶化。影响范围扩展到了下游服务,如LKE。 Akamai 确定了根本原因,并于2026年4月24日23:36 UTC之前在所有数据中心部署了修复。 为防止此问题再…
修复:目前,我们已于2026年4月24日23:36 UTC解决了影响NodeBalancer服务的问题。我们将持续监控,以确保其保持稳定。如果您仍遇到问题,请<a href="https://cloud.linode.com/support/tickets">提交工单</a>联系我们的支持团队。
我们的团队正在调查一个影响法兰克福(DE-FRA-2)连接性的新出现服务问题。我们将在获得更多信息后分享进一步更新。
原因:2026 年 4 月 20 日,大约在 11:05 UTC 至 13:10 UTC 之间,法兰克福 (DE-FRA-2) 数据中心的 Compute 服务(包括 Linode 和 Object Storage)经历了连接质量下降和性能问题。 在此期间,Frankfurt 区域的客户可能遇到了丢包或连接问题。 最初,我们怀疑是数据中心正在进行的电力维护所致;然而,后来确定其并未造成影响。 进一步调查发现,连接问题影响了站点内的某些计算主机,并导致了全站范围内的主机任务完成问题。Akamai 识别出数据中心内一台主机发出的错误路由通告,这是造成中断的原因之一。受影响的主机已被识别并隔离,从而缓解了问题并恢复了服务稳定性。 我们对造成…
修复:修复已实施,我们正在监控结果。
我们的团队正在调查一个新出现的服务问题,影响所有地区的Linode Kubernetes Engine标准版和企业版。有更多信息时我们会分享更多更新。
原因:从 2026 年 4 月 16 日 11:45 UTC 开始,使用 Linode Kubernetes Engine (LKE) 和 Linode Kubernetes Engine Enterprise (LKE-E) 的客户开始遇到部署 LKE 和 LKE-E 集群及节点的问题。受影响的客户无法部署新节点,这也导致他们无法回收节点和自动扩缩集群。 调查显示,凭据过期导致了身份验证失败。 我们的主题专家(SMEs)创建了新凭据并部署以减轻影响。在凭据轮换后,该问题已于 2026 年 4 月 16 日约 16:27 UTC 得到缓解。 我们正在继续调查导致本次凭据过期的根本原因,并将采取适当的预防措施。 我们对造成的影响深表歉…
修复:截至 2026 年 4 月 16 日 16:27 UTC,我们已经修复了影响 LKE 服务的问题。该问题是由一张过期证书引起的,该证书已更新。我们将持续监控,以确保其保持稳定。 如果您仍然遇到问题,请<a href="https://cloud.linode.com/support/tickets">提交支持工单</a>以获取帮助。
我们的团队已确定影响 Cloud Manager 和 API 的问题。我们正在快速实施修复,解决方案到位后将立即提供更新。在此期间,客户可能无法创建新的 Linode、更改云防火墙、启动迁移或调整大小操作。LKE 自动缩放也可能在此期间延迟。
原因:2026年4月15日 16:07 UTC,我们发现了一个影响 Linode 平台的问题,多个主机开始出现 Linode VM 访客编排器服务故障。该问题扰乱了新的 Linode 作业、Linode Kubernetes Engine (LKE) 扩缩容及相关操作。 客户可能会注意到与计算相关的任务处理缓慢或不完整,包括在调整 Linode 或集群大小、部署新资源、更新 Cloud Firewall 规则,或通过 Cloud Manager 或 API 进行其他更改时出现延迟或失败。这些症状导致在问题时间段内操作缓慢或部分完成。 初步调查将根本原因追溯到与 Linode VM 客户机编排器服务相关的一个有问题的配置文件。为此,我们…
修复:目前,我们已经能够修复影响 Cloud Manager 和 API 的问题。我们将持续监控以确保服务保持稳定。如果您仍然遇到问题且无法<a href="https://cloud.linode.com/support/tickets">提交支持工单</a>,请致电 855-454-6633(国际:+1-609-380-7100),或发送电子邮件至 support@linode.com。
我们的团队正在调查一个影响 Dedicated CPU 产品的服务问题。部分用户可能会遇到 Linode 启动失败、与资源分配不足相关的错误、Dedicated CPU 套餐迁移或 LKE 集群扩缩容失败,以及难以部署或扩缩容需要 Dedicated CPU 资源的工作负载。 我们将在获得更多信息时分享更多更新。
原因:2026年3月9日20:02 UTC,我们发现了一个影响Dedicated CPU套餐Linode的问题,导致多个数据中心的启动失败和资源分配错误。该问题最初由一位无法启动新部署的Dedicated CPU Linode的客户报告。 我们于2026年3月10日开始调查该问题,并在收到更多报告后,于2026年3月17日在内部对该问题进行了升级。截至2026年4月14日,该事件已影响横跨七个数据中心的35台Dedicated CPU套餐主机,包括阿姆斯特丹、伦敦、马德里、亚特兰大、芝加哥、西雅图、华盛顿特区和大阪。 该问题被追溯到已知的软件缺陷,该缺陷导致启动过程中的验证失败,进而引发资源不足错误,并阻止了回退分配。 领域专家确定缺失…
我们的团队正在调查影响美国 IAD(华盛顿)网络的新兴服务问题。我们将在获得更多信息后分享进一步的更新。
原因:大约在 2026 年 4 月 9 日 22:55 UTC 开始,客户无法访问托管在美国 IAD(华盛顿)数据中心(DC)的服务。调查显示,该问题由网络连接问题引起,这会导致在该数据中心部署的服务出现连接超时和/或错误。 分析确认,中断是由一台配置错误的计算主机在开机时产生异常网络流量引发的。 为减轻影响,我们隔离了该主机,此后网络稳定性得以恢复。影响已于 2026 年 4 月 10 日 02:01 UTC 得到缓解。所有管理服务完全正常运行,待处理的主机作业积压已全部处理完毕。 我们将继续调查根本原因,并采取适当的预防措施。 我们对造成的影响表示歉意,并感谢您的耐心和持续支持。如果您还有其他问题,请致电 855-454-6633(国…
我们的团队正在调查一个新出现的服务问题,该问题影响与我们在 London 2(gb-ion) 区域的 Linode 基础设施的连接,可能是由于上游 AS 导致的。我们将在核实后继续分享更多细节。
修复:我们已确认由上游 AS 引起的问题影响已得到缓解。我们将继续监控情况,直至收到解决方案的进一步确认。
我们的团队正在调查影响us-east-1中Object Storage的一个新出现的服务问题。我们将在获得更多信息后分享更多更新。
我们的团队正在调查一个新出现的服务问题,该问题影响新计算实例的部署,当交换磁盘大小设置为0时。这也影响了我们的托管数据库服务。我们将随着更多信息的获得分享额外更新。
我们的团队已定位到影响雅加达数据中心连接性的问题。我们正在快速实施修复,解决方案就绪后将尽快提供更新。
原因:2026年3月20日约10:40 UTC,位于 Jakarta, ID \(id-cgk\) 的数据中心经历了电源波动,导致 Jakarta 的所有服务中断,并对 Singapore Expansion、SP \(sg-sin-2\) 和 Melbourne, AU \(au-mel\) 区域的服务产生下游影响。 设施切换到备用电源,导致所有数据中心网络设备和机器同时重启。虽然切换到发电机电源本不应造成中断,但不间断电源(UPS)的意外问题导致了停机。 数据中心的基础设施工程团队已确认,我们第三方数据中心的市电电源发生了瞬态欠压情况(电压闪变)。在此事件期间,数据中心的两套 UPS 系统未按预期响应,导致受影响的机架发生断电。 本地…
修复:目前我们已经修正了影响我们位于印尼雅加达数据中心连接性的问题。我们将对此进行监控,以确保其保持稳定。如果您仍遇到问题,请<a href="https://cloud.linode.com/support/tickets">提交支持工单</a>以获取帮助。
我们的团队正在调查一个影响 Linode Kubernetes Engine Enterprise (LKE-E) 服务的问题。在获得更多信息后,我们将分享进一步的最新进展。
原因:大约在2026年3月17日01:00至14:12 UTC期间,客户无法在芝加哥(us-ord)区域部署新的Linode Kubernetes Engine Enterprise \(LKE-E\)集群。原因是用于预配置的DNS区域中的DNS记录数量超过了允许的上限,导致无法创建集群部署所需的新记录。 该区域的现有 LKE-E 集群和标准 LKE 集群继续正常运行。 在 12:00 UTC 收到第一个监控警报后,我们进行了调查并确定了根本问题。我们发现,与已删除的 LKE-E 集群关联的 DNS 记录未被正确清理,导致未使用的记录逐渐累积。 这种累积最终达到了 DNS 区域的记录限制,阻止了新记录的创建,并阻塞了新的集群部署。在 1…
修复:目前我们已能纠正影响LKE-E服务的问题。我们将持续监控以确保其保持稳定。如果您继续遇到问题,请<a href="https://cloud.linode.com/support/tickets">打开支持工单</a>寻求帮助。
我们的团队正在调查一个新出现的服务问题,该问题影响我们在华盛顿特区(US-IAD)位置的网络。我们将在获得更多信息后分享进一步的更新。
原因:_2026年3月13日,大约在UTC时间17:35至18:54之间,我们的Washington (US-IAD)数据中心遇到连接问题。在此期间,客户可能会注意到该数据中心托管的全部服务出现中断。_ _我们的调查发现,此前用于测试的三台服务器在未擦除磁盘的情况下被归还至库存。_ 因此,其中一台服务器被送往仓库,随后又被送回华盛顿数据中心。这导致一台主机广播了无效路径,从而引发了服务中断。_ _我们迅速隔离了受影响的 主机,服务大约在 18:54 UTC 开始恢复。 经过全面的监控和系统检查,我们确认该问题已在 19:01 UTC 完全解决。_ _为防止将来出现类似问题,我们将进行详细调查,以确定此主机为何配置错…
我们的团队正在调查一个新出现的服务问题,该问题影响位于 JP、OSA(大阪)的新 LKE Enterprise Clusters 的部署。我们将在获得更多信息后分享进一步的更新。
原因:从2026年3月12日大约19:15 UTC开始,客户无法在Osaka数据中心(JP-OSA)创建Linode Kubernetes Engine for Enterprise(LKE-E)集群,也无法执行诸如LKE-E版本升级、Control Plane ACL更改等管理任务。尝试在该数据中心部署LKE-E集群时,创建过程无限期停滞。 Akamai 的调查显示,该问题始于 Osaka 数据中心分阶段推出 LKE 软件版本之后。 Akamai 部署了软件修复以减轻影响。该影响已于 March 13, 2026 大约 01:55 UTC 时得到缓解。在受影响窗口期间创建的集群已恢复创建。 我们的主题专家将继续调查根本原因,并将采取…
修复:目前我们已能够修复影响 LKE 服务的问题。我们将持续监控以确保其保持稳定。如果您继续遇到问题,请<a href="https://cloud.linode.com/support/tickets">开启支持工单</a>以获取帮助。
我们的团队正在调查一个影响 IAD(华盛顿特区)计算主机的新出现服务问题。我们将在获得更多信息后分享更多更新。
原因:自 March 9, 2026 18:09 UTC 起,我们 IAD3 (Washington DC) 数据中心中约 25% 的 Compute 主机因应用了旨在改善网络性能的更新路由配置而出现网络连接质量下降。 此更新的路由器配置经过了广泛测试,并已在另一个地区的生产环境中运行了数周,未出现任何问题。调查显示,由于 IAD3 数据中心特有的网络配置,应用此更改无意中导致了这些主机的连接中断。 这导致在问题得到缓解之前,托管在这些机器上的 Linodes 和集群失去了访问和控制。由于该问题特定的网络特性以及内部服务对受影响设备可见性的下降,缓解步骤花费的时间比预期更长,这需要额外的规划才能有效回滚到之前的配置。 我们已…
修复:目前我们已能够纠正影响 IAD(华盛顿特区)数据中心连接的问题。我们将进行监控以确保其保持稳定。如果您仍遇到问题,请<a href="https://cloud.linode.com/support/tickets">打开支持工单</a>寻求帮助。