ERR_SSL_PROTOCOL_ERROR: como resolver no Chrome e localhost

O que é ERR_SSL_PROTOCOL_ERROR?

ERR_SSL_PROTOCOL_ERROR significa que a conexão segura falhou durante o handshake TLS, antes de o navegador conseguir carregar qualquer coisa. O Chrome e o Edge mostram o erro como "Não foi possível estabelecer uma conexão segura com este site. example.com enviou uma resposta inválida." Se o endereço for localhost, quase com certeza o seu servidor de desenvolvimento fala HTTP simples: abra http://localhost (veja a seção para desenvolvedores abaixo).

Toda conexão HTTPS começa com um handshake TLS, no qual o navegador e o servidor combinam a versão do protocolo (TLS 1.2 ou 1.3) e as cifras e trocam certificados. ERR_SSL_PROTOCOL_ERROR significa que essa negociação falhou: o outro lado respondeu com algo que não é TLS válido, ou rejeitou o handshake de um jeito que o navegador não soube classificar.

Isso acontece antes de qualquer requisição HTTP ser enviada, então não é um código de status HTTP. A lista de erros do Chromium o define como o erro -107, com uma linha só, "An SSL protocol error occurred": é o erro genérico de um handshake quebrado, ao contrário do erro específico -113, "sem versão de protocolo ou cifra em comum".

Como o ERR_SSL_PROTOCOL_ERROR aparece

O Chrome e outros navegadores baseados no Chromium exibem esse erro como um aviso de página inteira com a mensagem "Não foi possível estabelecer uma conexão segura com este site." Abaixo, você verá o código de erro específico. Veja as variações mais comuns que você pode encontrar.

• localhost enviou uma resposta inválida — a versão que os desenvolvedores veem: https:// aberto em um servidor local que fala HTTP simples
• ERR_SSL_PROTOCOL_ERROR — o código de erro que o Chrome mostra em letras pequenas abaixo da mensagem
• net::ERR_SSL_PROTOCOL_ERROR — o código de erro interno completo, exibido no console do DevTools do Chrome
• Não foi possível estabelecer uma conexão segura com este site — a mensagem principal que o usuário vê no Chrome
• [domínio] enviou uma resposta inválida — o texto detalhado que o Chrome exibe abaixo da mensagem principal
• ERR_SSL_PROTOCOL_ERROR em todos os navegadores — quando o erro aparece ao mesmo tempo no Chrome, Edge, Brave e Opera (indica um problema no servidor ou no sistema inteiro, não um bug de um navegador específico)

O que causa o ERR_SSL_PROTOCOL_ERROR?

Esse erro tem causas tanto do lado do cliente (seu dispositivo) quanto do servidor (o site). Identificar de qual lado está o problema é o primeiro passo para resolvê-lo. Se o erro aparece em todos os sites, o problema está do seu lado. Se aparece apenas em um site específico, provavelmente é um problema no servidor.

• HTTPS enviado a um servidor que fala HTTP — o caso mais pesquisado: https://localhost em um servidor de desenvolvimento, ou um site cuja porta 443 não está configurada para TLS. O navegador inicia um handshake e recebe texto simples de volta, o que o Chrome informa como "enviou uma resposta inválida".
• Varredura SSL/HTTPS do antivírus — programas de segurança que interceptam o HTTPS (Avast, Kaspersky, Bitdefender, ESET) se inserem no handshake e podem quebrá-lo, em todos os sites de uma vez.
• Interferência de VPN ou proxy — VPNs e proxies corporativos que inspecionam o tráfego HTTPS podem corromper o handshake, principalmente logo após trocar de rede.
• Uma rede que filtra o site — filtros de provedores, escolas, empresas e países, e bloqueadores baseados em DNS, quebram o handshake de propósito nos sites que bloqueiam. O sinal: o site abre nos dados móveis ou em outro Wi-Fi.
• Uma configuração TLS quebrada no servidor — a porta 443 respondendo em HTTP simples (um bloco de servidor na 443 sem TLS ativado), ou outro programa escutando na porta 443.
• Extensões do navegador — complementos de privacidade, bloqueio de anúncios e segurança que reescrevem requisições HTTPS podem atrapalhar o handshake.
• Dados antigos no navegador — dados de sessão em cache que não correspondem mais ao servidor.
• Muitas vezes confundido com ele — um servidor preso no TLS 1.0 ou 1.1 mostra ERR_SSL_VERSION_OR_CIPHER_MISMATCH ("usa um protocolo incompatível"); um certificado vencido, com nome errado ou autoassinado, ou um relógio errado, mostra um erro de certificado (NET::ERR_CERT_…); e um problema de QUIC (HTTP/3) mostra ERR_QUIC_PROTOCOL_ERROR. Veja ERR_SSL_VERSION_OR_CIPHER_MISMATCH e "Sua conexão não é particular".

