Iniciar Teste GratuitoEntrar

Glossário

O Que É um Proxy HTTP?

Um proxy HTTP é um servidor proxy que entende e encaminha tráfego HTTP (e, via método CONNECT, HTTPS), operando na camada de aplicação e capaz de inspecionar, modificar ou armazenar em cache dados de requisição e resposta para HTTP simples.

Entenda como os proxies HTTP diferem do SOCKS5, o que o HTTP CONNECT faz, e por que os proxies HTTP são o protocolo padrão suportado pela maioria dos scrapers e clientes HTTP.

Explicado

Um proxy HTTP é o tipo mais comum de servidor proxy. Ele entende HTTP na camada de aplicação: quando seu cliente envia uma requisição, o proxy pode ler a URL, os cabeçalhos e (para HTTP simples) o corpo, antes de encaminhar a requisição ao destino. Para HTTPS, o proxy usa o método CONNECT para estabelecer um túnel TCP até o destino, após o qual apenas retransmite bytes criptografados sem ver o conteúdo.

A maioria dos serviços comerciais de proxy, incluindo provedores residenciais, de ISP e de datacenter, expõe endpoints de proxy HTTP porque todo cliente e biblioteca HTTP os suporta nativamente. Definir as variáveis de ambiente `HTTP_PROXY` e `HTTPS_PROXY`, passar `proxies={...}` para o `requests` do Python ou configurar uma flag de inicialização no Playwright, tudo funciona imediatamente com URLs de proxy HTTP como `http://user:pass@gate.shifter.io:10000`.

A diferença entre HTTP e SOCKS5 é principalmente arquitetural. Proxies HTTP operam na camada de aplicação (podem interpretar HTTP); SOCKS5 opera na camada de transporte (apenas encaminha bytes TCP/UDP). Para scraping via HTTPS a diferença é praticamente cosmética, ambos acabam tunelando bytes criptografados, e o suporte a proxy HTTP é mais universal entre as ferramentas.

Como Funciona

Para HTTP puro, seu cliente envia a requisição completa para o proxy (`GET http://example.com/path HTTP/1.1` com URL absoluta), o proxy lê a URL, abre uma conexão com o destino, encaminha a requisição e retransmite a resposta de volta. Para HTTPS, o cliente primeiro envia uma requisição `CONNECT example.com:443` para o proxy, o proxy abre um túnel TCP até o destino e, a partir daí, o cliente e o servidor falam TLS de ponta a ponta através do proxy, que apenas repassa os bytes criptografados.

A autenticação geralmente acontece via o header `Proxy-Authorization` (Basic auth com username:password) ou codificando as credenciais na URL do proxy (`http://user:pass@host:port`). Geo-targeting e parâmetros de sessão em serviços comerciais costumam ser codificados no username (`customer-USER-country-us-session-12345`).

Tipos

Proxy HTTP Direto

O formato usado pelos serviços comerciais de proxy. Fica na frente dos clientes, representando-os perante a internet em geral. Os clientes configuram explicitamente o endereço do proxy.

Proxy HTTP Reverso

Fica na frente dos servidores de backend. Usado para balanceamento de carga, cache e terminação SSL (Nginx, HAProxy, Cloudflare). Os clientes não sabem que o proxy reverso está lá.

Túnel HTTP CONNECT

O mecanismo que os proxies HTTP usam para lidar com HTTPS. O cliente pede ao proxy para abrir um túnel até o destino e então fala TLS através do túnel de ponta a ponta com o destino.

Proxy HTTPS

Um proxy HTTP com o qual você se comunica via TLS. A conexão entre cliente e proxy é criptografada (além do TLS ponta a ponta pelo túnel CONNECT). Menos comum; usado em configurações voltadas para privacidade.

Casos de Uso Comuns

Extração de conteúdo HTTP/HTTPS (o caso de uso dominante)
Acesso à API através de uma saída com IP fixo
Filtragem de egress corporativo interno
Armazenamento em cache de conteúdo estático para economia de banda
Autenticação centralizada de tráfego de saída
Roteamento HTTP por aplicação em ambientes de dev / teste
Perguntas Frequentes

Perguntas frequentes

Perguntas comuns sobre proxy http.

Um proxy HTTP opera na camada de aplicação e pode interpretar requisições HTTP; um proxy SOCKS5 opera na camada de transporte e encaminha TCP/UDP bruto. Para HTTPS a diferença é praticamente cosmética, ambos acabam tunelando bytes criptografados. O SOCKS5 se destaca quando você precisa fazer proxy de protocolos não HTTP (FTP, SMTP, BitTorrent, jogos).

Não, não o conteúdo. Para HTTPS, o proxy abre um túnel TCP via CONNECT e apenas transfere bytes criptografados entre o cliente e o destino. O proxy pode ver o nome do host de destino (via a requisição CONNECT e o SNI do TLS) e o volume de bytes, mas não o corpo da requisição, os cabeçalhos ou a resposta.

`proxies={'http': 'http://user:pass@gate.shifter.io:10000', 'https': 'http://user:pass@gate.shifter.io:10000'}; requests.get(url, proxies=proxies)`. Mesma URL de proxy para http e https — o Python lida com o fluxo CONNECT automaticamente quando o esquema é https.

Sim. Shifter expõe endpoints de proxy residencial e ISP (proxy estático residencial) via HTTP/HTTPS (e SOCKS5). Use as mesmas credenciais e parâmetros de geo-targeting em ambos os protocolos. A maioria dos clientes usa HTTP por causa do suporte mais amplo de clientes.

O mecanismo que os proxies HTTP usam para lidar com HTTPS. O cliente envia `CONNECT host:port HTTP/1.1` para o proxy, o proxy abre um socket TCP até o destino e, a partir desse ponto, o cliente e o destino falam TLS de ponta a ponta através do túnel. O proxy não consegue ver o conteúdo criptografado.

HTTP para o proxy é adequado para a maioria dos usos comerciais. O TLS de ponta a ponta para destinos HTTPS permanece criptografado independentemente disso. HTTPS para o proxy adiciona uma camada extra de criptografia entre você e o proxy, o que protege contra a observação passiva da linha CONNECT e do cabeçalho Proxy-Authorization em redes não confiáveis. Vale a pena em WiFi público; geralmente é excessivo a partir de um servidor.