Você abre um vídeo ou um aplicativo web no Chrome, parte da página aparece e então a guia vira uma tela cinza: "Não é possível acessar esse site", logo abaixo a linha "A página … pode estar temporariamente indisponível ou pode ter sido movida permanentemente para um novo endereço da Web." e ERR_QUIC_PROTOCOL_ERROR no final. Recarregar às vezes ajuda, às vezes não, e no seu celular o mesmo site abre normalmente.
Raramente o site está fora do ar. O erro vem do QUIC, a forma mais recente pela qual o Chrome e o Edge se conectam a muitos sites grandes, e de algo no seu computador ou na sua rede que deixa essa conexão começar e depois a quebra. Aqui você vai ver o que é o QUIC, por que o Chrome costuma esconder essas falhas, quais são as causas e as soluções e o que muda com uma VPN ou um proxy.
O que significa ERR_QUIC_PROTOCOL_ERROR?
O QUIC é um protocolo de transporte: o conjunto de regras que leva os dados de uma página entre o servidor do site e o seu navegador. A maior parte do tráfego da web ainda usa TCP para isso. O QUIC faz o mesmo trabalho em cima do UDP, um protocolo mais simples que envia pacotes sem esperar a confirmação de cada um; a verificação, a ordenação e a criptografia ficam por conta do próprio QUIC. A diferença entre os dois está explicada em Diferença entre TCP e UDP.
Na lista de erros de rede do Chromium, o código-fonte por trás do Chrome e do Edge, este é o erro -356, descrito em uma única linha: "There is a QUIC protocol error." (Há um erro de protocolo QUIC.) Ele diz que a conexão QUIC falhou, não quem causou a falha. A tela cinza é a página genérica do Chrome: o Chromium não tem um texto próprio para esse erro, então "temporariamente indisponível" é uma frase padrão, não um diagnóstico.
Como HTTP/3, QUIC e a porta UDP 443 se relacionam?
HTTP é a linguagem que navegadores e servidores usam para pedir e entregar páginas. A versão mais recente, o HTTP/3, é definida na RFC 9114 como HTTP transportado sobre QUIC, e o padrão do QUIC, a RFC 9000, coloca os pacotes QUIC dentro de datagramas UDP (pacotes UDP avulsos). Para um endereço https://, isso normalmente significa a porta UDP 443. Sites seguros sempre usaram a porta 443, mas até o HTTP/3 ela era uma porta TCP, e muitos firewalls e filtros foram construídos em torno disso.
Um site anuncia o HTTP/3 em um cabeçalho de uma resposta comum. Quando verificamos em 6 de outubro de 2026, o example.com respondeu com alt-svc: h3=":443"; ma=86400: o HTTP/3 ("h3") está disponível na porta 443, e o navegador pode guardar essa informação por 86.400 segundos, ou seja, um dia. O YouTube e o Google enviam a mesma oferta com validade de 30 dias.
O padrão também prevê falhas. Quando uma rede bloqueia UDP, a RFC 9114 diz que os navegadores devem voltar às versões do HTTP baseadas em TCP: HTTP/2 ou HTTP/1.1 sobre uma conexão criptografada comum.
Por que o Chrome mostra um erro em vez de voltar para o TCP?
O Chrome segue essa regra, por isso uma rede que bloqueia o QUIC por completo raramente produz esse erro. O erro aparece quando o QUIC funciona no início e falha depois:
- O site oferece HTTP/3. A oferta chega no cabeçalho
alt-svcou, em alguns sites, em um registro DNS, e o Chrome a guarda. - O Chrome tenta o QUIC. Na visita seguinte, ele abre uma conexão QUIC para a porta UDP 443 e mantém uma conexão TCP comum de reserva.
- O QUIC nunca se conecta. Se os pacotes UDP forem bloqueados por completo, o TCP assume, e o Chrome marca o QUIC como quebrado para aquele site por alguns minutos, por mais tempo depois de falhas repetidas. Você não percebe nada.
- O QUIC se conecta e cai antes de a resposta chegar. O Chrome envia a requisição de novo pelo TCP e, se der certo, marca o QUIC como quebrado para o site.
- O QUIC cai depois que a resposta começou. Quando parte da resposta já chegou ao navegador, o código de conexão do Chromium trata a requisição como uma que "can not be retried" (não pode ser repetida). O Chrome mostra
ERR_QUIC_PROTOCOL_ERROR.
Ou seja, o erro aponta para uma rede em que o QUIC funciona pela metade: os pacotes passam por tempo suficiente para começar uma página, depois algo os descarta, altera ou corta. Um bloqueio limpo só teria custado o HTTP/3, não a página.
O que causa ERR_QUIC_PROTOCOL_ERROR?
| Causa | Sinal típico | Primeira verificação |
|---|---|---|
| Antivírus ou suíte de segurança com proteção web | Muitos sites falham em um computador, em qualquer rede | Pause a proteção web durante uma recarga |
| Firewall de empresa, escola ou Wi-Fi público | Só naquela rede | Pergunte a quem administra a rede |
| Aplicativo de VPN | Só com a VPN conectada | Desconecte ou escolha outro servidor |
| Roteador ou firewall que esquece conexões UDP ociosas | Uma guia aberta por um tempo falha no clique seguinte | Recarregue; atualize o firmware do roteador |
| O servidor HTTP/3 do site ou a CDN dele | Um site, em todas as redes e dispositivos | Espere ou avise o dono do site |
| Um proxy configurado no navegador | Não é este erro: o Chrome não usa QUIC por meio de um proxy | Veja a seção sobre proxies abaixo |
Em um computador de casa, os programas de segurança são os primeiros suspeitos. A central de ajuda da ESET diz que a proteção web dela pode não funcionar corretamente com o QUIC ativado, e a Trend Micro e a WatchGuard documentam o bloqueio da porta UDP 443 para que os navegadores passem para o HTTP/2. Um filtro que bloqueia o QUIC de forma limpa é inofensivo; um que deixa passar os primeiros pacotes e descarta o resto produz esse erro.
Roteadores e firewalls também acompanham cada conversa que passa por eles. A RFC 9308, o guia da IETF para operar o QUIC, observa que eles esquecem uma conversa UDP ociosa muito antes de uma conversa TCP, e alguns firewalls passam a recusar pacotes do servidor que não esperam mais. É por isso que uma guia parada por um tempo pode falhar no clique seguinte.
Como resolver ERR_QUIC_PROTOCOL_ERROR?
Siga estes passos em ordem e recarregue a página depois de cada um:
- Recarregue uma vez. Uma queda isolada, como uma oscilação rápida do Wi-Fi, muitas vezes não se repete.
- Tente outra rede. Abra o site pelos dados móveis do celular ou por um hotspot. Se funcionar lá, o site está bem.
- Desconecte a VPN. Se a página carregar, tente outro servidor ou outro protocolo de conexão no aplicativo da VPN.
- Pause a proteção web do antivírus para um teste. Desligue o recurso que verifica o tráfego web ou HTTPS, recarregue e depois ligue de novo. Se a pausa ajudou, atualize o programa e procure HTTP/3 ou QUIC nas páginas de ajuda dele; alguns fabricantes recomendam o próximo passo no lugar disso.
- Desative o QUIC no navegador. Isso elimina o erro em qualquer caso, porque o navegador deixa de usar o QUIC. Os passos vêm a seguir.
- Em um computador do trabalho ou da escola, fale com a equipe de TI. O firewall e as configurações do navegador pertencem à organização, e a solução também.
Como desativar o QUIC no Chrome e no Edge?
O QUIC vem ativado por padrão. A chave fica na página de recursos experimentais do navegador, onde os nomes das opções e os valores dos menus continuam em inglês mesmo com o Chrome em português. No Chrome para Windows, Mac, Linux ou Android:
- Digite
chrome://flags/#enable-quicna barra de endereços e pressione Enter. A página vai direto para Experimental QUIC protocol. - Mude o menu ao lado de Default para Disabled.
- Clique em Reiniciar na parte de baixo da página. O Chrome fecha e abre de novo.
No Edge, digite edge://flags/#enable-quic, mude Experimental QUIC protocol para Disabled e clique em Restart (Reiniciar).
O que você perde é o HTTP/3. As páginas carregam por HTTP/2 ou HTTP/1.1 sobre TCP, e em uma boa conexão você raramente vai notar. Para desfazer a mudança, volte a opção para Default. Trate isso como uma solução provisória: se um programa de segurança causou o erro, a correção de verdade é atualizar ou reconfigurar esse programa.
As organizações desligam o QUIC de forma centralizada com uma política chamada QuicAllowed ("Allow QUIC protocol"), que tem o mesmo nome no Chrome e no Edge (documentação da Microsoft). Digite chrome://policy na barra de endereços para ver as políticas do seu computador; se QuicAllowed estiver na lista, é a sua organização que decide se o QUIC é usado.
A culpa é do site?
Às vezes. Se um site falha em todas as redes e dispositivos enquanto outros sites funcionam, a causa provável é o servidor HTTP/3 dele ou a rede de distribuição de conteúdo (CDN, uma rede de servidores que entrega as páginas de um site a partir de um local perto de você). Só o dono do site pode corrigir isso; enquanto isso, desligar o QUIC contorna o problema.
Se o site é seu, confirme com visitantes em outras redes e depois desligue o HTTP/3 para um teste; na Cloudflare, a chave fica em Speed > Settings > Protocol Optimization > HTTP/3. Se você usa o seu próprio balanceador de carga, a RFC 9308 alerta que balanceadores que distribuem o tráfego por endereço e porta podem quebrar o QUIC quando o roteador de um visitante muda a porta.
VPNs e proxies causam esse erro?
Um aplicativo de VPN leva todo o tráfego do seu dispositivo, incluindo UDP, dentro de um túnel criptografado até o servidor dele. Embrulhar cada pacote em outro deixa menos espaço por pacote, e a RFC 9000 diz que o QUIC não deve ser usado em um caminho que não consiga transportar pacotes UDP de pelo menos 1.200 bytes. Um servidor de VPN que filtra UDP, ou um túnel com pouco espaço, quebra o QUIC; troque o servidor ou o protocolo no aplicativo.
Um proxy configurado no navegador funciona de outro jeito. Com um proxy HTTP ou HTTPS, o Chrome pede ao proxy um túnel até o site com uma requisição CONNECT, que passa pelo TCP. Um comentário no código de conexão do Chromium diz que o QUIC não pode ser falado com proxies que não sejam proxies QUIC, então o Chrome carrega o site por HTTP/2 ou HTTP/1.1 e esse erro não acontece.
O SOCKS5 é o caso especial, porque o próprio protocolo consegue transportar UDP além de TCP; Proxy SOCKS5: o que é e como funciona explica como.
O Chrome não usa essa parte. A documentação de proxy do Chrome diz que o SOCKS5 nele lida só com requisições TCP e "cannot be used to relay UDP traffic" (não pode ser usado para retransmitir tráfego UDP). Os nossos Proxies SOCKS5 retransmitem UDP para aplicativos que enviam UDP por conta própria, mas no Chrome levam as páginas pelo TCP como qualquer outro proxy.
Isso também explica o que você vê no trabalho. Quando você confere com os Proxies residenciais como uma loja aparece em outro país, as ferramentas para desenvolvedores do navegador (DevTools) mostram h2 onde uma visita direta mostra h3. Isso é esperado, não um defeito. Um proxy também não é a solução para esse erro: desligar o QUIC tem o mesmo efeito sem passar o seu tráfego por mais ninguém.
Avançado: veja se um site usa HTTP/3
Esta parte é para quem quer ver com os próprios olhos. O DevTools mostra o protocolo de cada requisição:
- Abra o site, pressione F12 ou Ctrl+Shift+I (Cmd+Option+I no Mac) e selecione o painel Rede.
- Clique com o botão direito no cabeçalho da tabela de requisições e selecione Protocolo.
- Recarregue a página.
h3significa HTTP/3 sobre QUIC;h2, HTTP/2 sobre TCP.
Se o site com falha mostra h3 em uma rede onde ele funciona, o QUIC está envolvido, e desligá-lo vai eliminar o erro. Para ver a oferta de HTTP/3 de um site sem navegador, peça os cabeçalhos dele com o curl, que já vem no Windows 10, no Windows 11 e no macOS; no Windows PowerShell, digite curl.exe.
curl -sI https://example.comO nosso teste em 6 de outubro de 2026 (curl 8.21.0, Windows 11) retornou, entre outros cabeçalhos, esta linha:
alt-svc: h3=":443"; ma=86400Se não houver h3 na resposta, geralmente o site não oferece HTTP/3 por esse caminho.
Erros relacionados
| Código | O que falhou | Roda sobre |
|---|---|---|
ERR_QUIC_PROTOCOL_ERROR (-356) | Uma conexão QUIC caiu depois que a resposta começou | UDP |
ERR_QUIC_HANDSHAKE_FAILED (-358) | Uma conexão QUIC nunca concluiu a configuração; o Chrome pode reenviar a requisição | UDP |
ERR_HTTP2_PROTOCOL_ERROR (-337) | Uma conexão HTTP/2 falhou | TCP |
ERR_SSL_PROTOCOL_ERROR (-107) | O handshake criptografado falhou | TCP |
ERR_CONNECTION_RESET (-101) | Uma conexão estabelecida foi cortada | TCP |
Se, ao desligar o QUIC, o erro virar ERR_SSL_PROTOCOL_ERROR, o mesmo filtro agora está quebrando a conexão TCP, e Como resolver err_ssl_protocol_error no Chrome e Edge continua a partir daí.
Onde você pode encontrar esse erro
- YouTube e serviços do Google, que oferecem HTTP/3 a todos os visitantes e pedem aos navegadores que guardem isso por 30 dias.
- Sites atrás da Cloudflare, que oferece HTTP/3 em todos os planos.
- Redes de escritórios e escolas cujos firewalls inspecionam o tráfego web.
- Computadores com uma suíte de segurança para internet que filtra páginas web.
Erros comuns
- Limpar cookies e cache. Eles guardam páginas e logins, não a conexão; a queda acontece abaixo deles.
- Reinstalar o Chrome. Uma instalação nova volta a usar o QUIC por padrão.
- Deixar a proteção web desligada de vez em vez de atualizar o programa ou desligar o QUIC.
- Culpar o site depois de uma única falha. Teste outra rede primeiro.
- Mudar as configurações de um computador do trabalho sem perguntar. O firewall que quebra o QUIC pertence à organização.
Guia de decisão
| Sua situação | O que fazer |
|---|---|
| Falha no Wi-Fi, funciona nos dados móveis | Verifique o roteador e qualquer filtro dessa rede |
| Só falha com a VPN ligada | Troque o servidor ou o protocolo no aplicativo da VPN |
| Começou com um antivírus novo ou atualizado | Pause a proteção web para um teste e depois atualize ou reconfigure o programa |
| Um site, em todas as redes | Avise o dono do site; enquanto isso, desligue o QUIC |
| Computador do trabalho ou da escola | Fale com a equipe de TI |
| Você precisa da página agora | Mude Experimental QUIC protocol para Disabled |
Perguntas frequentes
É seguro desativar o QUIC?
Sim. As páginas continuam criptografadas, usando TLS sobre TCP em vez de QUIC, como a maior parte da web funcionava antes do HTTP/3. Você pode voltar a opção para Default a qualquer momento.
Desativar o QUIC deixa a navegação mais lenta?
Em alguns sites, um pouco. O QUIC abre conexões mais rápido e lida melhor com a perda de pacotes, então a diferença aparece principalmente em conexões móveis ou Wi-Fi fracas.
Por que acontece mais no YouTube e nos sites do Google?
O Chrome usa QUIC com eles com mais frequência do que com a maioria dos sites, porque eles oferecem HTTP/3 a todos os visitantes. Um filtro que lida mal com o QUIC aparece ali primeiro.
Como resolver o erro no Android?
Primeiro alterne entre Wi-Fi e dados móveis e desligue qualquer aplicativo de VPN. Se o erro continuar, abra chrome://flags/#enable-quic no Chrome para Android e mude Experimental QUIC protocol para Disabled.
O Firefox mostra ERR_QUIC_PROTOCOL_ERROR?
Não. O código pertence ao Chromium, o motor por trás do Chrome, do Edge, do Brave e do Opera. O Firefox tem o próprio suporte a HTTP/3 e os próprios nomes de erro.
Um proxy ou uma VPN resolve o erro?
Uma VPN é mais vezes a causa do que a solução. Um proxy no navegador elimina o erro só como efeito colateral, porque o Chrome não usa QUIC por meio de proxies comuns; desligar a opção do QUIC faz o mesmo.
Em resumo
ERR_QUIC_PROTOCOL_ERROR significa que uma conexão QUIC, o transporte UDP por trás do HTTP/3, caiu depois que o site já tinha começado a responder, então o Chrome não conseguiu voltar para o TCP discretamente. Teste outra rede, a VPN e a proteção web do seu antivírus para descobrir o que está interferindo, e mude Experimental QUIC protocol para Disabled se precisar da página agora. Se você usa um navegador com proxies no trabalho, espere ver HTTP/2 ali; dá para comparar tipos de proxy e protocolos na nossa página de proxies.
