websocket连接会断开，抓包检查后发现是中间的代理服务器nginx断开的，同时将后端和浏览器都断开了。将nginx日志调到debug级别后，有下面的断开信息。
[info] 125923#125923: *34 client timed out (110: Connection timed out) while proxying upgraded connection, client: 127.0.0.1, server: , request:
检查nginx.conf的配置，proxy_send_timeout和proxy_read_timeout都设置得非常大，而且抓包也没有长时间没有流量。网上找不到和分析上面的报错，自己动手分析。由于我们的错误是在测试环境稳定复现的，有很好的分析条件。
首先，将nginx日志调到debug级别后，日志能看到的是info，没有真正开启debug。找了下要用带debug编译的nginx才可以。折腾了一会系统方面的配置得到真正的debug日志。
接下来是日志分析。在info日志前有10000的timer（下图是5000的示意）。然后就在nginx的conf文件里面找和10相关的配置，找到了一个send_timeout 10;。高度相关。
最后，我们修改这个参数的大小验证和日志的关联性。修改为5，日志就是上图打印的样子。修改为15则等了一两小时没有断开。可见 client timed out和send_timeout的大小设置有关系。
网上关于send_timeout的解释没法准确的理解，试图通过抓包给出准确的解释，无奈发现nginx和浏览器，以及nginx和后端最后通信间隔都是一样的，没有给出准确的解释。
多了点耐心做详尽的分析，抓包下来看到的现象是这样的，nginx最后转发给后端服务的时间间隔了5s，然后nginx首先断开也是和后端的连接，猜测是nginx给后端发数据间隔了5s导致。但本质上为什么nginx会间隔5s才给后端发包，因为浏览器的包到nginx先间隔了5s，然后nginx转发的时候就差了5s。结论是上行请求方向的数据差了5s导致的。
进一步测试，配置改成7s出现到后端的连接断开8s后才断开到浏览器的连接，显然线索已经很清晰，这次的断开是因为nginx在7s内没有给后端发消息，nginx主动断开。
)
