Um painel de conexões de central telefônica vintage com tomadas de latão e cabos revestidos de tecido sobre um fundo creme — a máquina original que ficava no meio de uma conexão
Todas as publicações

Os proxies são tão antigos quanto a Web: uma breve história do que eles realmente fazem

Ryan Turner
Ryan Turner · Head of Innovation
Abrir markdown

Um engenheiro do CERN e um engenheiro da Intel publicaram o primeiro artigo que descrevia um proxy da World Wide Web em abril de 1994 (Luotonen e Altis, Proxies da World Wide Web, 1994). A própria web tinha três anos. Os proxies não são uma solução alternativa acrescentada à internet posteriormente. Eles surgiram junto com ela.

Vale a pena conhecer essa história, pois a profissão praticamente não mudou nos últimos trinta anos. Um procurador é uma máquina que realiza uma solicitação em nome de terceiros e retorna o resultado. Tudo o que aconteceu desde 1994 — as hierarquias de cache, as redes de distribuição de conteúdo, os gateways corporativos, as redes de dispositivos que alimentam os sistemas de IA atualmente — é essa única ideia aplicada em escala cada vez maior.

Principais conclusões
  • O primeiro artigo sobre proxy da web foi publicado em abril de 1994, pelo CERN, e já tratava a travessia de firewalls e o armazenamento em cache como uma única tarefa (Luotonen e Altis, 1994).
  • O SOCKS completa 34 anos este ano. Continua sendo um protocolo com suporte.
  • A Cloudflare informou, em 1º de julho de 2026, que, em junho de 2026, mais de 50% do tráfego da internet era de origem não humana.
  • Proxies reversos, CDNs, balanceadores de carga e gateways de API são o mesmo mecanismo com nomes diferentes.

De onde, na verdade, surgiu o proxy da Web?

Em abril de 1994, Ari Luotonen, do CERN, e Kevin Altis, da Intel, publicaram Proxies da World Wide Web, descrevendo um servidor que proporcionava às pessoas em sub-redes fechadas acesso à internet por meio de um firewall (Arquivo do W3C, 1994). O artigo foi posteriormente publicado em Redes de computadores e sistemas ISDN. O problema que ele resolveu era bastante comum: os funcionários que estavam atrás de um firewall corporativo não conseguiam acessar a internet externa, e era necessário que alguém atuasse como intermediário.

Essa é a ideia por trás disso, e ela não mudou. Um proxy é uma máquina que faz uma solicitação em seu nome. A implementação do CERN, cern_httpd, era compatível com HTTP, Gopher, WAIS e FTP, o que dá uma ideia de como isso foi pioneiro.

O caso de uso inicial era o acesso, e não a evasão. Uma empresa desejava que seus funcionários pudessem acessar a internet sem precisar abrir um buraco no firewall para cada estação de trabalho. O proxy era o buraco — único, supervisionado e registrado.

Aqui está o ponto que costuma passar despercebido. O artigo de 1994 trata o armazenamento em cache e o controle de acesso como um mesmo conjunto de recursos, fornecido pelo mesmo equipamento. Todos os argumentos que ainda estamos discutindo em 2026 — sobre quem pode acessar o quê, com que frequência e se o servidor de origem deve arcar com os custos — já estavam evidentes em um artigo escrito antes mesmo de a maior parte da web existir.

Para conhecer as diferenças práticas entre os tipos de rede, consulte Comparação entre proxies residenciais e de data center, ou comece com O que é um proxy residencial.

Por que a Web dos primórdios precisava de proxies para sobreviver?

A largura de banda era o gargalo, e os proxies de cache foram a solução. O Squid, que ainda hoje é amplamente utilizado como proxy de cache, lançou a versão 1.0.0 em julho de 1996, tendo sido desenvolvido por Duane Wessels a partir do cache de objetos Harvest, criado na Universidade do Colorado em Boulder (Projeto Squid Web Cache, consultado em 31 de agosto de 2026).

