Прокси-сервер

11 июля 2026 · ~13 мин чтения

Прокси-сервер

Прокси-сервер (proxy — «доверенное лицо», «посредник») — это промежуточный
сервер, который принимает запросы от клиента и пересылает их дальше от
своего имени, а ответы возвращает обратно. Целевой сервер видит не тебя,
а прокси; ты общаешься не с сервером напрямую, а через посредника.

История

Идея посредника в сети старше самого веба, но как отдельное понятие
прокси оформился вместе с ростом World Wide Web в первой половине 1990-х.

• 1990–1994, CERN, Швейцария. Первый в мире веб-сервер — CERN httpd,
  написанный командой Тима Бернерса-Ли, — довольно быстро научился работать
  «шлюзом»: принимать запросы от браузеров внутри закрытой сети и ходить во
  внешний веб от их имени. В 1994 году Ари Луотонен (CERN) и Кевин Алтис
  опубликовали классическую статью «World-Wide Web Proxies», где впервые
  системно описали, что такое веб-прокси и зачем он нужен: доступ из-за
  файрвола и кэширование. Это фактически свидетельство о рождении термина
  в вебе.
• Примерно 1992 год. Дэвид Коблас представил SOCKS — универсальный
  протокол-посредник, который пересылает не веб-страницы, а любые
  TCP-соединения. В 1996 году пятая версия закреплена как стандарт
  RFC 1928 — SOCKS5 жив и массово используется до сих пор.
• 1996 год. Из университетского проекта Harvest вырос Squid —
  кэширующий прокси с открытым кодом, который на годы стал синонимом слова
  «прокси» в корпоративных сетях и у интернет-провайдеров. В эпоху дорогого
  и медленного интернета Squid экономил трафик, храня копии популярных
  страниц поближе к пользователям.
• 2000-е. Акцент смещается с экономии трафика на управление им:
  корпоративная фильтрация, балансировка нагрузки, и главное — расцвет
  обратных прокси (reverse proxy): nginx (2004, Игорь Сысоев), HAProxy,
  Varnish. Посредник встал не перед пользователем, а перед сервером.
• 2010-е — наши дни. Прокси стал невидимой тканью интернета: CDN и
  Cloudflare-подобные сервисы — это гигантские сети обратных прокси;
  сервисы «резидентных» и «мобильных» прокси продают IP-адреса обычных
  людей и сотовых операторов; микросервисные кластеры общаются между собой
  через прокси-«сайдкары» вроде Envoy.

Что это такое

Суть в одной картинке: вместо «клиент → сервер» получается
«клиент → посредник → сервер». Всё остальное — детали того, кто
поставил посредника и в чью пользу он работает.

Главное разделение — forward proxy vs reverse proxy (прямой против
обратного):

• Forward proxy работает на стороне клиента. Ты (или твоя компания,
  или твой скрипт) сознательно направляешь свой трафик через посредника.
  Цели: скрыть свой адрес, обойти ограничение, выйти из закрытой сети,
  закэшировать частые запросы, отфильтровать запрещённое. Целевой сервер
  видит IP-адрес прокси, а не твой.
• Reverse proxy работает на стороне сервера. Владелец сайта ставит
  посредника перед своими серверами. Цели: распределить нагрузку между
  несколькими машинами, оборвать на себе TLS-шифрование, отдать статику из
  кэша, спрятать внутреннюю структуру, отбить DDoS-атаку. Клиент при этом
  вообще не догадывается, что говорит с посредником, — для него это «сайт».

Одна и та же технология, направленная в разные стороны, решает почти
противоположные задачи — поэтому вокруг слова «прокси» столько путаницы.

Полезные пары для различения:

• Прокси vs VPN. VPN заворачивает и шифрует весь сетевой трафик
  устройства на уровне операционной системы; прокси обычно настраивается
  для конкретного приложения или протокола и сам по себе шифрование не
  добавляет. VPN — «переехал в другую страну целиком», прокси — «отправил
  курьера с одним конкретным поручением».
• Прокси vs NAT. NAT на домашнем роутере тоже подменяет твой адрес, но
  он работает на уровне пакетов, механически, не понимая содержимого.
  Прокси работает на уровне приложений: он читает запрос («ага, ты
  хочешь GET /page HTTP/1.1»), может его изменить, залогировать, отклонить
  или ответить из кэша.
• Прокси vs шлюз (gateway). Шлюз соединяет две разные сети или два
  протокола и обязателен для прохода; прокси — необязательный посредник
  внутри одного протокола, которого можно поставить, а можно убрать.

