來自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: