记一次nginx 502异常处理的判断处理

问题场景：应用人员反映某页面刷新时加载的某些url有时返回500，有时返回502

网络结构：2台主机部署应用程序，由nginx配置组成集群提供服务

nginx配置如下：

upstream        cluster_testamp.xxx.cn {
                server  192.168.x.x1:3004;
                server  192.168.x.x2:3005;
}

location / {
        proxy_pass      http://cluster_testamp.xxx.cn;
        proxy_redirect off;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header REMOTE-HOST $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_next_upstream error timeout invalid_header http_500 http_502 http_504 http_404;
    }

 

简单分析原因，之前在很多系统里都有人反映过返回502，经检查每次都是后台服务挂了导致返回502，所以判定问题应该还是出在后台服务上。

直接通过内网ip访问后台主机，发现2台主机上的服务对应的url都返回500，是服务器内部错误，与开发部门沟通后，可以确定是数据错误导致，但短时间内无法修正。

500的原因此时已经找到，502产生的原因此时还不知道，在此之前看过nginx的文档，里面提到过服务健康检查，重新查阅文档，确认upsteam默认支持健康检查，自动将不健康的节点从集群中离线。

想到一种可能，由于有些url是200，有些是500，当500访问过多时，nginx会判定该服务不健康，当集群中所有节点都不健康时，认为服务不存在，会有极短的一段时间对接受的连接直接返回502，即使本该200的url也受此影响。

多次手动快速刷新页面，没有模拟出这种情况。

后用python程序for循环模拟发送100连接，仍然没有模拟出，分析后认为顺序访问没有达到并发效果，但python的多线程由于GIL的原因对并发处理可能不理想，所以用java多线程模拟100并发同时发起连接，可以模拟出上面的效果，本该返回200的url也返回了502。

验证：

       用多线程程序模拟访问过程，设置100并发，访问2个url，一个在单次访问中返回200，一个在单次访问中返回500，按1/4的比例随机发送，正常情况下返回200的约20个，返回500或502的约80个，

实际验证结果中确实出现了本应返回200的url返回了502，图中标记为true的是本应返回200的访问。

此时可以认定为是由于服务500导致了健康检查动作，影响了正常的url返回。

 

将nginx配置中的

proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header REMOTE-HOST $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_next_upstream error timeout invalid_header http_500 http_502 http_504 http_404;

去掉后，不再返回502，只返回200或500。

已经是后半夜了，没有进行详细测试，想来是proxy_next_upstream ... http_502的影响，暂时没有深究其中原因。

看来掌握一个东西，读文档还是相当必要的啊。