我遇到了这个问题，原因是由于浏览器上的卡巴斯基保护插件。如果你遇到这种情况，试着禁用你的插件，看看这是否能解决你的问题。

对我来说，我已经启用了ufw，但我忘记暴露我的上行端口。_。

出现这种行为的原因之一可能是你在uwsgi上使用了http而不是socket。如果您直接使用uwsgi，请使用以下命令。

uwsgi --socket :8080 --module app-name.wsgi

ini文件中的相同命令是

chdir = /path/to/app/folder
socket = :8080
module = app-name.wsgi

我遇到了这个问题，原因是由于浏览器上的卡巴斯基保护插件。如果你遇到这种情况，试着禁用你的插件，看看这是否能解决你的问题。

“客户端关闭连接”中的“客户端”不一定是Web浏览器!

如果你在你的用户和你的Nginx之间有负载平衡服务——使用AWS或haproxy，你可能会在Nginx日志文件中发现499个错误。在这个配置中，负载均衡器服务将充当Nginx服务器的客户端和Web浏览器的服务器，来回代理数据。

对于haproxy，连接到上游和从上游(Nginx)或下游(Web浏览器)读取的某些适用超时的默认值约为60秒。

这意味着如果代理在大约60秒后还没有连接到上游进行写入，或者如果它还没有分别从下游(Web浏览器)或上游(Nginx)接收到任何数据作为HTTP请求或响应的一部分，它将关闭相应的连接，这将被Nginx视为错误，至少，如果后者当时正在处理请求(花了太长时间)。

对于繁忙的网站或需要更多时间执行的脚本，可能会发生超时。您可能需要找到一个适合您的超时值。例如，将它扩展到更大的数字，比如180秒。那也许能帮你解决问题。

根据您的设置，您可能会在浏览器中看到一个504网关超时HTTP错误，这可能表明php-fpm有问题。但是，如果日志文件中有499个错误，情况就不是这样了。

我知道这是一个旧线程，但它完全符合最近发生在我身上的事情，我想我应该在这里记录它。设置(在Docker中)如下:

nginx_proxy nginx Php_fpm运行实际的应用程序。

在应用程序登录提示时，现象为“502网关超时”。检查日志发现:

该按钮通过HTTP POST到/login…所以…… Nginx-proxy收到/login请求，并最终报告超时。 Nginx返回一个499响应，这当然意味着“主机死亡”。 登录请求根本没有出现在FPM服务器的日志中! 在FPM中没有回溯或错误消息…没有，零，zippo，零。

结果发现，问题是无法连接到数据库以验证登录。但如何弄清楚这一点完全是猜测。

The complete absence of application traceback logs ... or even a record that the request had been received by FPM ... was a complete (and, devastating ...) surprise to me. Yes, the application is supposed to log failures, but in this case it looks like the FPM worker process died with a runtime error, leading to the 499 response from nginx. Now, this obviously is a problem in our application ... somewhere. But I wanted to record the particulars of what happened for the benefit of the next folks who face something like this.