在为 seedloc.com 启用 Cloudflare CDN 加速时，遇到了一个非常典型的问题：
开启小黄云之后，网站直接打不开了。
浏览器给出的提示是：
无论是清除 Cookie、切换浏览器，还是使用无痕模式，都无法解决。但只要关闭 Cloudflare 的代理（仅保留 DNS 解析），网站立刻恢复正常。
这意味着，问题并不在网站程序或服务器本身，而是出现在 Cloudflare 与源服务器之间的访问逻辑 。
问题现象与初步判断
当时的整体状态可以总结为：
源服务器可直接访问
DNS 解析正常
HTTPS 在源站侧工作正常
关闭 Cloudflare 代理 → 网站正常
开启 Cloudflare 小黄云 → 无限重定向
如果是 DNS 配置错误，关闭代理通常无法立刻恢复访问。因此可以基本排除 DNS 问题，排查重点自然落在 SSL / HTTPS 配置 上。
Cloudflare SSL/TLS 模式是关键点
Cloudflare 提供了多种 SSL/TLS 加密模式，不同模式下 Cloudflare 与源服务器的通信方式完全不同。
常见的 SSL/TLS 模式说明
Flexible（灵活）
浏览器 → Cloudflare：HTTPS
Cloudflare → 源服务器：HTTP
这是一个 非常容易引发问题的模式 。
Full（完全）
浏览器 → Cloudflare：HTTPS
Cloudflare → 源服务器：HTTPS
不校验证书合法性
Full (strict)（完全 / 严格）
浏览器 → Cloudflare：HTTPS
Cloudflare → 源服务器：HTTPS
校验源服务器证书
这是 Cloudflare 官方推荐的 生产环境模式 。
问题根因：Flexible + 强制 HTTPS 跳转
在本次问题中，Cloudflare 的 SSL/TLS 模式被设置为了：
Flexible（灵活）
而 seedloc.com 的源服务器本身已经开启了：
HTTP → HTTPS 强制跳转
两者叠加后，实际访问流程变成了：
浏览器 → Cloudflare（HTTPS）
Cloudflare → 源服务器（HTTP）
源服务器：强制跳转 HTTPS
→ 返回 Cloudflare
→ Cloudflare 再次使用 HTTP 访问源站
→ 形成无限循环
浏览器在多次重定向后直接终止请求，于是出现了 ERR_TOO_MANY_REDIRECTS。
正确的解决方案：切换到 Full (strict)
解决方法并不复杂，也不需要改动 DNS 或服务器配置。
修改步骤
进入 Cloudflare 控制台：
SSL/TLS → 概述（Overview） → 自定义 SSL/TLS
将加密模式从 Flexible 修改为：
Full (strict) / 完全（严格）
保存设置即可。
.webp)
为什么 Full (strict) 可以彻底解决问题？
在 Full (strict) 模式下：
Cloudflare 访问源服务器时使用 HTTPS
不再触发源服务器的强制跳转
整个访问链路保持一致
HTTPS 状态清晰、可控
这是 Cloudflare 在实际生产环境中最稳定、最安全的工作方式。
修改后的结果
在将 SSL/TLS 模式切换为 Full (strict) 后：
网站访问立即恢复正常
不再出现重定向死循环
Cloudflare CDN 正常生效
HTTPS 行为符合预期
问题至此完全解决。
使用 Full (strict) 前需要注意的一点
唯一需要确认的是：
源服务器必须已经安装 HTTPS 证书
可以是：
Let’s Encrypt
Cloudflare Origin Certificate
任何有效的商业 SSL 证书
如果源服务器没有证书，Cloudflare 会拒绝连接。
一个可临时使用但不推荐的方案
如果暂时无法为源服务器配置证书，可以临时选择：
Full（非 strict）
该模式同样使用 HTTPS 连接源站，但不会校验证书合法性。
⚠️ 仅适合作为过渡方案，不建议长期使用。
总结
这次问题再次验证了一点：
Cloudflare 出现
ERR_TOO_MANY_REDIRECTS大多数情况下 不是 DNS 问题
而是 SSL/TLS 模式与源站配置不匹配
对于已经启用 HTTPS 的网站来说：
❌ Flexible
✅ Full (strict)
这是一个值得记录下来的典型 Cloudflare 实战案例。
评论