テストサイトhttp://socket.trailsandtribulations.net
Firefox：v15は正常に動作します。（ただし、トラフィックが多く、ネットが遅い場合、Firefoxも（静かに）失敗することがよくあります。）
chrome：以前は機能していましたが、v21はError during WebSocket handshake: 'Connection' header value is not 'Upgrade'
ただし、chromeがローカルで実行されている場合は、正常に動作します。タイの私のクライアントとドイツのサーバーで壊れます。繰り返しになりますが、Firefoxは、以前のバージョンのchromeと同様に、常に正しく機能します。
を介してWebSocketとHTMLを介しhaproxyて分割するために使用するnode.jsnginx
このソリューションが機能しないようにする何かが変更されましたか？
haproxy.cfgテストサイトのリンクが表示されるようになりました。これにより、常に最新の状態になります。
あなたのメッセージから、エラーはChromeによって報告されているように見えますが、最初はChromeがアクセスしたときにサーバーによって報告されたと理解していました。回避策として、「optionhttpclose」を「optionhttp-server-close」に置き換えると、問題が解消される可能性があると思います。また、すべての「オプションforceclose」を削除する必要があります。「optionhttp-server-close」しかない場合、haproxyは応答パスのConnectionヘッダーに触れないため、ブラウザは正常に動作します。ただし、エラーが表示されるバグがまだあり、ソフトウェアの作成者に報告する必要があることに注意する必要があります。
ところで、タイムアウトが大きすぎると、1日の終わりに多くの接続が切断されてしまいますが、これは意味がありません。最近の十分なhaproxyを使用している場合は、「timeout tunnel」を使用して、大きなHTTPタイムアウトを処理せずにWSタイムアウトを設定できます。しかし、それでも、1日はTCP接続には大きすぎます。一部のユーザーは、ハンドオーバーが発生する前にTCP接続が数分以上存続できないスマートフォンを使用します。
Firefoxはno-cache、WebSocketの更新を要求するときに使用します。このバージョンのクロムはそうではありません。http://code.google.com/p/chromium/issues/detail?id=148908&thanks=148908&ts=1347523876を参照してください
一部のプロキシでは、明らかにこれが必要です
また、関連する問題については、 https：//github.com/sockjs/sockjs-node/pull/88を参照してください。