Como resolver err_ssl_protocol_error no Chrome e Edge

Você clica no link de uma loja on-line e, em vez dela, o Chrome mostra uma página cinza e simples: "Não foi possível estabelecer uma conexão segura com este site", a linha "shop.example enviou uma resposta inválida.", uma sugestão para executar o Diagnóstico de Rede do Windows e, lá embaixo, ERR_SSL_PROTOCOL_ERROR. Recarregar traz a mesma página de volta, e o Edge mostra o mesmo código.

Pode ser que a loja esteja mesmo com defeito, mas com a mesma frequência algo no seu computador ou na sua rede atrapalhou. Este guia explica o que o código significa e em que ponto do handshake seguro ele aparece, as causas que reproduzimos em servidores de teste, as correções na ordem em que vale a pena tentá-las, o que verificar se o site é seu e onde entram os proxies e as VPNs.

O que significa ERR_SSL_PROTOCOL_ERROR?#

Sites cujo endereço começa com https:// usam TLS (Transport Layer Security), a criptografia por trás do cadeado; o nome antigo, SSL, sobrevive em códigos de erro como este. Antes que qualquer página trafegue, o navegador e o servidor fazem um handshake curto: combinam uma versão de TLS e um método de criptografia, o servidor prova a identidade dele e os dois lados criam as chaves. O padrão do TLS 1.3, a RFC 8446, diz que um handshake que falha encerra a conexão.

A lista de erros de rede do Chromium, o código-fonte por trás do Chrome e do Edge, descreve o erro -107 em uma frase curta: "An SSL protocol error occurred." (Ocorreu um erro de protocolo SSL.) O código que converte as falhas de TLS nesses números explica a falta de detalhe: toda falha de handshake sem um código mais específico acaba como -107. O código diz que o handshake quebrou, não quem o quebrou.

Também não é um aviso de certificado. "Sua conexão não é particular" e os códigos que começam com NET::ERR_CERT_ vêm depois, quando o navegador avalia o certificado do site; aqui o handshake parou antes disso. Os problemas de certificado estão em Sua conexão não é particular: causas e como resolver.

O que diz a tela "Não foi possível estabelecer uma conexão segura com este site"?#

Essas linhas vêm dos arquivos de idioma do Chromium em português do Brasil, e a página nós reproduzimos no Chromium 145 com Windows 11; no Mac, o link diz "Tente executar o Diagnóstico de Rede". O Edge é feito sobre o Chromium e mostra o mesmo código, embora o texto possa ser diferente. Ao contrário de um aviso de certificado, a página não tem o botão Avançadas, porque não existe nenhuma conexão segura com a qual seguir em frente.

Em que ponto do handshake ele quebra?#

Uma página segura passa por estas paradas em uma fração de segundo:

1. Conexão. O navegador se conecta ao servidor, normalmente na porta 443, a porta padrão dos sites seguros. Se isso falhar, você vê "Não é possível acessar esse site" no lugar (Não é possível acessar esse site: o que é e por que acontece).
2. Client Hello. O navegador lista as versões de TLS e os métodos de criptografia que aceita e informa o site que quer acessar.
3. Server Hello. O servidor escolhe uma versão e um método. A maioria dos casos deste guia quebra aqui: o navegador recebe algo que não consegue ler como TLS, como uma página web comum, uma página de bloqueio ou bytes embaralhados. A seção 5 da RFC 8446 exige que o software TLS encerre a conexão quando chega uma mensagem inesperada assim.
4. Certificate. O servidor envia o certificado. Uma falha neste ponto produz um aviso de certificado.
5. Finished. Os dois lados confirmam as chaves, o cadeado aparece e a requisição da página sai.

Se o navegador e o servidor não têm nenhuma versão de TLS em comum na parada 3, normalmente porque o servidor só oferece TLS 1.0 ou 1.1, o título continua o mesmo, mas o código passa a ser ERR_SSL_VERSION_OR_CIPHER_MISMATCH.

O que causa ERR_SSL_PROTOCOL_ERROR?#

