Nginx 1.9.12 proxy_cache always returns MISS

Been playing with this for 2 days.

proxy_pass is working correctly but the proxy_cache_path remains empty
whatever I make.

Here’s the source I use for tests:
root@NC-PH-0657-10:/etc/nginx/snippets# curl -X GET -I
http://www.kuriyama-truck.com/images/parts/13375/thumbnail_0/1_1.jpg
HTTP/1.1 200 OK
Date: Sat, 19 Mar 2016 18:15:16 GMT
Server: Apache/2.4.16 (Amazon) PHP/5.6.17
Last-Modified: Thu, 10 Mar 2016 05:01:30 GMT
ETag: “d0f3-52daab51fbe80”
Accept-Ranges: bytes
Content-Length: 53491
Content-Type: image/jpeg

Now here’s the response from the nginx:
root@NC-PH-0657-10:/etc/nginx/snippets# curl -X GET -I
http://dev.ts-export.com/kuriyamacache/images/parts/13375/thumbnail_0/1_1.jpg
HTTP/1.1 200 OK
Server: nginx
Date: Sat, 19 Mar 2016 18:14:46 GMT
Content-Type: image/jpeg
Content-Length: 53491
Connection: keep-alive
Expires: Sun, 19 Mar 2017 18:14:46 GMT
Cache-Control: max-age=31536000
Cache-Control: public
X-Cache-Status: MISS
Accept-Ranges: bytes

Here are the request headers from my browser:
GET /kuriyamacache/images/parts/13375/thumbnail_1/1_1.jpg HTTP/1.1
Host: dev.ts-export.com
Connection: keep-alive
Cache-Control: max-age=0
Accept:
text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,/;q=0.8
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36
(KHTML,
like Gecko) Chrome/49.0.2623.87 Safari/537.36
DNT: 1
Accept-Encoding: gzip, deflate, sdch
Accept-Language: fr-CA,fr;q=0.8,en-US;q=0.6,en;q=0.4,ja;q=0.2,de;q=0.2
Cookie: PRUM_EPISODES=s=1458412951203

Part of my setup:

proxy_cache_path /tmp/nginx/dev levels=1:2 keys_zone=my_zone:10m
max_size=10g inactive=60m use_temp_path=off;

server {

set $rule_3 0;
set $rule_4 0;
set $rule_5 0;
set $rule_8 0;
set $rule_9 0;

server_name dev.ts-export.com;
listen 80;
listen [::]:80;

root /home/tsuchi/public_html;

if ($reject_those_args) {
return 403;
}

include snippets/filters.conf;

error_page 404 /404.html;

if ($request_uri ~ “^/index.(php|html?)$” ) {
return 301 $scheme://dev.ts-export.com;
}

no SSL for IE6-8 on XP and Android 2.3

if ($scheme = https) {
set $rule_8 1$rule_8;
}
if ($http_user_agent ~ “MSIE (6|7|8).*Windows NT 5|Android 2.3”){
set $rule_8 2$rule_8;
}
if ($rule_8 = “210”){
return 301 http://dev.ts-export.com$request_uri;
}

location = / {
allow all;
}

location = /robots.txt {
add_header X-Robots-Tag noindex;
}

location ‘/.well-known/acme-challenge’ {
default_type “text/plain”;
root /tmp/letsencrypt-auto;
}

include snippets/proxyimg.conf;

location / {
try_files $uri $uri/ @rewrites;
allow all;
}
(…)
}

Contents of proxyimg.conf:

