# Чем отличается VPN от прокси

> Чем отличается VPN от прокси: уровень обработки данных, область действия, шифрование и DNS. Сводная таблица различий HTTP-прокси, SOCKS5 и системного туннеля.

Источник: https://vpn-ne-rabotaet.ru/chto-takoe-vpn/vpn-i-proxy/
Страница обновлена: 2026-08-17

---

**Прокси и VPN выводят трафик через промежуточный узел, но работают на разных уровнях: прокси обслуживает отдельное приложение и сам ничего не шифрует, а VPN поднимает системный сетевой интерфейс и шифрует IP-пакеты всего устройства.** Различий по существу три: уровень обработки, область действия и криптография.

> **Коротко.** SOCKS5 (RFC 1928) — прослойка между прикладным и транспортным уровнями, алгоритмов шифрования в стандарте нет. HTTP-прокси при методе CONNECT (RFC 9110) слепо пересылает байты. WireGuard упаковывает IP-пакеты в UDP и шифрует их связкой ChaCha20-Poly1305. Прокси включается в одной программе, туннель — для всей системы. Анонимности не даёт ни один из механизмов.

## Что такое прокси и что такое туннель?

Прокси — посредник, которого клиент выбирает сам своими настройками (RFC 9110, раздел 3.7); там же он отделён от шлюза (обратного прокси) и от перехватывающего прокси, неотличимого от постороннего в середине маршрута. Туннель в смысле VPN — виртуальный сетевой интерфейс: по документации Android сервис создаёт его сам, настраивает адреса и маршруты, а пакеты внутри начинаются с IP-заголовка. Подробнее — [что такое ВПН](/chto-takoe-vpn/).

## На каком уровне работает каждый механизм?

Туннель обрабатывает IP-пакеты, прокси — TCP-поток или отдельный HTTP-запрос. Номер уровня OSI первоисточники не называют: RFC 1928 описывает SOCKS5 как shim-прослойку между прикладным и транспортным уровнями, Chromium — как транспортный прокси. Следствие: SOCKS не даёт услуг шлюза сетевого уровня и не пересылает ICMP, поэтому ping и traceroute через прокси не проходят, а WireGuard инкапсулирует любые IP-пакеты поверх UDP.

## Чем HTTP-прокси отличается от SOCKS5?

HTTP-прокси разбирает запрос и видит его целиком, SOCKS5 знает только адрес назначения. Соединение по SOCKS5 идёт в четыре шага:

1. Клиент открывает TCP-соединение (по традиции порт 1080) и шлёт поле VER = X'05' со списком методов аутентификации.
2. Сервер выбирает метод: X'00' — без аутентификации, X'02' — пароль по RFC 1929, X'01' — GSSAPI.
3. Клиент передаёт команду CMD: CONNECT = X'01', BIND = X'02', UDP ASSOCIATE = X'03'; адрес задаёт ATYP — X'01' для IPv4, X'03' для домена, X'04' для IPv6.
4. Сервер соединяется с целевым узлом и работает трубой, не разбирая содержимого.

У HTTP-прокси иначе: для запросов по http:// цель передаётся в абсолютной форме (RFC 9112, раздел 3.2) — `GET http://example.org/pub/page.html HTTP/1.1`. Посредник получает схему, домен, путь с параметрами и заголовки Host, Cookie, User-Agent, обязан добавить Via и запрашивает пароль статусом 407.

## Почему CONNECT не равен шифрованию?

Потому что CONNECT просит посредника открыть туннель и слепо пересылать данные — таково его определение в RFC 9110. Шифрует TLS внутри туннеля; для ресурса по http:// пойдёт открытый текст. Цель задаётся особой формой, только хост и порт: `CONNECT server.example.com:443 HTTP/1.1` — домен и порт видны, URL и заголовки нет. Пароль защитой не является: Basic по RFC 7617 передаёт данные в Base64, а RFC 1929 предупреждает, что пароль SOCKS5 идёт открытым текстом.

## Кто разрешает доменное имя в адрес?

Ответ зависит от клиента, а не от протокола — отсюда и недоумение «прокси включён, а DNS-запросы уходят провайдеру».