Reproduzimos os casos principais com pequenos servidores de teste no nosso próprio computador. No Chromium 145, tanto um servidor que falava HTTP sem criptografia na porta segura quanto um servidor que respondia ao Client Hello com bytes aleatórios geraram ERR_SSL_PROTOCOL_ERROR. Um servidor limitado a TLS 1.0 e 1.1 gerou ERR_SSL_VERSION_OR_CIPHER_MISMATCH, e uma conexão cortada no meio do handshake gerou ERR_CONNECTION_CLOSED ou ERR_CONNECTION_RESET.

O problema está do seu lado ou do lado do site?#

1. Abra outros dois ou três sites seguros. Se eles também falharem, a causa está no seu aparelho ou na sua rede.
2. Abra o site com problema no celular com o Wi-Fi desligado. Se ele também falhar nos dados móveis, o site está com defeito; espere ou avise o dono.
3. Se funcionar nos dados móveis, tente outro aparelho no seu Wi-Fi. Uma segunda falha aponta para a rede; um sucesso aponta para algum software no seu computador.
4. Abra uma janela anônima com Mais > Nova janela anônima no Chrome. As extensões só funcionam ali se você permitiu, então uma página que carrega na janela anônima aponta para uma extensão.

Como corrigir no computador?#

Recarregue a página depois de cada passo.

1. Desative as extensões. No Chrome, no canto superior direito, selecione Mais > Extensões > Gerenciar extensões e desative as extensões de VPN, de proxy, de bloqueio de anúncios e de "segurança" (os passos do Google). No Edge, selecione Extensões, à direita da barra de endereços, depois Gerenciar extensões, e use a chave ao lado de cada uma (os passos da Microsoft). Se o erro sumir, ative-as de novo uma por uma.
2. Teste o seu software de segurança. Programas com verificação de HTTPS, verificação de SSL ou proteção web se colocam no meio de cada handshake. Pause só esse recurso, recarregue uma vez e depois ative-o de novo. Se a pausa ajudou, atualize o programa ou fale com o suporte dele em vez de deixar a proteção desligada.
3. Desligue a VPN e os apps de filtragem, inclusive apps que bloqueiam anúncios passando o tráfego por eles mesmos. Confira se não há nenhum proxy esquecido configurado no Windows: Como remover um proxy do Chrome e do Windows.
4. Atualize o navegador. No Chrome, selecione Mais > Ajuda > Sobre o Google Chrome e depois Reiniciar, se aparecer (os passos do Google). No Edge, digite edge://settings/help na barra de endereços; você também chega a essa página por Configurações e mais > Ajuda e comentários. O software de segurança precisa entender o handshake que o navegador envia, então uma diferença grande de versão entre os dois pode quebrar a verificação.
5. Feche o navegador por completo e abra de novo. O Chrome e o Edge guardam na memória detalhes dos handshakes recentes; um reinício completo apaga esses dados.

Por que ele aparece só em uma rede?#

Escolas, escritórios, hotéis, roteadores com controle dos pais e alguns provedores de internet filtram sites. Quando um filtro bloqueia um site seguro respondendo no lugar dele com uma página comum, sem criptografia, o navegador recebe uma página web onde esperava um Server Hello. É a mesma situação que o nosso servidor de teste com HTTP sem criptografia criou.

Em uma rede de trabalho ou de escola, pergunte à equipe de TI; o bloqueio é uma decisão do dono da rede, não um defeito. Como as organizações inspecionam o tráfego criptografado está explicado em O que é inspeção profunda de pacotes (DPI) e como funciona?.

Por que localhost ou a página do roteador mostram o erro?#

Um servidor de desenvolvimento no seu computador escuta, por exemplo, em http://localhost:3000, mas o navegador abre https://localhost:3000. O servidor responde ao Client Hello em HTTP sem criptografia, e o Chrome mostra ERR_SSL_PROTOCOL_ERROR, exatamente como no nosso teste. Roteadores, impressoras, câmeras e unidades de rede em endereços como 192.168.1.1 podem se comportar do mesmo jeito.

Para o seu próprio aparelho na sua própria rede, digite http:// antes do endereço, com a porta, se houver. Se o servidor de teste deve usar HTTPS, ative isso nas configurações do servidor com um certificado em que o seu computador confie. Nunca faça isso com um site público: http:// envia tudo sem criptografia.