Em 1996, uma universidade pagava por sua conexão à Internet por megabyte. Se quatro mil estudantes acessassem a mesma página inicial, a instituição pagaria quatro mil vezes pelo mesmo documento. Um proxy de cache reduziu esse número a uma única solicitação. Os caches do Harvest podiam ser organizados em hierarquias e se comunicar entre si por meio do Protocolo de Cache da Internet, de modo que, caso ocorresse uma falha de acesso em um campus, o conteúdo pudesse ser fornecido por um campus vizinho, em vez de pela origem.

1992: SOCKS presented at USENIX. 1994: the CERN World-Wide Web Proxies paper. 1995: onion routing work begins at the US Naval Research Laboratory. 1996: RFC 1928 standardises SOCKS5. 1996: Squid 1.0.0 released. 2002: the Tor network launches. 2026: the majority of internet traffic is non-human. Milestones are evenly spaced and not drawn to scale. 199219941995 199619962002 2026 SOCKS atUSENIX CERN proxypaper Onion routingat NRL RFC 1928SOCKS5 Squid 1.0.0released Tor networklaunches Majority oftraffic is bots Thirty-four years of standing in the middle Selected milestones in proxy and intermediary infrastructure
Marcos históricos espaçados uniformemente, sem escala. Fontes: arquivo do W3C (1994), USENIX (1992), RFC 1928 da IETF (1996), projeto Squid Web Cache, Projeto Tor, Cloudflare (2026).

Os proxies de cache foram o que permitiu que a internet da década de 1990 funcionasse. Isso não é uma questão de segurança nem de privacidade. Trata-se de uma questão econômica, e os aspectos econômicos voltaram a ganhar relevância.

Que problema o SOCKS estava resolvendo em 1992?

O SOCKS antecede o artigo sobre proxy da web em dois anos. Em setembro de 1992, David Koblas e Michelle R. Koblas apresentaram MEIAS no terceiro Simpósio de Segurança do UNIX da USENIX, em Baltimore (Anais da USENIX, 1992), e, a partir daí, o protocolo passou a estar disponível ao público. A versão 5 foi padronizada como RFC 1928 em março de 1996, que descreve uma estrutura para que aplicativos cliente-servidor “utilizem de forma conveniente e segura os serviços de um firewall de rede”.

Leia essa frase novamente. O próprio enfoque da IETF, em 1996, é segurança e conveniência. Não anonimato.

Esse mesmo padrão se mantém ao longo de toda a linhagem. Cada marco a seguir resolveu um problema operacional específico, e todos esses problemas ainda existem:

Year Milestone The problem it solved
1992 SOCKS presented at USENIX Letting arbitrary TCP applications, not just web browsers, cross a firewall
1994 CERN World-Wide Web Proxies paper Giving staff on a closed subnet access to the outside web
1995 Onion routing work begins at NRL Keeping the origin of sensitive government traffic unattributable
1996 RFC 1928 standardises SOCKS5 Adding authentication and UDP to firewall traversal
1996 Squid 1.0.0 released Cutting the bandwidth bill by not fetching the same document twice
2002 The Tor network launches Turning the NRL research into a public anonymity network
2026 Most traffic becomes non-human Deciding where billions of machine requests should originate

O Tor é aquele de que as pessoas se lembram, e ele surgiu uma década depois dos outros. Foi o oitavo ato dessa história, não o primeiro.

O roteamento em camadas (onion routing), antecessor do Tor, surgiu na mesma época e em um ambiente institucional semelhante. Em 1995, David Goldschlag, Michael Reed e Paul Syverson, do Laboratório de Pesquisa Naval dos EUA, começaram a questionar se seria possível estabelecer conexões na internet sem revelar quem estava se comunicando com quem. Esse trabalho resultou nos primeiros projetos e protótipos de roteamento em camadas, e seu objetivo era proteger as comunicações governamentais enviadas por meio de redes públicas (Histórico do Projeto Tor, consultado em 31 de agosto de 2026). A tecnologia que mais tarde se tornou sinônimo da dark web foi financiada pela Marinha dos Estados Unidos para impedir que o tráfego de informações de inteligência pudesse ser facilmente atribuído.

