WebSocket アップグレードの失敗 PCAP 分析: 101 のスイッチング プロトコル、プロキシ ヘッダー、TLS、および接続ドロップ

WebSocket の障害は、「WebSocket 接続に失敗しました」、「予期しない応答コード」、「ハンドシェイク応答を受信する前に接続が閉じられました」、「101 スイッチング プロトコルが見つかりません」、または「ソケットが切断されました」などの一般的なブラウザまたはアプリケーション メッセージの背後に隠れていることがよくあります。 HTTP は機能しているように見えるが、リアルタイム トラフィックが機能しない場合、ユーザーは「WebSocket アップグレードの失敗 pcap」、「101 スイッチング プロトコルが返されません」、「nginx websocket プロキシ ヘッダー」、および「WebSocket 接続のリセット」を検索します。

パケット キャプチャでは、HTTP アップグレード リクエストが送信されたかどうか、サーバーが「101 スイッチング プロトコル」を返したかどうか、プロキシが必要なヘッダーを削除したかどうか、TLS が成功したかどうか、アップグレード後に接続が切断されたかどうかを確認できます。

WebSocket トレースでは HTTP ハンドシェイクとアップグレード後の TCP タイムラインの両方を保存する必要があることが多いため、PCAP Surgery が役立ちます。

健全な WebSocket アップグレードとはどのようなものですか

クライアントはアップグレード ヘッダーを含む HTTP リクエストを送信します。

GET /socket HTTP/1.1
Host: example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: ...
Sec-WebSocket-Version: 13

The server replies:

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: ...

その後、接続は通常の HTTP 要求/応答トラフィックではなくなります。 WebSocket フレームを伝送します。

よくあるアップグレードの失敗

一般的な原因は次のとおりです。

• プロキシは「Upgrade」ヘッダーを削除します。
• プロキシは「接続: アップグレード」を削除または書き換えます。
• バックエンドルートはWebSocketをサポートしていません。
• TLS 終端により、リクエストが間違ったアップストリームに送信されます。
• HTTP/2 から HTTP/1.1 へのアップグレード動作の構成が間違っています。
• 101 の代わりに認証リダイレクトが発生します。
• バックエンドは 400、403、404、426、502、または 504 を返します。
• アップグレード後に接続がリセットされる。
• アイドル タイムアウトにより、静かな WebSocket が閉じられます。

ステータス コードとヘッダーが重要です。

プロキシヘッダーの問題

リバース プロキシは、WebSocket アップグレード ヘッダーを正しく転送する必要があります。バックエンドが「アップグレード: websocket」を認識しない場合、リクエストを通常の HTTP として扱う可能性があります。

パケット証拠:

• クライアントからプロキシへのリクエストにはアップグレード ヘッダーが含まれます。
• プロキシからバックエンドへのリクエストにはそれらがありません。
• バックエンドは 101 ではなく通常の HTTP 応答を返します。

これはプロキシ設定の問題であり、WebSocket クライアントのバグではありません。

TLSとSNI

セキュアな WebSocket (wss://) の場合、TLS は HTTP アップグレード前に発生します。 TLS が失敗すると、WebSocket ハンドシェイクは開始されません。 DNS、TCP、TLS ClientHello、SNI、および TLS アラートまたはリセットを保持します。

TLS パスが証明されるまでは、アップグレード ヘッダーを診断しないでください。

101 を超えると接続が切断される

場合によっては、アップグレードが成功しても、接続が閉じられることがあります。それは別の失敗です。

探す：

• FIN または RST 送信者。
• アイドルタイムアウト期間。
• WebSocket のピンポン アクティビティ。
• プロキシ読み取りタイムアウト。
• TCP 再送信。
• 窓ゼロ。
• バックエンドプロセスが再起動されます。

ドロップが一定の間隔で発生する場合は、タイムアウト ポリシーが適用されている可能性があります。

Checklist

このワークフローを使用します。

1. DNS と TCP 接続を維持します。
2. 「wss://」の TLS ハンドシェイクを確認します。
3. クライアントのアップグレード要求ヘッダーを検査します。
4. サーバーの応答ステータスを検査します。
5. 予想される場合は、「101 スイッチング プロトコル」を確認します。
6. クライアントからプロキシへのリクエスト、およびプロキシからバックエンドへのリクエストを比較します。
7. リダイレクトまたは認証応答を探します。
8. アップグレードが成功した場合は、アップグレード後の FIN/RST/タイムアウトを検査します。
9. 表示されている場合は、WebSocket のピン/ポン タイミングを保持します。
10. フルハンドシェイクを維持した後にのみトリムしてください。

最終診断

「101 スイッチング プロトコル」が証明されるまで、WebSocket アップグレードの失敗は通常、HTTP ハンドシェイクまたはプロキシ転送の問題です。アップグレード後、障害は長期にわたる TCP タイムアウト、リセット、またはアプリケーション プロトコルの問題になります。

PCAP サージェリーは両方のフェーズを保存するのに役立ち、あいまいな WebSocket エラーをヘッダー、プロキシの動作、TLS、バックエンドの応答、または接続の存続期間まで追跡できます。