502，504在超时场景下很容易被混同，辨别起来有肯定难度；
499 产生的起因往往也会和 504 会有外在关联。
注：本文为间断测试，所以批改nginx或php-fpm配置后，记得重启
根本环境(LNMP)：
nginx 配置
fastcgi_connect_timeout 5; # nginx连贯fastcgi的超时工夫
fastcgi_send_timeout 10; #nginx往fastcgi发送参数的超时工夫
fastcgi_read_timeout 10; #nginx从fastcig获取数据的超时工夫
php-fpm 配置
request_terminate_timeout = 30 ; 一次申请的最长执行工夫
PHP脚本：
nginx的webroot创立codetest.php文件，通过拜访localhost/codetest.php复现http响应code；
499 复现
php-fpm.conf：
request_terminate_timeout=30
nginx：
fastcgi_read_timeout 5;
代码：
sleep(15);
echo 'hello world';
499报错信息： Client Closed Request；即 客户端被动断开连接。
指一次http申请在客户端指定的工夫内没有返回响应，此时，客户端会被动断开连接，此时表象为客户端无响应返回；
此状态码在浏览器申请时简直不可见，因为浏览器默认超时工夫很长；
多见于业务架构中的服务模块之间的调用。
复现路径:
在linux终端应用curl命令申请，-m 示意超时工夫，单位秒
curl -i -m 3 http://127.0.0.1/codetest.php
返回：
Operation timed out after 3004 milliseconds with 0 bytes received
此时，nginx的 access_log 会呈现如下信息："HEAD /codetest.php HTTP/1.1" 499
502 复现
502，Bad Gateway，网关谬误，它往往示意网关从上游服务器中接管到的响应是有效的。
先来理解一下网关是什么含意
从宏观定义上来说只有是连贯两个不同网络设备的都能够叫网关，具体到Http申请这里，网关就是指是转发其余服务器通信数据的服务器，于本文而言，Nginx 就是网关。
502并不是指网关自身出了问题，而是从上游接管响应出了问题，比方因为上游服务本身超时导致不能产生响应数据，或者上游不依照协定约定来返回数据导致网关不能失常解析。
复现门路-1
敞开php-fpm过程，返回502。
这个比拟容易了解，参照下面的定义，因为php-fpm过程敞开，nginx连贯不上php-fpm，即nginx不能收从下层接管到响应数据。
nginx 谬误日志相似如下内容：
connect() to unix:xxxx/php-cgi.sock failed (2: No such file or directory) while connecting to upstream
复现门路-2
启动php-fpm过程，批改php-fpm.conf的 request_terminate_timeout 和php代码的 sleep 工夫来复现。
php代码：
`sleep(15);
echo 'hello world';`
php-fpm.conf
request_terminate_timeout=5
nginx
fastcgi_read_timeout 10;
php-fpm.conf设置的最大执行工夫是5s，然而php脚本须要的执行工夫大于15s，所以php-fpm过程执行5s时就回退出，此时php脚本没有失常执行实现，所以返回给网关Nginx的数据异样，于是导致502。
php-fpm谬误日志如下：
script '/webroot/codetest.php' (request: "GET /codetest.php") execution timed out (5.161544 sec), terminating
nginx谬误日志
recv() failed (104: Connection reset by peer) while reading response header from upstream
503 复现
503，Service Unavailable，服务不可用；
如果你搜寻 503，大部分文章会通知你，这是服务器在保护或者过载，高并发下个别会呈现此状态值；
严格来说，除非是DDoS攻打之类间接导致服务器宕机了，否则高并发并不会间接触发 503，而是触发 502 才对；
参考下面的 502 复现场景，高并发最间接的影响是，没有足够的 PHP 过程来解决客户端申请，而个别NGINX承载的连接数是远远大于PHP-fpm的，所以问题大概率不是NGINX这里；
如果想复现 NGINX-503 谬误，能够通过设置 NGINX 的 连接数限度来复现；
具体路径是：设置 limit_conn；
在NGINX配置文件中的 http 模块增加如下：limit_conn_zone $binary_remote_addr zone=per_ip:10m;
意思是：对用户IP进行并发计数，将计数内存区命名为 per_ip，设置计数内存区大小为10MB；
之后在 http 模块下的 server 模块增加相似如下限度：
## 残缺配置demohttp{ limit_conn_zone $binary_remote_addr zone=per_ip:10m; server { location /{ limit_conn per_ip 3; # 限度用户ip的并发连接数为3 root…… index…… } }}最初开启多线程，或者应用 ab 等压测工具，将并发数调到大于 3（因为下面的demo设置为最大连接数 3）；
而后去拜访接口codetest.php，即可复现 503 谬误。
因而，常见的 503 大多是NGINX开启了并发连接数限度导致，比方，你的接口被爬虫抓取；
如果是通过在PHP层通过redis限度拜访频次，则可抛出自定义的谬误，比方，401 等；
所以高并发呈现 503，并不是相对的，须要辩证的去对待，这里只是列举了一种可能。
504 复现
504，Gateway Timeout，网关超时。
它示意网关没有从上游及时获取响应数据。留神它和502在超时场景下的区别，502是指上游php-fpm因为超过本身容许的执行工夫而不能失常生成响应数据，而504是指在php-fpm还未执行实现的某一时刻，因为超过了nginx本身的超时工夫，nginx则认为上游php-fpm没有依照设置工夫返回响应数据就会返回504， 此时对于php-fpm而言还会继续执行上来，直到执行实现。
复现门路
代码：
`sleep(15);
echo 'hello world';`
php-fpm.conf
request_terminate_timeout=30
nginx
fastcgi_read_timeout 5;
codetest.php脚本执行工夫须要15s，小于php-fpm设置的一次申请的超时工夫30s，所以php脚本可失常实现；
但nginx从php-fpm读取数据的超时工夫为5s，所以在5s时，PHP未执行实现，但nginx的超时等待时间到了，于是返回504。
nginx谬误日志
upstream timed out (110: Connection timed out) while reading response header from upstream
面试Summary：
- 499 是因为超过客户端设置的申请超时工夫，客户端被动敞开连贯；
- 502 是因为 php-fpm 在本身的执行工夫要求内无奈按时实现，无奈返给NGINX失常的响应值；
- 504 是 php-fpm 在 NGINX 设置的超时工夫内无奈按时实现；
- 503 大多由NGINX开启了连接数限度后的高并发起因产生；
499，502，504，都是因超时而产生，区别在于，谁超了谁的时。
499 是超了客户端自身的连接时间；
502 是超了 php-fpm 的执行工夫；
504 是超了 NGINX 容许的最大读取工夫。