Cloudflare 中断、区域 CDN 故障和边缘级别降级并不总是显示在状态页面上。当您的 CDN 的 Tokyo POP 出现故障但其全局状态显示为绿色时，您在弗吉尼亚州的监控将无法捕获它。
区域中断检测需要从用户实际所在的位置进行监控，而不仅仅是基础设施所在的位置。
现在是凌晨 3 点。您的待命工程师因客户的成功而受到启发：“新加坡的三个企业客户报告他们无法访问该应用程序。大约两个小时前开始。”
你检查你的监控仪表板——一切都是绿色的。 Cloudflare 的状态页面 — 运行。 AWS — 没有发生任何事故。您的 APM — 快乐的小图表。因此，您要求客户重试，清除缓存，检查网络。
但这种事一直在发生。来自同一地区的更多门票。最后，有人从新加坡 VPS 运行跟踪路由并发现：流量正在访问返回 502 的 Cloudflare 边缘。 CDN 发生影响一个 PoP 的区域中断 — 并且您的监控堆栈中没有任何内容正在从该区域进行检查。
停机两个小时。对于特定的地理位置。零警报。这就是本页的盲点。
无论是 Cloudflare 中断、Fastly 边缘故障还是 Akamai 区域降级 - 检测这些问题都需要对受影响区域进行监控。这就是您在问题升级为客户升级之前发现问题的方法。
互联网不是一个单一的网络。来自悉尼的请求与来自法兰克福的请求所经过的基础设施完全不同。当该区域路径的任何部分发生故障时，只有该区域中的用户受到影响。
Cloudflare、Fastly 和 Akamai 等 CDN 在全球运营着数百个接入点 (PoP)。当特定边缘服务器或 PoP 遇到问题（硬件故障、配置错误或容量问题）时，只有路由到该边缘的用户会受到影响。 CDN 的全球状态仍然是“可运行”，因为 95% 的边缘都没有问题。
示例：2022 年 6 月，由于网络配置更改，Cloudflare 发生了 30 分钟的中断，影响了 19 个数据中心。这些地区的用户看到了错误；其他地方的用户没有遇到任何异常情况。
DNS 是任何请求的第一步。当 Cloudflare 的 1.1.1.1 或您的 CDN 的 DNS 服务器在特定区域遇到问题（任播路由配置错误、名称服务器过载）时，该区域的用户无法解析您的域。他们的浏览器仅显示“DNS_PROBE_FINISHED_NXDOMAIN”。
示例：区域 DNS 问题可能是由 ISP 级过滤、本地解析器问题或仅影响某些地理区域的任播路由问题引起的。
BGP 路由泄漏、劫持和错误配置可能会通过次优路径重定向流量或将其完全黑洞。当某个地区的主要运营商出现路由问题时，从该地区到您的 CDN 或源的流量可能会失败 - 即使两个端点都运行良好。
示例：BGP 事件定期影响数千个网络。单个错误配置的 AS 路径可能会导致您的站点在数小时内无法从整个国家/地区访问，而从您的监控位置看来却一切正常。
由于对等互连争议、拥塞或基础设施问题，特定国家/地区的主要 ISP 可能会降低与 CDN 的连接性。澳大利亚的 Telstra 用户可能会遇到故障，而同一城市的 Optus 用户则没有问题，因为流量流经不同的路径。
示例：ISP 和云提供商之间的对等互连争议在历史上曾导致数周的降级，影响特定市场中的数百万用户。
共同点：所有这些失败都在地理范围内。你的起源已经上升了。您的 CDN 配置正确。但是，在您的边缘和特定区域的用户之间的某个地方，出现了问题，而您从弗吉尼亚州的一个位置进行检查的监控无法检测到它。
大多数正常运行时间监控都是为了解决一个更简单的问题而设计的：“服务器是否响应？”对于服务全球用户的 CDN 加速网站来说，这不再是正确的问题。
大多数监控服务默认从少数美国或欧盟地点进行检查。如果 Cloudflare 的新加坡 PoP 出现故障，您来自俄勒冈州的支票仍然会成功 - 它会达到不同的、健康的优势。与此同时，您的亚太地区用户会看到 502 错误。
从 AWS 到 Cloudflare 运行检查使用云主干连接 - 不代表真实用户流量的优化路径。来自 AWS ap-southeast-1 的综合检查可能会绕过本地 ISP 上的用户失败的确切网络路径。
CDN 状态页面反映了其内部视图，通常跨数百个 PoP 进行聚合。影响 5% 基础设施的区域问题可能不会触发状态页面更新，但这 5% 可能包括整个东南亚。
HTTP 检查会告诉您请求是成功还是失败，但不会告诉您失败的位置。如果没有受影响区域的路由跟踪和延迟细分数据，您无法确定问题是 DNS、特定网络跃点还是 CDN 边缘。
Cloudflare 拥有 310 多个 PoP。如果您的监控从 3 个位置进行检查，则您验证的用户可能触及的边缘不到 1%。这不是断电检测——这只是希望得到最好的结果。
每当 Cloudflare 中断或区域 CDN 故障未被发现时，您就会失去用户、收入和对您所服务的市场的信任。
该时区工作时间内的区域中断可能会导致交易、注册或 API 调用花费数小时的时间。用户不会发送“你的网站因我而关闭”的电子邮件——他们只是离开。稍后您会看到区域指标有所下降，但没有明确的原因归因。
企业客户有 SLA。当他们无法访问您的平台而您甚至不知道存在问题时，那就是一次糟糕的对话。 “我们没有检测到中断”并不是建立信任的回应——尤其是当他们为可靠性付费时。
Googlebot 从全球多个位置进行抓取。如果您在某个区域的 CDN 边缘返回错误或响应缓慢，则会影响抓取预算、核心 Web 生命评估以及最终排名。您可能会发现特定市场的流量下降，但没有明显原因。
平均恢复时间 (MTTR) 从您检测到问题时开始计算。如果在您从客户票证中得知区域性 Cloudflare 中断影响用户 2 小时后，您的有效 MTTR 就会增加 2 小时。主动检测是最大程度地减少实际停机影响的唯一方法。
区域中断检测需要从用户所在的位置进行监控，并通过诊断深度来确定发生故障的位置。
每个监控位置都会触及不同的 CDN 边缘并遍历不同的网络路径。为了检测区域中断，您需要在每个有有意义流量的区域（亚太地区、欧洲、美洲、中东、非洲）建立节点。不仅仅是“国际”——特别是您的用户所在的地方。
超过 50 个位置的监控涵盖主要 CDN PoP 和 ISP 路径。
当新加坡的检查失败但其他地方的检查成功时，您需要知道：是 DNS 吗？特定的网络跃点？ CDN 边缘？来自受影响位置的 Traceroute 和 MTR 提供了诊断根本原因所需的证据，并将问题升级给 Cloudflare、您的 ISP 或托管提供商。
诊断数据将“某些东西出了问题”转化为可采取行动的根本原因。
距东京 400 毫秒是正常现象还是 Cloudflare 边缘降级？每个位置的历史数据构建基线，让您可以检测缓慢的故障 - 延迟增加不会触发硬故障，但会降低用户体验。您可以在区域 CDN 问题完全中断之前发现它。
基线在出现中断之前捕获降级情况。
实施监控的分步指南，可在用户报告之前捕获 Cloudflare 中断和区域 CDN 故障。
检查您的分析以确定您的用户在哪里。如果 20% 的流量来自亚太地区，那么您需要在那里设置多个监控节点——新加坡、东京、悉尼、孟买。将监控覆盖范围与实际用户分布相匹配。
为通过 Cloudflare 或 CDN 的主要 URL 设置 HTTP 监视器。这些应该到达 CDN 边缘，而不是直接到达您的源。包括您的应用程序域、API 端点和任何关键公共页面。
不同地区有不同的基线延迟。配置有意义的阈值：也许来自欧洲的 500 毫秒是可以接受的，但来自美国东部（当您的源站在那里时）的 500 毫秒表示存在 CDN 边缘问题。使用历史数据设定现实的基线。
设置在特定区域出现故障时触发的警报，而不仅仅是在所有位置出现故障时触发。仅限新加坡的故障仍然是值得了解的故障。将高优先级警报发送至 Slack、PagerDuty 或您的事件管理系统。
当警报触发时，您需要快速确定：这是 Cloudflare 的问题吗？网络路径问题？域名系统？从监控位置启用按需跟踪路由和 MTR，以便您可以立即收集诊断数据。
记录该过程：如何验证 Cloudflare 区域中断。在哪里检查 Cloudflare 的状态 API。如何用证据开票。您可以应用哪些缓解措施（故障转移、缓存旁路等）。做好这一准备可显着缩短 MTTR。
设置每周日历提醒以查看每个区域的延迟和正常运行时间。寻找规律：亚太地区是否一直较慢？特定位置是否有规律的光点？主动审查可以在缓慢的降级对用户产生重大影响之前发现它们。
对于不可接受区域中断的服务，请考虑采用多 CDN 策略，其中 DNS 可以在提供商之间进行故障转移。这需要独立监控每个 CDN 并具有可以切换流量的自动化。这是复杂性，但也是弹性。
Latency Global 旨在准确检测此类问题 - Cloudflare 中断、区域 CDN 故障以及单位置监控遗漏的网络问题。我们从进行监控，涵盖所有主要 CDN PoP 区域。
每次检查都包括完整的时序细分 - DNS 解析、TCP 连接、TLS 握手、TTFB 和总响应时间。当特定区域出现故障时，您可以从该位置运行traceroute 和 MTR，以准确识别网络路径中发生问题的位置。定价很简单：5 台显示器5 美元/月，包括所有位置。
区域中断检测需要许多位置的基础设施 - 这就是为什么大多数监控工具要么不提供它，要么向企业收取费用。我们关注重要的事情：覆盖范围和诊断深度。
当 CDN 网络中的特定边缘服务器或存在点 (PoP) 发生故障或性能下降，而其他边缘仍保持运行时，就会发生区域 CDN 中断。例如，Cloudflare 的新加坡 PoP 可能存在问题，而其美国和欧洲边缘则运行良好。通过受影响边缘的用户路由会遇到错误或性能下降；其他地方的用户不会注意到任何事情。这些中断对于仅从未受影响区域进行检查的监控来说是不可见的。
CDN 状态页面通常显示总体全局状态，而不是每个 PoP 的运行状况。当 5% 的边缘受到影响时，整体状态可能会保持“运行”状态，因为 95% 的基础设施正在运行。状态页面也有更新延迟——检测、验证和发布问题需要时间。此外，某些问题不符合公开披露的门槛，但仍会影响您的用户。从多个位置进行独立监控是获得有关区域可用性的基本事实的唯一方法。
至少，您需要在拥有用户的每个主要区域监控位置：至少是北美、欧洲和亚太地区。为了获得更好的覆盖范围，分布在全球的 50 多个地点将捕获大多数区域问题。关键是将监控覆盖范围与您的用户地理位置相匹配 - 如果 30% 的用户位于亚太地区，则您需要在那里部署多个节点（新加坡、东京、悉尼、孟买）。这并不是要匹配每个 CDN PoP，而是要覆盖主要的区域组。
首先，收集诊断证据：来自受影响位置的跟踪路由和 MTR、HTTP 响应代码和计时数据以及时间戳。检查 Cloudflare 的状态页面和 Twitter 是否有任何确认。如果这显然是 Cloudflare 问题，请使用您的证据打开支持票证。要立即缓解问题，请考虑：暂时绕过受影响区域的 Cloudflare（如果您的源站可以处理），如果您具有多 CDN 功能，则启用备份 CDN，或者在 Cloudflare 解决问题时更新状态页面以确认问题。记录一切以供事后审查。
是的，有适当的监测仪器。完整的 HTTP 检查计时显示：DNS 解析时间（如果 DNS 失败或缓慢，您知道这是 DNS 问题）、TCP 连接时间（网络路径问题）、TLS 握手时间（证书或加密问题）以及 TTFB/响应时间（源或边缘处理问题）。 Traceroute 显示网络路径以及数据包被丢弃或延迟的位置。通过比较受影响区域与健康区域的数据，您可以准确识别请求链中发生故障的位置。
如果检查间隔为 1 分钟，您可以在中断开始后 1-2 分钟内检测到中断。大多数监控服务会在连续 2-3 次故障后确认中断，以避免针对瞬态信号发出警报，因此实际检测时间为 2-5 分钟。将此与客户报告的中断进行比较，后者可能需要数小时才能通过支持票证显示出来。 MTTR 的差异非常显着 - 5 分钟与 2 小时意味着用户影响截然不同。
绝对地。 Fastly、Akamai、AWS CloudFront、Google Cloud CDN、Azure CDN 和任何其他 CDN 都可能遇到区域中断。同样的原则也适用：CDN 具有分布式基础设施，任何分布式系统都可能出现部分故障。检测方法是相同的 - 从多个全球位置进行监控以捕获影响特定边缘或区域的问题，无论您使用哪个 CDN。
停止依赖 CDN 状态页面和客户票证来了解区域中断。添加端点，选择监控位置，并在几分钟内了解 Cloudflare、Fastly 或堆栈的任何部分在任何区域出现故障的时间。
5 美元/月 • 70 多个地点（很快还会有 40 个以上） • 无合同 • 随时取消