ERR_QUIC_PROTOCOL_ERROR: o que é e como resolver no Chrome

O que é ERR_QUIC_PROTOCOL_ERROR?

ERR_QUIC_PROTOCOL_ERROR significa que a conexão QUIC do Chrome com o site caiu, geralmente depois que o site já tinha começado a enviar a página. O QUIC é o transporte baseado em UDP por trás do HTTP/3. O Chrome mostra sua página genérica "Não foi possível acessar o site" ("A página … pode estar temporariamente indisponível ou pode ter sido movida permanentemente para um novo endereço da Web") com o código embaixo; o Chromium o define como o erro -356, "There is a QUIC protocol error".

O Chrome normalmente se recupera sozinho: quando uma requisição QUIC falha, ele a repete por uma conexão TCP comum, a menos que o servidor já tivesse começado a responder (http_network_transaction.cc). Por isso, uma rede que bloqueia o QUIC por completo não causa esse erro; causa-o uma rede, VPN ou servidor que deixa o QUIC começar e depois o derruba.

Ele aparece apenas em navegadores baseados em Chromium: Chrome, Edge, Opera, Brave e Vivaldi. É uma falha diferente do ERR_SSL_PROTOCOL_ERROR (um handshake TLS quebrado) e do ERR_NETWORK_CHANGED (sua conexão mudou). Recarregue primeiro, porque a nova tentativa costuma funcionar; se o erro continuar voltando, as correções abaixo começam pela mais confiável, desativar o QUIC, e depois passam por cada causa.

O que é o QUIC e por que o Chrome o utiliza?

O QUIC foi desenvolvido pelo Google, anunciado pela primeira vez em 2013 e padronizado pelo IETF como RFC 9000 em 2021. Ele substitui TCP + TLS por um único protocolo criptografado sobre UDP e é o transporte do HTTP/3 (o DNS particular do Android também o usa para DNS sobre HTTP/3: veja o que é DNS particular).

Uma conexão TCP + TLS 1.3 precisa de duas idas e voltas antes da primeira requisição; o QUIC precisa de uma e pode retomar com zero. Em 7 de outubro de 2020, o Google anunciou que 25% dos usuários do Chrome Stable já usavam o IETF QUIC (rascunho h3-29). O Google mediu a latência da Pesquisa caindo mais de 2%, o rebuffering do YouTube caindo mais de 9% e o throughput subindo mais de 3% no desktop e 7% no celular (Chromium Blog).

O Chrome só usa QUIC quando um site o anuncia, em um cabeçalho Alt-Svc ou em um registro HTTPS de DNS. Verificamos 20 dos sites mais visitados em 26 de outubro de 2026: 10 anunciam HTTP/3 no cabeçalho Alt-Svc (Google, YouTube, Facebook, Instagram, Amazon, LinkedIn, Bing, WhatsApp, Cloudflare e OpenAI).

O que causa o ERR_QUIC_PROTOCOL_ERROR?

Toda causa segue o mesmo padrão: o QUIC começou e depois algo o derrubou.

• Uma rede que deixa o QUIC começar e depois o derruba — firewalls, roteadores ou equipamentos do provedor que descartam o tráfego UDP ou o deixam expirar no meio de uma transferência. (Uma rede que bloqueia a UDP 443 por completo só faz o Chrome usar TCP, sem erro.)
• Uma VPN que perde o UDP no meio da conexão — quando a VPN reconecta, troca de servidor ou de rota, ou deixa fluxos UDP ociosos expirarem, uma conexão QUIC aberta morre. (Um caminho pequeno demais para o QUIC falha durante o handshake, e aí o Chrome simplesmente usa TCP.)
• Software de segurança que inspeciona o tráfego — a "proteção da web" de antivírus ou firewall que intercepta conexões pode quebrar fluxos QUIC.
• Uma conexão instável — Wi-Fi fraco ou troca de rede no meio de um download.
• A configuração HTTP/3 do site — um servidor ou CDN que anuncia HTTP/3, mas cuja pilha QUIC falha no meio da resposta. Aí todos veem o erro naquele site, em qualquer rede: o Verificador de site fora do ar mostra se ele também falha para outras pessoas.
• Não é causa: um proxy — o Chrome só usa QUIC em conexões diretas; com um proxy configurado, toda requisição vai por TCP.

Correção 1: desativar o protocolo QUIC no Chrome

