nginx proxy_pass and proxy_cache

Francis Daly francis at
Thu Nov 11 08:54:21 UTC 2021

On Wed, Nov 10, 2021 at 08:58:54PM +0200, Reinis Rozitis wrote:

Hi there,

> > And I can't make a location block for a mimetype, or using another specifier than regexes to filter out requests to certain 'file types'. Is there any other 'good' solution except for, on my origin adding rewrites from /something/data1/ to /data1/?

Assuming that other proxy criteria are the same, I think that the "map"
suggestion with a variable for proxy_cache will be the simplest.

But if you have reasons to want more explicit config:

> Why just not separate the locations rather make them nested?
> Something like:
> location /something/ {
>   proxy_cache disk_cache;
>   proxy_pass   http://origin/data1/;
> }
> location ~* ^/something/.*\.xml$ {
>        proxy_cache fast_disk_cache;
>        proxy_pass   http://origin/data1/;
> }

I think that that one would fail for the same reason as the initial
attempt: proxy_pass-with-URI and regex location do not go well together. :

In some cases, the part of a request URI to be replaced cannot be determined:

lists three cases, and this is case#1.

As it happens, you *can* do it if you take advantage of case#3.

	location ~* ^/something/(.*\.xml)$ {
		proxy_cache fast_disk_cache;
		proxy_pass http://origin/data1/$1;

(although you probably want to capture to a named variable, instead of
hoping that $1 has not changed by the time proxy_pass uses it -- see and choose
the syntax that your version uses. Probably (?<this_bit>.*\.xml), and
then use $this_bit.)

You could possibly also take advantage of case#2, and do

	rewrite /something/(.*\.xml)$ /$1 break;

but that feels a bit too subtle to me.

Note that the regex-matching attempts may not do what you want if you
have %-encodings in the incoming requests -- test your use cases to see
that things work for you.

Or just use the map.

Good luck with it,

Francis Daly        francis at

More information about the nginx mailing list