Em que situações os proxies aparecem no dia a dia?

A maioria deles. Um proxy reverso é a mesma máquina voltada para o outro lado, trabalhando para o proprietário do site em vez de para o solicitante, e há uma delas na frente de quase todos os sites que o senhor acessou hoje. As redes de entrega de conteúdo são proxies de cache distribuídos na borda. Os balanceadores de carga são proxies. A rescisão TLS na frente de um servidor de aplicativos é um proxy. Gateways de saída corporativos, filtros de conteúdo em escolas e bibliotecas, gateways de API, malhas de serviços: todos eles são proxies, fazendo exatamente o que a máquina do CERN fazia em 1994.

O vocabulário é a parte interessante. Quando o intermediário trabalha para o proprietário do site, o setor chama isso de infraestrutura e o inclui no diagrama de arquitetura. Quando trabalha para a parte que faz a solicitação, o setor chama isso de proxy. A mesma máquina, a mesma posição no caminho da solicitação. Apenas a direção da seta mudou e, com ela, o termo.

É importante saber disso, nem que seja apenas para que o diagrama de arquitetura e a lista de fornecedores deixem de parecer duas tecnologias diferentes.

Por que a internet precisa de proxies agora mais do que nunca?

Porque a internet deixou de ser composta principalmente por seres humanos. Em um relatório publicado em 1º de julho de 2026, a Cloudflare constatou que, em junho de 2026, mais de 50% do tráfego na internet era não humano e que 52% das solicitações de rastreadores se destinavam ao treinamento de IA, um aumento em relação aos 22% registrados na primavera de 2025 (Cloudflare, Um ano do Dia da Independência do Conteúdo, 1º de julho de 2026).

Crawler requests made for AI training Share of all crawler requests seen by Cloudflare 22% 52% Spring 2025 June 2026
Fonte: Cloudflare, “Content Independence Day: um ano depois”, 1º de julho de 2026.

No mesmo relatório de 2026, a Cloudflare também constatou que, para cada hora passada online em busca de informações, apenas quinze minutos são dedicados à web aberta, e que algumas das categorias mais rastreadas registraram uma queda no tráfego humano de até 40% em menos de um ano (Cloudflare, 1º de julho de 2026).

Where an hour of information-seeking goes 15 min on the open web Open web Everywhere else
Fonte: Cloudflare, “Content Independence Day: um ano depois”, 1º de julho de 2026.

Ao colocar essas duas constatações lado a lado, o contorno do problema se torna evidente. As máquinas estão realizando a maior parte da busca, as pessoas estão dedicando a maior parte do tempo dentro dos mecanismos de respostas, e a web aberta está sendo lida mais do que nunca, embora seja visitada menos do que nunca. Cada uma dessas leituras feitas por máquinas precisa ter origem em algum lugar. Essa é uma questão indireta e, atualmente, é a questão central.

Como é construída uma rede de dispositivos moderna?

Sobre o consentimento. O Massive surgiu como um produto de monetização de aplicativos, no qual as pessoas trocavam uma parcela de capacidade computacional ociosa por recursos premium, e cada endereço IP é cadastrado por meio do SDK do Massive. Isso resulta em mais de 1 milhão de dispositivos residenciais verificados em mais de 195 países, com auditoria SOC 2, em conformidade com o GDPR, certificação AppEsteem e uma trilha de auditoria completa, da origem até a solicitação. A operadora pode identificar de quem é a conexão que transmitiu uma determinada solicitação.

