共计 5719 个字符，预计需要花费 15 分钟才能阅读完成。
前端报 502 bad gateway 怎么回事?502 Bad Gateway 服务器作为网关或者代理时，为了完成请求访问下一个服务器，但该服务器返回了非法的应答。
解决办法是：再刷新一下网页或清理一下电脑的缓冲文件在打开你想打开的网页就好了。一般情况下，这种办法是行得通的，但也不排除你所访问的网页被屏蔽的可能，如果你所访问的网页被屏蔽的话，就不管你怎么刷新也是没用的了。
1. 什么是 502 bad gateway 报错
简单来说 502 是报错类型代码 bad gateway 错误的网关
2. 产生 502 错误的原因
连接超时 我们向服务器器发送请求 由于服务器当前链接太多，导致服务器方面无法给于正常的响应, 产生此类报错，具体如下：
第一个原因:
DNS 缓冲。这种情况的通常原因是因为你在未开启 vpn 的情况下访问了 facebook 这样的网站。
这个时候自然访问不上，同时却在本机留下了缓冲。
这种情况通常在几分钟之内就可以访问了。也可以尝试 在 dos 窗口运行 ipconfig /flushdns，该命令会刷新 DNS 缓冲。
第二个原因:
你的浏览器开了代理什么的。确认一下关掉代理。
第三个原因：
dns 被劫持了，即使使用国外的 dns，也会被劫持。有些机子开 vpn 能够访问，有些 机子确不能。并且排除了代理、防火墙、本地网络的原因。这个时候同时 ping 远程网站，比如 facebook。不能访问的机子通常获取了一个怪异的 ip，从任何地方都 ping 不通的 ip。而能访问的机子 ip，在不能访问的机子上直接可以访问，也可以 ping 通。这种情况我们可以去掉 VPN 服务器的 DNS。
切换另外的 dns。在 windows 系统中，可以在本地网络连接的属性中，去掉默认的 dns，选用国外的 dns，比如 google 的。或 opendns。
3.502 错误的 HTTP 周期
任何客户端 (如 Web 浏览器或我们的 CheckUpDown 机器人) 经过下列循环时，与您的 Web 服务器沟通：
获取您的网站 IP 地址的 IP 名称 (您的网站 URL 的领导’http://‘)。这查找(转换的知识产权名称，IP 地址) 所提供的域名服务器(DNSs)。
打开一个 IP 套接字连接到该 IP 地址。写一个 HTTP 数据流通过该套接字。
从您的响应的 Web 服务器收到一个 HTTP 数据流。此数据流包含状态码的值是由 HTTP 协议。解析此数据流的状态码和其他有用信息。
这个错误发生在最后一步时，上面的客户端收到一个 HTTP 状态码，它确认为 502‘。
4. 固定 502 错误
一般这个问题是由于不良的 IP 之间的沟通后端计算机，包括您可能尝试访问的在 Web 服务器上的网站。在分析这个问题，您应该完全清除浏览器缓存。
如果您上网时在您尝试访问的所有网站上都看这个问题，有两种可能
1 )你的 ISP 出了重大设备故障 / 过载
2 )有问题的内部互联网连接如您的防火墙无法正常运作。
在第一种情况下，只有您的 ISP 可以帮助您。在第二种情况下，就需您自己解决任何阻止您进入互联网的问题。
如果您只有在部分尝试访问的网站中出现此问题，那就很可能是一个问题，即这些网站之一，其设备故障或超载。联系网站的管理员。
5. 出现 502 bad gateway 如何解决问题
最简单的方法：CTRL+F5 强制刷新
最好的解决办法当然还是在服务器上做 对大家来说不太可能 , 那么我们有什么解救的方法呢? 说白了很简单, 就是——刷新(不是一般的刷新哦)
刷新的原理：很多人可能不知道 刷新也是有两种的。所谓刷新其实就是从服务器下载数据到本地的硬盘浏览器, 再从本地硬盘种读取数据到浏览器显示给我们看。
①基本刷新：就是点击刷新或者使用 F5 快捷键, 基本刷新只是从本地的硬盘重新拿取数据到浏览器，并不重新向服务器发出请求。大部分用户很多时候都是这样刷新的，遇到 502 报错的就没有任何效果。
②从服务器刷新：如果你重新直接点击你想要浏览的网页链接，你会发现刚才还是显示 502 bad getway 的页面现在又可以正常浏览了! 明白道理了吧? 当你点击你想要浏览的网页链接的时候，是会从服务器重新下载数据的。解决方法就是从服务器上刷新：快捷键 ctrl+F5，这样就是重新向服务器发送请求了。如果服务器能正常给予你响应你就可以看到页面了。
另附：
nginx 502 bad gateway 错误的原因及解决方法
nginx 502 bad Gateway 的错误已经遇到好几次了，这里做一下记录，备忘哈哈。
会有好多种情况出现 502 错误，下面我们分情况来说一下。
一、fastcgi 缓冲区设置过小
出现错误，首先要查找 nginx 的日志文件，目录为 /var/log/nginx，在日志中发现了如下错误。
2013/01/17 13:33:47 [error] 15421#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;
############### 添加这 3 行
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
…………
}
三、默认 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 时间
http {
fastcgi_connect_timeout 300;
fastcgi_send_timeout 300;
fastcgi_read_timeout 300;
……
}
nginx 502 bad gateway
一些运行在 Nginx 上的网站有时候会出现“502 Bad Gateway”错误，有些时候甚至频繁的出现。以下是小编搜集整理的一些 Nginx 502 错误的排查方法，供参考：
Nginx 502 错误的原因比较多，是因为在代理模式下后端服务器出现问题引起的。这些错误一般都不是 nginx 本身的问题，一定要从后端找原因! 但 nginx 把这 些出错都揽在自己身上了，着实让 nginx 的推广者备受置疑，毕竟从字眼上理解，bad gateway? 不就是 bad nginx 吗? 让不了解的人看到，会直接把责任推在 nginx 身上，希望 nginx 下一个版本会把出错提示写稍微友好一些，至少不会是现在简单的一句 502 Bad Gateway，另外还不忘附上自己的大名。
Nginx 502 的触发条件
502 错误最通常的出现情况就是后端主机当机。在 upstream 配置里有这么一项配置：proxy_next_upstream，这个配置指定了 nginx 在从一个后端主机取数据遇到何种错误时会转到下一个后端主机，里头写上的就是会出现 502 的所有情况拉，默认是 error timeout。error 就是当机、断线之类的，timeout 就是读取堵塞超时，比较容易理解。我一般是全写上的：
proxy_next_upstream error timeout invalid_header http_500 http_503;
不过现在可能我要去掉 http_500 这一项了，http_500 指定后端返回 500 错误时会转一个主机，后端的 jsp 出错的话，本来会打印一堆 stacktrace 的错误信息，现在被 502 取代了。但公司的程序员可不这么认为，他们认定是 nginx 出现了错误，我实在没空跟他们解释 502 的原理 了……
503 错误就可以保留，因为后端通常是 apache resin，如果 apache 死机就是 error，但 resin 死机，仅仅是 503，所以还是有必要保留的。
解决办法
遇到 502 问题，可以优先考虑按照以下两个步骤去解决。
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 的内存不足了。
如果这样修改了还解决不了问题，可以参考下面这些方案：
一、max-children 和 max-requests
一台服务器上运行着 nginx php(fpm) xcache，访问量日均 300W pv 左右。
最近经常会出现这样的情况：php 页面打开很慢，cpu 使用率突然降至很低，系统负载突然升至很高，查看网卡的流量，也会发现突然降到了很低。这种情况只持续数秒钟就恢复了。
检查 php-fpm 的日志文件发现了一些线索。
Sep 30 08:32:23.289973 [NOTICE] fpm_unix_init_main(), line 271: getrlimit(nofile): max:51200, cur:51200 Sep 30 08:32:23.290212 [NOTICE] fpm_sockets_init_main(), line 371: using inherited socket fd=10,“127.0.0.1:9000″ Sep 30 08:32:23.290342 [NOTICE] fpm_event_init_main(), line 109: libevent: using epoll Sep 30 08:32:23.296426 [NOTICE] fpm_init(), line 47: fpm is running, pid 30587
在这几句的前面，是 1000 多行的关闭 children 和开启 children 的日志。
原来，php-fpm 有一个参数 max_requests，该参数指明了，每个 children 最多处理多少个请求后便会被关闭，默认的设置是 500。因为 php 是把请求轮询给每个 children，在大流量下，每个 childre 到达 max_requests 所用的时间都差不多，这样就造成所有的 children 基本上在同一时间 被关闭。
在这期间，nginx 无法将 php 文件转交给 php-fpm 处理，所以 cpu 会降至很低(不用处理 php，更不用执行 sql)，而负载会升至很高(关 闭和开启 children、nginx 等待 php-fpm)，网卡流量也降至很低(nginx 无法生成数据传输给客户端)
解决问题很简单，增加 children 的数量，并且将 max_requests 设置为 0 或者一个比较大的值：
打开 /usr/local/php/etc/php-fpm.conf 调大以下两个参数(根据服务器实际情况，过大也不行)
5120 600
然后重启 php-fpm。
二、增加缓冲区容量大小
将 nginx 的 error log 打开，发现“pstream sent too big header while reading response header from upstream”这样的错误提示。查阅了一下资料，大意是 nginx 缓冲区有一个 bug 造成的, 我们网站的页面消耗占用缓冲区可能过大。参考老外写的修 改办法增加了缓冲区容量大小设置，502 问题彻底解决。后来系统管理员又对参数做了调整只保留了 2 个设置参数：client head buffer，fastcgi buffer size。
三、request_terminate_timeout
如果主要是在一些 post 或者数据库操作的时候出现 502 这种情况，而不是在静态页面操作中常见，那么可以查看一下 php-fpm.conf 设置中的一项：
request_terminate_timeout
这个值是 max_execution_time，就是 fast-cgi 的执行脚本时间。
0s
0s 为关闭，就是无限执行下去。(当时装的时候没仔细看就改了一个数字)问题解决了，执行很长时间也不会出错了。优化 fastcgi 中，还可以改改这个值 5s 看看效果。
php-cgi 进程数不够用、php 执行时间长、或者是 php-cgi 进程死掉，都会出现 502 错误。
