We are going to be running a nginx reverse proxy that will pull data from a backend via the internet.

What we mean by via the internet is the backend machine will not be on a lan with the front facing reverse proxy.

We were thinking it would be nice to grip these requests prior to sending them over the internet.

The way I see it it should work something like this:

Client requests content with a accept-encoding header or gzip.

Reverse proxy sends this to the backend server.

Backend compresses this content since a accept encoding header of gzip was sent.

Request sent all the way up the chain compressed.

This we can all do as its pretty straight forward. The question I have is how will this work if we have gzip compression enabled on the nginx reverse proxy side?

Will nginx try to gzip content that is already gzipped?

Hope this makes sense. Thank you.


I understand the implications of caching already (and this serving) gzipped content. We would modify the cache key to include the accept encoding header, and thus serve (and cache) the properly compressed / uncompressed content according to what the user agent can accept.

  • I don't think this question fits the site very well. The setup you're describing is hardly complex, just try it and see if it does what you expect. If not, try and make it do what you want with a little research and config tweaking, and if you still have questions, we're here. You've done almost no research of your own. Aug 22, 2012 at 11:20
  • While I understand that the method posted above should work. I usually ask on here for clarification. Perhaps there is an automated way to have the proxy_pass module request backend content to be compressed? Perhaps there are any further gotchas that I have not though about? I think it wise to approach a problem with as much knowledge in hand as possible... Especially as our service is live, in production and fairly busy... Wouldnt want to start sending gzipped content to useragents that do not accept it. Or double gzipping content and wasting precious cycles... Aug 22, 2012 at 11:25

2 Answers 2


No, there is no problem with setting gzip on the reverse proxy and the backend server. At least I never had any issues. The proxy will recognize the already gzipped content and simply deliver it.

If you want any content to be gzipped from the backend simply add the appropriate header.

proxy_set_header Accept-Encoding "gzip";
  • 3
    We tested, and implemented gzipping on our backend. One note: proxy_set_header Accept-Encoding gzip is not recommended UNLESS you use (which we started) nginx gunzip (yes, its called gunzip) module. Other wise you will be serving gzipped content to clients which do not support compression. With gunzip module, you CAN use proxy_set_header Accept-Encoding gzip, and have nginx uncompress the content if required. Aug 26, 2012 at 21:31
  • Since there are no other answers, I will correct answer this one as its largely correct. Aug 26, 2012 at 21:36
  1. http://nginx.org/en/docs/http/ngx_http_gzip_module.html#gzip_http_version - the HTTP request version required for gzip to compress responses on the back-end is by default 1.1.

  2. http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_http_version - the HTTP request version used by default by the proxy module is 1.0

This means that by default is that your browser GET 1.1 request transforms itself into a GET 1.0 request when proxy requests it from the back-end. The back-end needs 1.1 to perform gzip compression, and so does not compress the response.

My suggestion is to use proxy_http_version 1.1; on the reverse proxy, and the standard gzip on; etc. settings in the back-end server.

There are two additional things to optimize this. One is the setting of 'gzip_static' (an extra module). When a request is made to 'index.html', this setting looks for and delivers an 'index.html.gz' file, if it exists. This has a positive impact on CPU usage, since the compression is not performed on the fly.

As for the other part of your question, what actually gets compressed is set with the gzip_types option. By default, only text/html gets compressed. If you have gzip files, you should be careful to exclude them. If you use the * option (compress everything), then also compressed files will be compressed with gzip before being sent. This isn't optimal for most images (jpg, png, gif), as they have some sort of LZW compression layer already implemented. Compressing a compressed file thus results only in small decrease or even increase of size, while using significant CPU resources to perform the compression. You should carefully examine what you want to compress based on frequency of requests and the type of content that's requested (or it's compression ratio). In terms of images, optimizing them with extra tooling (optipng, etc.) is more effective than turning on gzip compression.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .