502 Bad Gateway是nginx服务器上面经常遇到的问题，但是在网上查找资料的时候，95%的资料都是在讨论nginx+php-fpm的环境下如何如何处理。而我的环境是nginx + apache，为了把这个问题搞清楚，我希望通过这篇文章，能深入的对这个问题的解决思路做一个梳理。

502是nginx返回的错误

所有的502都是nginx返回的，在错误页面也可以看到只有nginx作为标识，没有看到apache。这说明502是在nginx这个环节出现了问题。所以，我们需要来再梳理一下，在nginx+apache这个环境中数据包的处理逻辑：

如上图，当请求到达nginx时，nginx将请求转发给apache进行处理，当apache将结果返回给nginx时，nginx再将结果展示给访客。但是，如果nginx转发请求之后，迟迟没有收到apache的结果，或者apache返回的结果和nginx预期的结果不对等，就会返回502错误。

那么这里面就包含了两个因素：

• 1）时间
• 2）数据

当处理时间超出预期时，可能产生502错误。当nginx得到的数据不符合预期时，也可能产生502错误。那么时间问题是怎么产生的呢？数据问题又是怎么产生的呢？

服务器性能造成的502问题

服务器的性能、配置的参数等，导致在整个请求处理过程中，请求被阻塞，从而导致请求处理时间过长，从而引起服务器假死等问题，其结果之一，就是nginx返回502错误。

机子硬件配置太低

服务器机器的配置确实太差的时候，环境跑起来其实是有点吃力的。服务器的硬件配置影响性能的，主要包括：内存、cpu、宽带、硬盘。

这些其实不必过多的去解释，大家都懂的。但是，这里面需要考虑的是，你的服务器到底配置多大的内存，多高的宽带，cpu多少核才好呢？你要这样去思考：

首先是cpu，它决定了程序运算的速度，并不是核数越多越好，因为一段程序的运行计算只需要那么多资源，多出来的cpu其实是浪费的。同一时间的访客数量运行不同的程序，就会使cpu占用率上升，你最好通过长期监控cpu的占用率，来了解你的当前cpu是否能够支持当前平均访客数量的运算需要，一旦超出某个值，就应该考虑加核。

内存也是同样的道理，内存是程序在执行过程中消耗掉的，当你的访客数上升的时候，内存就会被开销，你也应该长期去监控内存的占用情况，看到每天的峰值达到一个高度的时候，就考虑加内存。

cpu和内存、宽带都要用这种思维去考虑是否机子升级。当你升级到满足最高峰值的时候，502自然就不会出现了。

性能相关的服务器配置参数待优化

当你满足上面的硬件配置之后，就应该考虑一下服务器各个参数的优化。这里指的参数，是指上述nginx apache php mysql redis等他们在内存、IO上面的使用安排。

举一个例子，如果一台服务器内存为512M，系统占用了120M左右，其他一些服务占用了50M左右，现在有300M左右的内存留下来给napmr环境去运行。其中，redis的数据常驻内存，因此最好不要在这台服务器上使用。每一个访客访问某个网页的时候，nginx可能会用10M，apache用20M，php则根据该网页后台程序的逻辑，有可能用到8-32M，而如果这个页面需要连接Mysql进行数据库查询，Mysql又会根据连接和查询数不同，消耗掉可能16-64M的内存，这样算下来，同一时刻，单个访客可能就会消耗60-120M的内存，而你剩下的300M内存，最多也就能撑死5个访客，超过5个人的第6个人，就需要等待，直到前面的处理已经结束，内存被释放出来。（当然，这里仅仅是一个假设的例子）

而在nginx、apache、php的配置文件中，可以对这些消耗进行有限的配置。比如可以配置最大消耗内存，比如php最多允许消耗32M内存，当访客访问的页面php消耗的内存到达这个值的时候，就会在页面中返回错误结果，甚至直接白屏。这样，就可以为其他用户省下内存，第6个人进来时，内存还有，就可以直接打开页面，而无需等待内存释放。

除了内存的控制，服务器的配置参数中还有很多，可以有效对服务器资源进行分配。具体的这些配置，需要你去搜索nginx、apache、php相关的配置教程。

请求阻塞造成的502问题

在我们看到502的时候，所能了解到的，仅仅是nginx无法为你提供服务，返回的错误，而不知道后面具体是哪一个位置出了问题。网上大部分材料都说是php-fpm的配置问题，但实际上，问题可能会出现在php-fpm的后面环节。

我们来看一个情况：

上图中表示了一种情况，当php程序（运行时，而不是指代码执行）运行过程中，服务器突然内存占尽导致php进程崩溃，这个时候，php不会返回apache任何数据，而是apache监听到程序执行异常，这种异常让apache决定返回一个异常，而nginx在得到这个异常时，由于与预期得到的结果不同，所以返回了502.在这种情况中，问题并不是出现在apache这个环节，而是php这个环节。类似的，如果请求依赖于其他应用程序，这些应用程序突然崩溃的时候，也有可能返回502.

因此，要解决这个问题实在比较难，需要对整个运行机制做深入的监控，才能准确的把握问题的根源，才能定位解决问题。

一般这种监控可以通过以下途径去做：

• 1）日志
• 2）综合数据
• 3）逻辑分析

日志是比较靠谱的，例如上面这个案例中，日志可以这么去找。nginx的访问日志中记录了这条访问，再从apache中找到同样一条访问，再去分析php错误日志，找出最后几条错误是否是这次访问产生的。这样顺藤摸瓜，就可以大致定位错误引起的原因，在通过该原因具体分析引起这个错误的更深层次的原因，最终找到症结。

但是，为了提升性能，大多数服务器中没有保存日志，或者有些日志记录并不能帮助我们找到根源。这个时候就要你拥有数据分析和逻辑分析的能力，前提是你对这一整套的运行机制比较了解。通过服务器提供商提供的一些数据，服务器本身反馈的一些数据（如top free等命令得到的数据），以及日志记录，再按照请求运行的逻辑分析问题可能出现的位置，并且每个地方进行排查，一点一点去验证。

好了，本文主要是梳理了遇到502的解决思路，是提纲挈领式的提供思维方式。它不仅要求你能够完成服务器配置，而且要求你对服务器运行机制有更深入的了解，这或许是学习的一种有效方式。

2016-01-28 12295