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

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

ini文件中的相同命令是

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

我们在生产中也得到了499响应码。我们的堆栈是

NGINX, Gunicorn Django 芹菜(异步) Redis芹菜经纪人。 Postgresql

问题: 我们的API没有返回到Gunicorn -> NGINX的响应。因为Redis已关闭(正在加载数据)，所以celery将请求传递给.delay()方法以从API卸载工作负载，但它没有返回任何响应。

如何在Django和其他堆栈中重现它?

不从API返回任何响应。NGINX将向客户端发送499响应码。

我们是怎么解决的?

我们检查了堆栈的每个组件，最终找到了一个导致组件，它是Redis。我们注释了.delay()(这个方法使用了Redis)方法调用并测试了API，它工作得很好。

这可能是NGINX返回499的原因之一。 确保您的Web框架是否返回响应。如果它返回200，那么检查你的NGINX配置或客户端。

.．.从谷歌搜索过来的

我在这里找到了答案——> https://stackoverflow.com/a/15621223/1093174

这是为了提高我的AWS弹性负载均衡器的连接空闲超时!

(我用nginx/apache反向代理设置了一个Django站点，一个非常非常非常日志后端作业/视图超时)

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

就我而言，我没有耐心，最终误解了日志。

事实上，真正的问题是nginx和uwsgi之间的通信，而不是浏览器和nginx之间的通信。如果我在浏览器中加载了这个网站，并且等了足够长的时间，我就会得到一个“504 -坏网关”。但花了很长时间，我一直在尝试，然后在浏览器中刷新。所以我没有等待足够长的时间来看到504错误。当在浏览器中刷新时，也就是关闭前一个请求时，Nginx将其写入日志为499。

细化

在这里，我假设读者知道的和我刚开始玩游戏时一样少。

我的设置是一个反向代理，nginx服务器，和一个应用服务器，后面是uWSGI服务器。来自客户端的所有请求都将发送到nginx服务器，然后转发到uWSGI服务器，然后以同样的方式返回响应。我认为这是每个人使用nginx/uwsgi和应该使用它的方式。

我的nginx正常工作，但是uwsgi服务器出了问题。uwsgi服务器无法响应nginx服务器有两种(也许更多)方式。

1) uWSGI说:“我正在处理，请稍等，您很快就会得到回复”。Nginx有一段时间，它愿意等待，fx 20秒。之后，它将响应客户端，并返回一个504错误。

2) uWSGI死了，或者在nginx等待它的时候uWSGI死了。Nginx马上就看到了，在这种情况下，它返回一个499错误。

我通过在客户端(浏览器)中发出请求来测试我的设置。在浏览器中什么都没有发生，它只是一直挂着。大约10秒钟之后(比超时时间还短)，我得出结论，有些地方不太对(这是真的)，并从命令行关闭uWSGI服务器。然后我将转到uWSGI设置，尝试一些新的设置，然后重新启动uWSGI服务器。当我关闭uWSGI服务器时，nginx服务器将返回一个499错误。

所以我一直在调试499错误，这意味着在谷歌上搜索499错误。但是如果我等了足够长的时间，就会得到504错误。如果我得到504错误，我就能够更好地理解问题，然后能够调试。

所以结论是，问题出在uWGSI上，它一直挂着(“再等一会儿，再等一会儿，然后我就会给你一个答案……”)。

我不记得我是怎么解决这个问题的。我想这可能是由很多事情引起的。

在我的例子中，当客户端的API在得到任何响应之前关闭连接时，我得到了499。字面上发送了一个帖子，并立即关闭连接。 这是通过选项解决的:

proxy_ignore_client_abort上

Nginx doc