<div dir="ltr">Found it! The solution was in a a mailing list item from 2012. You have to turn proxy buffering on in order for the proxy cache to work. I'm caching like a champ now.<div><br></div><div>There probably ought to be a warning about that someplace, or it should be in the docs someplace.<div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 29, 2016 at 2:03 PM, CJ Ess <span dir="ltr"><<a href="mailto:zxcvbn4038@gmail.com" target="_blank">zxcvbn4038@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hello! I'm testing out a new configuration and there are two issues with the proxy cacheing feature I'm getting stuck on.<div><br></div><div>1) Everything is a cache miss, and I'm not sure why:</div><div><br></div><div>My cache config (anonymized):</div><div><br></div><div>...</div><div><div>proxy_cache_path /var/www/test_cache levels=2:2 keys_zone=TEST:32m inactive=365d max_size=16g loader_files=256;<br></div></div><div>...</div><div><div> upstream haproxy {</div><div> server <a href="http://127.0.0.1:8080" target="_blank">127.0.0.1:8080</a>;</div><div> keepalive 256;</div><div> }</div></div><div>...</div><div><div> location ~ "^/[W][A-Za-z0-9_-]{7,13}$" {</div><div> limit_except GET {</div><div> deny all;</div><div> }</div><div> proxy_http_version 1.1;</div><div> proxy_set_header Connection "Close"; # Disable Keepalives</div><div> proxy_set_header Host "<a href="http://www.testhost.com" target="_blank">www.testhost.com</a>"; # Upstream requires this value</div><div> proxy_set_header X-Real-IP $remote_addr;</div><div> proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;</div><div> proxy_set_header X-Forwarded-Proto https;</div><div> proxy_cache TEST;</div><div> proxy_cache_key $uri;</div><div> proxy_cache_valid 301 365d;</div><div> proxy_cache_valid 302 1d;</div><div> proxy_cache_lock on;</div><div> proxy_buffering off;</div><div> proxy_pass <a href="http://haproxy" target="_blank">http://haproxy</a>;</div><div> }</div></div><div>...</div><div><br></div><div>A sample response coming back from the upstream (captured with wireshark)</div><div><br></div><div><div>HTTP/1.1 301 Moved Permanently</div><div>Date: Mon, 29 Feb 2016 18:16:02 GMT</div><div>Content-Type: text/html</div><div>Transfer-Encoding: chunked</div><div>Connection: close</div><div>P3P: CP="some text"</div><div>X-Frame-Options: deny</div><div>Location: <a href="http://some.test.url/" target="_blank">http://some.test.url/</a></div><div><br></div><div>0</div></div><div><br></div><div>The cache directory is owned by the nginx user, perms 0700.</div><div><br></div><div>I'm expecting the 301 in the example above to be cached for a year, but nothing is created under /var/www/test_cache, and subsequent requests for the same resources are also cache misses.</div><div><br></div><div>2) For each URL which doesn't match any of the location blocks, I am seeing an error in the log file:</div><div><br></div><div>2016/02/29 13:55:20 [error] 19524#0: *1509121054 open() "/var/www/html/W4ud7y1k4jjbj" failed (2: No such file or directory), client: a.b.c.d, server:<a href="http://test.com" target="_blank">test.com</a>, request: "HEAD /W4ud7y1k4jjbj HTTP/1.1", host: "<a href="http://test.com" target="_blank">test.com</a>"<br></div><div><br></div><div>There is a "root /var/www/html" defined in the http block, although there is only one specific location which uses it:</div><div><br></div><div><div> location = /apple-app-site-association {</div><div> default_type application/pkcs7-mime;</div><div> break;</div><div> }</div></div><div><br></div><div>And the final location block in my server config is:</div><div><br></div><div><div> location = / {</div><div> rewrite ^ <a href="https://www.someother.test.com/" target="_blank">https://www.someother.test.com/</a> permanent;</div><div> break;</div><div> }</div></div><div><br></div><div>So my expectation is that since the request matches none of the location blocks, nginx will just issue a 404 response. However from the error log, it looks like it is trying the root directory first before issuing the 404. Is there some way to prevent that?</div><div><br></div><div><br></div><div><br></div><div><br></div><div> </div></div>
</blockquote></div><br></div></div></div>