Cloudflare Status 怎么查？实时状态、地区维护与故障排查指南

更新于 2026-11-03 · hgfastapp.lol

简答：先打开 Cloudflare 官方 Status 页面，看总体状态；再进入 Services 检查具体服务、History 查看事件和地区，最后用错误码、DNS、源站与本地网络逐层排查。本次核验时间为 2026 年 11 月 3 日，官方首页显示没有已知服务问题，但实时状态会变化，不能用旧结论代替当前检查。

定义：Cloudflare Status 是 Cloudflare 用来公布整体服务、具体组件、地区网络、事件记录、维护计划和通知订阅状态的官方状态系统。

先判断：Cloudflare 是全局故障，还是你自己的连接问题？

遇到网站打不开、控制台报错、Workers 或 Pages 部署失败时，不要先改 DNS、重置网络或更换客户端。先完成下面的三层判断：总体状态、具体服务、地区与事件。

检查位置	适合回答的问题	看到什么后继续排查	安全回退
Cloudflare Status 首页	Cloudflare 当前是否公布了整体服务问题？	查看总体提示、近期事件和进行中的维护。	只记录页面显示的时间和状态，不据此永久判断服务正常。
Services & Sites	是 CDN、DNS、Dashboard、API、Workers、Pages 还是其他组件异常？	搜索具体服务，查看 Operational、Degraded、Offline 或 Maintenance 等页面状态。	若目标组件正常，转查域名、源站、账户或本地网络。
Incident & maintenance history	刚才是否发生过区域性故障、维护或已解决事件？	按服务和地区筛选，查看事件状态、更新时间和影响范围。	记录 UTC 或页面显示的本地时间，避免把旧事件当成当前故障。
Status API	能否自动监控或接入内部告警？	读取总体状态、组件、未解决事件和维护接口。	自动化访问使用 API，不要抓取 HTML 状态页。

本次核验于 2026 年 11 月 3 日完成：官方首页显示“没有已知服务问题”，同时页面列出了若干进行中的地点维护。这里的两种信息并不矛盾：总体状态正常不等于每个数据中心、每项服务或每个用户路径都没有局部影响。发布后请重新打开官方页面确认，不要把本文中的实时结论当成持续保证。

先试这一步：在问题发生的同一时间打开官方首页，再进入 Services 搜索你实际使用的组件。如果首页没有对应事件、目标组件也显示正常，优先转向域名、源站、SSL 或本地网络排查。

Cloudflare Status 的页面分别怎么看？

1. 首页：看总体结论，但不要止步于此

首页用于快速查看总体提示、近期事件和进行中的维护。它适合回答“是否有公开的 Cloudflare 服务问题”，不适合单独证明某个域名、账户、源站或访问地区一定正常。页面还提供通知、Status API 和 RSS 等入口。

2. Services：定位具体组件

Services 页面按服务和站点分类展示状态，常见类别包括 CDN/Cache、DNS、Network、Dashboard、API、SSL/TLS、安全服务、Workers 和 Pages 等。搜索时使用你报错页面对应的功能名，不要只搜索“Cloudflare”。例如，网站打不开可先看 CDN、DNS 和 Network；后台登录异常可看 Dashboard 或 API；部署失败则检查 Workers、Pages 或相关开发者服务。

3. History：确认时间、地区和事件状态

History 页面适合核对“问题是否刚刚发生过”。按服务、地点和类型筛选后，重点看事件标题、In Progress、Resolved、Completed 等状态，以及最后更新时间。跨时区工作时，以页面给出的 UTC 或本地时间为准；如果你的故障时间与事件时间不匹配，就不要强行归因于该事件。

4. API 与订阅：适合团队监控

官方 API 文档说明，多数状态接口返回 JSON 且不需要认证；Summary 可同时获取总体指示器、组件状态、未解决事件和进行中的维护。自动轮询时应使用 API，并发送可识别的 User-Agent，避免直接抓取 HTML 页面。官方文档还说明，状态页通知独立于 Cloudflare 基础设施，可通过邮件、Webhook、Slack、Discord 或 Google Chat 接收；账户内的 Incident Alerts 则可按影响级别和组件筛选，并支持邮件、Webhook 或 PagerDuty。