Se o site é seu: como corrigir o servidor#

Quando visitantes relatam o erro e você consegue reproduzi-lo em um celular com dados móveis, verifique o servidor:

1. Faça um teste de fora. O SSL Server Test da Qualys lista as versões de TLS que o seu site público oferece e a cadeia de certificados que ele envia.
2. Confirme que a porta 443 fala TLS de verdade. No nginx, o parâmetro ssl precisa estar na linha listen; listen 443; sozinho serve HTTP sem criptografia na porta segura. No Apache, o SSLEngine do mod_ssl vem desligado por padrão, então um bloco <VirtualHost *:443> precisa de SSLEngine on.
3. Ofereça TLS 1.2 e 1.3. A RFC 8996 declarou TLS 1.0 e 1.1 obsoletos em 2021, e um servidor limitado a eles recebe ERR_SSL_VERSION_OR_CIPHER_MISMATCH. O nginx oferece TLS 1.2 e 1.3 por padrão desde a versão 1.23.4.
4. Verifique cada servidor por trás do nome. Atrás de um balanceador de carga ou de uma CDN, uma única máquina mal configurada causa o erro só para alguns visitantes ou regiões. Para ver o que os visitantes de outro país recebem, teste a partir de um endereço IP de lá, por exemplo pelos Proxies residenciais.
5. Recarregue a configuração depois de cada mudança.

Um bloco mínimo do nginx; a linha ssl_protocols repete o padrão e só importa se algo o tiver alterado:

server {
    listen 443 ssl;
    server_name example.com www.example.com;
    ssl_certificate     /etc/ssl/example.com/fullchain.pem;
    ssl_certificate_key /etc/ssl/example.com/privkey.pem;
    ssl_protocols TLSv1.2 TLSv1.3;
}

Um certificado expirado, um nome que não confere ou um certificado intermediário ausente mostram o aviso de certificado, não esta página.

Nível avançado: verifique se a porta 443 fala TLS#

Esta verificação é para donos de sites que usam a linha de comando. O curl vem com o Windows 10, o Windows 11 e o macOS; no Windows PowerShell, digite curl.exe, porque ali curl é um apelido de outro comando. Este comando envia de propósito uma requisição sem criptografia para a porta segura:

curl -I http://example.com:443

Use o seu próprio domínio e leia a primeira linha da resposta:

• Uma linha de status normal, como HTTP/1.1 200 OK, ou um redirecionamento: a porta 443 responde em HTTP sem criptografia, então o TLS está desligado. O nosso servidor de teste com HTTP sem criptografia respondeu HTTP/1.0 200 OK.
• 400 Bad Request: é a resposta do nginx quando HTTP sem criptografia chega a uma porta TLS; a página dele diz "The plain HTTP request was sent to HTTPS port". O TLS está ligado.
• curl: (52) Empty reply from server: o servidor descartou a requisição sem criptografia, como fez o nosso servidor de teste com TLS. O TLS está ligado.

E se você usa um proxy ou uma VPN?#

Um proxy comum raramente é a causa. Para um site https://, o navegador pede um túnel ao proxy e faz o handshake com o site através dele, enquanto o proxy repassa os bytes criptografados sem lê-los. No nosso teste, um site que falava HTTP sem criptografia na porta segura deu o mesmo ERR_SSL_PROTOCOL_ERROR com e sem proxy, e um site configurado corretamente passou intacto. Trocar de proxy ou de servidor VPN não conserta um site com defeito.

Problemas de proxy mostram outros códigos: um túnel recusado dá ERR_TUNNEL_CONNECTION_FAILED (Como resolver err_tunnel_connection_failed no Chrome e Edge), e um proxy HTTP cadastrado como proxy HTTPS em uma extensão de proxy nos deu ERR_PROXY_CONNECTION_FAILED (Servidor proxy não está respondendo: como resolver o erro). A exceção é o software que abre o tráfego criptografado de propósito, como proxies de depuração e apps de VPN gratuitos que pedem para você instalar um certificado; ele fica dentro do handshake e pode quebrá-lo (O que é um proxy MITM? Guia de Charles, Fiddler e mitmproxy).

