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


当前回答

...从谷歌搜索过来的

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

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

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

其他回答

在我的例子中,我有这样的设置

AWS ELB >> ECS(nginx) >> ECS(php-fpm).

我为ECS(php-fpm)服务配置了错误的AWS安全组,因此Nginx无法接触到php-fpm任务容器。 这就是为什么我在nginx任务日志中得到错误

499 0 - elb-healthchecker/2.0

健康检查配置为检查php-fpm服务并确认其正常运行并返回响应。

...从谷歌搜索过来的

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

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

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

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

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

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

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

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

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

有一次,我得到499“请求已被反病毒禁止”作为AJAX http响应(卡巴斯基互联网安全与轻启发式分析的假阳性,深度启发式分析正确地知道没有任何错误)。

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