当超过nginx proxy\u buffer\u大小时会发生什么情况？

我使用Docker在AWS Elastic Beanstalk中运行节点服务器，Docker也使用nginx。我的一个端点负责图像处理，如调整大小等。 我的日志显示了很多ESOCKETTIMEDOUT错误，这表明它可能是由无效的url引起的

情况并非如此，因为处理这种情况非常基本，当我打开明显无效的url时，它会很好地加载图像

到目前为止，我的研究使我做出了以下改变：

将请求模块的超时时间增加到2000 将容器uv_threadpool_size env变量设置为最大128 虽然1在一定程度上帮助改进了响应时间，但我看不到2有任何改进。我现在在服务器日志中遇到以下警告：

读取上游时，上游响应缓冲到临时文件/var/cache/nginx/proxy_temp/0/12/1234567890

这使我认为，ESOCKETTIMEDOUT错误可能是由于代理缓冲区大小被超过所致。但是，我不确定，在我继续根据直觉做出改变之前，我想听听大家的意见

所以我有两个问题：

如果在处理大图像时超过了nginx代理缓冲区大小，或者请求量超过了缓冲区大小，nginx代理缓冲区大小会导致错误吗？ 更新尺寸的成本影响（如有）是什么。AWS内存、实例大小等？ 我看到了一篇有用的文章，但想了解更多关于这是否对我的场景有帮助的意见。

当超过代理缓冲区大小时，它会创建一个临时文件作为一种交换，使用您的存储，如果可以计费，您的成本将增加。当您增加proxy\u buffer\u size值时，您将使用更多的RAM，这意味着您必须为更大的RAM付费，或者尝试使用当前的RAM

有两件事你不应该让用户等待处理：电子邮件和图像。它可能导致超时，甚至整个应用程序不可用。您始终可以为这些端点使用更大的超时，甚至更健壮的实例，但当它扩展时，您将遇到问题

---

我建议您采用不同的方法：做出图像占位符响应并异步处理这些图像。当它们作为版本调整大小的图像可用时，您可以正常为它们提供服务。有一个关于使用lambda进行类似操作的建议。

谢谢您的建议，这是一个很好的建议。然而，这并不能真正回答问题，即当超过nginx proxy\u buffer\u大小时会发生什么情况，以及如果它被增加会带来什么成本影响。我已经添加了您要问的内容，对此表示抱歉