今天遇到一个问题，
一个静态页面xx.com/path_x1/a.html部署在xx.com静态集群【browse----->静态集群varnish------>静态集群apache】
另外一个应用又通过apache代理访问xx.com,配置如下
RewriteRule ^/$ http://xx.com/path_x1/a.html [L,P]
访问的url是 yy.com 【browse----->应用集群apache----->静态集群varnish------>静态集群apache】
运营修改了这个页面，需要立即更新，及希望能通过yy.com看到最新的，于是将 yy.com传入到我们开发的一个varnish清除工具中，结果没效果
后来将xx.com/path_x1/a.html传入也没效果，而且发现yy.com和xx.com/path_x1/a.html返回的居然是两个不同的版本
接下来看看varnish缓存基本原理
- 通常情况下varnish会根据访问的host和url作为key, 但varnish 也提供了callback即配置文件中的vcl_hash，可以定制这个key
- 除此之外还有一个陷阱就是被代理服务器的vary头，通常情况下会返回Vary:Accept-Encoding，varnish会根据浏览器传过来的这个头（Accept-Encoding）的值，为同一个url缓存不同的版本，比如不支持压缩，或者不同类型的压缩（gzip?deflate?...?）
- 可能某些被代理服务器返回的vary头是Vary:Accept-Encoding，User-Agent，那就更悲摧了，版本会更加多
我排查了varnish后端的被代理服务排除了vary这个原因，
然后同过varnishlog仔细比对通过访问yy.com和xx.com/path_x1/a.html时的日志，发现了问题
如果通过xx.com/path_x1/a.html访问，那么varnish识别的host和url分别是xx.com和/path_x1/a.html
如果通过yy.com访问，那么varnish识别的host和url分别是yy.com和/path_x1/a.html ,竟然不是我们通常认为的yy.com和/ ，显然是apache在proxy到varnish时做了变化
按照上面的情况，当然是两个不同的版本
如果要清除yy.com，需要将yy.com/path_x1/a.html传入我们清除工具即可
看来我们的清除工具需要更自智能一些，遇到外站过来的代理，在了解映射规则的前提下智能清除缓存