nginx / gunicorn连接挂了60秒

我正在对nginx-> gunicorn-> Django应用程序进行HTTP POST请求。响应主体快速返回，但是请求还没有完成大约60多秒。

“完全完成”是指我尝试过的各种客户端（Chrome，wget，我正在构build的Android应用程序）表示请求仍在进行中，好像在等待更多数据。从Wireshark收听，我发现所有数据都很快到达，然后在60秒之后，ACK FIN终于来了。

本地开发服务器（ ./manage.py runserver ）上的相同POST请求会很快执行。另外，它直接对gunicorn执行，绕过nginx。也可以在Apache / mod_wsgi设置中快速运行。

GET请求没有问题。甚至其他的POST请求也没问题。我知道的一个区别是这个具体的请求返回201不是200。

我认为它与Content-Length标题，closures与Keepalive连接有关，但还不知道事情应该如何正常工作。

后端服务器（gunicorn）目前正在closures连接，这是有道理的。
后端服务器应该包含Content-Length header还是Transfer-encoding: chunked ？还是应该nginx能够应付没有这些，并根据需要添加它们？
我认为连接保持活着是有好处的，不应该在nginx中禁用。

更新：在nginx.conf中将keepalive_timeout设置为0修复了我的问题。但是，当然，保持活力已经消失了。我仍然不确定是什么问题。可能是堆栈中的东西（我的Django应用程序或gunicorn）没有正确实现分块传输，并迷惑客户端。

这听起来像你的上游服务器（gunicorn）是以某种方式持有连接打开特定的API调用 – 我不知道为什么（取决于您的代码，我认为），但默认proxy_read_timeout选项在proxy_read_timeout是60秒，所以它听起来像这个答复没有收到，出于某种原因。

我使用了一个非常类似的设置，并且我一般不会注意到有关POST的任何问题，或任何其他请求。

请注意， return HttpResponse(status=201)之前导致我的问题 – 看来Django更喜欢显式为空的主体： return HttpResponse("", status=201)工作。我通常在我所期望的身体中设置一些东西 – 这可能是值得注意的。