ThinkPHP 6.1 HTTPS跳转异常的核心是协议感知失准：未配置trust_proxy导致isSsl()始终返回false，X-Forwarded-Proto头不被信任，进而引发URL生成错误、混合内容、Cookie丢失及无限重定向。
ThinkPHP 6.1 项目开启 HTTPS 后内部跳转异常，核心问题通常不是跳转逻辑本身出错，而是协议感知失准、URL 生成不一致或混合内容干扰导致的连锁反应。重点不在“怎么跳”，而在“跳的时候认不认得清当前是 HTTPS”。
检查中间件是否正确识别 HTTPS 协议
TP6.1 的 $request->isSsl() 默认只信任直连请求，若你用了 Nginx、SLB、CDN 或 Cloudflare，X-Forwarded-Proto 头不会被自动采纳，isSsl() 永远返回 false，造成强制跳转失效或反复跳转。
- 确认已启用代理信任：在
config/app.php中设置'trust_proxy' => true，并填写真实代理 IP 段（如['10.0.0.0/8', '172.16.0.0/12', '192.168.0.0/16']） - 确保 Web 服务器（如 Nginx）正确透传协议头，例如添加：
proxy_set_header X-Forwarded-Proto $scheme; - 避免依赖
$_SERVER['HTTPS'] === 'on'判断——该值在绝大多数反代环境下为空或不可靠
统一 URL 生成方式，避免协议硬编码
控制器或模板中手动拼接 http:// 或 https:// 域名，极易导致跳转目标与当前协议不一致，尤其在测试环境切 HTTP、生产切 HTTPS 时更易暴露问题。
- 跳转一律用
redirect('route_name')或redirect()->to($request->url(true))，让框架自动补全协议和域名 - 前端 JS 中获取当前地址，改用
window.location.origin而非写死http://example.com - 静态资源链接（CSS/JS/img）务必使用相对协议（
//domain.com/xxx.js）或url()辅助函数生成，防止混合内容被浏览器拦截
验证 Cookie 和 Session 是否启用 secure 属性
HTTPS 开启后，若 Cookie 未标记 secure，浏览器可能拒绝发送；而 Session ID 若未安全传输，会导致登录态丢失、AJAX 请求 401、CSRF 校验失败，间接表现为“跳转后回到登录页”或“提交表单无响应”。
立即学习“PHP免费学习笔记（深入）”；
- 在
config/session.php中确认：'secure' => true,（生产环境必须为true） - 在
config/cookie.php中同样设'secure' => true，并确保'httponly' => true、'samesite' => 'Lax' - 如果使用了自定义中间件做跳转，务必在重定向前检查
$request->isAjax()或$request->header('accept') === 'application/json'，API 接口不应重定向，应返回 JSON 提示
排查 HSTS 和浏览器缓存干扰
有时页面看似“从 HTTPS 跳回 HTTP”，实则是浏览器强制升级机制在作祟——比如 HSTS 策略未清除，或 Chrome 的 Automatic HTTPS 功能介入。
- 访问
chrome://net-internals/#hsts，删除对应域名的 HSTS 记录 - 检查响应头是否误加了
Strict-Transport-Security: max-age=31536000; includeSubDomains，调试期建议临时设为max-age=0 - 关闭 Chrome 地址栏右侧的“闪电图标”（Automatic HTTPS），排除客户端强制干预
