On 21/04/2014 6:56 p.m., Timur Irmatov wrote: > After adding debug_options ALL,2 I see following in cache.log (attached): > > 2014/04/21 11:46:03.940 kid1| http.cc(750) processReplyHeader: HTTP > Server REPLY: > --------- > HTTP/1.1 200 OK > Server: nginx > Date: Mon, 21 Apr 2014 06:43:03 GMT > Content-Type: application/octet-stream > Last-Modified: Fri, 04 Apr 2014 14:34:09 GMT > Accept-Ranges: bytes > Content-Length: 6779936 > Connection: Keep-Alive > Age: 180 > > MZ<90> > ---------- > 2014/04/21 11:46:03.940 kid1| ctx: exit level 0 > 2014/04/21 11:46:03.940 kid1| store.cc(1011) checkCachable: > StoreEntry::checkCachable: NO: not cachable > > So Squid considers servers reply uncacheable. Why? > Something (unknown) has marked it to be discarded before it finished arriving. There is no sign of the store lookup logics looking up an existing entry either. And ALL,6 trace (very big) will probaly be needed for that one. There are two other obvious things to check. The first is that this request is arriving on the tproxy port and the domain name appears to be using different IPs in geographic based responses. Is the Squid box getting the same 217.69.139.110 destination as the client was contacting? debug option 78,3 The second is the storeid helper. What is its output? debug option 84,9 Amos
