Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm working with nginx 1.4.4 running on Ubuntu 12.04.4.
nginx is reverse-proxing a cluster of Rails application servers.

Static files (mostly assets) are served directly, without hitting the application servers.
I've set it up to gzip responses and to use pre-compressed files when available.

http {
  gzip on;
  gzip_http_version 1.0;
  gzip_proxied any;
  # other ngx_http_gzip_module directives...

  server {
    # proxy configuration

    location ^~ /assets/ {
      gzip_static on;
      expires max;
      add_header Cache-Control public;
      # root is inherited
      try_files $uri =404;
      error_page 404 /404.html;

This works.
I've tested it using a real pre-gzipped asset and a dummy non-compressed asset with the same name but different content:

/assets/application-a45d6...e2593.css         # dummy content
/assets/application-a45d6...e2593.css.gz      # real CSS

I could see that toggling gzip_static on and off would cause nginx to correctly serve the expected version of the file.
So far, so good.

However, this setup only works if the non-compressed version of the file is also present. Having only the pre-compressed version will cause a 404.

The documentation says:

With the “always” value (1.3.6), gzipped file is used in all cases, without checking if the client supports it. It is useful if there are no uncompressed files on the disk anyway or the ngx_http_gunzip_module is used.

(yes: I've tried both on and always, and I've also tried to add gunzip on. Nothing changed)

It seems to suggest that having only the compressed versions of the files is ok. Is this really the case? Is there anything wrong in my configuration?

share|improve this question
up vote 2 down vote accepted

It's possible that you've found a bug. But in general you want both files anyway, for three reasons:

  1. A few clients won't request compressed data, and if you force it on them with gzip_static always; they might not understand it.
  2. To ensure that the file is always found, and the request isn't passed upstream to Rails or being caught by the 404 handler (the possible bug). One of which is probably what's happening.
  3. Having nginx compress or uncompress the file at runtime means it must do so repeatedly, eating up valuable CPU that could be used to run your application. It's much less CPU intensive to simply send a static resource.
share|improve this answer
Thanks. Yes, the request is being caught by the handler. I'm pretty sure because when I replaced the try_files directive with try_files $uri @named_proxy_loc; the request was sent to Rails. – tompave Feb 3 '14 at 2:15
Also, yes, I'm aware of the advantages, and I am indeed happy to have both versions of the assets on the server. I was just wondering if my configuration is ok or if I'm missing something. – tompave Feb 3 '14 at 2:15
As long as you have gzip_static on; and not always, and have both versions of the file, you should be fine. – Michael Hampton Feb 3 '14 at 2:16
Ok, thank you. It's working like a charm. – tompave Feb 5 '14 at 19:23
try_files works before gzip_static therefore it looks for uncompressed file. – Alexey Ten Jul 11 '14 at 4:56

Uncompressed files are not required on Nginx 1.6 with:

    location ~ \.txt$ {
        gzip_static on;
        gunzip on;

Both curl http://localhost/index.txt and curl -H "Accept-Encoding: gzip" http://localhost/index.txt | gunzip now work fine with just /srv/www/localhost/index.txt.gz in my root directory.

share|improve this answer
The gunzip directive is relatively new. And it had some bugs prior to the 1.6 stable release. Anyway, if you have the extra CPU to spend on it, go ahead, but it will almost always be faster to have the resource already (un)compressed and available to sendfile() immediately. – Michael Hampton Jul 10 '14 at 23:28

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.