我有一个奇怪的问题(到目前为止)仅在 Firefox 中出现，它会将 URL 重写到不同的域(也由我们托管)。然而，重写不会发生在 Safari 或 Chrome 中(我在 MacBook Pro 上进行测试)。
我的设置是这样的:运行 HAProxy 的负载均衡器在 80 和内部 8080 上监听，Apache 在 443 上监听。80 上的流量被传递到后端，来自 Apache 的流量被 SSL 解密，然后发送到 localhost:8080，然后传递到后端的端口 8443。在后端，来自 80 的任何流量都被视为非 SSL，但在 8443 上被视为解密的 SSL。后端服务器运行 Apache。
如果我去https://www.sslexample.com/ (此后称为 SSL_DOMAIN)来自 SSL 站点上的任何浏览器，一切都按应有的方式运行。它命中 Apache SSL 加速器，被解密，传递给代理，然后发送到后端。如果我去http://www.nonsslexample.com/ (此后称为 NONSSL_DOMAIN)，对于非 SSL 站点，一切都按预期运行，它先访问代理，然后访问后端，然后按预期提供非 SSL 流量。
这就是事情变得奇怪的地方。如果我通过 http 转到 SSL_DOMAIN，应该发生的是我被重定向到 https。对于我们的混合 SSL/非 SSL 域之一，这在所有浏览器中都按预期工作。但是在 Firefox 上(有时我的同事在 Safari 上，从来没有在 Chrome 上)如果我通过 http 转到 SSL_DOMAIN，首先发生的事情是 URL 立即被重写为 NONSSL_DOMAIN，我被重定向到完全不同的域。
嗯？
查看 LB 上的日志，Chrome 和 Safari 表现正常——在端口 80 上命中 lb——但 Firefox 从未在端口 80 上使用 SSL_DOMAIN 命中负载均衡器。但是 LB 看到它的时间，它是已经被重写了。
我在 Firefox 上安装了 Tamper Data 插件，结果让我更加困惑。初始正确的 URL header 永远不会收到回复 header 。它立即被错误的替换。事情继续进行，就好像我有意使用非 SSL URL。
我查看了我的/etc/hosts 文件(因为这是在测试中，我们正在覆盖这些域)，一切看起来都是正确的。
如果您以前遇到过这样的问题，我将非常感谢您提供有关如何调试它的提示。
最佳答案
regilero 是对的。
我刚刚在 Mac OS X 10.9.1 上使用 Firefox 和 Safari 时遇到了同样的问题。它们似乎都缓存了 301 重定向并在下一次请求时在内部重写到曾经重定向过的 URL。
这很有趣，尤其是当您尝试在您的网络服务器配置中编写和测试重定向时。
我的解决方案是清空浏览器缓存。然后重定向将从服务器再次读取。每次我想再次读取重定向时，我都必须这样做。
关于apache - firefox url 重写神秘，但不是其他浏览器，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/11752491/