我相信有些人在面试运维类岗位的时候会碰到对方问关于这方面的问题，我这里通过几个实验来复现这个情况，并做出相关分析，我希望大家看完后针对这种问题能有一个清晰思路。
服务器 IPNginx 192.168.10.40
后端Web 192.168.10.50
我们使用一个flask制作一个小的后端程序，程序里加了sleep，为的是有时间你可以进行其他操作，比如终止进程：
#!/usr/bin/env python # -*- coding: utf-8 -*- from flask import Flask import random import time app = Flask(__name__) @app.route('http://www.likecs.com/') def hello_world(): time.sleep(10) html = "Hello World!" return html if __name__ == '__main__': app.run(host="0.0.0.0", port="5555")下面是Nginx配置：
server { listen 80; server_name ; #charset koi8-r; access_log /var/log/nginx/www.test.com/access.log detailed; error_log /var/log/nginx/www.test.com/error.log error; location / { proxy_pass :5555; proxy_set_header host ; proxy_connect_timeout 60s; proxy_read_timeout 60s; proxy_send_timeout 60s; # proxy_ignore_client_abort on; } #error_page 404 /404.html; #要保证下面的root目录中有50x.html，否则你只会收到404的代码 error_page 500 502 503 504 /50x.html; location = /50x.html { root /usr/share/nginx/html; }Nginx使用的日志格式
log_format detailed '$remote_addr - $remote_user [$time_local] ' '$server_protocol $scheme $ssl_protocol $http_host $request_method "$content_type" "$request" ' '$status $body_bytes_sent "$http_referer" $request_time ' '"$http_user_agent" "$http_x_forwarded_for" ' '[$upstream_addr] [$upstream_response_time] [$upstream_status] [$upstream_response_length]'; 实验1：状态码499其实499很好模拟，运行命令启动flask：
python3 ./myweb.py
确保程序已经开始监听
打开浏览器访问由于后端10秒返回（Python代码中有一个sleep函数）数据，所以当你访问这个URL之后，马上按终止或者关闭浏览器。
这时候Nginx的日志就是499
这个就是客户端在服务器还没有返回数据之前就终止了，也就是不再等待了。对于浏览器来说可能就是用户主动终止了。另外还有一种情况就是远程调用，对端设置的超时时长如果是5秒，那么由于我们程序设置的10秒后返回，对端到达5秒后会中断连接，那么我们的Nginx上就会产生499，其实这个和终止浏览器是一个意思。
proxy_ignore_client_abort on另外网上有说加上这个参数就没有499了，其实这个参数是忽略了客户端终止连接的这种情况，所以它在日志中就没有499了。
实验2：状态码502（Bad Gateway） 情况一：使用上面的配置不做任何改变。然后运行命令：
python3 ./myweb.py
打开浏览器访问，由于处理程序我设置的是10秒，所以我们有时间做其他操作，当请求进来时程序所在终端会显示如下信息：
在还没有返回的时候你直接按下CTRL+C来终止Flask程序，Nginx访问日志马上就是502错误。
查看Nginx访问日志和错误日志：
下面是抓包情况，最后一个箭头，我终止了flask程序，发送了fin给对方，所以Nginx的错误日志显示permaturely closed connection。
这种情况下后端处理程序因为某些原因被终止，导致Nginx到后端程序这条socket连接断开那么就会报这个错误。但是从抓包可以看到四次断开是正常完成的，也就是说你按CTRL+C或者kill -9 PID 这个程序，它内部还是会正常断开连接，对于Nginx来说相对于在等待数据返回的时候却收到了一个FIN。
情况二：