Режим SOCKS5 — стандартный и самый гибкий способ использования rVPN. Он запускает локальный SOCKS5-прокси, на который можно направлять отдельные приложения — не затрагивая другой трафик на вашей машине.
rVPN также может работать как HTTP-прокси вместе с SOCKS5-прокси. Это полезно, когда приложения или окружения ожидают переменных окружения HTTP_PROXY/HTTPS_PROXY, указывающих на HTTP-прокси (самая распространённая конвенция для CLI-инструментов вроде curl, git, npm, pip и Docker).
Оба прокси используют общий пул WebSocket-соединений — одновременная работа обоих не создаёт дополнительных накладных расходов.
Самый распространённый способ использования HTTP-прокси — через переменные окружения. Большинство CLI-инструментов и языков программирования автоматически их учитывают:
Окно терминала
export HTTP_PROXY=http://127.0.0.1:8118
export HTTPS_PROXY=http://127.0.0.1:8118
export ALL_PROXY=http://127.0.0.1:8118
После задания этих переменных такие инструменты, как curl, git, npm, pip, wget и Docker, идут через VPN без покомандной настройки:
Окно терминала
# No --proxy flag needed — env vars are picked up automatically
curlhttps://api.ipify.org
gitclonehttps://github.com/user/repo.git
pipinstallrequests
Добавьте в ~/.bashrc или ~/.zshrc, чтобы сохранить между сессиями.
HTTP CONNECT — используется для HTTPS. Клиент отправляет CONNECT host:443 HTTP/1.1, прокси отвечает 200 Connection Established, и трафик идёт через зашифрованный туннель к целевому хосту.
Обычная HTTP-пересылка — используется для незашифрованного HTTP. Клиент отправляет GET http://host/path HTTP/1.1, прокси подключается к хосту и пересылает запрос.
Оба пути учитывают правила раздельного туннелирования и используют тот же пул соединений, что и SOCKS5.
Клиенты должны отправлять заголовок Proxy-Authorization: Basic ... (браузеры и curl -x делают это автоматически, когда учётные данные в URL: http://user:[email protected]:8118).
В большинстве случаев используйте HTTP-прокси с переменными окружения — у него самая широкая совместимость с CLI-инструментами и системами сборки. Используйте SOCKS5 для проксирования отдельных приложений или когда нужна поддержка UDP.
Раздельное туннелирование позволяет направлять через VPN только определённый трафик, а остальной — напрямую. Это полезно, когда вы хотите достучаться до заблокированных сайтов через VPN, оставив локальный и внутренний трафик нетронутым.
Важно: Без DNS-прокси ваши DNS-запросы могут утечь провайдеру, даже когда вы используете SOCKS5-прокси. См. Защита от DNS-утечек для полного объяснения.
По умолчанию DNS-запросы разрешаются DNS-сервером вашей системы — вне VPN-туннеля. Это значит, что ваш провайдер может видеть, какие домены вы запрашиваете, даже когда ваш трафик проксируется.
rVPN включает встроенный DNS-прокси, который разрешает все запросы на стороне сервера через тот же зашифрованный WebSocket-туннель. Он также учитывает раздельное туннелирование: домены обхода разрешаются локально, а заблокированные рекламные/трекинговые домены сразу возвращают NXDOMAIN, не создавая сетевого трафика.
Все SOCKS5-потоки используют одно WebSocket-соединение с общей сессией Double Ratchet. Каждый SOCKS5 CONNECT создаёт логический «поток» через управляющие сообщения CreateFlow/CloseFlow в том же туннеле.
Преимущества:
Одно TLS-рукопожатие, один обмен ключами X3DH — ~250 мс накладных расходов вместо ~600 мс на каждое соединение
Создание потока за 0-RTT — данные отправляются немедленно, без ожидания подтверждения сервера
Меньшее потребление ресурсов сервера (один WebSocket, один ratchet вместо одного на поток)
Сервер поддерживает до 2000 одновременных потоков на mux-сессию
100% успешность в стресс-тестах (против ~85% для стандартного режима)
Компромиссы:
Единый долгоживущий бинарный поток — отличительный шаблон трафика, который могут обнаружить классификаторы
Все потоки используют одно соединение — если оно упадёт, всё переподключится
Как это работает:
Первый SOCKS5 CONNECT открывает mux-туннель WebSocket ({server_path}/mux)
Выполняется рукопожатие X3DH для установки общего Double Ratchet
Последующие потоки отправляют управляющие сообщения CreateFlow в том же туннеле
Клиент отправляет данные немедленно (0-RTT) — сервер буферизует, пока подключается к цели
Данные идут через мультиплексированные фреймы
Безопасность: Оптимизация 0-RTT — это НЕ TLS 0-RTT. TLS-рукопожатие и обмен ключами X3DH завершаются до того, как пойдут какие-либо данные. Защита от повторов обеспечивается Double Ratchet — у каждого сообщения свой message_number, а ratchet отклоняет сообщения с number < current (см. ratchet.rs:decrypt). Ключи сообщений расходуются после использования, поэтому повторы падают с «Message too old».
Конфигурация:
[socks5]
multiplex = true
# mux_path defaults to {server_path}/mux automatically
Замечание: Стандартный режим открывает один WebSocket на TCP-поток. В нагруженных сетях (например, браузеры с множеством вкладок) это может исчерпать серверный лимит max_connections_per_ip. При необходимости повысьте серверные лимиты:
