# 代理服务器与万维网同龄：关于其实际功能的简史
1994年4月，一位来自欧洲核子研究组织（CERN）的工程师和一位来自英特尔（Intel）的工程师发表了首篇描述万维网代理的论文（[Luotonen 和 Altis，《万维网代理》](https://www.w3.org/History/1994/WWW/Proxies/)， 1994)。当时万维网本身才诞生三年。代理并非事后强行附加到互联网上的权宜之计，而是与互联网同步诞生的。
这段历史值得了解，因为三十年来，代理的功能几乎未曾改变。 **代理服务器**是一种代表另一方发起请求并将结果返回的设备。自1994年以来的一切——缓存层次结构、内容分发网络、企业网关，以及当今为人工智能系统提供数据的设备网络——都是这一核心理念在越来越大的规模上得到应用的结果。
> **关键要点**
> - 第一篇关于Web代理的论文于1994年4月由欧洲核子研究组织（CERN）发布，其中已将防火墙穿透和缓存视为同一项任务（Luotonen和Altis，1994）。
> - SOCKS协议今年迎来三十四周年。它至今仍是受支持的协议。
> - Cloudflare 于 2026 年 7 月 1 日报告称，截至 2026 年 6 月，超过 50% 的互联网流量来自非人类。
> - 反向代理、CDN、负载均衡器和 API 网关本质上是同一机制，只是名称不同。
## Web代理究竟从何而来？
1994年4月，欧洲核子研究组织（CERN）的阿里·卢奥托宁（Ari Luotonen）和英特尔的凯文·阿尔蒂斯（Kevin Altis）发表了《万维网代理》（*World-Wide Web Proxies*）一文，描述了一种服务器，它能让处于封闭子网中的人员通过防火墙访问万维网（[W3C档案](https://www.w3.org/History/1994/WWW/Proxies/)，1994）。 该论文后来发表在《计算机网络与ISDN系统》上。它解决的问题很简单：位于企业防火墙后方的员工无法访问外部网络，因此必须有人充当中间人。
这就是代理的核心理念，至今未变。代理是一台代表用户发起请求的机器。欧洲核子研究中心的实现方案`cern_httpd`支持HTTP、Gopher、WAIS和FTP协议，这足以说明该技术问世之早。
最初的使用场景是访问，而非规避。企业希望员工能够访问互联网，却无需为每台工作站都在防火墙上开一个“洞”。代理服务器就是那个“洞”——唯一、受监管且被记录在案的。
以下是常被忽略的部分。 1994 年的论文将缓存和访问控制视为同一套功能，由同一台设备提供。我们直到 2026 年仍在争论的每一个问题——谁可以获取什么内容、获取频率如何，以及源服务器是否应承担成本——在网络尚未真正形成之际，就已经在这篇论文中清晰可见了。
关于网络类型的实际差异，请参阅[家庭代理与数据中心代理的对比](https://joinmassive.com/blog/residential-vs-datacenter-proxies-for-ai-agents)，或从[什么是家庭代理](https://joinmassive.com/blog/what-is-a-residential-proxy)开始了解。
## 早期万维网为何需要代理才能生存？
带宽是当时的瓶颈，而缓存代理正是解决之道。Squid 作为缓存代理至今仍被广泛使用，其 1.0.0 版于 1996 年 7 月发布，由杜安·韦塞尔斯（Duane Wessels）基于科罗拉多大学博尔德分校开发的 Harvest 对象缓存分支而来（[Squid Web Cache 项目](https://wiki.squid-cache.org/SquidFaq/AboutSquid)，检索于2026-08-31)。
1996年，大学按兆字节付费购买网络连接。如果四千名学生每人都访问同一个主页，该机构就需为同一份文档支付四千倍的费用。 缓存代理将这一请求整合为一次。Harvest缓存可以按层次结构排列，并通过互联网缓存协议（ICP）相互通信，因此某个校园的缓存未命中请求可以由邻近节点而非源服务器提供服务。
里程碑间距均匀，比例非实际。 来源：W3C档案（1994）、USENIX（1992）、IETF RFC 1928（1996）、Squid Web Cache项目、Tor项目、Cloudflare（2026）。
正因为有缓存代理，1990年代的万维网才得以加载。这既不是安全问题，也不是隐私问题。这是一个经济问题，而如今这一经济因素又重新浮现。
## 1992年SOCKS解决的是什么问题？
SOCKS 比 Web 代理论文早了两年。1992 年 9 月，David Koblas 和 Michelle R. Koblas 在巴尔的摩举行的第三届 USENIX UNIX 安全研讨会上发表了 *SOCKS* 论文（[USENIX 会议论文集](https://www.usenix.org/conference/sec92/socks)，1992）， 该协议自此向公众开放。1996年3月，第5版作为[RFC 1928](https://www.rfc-editor.org/rfc/rfc1928.html)被标准化，其中描述了一个供客户端-服务器应用程序“便捷且安全地使用网络防火墙服务”的框架。
请再读一遍这句话。IETF 自己在 1996 年的表述中强调的是安全性和便利性，而非匿名性。
这一模式贯穿了整个发展历程。下文列出的每个里程碑都解决了一个具体的运行问题，而这些问题至今仍然存在：
| 年份 | 里程碑 | 解决的问题 |
|---|---|---|
| 1992 | SOCKS 在 USENIX 会议上发表 | 允许任意 TCP 应用程序（而不仅仅是网页浏览器）穿越防火墙 |
| 1994 | CERN《全球万维网代理》论文 | 使封闭子网内的员工能够访问外部万维网 |
| 1995 | 美国海军研究实验室（NRL）启动洋葱路由研究 | 确保敏感政府流量的来源无法被追溯 |
| 1996 | RFC 1928 将 SOCKS5 标准化 | 在防火墙穿越中加入身份验证和 UDP 支持 |
| 1996 | Squid 1.0.0 发布 | 通过避免重复获取同一文档来降低带宽费用 |
| 2002 | Tor 网络上线 | 将 NRL 的研究成果转化为公共匿名网络 |
| 2026 | 大部分流量由非人类生成 | 决定数十亿条机器请求应源自何处 |
人们记忆最深的莫过于 Tor，而它比其他技术晚了十年才出现。 它是这个故事中的第八幕，而非第一幕。
SOCKS5 并非博物馆里的陈列品。在 2026 年的 Massive 家庭网络中，它与 HTTP 和 HTTPS 一同作为受支持的协议存在。 三十年前标准化的一项协议至今仍出现在商业产品页面上，因为它从一开始就妥善解决了相关问题。
洋葱路由（Onion routing）作为 Tor 的前身，诞生于同一时代，同样源自一个机构环境。1995年，大卫·戈德施拉格（David Goldschlag）、 迈克尔·里德和保罗·西弗森在美国海军研究实验室开始探索：是否可以在不透露通信双方身份的情况下建立互联网连接。这项研究产生了首批洋葱路由设计和原型，其目的是保护通过公共网络发送的政府通信（[Tor 项目历史](https://www.torproject.org/about/history/)，检索于2026年8月31日）。这项后来成为“暗网”代名词的技术，最初是由美国海军资助开发的，旨在防止情报通信被轻易追踪到来源。
## 代理服务器在日常生活中有哪些应用？
几乎无处不在。**反向代理**就是同一台机器反向工作，为网站所有者而非请求者服务，而你今天访问的几乎每个网站前面都有一台这样的代理。内容分发网络是分布在边缘的缓存代理。负载均衡器也是代理。 应用服务器前端的 TLS 终止服务器也是代理。企业出站网关、学校和图书馆的内容过滤器、API 网关、服务网格：它们全都是代理，其作用与 1994 年 CERN 那台服务器如出一辙。
有趣之处在于术语的差异。当中介为网站所有者服务时，业界称之为“基础设施”，并将其绘制在架构图中；当它为发起请求的一方服务时，业界则称之为“代理”。 同一台机器，在请求路径中的位置也相同。只是箭头的方向变了，随之而变的，是名称。
这一点值得了解，哪怕只是为了让架构图和供应商清单不再听起来像是两种不同的技术。
## 为什么如今网络比以往任何时候都更需要代理？
因为网络已经不再主要由人类构成。 在 2026 年 7 月 1 日发布的一份报告中，Cloudflare 发现截至 2026 年 6 月，互联网流量中超过 50% 来自非人类，且 52% 的爬虫请求用于 AI 训练，这一比例较 2025 年春季的 22% 显著上升 ([Cloudflare，《内容独立日，一年之后》](https://blog.cloudflare.com/agentic-internet-bot-report/)，2026年7月1日)。
来源：Cloudflare，《内容独立日一周年》，2026年7月1日。
在同一份2026年的报告中，Cloudflare还发现，用户每在线搜索信息一小时，其中仅有十五分钟是在开放网络上度过的；此外，一些被爬虫访问最频繁的类别中，人类流量在不到一年的时间内下降了多达40%（[Cloudflare](https://blog.cloudflare.com/agentic-internet-bot-report/)，2026年7月1日）。
来源：Cloudflare，《内容独立日》一周年，2026年7月1日.
将这两项发现并列来看，问题的全貌便显而易见。机器承担了大部分数据检索工作，人们将大部分时间耗费在答案引擎中，而开放网络的被阅读量虽创下历史新高，访问量却跌至历史最低点。每一次机器读取都必须源自某处。这是一个代理问题， 而这如今已成为核心问题。
## 现代设备网络是如何构建的？
基于用户同意。Massive最初是一款应用变现产品，用户通过出让部分闲置计算资源来换取高级功能，每个IP地址都通过Massive SDK进行主动授权。 这形成了覆盖 195 多个国家/地区的 100 多万台经过验证的家庭设备，通过 SOC 2 审计、符合 GDPR 要求、获得 AppEsteem 认证，并具备从源头到请求的完整审计轨迹。运营商可以查明某个请求是由谁的连接发出的。
这并非新规。欧洲核子研究组织（CERN）的代理服务器会记录所有经其传输的请求，因为系统管理员必须能够对流量负责。 设备网络则在更底层解答了同样的问题：不仅要了解请求的内容，还要明确是哪一连接承载了该请求，以及承载方基于何种条款同意进行传输。
针对任何设备网络，有两个值得探讨的问题：能否列出设备所有者同意的条款？能否将请求追溯至其源头？自1994年以来，这两个问题都已有明确的答案。规模发生了变化，但审计的核心问题始终如一。
在这个网络之上，还存在一个渲染层，它能从任何公开来源（无论位于何处）返回干净的 HTML 或 Markdown 格式内容。这就是 1994 年的问题陈述：无论你实际需要从何处访问，都能连接到公共网络，且输出格式符合 2026 年管道的预期。
关于设备网络中同意机制的更全面探讨，请参阅 [带宽共享中的同意机制](https://joinmassive.com/blog/what-does-consent-look-like-in-bandwidth-sharing)。
[阅读文档](https://docs.joinmassive.com) [联系我们](https://joinmassive.com/contact)
## 常见问题
### 代理服务器实际上用于什么？
防火墙穿透、缓存、负载均衡、TLS 终止、内容分发、API 网关、企业出站流量、地理位置精准的数据采集，以及日益增多的 AI 检索流量发起。 1994年4月欧洲核子研究组织（CERN）的一篇论文中记载了代理的首次应用，其目的是让位于防火墙后方的员工能够访问外部网络。
### 第一个 Web 代理是什么？
`cern_httpd`，由 Ari Luotonen 和 Kevin Altis 于 1994 年 4 月在《World-Wide Web Proxies》一文中描述。 它使封闭子网中的用户能够通过防火墙访问HTTP、Gopher、WAIS和FTP，并缓存响应结果，从而避免重复请求两次访问源服务器。
### CDN是代理吗？
是的。内容分发网络（CDN）是一种分布式缓存反向代理。它执行着1994年CERN论文中描述的两项相同功能：位于请求链路的中间位置并缓存结果，只不过箭头指向的是网站所有者而非请求者。
### 为什么2026年的代理流量在增长？
因为大多数网络流量已不再来自人类。Cloudflare 于 2026 年 7 月 1 日报告称，截至 2026 年 6 月，非人类流量已超过 50%，且 52% 的爬虫请求用于 AI 训练，这一比例较 2025 年春季的 22% 显著上升。 模型训练、数据检索和代理工作流均以机器级规模进行数据获取。
### 在家庭网络中，同意机制如何运作？
设备所有者通常会事先表示同意——通常是为了换取具体回报，例如应用程序的付费功能——并且可以随时撤回同意。独立认证（SOC 2、GDPR、AppEsteem）是区分“声明性政策”与“经审计政策”的关键。
## 相同任务，更大规模
代理服务器在1994年解决了一个实际问题，到了2026年又解决了该问题的更大版本——两次的解决原因都是一样的。有人需要访问无法直接访问的资源，因此必须有某种东西作为中间桥梁并高效地完成这一任务。
变化之处在于规模以及需求方。当年欧洲核子研究组织（CERN）的服务器仅服务于一个位于防火墙后方的实验室。 如今的等效任务则是从合适的地点，通过设备所有者同意承载的设备，发起机器流量——这种流量在互联网上已超过了人类流量。
三十二年过去了，中间仍是一台机器，代表某人发出请求，并记录下这一过程。
关于经济模式如何转变的更多内容，请参阅 [AI 爬虫封锁、按爬取次数付费及其对代理的影响](https://joinmassive.com/blog/the-closing-web-ai-crawler-blocking-pay-per-crawl-and-what-it-means-for-agents)。
## 参考文献
- Luotonen, A. 和 Altis, K., 《万维网代理（World-Wide Web Proxies）》，欧洲核子研究组织（CERN）和英特尔（Intel），1994年4月。检索于2026年8月31日。https://www.w3.org/History/1994/WWW/Proxies/
- Koblas, D. 和 Koblas, M. R.，《SOCKS》，第三届 UNIX 安全研讨会，USENIX 协会，巴尔的摩，1992 年 9 月，第 77-83 页。检索于 2026-08-31。https://www.usenix.org/conference/sec92/socks
- IETF，《RFC 1928：SOCKS 协议第 5 版》，1996 年 3 月。检索于 2026-08-31。https://www.rfc-editor.org/rfc/rfc1928.html
- Squid Web Cache 项目，《什么是 Squid？》。检索于 2026 年 8 月 31 日。https://wiki.squid-cache.org/SquidFaq/AboutSquid
- Tor 项目，*历史*。检索于 2026-08-31。https://www.torproject.org/about/history/
- Cloudflare，*内容独立日一周年：构建自主互联网的商业模式*，2026年7月1日。 检索于 2026-08-31。https://blog.cloudflare.com/agentic-internet-bot-report/