如果你只需要个人提醒，订阅状态页通知即可；如果需要接入值班系统，优先评估 API、Webhook 或 PagerDuty；如果需要在脚本中判断是否有未解决事件，使用官方 API 页面列出的 endpoint，并先在测试环境验证返回字段。

状态页显示正常，但网站仍打不开：按现象排查

“Cloudflare 总体正常”只说明官方没有公布对应的整体服务故障。网站仍打不开时，应按现象而不是按品牌名称排查。

现象或错误	优先判断	验证动作	停止条件与回退
域名解析失败、`NXDOMAIN`、`DNS_PROBE_POSSIBLE`	记录缺失、名称服务器变化、DNSSEC 或本地解析器问题。	核对域名拼写、顶级域和子域记录；必要时查询权威名称服务器，并比较不同网络的解析结果。	不要先反复刷新或清空所有网络配置；若记录刚修改，保留原记录并等待解析缓存变化。
522、523、524	更偏向 Cloudflare 到源站的连接、可达性或响应超时。	记录错误码、URL、时间和时区；由站点管理员检查源站状态、防火墙、Cloudflare IP 放行、源站 IP 与 DNS 是否一致。	访客不能直接修复源站；把诊断信息交给站点管理员，不要擅自改源站防火墙。
502 或 504	可能来自源站，也可能来自 Cloudflare，需先区分错误页样式和响应来源。	保存完整错误页面、响应头、URL 和时间；站点管理员检查源站负载、崩溃、超时与压缩响应。	不要仅凭 502 认定 Cloudflare 全局故障；先区分带 Cloudflare 品牌的源站错误和无品牌的边缘错误。
525、526 或 SSL 协议错误	可能是 Cloudflare 与源站的 TLS 握手、证书或协议兼容问题，也可能是本地网络干扰。	检查证书覆盖范围、有效性、源站 TLS 配置；访客可换一个网络复现并记录浏览器完整报错。	不要在没有备份和回退方案时直接切换 SSL 模式；先记录现有设置。
只有一台设备或一个网络失败	本地 DNS、浏览器缓存、代理、安全软件、网络出口或路由问题。	用同一 URL 在另一台设备、另一网络和无痕窗口测试；比较解析结果和错误时间。	若换网络后恢复，先恢复原代理、DNS 和安全软件设置，再定位差异。

Cloudflare 官方文档指出，522 表示 Cloudflare 连接源站超时，常见方向包括源站离线、过载、阻断 Cloudflare IP 或 DNS 中的源站地址不匹配；502/504 则需要先判断响应来自源站还是 Cloudflare。诊断时保留具体错误码、URL、发生时间和时区，这些信息比“Cloudflare 挂了”更适合交给主机商或站点管理员。

如果浏览器能显示错误页面，可在开发者工具的 Network 面板查看响应头；官方文档还说明，Cloudflare 生成的错误页可能包含 cf-error-type，其中 1xxx 通常指向 DNS/路由层，1101/1102 指向 Workers 运行时，52x 指向源站连接问题。命令行用户可在有权限且确认 URL 安全的前提下使用 curl -v https://example.com 观察响应头；不熟悉命令行时，保存浏览器错误页和完整 URL 即可。

如何建立一个低风险的 Cloudflare 故障判断流程？

记录现象：保存完整 URL、错误码、浏览器提示、发生时间、时区、设备和网络类型。
查官方总体状态：打开 Status 首页，确认是否存在公开事件或维护；不要只看搜索摘要。
查具体组件：进入 Services 搜索 CDN、DNS、Dashboard、API、Workers、Pages、SSL/TLS 或你实际使用的功能。
查地区与历史：在 History 按地点和服务筛选，确认事件是否覆盖你的访问路径以及发生时间是否相符。
做低风险复现：用同一设备换浏览器，或用另一网络测试；只做对比，不先重置网络、改 MTU、停用安全软件或批量修改 DNS。
按错误类型交给正确对象：DNS 记录和名称服务器交给域名或 DNS 管理员；522/523/524 交给源站或主机商；账户和 API 权限问题交给账户管理员；单设备问题先查本地网络。
验证修复：再次打开官方状态页、目标 URL 和关键 API；确认错误码消失，并在原网络与备用网络各复测一次。

