在我们的应用程序configuration中，nginx在gunicorn充当反向代理。
我们的应用程序通常会回应前端请求，但响应却很less…但是有些端点产生的响应大于一个内存页面（4K）。
发生这种情况时，nginx会logging下这个警告：
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日志最终充满了这个警告 – 就我所知，使这个警告从我们的日志中消失的唯一解决scheme是不好的解决scheme ：
我可以将nginx proxy_max_temp_file_size设置为0 – 基本上禁用大型响应的缓冲。 这将停止对文件的缓冲 – 但这也意味着对于产生大量响应的端点（例如，生成1到2MB响应的PDF生成的响应），慢速消费的客户端将使相应的gunicorn工作者停顿…事实上，如果存在是N个gunicorn工作者，只会让N个客户端在慢速networking连接后生成PDF，而我们的应用程序将会停止运行。
我可以将proxy_buffer_size增加到4K以上（即一个内存页面）。 我很确定这会对nginx性能产生严重的影响 – 我们70％的响应确实适合4K，我们将强制nginx分配…什么？ 2 MB的缓冲区为他们每个人，只是为了准备偶尔的PDF生成请求？ 编辑 ：其实这根本不是一个选项 – 迈克尔（下）评论说，唯一允许的值是4K和8K。
我可以closuresproxy_buffering ，但是和第一种解决scheme（慢速客户端=>死亡）一样糟糕。
实际上，nginx会将我们的日志充斥在我们想要的东西上 – 当响应很大时，临时缓冲到文件中。
我们只是想阻止这种淹没我们的日志，通过“标记”它不是一个真正的警告（我不知道为什么这是一个警告 – 什么“坏事”是警告我们？）
除了编辑nginx的源代码和重新编译，还有其他的解决scheme，我失踪了吗？
这是Nginx的error_log指令的日志级别的结果。
https://www.nginx.com/resources/admin-guide/logging-and-monitoring/
error_log logs/error.log warn;
警告消息，错误暴击消息，警报消息，以及emerg级别。
错误日志的默认设置全局工作。 要覆盖它，请将error_log指令放置在主（顶级）configuration上下文中。 主环境中的设置始终由其他configuration级别inheritance。 error_log指令也可以在http，stream，服务器和位置级别指定，并覆盖从较高级别inheritance的设置。
这条关于缓冲的线路处于警告级别：
[warn] 30055#0: *1428 an upstream response is buffered to a temporary file
所以，如果你确保你的错误日志级别没有设置为警告，即保持默认或减less它，那么你将不会再看到这个警告。 下面的任一解决scheme都会压制它们：
将其保留在默认值（级别“错误”及以上）：
error_log logs/error.log;
一样：
error_log logs/error.log error;
你也可以增加超出error的门槛，达到crit ， alert和emerg 。