之后每次请求都需要带上这个sid，建立websocket请求的连接也不例外。所以说，sid是polling，以及polling升级到websocket的关键。这之后的请求类似于：

https:/?eio=3&transport=polling&t=1540820717314-1&sid=eogal3frqlptoalp5est

wss:/?eio=3&transport=websocket&t=1540820717314-1&sid=eogal3frqlptoalp5est

那么问题来了，如果请求是带上的sid不是服务端生成的会怎样呢？服务端会不认识，给你返回一个400，并告诉你

我们遇到的便是这个问题，nginx默认的负载均衡策略是轮询，所以请求有可能会打到不是生成这个sid的机器上去，这时候我们就会收到一个400，如果运气好，可能也会打到原来的机器上，运气更好一点，甚至能坚持到websocket连接建立。

1. nginx的负载均衡采用ip_hash，这样能保证一个客户端的请求都走到一台服务器上

2. 不使用polling模式，只使用websocket

这两种方案各有利弊。第二种显而易见，不支持websocket的古老浏览器和客户端将没法工作。第一种的问题隐藏得比较深，试想，如果你增减了机器会怎样，这时候ip_hash策略的模将变化，之前的连接将全部失效，而对于微服务，扩缩容是很频繁的操作（特别是产品处于发展期），这种有损的扩缩容很大概率是不能接受的。

以上就是nginx代理socket.io服务的坑怎么解决的详细内容，更多请关注主机测评网其它相关文章！