- **curl.** `--socks5` резолвит имя локально, `--socks5-hostname` — на прокси; то же задают схемы `socks5://` и `socks5h://`.
- **Chrome.** По документации Chromium у HTTP-прокси имя разрешает прокси, у SOCKSv4 — клиент и только в IPv4, у SOCKSv5 — снова прокси. Аутентификация SOCKSv5 не поддерживается, UDP не ретранслируется.
- **Firefox.** В актуальных исходниках `network.proxy.socks5_remote_dns` по умолчанию `true`, а `network.proxy.socks_remote_dns` для SOCKS4 — `false`.

У туннеля развилки нет: wg-quick принимает ключ `DNS =` и вызывает `resolvconf` — резолвер меняется системно.

## Сводная таблица различий

Девять осей, по которым они расходятся.

| Ось сравнения | Прокси (HTTP или SOCKS5) | Туннель (WireGuard) |
|---|---|---|
| Что обрабатывает | HTTP-запрос или TCP-поток | IP-пакеты целиком |
| Область действия | Одно приложение | Интерфейс всей системы |
| Шифрование | В RFC 1928 нет, у HTTP-прокси нет | ChaCha20-Poly1305, Curve25519, Noise_IK |
| Ключи | Не существуют | Смена через 120 с, отказ от старых через 180 с |
| Видит посредник | URL и заголовки, при CONNECT — host:port | Шифртекст, но виден ваш IP |
| DNS | Клиент или прокси, зависит от программы | Задаёт ключ DNS |
| UDP и ICMP | UDP через UDP ASSOCIATE, ICMP не идёт | Любые IP-пакеты, включая ICMP |
| Аутентификация | X'00', пароль текстом, Basic в Base64 | Криптографическое рукопожатие |
| Обрыв связи | Ошибка либо соединение мимо прокси | Kill-switch добавляется вручную: PostUp/PreDown |

## Как включается прокси и как туннель?

Прокси включается настройкой приложения: расширение Chrome управляет им через API `chrome.proxy` с разрешением `proxy` и схемами http, https, quic, socks4, socks5. Браузерные «VPN-расширения» так и работают — меняют настройки одного браузера, а мессенджеры, игры и обновления системы идут мимо. Системный канал иной: на Android сервис объявляется с разрешением `BIND_VPN_SERVICE`, активным может быть лишь одно подключение, а списки `addAllowedApplication` и `addDisallowedApplication` взаимоисключающие. Практика — [как пользоваться ВПН](/chto-takoe-vpn/kak-polzovatsya/).

## Когда уместен каждый механизм?

Прокси уместен, когда нужно увести трафик одной программы. Пример без стороннего сервиса — `ssh -D`: OpenSSH поднимает локальный SOCKS-сервер (SOCKS4 и SOCKS5) и пробрасывает соединения по каналу SSH. Туннель уместен, когда важен охват: один канал для всех приложений, поддержка UDP и ICMP, предсказуемая точка выхода, защита в публичном Wi-Fi, безопасный удалённый доступ. Границы есть и у него: туннелирование поверх TCP WireGuard не поддерживает, маскировкой трафика проект не занимается. Как поднять канал — [настройка WireGuard на своём VPS](/nastrojka/wireguard/).

## Чего не делают оба механизма?

Ни прокси, ни туннель не дают анонимности: меняется видимый адрес, а не личность. Прокси способен раскрыть вас сам — RFC 7239 определяет заголовок Forwarded с параметром for, куда подставляется исходный адрес клиента. Раздел 4 рекомендует держать заголовок выключенным по умолчанию, а раздел 8.3 признаёт адрес клиента чувствительными данными и требует обфусцированных идентификаторов в for и by по умолчанию. Что от смены точки выхода не зависит вовсе — вход в аккаунт и фишинг — разобрано в материале [что такое ВПН](/chto-takoe-vpn/). Исходный адрес известен владельцу узла и там, и там; что попадает в логи — в материале про [безопасность](/bezopasnost-vpn/).

## Частые вопросы

Короткие ответы на частые вопросы о прокси и туннеле.

*Материал носит научно-технический характер и посвящён шифрованию трафика и настройке собственного защищённого канала. Прямой ответственности за использование VPN физическим лицом законодательство РФ не устанавливает. Сайт не рекламирует сервисы и не публикует рейтинги.*