先确认前提条件

在启用Cloudflare DNS负载均衡前，需要确认域名已通过Cloudflare的DNS托管，且计划支持负载均衡功能（如Business或Enterprise）。如果使用免费版，可以考虑开源替代方案或升级计划。另外，确保后端服务器有健康检查端点，例如返回200的HTTP页面或TCP端口可达。

很多人在这一步就卡住了——免费版确实没有负载均衡入口。如果你只是做简单故障转移，可以先用第三方DNS配合Cloudflare CDN，或者用Cloudflare的Traffic Steering功能（部分免费计划支持）。但如果你需要精确控制后端权重和健康检查，建议至少升级到Business。注意：不要在没确认域名托管在Cloudflare之前就尝试配置，否则负载均衡器不会生效。

把健康检查和源地址池配扎实

登录Cloudflare控制台，进入DNS页面，点击“Load Balancing”选项。创建负载均衡器时，先定义源地址池（Origin Pool），每个池包含一组服务器IP或域名。建议为每个池设置不同的地理位置标签，以便后续按区域分配流量。

这一步常见的坑是：源地址池里的IP写错、端口遗漏，或者健康检查协议不匹配。例如后端只支持HTTP但配置了HTTPS检查，Cloudflare会一直显示Unhealthy。建议先用手动TCP ping测试连通性：curl -I http://后端IP:端口。如果后端有SSL证书问题（比如自签证书），HTTPS健康检查会直接失败。你可以先改成HTTP check，或者在后端配置正确的证书后再改回HTTPS。另外，健康检查路径别写太深，推荐用/或/health，后端返回200即可。

改完怎么看状态

配置完成后，在负载均衡器的健康检查页面查看各端点的状态。如果显示“Unhealthy”，检查防火墙是否放行了Cloudflare的健康检查IP范围。同时，可以通过curl命令模拟请求：curl -H 'Host: yourdomain.com' https://负载均衡器IP，观察响应是否来自预期的服务器。

这里有一个关键点：Cloudflare健康检查IP范围会定期更新，你需要在后端的防火墙白名单里放行这些IP。另外，如果你用域名作为源地址（比如CDN回源），负载均衡器会自动解析并跟踪变化。但健康检查依然以解析后的IP为准。如果显示Unhealthy，先看防火墙日志是否有Cloudflare IP被拒绝。还有一个技巧：在检查页面点击“Retry”按钮，查看瞬时响应，比等待自动轮询更快发现问题。

备用方案和兜底

Cloudflare负载均衡依赖DNS解析，TTL默认较短（60秒），但更改配置后可能仍有短暂延迟。如果所有后端均宕机，Cloudflare会缓存最后正常的IP或返回错误。建议设置备用池或回退到静态页面，避免完全空白。另外，注意免费版可能有不支持自定义健康检查路径的限制。

备用池可以是一个指向简单静态页面的服务器，比如使用Cloudflare Pages托管一个503页面。配置时，在负载均衡器规则里添加一个Fallback Pool，优先级最低。这样当所有主用池都挂了，流量会指向备用池。但注意备用池的服务器也要通过健康检查，否则一样会挂。如果你不想额外花钱，可以设置TTL为120秒并开启Cloudflare的Smart Tiered Caching来减少回源压力，但这不能完全替代备用。

别忘了这些边界限制

一个常见错误是健康检查路径或协议不匹配，例如后端只支持HTTP但配置了HTTPS检查。另一个坑是源地址池中的IP写错或端口遗漏，导致检查连接被拒。此外，如果后端有SSL证书问题，HTTPS健康检查会失败。建议先用简单TCP ping测试连通性。

还有一个容易被忽略的点：Cloudflare的负载均衡器本身会消耗一个CNAME记录，如果你已经有根域名记录，需要先用Cloudflare的CNAME Flattening处理。另外，负载均衡器不支持UDP健康检查，如果你的服务是UDP（如游戏服务器），需要改用TCP探测或自定义脚本。最后，所有后端服务器的响应时间最好做统一监控，因为Cloudflare会根据响应时间做地理亲和性，如果某台服务器响应特别慢，其他区域的流量也可能被误导到它那里。