101 Switching Protocols 表示伺服器接受用戶端的 Upgrade 要求標頭。在結束 101 回應的空白行之後，雙方就會立刻在這條連線上改用另一種通訊協定。回應中必須包含 Upgrade 標頭，指出新的通訊協定。
如今這幾乎都是 WebSocket 交握。瀏覽器送出一個帶有 Upgrade: websocket、Connection: Upgrade 與 Sec-WebSocket-Key 的 GET，伺服器以 101 回應並附上對應的 Sec-WebSocket-Accept，此後雙方便改為交換 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
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=SEO 與重新導向檢查
一般的網頁要求絕不會得到 101。瀏覽器與爬蟲只有在明確要求升級連線時才會收到它，因此它對索引沒有任何影響。重新導向檢查工具送出的是一般的 GET、HEAD 或 POST 要求，不會看到 101。如果把 WebSocket 端點當成一般網址來檢查，它通常會回應 4xx 狀態碼，例如 426 Upgrade Required 或 400 Bad Request。
常見原因與使用情境
- 瀏覽器開啟 WebSocket（
new WebSocket('wss://...')），伺服器接受交握。 - 用戶端要求已淘汰的
h2c升級以改用明文 HTTP/2，而伺服器支援這項功能。 - WebSocket 在反向代理伺服器後方無法連線，原因是代理伺服器沒有轉送
Upgrade與Connection標頭。在 nginx 中請設定proxy_http_version 1.1，並將這兩個標頭傳給後端。