你的 Magento 重定向循环多半不是 VPN 的问题

访问日志里出现 302，店面经 VPN 打不开，结论便自己写好了。这个结论通常错得很有意思。重定向响应记录的只是浏览器被要求前往的去向，完全没有说明问题来自隧道、证书还是应用本身。日志那一行是排查的起点，不是结论。

302 说明去哪，不说明为什么

访问日志条目只记请求、状态码和大小，往往漏掉真正关键的 Location 头。单次重定向可能完全正常：规范主机名、补全尾部斜杠、切换到 HTTPS。你需要的是整条序列，因为一次跳转和一次循环是两种故障，责任方也不同。在不同 scheme 之间反复跳转，指向的是 URL 与 scheme 的处理。而跳到浏览器无法解析的域名，指向的就是完全另一处问题了。

这两者都不是关于 VPN 的证据。隧道是一条路径；重定向是应用写下的指令。

记录链条，而不是那一行日志

用浏览器的网络面板，为每一次跳转记录四个字段：请求的 URL、状态码、Location 头和时间。记录要以最终响应或连接错误收尾，因为真正值得看的是那次永远走不完的跳转。在正常路径和故障路径上各做一次，使用同一账号、同一条操作路径。对比两条链条，比日志里任何单独一行都有价值。

这份记录要当作隐私对待。URL 里带着会话标识，保存下来的浏览器归档包含的东西比你想象的多。贴进工单之前先去掉查询串。

应用对自身 URL 的认知

Magento 从配置里生成绝对 URL，并按网站或商店视图划分作用域。bin/magento config:show web/secure/base_url 打印的是应用所相信的值，而它往往是某次构建或迁移遗留的主机名，而不是浏览器实际使用的那一个。如果那里写的是内网主机，浏览器就被送往它到不了的地方，改隧道是修不好的。

把安全与非安全的基础 URL 同你眼前的公开域名逐项对比。任何一处不一致，都会产生你正在盯着的那次重定向。

可信代理头是一份契约

当 TLS 在负载均衡处终止时，应用看到的是明文 HTTP，必须被明确告知实情。offloader 头设置指定代理会写入的那个头名，例如转发协议，应用在判断 scheme 时依赖它。

这份信任只对某一个代理成立，不是通用授权。接受任意客户端发来的该头，就等于谁都能声称自己用的是某个 scheme，所以它只应出现在指定代理写入的地方。如果头名与代理行为不一致，应用就会生成指向浏览器从未使用过的 scheme 的重定向，循环由此闭合。把代理配置与应用设置放在一起核对，然后刷新配置缓存，让改动生效。

当循环来自会话而不是路由

总是回到登录页的链条，通常是 cookie 问题。要检查会话 cookie 是否签发给了浏览器实际使用的主机名，以及它在浏览器认为安全的连接上是否被标记为 secure。把 cookie 绑定到错误域，会造出一个看起来与路由故障一模一样的登录循环。

把已证实的错配修在它真正的责任方那里，无论是基础 URL、cookie 域还是代理契约，然后重测整条访问路径，而不是盯着某一个 302 消失。为了打断循环而关掉 HTTPS 要求，是用一个更糟的问题换一次重定向。改完之后要单独验证隧道：请求一个已知的内网资源，确认能够到达，这样下一次重定向才有干净的对照基准。