Haproxy 作为Shadowsocks 中继遇到的一个问题

之前用Haproxy 来转发Shadowsocks 的流量时遇到一个问题,现象是在使用Slack 的时候(聊天使用了Websocket),频繁重连。凭直觉是由于Haproxy 的某一项timeout 设置的不合理导致的。
Websocket 协议可以分为2个阶段,先用HTTP 握手,然后建立长连接,通过ws 协议进行通信。将Haproxy 作为中继时,在建立长连接之后,Haproxy 就转入tunnel 模式

TUN:tunnel(option http-tunnel):这是 1.0 ~ 1.5-dev21 的默认模式,类似于隧道,HAProxy 仅处理第一个请求和响应,剩余的报文将直接转发而不进行处理。尽量不要使用这个模式,因为它在日志记录和 HTTP 处理上有很多问题。 --来源:liaoph.com

涉及到的timeout 见下图:

我们遇到的需要频繁重连的情况,其实是由于timeout tunnel 设置不合理导致的。官方给的关于timeout tunnel 的解释:

Set the maximum inactivity time on the client and server side for tunnels.

The tunnel timeout applies when a bidirectional connection is established between a client and a server, and the connection remains inactive in both directions. This timeout supersedes both the client and server timeouts once the connection becomes a tunnel. In TCP, this timeout is used as soon as no analyser remains attached to either connection (eg: tcp content rules are accepted). In HTTP, this timeout is used when a connection is upgraded (eg: when switching to the WebSocket protocol, or forwarding a CONNECT request to a proxy), or after the first response when no keepalive/close option is specified......


defaults http
    option http-server-close
    timeout connect 5s
    timeout client 30s
    timeout client-fin 30s
    timeout server 30s
    timeout tunnel  1h    # timeout to use with WebSocket and CONNECT

把中继的Haproxy 的这项值设为1h,解决了Slack 会频繁重连的问题。


2016-07-27 haproxy websocket