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

Question

我有一个使用javascript的网络应用程序，该应用程序使用socket.io连接到套接字，而Chrome扩展程序以相同的方式连接到同一台服务器。 在大多数计算机和Internet连接上一切正常，但是我客户的一台计算机无法连接Chrome扩展程序（网络应用程序成功连接）。

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

由于这种情况仅发生在使用不同Internet连接（公司网络，访客网络，移动热点）的那台特定计算机（到目前为止，我尝试使用的10台左右）中，并且由于这些DID相同的网络中的其他计算机都能成功连接，我认为在有问题的计算机中安装或配置的某些东西会在连接请求发生之前捕获该连接请求，并尝试通过代理重定向它。

同样，这仅在Chrome扩展程序的上下文中发生。 使用相同Internet连接的同一台计算机确实可以在同一浏览器（Google Chrome）中从网页进行连接。

有人知道可能是什么问题吗？ 客户不知道有可能导致此问题的安全软件（防火墙，防病毒等），但这是由他的公司管理的计算机，因此管理员可以为他完成此操作。 但是，如果是这种情况，是否也不应捕获来自网页的连接？ Chrome扩展程序中的套接字连接与常规网络应用程序有什么不同吗？

谢谢！

Answer 1

WebSocket连接不同于普通的HTTP请求； 在确定某些代理可能无法支持之后，他们需要对协议进行升级。

在某种程度上，我在工作中落后于一个这样的（透明）代理。 但是，它不会尝试拦截HTTPS，这意味着我可以使用wss: WebSockets，但不能使用ws: WebSockets。

..无论如何，您应该使用它！ 通过市场上的“让我们加密”，HTTPS的入门门槛非常低。 如果根本没有任何敏感数据通过该连接发送，则符合您的最大利益。

记录下来，该特定代理是ZScaler （安全解决方案）的一部分。 可悲的是，它包含HTTPS MITM，因此上述方法不太可能解决问题（但无论如何都应实现！）。 它设置为操作系统级别的代理-如果可以更改该设置，或者用Chrome的代理设置覆盖，则可以解决该问题。 但是，这将激怒网络安全！

如果您无法做到这一点，那么您的客户就是SOL，并且应该抱怨该安全解决方案破坏了合法应用程序。

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

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