环境是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>"
uwsgi错误日志中没有信息。
花了很多时间在这之后，我终于明白了。有很多对Nginx的引用和peer的连接重置。他们中的大多数似乎与PHP有关。我找不到特定于Nginx和uwsgi的答案。
我终于找到了对fastcgi和502错误网关错误（https://support.plesk.com/hc/en-us/articles/213903705）的引用。这导致我在uwsgi配置中寻找缓冲区大小限制，其存在为buffer-size。默认值为4096.从文档中可以看出：
如果您计划接收包含大量标题的大量请求，则可以将此值增加到64k（65535）。
有很多方法可以配置uwsgi，我碰巧使用.ini文件。所以在我的.ini文件中我尝试过：
buffer-size=65535
这解决了这个问题。你可以调整它来品尝。也许从最大值开始并重新开始工作直到你有一个可接受的值，或者只是保持最大值。
追踪是令人沮丧的，因为uwsgi方面没有任何错误。
我得到了相同的nginx错误，并且uwsgi日志中也没有相关信息。问题是在某些情况下，应用程序没有按照http://uwsgi-docs.readthedocs.org/en/latest/ThingsToKnow.html的建议消耗整个请求主体：
如果HTTP请求具有正文（如表单生成的POST请求），则必须在应用程序中读取（使用）它。如果不这样做，与您的网络服务器的通信套接字可能会被破坏。如果你很懒，你可以使用后缓冲选项，它会自动为你读取数据。对于Rack应用程序，这将自动启用。
当然，这不是您的问题，但对于获得相同nginx错误的其他人可能会有用。
谢谢，在PHP服务器的情况下采用相同的解决方案。我们只需要在php.ini中将属性“output_buffering”值增加到更大的值，如65535或其他适当的值。
当我们收到像(104: Connection reset by peer) while reading response header from upstream这样的消息时，大多数情况下，我们可以归咎于这种错误的上游方面。
如上所述，连接由上游对等体重置，而不是由nginx本身重置。 Nginx作为客户端几乎无法做任何事情来使其正确。
我怀疑修改缓冲区大小是否会产生魔力。基本上，该命令会更改缓存响应头的缓冲区大小。这将在响应头太大时生效，在这种情况下我们收到一条消息说upstream sent too big header while reading response header from upstream，这与connection reset by peer完全不同。
由于这种错误是随机触发的，我建议你检查nginx在与上游交谈时是否使用keepalive。如果是这种情况，当空闲超时时，上游服务器可能会重置连接，而nginx不知道连接已被丢弃，因此使用相同的连接转发请求。
据我所知，没有优雅的解决方案来修复它。您可以重试或将keepalive_timeout值设置为nginx中的上游连接池以避免此问题。
引用：
Apache HttpClient Interim Error: NoHttpResponseException
http://tengine.taobao.org/document/http_upstream_keepalive_timeout.html
--post-buffering 32768在这里为我工作（并且气馁）这里NGINX + uWSGI Connection Reset by Peer
我现在没有时间进一步调查它（快速原型模式:)，但由于我花了很多时间才找到这个黑客，所以可能值得在这里发帖。
您需要重新安装PHP：
apt-get install --reinstall php5-fpm