在我们的应用程序的配置中，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_size为 0 - 基本上禁用大型响应的缓冲。这将停止对文件的缓冲 - 但这也意味着对于生成大型响应的端点（例如，创建 1-2MB 响应的 PDF 生成端点），消耗缓慢的客户端将使相应的 gunicorn 工作者停滞不前……事实上，如果有 N 个 gunicorn 工作者，则只需要 N 个客户端在慢速网络连接后生成 PDF，我们的应用程序就会瘫痪……我可以将其增加到
proxy_buffer_size4K 以上（即一个内存页面）。我非常确定这会对 nginx 性能产生严重影响 - 70% 的响应确实适合 4K，并且我们会强制 nginx 分配...什么？为每个响应分配 2MB 的缓冲区，只是为了应对偶尔的 PDF 生成请求？ 编辑：事实上这根本不是一个选择——迈克尔（如下）评论说唯一允许的值是 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、stream、server 和 location 级别指定，并覆盖从更高级别继承的设置。
关于缓冲的那行处于警告级别：
[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。