502 Bad Gateway

各位看官，网站打不开是不是很捉急；昨天小编的网站出现了502 bad gateway，“bad gateway”百度翻译是错误的网关，专业解释是Web服务器作为网关或代理服务器时收到无效的响应。 用我们的口语说是运行网站的服务器暂时挂了（不响应）。下面小编为大家分享下502 bad gateway 什么意思，502 bad gateway怎么解决。

产生错误的原因

连接超时 我们向服务器器发送请求 由于服务器当前链接太多，导致服务器方面无法给于正常的响应,产生此类报错。

502 bad gateway怎么解决

普通访客
一般情况下稍候访问或者按下快捷键 ctrl+F5强制刷新一下，这样是重新向服务器发送请求了。再或者清理一下电脑的缓冲文件.（如果一直都是这样，我们只能等管理员来解决）

管理员

1.查看当前的PHP FastCGI进程数是否够用

netstat -anpo | grep "php-cgi" | wc -l

如果实际使用的"FastCGI进程数"接近预设的"FastCGI进程数"，那么，说明"FastCGI进程数"不够用，需要增大。

2.部分PHP程序的执行时间超过了Nginx的等待时间，可以适当增加nginx.conf配置文件中FastCGI的timeout时间。

.....
http
{
......
fastcgi_connect_timeout 300;
fastcgi_send_timeout 300;
fastcgi_read_timeout 300;
......
}
php.ini中memory_limit设低了会出错，修改了php.ini的memory_limit为64M，重启nginx，发现好了，原来是PHP的内存不足了
总结，网站打不开，出现错误代码“502 bad gateway”，一般都是php-cgi进程数不够用、php执行时间长、或者是php-cgi进程死掉。

服务器常见错误代码解释

500 内部服务错误；顾名思义500错误一般是服务器遇到意外情况，而无法完成请求。
501 服务器不具备完成请求的功能；例如，服务器无法识别请求方法时可能会返回此代码。
503　服务器目前无法使用（由于超载或停机维护）；通常，这只是暂时状态。（服务不可用）
504 网关超时；通常web服务器故障、程序进程不够
505　服务器不支持请求中所用的 HTTP 协议版本（HTTP 版本不受支持）

HTTP/1.1: Status Code Definitions
10状态码定义
下面描述了每个状态代码，包括可以遵循的方法的描述以及响应中所需的任何元信息。

10.1信息1xx
这类状态码表示临时响应，仅由状态行和可选标题组成，并以空行结束。这类状态码没有必要的标题。由于HTTP / 1.0没有定义任何1xx状态码，除了在实验条件下，服务器不能向HTTP / 1.0客户端发送1xx响应。
客户端必须准备好在定期响应之前接受一个或多个1xx状态响应，即使客户端不期望100（继续）状态消息。意外的1xx状态响应可能被用户代理忽略。
代理必须转发1xx响应，除非代理和客户端之间的连接已经关闭，或者除非代理本身要求产生1xx响应。（例如，如果一个
代理在转发请求时会添加一个“Expect：100-continue”字段，则不需要转发相应的100（Continue）响应。）
10.1.1 100继续
客户端应该继续其请求。此临时响应用于通知客户端请求的初始部分已被接收并且尚未被服务器拒绝。客户端应该继续发送请求的其余部分，或者如果请求已经完成，则忽略这个响应。请求完成后，服务器必须发送最终响应。关于这个状态码的使用和处理的详细讨论见8.2.3节。

10.1.2 101交换协议
服务器通过升级消息头字段（14.42节）了解并愿意遵守客户端的请求，以改变在此连接上使用的应用协议。服务器将切换到响应的升级头字段定义的那些协议，紧接在终止101响应的空行之后。
协议只有在有利的情况下才能切换。例如，切换到较新版本的HTTP比旧版本更有优势，当交付使用这些特性的资源时，切换到实时同步协议可能是有利的。

