刚事情那会，有一次，上游调用我做事的老哥说，你的做事报"502缺点了，快去看看是为什么吧"。
当时那个做事里恰好有个调用日志，平时会记录各种200,4xx状态码的信息。于是我跑到做事日志里去搜索了一下502这个数字，毫无创造。于是跟老哥说，"做事日志里并没有502的记录，你是不是搞错啦？"
现在想来，多少有些不好意思。
不知道有多少老哥是跟当时的我是一样的，这篇文章，就来聊聊502缺点是什么？
我们从状态码是什么开始聊起。
HTTP状态码
我们平时在浏览器里逛的某宝和某度，实在都是一个个前端网页。
一样平常来说，前端并不存储太多数据，大部分时候都须要从后端做事器那获取数据。
于是前后端之间须要通过TCP协议去建立连接，然后在TCP的根本上传输数据。
而TCP是基于数据流的协议，传输数据时，并不会为每个加入数据边界，直策应用裸的TCP进行数据传输会有"粘包"问题。
因此须要用特地的协议格式去对数据进行解析。于是在此根本上设计了HTTP协议。详细的内容可以看我之前写的《既然有HTTP协议，为什么还要有RPC》。
比如，我想要看某个商品的详细信息，实在便是前端发的HTTP要求中传入商品的id，后端返回的HTTP相应中返回商品的价格，商店名，发货地址的信息等。
这样，表面上，我们是在刷着各种网页，实际上背后正有多次HTTP在不断进行收发。
但问题就来了，上面提到的都是正常情形，如果有非常情形呢，比如前端发的数据，根本就不是个商品id，而是一张图片，这对付后端做事端来说是不可能给出正常相应的，于是就须要设计一套HTTP状态码，用来标识这次HTTP要求相应流程是否正常。通过这个可以影响浏览器的行为。
比方说统统正常，那做事端返回个200状态码，前端收到后，可以放心利用相应的数据。但如果做事端创造客户端发的东西非常，就相应个4xx状态码，意思是这是个客户真个缺点，4xx里头的xx可以根据缺点的类型，再细分成各种码，比如401是客户端没权限，404是客户端要求了一个根本不存在的网页。反过来，如果是做事器有问题，就返回5xx状态码。
但问题就来了。
做事端都有问题了，搞严重点，做事器可能直接就崩溃了，那它还怎么给你返回状态码？
是的，这种情形，做事端是不可能给客户端返回状态码的。以是说，一样平常情形下5xx的状态码实在并不是做事器返回给客户真个。
它们是由网关返回的，常见的网关，比如nginx。
nginx的浸染
回到前后端交互数据的话题上，如果前端用户少，那后端处理起要求来，游刃有余。但随着用户越来越多，后端做事器受资源限定，cpu或者内存都可能会严重不敷，这时候办理方案也很大略，多搞几台一样的做事器，这样就能将这些前端要求均摊给几个做事器，从而提升处理能力。
但要实现这样的效果，前端就得知道后端详细有哪些个做事器，并逐一跟他们建立TCP连接。
也不是弗成，但便是麻烦。
但这时候如果能有个中间层挡在它们中间就好了，这样客户端只须要跟中间层连接，中间层再和做事器建立连接。
于是，这个中间层就成了这帮做事器的一个代理人一样，客户端有啥事都找代理人，只管发出自己的要求，再由代理人去找某个做事器去完成相应。全体过程下来，客户端只知道自己的要求被代理人帮忙搞定了，但代理人详细找了那个做事器去完成，客户端并不知道，也不须要知道。
像这种，屏蔽掉详细有哪些做事器的代理办法便是所谓的反向代理。
反过来，屏蔽掉详细有哪些客户真个代理办法，便是所谓的正向代理。
而这个中间层的角色，一样平常由nginx这类网关来充当。
其余，由于背后的做事器可能性能配置各不相同，有些4核8G，有些2核4G，nginx能为它们加上不同的访问权重，权重高的多转发点要求，通过这个办法实现不同的负载均衡策略。
nginx返回5xx状态码
有了nginx这一中间层后，客户端从直连做事端，变成客户端直连nginx，再由nginx直连做事端。从一个TCP连接变成两个TCP连接。
于是，当做事器发生非常时，nginx发送给做事器的那条TCP连接就不能正常相应，nginx在得到这一信息后，就会返回5xx缺点码给客户端，也便是说5xx的报错，实在是由nginx识别出来，并返回给客户真个，做事端本身，并不会有5xx的日志信息。以是才会涌现文章开头的一幕，上游收到了我做事的502报错，但我在自己的做事日志里却搜索不到这一信息。
产生502的常见缘故原由
在rfc7231中有关于502缺点码的官方阐明是
502 Bad Gateway The 502 (Bad Gateway) status code indicates that the server, while acting as a gateway or proxy, received an invalid response from an inbound server it accessed while attempting to fulfill the request.复制代码
翻译一下便是，502 (Bad Gateway) 状态代码表示做事器在充当网关或代理时，在考试测验知足要求时从它访问的入站做事器吸收到无效相应。
汝听，人言否？
这对付大部分编程小白来说，不仅没阐明到问题，反而只会冒出更多的问号。比如，这上面提到的无效相应到底指的是什么？
我来阐明下，它实在是说，502实在是由网关代理（nginx）发出的，是由于网关代理把客户真个要求转发给了做事端，但做事端却发出了无效相应，而这里的无效相应，一样平常是指TCP的RST报文或四次挥手的FIN报文。
四次挥手估计大家背的很熟了，以是略过，我们来重点说下RST报文是什么。
RST是什么？
我们都知道TCP正常情形下断开连接是用四次挥手，那是正常时候的优雅做法。
但非常情形下，收发双方都不一定正常，连挥手这件事本身都可能做不到，以是就须要一个机制去强行关闭连接。
RST 便是用于这种情形，一样平常用来非常地关闭一个连接。它是TCP包头中的一个标志位，在收到置这个标志位的数据包后，连接就会被关闭，此时吸收到 RST的一方，在运用层会看到一个 connection reset 或 connection refused 的报错。
而之以是发出RST报文，一样平常有两个常见缘故原由。
做事端过早断开连接
nginx与做事端之间有一条TCP连接，在nginx将客户端要求转发给做事端时，他两之间按道理会一贯保持这条连接，直到做事端将结果正常返回后，再断开连接。
但如果做事端过早断开连接，而nginx却还连续发过去，nginx就会收到做事端内核返回的RST报文或四次挥手的FIN报文，迫使nginx那边的连接结束。
过早断开连接的缘故原由常见的有两个。
第一个是，做事端设置的超时时间过短。不管是用的哪种编程措辞，一样平常都有现成的HTTP库，做事端一样平常都会有几个timeout参数，比如golang的HTTP做事框架里有个写超时（WriteTimeout），假设设置了2s，那它的含义便是，做事端在收到要求后须要在2s内处理完并将结果写到相应中，如果等不到，就会将连接给断掉。
比如你的接口处理韶光是5s，而你的WriteTimeout却只有2s，在没等到相应写完之前，HTTP框架就会主动将连接给断开。nginx此时就有可能收到四次挥手的FIN报文（有些框架也可能发RST报文），然后断开连接，于是客户端就会收到一个502报错。
碰着这种问题，将WriteTimeout的韶光调大一些就好了。
第二个缘故原由，也是造成502状态码最常见的缘故原由，便是做事端运用进程崩了（crash）。
做事端崩了，也便是当前没有一个进程在监听做事器端口，而此时你却考试测验向一个不存在的端口发数据，做事器的linux内核协议栈就会相应一个RST数据包。同样，这时候nginx也会给客户端一个502。
在开拓过程中，这种情形是最常见的。
现在我们大部分的做事器都会将挂掉的做事重启，因此我们须要判断下做事是否曾经崩溃过。
如果你有对做事真个cpu或者内存做过监控，可以看下CPU或内存的监控图是否涌现过断崖式的溘然下跌。如果有，十有八九百，便是你的做事端运用程序曾经崩溃过。
除此之外你还通过下面的命令，看下进程上次的启动韶光是什么时候。
ps -o lstart {pid}复制代码
比如我要看的进程id是13515，命令就须要像下面这样。
# ps -o lstart 13515 STARTEDWed Aug 31 14:28:53 2022复制代码
可以看到它上次的启动韶光是8月31日，这个韶光如果跟你印象中的操作韶光有差距，那解释进程可能是崩了之后被重新拉起了。
碰着这种问题，最主要的是找出崩溃的缘故原由，崩溃的缘故原由就多种多样了，比如，对未初始化的内存地址进行写操作，或者内存访问越界（数组arr长度明明只有2，代码却读arr[3]）。
这种情形险些都是程序有代码逻辑问题，崩溃一样平常也会留下代码堆栈，可以根据堆栈报错去排查问题，修复之后就好了。比如下面这张图是golang的报错堆栈信息，其他措辞的也类似。
不打印堆栈的情形
但有一些情形，有时候根本不留下堆栈。
比如内存透露导致进程占用内存越来越多，末了导致超过做事器的最大内存限定，触发OOM（out of memory）, 进程直接就被操作系统kill掉。
还有更暗藏的，代码逻辑里隐蔽了主动退出进程的操作。比如golang的日志打印里有个方法叫log.Fatalln()，打印完日志还会顺便实行os.Exit()直接退出进程，对源码不理解的新手很随意马虎犯这个错。
如果你很明确，你的做事没有崩过。那连续往下看。
网关将要求打到了一个不存在的IP上
nginx是通过配置的形式来代理多个做事器。这个配置一样平常是放在 /etc/nginx/nginx.conf 中。
打开它，你可能会看到类似下面这样的信息。
upstream xiaobaidebug.top { server 10.14.12.19:9235 weight=2; server 10.14.16.13:8145 weight=5; server 10.14.12.133:9702 weight=8; server 10.14.11.15:7035 weight=10;}复制代码
上面配置的含义是，如果客户端访问xiaobaidebug.top域名，nginx就会将客户真个要求转发到下面的4个做事器ip上，ip边上还有个weight权重，权重越高，被转发到的次数就越多。
可以看出，nginx具有相称丰富的配置能力。但要把稳的是，这些个文件是须要自己手动配置的。对付做事器少，且不怎么变革的情形，这当然没问题。
但现在已经是云原生时期了，很多公司内部都有自己的云产品，做事自然也会上云。一样平常来说每次更新做事，都可能会将做事支配到一台新的机器上。而这个ip也会随着改变，难道每发布一次做事，都须要手动去nginx上改配置吗？这显然不现实。
如果能在做事启动时，让做事主动将自己的ip见告nginx，然后nginx自己天生这样的一个配置并重新加载，那事情就大略多了。
为了实现这样一个做事注册的功能，不少公司都会基于nginx进行二次开拓。
但如果这个做事注册功能有问题，比方说做事启动后，新做事没注册上，但老做事已经被销毁了。这时候nginx还将要求打到老做事的IP上，由于老做事所在的机器已经没有这个做事了，以是做事器内核就会相应RST，nginx收到RST后回答502给客户端。
要排查这种问题也不难。
这个时候，你可以看下nginx侧是否有打印干系的日志，看下转发的IP端口是否符合预期。
如果不符合预期，可以去找找做这个根本组件的同事，进行一波友好的互换。
大略来说便是做事器没有相应，也便是我们的web做事器没有接到有效的信息导致的，产生缺点的缘故原由有很多，连接超时、设置代理、要求过多导致无法相应等等，都有可能导致要求502 Bad Gateway。
以下是搜集整理的一些502缺点的排查方法，供参考：
502缺点的缘故原由比较多，首先排查一下访问的电脑有没有设置代理。
是由于在代理模式下访问也是有可能报502的。
502 bad gateway
第二是用ipconfig命令或右键网络图形化界面查看ip和DNS，看下是否有问题
502 bad gateway
DNS 缓冲或者DNS设置禁绝确都有可能导致502。 这种情形的常日缘故原由是由于你在未开启vpn的情形下访问了facebook这样的网站。这个时候自然访问不上，同时却在本机留下了缓冲。 这种情形常日在几分钟之内就可以访问了。也可以考试测验 在dos窗口运行 ipconfig /flushdns，该命令会刷新DNS缓冲dns 被挟制了，纵然利用国外的dns，也会被挟制。有些机子开vpn能够访问，有些 机子确不能。
并且打消了代理、防火墙、本地网络的缘故原由。这个时候同时ping远程网站，比如facebook。不能访问的机子常日获取了一个怪异的ip， 从任何地方都ping不通的ip。而能访问的机子ip，在不能访问的机子上直接可以访问，也可以ping通。这种情形我们可以去掉VPN做事器的DNS。切换其余的dns。在windows系统中，可以在本地网络连接的属性中， 去掉默认的dns，选用国外的dns，比如google的114的。或opendns。
上面几部都检讨完了，末了清楚一下浏览器的缓存，CTRL+F5逼迫刷新页面。
如果是Nginx搭建的做事，则考试测验如下方法。
Nginx做事器上创造502缺点，很多情形下并非Nginx本身的问题。就以Nginx+PHP+MySQL这种架构解释。Nginx本身设置等cgi接口返回的数据延时太短，要延长这个韶光。犹如前面说的，很多情形下并非Nginx本身的问题，这样操作后常常并不能缓解问题。此时，就要考虑对应cgi接口的配置，比php-fpm.conf 的配置，脚本实行韶光的超时情形限定。这可以通过跟踪php-fpm的 slow log 来排查，对干系代码优化，减少延时。其余很大的问题在MySQL数据库这一块如果数据库实行命令超时也会大延长php脚本的实行韶光，导致 Nginx 等待超时。可以my.cnf的 slow log进行确认效能低下的sql语句是哪些，进行优化配置。通过优化 php-fpm 及 MySQL的配置都大大减少Nginx的等待超时的情形。
fastcgi缓冲区设置过小
确认这个问题首先要看nginx的日志文件，目录为/var/log/nginx，如果在日志中创造了类似如下缺点。
0: 16 upstream sent too big header while reading response header from upstream
则是nginx缓冲区有一个bug造成的,我们网站的页面花费占用缓冲区可能过大。
增加缓冲区即可，彻底办理了Nginx 502 Bad Gateway的问题。方法如下：
http {
fastcgi_buffers 8 16k;
fastcgi_buffer_size 32k;
请根据做事器已经网站的情形自行增大上述两个配置项。
二、代理缓冲区设置过小
如果你利用的是nginx反向代理，如果header过大，超出了默认的1k，就会引发上述的upstream sent too big header （说白了便是nginx把外部要求给后端处理，后端返回的header太大，nginx处理不过来就会导致502。
server {
listen 80;
server_name .lxy.me;
location / {
###############添加这3行
proxy_buffer_size 64k;
proxy_buffers 32 32k;
proxy_busy_buffers_size 128k;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
00001.
三、默认php-cgi的进程数设置过少
在安装好利用过程中涌现502问题，一样平常是由于默认php-cgi进程是5个，可能由于phpcgi进程不足用而造成502，须要修正/usr/local/php/etc/php-fpm.conf 将个中的max_children值适当增加。也有可能是max_requests值不足用。须要解释的是这连个配置项占用内存很大，请根据做事器配置进行设置。否则可能起到反效果。
四、php实行超时
php实行超时，修正/usr/local/php/etc/php.ini 将max_execution_time 改为300
五、nginx等待韶光超时
部分PHP程序的实行韶光超过了Nginx的等待韶光，可以适当增加nginx.conf配置文件中FastCGI的timeout韶光
fastcgi_connect_timeout 300;
fastcgi_send_timeout 300;
fastcgi_read_timeout 300;
502 bad gateway
502缺点还有一个常常涌现情形便是后端主机宕机。在配置里有这么一项配置：，这个配置指定了在从一个后端主机取数据碰着何种缺点时会转到下一个后端主机，里头写上的便是会涌现502的所有情形拉，默认是。便是宕机、断线之类的，便是读取堵塞超时，比较随意马虎理解。我一样平常是全写上的：
默认的进程数设置过少在安装好利用过程中涌现502问题，一样平常是由于默认进程是5个，可能由于进程不足用而造成502，须要修正/usr//php/etc/.conf将个中的值适当增加。也有可能是值不足用。须要解释的是这连个配置项占用内存很大，请根据做事器配置进行设置。否则可能起到反效果。
将要求提交给网关如实行，但是由于某些缘故原由没有实行完毕导致进程终止实行。说到此，这个问题就很明了了，与网关做事如的配置有关了。.conf配置文件中有两个参数就须要你考虑到，分别是和。最大子进程数，在高并发要求下，达到最大相应数，后续的要求就会涌现502缺点的。可以通过命令来查看当前连接数。设置单个要求的超时终止韶光。还该当把稳到php.ini中的参数。当要求终止时，也会涌现502缺点的。当积累了大量的php要求，你重启开释资源，但一两分钟不到，502又再次呈现，这是什么缘故原由导致的呢？这时还该当考虑到数据库，查看下数据库进程是否有大量的进程，数据库去世锁导致超时，前端终止了连续要求，但是SQL语句还在等待开释锁，这时就要重启数据库做事了或kill掉去世锁SQL进程了。
好了，关于502 bad gateway 报错就先谈论到这里，如果在开拓过程中还有其他缘故原由，欢迎在评论区留言评论。
总结HTTP状态码用来表示相应结果的状态，个中200是正常相应，4xx是客户端缺点，5xx是做事端缺点。客户端和做事端之间加入nginx，可以起到反向代理和负载均衡的浸染，客户端只管向nginx要求数据，并不关心这个要求详细由哪个做事器来处理。后端做事端运用如果发生崩溃，nginx在访问做事端时会收到做事端返回的RST报文，然后给客户端返回502报错。502并不是做事端运用发出的，而是nginx发出的。因此发生502时，后端做事端很可能没有没有干系的502日志，须要在nginx侧才能看到这条502日志。如果创造502，优先通过监控排查做事端运用是否发生过崩溃重启，如果是的话，再看下是否留下过崩溃堆栈日志，如果没有日志，看下是否可能是oom或者是其他缘故原由导致进程主动退出。如果进程也没崩溃过，去排查下nginx的日志，看下是否将要求打到了某个不有名IP端口上。
