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

事实上，真正的问题是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上，它一直挂着(“再等一会儿，再等一会儿，然后我就会给你一个答案……”)。

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

当你指向499时，nginx记录了一个连接中止。但这通常是在您的后端服务器太慢，另一个代理超时或用户软件终止连接时产生的。因此，检查uWSGI是否响应快，或者uWSGI /数据库服务器上是否有负载。

在很多情况下，在用户和nginx之间有一些其他的代理。有些可能在你的基础设施中，比如CDN，负载均衡器，清漆缓存等。其他可以在用户端，如缓存代理等。

如果你这边有代理，比如LoadBalancer / CDN……您应该将超时设置为先超时您的后端，然后逐步将其他代理超时给用户。

如果你有:

user >>> CDN >>> Load Balancer >>> Nginx >>> uWSGI

我建议你设置:

n秒到uWSGI超时 N +1秒到nginx超时 n+2秒超时到负载均衡器 n+3秒超时到CDN。

如果你不能设置一些超时(如CDN)，找到它的超时是什么，并根据它调整其他的(n, n-1…)

这提供了一个正确的超时链。你会发现是谁给出了超时并将正确的响应代码返回给用户。

.．.从谷歌搜索过来的

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

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

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

Nginx中的HTTP 499意味着客户端在服务器响应请求之前关闭了连接。以我的经验，通常是由客户端超时引起的。据我所知，这是Nginx特定的错误代码。

我知道这是一个旧线程，但它完全符合最近发生在我身上的事情，我想我应该在这里记录它。设置(在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.

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

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

ini文件中的相同命令是

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