ERR_SSL_PROTOCOL_ERROR no localhost (desenvolvedores)

localhost enviou uma resposta inválida. ERR_SSL_PROTOCOL_ERROR quase sempre significa que você abriu https://localhost em um servidor de desenvolvimento que só fala HTTP simples. O navegador inicia um handshake TLS, o servidor responde com texto HTTP comum, e o Chrome informa essa resposta como inválida. O Firefox informa o mesmo engano como SSL_ERROR_RX_RECORD_TOO_LONG.

• Use o endereço que o servidor mostra — troque https://localhost:3000 por http://localhost:3000. Os servidores de desenvolvimento de Next.js, Vite, React, Django, Rails e Flask servem HTTP, a menos que você ative o HTTPS
• Confira a porta — https://localhost sem porta significa a porta 443. Se o seu app roda na 3000 ou na 5173, a requisição chega a outro programa, ou a nada
• O Chrome continua mudando para https:// — um redirecionamento guardado de um app anterior na mesma porta pode causar isso: limpe imagens e arquivos em cache ou teste em uma janela anônima. (Versões do Chrome anteriores à 132 também podiam guardar uma entrada HSTS para localhost, que você apaga em Delete domain security policies em chrome://net-internals/#hsts)
• Você precisa de HTTPS localmente (callbacks de OAuth, cookies seguros) — next dev --experimental-https cria um certificado confiável localmente com o mkcert; o Vite aceita opções de certificado em server.https, ou @vitejs/plugin-basic-ssl para um autoassinado rápido; em qualquer outro lugar, mkcert -install && mkcert localhost 127.0.0.1 gera arquivos que o seu servidor pode carregar
• Um certificado autoassinado dá outro erro — NET::ERR_CERT_AUTHORITY_INVALID, não este. Clique em Avançadas → Ir para localhost (não seguro) ou, melhor, use um certificado do mkcert (o antigo flag allow-insecure-localhost expirou)

Como corrigir o ERR_SSL_PROTOCOL_ERROR (para usuários)

Comece pela Correção 1: em dois minutos ela mostra se o problema está no navegador, no dispositivo ou na rede, ou no site. Depois siga a lista de cima para baixo.

Correção 1: tente o modo anônimo e outra rede

A janela anônima começa sem cookies, sem cache e sem extensões (a menos que você as tenha permitido nela). Abra o site em uma janela anônima (Ctrl+Shift+N no Chrome e no Edge, Ctrl+Shift+P no Firefox) e depois em outra rede, como os dados móveis do celular.

Se carrega no modo anônimo, a causa está no navegador: uma extensão ou dados antigos (Correções 4 e 5). Se carrega só em outra rede, a sua rede, ou uma VPN ou proxy, filtra ou intercepta o site (Correção 3). Se falha em todo lugar, teste o site com um Verificador de certificado SSL: se ele também falhar, só o dono do site pode resolver.

Correção 2: desativar a varredura SSL/HTTPS do antivírus

Muitos antivírus (Avast, Kaspersky, Bitdefender, ESET, Norton) incluem um recurso de "varredura HTTPS" ou "inspeção SSL" que intercepta conexões criptografadas agindo como um proxy man-in-the-middle. Quando ele trata mal o handshake de um site, todos os navegadores do computador falham nesse site.

