# Прокси-серверы так же стары, как и сам Интернет: краткая история их реального назначения
В апреле 1994 года инженер из ЦЕРН и инженер из Intel опубликовали первую статью, в которой описывался прокси-сервер для Всемирной паутины ([Luotonen и Altis, *World-Wide Web Proxies*](https://www.w3.org/History/1994/WWW/Proxies/), 1994). Самому Интернету на тот момент было три года. Прокси-серверы — это не какое-то временное решение, привнесённое в Интернет задним числом. Они появились одновременно с ним.
Эту историю стоит знать, поскольку за тридцать лет их функции практически не изменились. **Прокси-сервер** — это устройство, которое отправляет запрос от имени другого участника и передаёт результат обратно. Всё, что появилось с 1994 года — иерархии кэширования, сети доставки контента, корпоративные шлюзы, сети устройств, питающие сегодня системы искусственного интеллекта, — представляет собой применение этой единственной идеи в всё более широких масштабах.
> **Ключевые выводы**
> - Первая статья о веб-прокси была опубликована в апреле 1994 года в CERN, и в ней обход брандмауэров и кэширование уже рассматривались как единая задача (Луотонен и Альтис, 1994).
> - В этом году протоколу SOCKS исполняется тридцать четыре года. Он по-прежнему поддерживается.
> - 1 июля 2026 года компания Cloudflare сообщила, что по состоянию на июнь 2026 года более 50 % интернет-трафика генерируется не людьми.
> - Обратные прокси, CDN, балансировщики нагрузки и шлюзы API — это один и тот же механизм, имеющий разные названия.
## Откуда же на самом деле появился веб-прокси?
В апреле 1994 года Ари Луотонен из ЦЕРН и Кевин Альтис из Intel опубликовали статью *World-Wide Web Proxies*», в которой описывался сервер, предоставлявший пользователям в закрытых подсетях доступ к Всемирной паутине через брандмауэр ([архив W3C](https://www.w3.org/History/1994/WWW/Proxies/), 1994). Позже эта статья была напечатана в журнале *Computer Networks and ISDN Systems*. Проблема, которую она решала, была вполне прозаичной: сотрудники, находящиеся за корпоративным брандмауэром, не могли выйти во внешний Интернет, и кто-то должен был выступать посредником.
В этом и заключается вся суть, и она не изменилась. Прокси — это устройство, которое отправляет запрос от вашего имени. Реализация CERN, `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 года; этот проект был создан Дуэйном Весселсом на основе объектного кэша Harvest, разработанного в Университете Колорадо в Боулдере ([Проект Squid Web Cache](https://wiki.squid-cache.org/SquidFaq/AboutSquid), по состоянию на 31.08.2026).
В 1996 году университеты оплачивали своё подключение к сети за мегабайт. Если четыре тысячи студентов одновременно загружали одну и ту же главную страницу, учебное заведение платил за один документ четыре тысячи раз. Прокси-сервер с кэшированием позволял выполнить этот запрос всего один раз. Кэши Harvest можно было организовывать в иерархии и налаживать связь между ними с помощью протокола Internet Cache Protocol, благодаря чему в случае промаха на одном из кампусов запрос мог обслуживаться соседним сервером, а не исходным.
Вехи расположены на равном расстоянии друг от друга, масштаб не соблюдён. Источники: архив W3C (1994), USENIX (1992), IETF RFC 1928 (1996), проект веб-кеша Squid, проект Tor, Cloudflare (2026).
Именно благодаря кэширующим прокси-серверам веб-страницы 1990-х годов вообще загружались. Это не вопрос безопасности и не вопрос конфиденциальности. Это вопрос экономики, и экономические факторы вновь вышли на первый план.
## Какую проблему решал SOCKS в 1992 году?
SOCKS появился на два года раньше публикации статьи о веб-прокси. В сентябре 1992 года Дэвид Коблас и Мишель Р. Коблас представили протокол *SOCKS* на третьем симпозиуме USENIX по безопасности UNIX в Балтиморе ([материалы USENIX](https://www.usenix.org/conference/sec92/socks), 1992), и с этого момента протокол стал общедоступным. Версия 5 была стандартизирована в качестве [RFC 1928](https://www.rfc-editor.org/rfc/rfc1928.html) в марте 1996 года; в ней описывается архитектура для клиент-серверных приложений, позволяющая «удобно и безопасно использовать услуги сетевого брандмауэра».
Прочитайте это предложение ещё раз. В 1996 году сама IETF определила основные приоритеты как безопасность и удобство. А не анонимность.
Такая же закономерность прослеживается на протяжении всей истории развития протокола. Каждая из приведённых ниже вех решала конкретную эксплуатационную проблему, и каждая из этих проблем существует до сих пор:
| Год | Веха | Решённая проблема |
|---|---|---|
| 1992 | Презентация протокола SOCKS на конференции USENIX | Обеспечение возможности прохождения через брандмауэр произвольных TCP-приложений, а не только веб-браузеров |
| 1994 | Статья CERN «World-Wide Web Proxies» | Предоставление сотрудникам, находящимся в закрытой подсети, доступа к внешнему Интернету |
| 1995 | Начало работ по луковой маршрутизации в NRL | Сохранение анонимности источника конфиденциального правительственного трафика |
| 1996 | Стандарт RFC 1928 закрепляет протокол SOCKS5 | Добавление аутентификации и протокола UDP к механизму обхода брандмауэра |
| 1996 | Выпуск Squid 1.0.0 | Сокращение расходов на трафик за счёт предотвращения повторной загрузки одного и того же документа |
| 2002 | Запуск сети Tor | Превращение результатов исследований NRL в общедоступную сеть анонимности |
| 2026 | Большая часть трафика становится нечеловеческим | Определение источника миллиардов запросов от машин |
Tor — это то, что запомнилось людям, и он появился на десять лет позже остальных. Это был восьмой акт в этой истории, а не первый.
SOCKS5 — это не музейный экспонат. В 2026 году он является поддерживаемым протоколом в сети Massive для частных пользователей наряду с HTTP и HTTPS. Протокол, стандартизированный тридцать лет назад, по-прежнему фигурирует в списке функций коммерческого продукта, поскольку с самого начала должным образом решил поставленную задачу.
«Луковичная маршрутизация» — предшественник Tor — возникла в ту же эпоху и в аналогичной институциональной среде. В 1995 году Дэвид Голдшлаг, Майкл Рид и Пол Сиверсон из Исследовательской лаборатории ВМС США начали задаваться вопросом, можно ли устанавливать интернет-соединения, не раскрывая, кто с кем общается. Результатом этой работы стали первые проекты и прототипы «луковичной маршрутизации», и её целью была защита правительственных сообщений, передаваемых по общедоступным сетям ([История проекта Tor](https://www.torproject.org/about/history/), прочитано 31.08.2026). Технология, которая впоследствии стала синонимом «даркнета», финансировалась ВМС США с целью предотвращения простой идентификации разведывательных сообщений.
## Где прокси-серверы встречаются в повседневной жизни?
Практически везде. **Обратный прокси-сервер** — это тот же сервер, только работающий в обратном направлении: он обслуживает владельца сайта, а не запрашивающего пользователя, и такой сервер находится перед практически каждым веб-сайтом, который вы загрузили сегодня. Сети доставки контента представляют собой кэширующие прокси, распределённые по периферии. Балансировщики нагрузки — это прокси. Терминация TLS перед сервером приложений — это прокси. Корпоративные шлюзы исходящего трафика, фильтры контента в школах и библиотеках, шлюзы API, сервисные сетки: все они — прокси, выполняющие точно то же, что и сервер CERN в 1994 году.
Самое интересное — это терминология. Когда посредник работает на владельца сайта, в отрасли его называют «инфраструктурой» и помещают на схему архитектуры. Когда он работает на сторону, отправляющую запрос, в отрасли его называют «прокси». Один и тот же сервер, одно и то же место в пути запроса. Изменилось лишь направление стрелки, а вместе с ним — и термин.
Об этом стоит знать, хотя бы для того, чтобы схема архитектуры и список поставщиков перестали восприниматься как две разные технологии.
## Почему Интернету сейчас как никогда нужны прокси?
Потому что Интернет перестал быть преимущественно человеческим. В отчёте, опубликованном 1 июля 2026 года, компания Cloudflare установила, что по состоянию на июнь 2026 года более 50 % трафика в Интернете приходится на нечеловеческие источники, а 52 % запросов роботов-пауков приходится на обучение искусственного интеллекта, по сравнению с 22 % весной 2025 года ([Cloudflare, *Content Independence Day, one year on*](https://blog.cloudflare.com/agentic-internet-bot-report/), 1 июля 2026 года).
Источник: Cloudflare, «День независимости контента: год спустя», 1 июля 2026 года.
В том же отчёте за 2026 год компания Cloudflare также установила, что из каждого часа, проведённого в Интернете в поисках информации, лишь пятнадцать минут приходится на открытый Интернет, а в некоторых из наиболее активно индексируемых категорий трафик, генерируемый пользователями, сократился на целых 40 % менее чем за год ([Cloudflare](https://blog.cloudflare.com/agentic-internet-bot-report/), 1 июля 2026 г.).
Источник: Cloudflare, «День независимости контента», год спустя, 1 июля 2026 г.
Сравните эти два вывода, и суть проблемы станет очевидной. Машины выполняют большую часть запросов, люди проводят большую часть времени в поисковых системах, а открытый Интернет читается чаще, чем когда-либо, при этом его посещают реже, чем когда-либо. Каждое из этих машинных чтений должно иметь какой-то источник. Это косвенный вопрос, и сейчас он является ключевым.
## Как построена современная сеть устройств?
На основе согласия. Massive начинала как продукт для монетизации приложений, в рамках которого пользователи обменивали часть простоя вычислительных ресурсов на премиум-функции, а каждое IP-адрес давало согласие на участие через SDK Massive. В результате мы располагаем более 1 млн проверенных бытовых устройств в более чем 195 странах; наша система прошла аудит SOC 2, соответствует требованиям GDPR, сертифицирована AppEsteem и обеспечивает полный аудиторский след от источника до запроса. Оператор может указать, чьё подключение передало конкретный запрос.
Это не новое требование. Прокси-сервер CERN регистрировал каждый проходящий через него запрос, поскольку системный администратор должен был быть в состоянии отчитаться за трафик. Сеть устройств отвечает на тот же вопрос на один уровень ниже: не только что именно запрашивалось, но и через чье соединение это прошло, а также на каких условиях было согласовано его передача.
Два вопроса, которые стоит задать любой сети устройств: можете ли вы назвать условия, на которые согласился владелец устройства, и можете ли вы отследить запрос до его источника? На оба вопроса существуют убедительные ответы с 1994 года. Масштаб изменился, а суть вопроса аудита осталась прежней.
Над этой сетью расположено рендеринговое звено, которое возвращает чистый HTML или Markdown из любого общедоступного источника, где бы он ни находился. Это и есть постановка задачи 1994 года: обеспечить доступ к общедоступному Интернету из любого места, где он вам действительно нужен, с форматами вывода, ожидаемыми конвейером 2026 года.
Более подробно о вопросах согласия в сетях устройств см. в статье [«Как выглядит согласие при совместном использовании пропускной способности»](https://joinmassive.com/blog/what-does-consent-look-like-in-bandwidth-sharing).