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