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

Question

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

通过检查background.js（创建套接字连接的扩展中的脚本）的扩展的控制台，我看到它不是试图连接到正确的URL（我的套接字服务器），而是一个未知的URL，似乎成为代理：https://gateway.zscloud.net/auT?origurl=http%3A%2F%2Fmy_socket_server_domain ...

因为这只发生在使用不同的互联网连接（企业网络，访客网络，移动热点）的特定计算机（从目前为止我尝试过的10个左右）以及由于其他计算机在这些相同的网络DID成功连接，我假设有问题的计算机中安装或配置的东西是在连接请求发生之前捕获并尝试通过代理重定向连接请求。

同样，这只发生在Chrome扩展的上下文中。使用相同的互联网连接的同一台计算机可以成功地从同一浏览器中的网页进行连接（Google Chrome）。

有谁知道问题可能是什么？客户端并不知道有安全软件（防火墙，防病毒软件等）可能导致这种情况，但它是由他的公司管理的计算机，所以管理员可以为他做这件事。但是，如果是这样的话，那么网页的连接不应该被捕获吗？ Chrome扩展套件中的套接字连接与常规网络应用有什么不同？

谢谢！

Answer 1

WebSocket连接不同于正常的HTTP请求;他们在确定（某些！）代理可能无法支持后需要进行协议升级。

我在一个这样的（透明）代理工作的背后，但是，它不会尝试拦截HTTPS，这意味着我可以使用WebSocket而不是ws: WebSockets。

..无论如何，你应该使用它！随着我们对市场进行加密，HTTPS的入门门槛非常低。如果任何敏感数据都通过该连接发送，则符合您的最佳利益。

有关记录，该特定的代理是ZScaler这是一个安全解决方案的一部分。不幸的是，它包含HTTPS MITM，所以上述方法不太可能解决问题（但应该实施！）。它被设置为操作系统级代理 - 如果该设置可以更改，或者通过Chrome的代理设置进行覆盖，则可以修复该设置。但是，这将会导致网络安全！

如果你不能这样做，那么你的客户端就是一个SOL，应该抱怨破解合法应用程序的安全解决方案链。

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

应该可以测试wss:开关是否起作用使用https://www.websocket.org/echo.html - 如果它能够连接那么一切都将工作在wss: