101 Switching Protocols significa que o servidor aceita o cabeçalho de requisição Upgrade enviado pelo cliente. Logo após a linha em branco que encerra a resposta 101, os dois lados passam a falar outro protocolo nessa conexão. A resposta precisa conter um cabeçalho Upgrade com o nome do novo protocolo.
Hoje, isso é quase sempre o handshake do WebSocket. O navegador envia um GET com Upgrade: websocket, Connection: Upgrade e um Sec-WebSocket-Key. O servidor responde 101 com o Sec-WebSocket-Accept correspondente e, a partir daí, os dois lados trocam frames WebSocket. O 101 também era usado no upgrade h2c (hoje obsoleto), do HTTP/1.1 em texto puro, sem TLS, para o HTTP/2. Em vez disso, os navegadores negociam o HTTP/2 e o HTTP/3 durante o handshake TLS (ALPN).
O mecanismo Upgrade só existe no HTTP/1.1. O HTTP/2 e o HTTP/3 nunca enviam 101; nesses protocolos, os WebSockets usam o CONNECT estendido (RFC 8441 e RFC 9220).
Exemplo de resposta
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=SEO e verificação de redirecionamentos
Um 101 nunca é o resultado de uma requisição comum de página. Navegadores e rastreadores só o recebem quando pedem explicitamente o upgrade da conexão; por isso, ele não tem nenhum efeito na indexação. Um verificador de redirecionamento envia requisições GET, HEAD ou POST simples e não vai ver um 101. Se um endpoint WebSocket for verificado como uma URL normal, ele geralmente responde com um código 4xx, como 426 Upgrade Required ou 400 Bad Request.
Causas comuns e casos de uso
- Um navegador abre um WebSocket (
new WebSocket('wss://...')) e o servidor aceita o handshake. - Um cliente pede o upgrade obsoleto
h2cpara HTTP/2 em texto puro, e o servidor dá suporte a ele. - Os WebSockets falham atrás de um proxy reverso porque o proxy não repassa os cabeçalhos
UpgradeeConnection. No nginx, definaproxy_http_version 1.1e repasse os dois cabeçalhos para o backend.