我一直在玩 Socket.io、node.js 和 WebSockets，所有这些我都可以通过 wifi 连接正常工作。
但是，当我通过 3G 连接（例如在我的 iPhone 上）测试支持 WebSocket 的应用程序时，似乎回到长轮询是唯一可行的解决方案。
使用 Socket.io，连接失败并返回“WebSocket 连接无效或来源未验证”，然后返回到长轮询。
我不知道 WebSockets 是否适用于 3G - 有没有人成功让它们像那样工作？我尝试了许多不同的方法，但似乎都失败了，这让我觉得我正在尝试不可能的事情。
一些移动电话运营商以设置您被迫通过的完全损坏的透明代理而闻名。这是 WebSocket 工作组从一开始就不得不处理的真正烦恼。该协议旨在确保在存在此类产品时它会很快失败，以便您的应用程序可以立即回退到其他方法。如果您发现检测异常需要很长时间并回退，请向 IETF 的 hybi 工作组报告，以便诊断和解决问题。
同时，您可以联系您的移动电话运营商并询问他们如何在不通过其损坏的透明代理的情况下访问网络，或者至少知道他们何时希望根据规范修复损坏的代理以支持 HTTP。其中一些可能会为您提供多种访问选项。
正如 Willy Tarreau 所说，它破坏了移动运营商使用的透明代理。我相信这也不是他们独有的（例如公司防火墙）。您可以通过使用不同的端口号（至少在移动运营商上）来解决此问题。端口 80 以外的东西。使用 SSL 也可能有效，但我还没有尝试过。
然后你会遇到防火墙后面的人阻止端口 80 和 443 之外的所有内容的问题。
编写您的 websockets 应用程序以在每次连接尝试时在端口 80 和其他端口之间切换，并让您的主机监听这两个端口。然后你很有可能连接到服务器。如果您使用 linux 同时监听两个端口，请使用 iptables port REDIRECT。
You can use Server-Sent Events protocol instead of WebSockets.
SSE is a simpler, HTTP-compatible and can go through proxies.
由于某些移动网络上的网络套接字连接不良，出现了同样的错误。解决了它们；
移动端口：将 websocket 的服务器和客户端移动到 SSL 端口（端口 443）
Ping keep-alive：每隔 X 秒从客户端向服务器发送周期性“ping”消息，并等待“pong”从服务器返回。如果服务器在 Y 秒内没有返回“pong”，请在客户端重新启动连接。
实施 (1) 将使您大部分时间到达那里。