A correção mais confiável: com o QUIC desligado, o Chrome usa HTTP/2 (ou HTTP/1.1) sobre TCP em todos os sites. As páginas continuam carregando; você abre mão dos ganhos de velocidade do QUIC, que o Google mediu em cerca de 2% mais rápido na Pesquisa e 9% menos rebuffering no YouTube.

Para administradores de TI: a política do Chrome e do Edge QuicAllowed definida como false desativa o QUIC em dispositivos gerenciados, sem mexer em chrome://flags.

Desativar o QUIC no Google Chrome

Siga estes passos para desativar o QUIC no Chrome no Windows, Mac ou Linux.

1. Open Chrome and type in the address bar:
   chrome://flags/#enable-quic

2. Find "Experimental QUIC protocol"

3. Change the dropdown from "Default" to "Disabled"

4. Click "Relaunch" at the bottom to restart Chrome

5. Verify: visit the website that showed the error

Desativar o QUIC no Microsoft Edge

Como o Edge é baseado em Chromium, o processo é quase idêntico.

1. Open Edge and type in the address bar:
   edge://flags/#enable-quic

2. Find "Experimental QUIC protocol"

3. Change to "Disabled"

4. Click "Restart" to apply

Desativar o QUIC no Opera e Brave

Opera e Brave usam o mesmo sistema de flags do Chromium.

Opera:  opera://flags/#enable-quic → Disabled → Restart
Brave:  brave://flags/#enable-quic → Disabled → Restart

Correção 2: redefinir as conexões do Chrome

Limpar dados raramente resolve, mas redefinir as conexões abertas pode: o Chrome passa a abrir conexões QUIC (ou TCP) novas com o site.

Descarregar as conexões e depois limpar o cache

Comece por Flush socket pools (veja a nota abaixo). Se o erro continuar, limpe o cache:

1. Press Ctrl+Shift+Delete (Windows/Linux) or Cmd+Shift+Delete (Mac)

2. Choose More → All time for the time range

3. Tick "Cached images and files"

