Перейти к содержанию

Стек прокси/туннель-протоколов: протокол, транспорт, безопасность, маскировка

Статус: Confirmed (разделение слоёв — официальная документация Xray; транспортная модель MASQUE — RFC; обфускация AmneziaWG — docs.amnezia.org) + Observed (MTU-матрёшка VLESS→WARP) + Research (частные детали поведения конкретных реализаций)
Область применения: чтение конфигураций Xray/Mihomo/sing-box; разбор цепочек вида «VLESS → VPS → WARP»; споры «VLESS+REALITY — это один протокол или нет»
Проверено на: Xray-docs-next (исходник xtls.github.io, 2026-09-24), RFC 9297/9298/9484, docs.amnezia.org (2026-09-24), wiki.metacubex.one (2026-09-24)
Последняя проверка: 2026-09-24
Source of truth: официальная документация Xray (транспорт/безопасность), IETF RFC (MASQUE), docs.amnezia.org
Provenance: raw-исследование proxy.md; базовые определения — в vpn-proxy-terminology.md, карта встраивания в ОС — в network-layer-tunnel-map.md

Что решаем

Сравнения вида «VLESS лучше WireGuard» или «REALITY — это транспорт?» — обычно ошибки категории: сравниваются вещи с разных слоёв. Эта статья даёт практическую слоёную модель, в которой у каждой технологии видно её место, и показывает, почему корректно собирать из них цепочки.

Слоёная модель

трафик приложения
    ↓
решение о маршруте (policy routing / правила движка)
    ↓
вход: прокси-listener или туннель-интерфейс (SOCKS5-порт, TUN)
    ↓
протокол проксирования/туннелирования (VLESS, SOCKS5, WireGuard…)
    ↓
транспорт (TCP/raw, WebSocket, gRPC, QUIC…)
    ↓
безопасность/маскировка при наличии (TLS, REALITY, AWG-джанк)
    ↓
IP-сеть

Порядок столбцов в конфиге может отличаться, но решения независимы: сменить транспорт, не меняя протокол; сменить outbound, не меняя вход; добавить маскировку, не меняя уровень туннелирования.

Слой протокола проксирования

Протокол отвечает на вопрос: как один узел просит другой передать трафик дальше.

  • SOCKS5 (RFC 1928) — классика: CONNECT для TCP, UDP ASSOCIATE для UDP.
  • HTTP-прокси / HTTP CONNECT — классика для веб-трафика.
  • VLESS / VMess / Trojan / Shadowsocks — протоколы проксирования нового поколения: минималистичные, с авторизацией (uuid/пароль) и шифрованием на своей стороне.
  • Hysteria2 / TUIC — протоколы поверх QUIC: другая транспортная база, те же роль и слой.

VLESS — именно протокол проксирования, а не «L7-прокси» в строгом OSI-смысле и не VPN. Он не становится VPN от того, что его подняли через TUN.

Слой транспорта

Официальная документация Xray разделяет протокол и транспорт явно: транспортная конфигурация — это «часть передачи данных вне прокси-протокола», и в ней три независимые категории:

  • транспортный способ (method): raw (бывший tcp), websocket, grpc, xhttp, mkcp, httpupgrade, hysteria;
  • безопасность транспорта (security): none / tls / reality;
  • дополнительные параметры (sockopt, finalmask).

Обе стороны должны использовать совместимый транспорт — если один конец на WebSocket, другой тоже обязан быть на WebSocket.

Слой безопасности и маскировки

REALITY — это настройка безопасности транспорта, а не отдельный протокол. Отсюда:

VLESS + REALITY + TCP(raw) — это три независимых выбора: протокол VLESS, безопасность REALITY, транспорт raw. Не один «индивидуальный протокол VLESS-REALITY».

Компоненты можно менять по отдельности — на этом строятся связки вида VLESS+Vision, VLESS+WS+TLS, «selective REALITY» и т. п.

Что маскировка меняет и что не меняет

Меняет:

  • видимость потока для фильтра: сигнатуру рукопожатия, тайминги, размер начальных пакетов. AmneziaWG: Jc (число мусорных пакетов после сигнатурных I1–I5), Jmin/Jmax (их размер) размывают начало сессии; REALITY маскирует TLS-рукопожатие под чужой сертификат.

Не меняет:

  • конфиденциальность — её обеспечивает криптография самого протокола (Noise_IK у WireGuard/AWG, шифрование VLESS/TLS). Маскировка поверх уже зашифрованного — про незаметность, не про секретность;
  • уровень туннелирования — AWG с джанк-параметрами остаётся тем же L3-туннелем; REALITY не превращает VLESS в другой слой;
  • семантику проксирования — смена маскировки не меняет, кто/куда/как проксирует.

Технологии, охватывающие несколько слоёв

Не всё влезает в один столбец — и это нормально:

  • MASQUE — семейство туннелирования поверх HTTP (RFC 9298 CONNECT-UDP, RFC 9484 CONNECT-IP, датаграммы HTTP по RFC 9297). Рекомендуемый транспорт — HTTP/3 (QUIC): датаграммы QUIC позволяют не вкладывать повторное обнаружение потерь в TCP. При этом CONNECT-IP концептуально — «IP-канал»: IP-пакеты едут полезной нагрузкой HTTP-датеграмм, т. е. конструкция ведёт себя как туннель L3, хотя «ездит» по HTTP. Пример того, как технология законно живёт на нескольких слоях.
  • WireGuard — сразу и крипто-протокол, и L3-туннель, и жёстко привязан к UDP-транспорту; отдельного «меню транспорта» у него нет. AmneziaWG добавляет слой маскировки, не трогая остальные.
  • Shadowsocks — шифрование и обфускация в одном пакете; исторически заменял «протокол+транспорт» одним механизмом.

Если технология охватывает несколько слоёв — говорим это прямо, а не запихиваем силой в одну ячейку.

Цепочки: вход ≠ выход, композиция ≠ компонент

Практическое следствие слоёности — корректное чтение цепочек:

клиент → [входной транспорт до VPS: VLESS+REALITY] → VPS → [выходной туннель: WARP/WireGuard] → Internet
  • VLESS здесь — входной прокси-туннель, WARP — выходной L3-VPN: классификация компонентов не обязана совпадать с классификацией всей конструкции;
  • слои заменяемы по отдельности: завтра вместо VLESS — Hysteria2 на тот же VPS с тем же WARP-выходом; для верхнего слоя ничего не меняется;
  • «WireGuard внутри VLESS внутри TUN внутри роутера» — не противоречие, а композиция; вопрос только, зачем каждый слой и совместимы ли стыки (умеет ли следующий слой принять результат предыдущего).

MTU-матрёшка (Observed)

Каждая инкапсуляция добавляет заголовки — эффективный MTU падает. Для связки VLESS → WARP/WireGuard владельцем наблюдалось рабочее значение MTU 1200 — без уменьшения начинались проблемы с крупными пакетами/PMTU (наблюдение из практики, не универсальная константа; в VPS-проекте amnezia-mihomo-gateway измеренная пара — TCPMSS --clamp-mss-to-pmtu + mtu: 1420 для AWG+WARP).

Формат ≠ протокол

Ещё одна частая путаница из списков Mihomo/подписок:

  • .conf / .awg — формат конфигурации WireGuard/AmneziaWG, а не протокол;
  • HTTP(S)-подписка — формат доставки конфигурации, а не способ передачи трафика;
  • URL-схема (vless://, masque://) — сериализация параметров протокола для импорта.

Смешивать их с VLESS/QUIC в одном списке «протоколов» — категорийная ошибка.

Методология чтения схем: граф и зум

Для разбора многослойных схем удобны два приёма (методология, не стандарт):

  1. Ориентированный граф: вершины — узлы/интерфейсы/движки, рёбра — куда реально идёт трафик, веса — задержка/скорость/MTU, условия перехода — правила маршрутизации. Путь «клиент → exit» — в буквальном смысле путь в этом графе.
  2. Зум: у схемы нет единственно правильного масштаба. Вся инфраструктура сверху — Телефон → Mihomo → VPS → WARP → Internet; увеличиваем Mihomo — внутри правила и 500 outbound; увеличиваем outbound — внутри VLESS+REALITY+raw; увеличиваем VPS — внутри ещё один Mihomo, которому не нужно знать о первом.

Отсюда принцип отладки: вопрос «почему этот пакет пошёл сюда?» решается зумом в нужный узел, а не переописанием всей системы. И принцип экономии: «могу построить цепочку из N узлов» и «нужна цепочка из N узлов» — разные утверждения; лишние слои — лишние точки отказа, задержки и MTU.

Что подтверждено, а что нет

Confirmed:

  • официальное разделение Xray: транспортная конфигурация — вне прокси-протокола; категории transport method / security / extra; список методов raw|websocket|grpc|xhttp|mkcp|httpupgrade|hysteria; требование совместимости концов (Xray-docs-next, 2026-09-24);
  • REALITY — значение поля security, не отдельный протокол (там же);
  • SOCKS5: CONNECT/UDP ASSOCIATE (RFC 1928);
  • MASQUE: туннелирование поверх HTTP, CONNECT-UDP (RFC 9298), CONNECT-IP (RFC 9484), HTTP-датаграммы (RFC 9297), HTTP/3/QUIC рекомендован (RFC);
  • AmneziaWG: то же крипто-ядро WireGuard, обфускация Jc/Jmin/Jmax + H1–H4, совместимость со стандартным WireGuard без обфускации (docs.amnezia.org, 2026-09-24);
  • общее правило «каждая инкапсуляция уменьшает эффективный MTU» — стандартный сетевой принцип.

Observed:

  • MTU 1200 как рабочее значение для VLESS → WARP (практика владельца); mtu 1420 + --clamp-mss-to-pmtu как измеренная пара для AWG+WARP в amnezia-mihomo-gateway.

Research / без гарантий:

  • конкретные списки поддерживаемых протоколов sing-box/иных клиентов (источники сырья — сторонние обзоры; сверять с документацией конкретной версии);
  • поведение «selective REALITY» в деталях реализации — см. документацию link-generators/web4core;
  • количественные сравнения производительности транспортов — вне этой статьи.

Источники и provenance

  • Xray-docs-next (репозиторий исходников xtls.github.io): docs/config/transport.md — проверено 2026-09-24.
  • RFC 1928 (SOCKS5), RFC 9297 (HTTP Datagrams), RFC 9298 (CONNECT-UDP), RFC 9484 (CONNECT-IP).
  • docs.amnezia.org → AmneziaWG (2026-09-24).
  • saymer-alt/amnezia-mihomo-gateway — измеренные MTU/MSS-базлайны.
  • Raw-материал: proxy.md — исследовательский диалог (таксономия протоколов, цепочки, модель графа/зума); сам по себе не доказательство.

Связанные материалы