HTTP/2 passa por proxies sem dificuldade porque roda sobre TCP, e TCP é exatamente o que um túnel CONNECT ou uma conexão SOCKS5 transporta. HTTP/3 não: ele roda sobre QUIC, que é baseado em UDP, e proxies HTTP comuns não conseguem tunelar UDP, enquanto a maioria das implementações SOCKS5 também não o faz. A consequência prática é que um cliente com proxy quase sempre fala HTTP/2 (ou HTTP/1.1) com um site, mesmo quando o site suporta HTTP/3 — o navegador faz a queda silenciosamente. Isso é aceitável para a maioria dos trabalhos, mas muda o que o destino vê, e vale a pena entender em vez de descobrir.
Os três protocolos em um minuto
- HTTP/1.1 (1997): baseado em texto, uma requisição por vez por conexão; navegadores abrem várias conexões em paralelo para compensar.
- HTTP/2 (2015): enquadramento binário, muitos streams concorrentes multiplexados em uma conexão TCP, compressão de cabeçalhos (HPACK), server push (agora amplamente abandonado). Mesmo TCP + TLS por baixo que HTTP/1.1.
- HTTP/3 (2022): a mesma semântica do HTTP/2, mas transportado por QUIC, um transporte que roda sobre UDP, incorpora TLS 1.3 no handshake, evita head-of-line blocking do TCP e permite que uma conexão sobreviva a uma mudança de IP (um telefone mudando de Wi-Fi para 4G).
Um navegador descobre que um site oferece HTTP/3 de duas maneiras: um cabeçalho de resposta Alt-Svc: h3=":443" em uma resposta HTTP/2 anterior, ou um registro DNS HTTPS anunciando-o. Uma vez que sabe, ele tenta QUIC na próxima conexão e lembra do resultado.
Como proxies transportam cada um
Proxy HTTP
Para um destino HTTPS, o cliente envia CONNECT host:443, o proxy abre uma conexão TCP para o destino e se transforma em um tubo de bytes burro. O que quer que o cliente e o destino negociem dentro desse tubo — TLS 1.3, depois HTTP/1.1 ou HTTP/2 via ALPN — é invisível para o proxy e funciona inalterado. HTTP/2 através de um proxy HTTP é, portanto, completamente normal.
UDP não tem lugar nesse modelo. CONNECT cria um túnel TCP; não há uma maneira padrão para um proxy HTTP/1.1 simples dizer “encaminhe meus datagramas UDP para este host.” Um navegador configurado com um proxy HTTP simplesmente não tenta QUIC para origens — Chrome e Firefox desabilitam HTTP/3 para conexões com proxy — e usa HTTP/2 através do túnel em vez disso. Sem erro, sem aviso.
Proxy SOCKS5
SOCKS5 define um comando UDP ASSOCIATE para retransmitir datagramas. Em princípio, um proxy SOCKS5 poderia transportar QUIC. Na prática:
- muitos proxies SOCKS5 comerciais implementam apenas
CONNECT(TCP) e rejeitam ou ignoram UDP ASSOCIATE; - o relay UDP via SOCKS5 exige que o proxy tenha uma porta UDP alcançável e que o cliente suporte a dança de associação, o que navegadores não fazem para HTTP/3;
- Chrome e Firefox tratam um proxy SOCKS da mesma forma que um HTTP para este propósito: HTTP/3 não é tentado.
Então, mesmo onde o proxy poderia encaminhar UDP, o navegador não vai pedir. Clientes QUIC de linha de comando e algumas bibliotecas podem ser apontados para um proxy SOCKS5 com capacidade UDP, mas isso é uma configuração especializada, não o padrão. Nossa comparação SOCKS5 vs HTTP cobre a distinção TCP/UDP de forma mais ampla.
O que transportaria HTTP/3: MASQUE e CONNECT-UDP
O grupo de trabalho MASQUE da IETF padronizou CONNECT-UDP (RFC 9298), uma extensão que permite que um proxy HTTP/3 (ou HTTP/2) tunelize payloads UDP — e, por extensão, QUIC para uma origem. É o que o iCloud Private Relay da Apple e alguns proxies de privacidade mais novos usam. O suporte em proxies comerciais de propósito geral e nas configurações de proxy do navegador ainda é incomum; quando um provedor anuncia “suporte a HTTP/3”, vale a pena perguntar se eles querem dizer que o proxy fala HTTP/3 com você ou pode tunelar HTTP/3 para origens — são coisas diferentes.
O que realmente acontece, passo a passo
- Seu navegador com proxy solicita
https://example.com. Ele abreCONNECT example.com:443através do proxy. - Dentro do túnel, ele faz um handshake TLS 1.3, oferecendo ALPN
h2ehttp/1.1. A origem escolheh2. Você está em HTTP/2. - A resposta carrega
Alt-Svc: h3=":443". O navegador anota — e, porque um proxy está configurado, ignora para fins de conexão. - Cada requisição subsequente para essa origem continua sobre HTTP/2 através do túnel.
Desligue o proxy e recarregue: o navegador agora honra Alt-Svc e o mesmo site é servido via HTTP/3. Nada está quebrado em nenhum dos casos; o protocolo simplesmente difere.
Por que isso importa
Desempenho
As vantagens do HTTP/3 — handshakes mais rápidos, sem head-of-line blocking em links com perda, migração de conexão — são perdidas através de um proxy. Para proxies de datacenter em bons links, a diferença é pequena. Para proxies móveis, onde o último salto é um link celular com perda, QUIC ajudaria mais e é exatamente onde você não pode tê-lo. Reserve um pouco mais de latência do que uma conexão HTTP/3 direta mostraria; veja a metodologia em como medir velocidade de proxy.
Fingerprinting e consistência
Este é o sutil. Sistemas anti-bot registram qual protocolo um cliente usou e como eram suas configurações HTTP/2 (veja como sistemas anti-bot funcionam). Um Chrome moderno em conexão direta alcança a maioria dos grandes sites via HTTP/3. O mesmo Chrome através de um proxy chega via HTTP/2. Sozinho, isso não é suspeito — muitos usuários reais estão atrás de proxies corporativos e nunca usam HTTP/3 — mas é mais um ponto de dados, e significa que sua impressão digital HTTP/2 (valores SETTINGS, ordem de cabeçalhos) agora está sempre exposta e deve ser consistente com o navegador alegado. Clientes HTTP que imitam navegadores devem imitar a camada HTTP/2, não apenas a camada TLS, exatamente por essa razão; o artigo sobre fingerprinting TLS explica a pilha.
Ferramentas de scraping
O requests do Python fala apenas HTTP/1.1; httpx pode fazer HTTP/2 com o extra h2; aiohttp é HTTP/1.1. Nenhum faz HTTP/3 através de um proxy. Como um navegador com proxy está em HTTP/2 de qualquer forma, usar HTTP/2 no seu cliente (onde a biblioteca suporta) mantém você mais próximo do que um usuário real com proxy parece. Exemplos em Proxies em Python.
Orientação prática
| Situação | O que você obtém | Ação |
|---|---|---|
| Navegador + proxy HTTP, site HTTP/3 | HTTP/2 via túnel CONNECT | Nada a fazer; isso é normal |
| Navegador + proxy SOCKS5, site HTTP/3 | HTTP/2 (navegador não tenta QUIC via SOCKS) | Nada a fazer |
| Você precisa de HTTP/3 para uma origem através de um proxy | Requer suporte a CONNECT-UDP/MASQUE de ponta a ponta | Pergunte ao provedor especificamente; assuma que não, a menos que confirmado |
| Site se comporta diferente com proxy vs direto | Possivelmente relacionado ao protocolo, mais provavelmente relacionado ao IP | Compare com um navegador real no mesmo proxy antes de culpar o HTTP/3 |
| Imitando cliente para sites protegidos | Deve corresponder às configurações HTTP/2 e ordem de cabeçalhos de um navegador | Use um cliente que imite HTTP/2, não apenas TLS |
| Medindo latência de proxy | Compare coisas semelhantes: HTTP/2 direto vs HTTP/2 com proxy | Não compare HTTP/3 direto contra HTTP/2 com proxy |
Perguntas frequentes
HTTP/2 funciona através de um proxy?
Sim. HTTP/2 roda sobre TCP e TLS, que um túnel CONNECT ou conexão SOCKS5 transporta de forma transparente. O proxy não precisa entender HTTP/2 de forma alguma.
HTTP/3 funciona através de um proxy?
Geralmente não. HTTP/3 usa QUIC sobre UDP; proxies HTTP não conseguem tunelar UDP e navegadores não tentam QUIC quando um proxy está configurado. O navegador cai para HTTP/2 automaticamente. Apenas proxies que suportam CONNECT-UDP (MASQUE) podem transportar HTTP/3 para origens, e isso é raro.
Um proxy SOCKS5 pode transportar QUIC?
O protocolo tem um comando de relay UDP, mas muitos serviços SOCKS5 comerciais não o implementam e navegadores não o usam para HTTP/3. Clientes especializados podem, se o proxy realmente suportar UDP ASSOCIATE.
Usar HTTP/2 em vez de HTTP/3 vai me fazer ser detectado?
Não por si só — muitos usuários legítimos estão atrás de proxies que forçam HTTP/2. Mas significa que sua impressão digital HTTP/2 está sempre visível, então deve ser consistente com o navegador que você alega ser.
HTTP/3 é mais rápido através de um proxy?
Você não obtém HTTP/3 através de um proxy comum, então a pergunta não se aplica; você obtém HTTP/2, que é ligeiramente mais lento em links com perda do que HTTP/3 seria. Em bons links de datacenter, a diferença é insignificante.
O que é Alt-Svc?
Um cabeçalho de resposta HTTP pelo qual um site informa ao cliente que o mesmo recurso está disponível em outro protocolo ou porta — tipicamente h3=":443" para anunciar HTTP/3. Navegadores o honram em conexões diretas e o ignoram para fins de conexão quando um proxy está configurado.