今天真是见鬼了。
原本只是想像往常一样，用 ChatGPT 优化一下博客文字，结果发现——ChatGPT 打不开，Twitter 上不去，甚至连我自己一些依赖 Cloudflare 的服务也陆续抽风。打开 Cloudflare Status 一看，果然官方事故通报已经发布：
（官方事件链接：你在正文里可以加上 Cloudflare 的公告，而不是裸链接）

这一波事故让我第一次真切地感受到什么叫“全球单点故障”。虽然 Cloudflare 本身并不是单点，但它确实已经深度融入全球互联网基础设施，只要它出现大规模问题，波及的范围就会非常可怕。

我自己的服务器架构其实很简单：

• DNS 解析：Cloudflare
• 代理功能：Cloudflare
• 后台服务接入：Cloudflare
• 理由：免费 + 隐藏源站 IP

本来只是图个方便，没想到今天这些便利成为了隐患。

Cloudflare 事故到底有什么影响？

对于普通用户来说，就是“好多网站打不开”。
但对站长来说，问题更具体：

• DNS 解析延迟甚至失败
• 代理层访问 5xx
• API 调用阻塞
• 某些地区极端不稳定
• 连 ChatGPT、Twitter 这些巨头都遭遇部分访问故障

依赖 Cloudflare 越深，越能感受到系统级中断的威力。

我的反思：不要让 Cloudflare 成为架构里的“唯一”

今天之后我意识到一个事实：
免费的稳定性永远不等于真正的 SLA。

Cloudflare 确实是性价比无敌的服务商，但如果所有关键链路都放在同一家公司，当它出现重大事故时，你的业务也会毫无退路。

因此我现在开始考虑：

• DNS 引入 多家服务商（如 DNSPod、Route53）
• 核心服务尽量减少 Cloudflare Worker / API 的耦合
• 源站 IP 不再完全依赖隐藏策略，改用安全组 + 限流 + 防火墙
• 为核心接口准备独立的“逃生通道”