O gateway da Proxynet repassa os túneis sem descriptografá-los, então você não instala nenhum certificado nosso; para usar os Proxies HTTPS em um navegador, veja Configuração de proxy no Windows e no Chrome. Em scripts, o Playwright mostrou net::ERR_SSL_PROTOCOL_ERROR no nosso teste, e em Python um SSLError com WRONG_VERSION_NUMBER costuma indicar um proxy HTTP escrito com https:// (Max Retries Exceeded With URL: o que é e como resolver).

Erros comuns#

• Procurar um jeito de pular a página. Não existe conexão criptografada, então não há nada em que clicar para seguir. http:// envia seus dados sem criptografia; deixe isso para o seu próprio roteador ou servidor de teste.
• Deixar o antivírus desligado. Pause só a verificação, e só para um teste.
• Limpar o cache e os cookies várias vezes. Nenhum dos dois participa do handshake.
• Clicar em Clear SSL state (limpar estado SSL) no Windows. Esse botão antigo do Windows vem do Internet Explorer e esvazia o cache do próprio Windows; o Chrome e o Edge guardam o deles dentro do navegador, e um reinício completo o apaga.
• Desligar o QUIC em chrome://flags. O QUIC, o transporte por trás do HTTP/3, tem o próprio código, ERR_QUIC_PROTOCOL_ERROR.
• Acertar o relógio por causa deste erro. Uma data errada quebra a verificação do certificado, e isso traz um aviso de relógio ou de certificado.

Guia de decisão#

Perguntas frequentes#

Por que recebo ERR_SSL_PROTOCOL_ERROR em todos os navegadores?#

A causa está fora do navegador: software de segurança, um app de VPN ou de filtragem, ou a rede. As extensões não passam de um navegador para outro entre Chrome, Edge e Firefox, mas a verificação do antivírus e os filtros de rede afetam todos eles. Se um site falha em todo lugar, o próprio site está mal configurado.

Como corrigir ERR_SSL_PROTOCOL_ERROR em um celular Android?#

Alterne entre Wi-Fi e dados móveis, desative apps de VPN e de bloqueio de anúncios (muitos funcionam como uma VPN no celular), atualize o Chrome pelo Google Play e reinicie o celular. Se o site continuar falhando nos dados móveis, o problema está do lado do site.

Dá para contornar ERR_SSL_PROTOCOL_ERROR?#

Não, e não há nada para contornar. A conexão criptografada nunca se formou, então o Chrome não oferece nenhum caminho para seguir. Digitar http:// enviaria seus dados sem criptografia, o que só é aceitável para o seu próprio roteador ou servidor de teste.

Por que localhost mostra ERR_SSL_PROTOCOL_ERROR?#

O seu servidor de desenvolvimento fala HTTP sem criptografia e o navegador o abriu com https://. Use http://localhost com o número da porta ou ative o HTTPS nas configurações do servidor.

ERR_SSL_PROTOCOL_ERROR é sinal de que meu computador foi hackeado?#

Normalmente não; a maioria dos casos vem de software de segurança, filtros, extensões ou de um site mal configurado. Se um software que você nunca instalou estiver interceptando o tráfego criptografado, faça uma verificação de malware, e nunca instale um certificado que um site ou app pedir.

Uma VPN ou um proxy resolvem ERR_SSL_PROTOCOL_ERROR?#

Não quando o site está com defeito: a VPN ou o proxy levam o mesmo handshake ao mesmo servidor. Se a causa for um filtro na sua rede, a decisão é do dono da rede, então pergunte a ele.

Em resumo#

ERR_SSL_PROTOCOL_ERROR significa que o handshake TLS quebrou antes mesmo de o certificado ser verificado, normalmente porque o navegador recebeu algo diferente de um Server Hello válido. Descubra se falha um site ou todos e depois passe por extensões, software de segurança, apps de VPN e de filtragem e a rede; em localhost ou na página de um roteador, use http://. Se o site é seu, garanta que a porta 443 fale TLS 1.2 ou 1.3. Um túnel de proxy comum não toca no handshake; a nossa página de proxies explica os tipos de proxy e para que serve cada um.