Essa não é uma obrigação nova. O proxy do CERN registrava todas as solicitações que passavam por ele, pois um administrador de sistema precisava poder prestar contas pelo tráfego. Uma rede de dispositivos responde à mesma pergunta em um nível inferior: não apenas o que foi solicitado, mas qual conexão o transportou e em que termos se concordou em transportá-lo.

Acima dessa rede, há uma camada de renderização que retorna HTML ou Markdown limpo a partir de qualquer fonte pública, em qualquer local. Trata-se da formulação do problema de 1994: acessar a web pública a partir de qualquer lugar de onde você realmente precise acessá-la, com os formatos de saída que um pipeline de 2026 espera.

Para uma abordagem mais completa sobre o consentimento em redes de dispositivos, consulte Como se manifesta o consentimento no compartilhamento de largura de banda.

Está desenvolvendo algo que depende da web pública?

O mesmo trabalho, em uma escala muito maior

Os proxies resolveram um problema concreto em 1994 e resolverão uma versão mais ampla desse problema em 2026, pela mesma razão em ambas as ocasiões. Alguém precisa acessar um recurso ao qual não tem acesso direto, e algo precisa atuar como intermediário e desempenhar bem essa função.

O que mudou foi a escala e quem está solicitando. O equipamento do CERN atendia a um único laboratório protegido por um firewall. Hoje, a função equivalente consiste em gerar tráfego de máquinas que já supera o tráfego humano na internet, proveniente dos locais certos, em dispositivos cujos proprietários concordaram em carregá-los.

Trinta e dois anos depois, ainda se trata de uma máquina que atua como intermediária, fazendo uma solicitação em nome de alguém e mantendo um registro disso.

Para saber mais sobre como a economia está mudando, consulte Bloqueio de rastreadores de IA, pagamento por rastreamento e o que isso significa para os agentes.

Fontes

Perguntas frequentes

Para que servem, na verdade, os proxies?+

Atravessamento de firewall, armazenamento em cache, balanceamento de carga, terminação de TLS, entrega de conteúdo, gateways de API, tráfego de saída corporativo, coleta de dados com precisão geográfica e, cada vez mais, tráfego de recuperação originado por IA. O primeiro uso documentado, no artigo do CERN de abril de 1994, consistiu em proporcionar aos funcionários protegidos por um firewall acesso à internet externa.

Qual foi o primeiro proxy da web?+

cern_httpd, descrito em Proxies da World Wide Web por Ari Luotonen e Kevin Altis, em abril de 1994. O sistema permitia que usuários em sub-redes fechadas acessassem os protocolos HTTP, Gopher, WAIS e FTP através de um firewall e armazenava as respostas em cache para que solicitações repetidas não fossem encaminhadas duas vezes ao servidor de origem.

Uma CDN é um proxy?+

Sim. Uma rede de entrega de conteúdo é um proxy reverso de cache distribuído. Ela desempenha as mesmas duas funções descritas no artigo do CERN de 1994: atua como intermediária em uma solicitação e armazena o resultado em cache, com a seta apontando para o proprietário do site, e não para o solicitante.

Por que o tráfego de proxy está crescendo em 2026?+

Isso porque a maior parte do tráfego na web já não é gerado por seres humanos. A Cloudflare informou, em 1º de julho de 2026, que, em junho de 2026, o tráfego não humano havia ultrapassado 50% e que 52% das solicitações de rastreadores eram destinadas ao treinamento de IA, um aumento em relação aos 22% registrados na primavera de 2025. O treinamento de modelos, a recuperação de dados e os fluxos de trabalho de agentes ocorrem em escala de máquina.

Como funciona o consentimento em uma rede residencial?+

O proprietário do dispositivo concorda desde o início, geralmente em troca de algo concreto, como recursos premium do aplicativo, e pode cancelar sua adesão. A certificação independente (SOC 2, GDPR, AppEsteem) é o que diferencia uma política declarada de uma política auditada.