nginx配置不生效-国外服务器-主机巴巴

#defineNGX_HTTP_CLIENT_CLOSED_REQUEST499

nginx中的504判定相关超时配置

由于api与nginx是通过uwsgi协议通信，因此关键的超时配置参数如下：

Syntax: uwsgi_connect_timeouttime;

uwsgi_connect_timeout60s;

Context: http,server,location

Definesatimeoutforestablishingaconnectionwithauwsgiserver.Itshouldbenotedthatthistimeoutcannotusuallyexceed75seconds.

Syntax: uwsgi_send_timeouttime;

Context: http,server,location

Setsatimeoutfortransmittingarequesttotheuwsgiserver.Thetimeoutissetonlybetweentwosuccessivewriteoperations,notforthetransmissionofthewholerequest.Iftheuwsgiserverdoesnotreceiveanythingwithinthistime,theconnectionisclosed.

Syntax: uwsgi_read_timeouttime;

Context: http,server,location

Definesatimeoutforreadingaresponsefromtheuwsgiserver.Thetimeoutissetonlybetweentwosuccessivereadoperations,notforthetransmissionofthewholeresponse.Iftheuwsgiserverdoesnottransmitanythingwithinthistime,theconnectionisclosed.

服务端耗时过长导致的499

将用户由于各种原因(如杀app)很快主动断开连接导致的499与客户端达到超时时间(这里是15s)导致的499混在了一起，无法区分客户端责任与服务端责任导致499问题。

对于nginx判定为499的请求，由于认为是客户端主动断开，不会被认为是服务端导致的unsuccessfulattempt而被计入用于failover判定的max_fails计数中，所以即便一个upstream大量触发了499，nginx都不会将其从可用upstream中摘除，相当于摘除不可用节点的功能失效，而由于负载过高导致499的upstream收到的请求依然不断增加最终可能导致更大的问题。

对于判定为499的请求，也是由于不会被认为是unsuccessfulattempt，所以uwsgi_next_upstream这一配置也不会work，于是当第一个处理请求的upstream耗时过长超时后，nginx不会尝试将其请求转发为下一个upstream尝试处理后返回，只能直接失败。

那是不是把客户端超时时间调大？或者把nginxupstream超时时间调小解决呢？调大客户端超时时间当然是不合理的，任何用户请求15s还未收到响应肯定是有问题的，所以正确的做法应该是调小upstream的超时时间，一般来说服务端对于客户端请求处理时间应该都是在数十、数百ms之间，超过1s就已经属于超长请求了，所以不但默认的60s不行，客户端设置的15s也不能用于upstream的超时判定。最终经过综合考虑服务端各api的耗时情况，先敲定了一个upstream5s的超时时间配置--由于之前没有经验首次修改步子不迈太大，观察一段时间后继续调整，这样做已经足以很大程度解决以上的3个问题：

将用户由于各种原因(如杀app)很快主动断开连接导致的499与nginx达到upstream超时时间时主动结束的504区分开了。

504会被纳入max_fails计算，触发nginx摘除失败节点逻辑，在单台机器故障响应缓慢时可以被识别出来暂时摘除出可用节点列表，防止其负载进一步加大并保证后续请求均被正常可用节点处理返回。

当nginx等待upstream处理达到5s触发超时时，其会按照uwsgi_next_upstream配置尝试将请求(默认仅限幂等的GET请求)转交给下一个upstream尝试处理后返回，这样在单一upstream由于异常负载较高超时时，其他正常的upstream可以作为backup兜底处理其超时请求，这里客户端原本等待15s超时的请求一般在5~10s内可以兜底返回。

通过proxy_ignore_client_abort配置解决499问题？

在网上查找资料时还有网友提出解除nginx499问题的一个思路是设置proxy_ignore_client_abort参数，该参数默认为off，将其设置为on后，对于客户端主动断开请求的情况，nginx会ignore而以upstream实际返回的状态为准，nginx官方文档说明如下：

Syntax: proxy_ignore_client_aborton|off;

proxy_ignore_client_abortoff;

Context: http,server,location

Determineswhethertheconnectionwithaproxiedservershouldbeclosedwhenaclientclosestheconnectionwithoutwaitingforaresponse.

但是在客户端主动断开连接时，设置这个参数的意义除了使nginxlog中记录的状态码完全按照upstream返回确定，而非表示客户端断连的499之外，对于实际问题解决完全没有任何帮助，感觉颇有把头埋进沙子的鸵鸟风格，不知道这个参数设置到底会有什么实用的场景。

非高峰时期单个upstream偶发响应缓慢、导致超时的原因

这是个好问题，这个问题是近期才出现的，在解决了上面说的nginx错配问题后尝试排查这个问题，从现象上看应该是某些特定请求触发了upsteamCPU飙升，响应缓慢后进一步影响了后续请求的处理，最终导致所有请求响应缓慢触发客户端499。在nginx错配问题解决后，再次出现这种单台upstream缓慢超时情况后，nginx会很快通过failover摘除掉问题upstream避免情况进一步恶化，而对于首次访问问题upstream超时的GET请求也会backup转发至其他可用upstream处理后返回，已经很大程度上降低了此类异常情况的影响。最终，修正配置后单upstream的偶发异常会以几天一次的频率触发部分POSTapi的少量504阈值告警，其问题的根本原因还在探寻中。

以上就是nginx配置不当引发的499与failover机制失效问题怎么解决的详细内容，更多请关注主机测评网其它相关文章！

本文来源：国外服务器--nginx配置不生效

本文地址：https://www.idcbaba.com/guowai/5479.html

标签：