跳转到主内容
websoft网络软件专家 - 深耕网络技术,打造实用软件!

宝塔面板强制HTTPS后出现无限循环重定向怎么办_排查CDN设置及清除缓存

Cloudflare SSL模式设为“灵活”是重定向循环的头号原因,因其导致Cloudflare以HTTP回源,与宝塔强制HTTPS叠加形成301循环;应改为“完全”或“完全(严格)”模式,并清理Nginx中残留的return 301规则、关闭自动HTTPS重写、清除浏览器及CDN缓存。 Cloudflare SSL模式设成“灵活”是重定向循环的头号原因 浏览器报
ERR_TOO_MANY_REDIRECTS
或状态码
310
,但宝塔 Nginx 配置里只有一处
return 301 https://$host$request_uri
——这说明跳转不是单点触发,而是两段逻辑叠加:Cloudflare 自己跳一次,宝塔再跳一次。 根本问题出在 Cloudflare 的「SSL/TLS 加密模式」。默认选的「灵活」会让 Cloudflare 用 HTTP 去访问你的宝塔服务器(哪怕你开了强制 HTTPS),于是路径变成: 用户 → Cloudflare(HTTP → HTTPS)→ 宝塔(收到 HTTP → 再 301 到 HTTPS)→ 循环。 必须进 Cloudflare 控制台 → 域名 → SSL/TLS → 概览 → 把加密模式从
灵活
改为
完全
或
完全(严格)
选
完全(严格)
前,确认宝塔已安装有效证书(不能是自签名、过期或仅用于子域名的证书),否则 Cloudflare 会直接拒绝连接 别只改 SSL 模式,顺手关掉「自动 HTTPS 重写」(在 SSL/TLS → 边缘证书里)——它会在 HTML 中插入 JS 强制跳转,和 Nginx 规则叠加更易超限 宝塔「强制 HTTPS」开关关了,配置文件里还藏着 return 301 很多人点了「SSL」页签右上角的关闭按钮就以为完事了,但宝塔不会自动清理旧规则。下次重启 Nginx 或重装证书时,它可能又把
return 301 https://$host$request_uri
插回去。 真正要动的是网站的 Nginx 配置文件: 宝塔后台 → 网站 → 对应站点 → 「配置文件」→ 搜索
return 301 https
或
rewrite ^(.*)$ https://
PS CS6绿色精简版 最好用的图像处理软件 下载 重点检查
server { listen 80; ... }
这个块,不是 SSL 的那个
server
块 删掉整行,或用
#
注释掉;别留空行或半截语句,Nginx 会报错 如果用了多级域名(如
www
和根域都绑定了证书),还要检查是否两个
server
块都写了跳转——比如
example.com
跳
www.example.com
,而后者又跳回根域 浏览器缓存和 CDN 缓存会固化错误跳转链 即使你改完了 Cloudflare 和宝塔,用户访问时仍可能看到 310 错误。这是因为:浏览器记住了之前的 301 跳转,CDN 节点也缓存了 Location 响应头。 本地测试前,先清 Chrome/Edge 的 DNS 缓存:
chrome://net-internals/#dns
→ 点「Clear host cache」 再清浏览器全部缓存(Ctrl+Shift+Del → 勾选「Cookie 及其他网站数据」「缓存的图像和文件」) Cloudflare 上,进「缓存」→ 「配置」→ 点「清除整个站点缓存」;或者临时开启「开发模式」(5 分钟),让所有请求绕过缓存直连源站 别信「无痕窗口」——它不清理 DNS 缓存,也不绕过已缓存的 301 反向代理场景下 X-Forwarded-Proto 头没透传也会导致循环 如果你用宝塔做了反向代理(比如把
/api
转给 Node.js 或 Django),但后端服务自己判断协议并跳转,那就算 Cloudflare 和宝塔都配对了,照样会循环。 典型表现是:直接访问宝塔监听的 80 端口没问题,但走 Cloudflare 就 310;curl 测试时加
-H "X-Forwarded-Proto: https"
就正常,不加就跳。 进宝塔「网站」→「反向代理」→ 编辑对应代理 → 「高级」→ 在「请求头」里补上:
proxy_set_header X-Forwarded-Proto $scheme;
同时确保有:
proxy_set_header Host $http_host;
(不是
$host
),否则后端拿到的 Host 可能丢端口或协议信息 后端代码里如果硬编码了跳转逻辑(比如 Express 的
res.redirect('https://' + req.get('host'))
),得改成依赖
X-Forwarded-Proto
头判断 真正卡住的地方,往往不是某一个开关没关,而是 Cloudflare 的「灵活」模式、宝塔配置里残留的
return 301
、浏览器缓存三者叠在一起,让一次请求实际走了 4–5 次跳转才被浏览器拦截。动手前先 curl -I 看响应头里的 Location 变化,比盲调快得多。

相关文章