ERR_HTTP2_PROTOCOL_ERROR: o que é e como resolver

O que é o ERR_HTTP2_PROTOCOL_ERROR?

O ERR_HTTP2_PROTOCOL_ERROR é um erro do Chrome e do Edge que significa que o fluxo HTTP/2 que carrega a página falhou: o servidor o reiniciou antes de terminar ou enviou cabeçalhos que o navegador rejeita. No Chromium, é o erro de rede -337: “There is an HTTP/2 protocol error” (net_error_list.h). O Chrome não tem uma página de erro própria para ele, então você vê a genérica: “Não é possível acessar esse site. A página da Web em … pode estar temporariamente indisponível ou pode ter sido movida permanentemente para um novo endereço da Web”, com ERR_HTTP2_PROTOCOL_ERROR embaixo. O Edge mostra o mesmo código na própria tela de erro.

O HTTP/2 é a versão mais rápida do HTTP que a maioria dos sites HTTPS usa hoje. Cada requisição viaja em seu próprio fluxo dentro de uma única conexão, e qualquer um dos lados pode cancelar um fluxo com um reinício. O Chrome reporta qualquer reinício vindo do servidor como erro de protocolo, seja qual for o motivo do servidor, e também cancela um fluxo por conta própria quando os cabeçalhos quebram as regras do HTTP/2 (um cabeçalho Transfer-Encoding, letras maiúsculas no nome de um cabeçalho, um status ausente).

Desenvolvedores costumam ver o erro no console do DevTools como net::ERR_HTTP2_PROTOCOL_ERROR 200 (OK). Essa combinação é uma pista forte: os cabeçalhos eram válidos e o servidor respondeu 200, mas o fluxo falhou enquanto o corpo chegava.

O que o HTTP/2 considera malformado

O padrão HTTP/2 (RFC 9113) lista os erros que tornam uma resposta malformada. São os problemas por trás da maioria dos erros reais, e é assim que cada um chega ao navegador:

O que causa o ERR_HTTP2_PROTOCOL_ERROR?

A maioria dos casos vem do lado do servidor, mas algumas coisas no seu próprio computador podem danificar uma resposta no caminho:

• No servidor: uma resposta que o servidor ou o proxy não consegue terminar (um proxy que fica sem espaço em disco ou não consegue gravar seus arquivos temporários, uma aplicação que trava durante o streaming, um timeout), valores de Content-Length errados que fazem o proxy à frente desistir, cabeçalhos proibidos ou inválidos e suporte a HTTP/2 com bugs em um servidor ou configuração de CDN mais antigos.
• No seu lado: antivírus ou firewall que inspeciona o HTTPS e reescreve o tráfego, extensões do navegador que modificam requisições ou respostas, uma requisição que o servidor trata mal (por exemplo, cookies grandes demais) e, ocasionalmente, uma versão desatualizada do Chrome.

Correção 1: recarregue sem cache e teste uma janela anônima

Pressione Ctrl + Shift + R (Mac: Cmd + Shift + R) para recarregar sem o cache. Uma resposta que foi cortada uma vez pode chegar inteira na próxima tentativa.

Depois, abra a página em uma janela anônima (Ctrl + Shift + N, no Mac Cmd + Shift + N). A janela anônima não tem cookies nem o cache do seu perfil normal, e as extensões ficam desativadas por padrão. Se a página carregar ali, a Correção 2 ou a Correção 3 vai resolver o problema na sua janela normal.

Correção 2: limpe os cookies e os arquivos em cache desse site

Limpar os cookies e os arquivos em cache do site muda a requisição que o Chrome envia (menos cookies, nenhuma cópia em cache para revalidar), o que pode evitar um bug do servidor. Clique em Ver informações do site, à esquerda da barra de endereço → Cookies e dados de sites → Gerenciar dados de sites no dispositivo → exclua e recarregue. Para uma limpeza mais ampla, pressione Ctrl + Shift + Delete e limpe Imagens e arquivos em cache dos Últimos sete dias.

Correção 3: pause a verificação HTTPS do antivírus e as extensões

Software de segurança que descriptografa e inspeciona o HTTPS fica no meio de toda conexão HTTP/2. Se o tratamento de HTTP/2 dele tem bugs ou está desatualizado, ele pode quebrar fluxos ou repassar cabeçalhos que o Chrome rejeita. Desative só o recurso de verificação HTTPS (Avast/AVG: Web Shield → Enable HTTPS scanning; ESET: SSL/TLS protocol filtering; Kaspersky: Scan encrypted connections; nas versões em português, algo como “verificação de HTTPS”) e recarregue. Se isso resolver, atualize o antivírus e adicione uma exclusão para o site.

Depois, desative todas as extensões em chrome://extensions, recarregue e reative uma por vez. Bloqueadores de anúncios, ferramentas de privacidade e qualquer coisa que edite cabeçalhos são os suspeitos de sempre.

Correção 4: atualize o Chrome e teste outros navegadores

Abra chrome://settings/help para instalar qualquer atualização pendente e reinicie o navegador. Depois abra a mesma página no Firefox ou no Safari, e em outro dispositivo ou rede. Se falhar em todos, o site está quebrado e só o dono pode corrigir (a verificação HTTPS do antivírus afeta todos os navegadores de um computador, então um segundo dispositivo é o teste de verdade). Se só o Chrome ou o Edge falham, o site provavelmente envia um cabeçalho que o Chrome rejeita; vale repetir as correções 2 e 3 mesmo assim.

