Problem with proxy cache misses

CJ Ess zxcvbn4038 at gmail.com
Mon Feb 29 20:20:22 UTC 2016


Yes, it does exist:

stat /var/www/test_cache

  File: `/var/www/test_cache'
  Size: 4096            Blocks: 8          IO Block: 4096   directory
Device: 802h/2050d      Inode: 22195081    Links: 2
Access: (0700/drwx------)  Uid: (  497/   nginx)   Gid: (    0/    root)
Access: 2016-02-29 15:14:19.271701729 -0500
Modify: 2016-02-29 15:14:15.894687178 -0500
Change: 2016-02-29 15:14:15.894687178 -0500

I did an su to nginx and touched a file in the directory and removed it
without issue. I did an nginx reload and I didn't see any warnings or
errors regarding permissions in the error log.



On Mon, Feb 29, 2016 at 2:15 PM, Payam Chychi <pchychi at gmail.com> wrote:

> Look at your proxy cache path... (proxy_cache_path /var/www/test_cache)
> Are you sure the path exists and had proper perms/ownership?
>
> Payam
>
>
> On Feb 29, 2016, 11:03 AM -0800, CJ Ess <zxcvbn4038 at gmail.com>, wrote:
>
> Hello! I'm testing out a new configuration and there are two issues with
> the proxy cacheing feature I'm getting stuck on.
>
> 1) Everything is a cache miss, and I'm not sure why:
>
> My cache config (anonymized):
>
> ...
> proxy_cache_path /var/www/test_cache levels=2:2 keys_zone=TEST:32m
> inactive=365d max_size=16g loader_files=256;
> ...
>   upstream haproxy {
>     server 127.0.0.1:8080;
>     keepalive 256;
>   }
> ...
>     location ~ "^/[W][A-Za-z0-9_-]{7,13}$" {
>       limit_except GET {
>         deny  all;
>       }
>       proxy_http_version 1.1;
>       proxy_set_header Connection "Close"; # Disable Keepalives
>       proxy_set_header Host "www.testhost.com"; # Upstream requires this
> value
>       proxy_set_header X-Real-IP $remote_addr;
>       proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
>       proxy_set_header X-Forwarded-Proto https;
>       proxy_cache TEST;
>       proxy_cache_key $uri;
>       proxy_cache_valid 301 365d;
>       proxy_cache_valid 302 1d;
>       proxy_cache_lock on;
>       proxy_buffering off;
>       proxy_pass http://haproxy;
>     }
> ...
>
> A sample response coming back from the upstream (captured with wireshark)
>
> HTTP/1.1 301 Moved Permanently
> Date: Mon, 29 Feb 2016 18:16:02 GMT
> Content-Type: text/html
> Transfer-Encoding: chunked
> Connection: close
> P3P: CP="some text"
> X-Frame-Options: deny
> Location: http://some.test.url/
>
> 0
>
> The cache directory is owned by the nginx user, perms 0700.
>
> 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.
>
> 2) For each URL which doesn't match any of the location blocks, I am
> seeing an error in the log file:
>
> 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:test.com, request: "HEAD /W4ud7y1k4jjbj
> HTTP/1.1", host: "test.com"
>
> There is a "root /var/www/html" defined in the http block, although there
> is only one specific location which uses it:
>
>     location = /apple-app-site-association {
>       default_type application/pkcs7-mime;
>       break;
>     }
>
> And the final location block in my server config is:
>
>     location = / {
>       rewrite ^ https://www.someother.test.com/ permanent;
>       break;
>     }
>
> 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?
>
>
>
>
>
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
>
>
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20160229/16cb3d1c/attachment.html>


More information about the nginx mailing list