10.2成功2xx
这类状态码表明客户的请求已被成功接收，理解和接受。

10.2.1 200 OK
请求已成功。与响应一起返回的信息取决于请求中使用的方法，例如：
在响应中发送GET请求资源对应的实体;
HEAD与请求的资源对应的实体头字段在响应中发送而没有任何消息体;
发布描述或包含行动结果的实体;
跟踪由最终服务器收到的包含请求消息的实体。

10.2.2 201创建
请求已经完成并导致创建新的资源。新创建的资源可以由响应实体中返回的URI（s）引用，其中由Location标题字段给出的资源的最具体的URI。响应应该包括一个包含资源特性和位置的实体，用户或用户代理可以从中选择一个最合适的实体。实体格式由Content-Type头域中给出的媒体类型指定。源服务器必须在返回201状态码之前创建资源。如果这个动作不能立即执行，那么服务器应该用202（Accepted）响应来响应。
一个201响应可以包含一个ETag响应头域，表示刚创建的被请求变量的实体标签的当前值，见14.19节。

10.2.3接受
该请求已被接受处理，但处理尚未完成。该请求可能最终也可能不会最终被执行，因为在处理实际发生时它可能被禁止。没有这样的异步操作重新发送状态码的功能。

202的回应是故意不承诺的。它的目的是允许一个服务器接受一个其他进程的请求（也许是一个只能每天运行一次的面向批处理的进程），而不需要用户代理与服务器的连接持续到进程完成。用这个响应返回的实体应该包含一个请求当前状态的指示，或者一个指向状态监视器的指针，或者一些估计用户什么时候能够满足请求的指针。

10.2.4 203非权威信息
实体头中返回的元信息不是从源服务器可用的权威集合，而是从本地或第三方副本收集的。呈现的集合可以是原始版本的子集或超集。例如，包括关于资源的本地注释信息可能会导致源服务器已知的元信息的超集。使用此响应代码不是必需的，只有当响应否则是200（正常）时才适用。

10.2.5 204没有内容
服务器已经完成了请求，但不需要返回实体主体，并且可能想要返回更新后的元信息。响应可以包含新的或更新的实体头信息，如果存在的话应该与请求的变体相关联。

如果客户端是一个用户代理，它不应该从导致请求被发送的文档视图改变它的文档视图。尽管任何新的或更新的元信息应该被应用到当前在用户代理的活动视图中的文档，但是这个响应主要是为了允许在不改变用户代理的活动文档视图的情况下进行动作输入。

204响应绝不能包含消息体，因此总是由头字段后的第一个空行终止。

10.2.6 205重置内容
服务器已经完成了请求，用户代理应该重置导致请求发送的文档视图。该响应主要是为了允许通过用户输入进行动作的输入，然后清除输入的形式，以便用户可以容易地启动另一个输入动作。答复不得包含一个实体。

10.2.7 206部分内容
服务器已经完成了资源的部分GET请求。该请求必须包含一个Range头域（14.35节），表示期望的范围，并且可以包含一个If-Range头域（14.27节）来使请求有条件。

响应必须包含以下头部字段：

  - 指示
    包含在此响应范围内的Content-Range标题字段（14.16节），或者
    包含每个部分的Content-Range字段的多部分/字节范围内容类型。如果
    Content-Length头字段出现在响应中，它的
    值必须与
    消息体中传送的实际OCTET数相匹配。
  - 日期
  -  ETag和/或内容 - 位置，如果标题已经被发送
    到200响应相同的请求
  - 过期，高速缓存控制和/或变化，如果字段值可能
    不同于以前任何响应中发送的相同
    变体

如果206响应是使用强大缓存验证器的If-Range请求的结果（请参阅第13.3.3节），则响应不应包含其他实体标头。如果响应是使用弱验证器的If-Range请求的结果，那么响应绝不能包含其他实体头; 这可以防止缓存的实体和更新的标题之间的不一致。否则，响应必须包含所有将返回200（OK）响应给相同请求的实体头。

