通過負載均衡器時，Nginx 不發送壓縮後的資產

我有一個 nginx 伺服器充當負載平衡器，它將請求委託給其他應用程序伺服器。

當我嘗試直接向應用程序伺服器請求資產時，該資產以 gzip 壓縮版本提供，範例：

➜ ~ curl -IH 'Accept-Encoding: gzip, deflate' http://application/asset.css HTTP/1.1 200 OK Server: nginx/1.6.2 Date: Thu, 15 Sep 2016 14:13:03 GMT Content-Type: text/css Content-Length: 35038 Connection: keep-alive Content-Encoding: gzip Expires: Thu, 31 Dec 2037 23:55:55 GMT Cache-Control: max-age=315360000 Cache-Control: public

而對負載均衡器的相同請求，則返回資產的非壓縮版本。 ➜ ~ curl -IH 'Accept-Encoding: gzip, deflate' https://load-balancer/asset.css HTTP/1.1 200 OK Server: nginx/1.6.2 Date: Thu, 15 Sep 2016 14:16:15 GMT Content-Type: text/css Content-Length: 240442 Connection: keep-alive Expires: Thu, 31 Dec 2037 23:55:55 GMT Cache-Control: max-age=315360000 Cache-Control: public Accept-Ranges: bytes

這是我對 LB 的配置： location / { client_max_body_size 10M; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header Host $http_host; proxy_set_header X-Forwarded-Proto https; # if use ssl proxy_redirect off; proxy_pass http://application; }

提前致謝

解決了！

我自己發現從負載均衡器發送到上游（應用程序伺服器）的請求是在 HTTP/1.0 中完成的，而應用程序端的 nginx 伺服器只在請求在 HTTP >= 1.1 時壓縮文件，由於預設參數。

http://nginx.org/en/docs/http/ngx_http_gzip_module.html#gzip_http_version

還有另一種方法可以解決這個問題。您可以為上游代理連接設置更高的 HTTP 協議版本。可以通過這個參數來完成：proxy_http_version 1.1;

這將是一個更好的選擇，因為這樣您可以從 HTTP/1.1 的許多優點中受益，例如持久連接和額外的新狀態程式碼。

例如這是我自己的設置塊：

server {
   listen       80;
   server_name  domain.tld;
   location / {
        include proxy_params;
        proxy_http_version 1.1;
        proxy_pass http://my-up-stream;
   }
}

http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_http_version

引用自：https://serverfault.com/questions/803304