那个深夜：Cloudflare配置失误引发的回源灾难实录

凌晨2点17分，手机突然疯狂震动——监控系统报警，我们所有托管在Cloudflare后的API服务全部返回502错误。作为当晚的值班工程师，我瞬间从床上弹起来，手忙脚乱地打开笔记本。这个故障教会了我关于CDN配置最血淋淋的一课：错误的回源设置比DDOS攻击更致命。

故障现象：完美的502风暴

控制面板显示所有边缘节点都在返回502 Bad Gateway，但源服务器监控却显示CPU、内存一切正常。最诡异的是：

• 直接访问源服务器IP端口正常
• Cloudflare的缓存命中率突然归零
• 没有任何防火墙拦截记录

排查过程：三个致命假设

我最初沿着三个错误方向排查：

1. SSL证书问题：检查了证书链和TLS版本配置
2. DNS污染：反复验证了A记录解析
3. 源服务器过载：其实CPU使用率不到5%

直到无意间点开「Network」选项卡，看到这个配置项时，我后背突然一凉：

# 错误的origin规则示例
origin.example.com:443 {
  # 忘记配置TLS SNI
  tls {
    alpn http/1.1
  }
}

根本原因：SNI幽灵

问题出在Cloudflare的回源SNI配置上。我们在迁移到新服务器时：

• 源站启用了严格的SNI校验
• 但Cloudflare回源请求中没携带正确SNI头
• 导致源服务器直接拒绝连接

这就像快递员把包裹送到了正确的小区，却报错了门牌号。

修复方案：五分钟的救赎

解决方案简单得让人想哭：

1. 在Cloudflare面板找到「SSL/TLS」→「Origin Server」
2. 勾选「Enable Server Name Indication (SNI)」
3. 填写与证书匹配的SNI主机名

修改后立即生效，监控曲线像跳水运动员一样恢复了正常。

血泪经验：回源检查清单

现在我们的变更流程强制要求检查：

这次事故让我明白：CDN不是魔法黑箱，回源配置需要像对待数据库连接字符串一样谨慎。现在每次修改Cloudflare设置前，我都会条件反射般地先检查这三项，毕竟凌晨被报警叫醒的滋味，体验一次就够了。