我有一个javascript的网络应用程序，它使用socket.io连接到套接字，Chrome扩展程序以相同的方式连接到同一服务器。 在大多数计算机和互联网连接中，一切正常，但我的一台客户的计算机未能连接Chrome扩展程序（网络应用程序连接成功）。
通过检查扩展控制台的background.js（创建套接字连接的扩展中的脚本），我看到它没有尝试连接到正确的URL（我的套接字服务器），而是连接到未知的URL这似乎是一个代理：https://gateway.zscloud.net/auT?origurl=http%3A%2F%2Fmy_socket_server_domain ...
由于这种情况仅发生在使用不同互联网连接（公司网络，来宾网络，移动热点）的特定计算机（我目前为止尝试过的10台左右）以及同一网络中的其他计算机DID成功在连接中，我假设在有问题的计算机中安装或配置的东西在它发生之前捕获连接请求并尝试通过代理重定向它。
同样，这仅在Chrome扩展程序的上下文中发生。使用相同互联网连接的同一台计算机可以成功连接同一浏览器（谷歌浏览器）中的网页。
有人知道问题是什么吗？客户端不知道有可能导致这种情况的安全软件（防火墙，防病毒软件等），但它是由他的公司管理的计算机，因此管理员可以为他做到这一点。但是，如果是这种情况，是否也不应该捕获来自网页的连接？ Chrome扩展程序中的插槽连接是否与特定网络应用程序不同？
谢谢！
答案 0 :(得分：1)
WebSocket连接与普通HTTP请求不同;在确定（某些！）代理可能无法支持之后，它们需要协议升级。
我在某个地方支持一个这样的（透明）代理工作;但是，它不会尝试拦截HTTPS，这意味着我可以使用wss: WebSockets而不是ws: WebSockets。
..无论如何你应该使用它！随着市场上的Let加密，HTTPS的进入门槛非常低。如果通过该连接发送任何敏感数据，则符合您的最佳利益。
对于记录，该特定代理是ZScaler的一部分，这是一种安全解决方案。遗憾的是，它包括HTTPS MITM，因此上述内容不太可能解决问题（但无论如何都应该实现！）。它已设置为操作系统级别的代理 - 如果该设置可以更改，或使用Chrome的代理设置覆盖，则可以解决此问题。但是，这会破坏网络安全！
如果你不能这样做，那么你的客户就是SOL，应该抱怨破坏合法应用程序的安全解决方案链。
修改：我环顾四周，发现this，似乎声称使用SSL（即wss:）就足够了。但是从2012年开始 - 可能在ZScaler能够MITM所有HTTPS流量之前。
应该可以使用https://www.websocket.org/echo.html来测试wss:切换是否有效 - 如果它可以连接那么一切都可以在wss:上运行