原来浏览器不但缓存文件，还会缓存重定向。
原来我有一个域名用到了重定向，现在我放开了重定向。
重启ngnix，竟然不起做用，还是跑到了原来重定向的网站。
我把nginx配置删除以后，仍然跑到了原来的网站。
百思不得其解，等我再三检查，依然没有发现啥问题。
我在域名后方加了?，添加了任何其他参数，嘿，变过来了。
这么看来有可能就是浏览器给缓存了重定向了。
whatever，不知道到底是不是浏览器给重定向的，不去纠结，不是服务器，就是浏览器给重定向了，总有一个。
后来查看你可以参考下面的。
这几天开发中遇到一个怪事，一个按钮（超链接）不知道怎么回事就不能用了，跟了代码，发现超链接中的参数没有传到server上来，百思不得其解，想尽了各种方法，都没解决。你说你感到万分沮丧，甚至开始怀疑server。
后来用抓包工具查看了浏览器发出的请求，发现发出请求时就没有了连接中的get参数，看来还是浏览器的问题，尝试不同浏览器，chrome和safari都不行，firefox居然没问题。为什么不尝试ie？我才不在乎ie行不行呢！
再仔细深入重现问题的操作序列，发现了其中有一个重定向！忽然想起了当年peter同学在技术交流上介绍301和302的区别，这真如一道黎明的曙光闪现！没错，w3c标准，301为永久重定向，应该被缓存。查看代码，Django的redict函数，默认发出的是301！这样，看似“见鬼”的问题解决了。其实是因为重定向到了不带参数的url，使得问题看起来好像是参数丢失了，让我们误入歧途。
总结，重定向分为301永久重定向和302临时重定向，对于301来说，浏览器可以缓存重定向的结果，当下次请求未定向的连接时，改为直接请求重定向后的结果。这也是为什么在浏览器状态栏眼睁睁的看着一个连接，点进去却是另外一个。那我们的问题在firefox中没有发生？从这点上，看来firefox还不够“标准”哈。