チャットページは開くのにライブ接続が失敗する場合の調査箇所
ページとチャットの通信経路は別々のリクエストです。WebSocket、イベントストリーム、ロングポーリングを確認し、接続確立・配信・寿命を切り分けます。
チャットページを読み込む前にネットワークパネルを開き、画面の骨組みを描くリクエストではなく、メッセージを運ぶリクエストを探します。文書、スクリプト、サインインのやり取り、チャットの通信経路は、それぞれ別のホストへ向かうことがあります。VPN がチャットを壊したという報告の多くは、実際にはこの四つのリクエストのどれかが失敗した話です。順番に見ていけば、答えはたいてい最初の二分で見えます。
メッセージを運ぶリクエストを特定する
ページが落ち着いてから種類で絞り込みます。WebSocket は独立した項目として現れ、イベントストリームは応答が伸びながら開いたままになり、ロングポーリングは一定の間隔で繰り返されます。更新を運んでいるものについて、スキーム、ホスト、ポート、ステータスを記録します。サインインの前と後のどちらで始まったかを書き留めます。認証前に開かれる通信経路は、認証後に開かれるものとは普通、設計が違うからです。アップグレード要求や受け入れられたコンテンツ種別についてはリクエストヘッダーを読みます。配信中のページが実際に選んだ通信経路は、そこに現れるからです。
古いフォーラムの投稿は、製品が何年も前に使わなくなった通信経路を説明しています。記事ではなく、ブラウザが記録した内容を信じてください。項目がまったく無い場合、クライアントのコードが接続を一度も試みていない可能性があり、それはより前のスクリプトや設定の失敗を示します。ページが読み込まれたことは文書が届いたことしか証明せず、その区別が、そもそもネットワークを調べるべきかどうかを決めます。
確立・配信・寿命はそれぞれ違う形で失敗する
WebSocket は HTTP アップグレードで始まり、それにステータス 101 が返り、その後のやり取りはページ取得ではなくフレーム化されたメッセージになります。この二段階を RFC 6455 は明示的に分けています。イベントストリームはストリーミングのコンテンツ種別で応答し、応答本体を開いたまま保持します。どちらも、開けない、開いても何も配信しない、開いて配信したあとに静かに死ぬ、という失敗をします。
wscat -c wss://chat.example.com/socket -H "Origin: https://chat.example.com"
curl -N -H "Accept: text/event-stream" https://chat.example.com/events
プロファイルに触れる前に、最初の意味のある失敗を捉えます。三つのタイミングは別々の層を指すからです。ハンドシェイクが完了しない場合は、同じホストへの通常の HTTPS リクエストと比べ、そもそも何かが届いているかを見ます。完了してもメッセージが来ない場合は、別のアカウントから試験メッセージを送ってもらいながら、フレームやストリーム本体を観察します。動いたあとに止まる場合は、正確な時刻とクローズコードを記録します。その二つで、どちら側が諦めたかが分かるからです。
コード 1006 は、クローズフレームなしで接続が閉じたことを意味し、中間装置やアイドルタイムアウトがブラウザの内側からはそう見えます。VPN のハートビートは、内側のアプリケーションセッションが生きている証拠にはなりません。
ライブ用ホストは別の宛先である
チャットのバックエンドはしばしば 独自のホスト名で動いて おり、別のポートや別の証明書の背後にあることもあります。その宛先には独自の名前解決、経路、プロキシの扱いが必要で、スプリットトンネリングはページを含みつつソケットを除外することがあります。クライアント端末からライブ用ホスト名を解決し、そのネットワークで期待するアドレスを返すか確認します。証明書チェーンはそのホスト名について個別に確認します。サイトを覆うワイルドカードが、ソケットのエンドポイントまで覆うとは限らないからです。
経路にプロキシがある場合は、アップグレードや長時間の応答をバッファリングせずに通す設定かを確認します。HTML を書き換える企業プロキシは WebSocket のアップグレードを苦手とする場合が多く、その結果ページは描画されるのにチャットは接続しない、という状態になります。同じ製品への二つのリクエストは、同じホストへの二つのリクエストではないのです。
直すべきは宛先リストであり、セキュリティ検査ではない
宛先リストを直すのは経路の変更であり、経路の所有者の仕事です。証明書の検証を緩めたり Origin ヘッダーを削ったりするのはセキュリティの変更であり、ポリシーの所有者の仕事で、チケットを調べている本人であることは稀です。接続できたように見せる最短の方法は、たいてい事故を可能にする最短の方法でもあります。
何かを変える前に、バックエンドがどのオリジンを受け入れるかをアプリケーションの所有者に尋ね、その答えをプロキシを管理する人へ渡します。証明書エラーがトンネル経由でのみ出る場合は、迂回路を入れるのではなく、傍受している機器を調べます。
引き継げるだけの記録を残す
役に立つ記録は短いものです。ページの URL、ライブのエンドポイント、ハンドシェイクの結果、最初の失敗時刻、再接続を試みたかどうか。そこに VPN プロファイル名と使っていたネットワークを加えれば、読んだ人は六つ質問しなくても同じ試験を再現できます。クッキー、認証ヘッダー、メッセージ本文は伏せ、アーカイブ全体の書き出しよりタイミング列のスクリーンショットを選びます。フレームやネットワークのアーカイブには私的なメッセージやセッショントークンが含まれうるので、添付する前に中身を確認します。
静かな切断であれば、クローズコードとその直前のアイドル区間を添えます。その二つでタイムアウトの持ち主が分かることが多いからです。タイムアウト値を自分で推測せず、記録をアプリケーションまたはゲートウェイの所有者へ渡します。対応しているキープアライブの挙動についての彼らの答えが、チケットを閉じる答えです。