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

Question

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

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

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

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

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

谢谢！

Answer 1

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

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

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

为了记录，该特定代理是ZScaler 的一部分，这是一种安全解决方案。遗憾的是，它包含 HTTPS MITM，因此上述方法不太可能解决问题（但无论如何都应该实施！）。它被设置为操作系统级别的代理 - 如果可以更改该设置，或者用 Chrome 的代理设置覆盖，那将修复它。但是，这会影响网络安全！

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

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

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