Аналогии из жизни

1. Секретарь руководителя (forward proxy). Ты просишь секретаря
позвонить в ресторан и забронировать столик. Ресторан слышит голос и номер
секретаря, а не твой. Секретарь может отказаться («в этот ресторан мы не
звоним»), может ответить сам («я там уже бронировал вчера, столик есть») —
это фильтрация и кэш.
Где ломается: секретарь знает о тебе всё — кто ты и что просил. Прокси
не даёт анонимности от самого прокси: его владелец видит твой трафик. И
если секретарь нечистоплотен, он перескажет твои просьбы кому угодно —
ровно так работают недобросовестные «бесплатные прокси».

2. Администратор зала в ресторане (reverse proxy). Ты говоришь с одним
человеком у входа, а он решает, к какому из десяти официантов тебя
посадить, и приносит воду сам, не дёргая кухню. Для тебя ресторан — это
один администратор; сколько за ним поваров и официантов, ты не знаешь.
Где ломается: если администратор один и он упал в обморок, ресторан
«лежит» целиком, даже если кухня в порядке. Reverse proxy — единая точка
отказа, поэтому в серьёзных системах его резервируют. А ещё аналогия молчит
о том, что администратор может переписывать заказы — реальный прокси
умеет менять заголовки и содержимое.

3. Абонентский ящик и переадресация почты. Отправитель пишет на адрес
а/я, а не на твой домашний; служба пересылает письма туда, куда ты указал.
Сменил квартиру — переадресация продолжает работать, отправители ничего не
заметили.
Где ломается: почта идёт с задержкой — и прокси тоже добавляет задержку
(лишний сетевой прыжок). Плюс письмо в ящике лежит нетронутым, а прокси
может вскрывать и читать «конверты», если трафик не зашифрован — аналогия
опасно преуменьшает степень доступа посредника к содержимому.

Как это работает

Разберём три типовых сценария, по нарастающей.

Сценарий 1: обычный HTTP-прокси (незашифрованный трафик).

1. Браузер настроен «ходить через proxy.example.com:3128».
2. Вместо того чтобы открывать соединение с сайтом, браузер открывает
   соединение с прокси и отправляет запрос целиком:
   GET http://site.ru/page HTTP/1.1 (обрати внимание — URL полный,
   с доменом: прокси должен знать, куда идти).
3. Прокси решает: пустить? отдать из кэша? залогировать? Потом сам
   открывает соединение с site.ru, получает ответ и пересылает тебе.
4. Часто прокси дописывает заголовок X-Forwarded-For: <твой IP> —
   «передаю от такого-то». Анонимные прокси этого не делают.

Сценарий 2: HTTPS через прокси — метод CONNECT.

С зашифрованным трафиком прокси не может читать запрос — и не должен.
Поэтому браузер просит: CONNECT site.ru:443 HTTP/1.1 — «пробрось мне
туннель до этого адреса». Прокси открывает TCP-соединение и дальше тупо
перекачивает зашифрованные байты в обе стороны, не понимая содержимого.
Он видит только куда ты ходишь (домен), но не что ты там делаешь.

Сценарий 3: SOCKS5 и мобильные прокси.

SOCKS5 — посредник уровнем ниже: он пересылает любые TCP-соединения
(и UDP), не разбирая протокола. Браузер, мессенджер, торрент-клиент —
всё ходит одинаково. Схема: клиент подключается к SOCKS-серверу,
проходит аутентификацию (логин/пароль), говорит «соедини меня с таким-то
адресом» — и дальше течёт сырой поток байтов.

Особый подвид — мобильные прокси. Провайдер такого сервиса держит
ферму устройств с SIM-картами (или соглашения с операторами), и твой
трафик выходит в интернет с настоящего IP-адреса сотового оператора.
Ключевые слова здесь:

• exit-IP — адрес, с которого твой запрос «выныривает» в интернет;
  именно его видит целевой сайт.
• Ротация — смена exit-IP: по расписанию (каждые N минут) или по
  запросу — дёрнул специальную ссылку, получил новый адрес.

Почему это работает против антифрода: сотовые операторы прячут тысячи
абонентов за небольшим пулом общих IP (CGNAT — операторский NAT), поэтому
заблокировать мобильный IP — значит заблокировать заодно толпу невинных
людей. Сайты поэтому относятся к таким адресам мягче: меньше капчи,
меньше банов. Обратная сторона — мобильные прокси медленные и дорогие.

