web console应该通过websocket连ui，而不是连proxy

[yuyijq]

现在的逻辑是web console去遍历proxy，然后连接，这就导致web console要直连proxy，一般生产是不让本地直连的。合理的方式应该是web console连ui，然后ui去选择应该连哪一台proxy

[xkrivzooh]

一般公司都会存在用户本地和prod 环境的网络隔离问题，简单说就是开发人员的电脑本地不能直接访问到线上的机器，比如不能直接从本地telnet线上机器服务。

至于你说的「合理的方式应该是web console连ui，然后ui去选择应该连哪一台proxy」：

• 其实web console连bistoury的ui模块也存在上面说的网络隔离问题，因为bistoury ui模块也是需要在生产环境部署的，而web console中websocket请求的发起端其实是用户端，因此网络隔离问题总是存在的。
• 在一定程度上来说现在就是通过bistoury ui模块选择websocket应该连接哪个proxy。

这种问题其实根本原因是网络隔离导致的，一般的解法为：

• websocket 途径（不存在网络隔离的）nginx，这样来解决
• 针对proxy的机器和特定端口开启网络白名单
• 建议针对每一台proxy机器搞一个lvs域名，增加一个proxy ip和lvs域名的映射关系，这样proxy机器ip变化的时候，修改成本可以小一些。

[yuyijq]

@xkrivzooh websocket连proxy这里有一个逻辑的：websocket需要轮询所有proxy，然后寻找agent的连接在哪一台proxy上，所以直接暴露proxy不管是放在nginx后面，还是lvs域名都不行（除非你给每台proxy一个域名）。 合理的方式就是 websocket 通过nginx连接web ui(一个域名)，由ui去选具体哪一台proxy，然后去连接。

[xkrivzooh]

@yuyijq 恩，赞同你说的：

合理的方式就是 websocket 通过nginx连接web ui(一个域名)，由ui去选具体哪一台proxy，然后去连接。

我们当时为了快速上线，就给每一个proxy分配了一个域名，然后ui模块使用proxy ip获取对应的域名。这块确实挺恶心的。