Технические детали

Как устроен Qeli

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

Что изменилось в 0.8.2: конфигурация, восстановление сети и Linux TUN →

Как работает соединение

Установка соединения шаг за шагом

При закреплённом ключе сервер подтверждает свою подлинность до того, как клиент отправит пароль. Порядок шагов важен для безопасности; при TOFU первое подключение нужно проверить отдельно.

1

Знакомство

Клиент ⇄ Сервер

Соединение начинается через выбранный транспорт: plain использует голый X25519, остальные режимы — TLS-shaped или настоящий TLS с гибридным key share.

2

Отпечаток

внутри

Подлинность привязана к хешу всего рукопожатия — подмена ломает соединение.

3

Сервер → клиент

Сервер → Клиент

Сервер доказывает владение ключом, клиент сверяет с закреплённым — до отправки пароля.

4

Вход клиента

Клиент → Сервер

По защищённому каналу — логин и пароль; проверка Argon2id и доступ по профилю.

Передача данных

Клиент ⇄ Сервер

Каждый пакет шифруется и уходит в выбранном транспорте — HTTPS, WebSocket или QUIC-shaped UDP.

Транспортные режимы

Один протокол — шесть транспортных режимов

Режим определяет форму трафика и задаётся согласованной парой параметров профиля и клиента. Установщик по умолчанию разворачивает reality-tls; встроенный дефолт конфига — fake-tls. Остальные режимы подходят для доверенных сетей, совместимости и резервных каналов.

Настройки и готовые профили всех режимов →
флагманTCP · TLS 1.3

Настоящий TLS 1.3

reality-tls · браузерный TLS 1.3 (realtls)

Главный режим Qeli: клиент шлёт браузерное рукопожатие TLS 1.3 (отпечаток JA4 t13d1516h2_8daaf6152771), а сервер терминирует настоящий TLS 1.3 (realtls) и несёт туннель внутри. На проводе это настоящий TLS 1.3, а не имитация; внутри идёт туннель qeli, а доверие строится на закреплённом ключе сервера. Работает на Linux, Android, iOS, Windows и macOS через общий realtls-движок.

Сервер заимствует настоящий сертификат целевого сайта — даже активный пробер видит легитимный TLS, как у Xray-REALITY.
в трафике ClientHello (Chrome JA4) → TLS 1.3 (realtls) зашифрованный flight → туннель внутри настоящего TLS
  • Настоящее рукопожатие TLS 1.3 с отпечатком JA4 браузера Chrome
  • Сервер терминирует TLS (realtls), туннель идёт внутри
  • Единый realtls-движок на всех клиентах (Linux, Android, iOS, Windows, macOS)
1212 ↑ / 1066 ↓ Мбит/с · TCP P=4, IPv4 · Recordizer
Отчёт 0.8.0 · 01.09.2026
для доверенных сетейTCP · базовый

Базовый туннель — plain

plain · голый шифрованный туннель

Сырой обмен X25519 и голые записи [len][nonce][ct] — никакой TLS-обёртки и лишних слоёв. Самый быстрый и дешёвый по CPU режим (≈ как fake-tls по скорости). Нужен там, где дополнительный транспортный слой не требуется: доверенная сеть, внутренний канал. Только TCP.

в трафике обмен X25519 → [len][nonce][ct] · без TLS-обёртки
  • Максимальная скорость, минимум накладных расходов
  • Без дополнительного транспортного слоя — это базовый туннель
1705 ↑ / 1689 ↓ Мбит/с · TCP P=4, IPv4 · Recordizer
Отчёт 0.8.0 · 01.09.2026
запасной · лёгкийTCP · уровень 1

TLS-совместимый транспорт

fake-tls · TLS-совместимый

Соединение начинается с рукопожатия в формате TLS 1.3: клиент шлёт ClientHello с именем сайта (SNI), гибридным X25519MLKEM768 key share и GREASE-значениями. Порядок TLS-расширений рандомизируется. Дальше данные идут в TLS-записях типа Application Data; это TLS-shaped framing, не настоящий TLS.

в трафике ClientHello · SNI · X25519MLKEM768 · GREASE порядок расширений рандомизирован данные → TLS record 0x17 (application_data)
  • Данные передаются в TLS-записях
  • Порядок TLS-расширений рандомизирован
  • Минимальная структура — почти нет накладных расходов
1752 ↑ / 1695 ↓ Мбит/с · TCP P=4, IPv4 · Recordizer
Отчёт 0.8.0 · 01.09.2026
дополнительное шифрованиеTCP · уровень 2