Procure no antivírus configurações chamadas Web Shield, HTTPS Scanning, SSL Scanning ou Encrypted connections scanning e desative-as temporariamente. Se o erro sumir, você pode adicionar o domínio afetado à lista de exclusões do antivírus.

Correção 3: desativar VPN ou proxy

VPNs e proxies HTTP ficam entre o navegador e o servidor web. Algumas VPNs inspecionam o tráfego HTTPS ou encaminham conexões por servidores com TLS quebrado. Proxies corporativos costumam usar interceptação de SSL (parecida com a varredura HTTPS do antivírus), que pode quebrar handshakes TLS.

Desconecte a VPN temporariamente e tente carregar o site. Se funcionar sem a VPN, o problema está em como ela trata as conexões SSL. Tente outro servidor da VPN ou fale com o provedor.

Correção 4: desativar extensões do navegador

Extensões que filtram ou redirecionam o tráfego, como extensões de VPN e proxy e complementos de segurança, podem quebrar conexões seguras.

Vá em chrome://extensions/, desative todas as extensões e recarregue a página. Se o erro sumir, reative-as uma a uma para achar a responsável.

Correção 5: limpar cache e cookies do navegador

Cookies ou dados em cache antigos às vezes atrapalham, e limpá-los leva um minuto.

• Passo 1: Pressione Ctrl+Shift+Delete (Mac: Cmd+Shift+Delete) para abrir Excluir dados de navegação
• Passo 2: Escolha Mais → Todo o período como intervalo de tempo
• Passo 3: Marque Cookies e outros dados de sites e Imagens e arquivos em cache
• Passo 4: Clique em Excluir dados (Excluir deste dispositivo se você não estiver conectado) e reinicie o Chrome

Para um único site, vá em chrome://settings/content/all, pesquise o domínio e exclua os dados dele.

Correção 6: descartar o QUIC (HTTP/3)

O Chrome tenta o QUIC (HTTP/3 sobre UDP) junto com uma conexão TCP normal e volta para o TCP quando o QUIC falha, então o QUIC raramente causa ERR_SSL_PROTOCOL_ERROR. Se a página ou o DevTools mostrar ERR_QUIC_PROTOCOL_ERROR, desativar o QUIC é a solução (veja ERR_QUIC_PROTOCOL_ERROR):

• Passo 1: Digite chrome://flags/#enable-quic na barra de endereço
• Passo 2: Encontre Experimental QUIC protocol
• Passo 3: Mude de Default para Disabled
• Passo 4: Clique em Relaunch para reiniciar o Chrome

As páginas continuam carregando com o QUIC desativado, via HTTP/2 sobre TCP; reative-o depois que a rede ou o site for corrigido.

Correção 7: atualize seu navegador

Versões antigas do navegador podem não ter os recursos e cifras TLS que os sites modernos esperam, e as atualizações corrigem bugs de TLS.

Atualize o Chrome: vá em chrome://settings/help ou Menu → Ajuda → Sobre o Google Chrome. O Chrome baixa as atualizações automaticamente, mas precisa reiniciar para aplicá-las. Para o Edge: edge://settings/help. Para o Firefox: Menu → Ajuda → Sobre o Firefox.

Correção 8: limpar o cache DNS

Um DNS desatualizado pode levar o navegador a um servidor antigo que não serve mais o site via TLS. Limpar o cache DNS força uma nova consulta.

# Windows (Command Prompt as Admin)
ipconfig /flushdns

# macOS
sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder

# Linux
sudo resolvectl flush-caches

# Chrome internal DNS cache
# Visit chrome://net-internals/#dns → Click "Clear host cache"

Depois de limpar, confira se o domínio resolve para o IP correto com a ferramenta de Consulta DNS do DNS Robot. Se o endereço IP parecer errado, o site pode ter mudado de provedor de hospedagem e o DNS ainda não propagou totalmente.

Correção 9: verifique a data e hora do sistema

Um relógio errado normalmente aparece como outro erro, NET::ERR_CERT_DATE_INVALID ("Seu relógio está adiantado" ou "Seu relógio está atrasado"), porque um certificado só vale entre duas datas. Ainda assim, descartar isso leva dez segundos:

• Windows: Configurações → Hora e idioma → Data e hora → ative "Definir horário automaticamente" e "Definir fuso horário automaticamente"
• Mac: Ajustes do Sistema → Geral → Data e Hora → ative "Definir data e hora automaticamente"
• Linux: execute sudo timedatectl set-ntp true para ativar a sincronização NTP

Correção 10: limpar o estado SSL (Windows)

Muitos guias sugerem Limpar estado SSL nas Opções da Internet do Windows (inetcpl.cpl → Conteúdo → Limpar estado SSL). Isso limpa o cache de sessões da biblioteca TLS do próprio Windows, usada por apps que dependem da rede do Windows. O Chrome e o Edge usam a sua própria biblioteca TLS, então isso raramente muda algo para eles.

O equivalente para o navegador é mais simples: feche todas as janelas do navegador (confira a bandeja do sistema, onde pode haver um Chrome em segundo plano) e abra-o de novo. Isso descarta todas as sessões TLS em cache. Se o erro sobreviver a uma reinicialização completa, passe para as próximas correções.

Correção 11: redefinir configurações de rede (último recurso)

Se nada mais funcionar, redefina a pilha de rede. No Windows, estes comandos redefinem o Winsock e o TCP/IP, incluindo endereços IP estáticos e servidores DNS configurados manualmente; no macOS e no Linux, eles só limpam o cache DNS ou reiniciam o serviço de rede.

# Windows (Command Prompt as Admin)
netsh winsock reset
netsh int ip reset
ipconfig /release
ipconfig /renew
ipconfig /flushdns

# Then restart your computer

# macOS — flush the DNS cache
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

# Linux — restart NetworkManager
sudo systemctl restart NetworkManager

Como corrigir o ERR_SSL_PROTOCOL_ERROR (para donos de sites)

Se muitos visitantes relatam ERR_SSL_PROTOCOL_ERROR, o problema está no servidor: em geral a porta 443 respondendo em HTTP simples, ou outro programa nessa porta. Problemas de certificado mostram os próprios erros, mas confira-os já que está lá. (Um certificado e uma chave que não combinam impedem o servidor de carregar a nova configuração: verifique com nginx -t ou apachectl configtest depois de qualquer mudança.)

Verifique seu certificado SSL

O primeiro passo é verificar se o certificado SSL é válido, está instalado corretamente e não venceu. Use o Verificador de certificado SSL do DNS Robot para checar na hora o status do certificado, a data de expiração, o emissor e a cadeia de certificados.

Estes problemas de certificado mostram os próprios erros, e não ERR_SSL_PROTOCOL_ERROR, mas corrija-os já que está lá:

• Certificado vencido (NET::ERR_CERT_DATE_INVALID) — os certificados do Let's Encrypt duram 90 dias (64 dias a partir de fevereiro de 2027), então a renovação precisa ser automática; se ela falhar (timer do certbot parado, desafio DNS quebrado), o certificado vence sem aviso.
• Domínio errado (NET::ERR_CERT_COMMON_NAME_INVALID) — o certificado foi emitido para example.com, mas o site é servido em www.example.com (ou vice-versa). O certificado precisa corresponder ao domínio exato ou incluir um curinga (*.example.com).
• Certificado autoassinado (NET::ERR_CERT_AUTHORITY_INVALID) — serve para desenvolvimento, mas nunca é confiável para os navegadores em produção.
• Certificado revogado (NET::ERR_CERT_REVOKED) — a autoridade certificadora o revogou após o comprometimento da chave ou uma emissão indevida.
• Certificado errado para o nome (NET::ERR_CERT_COMMON_NAME_INVALID) — vários sites compartilham um IP e o servidor não usa SNI (Server Name Indication) para escolher o certificado de cada site.

# Check certificate from command line
openssl s_client -connect yourdomain.com:443 -servername yourdomain.com </dev/null 2>/dev/null | openssl x509 -noout -dates -subject -issuer