如果ETag或Last-Modified头部不完全匹配，则缓存不得将206响应与其他先前缓存的内容组合在一起，见13.5.4。

不支持Range和Content-Range标头的缓存不能缓存206（部分）响应。

10.3重定向3xx
这类状态码表明用户代理需要采取进一步行动来完成请求。当且仅当在第二个请求中使用的方法是GET或HEAD时，所需的动作可以由用户代理执行，而不与用户交互。客户端应该检测到无限重定向循环，因为这样的循环为每个重定向生成网络流量。

  注意：此规范的以前版本推荐
  最多五个重定向。内容开发者应该意识到
  可能有客户实现了这样一个固定的
  限制。

10.3.1 300多种选择
所请求的资源对应于一组表示中的任何一个，每个表示具有其自己的特定位置，并且正在提供代理驱动的协商信息（部分12），使得用户（或用户代理）可以选择优选的表示并将其重定向请求到那个位置。

除非是HEAD请求，否则响应应该包含一个实体，该实体包含一个资源特性和位置列表，用户或用户代理可以从中选择一个最合适的资源。实体格式由Content-Type头字段中给出的媒体类型指定。取决于格式和功能

用户代理，选择最合适的选择可以自动执行。但是，这个规范没有为这种自动选择定义任何标准。

如果服务器有优先选择的表示，它应该在位置字段中包含该表示的特定URI; 用户代理可以使用位置字段值进行自动重定向。除非另有说明，否则此响应是可缓存的。

10.3.2 301永久移动
被请求的资源已经被分配了一个新的永久性的URI，任何将来对这个资源的引用都应该使用返回的URI之一。具有链接编辑功能的客户端应尽可能将对Request-URI的引用重新链接到服务器返回的一个或多个新引用。除非另有说明，否则此响应是可缓存的。

新的永久URI应该由响应中的位置字段给出。除非请求方法是HEAD，否则响应的实体应该包含一个超链接到新URI的短超文本记录。

如果接收到301状态代码以响应GET或HEAD以外的请求，则用户代理不能自动重定向请求，除非用户可以确认，因为这可能会改变发出请求的条件。

  注意：在
  收到301状态码后自动重定向POST请求时，一些现有的HTTP / 1.0用户代理
  将错误地将其更改为GET请求。

10.3.3 302发现
请求的资源暂时驻留在不同的URI下。由于重定向有时可能会被改变，所以客户端应该继续使用Request-URI来处理将来的请求。如果由Cache-Control或Expires标头字段指示，则该响应仅可缓存。

临时URI应该由响应中的位置字段给出。除非请求方法是HEAD，否则响应的实体应该包含一个超链接到新URI的短超文本记录。

如果接收到302状态码来响应除GET或HEAD以外的请求，用户代理不能自动重定向请求，除非用户可以确认，因为这可能会改变发出请求的条件。

  注意：RFC 1945和RFC 2068指定客户端不允许
  更改重定向请求上的方法。然而，大多数
  现有的用户代理实现将302看作是303 
  响应，无论
  原始请求方法如何，都对Location字段值执行GET 。状态码303和307已
  被添加到希望明确地清楚
  客户端期望哪种反应的服务器。

10.3.4 303见其他
对请求的响应可以在不同的URI下找到，并且应该在该资源上使用GET方法进行检索。此方法主要用于允许POST激活的脚本的输出将用户代理重定向到选定的资源。新的URI不是最初请求的资源的替代参考。303响应不能被缓存，但对第二个（重定向的）请求的响应可能是可缓存的。

不同的URI应该由响应中的位置字段给出。除非请求方法是HEAD，否则响应的实体应该包含一个超链接到新URI的短超文本记录。

  注意：许多pre-HTTP / 1.1用户代理不了解303 
  状态。当与这种客户端的互操作性是一个问题时，
  可以使用302状态码来代替，因为大多数用户代理对
  302响应作出反应，如303所述。