Дополнительное шифрование (obfs)

obfs · дополнительный криптослой ChaCha20

Весь поток дополнительно шифруется потоковым ключом ChaCha20 на общем секрете (PSK). Начало оформлено как рукопожатие WebSocket Upgrade: клиент шлёт GET … Upgrade: websocket, сервер отвечает 101 Switching Protocols с Sec-WebSocket-Accept. Путь, Host, User-Agent и ключ рандомизированы.

в трафике GET /<rand> HTTP/1.1 · Host/UA/key рандом Upgrade: websocket → 101 Switching Protocols далее: поток ChaCha20 XOR
  • Начало совместимо с WebSocket — печатаемый HTTP-текст
  • Дополнительный слой ChaCha20 поверх основного шифрования
  • Лимит потока — 256 ГиБ на направление, затем безопасный реконнект
1256 ↑ / 1293 ↓ Мбит/с · TCP P=4, IPv4 · Recordizer
Отчёт 0.8.0 · 01.09.2026
разделение портаTCP · уровень 3

Разделение порта (reality)

reality · разделение порта

Сервер криптографически опознаёт свой клиент по токену в session_id ClientHello. Неопознанные подключения перенаправляются на указанный хост. Токен представляет собой AEAD-шифротекст (short_id, timestamp), связанный с DH-обменом. В режиме reality-tls поверх прокси-слоя добавляется терминирование настоящего TLS 1.3 (realtls).

в трафике токен в session_id → опознан → туннель нет токена → перенаправление на целевой хост
  • Неопознанные подключения перенаправляются на сторонний хост
  • Опознание криптографическое, защита от повторного воспроизведения
  • Доступен режим с настоящим TLS 1.3 (reality-tls)
1741 ↑ / 1705 ↓ Мбит/с · TCP P=4, IPv4 · Recordizer
Отчёт 0.8.0 · 01.09.2026
UDPUDP · уровень 2

UDP в QUIC-shaped форме

quic · UDP с QUIC-shaped Initial

Qeli оформляет UDP-датаграмму в строго заданной форме QUIC v1 Initial: байт 0xC3, версия 1, четырёхбайтовый DCID, пустые SCID и token, объявленная длина и четырёхбайтовый номер пакета. Это QUIC-shaped формат, а не полноценная реализация QUIC: здесь нет QUIC Initial AEAD, header protection, CRYPTO frames и обязательного padding до 1200 байт.

в трафике [0xC3][version=1][DCID:4][SCID:0][token:0] [length][packet number:4][qeli payload]
  • Новые пакеты используют точную форму qeli Initial с байтом 0xC3
  • Парсер проверяет все длины и полное потребление датаграммы
  • Для rolling upgrade принимается только историческая форма 0xE3
491 ↑ / 520 ↓ Мбит/с · TCP P=4, IPv4 · Recordizer
Отчёт 0.8.0 · 01.09.2026
Безопасность

Криптография и честная защита

Современный криптостек: гибридный X25519 + ML-KEM-768 во всех режимах, кроме plain, эфемерные ключи, шифрование с проверкой целостности и настоящий TLS в reality-tls. Вот что содержится в пакете data plane.

заголовоктранспорт
nonce12 байт · псевдослучайный
зашифрованные данные + тегChaCha20-Poly1305
паддингслучайный

Так выглядит пакет data plane. Во всех режимах, кроме plain, ключи выводятся из гибридного X25519 + ML-KEM-768 через HKDF-SHA256; plain использует классический X25519. Данные защищает ChaCha20-Poly1305, пароли — Argon2id. В reality-tls пакет дополнительно идёт внутри TLS 1.3 с AES-GCM 128/256.

X25519 X25519MLKEM768 · кроме plain ChaCha20-Poly1305 Argon2id reality-tls · TLS 1.3 (Chrome JA4) Channel-binding Ключ на каждый профиль

Безопасность и надёжность

Защита ключа сервера, разграничение доступа, защита от подбора пароля и устойчивость к сбоям — встроены в протокол.

Защита подключения

  • Закрепление ключа сервераклиент пиннит ключ — подменный сервер не пройдёт
  • Привязка к рукопожатиюподмена данных в канале рвёт соединение (анти-MITM)
  • Обязательная проверка ключаклиенты без ключа отклоняются, ключ скрыт от сканеров

