javascript - 来自 chrome 扩展的套接字连接被代理/防火墙阻止

Question

我有一个 JavaScript 网络应用程序，它使用 socket.io 连接到套接字，并且 Chrome 扩展以相同的方式连接到同一服务器。 在大多数计算机和互联网连接中一切正常，但我客户的一台计算机无法连接 Chrome 扩展程序(网络应用程序连接成功)。

通过检查扩展控制台的background.js(扩展中创建套接字连接的脚本)，我发现它并没有尝试连接到正确的URL(我的套接字服务器)，而是连接到一个未知的URL，该URL似乎是代理:https://gateway.zscloud.net/auT?origurl=http%3A%2F%2Fmy_socket_server_domain ...

因为这种情况仅发生在使用不同互联网连接(公司网络、访客网络、移动热点)的特定计算机(到目前为止我尝试过的 10 台左右)中，并且由于同一网络中的其他计算机确实成功了在连接过程中，我假设有问题的计算机中安装或配置的某些东西正在捕获连接请求，并尝试通过代理重定向它。

同样，这种情况仅发生在 Chrome 扩展程序的上下文中。使用相同互联网连接的同一台计算机确实可以成功地从同一浏览器(Google Chrome)中的网页进行连接。

有人知道问题出在哪里吗？客户不知道可能会导致这种情况的安全软件(防火墙、防病毒等)，但这是由他的公司管理的计算机，因此管理员可以为他做到这一点。但是，如果是这样的话，来自网页的连接不应该也被捕获吗？ Chrome 扩展程序中的套接字连接有什么与常规网络应用不同的地方吗？

谢谢!

Answer 1

WebSocket 连接与普通 HTTP 请求不同；他们需要在建立(某些!)代理可能无法支持后进行协议(protocol)升级。

我在工作中曾在某个时候支持过这样一个(透明的)代理；但是，它不会尝试拦截 HTTPS，这意味着我可以使用 wss: WebSockets，但不能使用 ws: WebSockets。

..无论如何，你应该使用它!随着 Let's Encrypt 的上市，HTTPS 的进入阈值非常低。如果通过该连接发送任何敏感数据，则符合您的最佳利益。

根据记录，该特定代理是 ZScaler 的一部分这是一个安全解决方案。遗憾的是，它包含 HTTPS MITM，因此上述方法不太可能解决问题(但无论如何都应该实现!)。它被设置为操作系统级代理 - 如果该设置可以更改或用 Chrome 的代理设置覆盖，则可以修复它。然而，这会破坏网络安全!

如果您做不到这一点，那么您的客户就是 SOL，应该向上级投诉安全解决方案破坏了合法应用程序。

编辑:我环顾四周，发现 this ，它似乎声称使用 SSL(即 wss:)就足够了。但这是从 2012 年开始的——也许在 ZScaler 能够 MITM 所有 HTTPS 流量之前。

应该可以使用 https://www.websocket.org/echo.html 来测试 wss: 开关是否有效。 - 如果它可以连接，那么一切都将通过wss:

进行