Cloudflare Flexible 模式下，源站强制 HTTPS 导致重定向循环

网站接入 Cloudflare 代理后，浏览器提示 ERR_TOO_MANY_REDIRECTS，而源站配置里有一条“所有 HTTP 请求都跳到 HTTPS”的规则。如果 Cloudflare 的 SSL/TLS 加密模式仍为 Flexible，这两项设置会相互冲突。

这个场景的关键是回源协议。浏览器访问 HTTPS，不代表 Cloudflare 也用 HTTPS 连接源站。Flexible 模式下，HTTPS 访客请求会通过 HTTP 回源；源站再把它重定向到同一个 HTTPS 地址，浏览器重试后又进入相同过程。

先看重定向去了哪里

在浏览器开发者工具的 Network 面板勾选保留日志，然后重新加载页面，查看连续响应的状态码和 Location。也可以用下面的命令查看第一跳；example.com 需要替换为自己的域名：

curl -sS -D - -o /dev/null https://example.com/

以下是循环中可能出现的响应示例，不能据此判断所有重定向都是这个原因：

HTTP/2 301
location: https://example.com/

如果请求已经是这个 HTTPS 地址，响应却反复要求回到相同地址，就检查 Cloudflare 的加密模式，以及源站 80 端口是否有无条件的 HTTPS 跳转。例如：

server {
    listen 80;
    server_name example.com;
    return 301 https://example.com$request_uri;
}

如果 Location 在两个域名、www 与根域名，或者两个路径之间交替，先检查对应的跳转规则。那不一定是 Flexible 回源导致的循环。清理浏览器缓存也无法修复仍在发生的服务器跳转。

源站有合格证书时，改用 Full (strict)

源站已经提供 HTTPS 时，应先确认 443 端口可供 Cloudflare 访问，证书未过期、覆盖回源目标主机名，并由公开受信任 CA 或 Cloudflare Origin CA 签发。确认这些条件后，在 Cloudflare 的 SSL/TLS Overview 中选择 Full (strict)。

这会让 Cloudflare 通过 HTTPS 回源，并校验证书。源站 80 端口的 HTTP→HTTPS 跳转可以保留，因为 HTTPS 访客不再反复进入这个 HTTP 入口。修改后检查实际生效的模式，尤其是存在主机级覆盖规则的站点。

如果切换后出现 525 或 526，应回到源站 TLS 握手、证书链及主机名检查，不要把关闭证书校验当作长期修复。修改前记录原模式和跳转规则；需要恢复时，应按原配置还原，并重新检查是否又引入原来的循环。

源站暂时只能提供 HTTP 时

暂时保留 Flexible 的前提，是接受 Cloudflare 到源站这一段不加密。此时需要移除导致循环的源站 HTTP→HTTPS 跳转，让 HTTP 回源请求实际返回页面；访客的 HTTP→HTTPS 跳转可由 Cloudflare 的 Always Use HTTPS 在边缘完成。

单独打开 Always Use HTTPS，并不会消除源站仍在执行的无条件跳转。修改 Nginx 时应保留原配置，检查通过后再重载；实际服务启动在容器或使用非默认配置文件时，使用对应实例的管理方式。这样做也会改变直接访问源站 HTTP 时的行为，需要确认源站访问限制是否符合预期。

如果 Web 服务器已经不跳转，但应用仍根据自身收到的 HTTP 请求生成 HTTPS 跳转，应检查应用的可信代理与外部协议配置。只信任受控代理提供的协议头，不要允许外部客户端任意伪造头字段来影响安全判断。

怎样确认已经恢复

用新的浏览器会话分别访问 HTTP 和 HTTPS 地址。HTTP 可以有限次跳转到指定 HTTPS 地址，HTTPS 应得到预期页面或应用正常的认证响应，不能再次重定向到自身。再检查登录、后台及子域名，确认没有另一组规则继续制造循环。