Простая схема всего сказанного:

forward proxy:   [ты] ──> [прокси на твоей стороне] ──> [сайт]
reverse proxy:   [ты] ──> [прокси на стороне сайта] ──> [ферма серверов]
цепочка:         [ты] ──> [прокси 1] ──> [прокси 2] ──> [сайт]

Цепочки прокси тоже бывают: каждый следующий узел знает только соседей.
На этой идее построен Tor — три посредника, каждый из которых не видит
картину целиком.

Где встречается в обычной жизни

• Офисный интернет. В большинстве средних и крупных компаний браузер
  ходит в сеть через корпоративный прокси: он режет запрещённые категории
  сайтов, логирует посещения и часто расшифровывает HTTPS. «Почему с
  рабочего ноута не открывается сайт» — почти всегда про него.
• Любой крупный сайт. Открываешь интернет-магазин или банк — с
  вероятностью, близкой к 100%, ты говоришь не с их сервером, а с обратным
  прокси (CDN, балансировщик, анти-DDoS-щит). Замечаешь это, только когда
  видишь страницу «Checking your browser... Cloudflare».
• Мобильный интернет. Твой смартфон почти наверняка сидит за CGNAT
  оператора — с одним публичным IP на сотни абонентов. Это не совсем
  прокси, но именно поэтому «IP-адрес» давно не равен «человек».
• Блокировки и их обход. Когда сайт «не открывается», а через
  посредника — открывается, ты пользуешься forward proxy, даже если кнопка
  в приложении называется иначе.
• Экономия трафика в браузере. Режимы «турбо» и «экономия данных» в
  мобильных браузерах гоняли страницы через прокси-серверы производителя,
  которые сжимали картинки и код по дороге.

Где встречается в IT и бизнесе

• Балансировка нагрузки. Нужно, когда один сервер перестал вывозить:
  reverse proxy (nginx, HAProxy) раскидывает запросы по ферме серверов и
  убирает из ротации умершие. Это самый массовый способ масштабировать веб.
• API-gateway. Специализированный reverse proxy перед микросервисами:
  аутентификация, лимиты запросов (rate limiting), версионирование API —
  всё в одном месте, а не в каждом сервисе отдельно.
• Корпоративная безопасность. Прокси как контрольно-пропускной пункт: фильтрация
  категорий сайтов, защита от утечек данных (DLP), журналирование. Нужно,
  когда за трафик сотрудников отвечаешь юридически.
• Парсинг и автоматизация. Скрипты и боты, которые собирают данные с
  сайтов, ходят через пулы резидентных или мобильных прокси с ротацией
  IP — иначе первый же антифрод их забанит. Целая индустрия с прайсом
  «за гигабайт трафика».
• Кэширование на границе (edge). CDN — это сеть reverse proxy по всему
  миру: пользователь получает картинку с сервера в своём городе, а не с
  другого континента. Нужно, когда аудитория географически размазана.

Кто пользуется

• Cloudflare — крупнейшая в мире сеть обратных прокси: по данным
  самой компании, через неё проходит трафик примерно каждого пятого
  сайта в интернете, а в пике она обрабатывает десятки миллионов
  HTTP-запросов в секунду.
• nginx — по данным W3Techs, годами делит с Apache и Cloudflare
  первые места среди веб-серверов мира; огромная доля его установок —
  именно в роли reverse proxy, а не «чистого» веб-сервера.
• Netflix, букинги, банки — за любым брендом с миллионами
  пользователей стоит слой балансировщиков и API-gateway; у Netflix,
  например, это открытый проект Zuul.
• Google, Meta, крупные клауды — внутри дата-центров сервисы общаются
  через сайдкар-прокси (Envoy и аналоги) — это называется service mesh
  (сервисная сетка); Envoy родился в Lyft в 2016 году.
• Squid до сих пор стоит у провайдеров и в университетских сетях по
  всему миру — проекту почти тридцать лет.

Альтернативы и конкуренты

• VPN.
  Плюсы: шифрует весь трафик устройства, не нужно настраивать каждое
  приложение, скрывает сам факт того, куда ты ходишь, от локальной сети.
  Минусы: тяжелее и дороже в развёртывании, весь трафик — в одну трубу,
  для точечных задач (один скрипт, один сайт) избыточен.
