网站开启 HTTPS、接入 CDN 或修改域名后，如果浏览器提示“重定向次数过多”，说明请求在多个地址之间反复跳转。清理浏览器缓存可能暂时改变表现，却不能修复服务器与程序之间相互冲突的规则。正确的起点是找到循环中的两个或多个地址。
一、记录完整跳转链
打开浏览器开发者工具的“网络”面板，保留请求日志，再访问出错页面。逐条查看 301、302、307 或 308 响应中的 Location 目标，记录请求从哪个地址跳到哪里。测试时可临时禁用浏览器缓存，并用新的浏览器会话对照。
常见模式包括 HTTP 与 HTTPS 来回切换、带 www 与不带 www 来回切换、首页与登录页互相跳转。先确认模式，再寻找负责这些跳转的配置层。只有单个页面出错时，应优先检查该页面的路由或登录条件。
二、统一 HTTPS 与回源方式
例如，访问者通过 HTTPS 连接 CDN，而 CDN 使用 HTTP 访问源站；如果源站检测到 HTTP 就跳回同一个 HTTPS 地址，下一次回源仍可能触发相同跳转。出现这种情况，应核实 CDN 的回源协议、源站证书及应用对原始协议的识别方式。
不要为了消除循环直接关闭整站 HTTPS。应先使回源方式与源站规则一致；应用需要读取代理转发信息时，只信任由受信代理写入的协议标识，不能无条件相信任意客户端传来的请求头。具体选项以主机与 CDN 的实际文档为准。
三、让主域名规则保持一致
确定网站最终使用的唯一访问地址，例如 HTTPS 加不带 www 的域名，再核对主机面板、程序站点地址、伪静态文件和插件设置。如果面板把不带 www 跳转到 www，而程序又反向跳转，就会形成循环。
修改前备份原规则与程序配置。每次只调整一个有明确冲突的地方，并立即复测。永久跳转可能被缓存，规则测试应先在可控环境进行；确定无误后，再按网站需求选择最终的跳转类型。
四、登录循环要额外检查 Cookie
若普通页面可访问，只有后台登录后反复返回登录页，检查 Cookie 的域名、路径、Secure 属性与会话保存是否匹配当前访问地址。域名或协议刚刚修改时，旧 Cookie 可能影响登录，可先清除该站点的 Cookie 后测试，无须清空所有网站的数据。
如果每次刷新都生成新会话，还要检查 PHP 会话目录是否可写、程序是否报错。不要在公共页面显示会话标识，也不要通过取消登录验证来“修复”问题。
五、修复后验证不同入口
- 分别访问 HTTP、HTTPS、带 www 和不带 www 的入口，确认最终地址一致。
- 检查首页、文章内页、登录页、退出操作和一个不存在的地址，避免只验证首页。
- 确认没有多余跳转链，静态资源可用，后台会话保持正常。
- 按需刷新受影响的 CDN 缓存，再用不同网络或新的浏览器会话复测。
支付通知和表单接口应直接配置到最终可用地址，不要假设所有调用方都会跟随跳转。接口若涉及 POST，请同时核对重定向是否保留请求方法与请求体。
需要检查规则文件时，可结合WordPress 与 Z-BlogPHP 伪静态排查指南操作。技术参考：MDN：HTTP 重定向。