我得到了很多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没有问题。我只看表面。好像是客户的问题。


当前回答

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

其他回答

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

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

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

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

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

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

这并没有回答OPs的问题,但由于我在激烈地寻找答案后来到这里,我想分享我们的发现。

在我们的例子中,这些499是意料之中的。例如,当用户在某些搜索框中使用提前输入功能时,我们会在日志中看到类似的内容。

GET /api/search?q=h [Status 499] 
GET /api/search?q=he [Status 499]
GET /api/search?q=hel [Status 499]
GET /api/search?q=hell [Status 499]
GET /api/search?q=hello [Status 200]

因此,在我们的情况下,我认为使用proxy_ignore_client_abort是安全的,这是在前面的回答中建议的。谢谢你!

使用标准的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的调用。

出现这种行为的原因之一可能是你在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记录了一个连接中止。但这通常是在您的后端服务器太慢,另一个代理超时或用户软件终止连接时产生的。因此,检查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…)

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