Доступ и атаки

  • Раздельный доступпрофили изолированы — чужой профиль недоступен
  • Защита от подбора пароляблокировка «пользователь + адрес», пароли на Argon2id
  • Защита от усиления атакответ ограничен ~3× от запроса — сервер невыгоден как DDoS-усилитель

Надёжность связи

  • Автопереподключениепри смене Wi-Fi и мобильной сети клиент сам переподключается за секунды
  • Устойчивый к сбоям DNSинтернет не пропадает после падения программы
  • Скрытый счётчик пакетовпоследовательный счётчик не виден на проводе
Qeli 0.8.2 · Linux · 19.10.2026

Новые замеры готовой сборки

Intel i5-8500; две VM по 2 vCPU / 2 ГиБ. На обоих концах один готовый Linux ELF; Recordizer required и PACKET_MUX_V1 активны. Внешний IPv4, MTU 1500/1400, очереди клиента/сервера 1000/1000.

TCP P=1: один поток внутри туннеля

Мбит/с на приёмнике. Каждая ячейка — медиана трёх прогонов по 15 секунд с исключением первых трёх. Последний столбец — среднее четырёх медиан. ↑ отдача, ↓ загрузка. Название UDP-профиля обозначает транспорт туннеля, а не тип тестового трафика.

Транспорт туннеляIPv4 ↑IPv4 ↓IPv6 ↑IPv6 ↓Среднее
TCP FakeTLS1975,012205,102006,702170,342089,29
TCP Reality-TLS1124,951059,831142,851067,031098,66
UDP FakeTLS1135,561329,651163,331323,541238,02
UDP QUIC1165,951267,631192,201282,991227,19

При неограниченном TCP сохранялись повторные передачи и сбросы TUN. Процент потерь TCP не измерялся. Это лабораторный результат, не гарантия скорости на любом VPS.

UDP: нагрузка 600 Мбит/с

Во всех 48 окнах четырёх профилей — ноль потерь приёмника и сбросов TUN клиента/сервера. IPv4/IPv6, отдача/загрузка, три повтора. Это отдельная последовательная серия, не одновременный TCP/UDP-тест.

UDP: отдельные замеры 900/950

Внутренний IPv6 upload: FakeTLS — 899,57 Мбит/с при заданных 900, QUIC — 949,46 при 950. Медиана потерь: 0,005329% и 0,000471% соответственно. Ноль TUN drops не означает ноль сквозных потерь.

UDP измерялся при фиксированной нагрузке, без поиска потолка. Эти TCP P=1 результаты нельзя подставлять в сравнительный график TCP P=4 версии 0.8.0 ниже: другие VPN в этой серии не тестировались.

Методика и ограничения · TCP JSON · UDP JSON
Data plane · новое в 0.8.1

UDP batching: меньше системных вызовов, тот же wire format

Linux и Android группируют уже готовые UDP-датаграммы в bounded-пачки до 32 через recvmmsg/sendmmsg. Таймер накопления не добавляется; порядок, roaming, pacing, фрагментация и PMTU fallback сохраняются.

01

Upload: 320,8 → 694,7 Мбит/с

Медиана чередующегося same-window A/B на двухъядерном стенде: +116,5%.

02

Download: 359,8 → 697,5 Мбит/с

На том же стенде и окне измерения: +93,9%.

03

Ниже относительная нагрузка CPU

−13,2% у upload-клиента и −7,9% у server download worker.

04

Отдельный релизный A/B

Этот узкий тест проверяет конкретную оптимизацию. Полный сравнительный benchmark 0.8.0 с 34 режимами сохранён ниже без изменения цифр.

Результат относится к конкретной двухъядерной лаборатории и не является обещанием одинаковой скорости на любом VPS, телефоне или сетевом пути. Методика и полный контекст релиза 0.8.1 →

Benchmark · 1 сентября 2026

Qeli 0.8.0: полный dual-stack прогон

Полный прогон охватывает 34 режима на одном стенде: две Debian VM с 2 vCPU и 2 GiB RAM, iperf3 3.18, MTU 1400, IPv4 и IPv6. Ниже отдельно показаны профильные результаты Qeli и сравнение транспортов с одинаковым уровнем маскировки.

01

Один стенд

Две Debian VM: по 2 vCPU и 2 GiB RAM, одинаковый сетевой путь, iperf3 3.18 и MTU 1400.

02

TCP без случайного пика

Четыре параллельных потока, три повтора. В таблице используется медиана, поэтому единичный удачный прогон не определяет результат.

