將後端壓縮到 nginx 反向代理數據的最佳方法是什麼？

我們將執行一個 nginx 反向代理，它將通過網際網路從後端提取數據。

我們通過網際網路的意思是後端機器不會在具有前置反向代理的區域網路上。

我們認為在通過 Internet 發送這些請求之前處理這些請求會很好。

我看到它的方式應該是這樣的：

客戶端請求帶有接受編碼標頭或 gzip 的內容。

反向代理將此發送到後端伺服器。

後端壓縮此內容，因為已發送 gzip 的接受編碼標頭。

請求一路向上發送壓縮鏈。

我們都可以這樣做，因為它非常簡單。我的問題是，如果我們在 nginx 反向代理端啟用了 gzip 壓縮，這將如何工作？

nginx 會嘗試壓縮已經壓縮過的內容嗎？

希望這是有道理的。謝謝你。

更新 1：

我了解記憶體已經（以及此服務）gzip 壓縮內容的含義。我們將修改記憶體鍵以包含接受編碼標頭，從而根據使用者代理可以接受的內容提供（並記憶體）正確壓縮/未壓縮的內容。

不，在反向代理和後端伺服器上設置 gzip 沒有問題。至少我從來沒有遇到過任何問題。代理將辨識已經壓縮過的內容並簡單地傳遞它。

如果您想從後端壓縮任何內容，只需添加適當的標題。

proxy_set_header Accept-Encoding "gzip";

1. http://nginx.org/en/docs/http/ngx_http_gzip_module.html#gzip_http_version - gzip 在後端壓縮響應所需的 HTTP 請求版本預設為 1.1。
2. http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_http_version - 代理模組預設使用的HTTP請求版本為1.0

這意味著預設情況下，當代理從後端請求它時，您的瀏覽器 GET 1.1 請求會將其自身轉換為 GET 1.0 請求。後端需要 1.1 進行 gzip 壓縮，所以不壓縮響應。

我的建議是proxy_http_version 1.1;在反向代理上使用，以及gzip on;後端伺服器中的標準等設置。

還有兩個額外的東西可以優化這個。一個是“gzip_static”（一個額外的模組）的設置。當向“index.html”發出請求時，此設置會查找並提供“index.html.gz”文件（如果存在）。這對 CPU 使用率有積極影響，因為壓縮不是即時執行的。

至於您問題的另一部分，實際壓縮的內容是使用 gzip_types 選項設置的。預設情況下，只有 text/html 被壓縮。如果您有 gzip 文件，則應小心排除它們。如果您使用*選項（壓縮所有內容），然後壓縮文件也將在發送前用 gzip 壓縮。這對於大多數圖像（jpg、png、gif）來說並不是最優的，因為它們已經實現了某種 LZW 壓縮層。因此，壓縮壓縮文件只會導致大小的小幅減少甚至增加，同時會使用大量 CPU 資源來執行壓縮。您應該根據請求的頻率和請求的內容類型（或壓縮比）仔細檢查要壓縮的內容。在圖像方面，使用額外的工具（optipng 等）對其進行優化比打開 gzip 壓縮更有效。

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