环境为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和连接重置的引用。其中大多数似乎与PHP有关。我找不到一个特定于Nginx和uwsgi的答案。
我终于找到了一个参考fastcgi和一个502坏网关错误(https://support.plesk.com/hc/en-us/articles/213903705)。这导致我在uwsgi配置中寻找缓冲区大小限制，它以buffer-size的形式存在。默认值为4096。从文档中，它说:
有很多方法可以配置uwsgi，我碰巧使用的是.ini文件。因此，在我的。ini文件中，我尝试:如果你计划接收带有大量标头的大请求，你可以将此值增加到64k(65535)。
buffer-size=65535
修复了这个问题。你可以根据自己的口味来调整。也许可以从最大值开始，直到你有一个可接受的值，或者只是保持最大值。
这是令人沮丧的跟踪，因为没有错误在uwsgi方面的事情。
我得到相同的nginx错误，也没有在uwsgi日志信息。问题是，在某些情况下，应用程序没有像http://uwsgi-docs.readthedocs.org/en/latest/ThingsToKnow.html:
中建议的那样消耗整个请求体。如果一个HTTP请求有一个主体(像一个表单生成的POST请求)，你必须在你的应用程序中读取(消费)它。如果不这样做，与web服务器的通信套接字可能会被破坏。如果你很懒，你可以使用后缓冲选项，它会自动为你读取数据。对于机架应用程序，这是自动启用的。
当然，这不是一个问题，在你的情况下，但它可能是有用的其他人谁得到相同的nginx错误。
我们只需要增加属性"output_buffering"值，在php.ini中，到一个更大的值，如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不知道连接已被丢弃，因此使用相同的连接转发请求。
就我所知，没有一个优雅的解决方案来解决这个问题。你可以在nginx中重试或设置一个keepalive_timeout值到上游连接池来避免这个问题。
Apache HttpClient Interim Error: NoHttpResponseException
http://tengine.taobao.org/document/http_upstream_keepalive_timeout.html--post-buffering 32768NGINX + uWSGI Connection Reset by Peer
我现在没有时间进一步研究它(快速原型模式:)，但因为我花了很多时间来找到这个hack，它可能值得在这里发布。
如果您的请求/响应头相当大，则可能发生这种情况。
在/etc/uwsgi/apps-available/your-app.ini添加buffer-size=65535
这不是偶然出现的
我想最有可能的原因是你的php-fpm.log尺寸过大。尝试将log_level更改为php-fpm.conf的上层并清除日志。
你需要重新安装PHP:
apt-get install --reinstall php5-fpm