# Check certificate chain completeness
openssl s_client -connect yourdomain.com:443 -servername yourdomain.com </dev/null 2>&1 | grep -E "depth|Verify"

# Renew Let's Encrypt certificate
sudo certbot renew --dry-run   # test first
sudo certbot renew

Ative o TLS 1.2 e TLS 1.3

Todos os navegadores modernos exigem pelo menos o TLS 1.2: o TLS 1.0 e o 1.1 foram oficialmente descontinuados pela RFC 8996 em 2021. Um lado que recusa a versão do outro encerra o handshake com o alerta TLS 70, protocol_version (RFC 8446 §6.2). Um servidor que só suporta TLS 1.0 ou 1.1 mostra ERR_SSL_VERSION_OR_CIPHER_MISMATCH em vez deste erro, mas falha do mesmo jeito. O TLS 1.3 conecta em uma ida e volta, em vez das duas do TLS 1.2: ative os dois.

# Nginx — ssl_protocols in nginx.conf or site config
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384';
ssl_prefer_server_ciphers off;

# Apache — in httpd.conf or ssl.conf
SSLProtocol -all +TLSv1.2 +TLSv1.3
SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256
SSLHonorCipherOrder off

Depois de atualizar a configuração TLS, reinicie o servidor web (sudo systemctl restart nginx ou sudo systemctl restart apache2) e teste com o Verificador de certificado SSL do DNS Robot para confirmar que os protocolos estão ativos.

Instale a cadeia completa de certificados

Uma cadeia incompleta aparece como erro de certificado (NET::ERR_CERT_AUTHORITY_INVALID) nos navegadores e apps que não conseguem preencher o intermediário que falta, então instale a cadeia completa enquanto estiver verificando. O servidor precisa enviar o seu certificado mais os certificados intermediários que o ligam a uma raiz confiável.

A maioria das autoridades certificadoras oferece um arquivo "CA bundle" ou "full chain". No Let's Encrypt, use fullchain.pem (e não só cert.pem). Em outras CAs, baixe o certificado intermediário na documentação delas e concatene-o com o seu certificado.

# Nginx — use fullchain, not just cert
ssl_certificate /etc/letsencrypt/live/yourdomain.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/yourdomain.com/privkey.pem;

# Apache
SSLCertificateFile /etc/letsencrypt/live/yourdomain.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/yourdomain.com/privkey.pem

Verifique a configuração HSTS

O HSTS (HTTP Strict Transport Security) diz aos navegadores para usar sempre HTTPS no seu domínio. Se a política HSTS tem um max-age longo e a sua configuração TLS quebra depois, os navegadores não podem voltar para o HTTP: os visitantes veem uma página de erro sem como prosseguir.

Confira o cabeçalho HSTS com o Verificador de headers HTTP do DNS Robot. Se você definiu um max-age muito longo (como 2 anos) e o certificado venceu, quem já visitou o site fica preso ao HTTPS sem alternativa. Para resolver, primeiro corrija o certificado SSL; depois os navegadores voltam a conectar normalmente.

Verifique a configuração do servidor

Este erro de servidor quebra o handshake mesmo com um certificado válido, e mais um mostra um erro diferente:

• Porta 443 servindo HTTP simples — a causa clássica do lado do dono: no nginx, listen 443; sem ssl (precisa ser listen 443 ssl;), ou outro serviço ligado à porta 443.
• Incompatibilidade de cifras — um servidor que só oferece cifras que os navegadores recusam mostra ERR_SSL_VERSION_OR_CIPHER_MISMATCH. Use cifras AEAD modernas (AES-GCM, ChaCha20).

Teste de fora com openssl s_client -connect example.com:443 -servername example.com </dev/null: "wrong version number" (OpenSSL) ou "tlsv1 alert protocol version" (o openssl que vem no macOS) significa que a porta 443 não fala TLS, e a exibição de um certificado significa que o handshake funciona.

ERR_SSL_PROTOCOL_ERROR no Android

