从上游读取响应头时,Nginx uwsgi(104:由对等方重置连接)

use*_*130 44 django nginx uwsgi

环境是Nginx + uwsgi.

在某些GET请求中从Nginx获取502错误的网关错误.似乎与URL的长度有关.在我们的特定情况下,它是一长串的GET参数.缩短GET参数,没有502错误.

来自nginx/error.log

[error] 22113#0: *1 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: 192.168.1.100, server: server.domain.com, request: "GET <long_url_here>"
Run Code Online (Sandbox Code Playgroud)

uwsgi错误日志中没有信息.

use*_*130 81

花了很多时间在这之后,我终于明白了.有很多对Nginx的引用和peer的连接重置.他们中的大多数似乎与PHP有关.我找不到特定于Nginx和uwsgi的答案.

我终于找到了对fastcgi和502错误网关错误的引用(https://support.plesk.com/hc/en-us/articles/213903705).这导致我去寻找其中存在的uwsgi配置的缓冲区大小限制缓冲区大小.默认值为4096.从文档中可以看出:

如果您计划接收包含大量标题的大型请求,则可以将此值增加到64k(65535).

有很多方法可以配置uwsgi,我碰巧使用.ini文件.所以在我的.ini文件中我尝试过:

buffer-size=65535
Run Code Online (Sandbox Code Playgroud)

这解决了这个问题.你可以调整它来品尝.也许从最大值开始并重新开始工作直到你有一个可接受的值,或者只是保持最大值.

追踪是令人沮丧的,因为uwsgi方面没有任何错误.


Rin*_*nas 5

我收到了同样的 nginx 错误,而且 uwsgi 日志中也没有信息。问题是,在某些情况下,应用程序没有按照http://uwsgi-docs.readthedocs.org/en/latest/ThingsToKnow.html 中的建议使用整个请求正文:

如果 HTTP 请求有正文(如表单生成的 POST 请求),则必须在应用程序中读取(使用)它。如果您不这样做,与您的网络服务器的通信套接字可能会被破坏。如果你很懒惰,你可以使用后缓冲选项,它会自动为你读取数据。对于机架应用程序,这是自动启用的。

当然,这在您的情况下不是问题,但对于遇到相同 nginx 错误的其他人来说可能有用。