给别人轻松讲明白一个问题，才能算自己真正了解这个问题。
Origin Header 头让我熟悉了一次sheme
从HTTP的头Origin说起，想起之前客户端定义scheme，因为不了解，问了开发的同事“scheme是什么？”反正我当时是不明白他们讲的。
在了解HTTP Origin语法的时候，我其实才真正明白：scheme 指请求所使用的协议，通常是HTTP、HTTPS或者其他。
Origin: <scheme> "://" <host> [":" <port>]Origin表示请求来至哪个站点。在WebSocket通信的时候，明确指明要校验这个参数。
服务器内部错误。比如：服务端处理出现异常。同时，在PHP错误日志中可以查看异常发生的调用栈信息。
作为网关或者代理工作的服务器尝试执行请求时，从上游服务器接收到无效的响应。比如nginx从php-fpm接收到了不完整的response数据。
比如：服务端尝试连接mysql，但长时间链接不上，就会返回502错误。
可以浏览一些具体的文章：
http 502 和 504 的区别Nginx一次奇怪的502 报错探究网关超时。为了完成您的 HTTP 请求，该服务器访问一个上游服务器，但没得到及时的响应
比如：nginx超过了自己设置的超时时间，不等待php-fpm的返回结果，直接给客户端返回504错误。但是此时php-fpm依然还在处理请求（在没有超出自己的超时时间的情况下）。
首先我们启动一个Go的原生服务，然后在服务前设置Nginx作为服务的代理。这里配置中配置 Nginx 到 Go 服务使用长链接。
直接在代码中手动调用 panic，然后请求接口，观察接口的状态码返回值。
r.POST("/panic", func(context *gin.Context) { panic("this panic") })使用 curl 命令请求接口，同时，打印接口的详细信息。在程序处理请求的过程中发生panic的话，服务返回的500。这里，建议加上 -v 参数。
➜ ~ curl -v -X POST http://127.0.0.1:8081/panic * Trying 127.0.0.1... * TCP_NODELAY set * Connected to 127.0.0.1 (127.0.0.1) port 8081 (#0) > POST /panic HTTP/1.1 > Host: 127.0.0.1:8081 > User-Agent: curl/7.64.1 > Accept: */* > < HTTP/1.1 500 Internal Server Error < Date: Sat, 03 Oct 2020 02:01:14 GMT < Content-Length: 0 < * Connection #0 to host 127.0.0.1 left intact * Closing connection 0通过网络的请求情况，我们来佐证一下这个过程，对这个过程抓包分析。图中标志①的地方是因为程序中发生了 panic 导致，可以看出，虽然程序发生了panic，但是整个链接（63509端口到8001端口）并没有因为panic而断开；之后是②部分，服务端主动发起了3次心跳（默认间隔15秒）；最后，在③阶段，客户端主动断开了链接。
如果对 panic的信息进行了 recover 呢，我们调整一下代码，在 router 前加一个中间件来专门 recover 请求中的 panic信息：
func MiddleRecover(ctx *gin.Context) { defer func() { if r := recover(); r != nil { log.Println("panic occur", r) } }() ctx.Next() }我们继续使用curl 请求 /panic 接口，接口正常返回了，状态码是200。
➜ ~ curl -v -X POST http://127.0.0.1:8081/panic * Trying 127.0.0.1... * TCP_NODELAY set * Connected to 127.0.0.1 (127.0.0.1) port 8081 (#0) > POST /panic HTTP/1.1 > Host: 127.0.0.1:8081 > User-Agent: curl/7.64.1 > Accept: */* > < HTTP/1.1 200 OK < Date: Sat, 03 Oct 2020 02:08:39 GMT < Content-Length: 0 < * Connection #0 to host 127.0.0.1 left intact * Closing connection 0那么，如何触发502的状态码呢，通过前面对状态码的介绍：“从上游服务器接收到无效的响应”。从网络传输来看，在传输的过程中，如果服务端主动断开链接，就会导致502。服务端怎么样才会主动断开链接呢，有一种比较常见的情况，就是整个服务 crash。
我们在新建一个请求，用来导致整个服务发生 panic，这里采用 map 并发读写的panic，因为这个panic 是runtime层发生的panic，整个服务只能crash，不能被recover。代码中模拟了 map 的并发读写操作。注意，并不一定每次都能触发panic
result := make(map[int]int) r.POST("/crash_panic", func(context *gin.Context) { go func() { for { result[1] = 1 } }() _ = result[1] context.JSON(http.StatusOK, "") })我们还是通过 curl 来请求几次，看一下结果。在系统崩溃时，返回的状态码确实是502。
➜ nginx curl -v -X POST http://127.0.0.1:1144/crash_panic * Trying 127.0.0.1... * TCP_NODELAY set * Connected to 127.0.0.1 (127.0.0.1) port 1144 (#0) > POST /crash_panic HTTP/1.1 > Host: 127.0.0.1:1144 > User-Agent: curl/7.64.1 > Accept: */* > < HTTP/1.1 502 Bad Gateway < Server: nginx/1.19.1 < Date: Sat, 03 Oct 2020 08:21:45 GMT < Content-Type: text/html < Content-Length: 157 < Connection: keep-alive < <html> <head><title>502 Bad Gateway</title></head> <body> <center><h1>502 Bad Gateway</h1></center> <hr><center>nginx/1.19.1</center> </body> </html> * Connection #0 to host 127.0.0.1 left intact * Closing connection 0依旧通过网络抓包来看一下连接断开的过程。从图中的②可以看出，服务端主动断开了网络的连接。因为服务Down机了，在Down机的时候会主动断开服务端的连接。
最后，我们再来看一下504，没有得到及时的响应。怎么样才算是网络超时呢，看一下实验的 nginx 配置文件。
upstream mysvr { server 127.0.0.1:8081; keepalive 300; #这个很重要！ } server { keepalive_requests 120; #单连接请求上限次数。 listen 1144; #监听端口 location / { #请求的url过滤，正则匹配，~为区分大小写，~*为不区分大小写。 proxy_pass http://mysvr; #请求转向mysvr 定义的服务器列表 proxy_set_header Host $host; proxy_set_header Connection ""; #设置Connection为长连接（默认为no） proxy_connect_timeout 30; #与upstream server的连接超时时间 proxy_read_timeout 60s; #nginx会等待多长时间来获得请求的响应 proxy_send_timeout 12s; #发送请求给upstream服务器的超时时间 proxy_http_version 1.1; } }对配置文件做一下改动，将proxy_read_timeout从60秒调整到3秒，然后我在程序中sleep 3秒看一下效果:
r.POST("/timeout", func(context *gin.Context) { time.Sleep(time.Second * 4) context.JSON(http.StatusOK, "") })下面是 curl 请求的过程以及网络抓包的截图：
➜ nginx curl -v -X POST http://127.0.0.1:1144/timeout * Trying 127.0.0.1... * TCP_NODELAY set * Connected to 127.0.0.1 (127.0.0.1) port 1144 (#0) > POST /timeout HTTP/1.1 > Host: 127.0.0.1:1144 > User-Agent: curl/7.64.1 > Accept: */* > < HTTP/1.1 504 Gateway Time-out < Server: nginx/1.19.1 < Date: Sat, 03 Oct 2020 08:33:54 GMT < Content-Type: text/html < Content-Length: 167 < Connection: keep-alive < <html> <head><title>504 Gateway Time-out</title></head> <body> <center><h1>504 Gateway Time-out</h1></center> <hr><center>nginx/1.19.1</center> </body> </html> * Connection #0 to host 127.0.0.1 left intact * Closing connection 0通过第二列的时间项，我们可以计算出，大概在3秒后，nginx主动断开了链接，然后客户端收到了504的状态码。