03

IPv4 и IPv6

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

04

Раздельные категории

Полностью маскируемые режимы сравниваются между собой. Частичная и отсутствующая маскировка показаны отдельно как контроль.

TCP P=4 · медиана трёх прогонов · IPv4

отдача (Мбит/с) загрузка (Мбит/с)
plainraw + recordizer
fake-tlsrecordizer
realityrecordizer
obfsrecordizer
reality-tlsrecordizer + H2

Все показанные профили Qeli 0.8.0 работали с обязательным PACKET_MUX_V1. Это медианы трёх TCP P=4-прогонов IPv4; значения IPv6 и все 12 профилей приведены в подробной таблице.

Средний найденный UDP ceiling по группам Qeli

IPv4/IPv6 и отдача/загрузка · Мбит/с
быстрые TCP-профили
тяжёлые TCP-профили
нативные UDP-профили

UDP ceiling — максимальная найденная предложенная скорость с успешным окном при потерях не более 1%. Это среднее четырёх направлений rep1; pass/n и медиана потерь каждого профиля доступны в полном отчёте.

Qeli 0.8.0: результаты всех 12 профилей

Все значения — Мбит/с, порядок в ячейке: отдача / загрузка. TCP P=4 — медиана трёх прогонов; UDP — найденный rep1 ceiling.

ПрофильTCP P=4 · IPv4TCP P=4 · IPv6UDP ceiling · IPv4UDP ceiling · IPv6
tcp-plain-raw + Recordizer1705 / 16891825 / 18071300 / 14501350 / 1425
tcp-faketls + Recordizer1752 / 16951823 / 18201225 / 14001300 / 1475
tcp-padding + Recordizer1751 / 16831841 / 17991175 / 14501325 / 1500
tcp-frag + Recordizer1774 / 16841834 / 18001350 / 14251250 / 1500
tcp-obfs + Recordizer1256 / 12931371 / 1386925 / 1200925 / 1200
tcp-reality + Recordizer1741 / 17051834 / 17861275 / 14001275 / 1450
tcp-reality-tls + Recordizer1212 / 10661219 / 1074925 / 1125975 / 1200
udp-faketls + Recordizer484 / 528458 / 507350 / 450325 / 450
udp-padding + Recordizer499 / 513468 / 512375 / 450375 / 500
udp-quic + Recordizer491 / 520473 / 506350 / 475325 / 475
tcp-obfs-awg + Recordizer1312 / 13001407 / 1389875 / 1175875 / 1175
udp-faketls-awg + Recordizer479 / 509479 / 515375 / 450350 / 475

Все 12 профилей Qeli использовали обязательный PACKET_MUX_V1; runtime подтвердил маркер PACKET_MUX_V1 active ... policy=required. Поэтому они относятся к группе с полной маскировкой. TCP-тест повторён трижды; полный отчёт содержит pass/n, медиану потерь, CV, CPU, RSS и kernel drops.

Как оценивается маскировка: форма рукопожатия, размеры и границы записей, интервалы и пакетирование, а также ответ на активную проверку. Это описание работающих механизмов, а не обещание «невидимости для DPI».

Отчёт и воспроизводимостьполный отчёт
Интерпретация

Что видно из результатов

  • Пять быстрых TCP-профилей Qeli образуют плотную группу около 1,7–1,8 Гбит/с; IPv6 не показывает заметного штрафа.
  • obfs, reality-tls и связка obfs + AWG меняют больше признаков внешнего трафика, но требуют больше вычислений.
  • UDP-транспорты нужно оценивать отдельно: их ceiling измеряет устойчивую предложенную нагрузку при потерях не более 1%.
Границы вывода

Чего этот тест не доказывает

  • Результат стенда не гарантирует ту же скорость на другом VPS, маршруте или процессоре.
  • Высокая пропускная способность не является оценкой стойкости к блокировкам или безопасности протокола.
  • Контрольные режимы без маскировки показывают масштаб производительности, но не участвуют в честном рейтинге маскируемых транспортов.
1767 Мбит/с
Среднее TCP P=4 быстрых TCP-профилей Qeli
1365 Мбит/с
Средний UDP ceiling быстрых TCP-профилей
409 Мбит/с
Средний UDP ceiling нативной UDP-линейки

