101 Switching Protocols は、サーバーがクライアントの Upgrade リクエストヘッダーを受け入れたことを示します。101 レスポンスの終わりを示す空行の直後から、この接続では双方が別のプロトコルで通信します。レスポンスには、新しいプロトコルを示す Upgrade ヘッダーが含まれていなければなりません。
現在の用途は、ほぼ WebSocket のハンドシェイクに限られます。ブラウザーは Upgrade: websocket、Connection: Upgrade、Sec-WebSocket-Key を付けた GET を送信し、サーバーは対応する Sec-WebSocket-Accept を付けて 101 を返します。それ以降は、双方が WebSocket のフレームをやり取りします。101 は、平文の HTTP/1.1 から HTTP/2 へ切り替える h2c アップグレードにも使われていましたが、この方式は現在では非推奨です。ブラウザーは代わりに、TLS ハンドシェイクの中で（ALPN により）HTTP/2 や HTTP/3 をネゴシエートします。
Upgrade の仕組みがあるのは HTTP/1.1 だけです。HTTP/2 と HTTP/3 では 101 が送られることはなく、これらのプロトコル上の WebSocket には拡張 CONNECT（RFC 8441 と RFC 9220）が使われます。
レスポンス例
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=SEO とリダイレクトチェック
通常のページリクエストの結果として 101 が返されることはありません。ブラウザーやクローラーが 101 を受け取るのは接続のアップグレードを明示的に要求した場合だけなので、インデックスには影響しません。リダイレクトチェッカーが送るのは通常の GET、HEAD、POST リクエストなので、101 が表示されることはありません。WebSocket のエンドポイントを通常の URL のようにチェックすると、たいていは 426 Upgrade Required や 400 Bad Request などの 4xx コードが返ります。
よくある原因と主な用途
- ブラウザーが WebSocket を開き（
new WebSocket('wss://...')）、サーバーがハンドシェイクを受け入れた場合。 - クライアントが、平文の HTTP/2 に切り替える非推奨の
h2cアップグレードを要求し、サーバーがそれに対応している場合。 - リバースプロキシが
UpgradeヘッダーとConnectionヘッダーを転送しないため、プロキシ経由で WebSocket が失敗する場合。nginx ではproxy_http_version 1.1を設定し、両方のヘッダーをバックエンドに渡してください。