刚工作那会，有一次，上游调用我服务的老哥说，你的服务报&34;。
当时那个服务里正好有个调用日志，平时会记录各种200,4xx状态码的信息。于是我跑到服务日志里去搜索了一下502这个数字，毫无发现。于是跟老哥说，&34;
现在想来，多少有些不好意思。
不知道有多少老哥是跟当时的们从状态码是什么开始聊起。
HTTP状态码
我们平时在浏览器里逛的某宝和某度，其实都是一个个前端网页。
一般来说，前端并不存储太多数据，大部分时候都需要从后端服务器那获取数据。
于是前后端之间需要通过TCP协议去建立连接，然后在TCP的基础上传输数据。
而TCP是基于数据流的协议，传输数据时，并不会为每个消息加入数据边界，直接使用裸的TCP进行数据传输会有&34;问题。
因此需要用特地的协议格式去对数据进行解析。于是在此基础上设计了HTTP协议。详细的内容可以看我之前写的《既然有HTTP协议，为什么还要有RPC》。
比如，我想要看某个商品的具体信息，其实就是前端发的HTTP请求中传入商品的id，后端返回的HTTP响应中返回商品的价格，商店名，发货地址的信息等。
这样，表面上，我们是在刷着各种网页，实际上背后正有多次HTTP消息在不断进行收发。
但问题就来了，上面提到的都是正常情况，如果有异常情况呢，比如前端发的数据，根本就不是个商品id，而是一张图片，这对于后端服务端来说是不可能给出正常响应的，于是就需要设计一套HTTP状态码，用来标识这次HTTP请求响应流程是否正常。通过这个可以影响浏览器的行为。
比方说一切正常，那服务端返回个200状态码，前端收到后，可以放心使用响应的数据。但如果服务端发现客户端发的东西异常，就响应个4xx状态码，意思是这是个客户端的错误，4xx里头的xx可以根据错误的类型，再细分成各种码，比如401是客户端没权限，404是客户端请求了一个根本不存在的网页。反过来，如果是服务器有问题，就返回5xx状态码。
但问题就来了。
服务端都有问题了，搞严重点，服务器可能直接就崩溃了，那它还怎么给你返回状态码？
是的，这种情况，服务端是不可能给客户端返回状态码的。所以说，一般情况下5xx的状态码其实并不是服务器返回给客户端的。
它们是由网关返回的，常见的网关，比如nginx。
nginx的作用
回到前后端交互数据的话题上，如果前端用户少，那后端处理起请求来，游刃有余。但随着用户越来越多，后端服务器受资源限制，cpu或者内存都可能会严重不足，这时候解决方案也很简单，多搞几台一样的服务器，这样就能将这些前端请求均摊给几个服务器，从而提升处理能力。
但要实现这样的效果，前端就得知道后端具体有哪些个服务器，并一一跟他们建立TCP连接。
也不是不行，但就是麻烦。
但这时候如果能有个中间层挡在它们中间就
以上就是朝夕生活（www.30zx.com）关于“502问题怎么排查？”的详细内容，希望对大家有所帮助！
