---
title: "Como resolver err_ssl_protocol_error no Chrome e Edge"
description: "err_ssl_protocol_error e \"Não foi possível estabelecer uma conexão segura com este site\": o handshake TLS falhou. Descubra se o problema é seu ou do site."
url: https://proxynet.io/pt-br/blog/err-ssl-protocol-error
date: 2026-10-05
author: "Acar Diveroli"
category: "Tutoriais"
lang: pt-BR
---

# 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.

> **Nota: Resposta rápida**
>
> `ERR_SSL_PROTOCOL_ERROR` significa que o navegador chegou ao servidor do site, mas o handshake TLS, a troca inicial que estabelece uma conexão criptografada, falhou porque a resposta não era válida. Se um site falha em todos os aparelhos e redes, esse site está mal configurado, muitas vezes servindo HTTP sem criptografia na porta segura, e só o dono pode corrigir. Se muitos sites falham em um computador ou em uma rede, tente uma janela anônima, desative extensões, VPN e apps de filtragem, pause a verificação de HTTPS do antivírus por uma única recarga e atualize o navegador. Em `localhost` ou no endereço do seu roteador, digite `http://` no lugar. A página não oferece nenhum caminho para continuar, e você não deve procurar um.

## 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](https://www.rfc-editor.org/rfc/rfc8446.html), diz que um handshake que falha encerra a conexão.

A [lista de erros de rede](https://github.com/chromium/chromium/blob/main/net/base/net_error_list.h) 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](https://github.com/chromium/chromium/blob/main/net/ssl/openssl_ssl_util.cc) 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](/pt-br/blog/your-connection-is-not-private).

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

| Linha na tela | O que significa |
|---|---|
| "Não foi possível estabelecer uma conexão segura com este site" | O título do Chrome para falhas de handshake |
| "example.com enviou uma resposta inválida." | A resposta à primeira mensagem do navegador não era TLS válido. O Chrome dá o nome do site, mas não consegue saber se foi o site ou um aparelho no meio do caminho que a enviou |
| "Tente executar o Diagnóstico de Rede do Windows." | Um link para o solucionador de problemas do sistema; como o servidor respondeu, ele raramente encontra algo |
| `ERR_SSL_PROTOCOL_ERROR` e **Recarregar** | O código e um botão que simplesmente tenta de novo |

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](/pt-br/blog/this-site-cant-be-reached)).
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?

| Causa | Quem vê | Quem pode corrigir |
|---|---|---|
| O site serve HTTP sem criptografia na porta segura | Todo mundo, em qualquer aparelho | O dono do site |
| `https://` digitado para um aparelho ou servidor de teste que só fala HTTP | Só esse endereço | Você: use `http://` para o seu próprio aparelho |
| Falha um antivírus que verifica o tráfego criptografado | Muitos sites, um computador | Você: atualize ou reconfigure o programa |
| Uma VPN, um bloqueador de anúncios ou um app de "proteção" que filtra o tráfego | Muitos sites, um aparelho | Você: desative para testar |
| Um filtro de rede responde com a própria página sem criptografia | Sites bloqueados, a rede inteira | O administrador da rede |
| Uma extensão do navegador que mexe no tráfego | Um navegador | Você: desative |

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](https://support.google.com/chrome/answer/2664769?hl=pt-BR)). 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](https://support.microsoft.com/pt-br/microsoft-edge/add-turn-off-or-remove-extensions-in-microsoft-edge-9c0ec68c-2fbc-2f2c-9ff0-bdc76f46b026)). 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](/pt-br/blog/remove-proxy-chrome-windows).
4. **Atualize o navegador.** No Chrome, selecione **Mais > Ajuda > Sobre o Google Chrome** e depois **Reiniciar**, se aparecer ([os passos do Google](https://support.google.com/chrome/answer/95414?hl=pt-BR)). 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?](/pt-br/blog/what-is-deep-packet-inspection).

## 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](https://www.ssllabs.com/ssltest/) 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`](https://nginx.org/en/docs/http/configuring_https_servers.html); `listen 443;` sozinho serve HTTP sem criptografia na porta segura. No Apache, o [`SSLEngine`](https://httpd.apache.org/docs/2.4/mod/mod_ssl.html) 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](https://www.rfc-editor.org/rfc/rfc8996.html) 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](https://proxynet.io/pt-br/residential-proxy).
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:

```nginx
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:

```bash
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](/pt-br/blog/err-tunnel-connection-failed)), 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](/pt-br/blog/proxy-server-not-responding)). 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](/pt-br/blog/mitm-proxy)).

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](https://proxynet.io/pt-br/https-proxy) em um navegador, veja [Configuração de proxy no Windows e no Chrome](/pt-br/blog/windows-chrome-proxy-settings). 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](/pt-br/blog/max-retries-exceeded-with-url)).

## 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

| Situação | O que fazer |
|---|---|
| Um site falha em todos os aparelhos e redes | O site está com defeito; espere ou avise o dono |
| Todos os sites seguros falham em um computador | Extensões, depois software de segurança, depois apps de VPN ou de filtragem |
| Só uma rede Wi-Fi mostra o erro | Um filtro de rede; pergunte a quem administra a rede |
| A página carrega em uma janela anônima | Desative as extensões uma por uma |
| O endereço é `localhost` ou `192.168.x.x` | Use `http://` para o seu próprio aparelho |
| O site é seu | Verifique `listen 443 ssl` ou `SSLEngine on`, e TLS 1.2 e 1.3 |

## 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](/pt-br/proxy) explica os tipos de proxy e para que serve cada um.