location ^~ /kuriyamacache {
expires 1y;
access_log off;
log_not_found off;
resolver 127.0.0.1;

proxy_pass http://www.kuriyama-truck.com/;

proxy_cache my_zone;
proxy_cache_key "$scheme$request_method$host$request_uri";
proxy_buffering on;

proxy_cache_valid  200 301 302  60m;
proxy_cache_valid  404      1m;
proxy_cache_use_stale error timeout http_500 http_502 http_503

http_504;
proxy_cache_revalidate on;
proxy_cache_lock on;

proxy_set_header Host $host;
proxy_set_header   X-Real-IP        $remote_addr;
proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;

proxy_ignore_headers X-Accel-Redirect X-Accel-Expires 

X-Accel-Limit-Rate
X-Accel-Buffering X-Accel-Charset Set-Cookie Cache-Control Vary Expires;

proxy_pass_header ETag;
proxy_hide_header Cache-Control;

add_header Cache-Control "public, max-age=31536000";
add_header X-Cache-Status $upstream_cache_status;

}

Posted at Nginx Forum:

I think I’ve run into the problem before - move the proxypass statement
from the top of the location stanza to the bottom, and I think that will
solve your issue.

Seems like it’s resolved:

$ curl -I
http://dev.ts-export.com/kuriyamacache/images/parts/13375/thumbnail_0/1_1.jpg
HTTP/1.1 200 OK
Server: nginx
Date: Sat, 19 Mar 2016 20:42:46 GMT
Content-Type: image/jpeg
Content-Length: 53491
Connection: keep-alive
Last-Modified: Thu, 10 Mar 2016 05:01:30 GMT
ETag: “d0f3-52daab51fbe80”
Expires: Sun, 19 Mar 2017 20:42:46 GMT
Cache-Control: max-age=31536000
Cache-Control: public, max-age=31536000
X-Cache-Status: MISS
Accept-Ranges: bytes

$ curl -I
http://dev.ts-export.com/kuriyamacache/images/parts/13375/thumbnail_0/1_1.jpg
HTTP/1.1 200 OK
Server: nginx
Date: Sat, 19 Mar 2016 20:42:48 GMT
Content-Type: image/jpeg
Content-Length: 53491
Connection: keep-alive
Last-Modified: Thu, 10 Mar 2016 05:01:30 GMT
ETag: “d0f3-52daab51fbe80”
Expires: Sun, 19 Mar 2017 20:42:48 GMT
Cache-Control: max-age=31536000
Cache-Control: public, max-age=31536000
X-Cache-Status: HIT
Accept-Ranges: bytes

Although you stated you problem was resolved, you need to understand
what
you are configuring/testing.

In the first message you posted, the first response URL using the cache
(starting with ‘/kuriyamacache’) did not correspond to the alleged
request
headers’ URL (‘thumbnail_0’ vs ‘thumbnail_1’), so you probably got mixed
up
in your tests.

Note that you configured cache only for path starting with
‘/kuriyamacache’, not others, which will end up being served by another
location block.
Since you add headers in the response of requests being served at the
proper location, look for their existence.

The cache will only get triggered if a requests is served by this
specific
location, if the request URI matches the cache key defined with the
proxy_cache_key directive, if the status code of the response is
cacheable,
and with the cache entry being only valid for the specified amount of
time.

I do not thing the proxy_pass directive is sensitive to order, otherwise
you would not have seen the headers added with add_header in any
response.
I encourage you to carefully re-test the configuration you provided here
and if any trouble arise, please provide a detailed step-by-step way of
reproducing the problem.

B. R.

Great! =) Make sure proxy buffering stays on - that will bypass the
cache
if turned off, and make sure your key space is large because you’ll
throw
500s for everything if it runs out (I figured it would evict a key if it
ran out of space, and what was a wrong assumption)

Yes it’s resolved.

I’ve change the cache path yesterday and a few minutes ago, I noticed
that
error message:

“2016/03/19 12:31:02 [emerg] 8984#8984: cache “my_zone” uses the
“/tmp/nginx/dev” cache path while previously it used the “/tmp/nginx”
cache
path”

It seems it was enough to prevent the cache from running. Interesting.

BTW, do you see anything useless, redundant in my config?

Thanks for the help!

Posted at Nginx Forum: