3G接続を介したWebSocket
私はSocket.io、node.js、WebSocketsで遊んでいますが、これらはすべて、wifi接続で正常に動作します。
ただし、3G接続を介して（たとえば、iPhoneで）WebSocket対応アプリをテストすると、ロングポーリングにフォールバックすることが唯一の実行可能なソリューションのようです。
Socket.ioを使用すると、長いポーリングにフォールバックする前に、「WebSocket接続が無効であるか、Originが検証されていません」で接続が失敗します。
WebSocketsが3Gで動作するように設計されているかどうかはわかりません-そのように動作させることに成功した人はいますか？私はさまざまな方法を試してみましたが、すべてが失敗したようで、不可能を試みていると思います。
一部の携帯電話事業者は、あなたが通過しなければならない、完全に壊れた透明なプロキシを設定することで有名です。これは、WebSocketワーキンググループが当初から対処しなければならない本当の悩みの種です。プロトコルは、そのような製品が存在する場合に非常に迅速に失敗し、アプリケーションがすぐに他の方法にフォールバックできるように設計されています。異常を検出してフォールバックするのに長い時間がかかる場合は、IETFのhybiワーキンググループに報告して、問題を診断して対処できるようにしてください。
同時に、携帯電話事業者に連絡して、壊れた透過プロキシを通過せずにネットにアクセスする方法を尋ねるか、少なくとも、壊れたプロキシが仕様に従ってHTTPをサポートするように修正される予定がある時期を知ることができます。それらのいくつかはあなたに複数のアクセスオプションを提供するかもしれません。
ウィリータローが言うように、それはモバイルオペレーターが使用する透明なプロキシが壊れています。私もそれが彼らだけのものではないと確信しています（たとえば、企業のファイアウォールなど）。 （少なくとも携帯電話会社では）別のポート番号を使用すると、これを回避できます。ポート80以外の何か。SSLの使用も機能する可能性がありますが、まだ試していません。
次に、ファイアウォールの背後にいる人々がポート80と443の外側のすべてをブロックするという問題に遭遇します。
接続を試行するたびにポート80と他のポートを切り替えるようにwebsocketsアプリを作成し、ホストがこれらの2つのポートをリッスンするようにします。その後、サーバーに接続する可能性が高くなります。 Linuxを使用して2つのポートを同時にリッスンする場合は、iptablesポートREDIRECTを使用します。
WebSocketの代わりに Server-Sent Events プロトコルを使用できます。
SSEはより単純でHTTP互換であり、プロキシを通過できます。
特定のモバイルネットワークを介した不良なWebソケット接続で同じエラーが発生しました。それらを解決しました。
ポートの移動：WebSocketのサーバーとクライアントをSSLポート（ポート443）に移動します。
Pingキープアライブ：X秒ごとにクライアントからサーバーに定期的な「ping」メッセージを送信し、「ポン」がサーバーから戻るのを待機します。サーバーがY秒以内に "pong"を返さない場合は、クライアントで接続を再開します。
（1）を実装すると、ほとんどの方法が得られます。