Продуктовый агрегат всех 12 Qeli-профилей — 1220 Мбит/с TCP P=4. Dual-stack gate пройден в 19 из 19 случаев, runtime-маркер обязательного recordizer получен для 12 из 12 Qeli-профилей. Дрейф прямого baseline после матрицы: +1.48% на отдачу и −1.71% на загрузку. CPU и RSS измерялись отдельно для VM и набора процессов; полные таблицы доступны в отчёте.

Сопоставимые режимы и контроль

Сравнение скорости при разном уровне маскировки

В основном рейтинге собраны транспорты, которые полностью меняют узнаваемые признаки VPN-трафика. Серые полосы показывают два быстрых контрольных режима без маскировки, а Hysteria 2 QUIC TLS отмечена как частично маскируемый режим. Скорость каждого варианта — среднее отдачи и загрузки по IPv4 и IPv6 в TCP-тесте с четырьмя параллельными потоками.

Серые полосы нужны только для масштаба. WireGuard plain показывает нативный kernel dataplane, а OpenVPN UDP + DCO переносит data channel в ядро. Они могут быть быстрее именно потому, что не маскируют трафик, поэтому это не прямая победа над защищёнными конфигурациями.

Средняя TCP-скорость · IPv4 и IPv6

WireGuard plainбез маскировки · kernel baseline
AmneziaWG full 3.1
OpenVPN UDP + DCOбез маскировки · kernel offload
Qeli fast TCP + Recordizer
Qeli · 12 профилей
Hysteria 2 QUIC TLSчастичная маскировка
Xray VLESS REALITY Vision
Hysteria 2 Salamander
WireGuard + wg-obfuscator STUN
OpenVPN TCP + Cloak

Серые полосы — контрольные варианты без маскировки: WireGuard plain 3161 Мбит/с и OpenVPN UDP + DCO 1900 Мбит/с. Hysteria 2 QUIC TLS 1134 Мбит/с имеет частичную маскировку. Среди режимов с полной маскировкой AmneziaWG full 3.1 показал 2820 Мбит/с, Qeli fast TCP + Recordizer — 1767 Мбит/с, а агрегат 12 Qeli-профилей — 1220 Мбит/с.

Сравнение возможностей

Возможность WireGuard AmneziaWG OpenVPN Shadowsocks Xray/VLESS Hysteria 2 Qeli
Нативный IP-туннель (L3)дададапроксипроксипроксида
TCP P=4, Мбит/с3161 plain · без маскировки
510 wg-obfuscator STUN		2820 full 3.11900 UDP + DCO · без маскировки
453 TCP + Cloak		не измерялся997 REALITY Vision1134 QUIC TLS · частично
760 Salamander · маскировка		1767 fast TCP
1220 12 профилей
Приватный транспортнет★★★нет★★★★★★★★★★★★★★★
Несколько транспортных режимовнетодиннетплагины★★★★частично★★★★ plain / fake-tls / obfs / reality / reality-tls / quic
Настоящий TLSнетнетреальный TLSчерез плагинTLS + REALITYпод HTTP/3да reality-tls · Chrome JA4
Встроенная панель управлениянетприложениенетнетнетнетда
Защита от подбора паролянетнетплагиннетнетнетда
Закрепление ключа сервераключ узлаключ узласертификатпарольдасертификатда
Раздельный доступ по профилямнетнетнетнетчастичнонетда
Несколько профилей в одной службенетнетнетнетданетда
Работа в ядре системыдаданетнетнетнетнет
Независимый аудит безопасности★★★★★★★★★★★★★★★нет
Постквантовая криптографиянетнетнетнетнетнетда во всех режимах, кроме plain

Настройка — единый текстовый формат

Один формат настроек для сервера, клиента и списка пользователей. Настройки клиента — это та же ссылка для подключения и QR-код.

настройки клиента
# минимальный набор настроек
[qeli]
server = vpn.example.com:443
proto  = tcp
mode   = obfs
front  = websocket
obfs_key = ОБЩИЙ-СЕКРЕТНЫЙ-КЛЮЧ
user   = alice
pass   = ••••••••
# закреплённый ключ сервера
key    = 33f399e6…d532450
ссылка для подключения
# одна ссылка → QR-код → импорт в клиент
qeli://alice:pass@vpn.example.com:443
  ?proto=tcp
  &mode=obfs
  &front=websocket
  &obfs=ОБЩИЙ-СЕКРЕТНЫЙ-КЛЮЧ
  &sni=www.google.com
  &key=33f399e6…d532450

# создаётся в панели управления или командой:
$ qeli add-client alice --link --host vpn.example.com:443
← Вернуться к обзору продукта