任何涉及 DNS、SSL、代理、防火墙或源站的修改，都应先导出或记录现有配置，并保留可恢复的旧值。若修改后现象变差，优先回退最近一次变更，而不是连续叠加新改动。

Cloudflare Status 常见状态怎么理解？

状态页的展示标签和 API 字段可能随页面实现变化，以下按官方当前页面与 API 文档的用途解释：

Operational：组件当前按状态页定义运行，不能证明每个域名、账户、地区或源站都可访问。
Degraded：性能或可用性出现下降，可能是部分功能、地区或请求路径受影响。
Partial Outage：部分组件或部分范围发生中断，需继续查看事件详情和地区。
Major Outage：影响范围较大的服务中断，需要结合事件更新判断进展。
Maintenance：维护窗口或进行中的维护，不等于所有相关服务都不可用；应查看地点、时间和影响说明。
Resolved：事件已标记解决，但你的本地 DNS 缓存、源站连接或账户配置可能仍需单独验证。

官方 Status API 文档还把总体状态和组件状态分开：总体接口返回 none、minor、major 或 critical 等指示器，组件接口则返回 operational、degraded_performance、partial_outage 或 major_outage 等状态。自动化判断时应依据接口返回字段，不要用网页文字做脆弱的字符串匹配。

什么时候应继续等，什么时候应立即排查？

可以先观察：官方 History 中存在与你的服务、地区和时间吻合的 In Progress 事件；此时记录事件链接和更新时间，避免频繁改配置。
应立即排查：Status、Services 和 History 都没有匹配事件，但只有你的域名失败；优先查看 DNS、源站、SSL、WAF、部署记录和本地网络。
应联系站点管理员：你是访客并遇到 5xx、522、523、524、525 或 526；Cloudflare 官方说明，访客应向网站所有者报告，域名所有者再收集错误详情处理。
应建立通知：网站、API 或跨境办公系统依赖 Cloudflare，且故障需要值班响应；使用状态页通知、API 或 Webhook，而不是依赖人工刷新。

状态页面是公开事件入口，不是对单个站点的可用性保证。判断是否真的是 Cloudflare 故障，至少要让“官方事件、具体服务或地区、你的错误时间”三项能够相互对应。

常见问题

Cloudflare Status 显示正常，为什么我的网站还是打不开？

因为状态页反映的是 Cloudflare 公开的总体或组件状态，不代表你的源站、DNS 记录、SSL、WAF、账户权限和本地网络都正常。先看错误码，再分别核对 Services、DNS、源站和访问网络。

Cloudflare Status 官方入口在哪里？

可从 Cloudflare 官方 Status 首页开始，再根据问题进入 Services 查看具体组件，进入 History 查看已解决事件和地区维护。需要自动监控时使用官方 Status API 页面列出的接口。

怎么判断是 Cloudflare 故障还是源站故障？

先记录错误码和时间，再查看官方 Status、Services 和 History 是否有匹配事件。522、523、524 通常需要重点检查 Cloudflare 到源站的连接；502/504 必须进一步区分响应来自源站还是 Cloudflare。

Cloudflare 的 Operational、Degraded、Partial Outage 和 Maintenance 有什么区别？

Operational 表示组件按状态页定义运行；Degraded 表示性能或可用性下降；Partial Outage 表示部分范围中断；Maintenance 表示维护状态。最终应以事件详情、服务、地区和更新时间为准。

可以用 Cloudflare Status API 做监控吗？

可以。官方 API 文档提供总体状态、组件、未解决事件、全部事件以及进行中或计划维护等接口，多数接口返回 JSON 且通常不需要认证。自动访问应使用 API，并发送可识别的 User-Agent。

看到 522 或 524 时，普通访客应该改 DNS 吗？

通常不应直接改 DNS。522 或 524 更需要由站点管理员检查源站可达性、负载、防火墙、Cloudflare IP 放行和响应超时。访客应保存错误码、URL、时间和时区并联系网站方。