Cloudflare配置踩坑记：一次DNS解析引发的血案

上周五深夜，我正在愉快地吃着烧烤，突然收到监控报警——我们核心业务的API突然大面积502。放下烤串擦了擦手，我花了40分钟才定位到是Cloudflare配置问题。今天就把这个典型的「DNS回源陷阱」复盘给大家，下次遇到类似问题至少能省半小时排查时间。

故障现象：诡异的502报错

最初看到监控图时我很困惑：所有边缘节点都返回502，但源站监控显示CPU/内存完全正常。更奇怪的是：

• 直接访问源站IP+端口完全正常
• Cloudflare面板显示「Active」状态
• SSL证书检测全部通过

这感觉就像你家WiFi显示满格却打不开网页——最折磨人的故障类型。

排查过程：那些容易忽略的细节

首先用dig +trace确认DNS解析链：

dig api.ourdomain.com +trace
;; Received 1056 bytes from 1.1.1.1#53(1.1.1.1) in 12 ms
;; → 这里显示Cloudflare返回了正确IP

接着用cURL测试回源请求：

curl -v -H "Host: api.ourdomain.com" http://源站IP
→ 200 OK

直到用Cloudflare的测试工具才发现端倪：

Error 502: Hostname does not resolve to origin server

问题根源：DNS配置的「鬼打墙」

原来我们在Cloudflare做了两件「聪明反被聪明误」的操作：

1. 在DNS记录里把api.ourdomain.com指向了Cloudflare代理（橙色云图标）
2. 同时在「Origin Rules」里设置了回源地址为api.ourdomain.com

这就形成了死循环：用户请求 → CF代理 → 解析回源地址 → 又指向CF代理 → 无限循环直到超时。

解决方案与经验总结

最终修正方法很简单：在Origin Rules里改用源站内部IP或独立解析记录（如origin-api.ourdomain.com）。这里分享几个关键经验：

• ⚠️ 永远不要让回源地址指向经过CF代理的记录
• 善用端口检查工具确认回源端口开放
• 测试时建议关闭「Always Online」等缓存功能

这次事故让我深刻理解到：越是「智能」的云服务，配置错误时表现越诡异。下次再遇到502，我的排查清单会首先检查这个死亡循环。现在，我得去把凉了的烤串热一热…