Nginx反向代理到Django，在从上游读取响应头时接收“上游过早关闭的连接”` TL；博士

当Nginx试图通过http反向代理到本地Django实例（没有WSGI中间件）时，当Nginx从上游读取响应头时，记录上游过早关闭的连接时，会发生什么http/tcp现象

长版本 冒着激怒社区的风险，我不打算包含任何配置，虽然我确信它是相关的，但我正在试图理解这种现象背后的理论

我和一些队友维护一个Web服务器供内部使用。在我们内部工具的世界里，东西永远不会被生产出来。我们通常会做任何必要的事情，为同事带来一些价值。风险和可用资源都很低

因此，我们已经犯下了一个重大的错误，那就是单独安装Python2Django服务器。没有WSGI中间件，没有其他进程。我看到了警告，但我们做了我们所做的

最近，我在这个讨厌的东西面前放了一个Nginx实例，让我们能够在零停机的情况下“热交换”web应用程序实例。我仍然没有在两者之间插入任何内容。Nginx只是通过localhost http反向代理到在localhost非标准端口上侦听的Django实例

在这一变化之后，我们开始看到Nginx的502爆发。有一些页面是“实时”的，因为它们进行一些轮询来检查事物的更新。因此，就我们拥有的用户数量而言，流量“很大”

事实上，我认为在推出Nginx之前，问题已经存在，但由于浏览器直接出现错误，它只是简单地重试，用户看不到这个问题，而现在他们收到了一条丑陋的502错误消息

现在回答问题： 如果我在Nginx error.log

中看到上游在从上游读取响应头时过早关闭连接

这实际上意味着什么？我在这个网站上看到了很多关于修改配置的建议，这些建议似乎都不适用于我，但我要寻找的是理论

这个错误是什么意思？ 当Nginx试图将请求代理给Django时，它到底经历了什么？ Django拒绝连接吗？ Django是否在连接完成之前关闭连接

如果Django在做这些事情，为什么？它是否内存不足，线程，是否有一些原因会限制线程的数量，等等

作为一次临时修复的盲目尝试，我在周末修复了应用程序的第二个实例，并将Nginx配置为循环负载平衡。这似乎奏效了，但我要到周一早上高峰负荷到来时才能确定

第二个实例位于同一个框中，因此不能有任何其他系统资源。Python解释器实例中是否有一些资源正在耗尽，以至于创建第二个实例会给我“两倍”的容量

除了“投入更多资源”之外，我真的在努力学习一些有价值的东西

任何帮助都将不胜感激。提前谢谢

更新 菲利普，非常感谢你的详尽回答！一个快速的问题来锁定我的理解

如果我的上游Python服务器“无法并行处理足够多的请求并阻塞”，那么这可能是什么原因呢。这是一个单一的过程，所以我认为这可以简化问题。什么资源将耗尽？服务器不可能只是以它能适应的任何速度读取套接字吗？什么样的系统/服务器配置决定了它一次可以处理的飞行中请求的数量？我仔细查看了一下，没有发现任何显式的Django（Python服务器库）配置选项会人为地限制其响应能力。我当然可以提供额外的资源，但如果这更多是一个系统限制，那么我不会期望同一个框中的另一个实例做任何事情（这是我现在所期望的，因为第二个实例在周末开始产生相同的问题）。我想在这里一劳永逸地做出一个深思熟虑的决定

再次感谢您（或任何其他人）的帮助

更新2 根本问题（正如我周一早上一位精通Linux内核的同事向我描述的那样）是侦听队列深度

正是这种结构的能力有限。当进程侦听端口时，新的连接尝试进入（在建立连接之前），如果进程建立连接的速度比进入连接的速度慢，则侦听队列将建立起来

因此，这与内存或CPU无关（除非这些资源的短缺是连接建立缓慢的原因），而是对进程连接容量的限制

我决不是这方面的专家，但我所追求的正是这种结构，我想知道为什么一个给定的进程突然决定（或者操作系统决定）它将不再接受连接

更多内容可以阅读

再次感谢菲利普带领我走上正确的道路

上游在从上游读取响应头时过早关闭连接

这个错误肯定在上游，这意味着在您的情况下，连接到Python服务器。502表示从Nginx到其上游服务器之一的TCP连接已关闭（从python进程主动关闭，或在超时时由系统主动关闭）

根据您所描述的，可能是Python服务器无法并行和分块处理足够的请求。只要前面没有Nginx，您就不会注意到，可能只是请求很慢。随着Nginx的出现，它会发生变化，因为Nginx可以轻松地处理大量请求，并且可能会接受比其上游服务器（即，您的Python服务器）能够跟上的更多的请求。