Usuários Android encontram ERR_SSL_PROTOCOL_ERROR tanto no Chrome para Android quanto em apps baseados em WebView. As correções diferem um pouco do desktop porque o Android gerencia certificados e configurações de rede de maneira diferente.

• Troque de rede — desligue o Wi-Fi e tente os dados móveis (ou o contrário). Se o site carregar, a rede está filtrando ou interceptando o acesso
• Desative o DNS particular para testar — Configurações → Rede e Internet → DNS particular → Desativado (e no Chrome: Configurações → Privacidade e segurança → Usar DNS seguro). Um serviço de DNS com filtro (bloqueio de anúncios, controle dos pais) envia os sites que bloqueia a um servidor que não consegue concluir o handshake
• Limpe os dados do Chrome — Configurações → Apps → Chrome → Armazenamento → Limpar cache (depois "Manage space", se isso não resolver)
• Atualize o Chrome — Play Store → sua foto de perfil → Gerenciar apps e dispositivos → atualize o Chrome
• Limpe as credenciais de rede — Configurações → Segurança (em celulares mais novos: Mais configurações de segurança → Criptografia e credenciais) → Limpar credenciais. Isso remove todos os certificados instalados pelo usuário
• Confira a data e a hora — Configurações → Sistema → Data e hora → automáticas. Um relógio errado mostra um erro de certificado, mas é rápido descartar isso
• Redefina as configurações de rede — Configurações → Sistema → Opções de redefinição, depois a redefinição do Wi-Fi e da rede móvel (o nome varia conforme a versão do Android)

ERR_SSL_PROTOCOL_ERROR no iPhone e no iPad

No iPhone, o Chrome mostra ERR_SSL_PROTOCOL_ERROR e o Safari diz que "Safari can't establish a secure connection to the server" (mensagem em inglês: não achei o texto em português nos materiais da Apple). As causas são as mesmas de um computador; os ajustes ficam em outros lugares:

• Troque de rede — desligue o Wi-Fi e tente os dados móveis. Se o site carregar, a rede Wi-Fi está filtrando ou interceptando o acesso
• Remova VPNs e perfis que você não reconhece — Ajustes → Geral → Gestão de VPN e Dispositivo. Um perfil que instala o próprio certificado ou uma VPN pode interceptar o HTTPS
• Teste sem a Retransmissão Privada do iCloud — Ajustes → [seu nome] → iCloud → Retransmissão Privada → desativada, e tente de novo
• Confira os limites do Tempo de Uso — Ajustes → Tempo de Uso → Conteúdo e Privacidade, e depois o ajuste de conteúdo da web. Um site bloqueado falha em vez de carregar
• Defina o relógio como automático — Ajustes → Geral → Data e Hora → Definir Automaticamente

ERR_SSL_PROTOCOL_ERROR em outros navegadores

ERR_SSL_PROTOCOL_ERROR é um código de erro específico do Chromium. Outros navegadores mostram mensagens diferentes para a mesma falha de handshake SSL.

Se o erro aparece em todos os navegadores ao mesmo tempo, o problema está no seu sistema (varredura HTTPS do antivírus, uma VPN ou proxy, a rede) ou no servidor (a porta 443 não serve TLS direito). Se só um navegador falha, confira as extensões e os dados em cache dele.

Códigos de erro SSL/TLS relacionados

O Chrome tem vários códigos de erro relacionados a SSL. Todos indicam problemas diferentes de handshake TLS ou de certificado.

Para qualquer erro de SSL, você pode diagnosticar o problema rapidamente com o Verificador de certificado SSL do DNS Robot: ele mostra o status do certificado, a integridade da cadeia, as versões de TLS suportadas e a data de expiração em uma única verificação.

Se a sua página diz que o site "usa um protocolo incompatível", você tem ERR_SSL_VERSION_OR_CIPHER_MISMATCH, não este erro: veja como corrigir o ERR_SSL_VERSION_OR_CIPHER_MISMATCH.

Se a página disser "example.com encerrou a conexão inesperadamente" (ERR_CONNECTION_CLOSED), a conexão foi interrompida em vez de falhar. Veja ERR_CONNECTION_CLOSED para esse caso.