问题背景
使用阿里云的WAF时， HTTPS访问，偶尔会出现 SSL 建立连接失败,抓包发现 WAF返回了Encrypted Alert ，然后发了FIN包结束
内容里头序号 182~197的包都有异常
问题分析
问题方向确定
问题描述为:抓包发现 WAF返回了Encrypted Alert ，然后发了FIN包结束
分析FIN包是TCP链接中断开时使用的；如图：
确定该问题不是用户描述的SSL建立链接失败；而是断开链接有问题。
分析报文
定位用户描述的报文，如下确实有看到描述的报文，但是该分析方式无法有效的判断问题：
使用wireshark功能 Follow TCP Stream(追踪TCP流)观察条有问题的流报文
可以看到：
A、其中Encrypted Alert与FIN是同时从服务端发送的
B、Encrypted Alert的报文与上一条报文的间隔时间为119.89S
C、No.193的报文客户端马上发送了ACK
D、No.194过了14.948客户端发送了一个RST,ACK报文，重置链接
E、No.181与No.191直接没有任何报文通信
问题定位
总所周知WAF是一个Web应用层面的防护产品，目前WAF的实现访问是使用Tengine做方向代理。即也会有会话保持时长限制；
而WAF的会话保持时长为120S，与No.181与No.191直接的间隔时间非常相近；建议用户根据链接。
附录
关于SSL-Encrypted Alert提示
SSL通信在断开连接时均为发送Encrypted Alert信息给客户端告知要关闭ssl会话了，同步会发生FIN,ACK报文从TCP层面断开链接:
Since we are already in an encrypted connection, the only way to really know what is being sent within packets is to make Wireshark or similar tools aware of the keys used in the transmission. Even though this is possible, I think for the purpose of this analysis it is enough to know that the client sends an alert message when the connection is asked to be closed actively by the client or server. The type of this Alert message should be CloseNotify (type 0), but we won’t be able to see it from the raw data. In this case, the client is the sender of the following Alert message:
Secure Sockets Layer
TLSv1.2 Record Layer: Encrypted Alert
Content Type: Alert (21)
Version: TLS 1.2 (0x0303)
Length: 26
Alert Message: Encrypted Alert关于会话超时时间
proxy_read_timeout 60s;
默认：60s
配在：http中、server中、location中
在将请求发送给upstream的server后，后端server就会回传数据，这个时间是两次收取数据的时间差，不是整个的接收时间。比如说负载大、网络卡，在第1次收到请求的数据时断了，然后过了60s后才收到后面的数据，这两个时间差(其实就是两次read的时间差)超过了设置的60s，tengine（nginx）就会超时报错，我当前走的是默认设置60s。
Defines a timeout for reading a response from the proxied server. The timeout is set only between two successive read operations, not for the transmission of the whole response. If the proxied server does not transmit anything within this time, the connection is closed.