4. Click "Delete data" ("Delete from this device" if you're signed out)

5. Restart Chrome and try the website again

Correção 3: desativar as extensões do navegador

Raramente é a causa: extensões não conseguem mudar o QUIC em si, e as extensões de "VPN" do Chrome para desktop são na verdade proxies, que impedem o Chrome de usar QUIC.

Abra o site em uma janela anônima (Ctrl+Shift+N), onde as extensões ficam desativadas, a menos que você as tenha permitido. Se carregar lá, desative as extensões uma a uma em chrome://extensions/ para achar a responsável.

Correção 4: verificar o firewall e o antivírus

Um firewall que bloqueia a porta UDP 443 por completo não causa esse erro: o Chrome simplesmente usa TCP. O problema é um firewall ou suíte de segurança que deixa o QUIC começar e depois o descarta ou o inspeciona.

Libere a UDP 443 de saída por completo ou bloqueie-a por completo. Veja como verificar as configurações mais comuns.

Firewall do Windows

O Firewall do Windows Defender permite o tráfego de saída por padrão, e uma regra de bloqueio sempre vence uma de permissão; por isso, procure uma regra de bloqueio que alguém tenha adicionado e desative-a. Execute o PowerShell como administrador:

# List enabled outbound block rules that cover UDP (or any protocol)
Get-NetFirewallRule -Direction Outbound -Action Block -Enabled True |
  Where-Object { ($_ | Get-NetFirewallPortFilter).Protocol -in 'UDP', 'Any' } |
  Select-Object Name, DisplayName

# Turn off the rule that blocks UDP 443 (use its Name from the list)
Disable-NetFirewallRule -Name '<Name>'

Firewall do macOS

O firewall integrado do macOS só controla conexões de entrada, então não consegue bloquear o QUIC. Se você usa um firewall de saída como Little Snitch ou LuLu, confira as regras dele para o tráfego UDP do Chrome para a porta 443.

Firewalls no nível do roteador

O teste mais rápido: conecte-se ao ponto de acesso do celular e carregue o site. Se o erro sumir, a causa é o seu roteador, o equipamento do provedor ou o firewall do escritório.

Depois procure, na página de administração do roteador (geralmente 192.168.1.1 ou 192.168.0.1), configurações de firewall, "SPI" ou segurança que limitem o UDP, e atualize o firmware.

Correção 5: verificar a VPN

Uma VPN faz túnel de todo o seu tráfego, UDP inclusive, então o QUIC normalmente passa por ela. O problema começa quando o próprio túnel é instável: uma reconexão, uma troca de servidor ou de rota, ou uma VPN que deixa fluxos UDP ociosos expirarem derruba as conexões QUIC abertas.

Desconecte a VPN e recarregue. Se o erro sumir, tente isto:

• Troque o servidor ou o protocolo da VPN — um servidor mais estável ou outro protocolo costuma acabar com as quedas
• VPNs corporativas — muitas redes de empresas bloqueiam o QUIC de propósito para poder inspecionar o HTTPS; siga a configuração da TI e desative o QUIC se os erros persistirem
• Deixe o QUIC desativado enquanto usa a VPN — a Correção 1 funciona com qualquer VPN, porque o Chrome passa a usar TCP

Correção 6: procurar um proxy oculto ou um filtro de tráfego

Uma configuração de proxy não causa esse erro: o Chrome só usa QUIC em conexões diretas, então, com um proxy, toda requisição vai por TCP. O que pode parecer um proxy, porém, é um software de segurança ou de VPN que filtra o tráfego na camada de rede sem nenhuma configuração de proxy.

Se o erro aparece em todas as redes, mas só neste computador, desligue esse tipo de software ("web shield", "proteção de rede", um app de VPN rodando em segundo plano) um de cada vez e recarregue.

Correção 7: atualizar o Chrome para a versão mais recente

O código QUIC do Chrome é atualizado com frequência, e as atualizações corrigem bugs do lado do Chrome na conexão. Atualize o Chrome (ou Edge, Opera, Brave) antes de mudar qualquer outra coisa em um computador que ficou um tempo offline.

1. Open Chrome → click ⋮ (three dots) → Help → About Google Chrome

2. Chrome will automatically check for updates

3. If an update is available, click "Relaunch" to apply

4. After updating, verify your Chrome version:
   chrome://version
   
   Look for the version number 

Problemas de QUIC no servidor (para donos de sites)

Se você é dono de um site e seus visitantes relatam ERR_QUIC_PROTOCOL_ERROR, o problema pode estar no seu servidor. Estas são as causas mais comuns no lado do servidor.

• Configuração HTTP/3 da Cloudflare — se os visitantes relatam o erro e você usa a Cloudflare, confira Speed > Settings > Protocol Optimization > HTTP/3 e teste com ela desligada por um tempo
• O HTTP/3 do seu próprio servidor — o nginx tem HTTP/3 desde a versão 1.25.0 (listen 443 quic reuseport; mais um cabeçalho Alt-Svc); LiteSpeed e Caddy também o suportam. Confirme que o listener UDP da porta 443 está acessível e que a sua pilha QUIC está atualizada. O QUIC sempre usa TLS 1.3: o Verificador de certificado SSL mostra se o seu servidor o oferece
• Balanceadores de carga que não encaminham UDP — balanceadores de aplicação como o AWS ALB só transportam TCP. Se você anuncia h3 no Alt-Svc sem encaminhar a UDP 443, o Chrome marca o QUIC como quebrado para o seu site por 5 minutos, depois tenta de novo, dobrando a espera até 2 dias, e disputa com o TCP a cada vez: remova o cabeçalho ou use um balanceador de camada 4 com suporte a UDP

# Test HTTP/3 only, with no fallback (needs a curl built with HTTP/3)
curl --http3-only -sI https://your-domain.com

# Check something listens on UDP 443 (as root; firewalls are separate)
ss -ulnp 'sport = :443'

# Verify Alt-Svc header (tells browsers QUIC is available)
curl -sI https://your-domain.com | grep -i alt-svc
# Expected: alt-svc: h3=":443"; ma=86400

Você deve manter o QUIC ativado ou desativá-lo?

Desativar o QUIC é uma correção segura, mas, em uma rede saudável, você abre mão de velocidade real. Um jeito prático de decidir:

Mantenha o QUIC ativado em casa, nos dados móveis e em qualquer rede onde o erro não apareça. Os próprios dados do Google mostram Pesquisa mais rápida, menos rebuffering de vídeo e mais throughput com ele, e o QUIC mantém as conexões vivas quando o celular passa do Wi-Fi para os dados móveis.

Desative o QUIC em uma rede ou VPN onde o erro continua voltando. O Chrome passa a usar HTTP/2 (ou HTTP/1.1) sobre TCP, que qualquer rede suporta; a maioria das pessoas não nota a diferença em uma boa banda larga.

Quando o mesmo tipo de falha acontece por HTTP/2 em vez de QUIC, o Chrome mostra o ERR_HTTP2_PROTOCOL_ERROR, que tem causas e correções próprias.