• SSH-туннель (port forwarding).
  Плюсы: если есть любой сервер с SSH — прокси уже готов, одна команда
  (ssh -D даёт SOCKS-прокси), трафик зашифрован.
  Минусы: держится на одном соединении, неудобно для команды, нет
  управления политиками и кэша.
• Tor.
  Плюсы: настоящая анонимность через цепочку из трёх узлов, бесплатно.
  Минусы: медленный, многие сайты блокируют выходные узлы, для бизнес-задач
  почти всегда неприемлем по скорости и репутации.
• NAT/шлюз без прокси.
  Плюсы: прозрачно, быстро, ничего не настраивать в приложениях.
  Минусы: нет понимания протокола — ни фильтрации по URL, ни кэша, ни
  логов уровня приложения.

Когда НЕ стоит использовать

• Когда нужна настоящая анонимность. Обычный прокси — это перенос
  доверия: вместо провайдера твой трафик видит владелец прокси. Бесплатные
  прокси нередко существуют именно ради сбора чужого трафика. Потому что
  посредник — это не невидимость, а другой наблюдатель.
• Когда критична задержка. Каждый посредник — лишний сетевой прыжок и
  лишние миллисекунды. Для игр, звонков, трейдинга прокси на пути — зло,
  если только он не стоит физически ближе к цели.
• Когда это способ «решить» проблему доступа в обход правил. Если
  корпоративная сеть или сервис что-то запрещает, прокси технически может
  это обойти — но это нарушение договора или закона, а не инженерное
  решение. Потому что блокировка — это правило, а не баг.

Связанные понятия

• Reverse proxy (обратный прокси) — посредник на стороне сервера:
  балансировка, кэш, TLS-терминация.
• CDN (Content Delivery Network) — географически распределённая сеть
  кэширующих обратных прокси.
• NAT (Network Address Translation) — подмена адресов на уровне
  пакетов, «прокси без понимания смысла».
• SOCKS5 — протокол универсального проксирования любых TCP/UDP-потоков.
• MITM (man-in-the-middle) — атака (или легальная инспекция), когда
  посредник расшифровывает и читает чужой трафик.
• Service mesh (сервисная сетка) — архитектура, где каждый микросервис
  общается с миром через персональный сайдкар-прокси.
• CGNAT (Carrier-Grade NAT) — операторский NAT, из-за которого тысячи
  абонентов делят один публичный IP.

Литература и источники

• Ari Luotonen, Kevin Altis. «World-Wide Web Proxies» (1994, en) — та
  самая первая статья; ищется по точному названию.
• RFC 1928 «SOCKS Protocol Version 5» (1996, en) —
  https://www.rfc-editor.org/rfc/rfc1928
• Wikipedia (ru/en): «Прокси-сервер» / «Proxy server», отдельно —
  «Reverse proxy» — хорошая карта разновидностей.
• Документация nginx, раздел про reverse proxy и модуль proxy_pass —
  https://nginx.org/ru/docs/
• Книга: James Kurose, Keith Ross. «Computer Networking: A Top-Down
  Approach» (en; есть русский перевод «Компьютерные сети. Нисходящий
  подход») — главы про прикладной уровень дают системную картинку, где
  прокси живёт в сетевом стеке.
• Блог Cloudflare (blog.cloudflare.com, en) — регулярные разборы, как
  устроены крупнейшие в мире обратные прокси изнутри.

Где встретилось у меня

Вчера я настраивал браузерную автоматизацию, которая ходит в интернет
через мобильные прокси: проверял, каким exit-IP её видит внешний мир,
разбирался со сменой адреса по специальной ссылке ротации и с
авторизацией на самом прокси. Попутно всплыла разница между headful- и
headless-режимом браузера и то, как сайты по-разному встречают трафик с
«обычных» и мобильных адресов.

Краткое резюме

• Прокси — посредник между клиентом и сервером: запросы идут через него и
  от его имени.
• Два лица одной технологии: forward proxy служит клиенту (скрыть адрес,
  отфильтровать, закэшировать), reverse proxy служит серверу (балансировка,
  кэш, защита). Почти весь современный веб стоит за обратными прокси.
• Прокси — это перенос доверия, а не анонимность: владелец посредника
  видит твой трафик. Бесплатные прокси опасны именно этим.
• С HTTPS прокси видит только домены (через метод CONNECT), но
  корпоративные прокси умеют TLS-инспекцию и читают всё.
• Мобильные прокси дают exit-IP сотовых операторов с ротацией — сайты
  относятся к таким адресам мягче, потому что за одним IP стоят толпы
  реальных людей.