我正在使用启用了gzip的nginx反向代理caching。 但是，我从Android应用程序HTTP请求到我的Rails JSON Web服务中遇到了一些问题。 看起来，当我closures反向代理caching，它工作正常，因为响应头没有gzip。 所以我觉得问题是由gzip引起的。 什么是最适合的gzip压缩级别？
gzip on; gzip_http_version 1.0; gzip_vary on; gzip_comp_level 6; gzip_proxied any; gzip_types text/plain text/css text/javascript application/javascript application/json application/x-javascript text/xml application/xml application/xml+rss; gzip压缩的级别简单地决定了数据在1-9的范围内的压缩程度，其中9是最受压缩的。 折衷的是，大多数压缩数据通常需要大部分的压缩/解压缩工作，所以如果你在大容量的网站上设置得相当高，你可能会感受到它的效果。
这听起来像你的问题更多地与请求上的HTTP头相关。 通常gzip压缩的HTTPstream量伴随着Content-Encoding: gzip头。 如果这被丢弃，那么客户端可能不知道必须解压缩响应。
我使用两个文件在nginx 1.3.9下testing了这些结果，这些结果是我得到的各个级别的结果：
text/html – phpinfo（）：
0 55.38 KiB (100.00% of original size) 1 11.22 KiB ( 20.26% of original size) 2 10.89 KiB ( 19.66% of original size) 3 10.60 KiB ( 19.14% of original size) 4 10.17 KiB ( 18.36% of original size) 5 9.79 KiB ( 17.68% of original size) 6 9.62 KiB ( 17.37% of original size) 7 9.50 KiB ( 17.15% of original size) 8 9.45 KiB ( 17.06% of original size) 9 9.44 KiB ( 17.05% of original size)
application/x-javascript – jQuery 1.8.3（未压缩）：
0 261.46 KiB (100.00% of original size) 1 95.01 KiB ( 36.34% of original size) 2 90.60 KiB ( 34.65% of original size) 3 87.16 KiB ( 33.36% of original size) 4 81.89 KiB ( 31.32% of original size) 5 79.33 KiB ( 30.34% of original size) 6 78.04 KiB ( 29.85% of original size) 7 77.85 KiB ( 29.78% of original size) 8 77.74 KiB ( 29.73% of original size) 9 77.75 KiB ( 29.74% of original size)
我不确定这是多么具有代表性，但它应该作为一个例子。 另外，我没有考虑到CPU的使用情况，但从这些结果看来，理想的压缩级别似乎在4到6之间。
此外，如果您使用gzip_static模块，则可能需要预先压缩文件（使用PHP）：
function gzip_static($path) { if ((extension_loaded('zlib') === true) && (is_file($path) === true)) { $levels = array(); $content = file_get_contents($path); foreach (range(1, 9) as $level) { $levels[$level] = strlen(gzencode($content, $level)); } if ((count($levels = array_filter($levels)) > 0) && (min($levels) < strlen($content))) { if (file_put_contents($path . '.gz', gzencode($content, array_search(min($levels), $levels)), LOCK_EX) !== false) { return touch($path . '.gz', filemtime($path), fileatime($path)); } } } return false; }
这样可以在不牺牲每个请求的CPU的情况下获得最佳压缩。
如果你真的可以腾出CPU资源，你可以使用9，但是对于大多数站点来说，2的值就足够了，因为gzip在1级之后不会减less太多的文件。
如果你有大量的网站，仍然想要完整的压缩级别，最好的办法是把你的静态内容放在Amazon S3或类似的对象存储服务上，然后上传压缩文件。
你仍然会想用nginx压缩你的html，所以最好保持这个值正常，我在那里使用5。