# Proxies Are as Old as the Web: A Short History of What They Actually Do
An engineer at CERN and an engineer at Intel published the first paper describing a World Wide Web proxy in April 1994 ([Luotonen and Altis, *World-Wide Web Proxies*](https://www.w3.org/History/1994/WWW/Proxies/), 1994). The web itself was three years old. Proxies are not a workaround bolted onto the internet after the fact. They arrived with it.
That history is worth knowing, because the job has barely changed in thirty years. **A proxy** is a machine that makes a request on another party's behalf and passes the result back. Everything since 1994, the caching hierarchies, the content delivery networks, the corporate gateways, the device networks feeding AI systems today, is that one idea applied at bigger and bigger scale.
> **Key Takeaways**
> - The first web proxy paper shipped in April 1994, from CERN, and it already treated firewall traversal and caching as one job (Luotonen and Altis, 1994).
> - SOCKS turns thirty-four this year. It is still a supported protocol.
> - Cloudflare reported on 1 July 2026 that as of June 2026, more than 50% of internet traffic is non-human.
> - Reverse proxies, CDNs, load balancers and API gateways are the same mechanism wearing different names.
## Where Did the Web Proxy Actually Come From?
In April 1994, Ari Luotonen of CERN and Kevin Altis of Intel published *World-Wide Web Proxies*, describing a server that gave people on closed subnets access to the web through a firewall ([W3C archive](https://www.w3.org/History/1994/WWW/Proxies/), 1994). The paper was later carried in *Computer Networks and ISDN Systems*. The problem it solved was mundane: employees behind a corporate firewall could not reach the outside web, and somebody had to stand in the middle.
That is the whole idea, and it has not changed. A proxy is a machine that makes a request on your behalf. The CERN implementation, `cern_httpd`, could speak HTTP, Gopher, WAIS and FTP, which tells you how early this was.
The founding use case was access, not evasion. A company wanted its people to reach the web without punching a hole in the firewall for every workstation. The proxy was the hole, singular, supervised, and logged.
Here is the part that gets lost. The 1994 paper treats caching and access control as the same feature set, delivered by the same box. Every argument we are still having in 2026, about who may fetch what, how often, and whether the origin server should bear the cost, was already legible in a paper written before most of the web existed.
For the practical differences between network types, see [residential and datacenter proxies compared](https://joinmassive.com/blog/residential-vs-datacenter-proxies-for-ai-agents), or start with [what a residential proxy is](https://joinmassive.com/blog/what-is-a-residential-proxy).
## Why Did the Early Web Need Proxies to Survive?
Bandwidth was the binding constraint, and caching proxies were the answer. Squid, still in wide use as a caching proxy today, released version 1.0.0 in July 1996, forked by Duane Wessels from the Harvest object cache built at the University of Colorado Boulder ([Squid Web Cache project](https://wiki.squid-cache.org/SquidFaq/AboutSquid), retrieved 2026-08-31).
A university in 1996 paid for its link by the megabyte. If four thousand students each pulled the same homepage, the institution paid four thousand times for one document. A caching proxy made that one fetch. Harvest caches could be arranged in hierarchies and talk to each other over the Internet Cache Protocol, so a miss at one campus could be served by a neighbour rather than by the origin.
Milestones evenly spaced, not to scale. Sources: W3C archive (1994), USENIX (1992), IETF RFC 1928 (1996), Squid Web Cache project, Tor Project, Cloudflare (2026).
Caching proxies are why the 1990s web loaded at all. That is not a security story or a privacy story. It is an economics story, and the economics have come back around.
## What Problem Was SOCKS Solving in 1992?
SOCKS predates the web proxy paper by two years. In September 1992, David Koblas and Michelle R. Koblas presented *SOCKS* at the third USENIX UNIX Security Symposium in Baltimore ([USENIX proceedings](https://www.usenix.org/conference/sec92/socks), 1992), and the protocol became publicly available from there. Version 5 was standardised as [RFC 1928](https://www.rfc-editor.org/rfc/rfc1928.html) in March 1996, which describes a framework for client-server applications to "conveniently and securely use the services of a network firewall."
Read that sentence again. The IETF's own framing, in 1996, is security and convenience. Not anonymity.
The same pattern holds across the whole lineage. Each milestone below solved a specific operational problem, and every one of those problems still exists:
| 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 |
Tor is the one people remember, and it arrived a decade after the others. It was the eighth act in this story, not the first.
SOCKS5 is not a museum piece. It is a supported protocol on Massive's residential network in 2026, alongside HTTP and HTTPS. A protocol standardised thirty years ago is still a line item on a commercial product page because it solved its problem properly the first time.
Onion routing, the ancestor of Tor, came out of the same era and a similarly institutional place. In 1995, David Goldschlag, Michael Reed and Paul Syverson at the US Naval Research Laboratory began asking whether internet connections could be made without revealing who was talking to whom. That work produced the first onion routing designs and prototypes, and its purpose was protecting government communications sent over public networks ([Tor Project history](https://www.torproject.org/about/history/), retrieved 2026-08-31). The technology that later became shorthand for the dark web was funded by the US Navy to keep intelligence traffic from being trivially attributable.
## Where Do Proxies Show Up in a Normal Day?
Most of them. **A reverse proxy** is the same machine pointed the other way, working for the site owner rather than the requester, and one sits in front of nearly every website you loaded today. Content delivery networks are caching proxies distributed to the edge. Load balancers are proxies. The TLS termination in front of an application server is a proxy. Corporate egress gateways, school and library content filters, API gateways, service meshes: proxies, all of them, doing exactly what the CERN box did in 1994.
The vocabulary is the interesting part. When the intermediary works for the site owner, the industry calls it infrastructure and puts it on the architecture diagram. When it works for the party making the request, the industry calls it a proxy. Same machine, same position in the request path. Only the direction of the arrow changed, and with it the word.
Worth knowing, if only so the architecture diagram and the vendor list stop sounding like two different technologies.
## Why Does the Web Need Proxies More Now Than Ever?
Because the web stopped being mostly human. In a report published on 1 July 2026, Cloudflare found that as of June 2026 more than 50% of traffic on the internet is non-human, and that 52% of crawler requests are for AI training, up from 22% in spring 2025 ([Cloudflare, *Content Independence Day, one year on*](https://blog.cloudflare.com/agentic-internet-bot-report/), 1 July 2026).
Source: Cloudflare, Content Independence Day, one year on, 1 July 2026.
In the same 2026 report, Cloudflare also found that for every hour spent online searching for information, only fifteen minutes is spent on the open web, and that some of the most heavily crawled categories have seen human traffic decline as much as 40% in less than one year ([Cloudflare](https://blog.cloudflare.com/agentic-internet-bot-report/), 1 July 2026).
Source: Cloudflare, Content Independence Day, one year on, 1 July 2026.
Put those two findings next to each other and the shape of the problem appears. Machines are doing most of the fetching, people are spending most of their time inside answer engines, and the open web is being read more than ever while being visited less than ever. Every one of those machine reads has to originate somewhere. That is a proxy question, and it is now the central one.
## How Is a Modern Device Network Built?
On consent. Massive began as an app monetization product, where people traded a slice of idle compute for premium features, and every IP is opted in through the Massive SDK. That produces 1M+ verified residential devices across 195+ countries, SOC 2 audited, GDPR compliant, AppEsteem certified, with a full audit trail from source to request. The operator can say whose connection carried a given request.
That is not a new obligation. The CERN proxy logged every request through it, because a system administrator had to be able to answer for the traffic. A device network answers the same question one layer down: not just what was requested, but whose connection carried it, and on what terms they agreed to carry it.
Two questions worth asking any device network: can you name the terms the device owner agreed to, and can you trace a request back to its source? Both have had good answers since 1994. The scale changed, the audit question did not.
On top of that network sits a rendering layer that returns clean HTML or markdown from any public source, in any location. It is the 1994 problem statement, reaching the public web from wherever you actually need to reach it, with the output formats a 2026 pipeline expects.
For a fuller treatment of consent in device networks, see [what consent looks like in bandwidth sharing](https://joinmassive.com/blog/what-does-consent-look-like-in-bandwidth-sharing).
[Read the docs](https://docs.joinmassive.com) [Talk to us](https://joinmassive.com/contact)
## Frequently Asked Questions
### What are proxies actually used for?
Firewall traversal, caching, load balancing, TLS termination, content delivery, API gateways, corporate egress, geo-accurate data collection and, increasingly, originating AI retrieval traffic. The first documented use, in the April 1994 CERN paper, was giving staff behind a firewall access to the outside web.
### What was the first web proxy?
`cern_httpd`, described in *World-Wide Web Proxies* by Ari Luotonen and Kevin Altis in April 1994. It gave users on closed subnets access to HTTP, Gopher, WAIS and FTP through a firewall, and it cached responses so that repeat requests did not hit the origin server twice.
### Is a CDN a proxy?
Yes. A content delivery network is a distributed caching reverse proxy. It performs the same two functions the 1994 CERN paper described, standing in the middle of a request and caching the result, with the arrow pointing toward the site owner rather than the requester.
### Why is proxy traffic growing in 2026?
Because most web traffic is no longer human. Cloudflare reported on 1 July 2026 that, as of June 2026, non-human traffic had passed 50% and that 52% of crawler requests were for AI training, up from 22% in spring 2025. Model training, retrieval and agent workflows all fetch at machine scale.
### How does consent work on a residential network?
The device owner agrees up front, usually in exchange for something concrete such as premium app features, and can withdraw. Independent certification (SOC 2, GDPR, AppEsteem) is what separates a stated policy from an audited one.
## Same Job, Much Bigger Scale
Proxies solved a real problem in 1994 and they solve a bigger version of it in 2026, for the same reason both times. Somebody needs to reach a resource they cannot reach directly, and something has to stand in the middle and do it well.
What changed is scale and who is asking. The CERN box served one laboratory behind one firewall. The equivalent job today is originating machine traffic that now outweighs human traffic on the internet, from the right places, on devices whose owners agreed to carry them.
Thirty-two years on, it is still a machine in the middle, making a request on someone's behalf, and keeping a record of it.
For more on how the economics are shifting, see [AI crawler blocking, pay-per-crawl, and what it means for agents](https://joinmassive.com/blog/the-closing-web-ai-crawler-blocking-pay-per-crawl-and-what-it-means-for-agents).
## Sources
- Luotonen, A. and Altis, K., *World-Wide Web Proxies*, CERN and Intel, April 1994. Retrieved 2026-08-31. https://www.w3.org/History/1994/WWW/Proxies/
- Koblas, D. and Koblas, M. R., *SOCKS*, UNIX Security Symposium III, USENIX Association, Baltimore, September 1992, pp. 77-83. Retrieved 2026-08-31. https://www.usenix.org/conference/sec92/socks
- IETF, *RFC 1928: SOCKS Protocol Version 5*, March 1996. Retrieved 2026-08-31. https://www.rfc-editor.org/rfc/rfc1928.html
- Squid Web Cache project, *What is Squid?*. Retrieved 2026-08-31. https://wiki.squid-cache.org/SquidFaq/AboutSquid
- Tor Project, *History*. Retrieved 2026-08-31. https://www.torproject.org/about/history/
- Cloudflare, *Content Independence Day, one year on: building the business model for the agentic Internet*, 1 July 2026. Retrieved 2026-08-31. https://blog.cloudflare.com/agentic-internet-bot-report/