我们有以下设置：Nginx – > Varnish – > HAProxy – > App Server A / App Server B.
我们处理的大多数请求都是由HAProxy代理到App Server A.这是基于主机头值完成的。 一些主机应该被redirect到App Server B.到App Server B的stream量非常低。
大多数请求工作正常。 每隔一段时间请求应该代理到应用程序服务器B给出一个404状态代码。 这些请求显示在Nginx，Varnish和App Server A的日志中，但不是HAProxy。
请求正常工作的应用程序服务器A和B由HAProxy正确logging。
看起来Varnish重用连接到由HAProxybuild立的App Server A，阻止这些请求被重新评估并发送到适当的后端。 这是我的问题的一个似是而非的原因？ 有没有办法强制Varnish重新连接到后端，或HAProxy留在这些服务器之间？ 每种解决scheme的优点/缺点是什么？
谢谢！
编辑：
这是我的Varnish日志文件的一部分：
12 SessionClose c Connection: close 12 StatSess c 127.0.0.1 54331 0 1 1 0 0 1 652 0 0 CLI - Rd ping 0 CLI - Wr 200 PONG 1329319173 1.0 12 SessionOpen c 127.0.0.1 54334 :6081 12 ReqStart c 127.0.0.1 54334 1884874126 12 RxRequest c GET 12 RxURL c /path/to/page 12 RxProtocol c HTTP/1.0 12 RxHeader c Host: www.example.com 12 RxHeader c Connection: close 12 RxHeader c User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.7 (KHTML, like Gecko) Chrome/16.0.912.77 Safari/535.7 12 RxHeader c Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 12 RxHeader c Referer: http://www.example.com/path/to/previous/ 12 RxHeader c Accept-Encoding: gzip,deflate,sdch 12 RxHeader c Accept-Language: en-US,en;q=0.8 12 RxHeader c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3 12 RxHeader c Cookie: 71666-bl0098f964_r=0; 71666-bl0098f964_s=145818062; _advocaten-cms_session=BAh7BjoPc2Vzc2lvbl9pZCIlMmRhNGFhMWY3MDRlMzljNGRkZTQ0MTI3MjJhN2E2NzY%3D--5d089ff2c72e4ad91d415cb14020834387c2077e; 71666-bl0098f964_i=272; 71666-bl0098f964_vt=1329319215438 12 VCL_call c recv 12 VCL_return c pass 12 VCL_call c hash 12 VCL_return c hash 12 VCL_call c pass 12 VCL_return c pass 12 Backend c 14 default default 14 TxRequest b GET 14 TxURL b /path/to/page/ 14 TxProtocol b HTTP/1.0 14 TxHeader b Host: www.example.com 14 TxHeader b User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.7 (KHTML, like Gecko) Chrome/16.0.912.77 Safari/535.7 14 TxHeader b Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 14 TxHeader b Referer: http://www.example.com/path/to/previous/ 14 TxHeader b Accept-Encoding: gzip,deflate,sdch 14 TxHeader b Accept-Language: en-US,en;q=0.8 14 TxHeader b Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3 14 TxHeader b Cookie: 71666-bl0098f964_r=0; 71666-bl0098f964_s=145818062; _advocaten-cms_session=BAh7BjoPc2Vzc2lvbl9pZCIlMmRhNGFhMWY3MDRlMzljNGRkZTQ0MTI3MjJhN2E2NzY%3D--5d089ff2c72e4ad91d415cb14020834387c2077e; 71666-bl0098f964_i=272; 71666-bl0098f964_vt=1329319215438 14 TxHeader b X-Forwarded-For: 127.0.0.1 14 TxHeader b X-Varnish: 1884874126 14 RxProtocol b HTTP/1.1 14 RxStatus b 404 14 RxResponse b Not Found 14 RxHeader b Date: Wed, 15 Feb 2012 15:20:06 GMT 14 RxHeader b Server: Apache 14 RxHeader b Vary: Accept-Encoding 14 RxHeader b Content-Encoding: gzip 14 RxHeader b Content-Length: 243 14 RxHeader b Connection: close 14 RxHeader b Content-Type: text/html; charset=iso-8859-1 12 TTL c 1884874126 RFC 120 1329319174 0 0 0 0 12 VCL_call c fetch 12 VCL_return c pass 12 ObjProtocol c HTTP/1.1 12 ObjStatus c 404 12 ObjResponse c Not Found 12 ObjHeader c Date: Wed, 15 Feb 2012 15:20:06 GMT 12 ObjHeader c Server: Apache 12 ObjHeader c Vary: Accept-Encoding 12 ObjHeader c Content-Encoding: gzip 12 ObjHeader c Content-Type: text/html; charset=iso-8859-1 14 Length b 243 14 BackendClose b default 12 VCL_call c deliver 12 VCL_return c deliver 12 TxProtocol c HTTP/1.1 12 TxStatus c 404 12 TxResponse c Not Found 12 TxHeader c Server: Apache 12 TxHeader c Vary: Accept-Encoding 12 TxHeader c Content-Encoding: gzip 12 TxHeader c Content-Type: text/html; charset=iso-8859-1 12 TxHeader c Content-Length: 243 12 TxHeader c Date: Wed, 15 Feb 2012 15:19:34 GMT 12 TxHeader c X-Varnish: 1884874126 12 TxHeader c Age: 0 12 TxHeader c Via: 1.1 varnish 12 TxHeader c Connection: close 12 Length c 243 12 ReqEnd c 1884874126 1329319174.638826609 1329319174.639825106 0.000061750 0.000943899 0.000054598 12 SessionClose c Connection: close 12 StatSess c 127.0.0.1 54334 0 1 1 0 1 1 260 243 0 CLI - Rd ping 0 CLI - Wr 200 PONG 1329319176 1.0 HAProxy是默认的后端。
这也可能与HAProxy不logging同一会话的后续请求有关吗？ 我假设自HAProxy没有login他们，他们没有通过它，但根据文件这是有意的行为。 由于Varnish就HAProxy而言是客户端，因此多个请求（来自多个访问者）可以属于同一个会话？
编辑2：看来，如果我添加
option forceclose option http-pretend-keepalive
到我的HAProxyconfiguration问题消失或变得不那么频繁。 这感觉就像是一个解决Varnish / HAProxy交互的更深层次的问题。 清漆收到一个Connection: Close标题，但没有在后端请求中指定该标题。 强制closures连接确保HAProxy评估来自Varnish的每一个请求。