今晚,不是被攻击,不是流量暴增,而是全球数百万网站集体"消失"了——DNS解析失败、CDN无响应、Workers边缘计算全线瘫痪。一开始我还以为自己的网络坏掉了呢,试了各种办法,都不好使。

打开Downdetector,那条代表Cloudflare的蓝色曲线几乎垂直上升。ChatGPT、Discord、Medium、Shopify...一长串知名网站陷入不可用状态。
这已经是2025年第三次大规模宕机。
作为一个在生产环境用了5年Cloudflare的老油条,我想和你聊聊:这次故障暴露了什么?为什么全球开发者明知风险还要all in?以及,有没有真正靠谱的容错方案?
先看官方通报:这次故障源于DNS解析服务异常,进而触发CDN缓存失效,最终导致Workers边缘计算节点无法路由。
用简化的流程图表示:
用户请求
↓
[DNS查询] → Cloudflare DNS (❌故障)
↓
无法获取IP地址
↓
[CDN节点] → 找不到源站位置 (❌失效)
↓
[Workers边缘计算] → 依赖DNS的业务逻辑 (❌瘫痪)
↓
整个服务链路崩溃
关键点在于"级联失败":
DNS不仅仅是域名解析,它是Cloudflare整个服务体系的基石。一旦DNS出问题:
这就像多米诺骨牌,第一张倒下,后面全完蛋。
国内开发者可能感受不深,但对于海外独立开发者:
这对于初创团队和个人项目,简直是降维打击。
来看一个真实场景对比:
不用Cloudflare的传统架构:
[用户]
→ 腾讯云DNS (¥50/月)
→ 阿里云CDN (按流量¥0.24/GB)
→ AWS Shield (DDoS防护,¥3000/月起)
→ 自建边缘计算服务器 (运维成本...)
用Cloudflare:
[用户]
→ Cloudflare一站式服务
→ 月费: $0 (免费版) / $20 (Pro版)
这性价比,你说香不香?
一旦你的架构深度集成了Cloudflare:
迁移成本高到让人绝望。就像从微信迁移到钉钉,不是技术问题,是整个生态问题。
故障原因:第三方冷存储供应商故障,导致全球KV读取失败 影响时长:4小时23分钟 暴露问题:边缘存储依赖单一供应商,没有热备份
故障原因:工程师配置错误,DNS前缀路由失效 影响时长:62分钟 暴露问题:自动化配置缺少多级审核机制
故障原因:DNS服务异常触发CDN连锁反应 影响时长:预估90分钟+ 暴露问题:核心服务之间耦合过紧,缺少隔离机制
三次故障的共同特征:
最小可用方案:
// DNS健康检查 + 自动切换
const dnsProviders = [
{ name: 'Cloudflare', server: '1.1.1.1', priority: 1 },
{ name: 'Route53', server: '8.8.8.8', priority: 2 },
{ name: 'DNSPod', server: '119.29.29.29', priority: 3 }
];
asyncfunction resolveWithFallback(domain) {
for (const provider of dnsProviders) {
try {
const result = await dns.resolve(domain, provider.server);
if (result) return result;
} catch (error) {
console.warn(`${provider.name} DNS failed, trying next...`);
continue;
}
}
thrownewError('All DNS providers failed');
}
推荐配置(中国场景):
核心思路:当CDN不可用时,自动回源到源站
// Service Worker实现CDN降级
self.addEventListener('fetch', event => {
const cdnUrl = event.request.url.replace('origin.com', 'cdn.cloudflare.com');
event.respondWith(
fetch(cdnUrl, { timeout: 3000 }) // 3秒超时
.catch(() => {
console.warn('CDN timeout, fallback to origin');
return fetch(event.request.url); // 直接访问源站
})
);
});
实际效果:
Cloudflare Workers的危险写法:
// ❌ 危险:业务逻辑完全依赖Workers
export default {
async fetch(request) {
// 鉴权、路由、业务逻辑全在这
const user = await authenticate(request);
return handleRequest(user);
}
}
更安全的写法:
// ✅ 安全:源站保留完整能力
exportdefault {
async fetch(request) {
try {
// Workers只做加速和缓存
const cached = await CACHE.get(request.url);
if (cached) returnnew Response(cached);
// 源站保留完整业务逻辑
return fetch('https://origin-server.com' + request.url);
} catch {
// Workers挂了?直接透传到源站
return fetch(request);
}
}
}
架构对比:
传统方式(危险):
[用户] → [Workers独立处理业务] → (Workers挂了=服务挂了)
推荐方式(安全):
[用户] → [Workers加速层] → [源站完整服务]
↓ (故障时)
[直接访问源站]
核心代码(基于UptimeRobot API):
import requests
import time
# 多地域探测节点
PROBE_LOCATIONS = [
'us-east', 'eu-west', 'asia-southeast', 'china-beijing'
]
def check_availability(url, timeout=5):
results = {}
for location in PROBE_LOCATIONS:
try:
start = time.time()
resp = requests.get(url, timeout=timeout,
headers={'X-Probe-Location': location})
latency = (time.time() - start) * 1000
results[location] = {
'status': resp.status_code,
'latency': f'{latency:.2f}ms'
}
except Exception as e:
results[location] = {'status': 'FAILED', 'error': str(e)}
return results
# 实时监控
whileTrue:
status = check_availability('https://your-site.com')
if any(r['status'] != 200for r in status.values()):
send_alert('WARNING: Service degradation detected')
time.sleep(60) # 每分钟检查一次
告警规则建议:
很多人觉得"多云=烧钱",我们算笔账:
方案A:All in Cloudflare
成本:$20/月 (Pro版)
风险:一年宕机3次,每次影响时长1-4小时
损失:假设每小时业务损失$1000,年损失≈$6000+
方案B:Cloudflare + 国内CDN
Cloudflare Pro: $20/月
腾讯云CDN (备份): 100GB流量 ≈ ¥24/月 ($3.5)
DNSPod (备份DNS): ¥50/月 ($7)
------
总成本: $30.5/月 (增加50%)
------
收益:
- 国内访问速度提升60%
- 故障自动切换,损失降低90%
- 年节省损失: $5400+
ROI计算:
额外投入: $30.5 - $20 = $10.5/月 = $126/年
故障损失减少: $6000 × 90% = $5400/年
------
净收益: $5274/年
结论:多云架构不是成本,是投资。
2025年的云服务市场:
这种集中带来了:
看看容器领域的演进:
2010年代早期: Docker一家独大
↓
2015年: Kubernetes出现,定义了容器编排标准
↓
现在: Docker、containerd、CRI-O 可互换
CDN/DNS领域需要类似的演进:
目前已有进展:
短期策略(1-2年):
长期策略(3-5年):
Cloudflare的服务陆续恢复。
我看着监控面板上那些跳动的绿色指标,想起一句话:
"The Internet interprets censorship as damage and routes around it." —— 互联网把审查视为损坏,并绕过它。
今天,我们需要同样的思维:
把任何单点依赖都视为潜在的"损坏",然后设计出能够"绕过"的架构。
Cloudflare不会是最后一次宕机,AWS也不会,阿里云也不会。
真正的高可用,不是选对了服务商,而是当任何服务商出问题时,你的系统依然能跑。
对了,GitHub上有个项目叫multi-cdn-failover,里面有完整的多CDN切换方案。等Cloudflare彻底恢复了,我打算fork一份,改成适合国内场景的版本。
你的网站准备好下一次宕机了吗?
💬 讨论话题:
欢迎留言,我会认真回复每一条。