# Os proxies são tão antigos quanto a Web: uma breve história do que eles realmente fazem
Um engenheiro do CERN e um engenheiro da Intel publicaram o primeiro artigo descrevendo um proxy da World Wide Web em abril de 1994 ([Luotonen e Altis, *World-Wide Web Proxies*](https://www.w3.org/History/1994/WWW/Proxies/), 1994). A própria Web tinha três anos de existência. Os proxies não são uma solução alternativa acoplada à Internet posteriormente. Eles surgiram junto com ela.
Vale a pena conhecer essa história, pois a função deles praticamente não mudou em trinta anos. **Um proxy** é uma máquina que faz uma solicitação em nome de outra parte e retorna o resultado. Tudo o que surgiu desde 1994 — as hierarquias de cache, as redes de entrega 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 na web foi publicado em abril de 1994, pelo CERN, e já tratava a travessia de firewalls e o armazenamento em cache como uma única função (Luotonen e Altis, 1994).
> - O SOCKS completa trinta e quatro anos este ano. Ainda é um protocolo compatível.
> - 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 surgiu, na verdade, o proxy da Web?
Em abril de 1994, Ari Luotonen, do CERN, e Kevin Altis, da Intel, publicaram *World-Wide Web Proxies*, descrevendo um servidor que proporcionava às pessoas em sub-redes fechadas acesso à web por meio de um firewall ([arquivo do W3C](https://www.w3.org/History/1994/WWW/Proxies/), 1994). O artigo foi posteriormente publicado na revista *Computer Networks and ISDN Systems*. O problema que ele resolvia era simples: funcionários protegidos por um firewall corporativo não conseguiam acessar a web externa, e alguém precisava atuar 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 mostra o quão antigo foi esse conceito.
O caso de uso original era o acesso, não a evasão. Uma empresa desejava que seus funcionários acessassem a web sem precisar abrir um buraco no firewall para cada estação de trabalho. O proxy era o buraco, único, supervisionado e registrado.
Aqui está a parte que se perdeu. 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 discutimos 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](https://joinmassive.com/blog/residential-vs-datacenter-proxies-for-ai-agents) ou comece por [o que é um proxy residencial](https://joinmassive.com/blog/what-is-a-residential-proxy).
## Por que a Web inicial precisava de proxies para sobreviver?
A largura de banda era a restrição limitante, e os proxies de cache eram a solução. O Squid, ainda amplamente utilizado como proxy de cache hoje em dia, lançou a versão 1.0.0 em julho de 1996, desenvolvido por Duane Wessels a partir do cache de objetos Harvest, criado na Universidade do Colorado em Boulder ([Projeto Squid Web Cache](https://wiki.squid-cache.org/SquidFaq/AboutSquid), consultado em 31 de agosto de 2026).
Em 1996, uma universidade pagava por seu link por megabyte. Se quatro mil estudantes acessassem a mesma página inicial, a instituição pagaria quatro mil vezes por um único documento. Um proxy de cache reduziu isso a um único acesso. 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 uma falha de acesso em um campus pudesse ser atendida por um vizinho, em vez de pela origem.
Marcos espaçados uniformemente, fora de escala. Fontes: arquivo do W3C (1994), USENIX (1992), IETF RFC 1928 (1996), projeto Squid Web Cache, Projeto Tor, Cloudflare (2026).
Os proxies de cache são a razão pela qual a web da década de 1990 conseguia carregar. Isso não é uma questão de segurança nem de privacidade. É uma questão econômica, e a economia voltou a ser o centro das atenções.
## Que problema o SOCKS resolvia em 1992?
O SOCKS antecede o artigo sobre proxies da web em dois anos. Em setembro de 1992, David Koblas e Michelle R. Koblas apresentaram o *SOCKS* no terceiro Simpósio de Segurança UNIX da USENIX, em Baltimore ([Anais da USENIX](https://www.usenix.org/conference/sec92/socks), 1992), e o protocolo passou a estar disponível ao público a partir de então. A versão 5 foi padronizada como [RFC 1928](https://www.rfc-editor.org/rfc/rfc1928.html) 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 enquadramento da IETF, em 1996, é segurança e conveniência. Não anonimato.
O mesmo padrão se mantém ao longo de toda a linhagem. Cada marco abaixo resolveu um problema operacional específico, e todos esses problemas ainda existem:
| Ano | Marco | O problema que resolveu |
|---|---|---|
| 1992 | SOCKS apresentado na USENIX | Permitir que aplicativos TCP arbitrários, e não apenas navegadores da web, atravessem um firewall |
| 1994 | Artigo do CERN *World-Wide Web Proxies* | Proporcionar aos funcionários em uma sub-rede fechada acesso à web externa |
| 1995 | Início dos trabalhos sobre roteamento em camadas (onion routing) no NRL | Manter a origem do tráfego governamental confidencial não rastreável |
| 1996 | A RFC 1928 padroniza o SOCKS5 | Adicionando autenticação e UDP à travessia do firewall |
| 1996 | Lançamento do Squid 1.0.0 | Reduzindo os custos com largura de banda ao evitar o download repetido do mesmo documento |
| 2002 | Lançamento da rede Tor | Transformando a pesquisa do NRL em uma rede pública de anonimato |
| 2026 | A maior parte do tráfego passa a ser não humano | Determinando de onde devem se originar bilhões de solicitações de máquinas |
O Tor é aquele de que as pessoas se lembram, e ele surgiu uma década depois dos outros. Foi o oitavo ato desta história, não o primeiro.
O SOCKS5 não é uma peça de museu. É um protocolo compatível na rede residencial da Massive em 2026, ao lado do HTTP e do HTTPS. Um protocolo padronizado há trinta anos ainda é um item listado na página de um produto comercial porque resolveu seu problema adequadamente desde o início.
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 produziu os primeiros projetos e protótipos de roteamento em camadas, e seu objetivo era proteger as comunicações governamentais enviadas por redes públicas ([História do Projeto Tor](https://www.torproject.org/about/history/), consultado em 31/08/2026). A tecnologia que mais tarde se tornou sinônimo da dark web foi financiada pela Marinha dos EUA para impedir que o tráfego de inteligência fosse facilmente atribuível.
## Onde os proxies aparecem no dia a dia?
Na maioria dos casos. **Um proxy reverso** é a mesma máquina apontada na direção oposta, trabalhando para o proprietário do site em vez de para o solicitante, e há um deles na frente de quase todos os sites que o(a) senhor(a) acessou hoje. As redes de entrega de conteúdo são proxies de cache distribuídos até a 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 coloca 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, a palavra.
Vale a pena 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 Web precisa de proxies agora mais do que nunca?
Porque a Web deixou de ser predominantemente humana. 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, *Content Independence Day, one year on*](https://blog.cloudflare.com/agentic-internet-bot-report/), 1º de julho de 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 um declínio no tráfego humano de até 40% em menos de um ano ([Cloudflare](https://blog.cloudflare.com/agentic-internet-bot-report/), 1º de julho de 2026).
Fonte: Cloudflare, Dia da Independência do Conteúdo, um ano depois, 1º de julho de 2026.
Coloque essas duas constatações lado a lado e o contorno do problema se torna evidente. As máquinas estão realizando a maior parte das consultas, as pessoas estão passando a maior parte do tempo em mecanismos de busca, e a web aberta está sendo lida mais do que nunca, ao mesmo tempo em que é 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 mais central.
## Como é construída uma rede moderna de dispositivos?
Com base no consentimento. A Massive começou 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 voluntariamente por meio do SDK da Massive. Isso resulta em mais de 1 milhão de dispositivos residenciais verificados em mais de 195 países, auditado pela SOC 2, em conformidade com o GDPR, certificado pela AppEsteem, com uma trilha de auditoria completa desde a origem até a solicitação. A operadora pode indicar de quem foi a conexão que transportou 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 ser capaz de prestar contas pelo tráfego. Uma rede de dispositivos responde à mesma pergunta um nível abaixo: não apenas o que foi solicitado, mas qual conexão o transmitiu e em que termos concordaram em transmiti-lo.
Duas perguntas que vale a pena fazer a qualquer rede de dispositivos: é possível indicar os termos com os quais o proprietário do dispositivo concordou e é possível rastrear uma solicitação até sua origem? Ambas têm respostas satisfatórias desde 1994. A escala mudou, mas a questão da auditoria permaneceu a mesma.
Acima dessa rede, há uma camada de renderização que retorna HTML limpo ou Markdown a partir de qualquer fonte pública, em qualquer local. Trata-se da formulação do problema de 1994: acessar a web pública de onde quer que você realmente precise acessá-la, com os formatos de saída esperados por um pipeline de 2026.
Para uma abordagem mais completa sobre o consentimento em redes de dispositivos, consulte [como funciona o consentimento no compartilhamento de largura de banda](https://joinmassive.com/blog/what-does-consent-look-like-in-bandwidth-sharing).
[Leia a documentação](https://docs.joinmassive.com) [Entre em contato conosco](https://joinmassive.com/contact)
## Perguntas frequentes
### Para que servem, na verdade, os proxies?
Atravessamento de firewall, armazenamento em cache, balanceamento de carga, rescisão de TLS, entrega de conteúdo, gateways de API, saída corporativa, coleta de dados com precisão geográfica e, cada vez mais, geração de tráfego de recuperação de IA. O primeiro uso documentado, no artigo do CERN de abril de 1994, consistiu em proporcionar aos funcionários atrás de um firewall acesso à web externa.
### Qual foi o primeiro proxy da web?
`cern_httpd`, descrito em *World-Wide Web Proxies*, de Ari Luotonen e Kevin Altis, em abril de 1994. Ele proporcionava aos usuários em sub-redes fechadas acesso a HTTP, Gopher, WAIS e FTP através de um firewall, além de armazenar respostas em cache para que solicitações repetidas não atingissem o servidor de origem duas vezes.
### Uma CDN é um proxy?
Sim. Uma rede de entrega de conteúdo (CDN) é um proxy reverso de armazenamento em cache distribuído. Ela desempenha as mesmas duas funções descritas no artigo do CERN de 1994: posiciona-se no meio de uma solicitação e armazena o resultado em cache, com a seta apontando para o proprietário do site, em vez de para o solicitante.
### Por que o tráfego de proxy está crescendo em 2026?
Porque a maior parte do tráfego da web já não é humano. 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 antecipadamente, geralmente em troca de algo concreto, como recursos premium de aplicativos, e pode revogar seu consentimento. A certificação independente (SOC 2, GDPR, AppEsteem) é o que distingue uma política declarada de uma política auditada.
## A mesma função, em escala muito maior
Os proxies resolveram um problema real em 1994 e resolvem uma versão maior desse problema em 2026, pela mesma razão em ambas as ocasiões. Alguém precisa acessar um recurso ao qual não pode acessar diretamente, e algo precisa se interpor no meio e fazer isso bem.
O que mudou foi a escala e quem está solicitando. O servidor do CERN atendia a um único laboratório protegido por um firewall. A função equivalente hoje consiste em originar tráfego de máquinas que agora supera o tráfego humano na internet, proveniente dos locais certos, em dispositivos cujos proprietários concordaram em utilizá-los.
Trinta e dois anos depois, ainda é uma máquina no meio, 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](https://joinmassive.com/blog/the-closing-web-ai-crawler-blocking-pay-per-crawl-and-what-it-means-for-agents).
## Fontes
- Luotonen, A. e Altis, K., *World-Wide Web Proxies*, CERN e Intel, abril de 1994. Acessado em 31 de agosto de 2026. https://www.w3.org/History/1994/WWW/Proxies/
- Koblas, D. e Koblas, M. R., *SOCKS*, Simpósio de Segurança UNIX III, Associação USENIX, Baltimore, setembro de 1992, pp. 77-83. Acessado em 31 de agosto de 2026. https://www.usenix.org/conference/sec92/socks
- IETF, *RFC 1928: Protocolo SOCKS Versão 5*, março de 1996. Acessado em 31 de agosto de 2026. https://www.rfc-editor.org/rfc/rfc1928.html
- Projeto Squid Web Cache, *O que é o Squid?*. Acessado em 31 de agosto de 2026. https://wiki.squid-cache.org/SquidFaq/AboutSquid
- Projeto Tor, *História*. Acessado em 31 de agosto de 2026. https://www.torproject.org/about/history/
- Cloudflare, *Dia da Independência do Conteúdo, um ano depois: construindo o modelo de negócios para a Internet autônoma*, 1º de julho de 2026. Acessado em 31 de agosto de 2026. https://blog.cloudflare.com/agentic-internet-bot-report/