加载失败
Azure（微软云）出现一次影响管理门户（Azure Portal）、边缘流量层（Azure Front Door/CDN）和若干区域可达性的中断事件。HN 用户回报差异化影响：部分 VM、AKS 集群与通过直链访问的 App Services 在部分区域仍可用，但通过 Front Door 的域名解析或边缘交付失败导致外部访问中断。评论指出微软的公开状态页（Azure Service Health）最初显示绿色且更新滞后，且由于订阅级健康信息需在门户内查看，导致信息盲区；另外 Office 365 表面可用但依赖的 Entra ID 身份层可能受影响。讨论还把此次事件与近期 AWS 宕机相比较，引发对单云依赖与多云或小型主机商可用性权衡的讨论。
多位用户报告后端计算资源仍然可用：VM、部分 AKS 集群和通过直链访问的 App Services 在若干区域（例如 eastus、eastus2、荷兰）仍能响应。与此同时，Azure Front Door 似乎无法解析其负责的域名，导致经由 Front Door 的流量入口完全中断，个别团队被迫绕过 Front Door 使用直链。具体例子包括 GitLab 实例和 App Service 通过提供的 URL 可用，但通过 Front Door 的域名无法访问，说明故障集中在边缘/分发层而非所有后端实例同时宕机。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6]
用户指出 Azure 的公开状态页（azure.status.microsoft）在事件初期仍显示绿色，官方页面最初未标注活动事件，造成信息混淆。随后状态页才补充“我们正在调查 Azure 门户访问问题”的说明，但更新明显滞后。更糟糕的是 Service Health 的深入信息需通过 Azure Portal 登录查看，而当门户本身受影响时，订阅级别的健康信息也无法访问，增加了排障难度和可见性盲区。
有人报告 Office 365（如 Outlook、Teams）表面上仍可用，但其他评论提醒这些服务未必直接托管在 Azure。核心担忧在于认证层：Entra ID（原 Azure Active Directory）负责 Office 365 和许多服务的登录，一旦其受影响，用户可能无法完成认证，即便应用看似在线。评论中有确认指出 Entra ID 似乎受影响，这解释了为什么应用能被访问但登录或凭证验证会失败。
多条评论将本次中断与近期 AWS 宕机并列，表达对大型云供应商连续出现故障的担忧，并声称“多个 Hyperscaler 接连失败”。一些用户以 Hetzner 和 DigitalOcean 为例，称在自身经验中这些更小或专注的主机商在长期运行上更稳定，从而质疑高价云服务的高可用承诺。讨论中还有分歧：有人认为仅是管理门户问题，而另一些人指出 CDN 与 Front Door 也受影响，强化了依赖单一云服务商带来风险的论点。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6]
若干用户报告在同一时间点（约 15:45）观测到入口流量瞬间降为零，且多个回复的时间点一致，表明这是一次突发且具有同步性的事件。该现象更像是边缘/路由或 DNS 层的整体失效，而非单一区域或逐步退化。多名用户在相近时间互相确认流量骤降，支持此次故障为跨区域或全局性的入口层问题的判断。
Azure Front Door: 微软的全球应用交付与边缘流量服务，负责流量路由、SSL 终止、域名解析与 CDN 加速，常作为外部流量的入口层。
Azure Portal: Azure 的网页管理控制台，用于资源管理和查看订阅级别的诊断与 Service Health 信息，许多运维操作需在此执行。
Azure Service Health（azure.status.microsoft）: Microsoft 提供的公开状态页和订阅级健康服务，用于通报全局与订阅级别的事件；部分详细信息需在 Azure Portal 登录后查看。
Entra ID（原 Azure Active Directory）: Microsoft 的身份与访问管理服务，负责用户认证与授权；若其受影响，会导致 Office 365 和基于该认证的服务出现登录问题。
AKS (Azure Kubernetes Service): Azure 托管的 Kubernetes 服务，用于运行容器化工作负载，评论中有用户报告其集群在事件中仍可接收请求。