Correção 5: teste a página sem HTTP/2

O Chrome pode ser iniciado com HTTP/2 (e HTTP/3) desligados, o que mostra se o HTTP/2 está envolvido. Inicie um segundo Chrome, separado, a partir de um terminal; a pasta de perfil extra o transforma em uma nova instância mesmo com o seu Chrome normal aberto:

# Windows (Command Prompt)
"C:\Program Files\Google\Chrome\Application\chrome.exe" --user-data-dir="%TEMP%\h2test" --disable-http2 --disable-quic

# macOS (Terminal)
open -na "Google Chrome" --args --user-data-dir=/tmp/h2test --disable-http2 --disable-quic

Se a página carregar nessa janela, as respostas HTTP/2 dela são o problema e o dono precisa corrigi-las. Se agora ela falhar com ERR_CONTENT_LENGTH_MISMATCH ou ERR_INCOMPLETE_CHUNKED_ENCODING, o servidor está cortando a resposta seja qual for o protocolo. Feche essa janela quando terminar; o seu Chrome normal não é afetado.

Para donos de sites: como corrigir erros de protocolo HTTP/2

Se visitantes em redes e navegadores diferentes relatam o erro, o problema está na sua infraestrutura. Estas três verificações encontram quase todos os casos.

1. Reproduza o erro com o curl

# HTTP/2: watch the end of the output
curl -sv --http2 https://example.com/broken-page -o /dev/null
# A stream the server gave up on ends with something like:
# HTTP/2 stream 1 was not closed cleanly: INTERNAL_ERROR (err 2)
# (curl 8.19+: HTTP/2 stream 1 reset by server (error 0x2 INTERNAL_ERROR);
#  "reset by curl" means curl rejected the response itself)

# Same URL over HTTP/1.1 for comparison
curl -sv --http1.1 https://example.com/broken-page -o /dev/null

Se o HTTP/1.1 funciona e o HTTP/2 falha, o HTTP/2 está envolvido. “Reset by server” aponta para o servidor ou um proxy desistindo no meio da resposta. O curl não verifica exatamente o que o Chrome verifica (ele rejeita divergências de Content-Length e cabeçalhos de conexão que o Chrome deixa passar), então encare como uma pista forte, não como prova. O verificador de cabeçalhos HTTP lista os cabeçalhos que a sua aplicação define, vistos de fora da sua rede.

2. Procure respostas cortadas no meio do stream

A causa mais comum no servidor é uma resposta que começa (status 200, cabeçalhos enviados) e depois não consegue ser terminada. O nginx armazena em buffer as respostas maiores da sua aplicação em arquivos temporários; se o disco estiver cheio ou o nginx não conseguir gravar na pasta temporária, ele reinicia o fluxo e o navegador reporta um erro de protocolo. Verifique:

df -h                                   # is any disk full?
sudo grep -E "No space left|Permission denied" /var/log/nginx/error.log | tail
ls -ld /var/lib/nginx/proxy /var/lib/nginx/fastcgi   # Debian/Ubuntu packages
ls -ld /var/cache/nginx/proxy_temp /var/cache/nginx/fastcgi_temp   # nginx.org packages
# the temp folders must be writable by the nginx worker user

Verifique também o próprio app: um processo PHP ou Node que trava, estoura o tempo limite ou atinge um limite de memória enquanto envia uma página grande ou um download produz o mesmo resultado. Os logs do app perto do horário do erro normalmente mostram isso.

3. Corrija o Content-Length e os cabeçalhos proibidos

• Content-Length: deixe o servidor calculá-lo. Não o defina à mão no código da aplicação se um plugin, um middleware ou o servidor web também comprime ou modifica a saída, porque aí o tamanho declarado deixa de bater com os bytes enviados. Um tamanho definido no código PHP enquanto um plugin ou uma configuração do PHP também comprime a saída é uma das formas como isso acontece em sites WordPress.
• Transfer-Encoding: nunca o envie em uma resposta HTTP/2; o Chrome reinicia o fluxo assim que vê um. A RFC 9113 também proíbe Connection, Keep-Alive, Proxy-Connection e Upgrade. O Chrome os ignora, mas o curl e outros clientes estritos os rejeitam, e o nginx remove a maioria deles das respostas via proxy para você.
• Valores de cabeçalho: garanta que nenhum cabeçalho contenha quebra de linha ou caractere de controle. Isso costuma vir de dados do usuário colocados em um cabeçalho, como um nome de arquivo em Content-Disposition.
• CDN à frente: se você usa Cloudflare ou outra CDN, teste a origem diretamente (com curl --resolve ou uma entrada no hosts) para saber se o erro vem da origem ou da CDN.

ERR_HTTP2_PROTOCOL_ERROR vs. erros parecidos

Guias detalhados: ERR_QUIC_PROTOCOL_ERROR, ERR_SSL_PROTOCOL_ERROR, ERR_CONNECTION_CLOSED e ERR_EMPTY_RESPONSE. Para verificar o certificado e a configuração HTTPS de um site de fora, use o Verificador de SSL.