在我們應用程式的配置中，nginx 充當gunicorn.
一般來說，我們的應用程式會使用較小的回應來回覆前端請求…但某些端點會產生大於一頁記憶體頁 (4K) 的回應。
發生這種情況時，nginx 會記錄以下警告：
an upstream response is buffered to a temporary file
/path/to/nginx/proxy_temp/4/86/0000000864 while reading upstream,
client: 1.2.3.4, server: api.ourdomain.com, request: "GET /pdf/..."
我們的 nginx 日誌最終充斥著這個警告 - 據我所知，讓這個警告從我們的日誌中消失的唯一解決方案是糟糕的解決方案：
我可以將 nginx 設為
proxy_max_temp_file_size0 - 基本上禁用大型響應的緩衝。這將停止對檔案的緩衝- 但這也意味著對於產生大型回應的端點（例如，建立1-2MB 回應的PDF 產生端點），緩慢消耗的客戶端將停止相應的Gunicorn 工作程序..... .事實上，如果有是 N 個 Gunicorn 工作人員，只需要 N 個客戶端在慢速網絡連接下生成 PDF，我們的應用程序就會崩潰......我可以將其增加到
proxy_buffer_size4K 以上（即一個內存頁）。我非常確定這會對 nginx 性能產生嚴重影響 - 我們的 70% 的響應確實適合 4K，並且我們將強制 nginx 分配......什麼？每一個都有 2MB 的緩衝區，只是為了偶爾的 PDF 產生請求做好準備？ 編輯：事實上這根本不是一個選項 - Michael（下）評論說唯一允許的值是 4K 和 8K。我可以關閉
proxy_buffering- 但這和第一個解決方案一樣糟糕（緩慢的客戶端 => 死亡）。
本質上，nginx 會淹沒我們的日誌，記錄我們想要的東西——當響應很大時暫時緩衝到檔案。
我們只是想阻止它淹沒我們的日誌，通過“標記”它不是真正的警告（我什至不確定為什麼這是一個警告 - 它警告我們什麼“壞事”？）
除了編輯nginx原始碼並重新編譯之外，我還缺少其他解決方案嗎？
答案1
這是 Nginx 的 error_log 指令的日誌等級的結果。
https://www.nginx.com/resources/admin-guide/logging-and-monitoring/
error_log logs/error.log warn;
記錄警告、錯誤暴擊、警報和緊急等級的訊息。
錯誤日誌的預設設定全域有效。若要覆寫它，請將 error_log 指令放置在主（頂級）配置上下文中。主上下文中的設定始終由其他配置等級繼承。 error_log 指令也可以在 http、流、伺服器和位置層級指定，並覆寫從更高層級繼承的設定。
關於緩衝的那行處於警告等級：
[warn] 30055#0: *1428 an upstream response is buffered to a temporary file
因此，如果您確保錯誤日誌等級未設定為警告，即保留預設值或降低它，那麼您將不會再看到該警告。以下任一解決方案都會抑制它們：
保留預設值（“錯誤”等級及以上）：
error_log logs/error.log;
一樣：
error_log logs/error.log error;
您還可以將閾值增加到超過error、最多crit、alert和emerg。