Nginx – the best way to compress backend to nginx reverse proxy data

compressiongzipnginxreverse-proxy

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.

UPDATE 1:

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.

Best Answer

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";

Related Solutions

Nginx – How to Set Up as a Caching Reverse Proxy

I don't think that there is a way to explicitly invalidate cached items, but here is an example of how to do the rest. Update: As mentioned by Piotr in another answer, there is a cache purge module that you can use. You can also force a refresh of a cached item using nginx's proxy_cache_bypass - see Cherian's answer for more information.

In this configuration, items that aren't cached will be retrieved from example.net and stored. The cached versions will be served up to future clients until they are no longer valid (60 minutes).

Your Cache-Control and Expires HTTP headers will be honored, so if you want to explicitly set an expiration date, you can do that by setting the correct headers in whatever you are proxying to.

There are lots of parameters that you can tune - see the nginx Proxy module documentation for more information about all of this including details on the meaning of the different settings/parameters: http://nginx.org/r/proxy_cache_path

http {
  proxy_cache_path  /var/www/cache levels=1:2 keys_zone=my-cache:8m max_size=1000m inactive=600m;
  proxy_temp_path /var/www/cache/tmp; 


  server {
    location / {
      proxy_pass http://example.net;
      proxy_cache my-cache;
      proxy_cache_valid  200 302  60m;
      proxy_cache_valid  404      1m;
    }
  }
}

Nginx – the best nginx compression gzip level

The level of gzip compression simply determines how compressed the data is on a scale from 1-9, where 9 is the most compressed. The trade-off is that the most compressed data usually requires the most work to compress/decompress, so if you have it set fairly high on a high-volume website, you may feel its effect.

It sounds like your issues are more related to the HTTP headers on the requests. Usually gzip-compressed HTTP traffic is accompanied by the Content-Encoding: gzip header. If this is being dropped somewhere, then the client might not know to have to decompress the response.

Related Topic