El servidor cambia al protocolo que pidió el cliente.
Cuándo usarlo
Al actualizar una conexión a WebSocket.
A tener en cuenta
Casi siempre ves 101 durante un handshake de WebSocket: el cliente envía Upgrade: websocket y Connection: Upgrade, y el servidor responde 101 con Sec-WebSocket-Accept. Si en su lugar obtienes 200, 400 o 426, algo intermedio eliminó las cabeceras Upgrade. Detrás de nginx tienes que reenviarlas explícitamente con proxy_http_version 1.1, proxy_set_header Upgrade $http_upgrade y proxy_set_header Connection upgrade.
Tras el cambio, el siguiente problema son los tiempos de espera por inactividad: nginx cierra las conexiones con proxy tras proxy_read_timeout, 60 segundos por defecto, y AWS ALB tiene un tiempo de espera por inactividad de 60 segundos, así que los sockets silenciosos necesitan pings. HTTP/2 no usa 101 en absoluto; los WebSockets sobre HTTP/2 usan el CONNECT extendido del RFC 8441. Un 101 no tiene cuerpo y nunca se almacena en caché.
Informativo (1xx)
Los códigos 1xx son informativos: el servidor ha recibido la solicitud y el intercambio continúa. Los navegadores y las bibliotecas HTTP se encargan de ellos por ti.
Cómo se ve
HTTP/1.1 101 Switching ProtocolsCómo comprobarlo
curl -s -o /dev/null -w "%{http_code}\n" https://example.com/