HTTP 505 HTTP Version Not Supported: o que significa e como corrigir

O que este erro significa e como reconhecê-lo

• Um navegador, cliente de API, sistema de monitoramento ou ferramenta de linha de comando recebe 505 HTTP Version Not Supported.
• A resposta pode incluir uma mensagem informando que a versão HTTP solicitada não é compatível.
• O DNS pode ser resolvido com sucesso e o TLS pode ser concluído com sucesso, pois o cliente recebeu uma resposta HTTP depois disso.
• O erro pode ocorrer apenas com um cliente, caminho de negociação de protocolo, URL, método HTTP ou intermediário específico.
• Os cabeçalhos da resposta podem revelar se ela veio de um proxy, CDN, load balancer ou servidor de origem, além de mostrar detalhes de cache ou conexão.

Causas principais, por probabilidade

1. Versão de protocolo HTTP não compatível: O endpoint não é compatível com a versão principal do HTTP usada pela solicitação. Essa é a causa que define o status 505.
2. Incompatibilidade de protocolo entre um intermediário e seu upstream: Um reverse proxy, CDN, load balancer ou gateway pode usar uma versão de protocolo que o próximo servidor não aceita ou pode retornar sua própria resposta 505.
3. Configuração de protocolo HTTP incorreta ou incompleta: Uma alteração recente no servidor, proxy ou aplicativo pode ter habilitado ou exigido uma versão de protocolo que não é compatível em todo o caminho da solicitação.
4. Negociação ou comportamento de solicitação específico do cliente: Um cliente ou ferramenta de monitoramento pode selecionar um protocolo HTTP diferente do usado por navegadores ou outros clientes, expondo um problema de compatibilidade.
5. Resposta inesperada de uma camada que não é a origem: O status pode ser produzido por um gateway ou intermediário de segurança, e não pelo aplicativo responsável pela URL. São necessários cabeçalhos e logs para distinguir esse caso de uma resposta do servidor de origem.

Autenticação, limites de taxa, DNS e TLS podem afetar uma solicitação, mas não explicam por si só uma resposta HTTP 505. Trate-os como caminhos de investigação separados, a menos que os cabeçalhos da resposta ou os logs os relacionem à falha de versão do protocolo.

Como corrigir

Para visitantes e usuários de API

1. Tente acessar a URL exata novamente uma vez e verifique se o cliente está atualizado e configurado para fazer uma solicitação HTTP normal.
2. Se o problema ocorrer em um cliente de API ou ferramenta de monitoramento, compare o resultado com outro cliente compatível. Registre se a falha é específica do cliente.
3. Anote a URL, o método HTTP, o horário aproximado, o status da resposta e os cabeçalhos da resposta. Não inclua senhas, cookies, tokens de autorização ou outros segredos.
4. Se o erro persistir, envie esses detalhes sanitizados ao responsável pelo site ou pela API. Em geral, um visitante não pode corrigir um problema de compatibilidade de protocolo no servidor.

Para desenvolvedores e administradores de sites

1. Capture a solicitação exata. Registre o hostname, o caminho, o método, o protocolo da solicitação, o cliente, o timestamp e o status final. Confirme que a resposta é realmente 505, e não um redirecionamento ou um status exibido pelo cliente após outra falha.
2. Verifique a negociação do protocolo. Determine qual versão HTTP o cliente usou ou tentou usar e quais versões o endpoint, proxy, load balancer ou CDN aceita. Em conexões criptografadas, analise o protocolo de aplicação negociado quando suas ferramentas o disponibilizarem.
3. Identifique a camada da resposta. Use cabeçalhos da resposta, assinaturas do servidor quando disponíveis, identificadores de solicitação e logs de acesso para determinar se o 505 veio da CDN, WAF, gateway, reverse proxy, servidor web ou aplicativo.
4. Correlacione os logs. Pesquise na camada identificada e na camada upstream pelo mesmo timestamp, rota, método, cliente e ID da solicitação. A ausência de um log na origem pode indicar que um intermediário rejeitou a solicitação antes de encaminhá-la.
5. Revise alterações recentes de protocolo. Verifique implantações e alterações de configuração recentes que afetem o suporte a versões HTTP, conexões do proxy com a origem, listeners do load balancer, roteamento do gateway e a configuração do cliente ou monitoramento.
6. Aplique a correção autorizada mais específica. Alinhe o cliente, o intermediário e a origem afetados a uma versão de protocolo compatível com todo o caminho da solicitação. Não desative a validação de TLS, a autenticação ou os controles de segurança como solução alternativa.
7. Teste novamente a mesma solicitação. Verifique a URL e o método originais e, em seguida, teste rotas e caminhos de protocolo representativos. Confirme que a correção não alterou códigos de status ou comportamento de roteamento não relacionados.
8. Use uma implantação controlada para infraestrutura compartilhada. Se a configuração afetada atender a muitos sites ou rotas, teste-a em staging aprovado ou em uma alteração de escopo limitado antes de aplicá-la amplamente. Siga os procedimentos de alteração e rollback do ambiente.

Prevenção e como verificar a correção

• Documente as versões HTTP compatíveis com clientes, gateways, proxies, load balancers e origens em cada caminho de solicitação.
• Teste rotas importantes de navegador e métodos de API pelo caminho real de proxy e CDN, semelhante ao de produção, após alterações de protocolo ou infraestrutura.
• Monitore os códigos de status por rota, tipo de cliente, protocolo e implantação para que respostas 505 específicas de clientes sejam identificadas.
• Mantenha as configurações de proxy, load balancer, servidor web e aplicativo sob controle de versão, com um caminho de rollback testado.
• Retenha logs correlacionados de acesso e gateway por tempo suficiente para identificar qual camada gerou uma resposta inesperada.
• Mantenha as ferramentas de monitoramento e os clientes de API atualizados e valide suas configurações de protocolo durante a integração ou alterações de configuração.

Perguntas frequentes