10.3.5 304未修改
如果客户端执行了条件GET请求并且允许访问，但是文档没有被修改，那么服务器应该用这个状态码进行响应。304响应不能包含消息体，因此总是由头字段后面的第一个空行终止。

响应必须包含以下头部字段：

  - 日期，除非第14.18.1节要求省略

如果无时钟源服务器服从这些规则，并且代理和客户端将自己的日期添加到没有收到的任何响应（如[RFC 2068]第14.19节中已经指定的那样），缓存将正常运行。

  -  ETag和/或内容 - 位置，如果标题已经被发送
    到200响应相同的请求
  - 过期，高速缓存控制和/或变化，如果字段值可能
    不同于以前任何响应中发送的相同
    变体

如果条件GET使用了强大的缓存验证器（请参阅13.3.3节），那么回应不应包含其他实体标题。否则（即，条件GET使用弱验证器），响应不能包含其他实体头; 这可以防止缓存的实体和更新的标题之间的不一致。

如果304响应指示当前未被高速缓存的实体，则高速缓存必须忽略该响应并在没有条件的情况下重复该请求。

如果高速缓存使用收到的304响应来更新高速缓存条目，则高速缓存必须更新条目以反映响应中给出的任何新的字段值。

10.3.6 305使用代理
被请求的资源必须通过Location字段给出的代理来访问。位置字段给出了代理的URI。预计收件人通过代理重复这个单一的请求。305响应只能由原始服务器产生。

  注意：RFC 2068不清楚，305是打算重定向一个
  请求，并且只能由原始服务器生成。没有
  观察到这些限制会带来重大的安全后果。

10.3.7 306（未使用）
306状态码用于规范的以前版本，不再使用，代码保留。

10.3.8 307临时重定向
请求的资源暂时驻留在不同的URI下。由于重定向有时可能会被修改，所以客户端应该继续使用Request-URI来处理将来的请求。如果由Cache-Control或Expires标头字段指示，则该响应仅可缓存。

临时URI应该由响应中的位置字段给出。除非请求方法是HEAD，否则响应实体应该包含一个超链接到新URI的简短超文本注释，因为许多pre-HTTP / 1.1用户代理不了解307的状态。因此，注释应该包含用户在新的URI上重复原始请求所需的信息。

如果接收到307状态码来响应除GET或HEAD以外的请求，则用户代理不能自动重定向请求，除非用户可以确认，因为这可能会改变发出请求的条件。

10.4客户端错误4xx
4xx类状态码用于客户端似乎有错误的情况。除了响应HEAD请求外，服务器应该包含一个包含错误情况说明的实体，以及它是临时还是永久状态。这些状态码适用于任何请求方法。用户代理应该向用户显示任何包含的实体。

如果客户端正在发送数据，那么在服务器关闭输入连接之前，使用TCP的服务器实现应当小心，以确保客户端确认收到了包含响应的数据包。如果客户端在关闭后继续向服务器发送数据，则服务器的TCP堆栈将向客户端发送一个重置数据包，这可能会清除客户端的未确认输入缓冲区，然后才能被HTTP应用程序读取和解释。

10.4.1 400错误的请求
由于格式错误，服务器无法理解请求。客户端不应该不加修改地重复请求。

10.4.2 401未经授权
该请求需要用户认证。响应必须包含一个WWW-Authenticate头域（14.47节），其中包含一个适用于所请求资源的挑战。客户端可以用合适的授权头域来重复请求（见14.8节））。如果请求已经包含了授权凭证，那么401响应表明这些凭证的授权已被拒绝。如果401响应包含与之前的响应相同的挑战，并且用户代理已经尝试了至少一次认证，则用户应该被呈现给响应中给出的实体，因为该实体可能包括相关的诊断信息。HTTP访问认证在“HTTP认证：基本和摘要访问认证” [43]中解释。

10.4.3需要付款402
此代码保留供将来使用。

