101 Switching Protocols significa que el servidor acepta el encabezado de solicitud Upgrade del cliente. Justo después de la línea vacía que cierra la respuesta 101, ambas partes hablan otro protocolo en esa conexión. La respuesta debe incluir un encabezado Upgrade con el nombre del nuevo protocolo.
Hoy en día se trata casi siempre del handshake de WebSocket. El navegador envía un GET con Upgrade: websocket, Connection: Upgrade y una Sec-WebSocket-Key. El servidor responde 101 con el Sec-WebSocket-Accept correspondiente y, a partir de ese momento, ambas partes intercambian tramas WebSocket. El 101 también se usaba para la actualización h2c de HTTP/1.1 sin cifrar a HTTP/2, hoy obsoleta. En su lugar, los navegadores negocian HTTP/2 y HTTP/3 durante el handshake TLS (ALPN).
El mecanismo Upgrade solo existe en HTTP/1.1. HTTP/2 y HTTP/3 nunca envían 101; los WebSockets sobre esos protocolos usan CONNECT extendido (RFC 8441 y RFC 9220).
Ejemplo de respuesta
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=SEO y verificación de redirecciones
Un 101 nunca es el resultado de una solicitud normal de una página. Los navegadores y los rastreadores solo lo reciben cuando piden de forma explícita actualizar la conexión, por lo que no afecta a la indexación. Un verificador de redirecciones envía solicitudes GET, HEAD o POST normales y no verá un 101. Si se verifica un endpoint de WebSocket como si fuera una URL normal, suele responder con un código 4xx como 426 Upgrade Required o 400 Bad Request.
Causas frecuentes y casos de uso
- Un navegador abre un WebSocket (
new WebSocket('wss://...')) y el servidor acepta el handshake. - Un cliente pide la actualización obsoleta
h2ca HTTP/2 sin cifrar y el servidor la admite. - Los WebSockets fallan detrás de un proxy inverso porque este no reenvía los encabezados
UpgradeyConnection. En nginx, configuraproxy_http_version 1.1y pasa ambos encabezados al backend.