我得到了很多499 NGINX错误码。我知道这是客户端的问题。这不是NGINX或我的uWSGI堆栈的问题。当a得到499时，我注意到uWSGI日志中的相关性。
address space usage: 383692800 bytes/365MB} {rss usage: 167038976
bytes/159MB} [pid: 16614|app: 0|req: 74184/222373] 74.125.191.16 ()
{36 vars in 481 bytes} [Fri Oct 19 10:07:07 2012] POST /bidder/ =>
generated 0 bytes in 8 msecs (HTTP/1.1 200) 1 headers in 59 bytes (1
switches on core 1760)
SIGPIPE: writing to a closed pipe/socket/fd (probably the client
disconnected) on request /bidder/ (ip 74.125.xxx.xxx) !!!
Fri Oct 19 10:07:07 2012 - write(): Broken pipe [proto/uwsgi.c line
143] during POST /bidder/ (74.125.xxx.xxx)
IOError: write error
我正在寻找一个更深入的解释，希望我的NGINX配置uwsgi没有问题。我只看表面。好像是客户的问题。
使用标准的nginx配置和php-fpm，这个错误很容易重现。
在页面上按下F5按钮将向服务器创建数十个刷新请求。浏览器在刷新时取消之前的每个请求。以我为例，我在客户的网上商店日志文件中发现了数十个499。从nginx的角度来看:如果在下一次刷新请求之前没有将响应传递给客户端，nginx将记录499错误。
mydomain.com.log:84.240.77.112 - - [19/Jun/2018:09:07:32 +0200] "GET /(path) HTTP/2.0" 499 0 "-" (user-agent-string)
mydomain.com.log:84.240.77.112 - - [19/Jun/2018:09:07:33 +0200] "GET /(path) HTTP/2.0" 499 0 "-" (user-agent-string)
mydomain.com.log:84.240.77.112 - - [19/Jun/2018:09:07:33 +0200] "GET /(path) HTTP/2.0" 499 0 "-" (user-agent-string)
mydomain.com.log:84.240.77.112 - - [19/Jun/2018:09:07:33 +0200] "GET /(path) HTTP/2.0" 499 0 "-" (user-agent-string)
mydomain.com.log:84.240.77.112 - - [19/Jun/2018:09:07:33 +0200] "GET /(path) HTTP/2.0" 499 0 "-" (user-agent-string)
mydomain.com.log:84.240.77.112 - - [19/Jun/2018:09:07:34 +0200] "GET /(path) HTTP/2.0" 499 0 "-" (user-agent-string)
mydomain.com.log:84.240.77.112 - - [19/Jun/2018:09:07:34 +0200] "GET /(path) HTTP/2.0" 499 0 "-" (user-agent-string)
mydomain.com.log:84.240.77.112 - - [19/Jun/2018:09:07:34 +0200] "GET /(path) HTTP/2.0" 499 0 "-" (user-agent-string)
mydomain.com.log:84.240.77.112 - - [19/Jun/2018:09:07:34 +0200] "GET /(path) HTTP/2.0" 499 0 "-" (user-agent-string)
mydomain.com.log:84.240.77.112 - - [19/Jun/2018:09:07:35 +0200] "GET /(path) HTTP/2.0" 499 0 "-" (user-agent-string)
mydomain.com.log:84.240.77.112 - - [19/Jun/2018:09:07:35 +0200] "GET /(path) HTTP/2.0" 499 0 "-" (user-agent-string)
当然，如果php-fpm处理需要更长的时间(比如一个沉重的WP页面)，它可能会导致问题。例如，我听说过php-fpm崩溃，但我相信可以通过正确配置服务来防止崩溃，比如处理对xmlrpc.php的调用。
就我而言，我没有耐心，最终误解了日志。
事实上，真正的问题是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上，它一直挂着(“再等一会儿，再等一会儿，然后我就会给你一个答案……”)。
我不记得我是怎么解决这个问题的。我想这可能是由很多事情引起的。
