Сравнение VPN-протоколов · 2026
NaiveProxy vs Trojan-GFW
Сравнение двух VPN-протоколов с точки зрения работы в России 2026: транспорт, шифрование, устойчивость к ТСПУ, реальные сценарии использования.
NaiveProxy (Chrome's network stack proxy)
NaiveProxy
Прокси через настоящий Chrome network stack — JA3-fingerprint неотличим от браузера
паспорт протокола →Trojan-GFW (Trojan over TLS)
Trojan-GFW
VPN через TLS-туннель с реальным fallback HTTPS-сайтом — DPI не отличает
паспорт протокола →Вердикт для РФ 2026
Выбираем NaiveProxy
Не детектируется ТСПУ потому что fingerprint = настоящий Chrome (NaiveProxy линкуется с реальным Chromium-кодом, а не имитирует его). Требует server-side установки caddy-forwardproxy или nginx с naive-плагином. Конфиг сложнее, чем Reality, но устойчивость к active probing — одна из лучших на рынке.
Trojan-GFW: Работает в РФ. DPI видит обычный HTTPS-трафик к легитимному домену с реальным сертификатом. Неавторизованные запросы реально отдаются с web-сервера на том же порту.
сравнительная таблица
Параметры
| параметр | NaiveProxy | Trojan-GFW |
|---|---|---|
| Год | 2020 | 2017 |
| Транспорт | TCP, HTTP/2, HTTP/3 | TCP |
| Шифрование | TLS 1.3 / QUIC (родной Chrome) | TLS 1.2/1.3 (стандартный server cert) |
| Обфускация | Использует Chrome network stack — JA3 идентичен обычному Chrome-браузеру | Полный TLS-handshake с настоящим сертификатом; неавторизованные запросы проксируются на fallback HTTPS-сайт |
| Open-source | да | да |
| Статус в РФ 2026 | работает в РФ | работает в РФ |
NaiveProxy
плюсы
- + JA3-fingerprint полностью совпадает с обычным Chrome — DPI бессильно
- + Поддержка HTTP/3 (QUIC) — современный transport со всеми оптимизациями
- + Безопасен от active probing — сервер выглядит как обычный HTTPS-сайт
- + Минимум кастомного кода — основной weight на Chromium upstream, меньше bugs
- + Стабильность под нагрузкой — Chrome-стек проверен миллиардами браузеров
минусы
- − Сложнее в server-side настройке — нужен caddy с forwardproxy plugin или nginx-naive
- − Большой бинарник клиента — линкуется с Chromium net-кодом (десятки MB)
- − Меньшая гибкость по сравнению с xray/sing-box — нет shadow-стека, mux'инга
- − Поддерживается только в naiveproxy-клиенте, в мейнстрим-клиентах (NekoBox и т.п.) — нет
- − Server-stack нужно держать актуальным — устаревший Chromium может выдать характерный fingerprint
Trojan-GFW
плюсы
- + Использует настоящий TLS-сертификат (Let's Encrypt) — не distinguishable от обычного HTTPS
- + Fallback: неавторизованные запросы реально отдаются с веб-сервера на 443 порту
- + Прост в настройке: nginx + trojan-server, всё на 443 порту
- + Стабильная работа в Китае с 2017 года, в РФ — с 2022
минусы
- − Только TCP — на сетях с QoS на TCP может быть медленнее, чем UDP-протоколы
- − Нужен валидный домен и сертификат (бесплатно через Let's Encrypt)
- − Predesessor — менее активная разработка чем у Reality (но протокол стабильный)
Детали
NaiveProxy
NaiveProxy появился в 2020 году с радикально другой философией обхода блокировок: вместо того, чтобы имитировать обычный браузер, использовать его настоящий код. Клиент NaiveProxy линкуется с net-стеком Chromium (TLS, HTTP/2, HTTP/3, QUIC), и его JA3-fingerprint буквально идентичен Chrome той же версии — DPI не может отличить proxy-трафик от обычного браузинга. Server-side — обычный HTTPS-сайт на caddy или nginx с плагином naive: при правильном forward-токене он действует как proxy, без токена — отдаёт честный контент сайта (или 404). Это закрывает active probing: китайский GFW специально стучится на подозрительные endpoints, и большинство VPN-протоколов либо выдают характерный ответ, либо молчат необычно — NaiveProxy просто работает как сайт. В 2026 году NaiveProxy — выбор любителей максимальной маскировки, не подверженных influence фактором сложности настройки. Reality проще, но NaiveProxy всё ещё считается gold standard по неотличимости от браузера.
Где используется: Self-host для пользователей с фокусом на максимальную маскировку под повседневный браузерный трафик, защита от active probing, среды с агрессивным DPI (Китай, Иран, корпоративные firewalls).
Trojan-GFW
Trojan-GFW (Great FireWall) появился в 2017 году как ответ на блокировки в Китае. Идея: вместо имитации TLS-handshake (что делают Cloak, V2Ray-TLS), Trojan использует НАСТОЯЩИЙ HTTPS-сервер. Клиент устанавливает TLS-сессию с реальным доменом и сертификатом, и только после успешного TLS-handshake отправляет ключ-пароль (32 байта в начале первого application-data пакета). Если ключ совпадает — соединение проксируется в VPN; если нет — соединение перенаправляется на fallback HTTPS-сервер (обычно nginx с реальным сайтом). Снаружи это выглядит как обычный HTTPS-трафик: те же сертификаты, те же TLS-параметры, тот же ответ от веб-сервера для случайных подключений.
Где используется: Self-host VPN с минимальной настройкой. Хорошая альтернатива Reality для тех, у кого уже есть HTTPS-сервер.