10.4.4 403禁止
服务器了解请求，但拒绝履行。授权不起作用，请求不应重复。如果请求方法不是HEAD，服务器希望公开为什么请求没有被满足，那么它应该描述拒绝的原因。如果服务器不希望将这些信息提供给客户端，则可以使用状态码404（Not Found）。

10.4.5 404未找到
服务器没有找到任何匹配的请求的URI。没有迹象表明病情是暂时的还是永久性的。如果服务器通过一些内部可配置的机制知道旧资源永久不可用并且没有转发地址，则应该使用410（Gone）状态码。当服务器不希望揭示为什么请求被拒绝，或者没有其他响应适用时，通常使用这种状态码。

10.4.6 405方法不允许
Request-URI中指定的方法不允许使用Request-URI标识的资源。响应必须包含一个Allow头，其中包含所请求资源的有效方法列表。

10.4.7 406不可接受
由请求标识的资源只能根据在请求中发送的接受头来生成具有不可接受的内容特征的响应实体。

除非是HEAD请求，否则响应应该包含一个实体，该实体包含一个可用的实体特征和位置列表，用户或用户代理可以从中选择一个最合适的实体特征和位置。实体格式由Content-Type头域中给出的媒体类型指定。根据用户代理的格式和功能，可以自动选择最合适的选项。但是，这个规范没有为这种自动选择定义任何标准。

  注意：HTTP / 1.1服务器被允许
  根据
  请求中发送的Accept头返回不可接受的响应。在某些情况下，这甚至可能比发送
  406响应更可取。鼓励用户代理检查
  传入响应的标题以确定它是否可接受。

如果响应可能是不可接受的，用户代理应该暂时停止接收更多的数据，并询问用户对进一步操作的决定。

10.4.8 407需要代理验证
此代码类似于401（未授权），但表示客户端必须首先使用代理进行身份验证。代理务必返回一个代理 - 认证标题字段（14.33节），其中包含一个适用于所请求资源的代理的挑战。客户端可以用合适的Proxy-Authorization头域来重复请求（见14.34节）。HTTP访问认证在“HTTP认证：基本和摘要访问认证” [43]中解释。

10.4.9 408请求超时
客户端在服务器准备等待的时间内没有发出请求。客户可以随时重复请求而不做任何修改。

10.4.10 409冲突
由于与当前资源状态的冲突，请求无法完成。此代码仅在预期用户可能能够解决冲突并重新提交请求的情况下才被允许。响应主体应该包括足够的

信息供用户识别冲突的来源。理想情况下，响应实体会为用户或用户代理提供足够的信息来解决问题; 然而，这可能是不可能的，也不是必需的。

冲突最有可能发生在响应PUT请求。例如，如果正在使用版本控制，并且包含PUT的实体更改为与先前（第三方）请求相冲突的资源，则服务器可能会使用409响应来指示无法完成请求。在这种情况下，响应实体可能会以响应Content-Type定义的格式包含两个版本之间的差异列表。

10.4.11 410去
所请求的资源在服务器上不再可用，并且不知道转发地址。预计这种情况将被视为永久性的。具有链接编辑功能的客户端应该在用户批准后删除对Request-URI的引用。如果服务器不知道或无法确定该条件是否是永久性的，则应该使用状态码404（Not Found，未找到）。除非另有说明，否则此响应是可缓存的。

410响应的主要目的是通过通知接收方资源被故意不可用以及服务器所有者希望去除到该资源的远程链接来帮助网络维护的任务。这样的事件对于有限时间的促销服务以及属于不再在服务器现场工作的个人的资源是很常见的。没有必要将所有永久不可用的资源标记为“不存在”或将标记保留任意时间长度 - 这由服务器所有者决定。

10.4.12 411所需长度
服务器拒绝接受没有定义的内容长度的请求。如果请求消息中添加了一个包含消息体长度的有效的Content-Length头域，客户端可以重复请求。

