Der Server wechselt zu dem Protokoll, das der Client angefordert hat.
Wann du ihn verwendest
Beim Upgrade einer Verbindung auf WebSocket.
Gut zu wissen
101 siehst du fast immer beim WebSocket-Handshake: Der Client sendet Upgrade: websocket und Connection: Upgrade, und der Server antwortet mit 101 und Sec-WebSocket-Accept. Bekommst du stattdessen 200, 400 oder 426, hat etwas dazwischen die Upgrade-Header verworfen. Hinter nginx musst du sie explizit weiterleiten, mit proxy_http_version 1.1, proxy_set_header Upgrade $http_upgrade und proxy_set_header Connection upgrade.
Nach dem Wechsel werden Idle-Timeouts zum nächsten Problem: nginx schließt weitergeleitete Verbindungen nach proxy_read_timeout, standardmäßig 60 Sekunden, und AWS ALB hat einen Idle-Timeout von 60 Sekunden, ruhige Sockets brauchen also Pings. HTTP/2 verwendet 101 überhaupt nicht; WebSockets über HTTP/2 nutzen Extended CONNECT aus RFC 8441. Eine 101 hat keinen Body und wird nie gecacht.
Information (1xx)
1xx-Codes sind informativ: Der Server hat die Anfrage erhalten und der Austausch geht weiter. Browser und HTTP-Bibliotheken kümmern sich selbst darum.
So sieht es aus
HTTP/1.1 101 Switching ProtocolsSo prüfst du ihn
curl -s -o /dev/null -w "%{http_code}\n" https://example.com/