10.4.13 412 先决条件失败
在服务器上测试时，在一个或多个请求头字段中给出的前提条件评估为false。此响应代码允许客户端将当前资源元信息（头字段数据）的先决条件放置，从而防止将所请求的方法应用于除预期的资源之外的资源。

10.4.14 413请求实体太大
服务器拒绝处理请求，因为请求实体大于服务器愿意或能够处理的大小。服务器可以关闭连接以防止客户端继续请求。

如果条件是临时的，那么服务器应该包含一个Retry-After头域来表示它是临时的，在什么时候客户端可以再次尝试。

10.4.15 414请求URI太长
服务器拒绝服务请求，因为Request-URI比服务器愿意解释的长。这种罕见的情况只有当客户端不正确地将POST请求转换为具有长查询信息的GET请求时，当客户端已经下降到重定向的URI“黑洞”（例如，指向的重定向的URI前缀它本身的后缀），或者当服务器受到试图利用固定长度缓冲区中存在的安全漏洞来读取或操纵Request-URI的客户端的攻击时。

10.4.16 415不支持的媒体类型
服务器拒绝为请求提供服务，因为请求的实体的格式不是所请求方法的请求资源所支持的格式。

10.4.17 416要求范围不满足
如果一个请求包含一个Range request-header字段（14.35节），并且这个字段中的范围说明符值都不重叠所选资源的当前范围，那么服务器应该返回一个带有这个状态码的响应，而请求没有包括一个If-Range请求标题字段。（对于字节范围，这意味着所有字节范围规范值的第一个字节位置大于所选资源的当前长度。）

当这个状态码返回一个字节范围的请求时，响应应该包含一个Content-Range实体标题字段，指定所选资源的当前长度（见14.16节 ）。这个响应不能使用multipart / byteranges内容类型。

10.4.18 417期望失败
期望的请求头字段（请参阅第14.20节）给出的期望不能被这个服务器满足，或者如果服务器是代理服务器有明确的证据表明下一个跃点服务器不能满足请求。

10.5服务器错误5xx
以数字“5”开头的响应状态代码表示服务器意识到错误或不能执行请求的情况。除了响应HEAD请求外，服务器应该包含一个包含错误情况说明的实体，以及它是临时还是永久状态。用户代理应该向用户显示任何包含的实体。这些响应代码适用于任何请求方法。

10.5.1 500内部服务器错误
服务器遇到意外情况，阻止它履行请求。

10.5.2 501未实施
服务器不支持完成请求所需的功能。当服务器不能识别请求方法并且不能支持任何资源时，这是相应的响应。

10.5.3 502错误的网关
服务器作为网关或代理服务器，在尝试执行请求时从其所访问的上游服务器收到无效响应。

10.5.4 503服务不可用
由于服务器暂时过载或维护，服务器当前无法处理该请求。这意味着这是一个暂时的情况，经过一段时间后会缓解。如果已知，则可以在Retry-After标题中指示延迟的长度。如果没有给出Retry-After，那么客户端应该像处理500响应那样处理响应。

  注意：503状态码的存在并不意味着
  服务器在过载时必须使用它。一些服务器可能希望
  简单地拒绝连接。

10.5.5 504网关超时
作为网关或代理的服务器在尝试完成时需要访问URI（例如，HTTP，FTP，LDAP）或某些其他辅助服务器（例如DNS）指定的上游服务器时没有收到及时的响应请求。

  注意：对实现者的注意：
  当DNS查找超时时，一些已部署的代理已知返回400或500。

10.5.6不支持505 HTTP版本
服务器不支持或拒绝支持请求消息中使用的HTTP协议版本。服务器正在指示它不能或不愿意使用与客户端相同的主要版本来完成请求，如3.1节所述 ，而不是使用此错误消息。响应应该包含一个实体，描述为什么该版本不被支持以及该服务器支持哪些其他协议。

仅学习，来源于网络，侵删。