Сам факт подключения к серверу VPN может быть виден — и это нормально, с этим просто надо грамотно обращаться. В условиях когда собирается больше входных данных на ТСПУ это остаётся чуть ли не единственным максимумом который определяет сколько проживет лично ваш айпи адрес и VPN.

🧿 Включите Kill Switch и/или Always VPN. Если туннель отвалится, трафик должен блокироваться, а не тихо уходить напрямую. Без этого вы оголяетесь именно в момент сбоя — а сбои теперь будут чаще.
🧿 Если ваш VPN не умеет нормально вести IPv6 внутри туннеля, он должен жёстко блокировать IPv6 снаружи. Иначе часть трафика поедет мимо — ровно то, что новая система и призвана подсветить.

🧿 Полный VPN (TUN) на весь компьютер заворачивает в туннель вообще всё. Это удобно и безопаснее по утечкам, но выглядит как один большой стабильный поток к одному серверу — такую цель проще заметить. Не используйте это если хотите жить дольше.

Прокси / socks / vless (в режиме noTUN) / выборочный туннель (только нужные приложения) дробит трафик и иногда живёт дольше, потому что не выглядит как один гигантский туннель на весь ПК. Но тут выше риск утечек: часть приложений, DNS и IPv6 могут пойти мимо. Но это лучшее что может сделать именно клиент.

Если абонент 90% времени и трафика ходит на один внешний IP, который не похож на сайт/CDN/обычный сервис, то это может быть VPN-endpoint.

Главная задача ТСПУ — не заблокировать, а — найти такую найти статистическую аномалию — ДОКАЗАТЬ что это действительно аномалия — ПЕРЕПРОВЕРИТЬ что это VPN — и только после всех шагов рубануть его или навсегда или поставить cooldown на N-ое время по своим таймингам алгоритмов.

Типичные признаки будут такими:
🧿 этот абонент почти всё время льёт трафик на один странный IP
🧿 много других абонентов тоже ходят на этот же IP
🧿 IP находится в датацентре
🧿 на нём нет нормального публичного сайта
🧿 поведение (но это уже определяет протокол, а не пользователь или сервер — vless + xHTTP и vless + TCP RAW ведут себя по разному) похоже на туннель

И дальше этот IP можно считать кандидатом в VPN endpoint. Если у пользователя белый индивидуальный IP то это вообще теперь смерти подобно. Лучше сидеть за NAT с серым IP.

ТСПУ всё равно будет собирать теперь

source IP
source port
destination IP
destination port
protocol
time
volume
duration
SNI/TLS признаки, если видны
QUIC/UDP признаки

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

Да будут ложные срабатывания. Ведь кроме ВПН такой паттерн трафика создают и:

корпоративный VPN
VDI / удалённый рабочий стол
игровой сервер
облачный backup
стриминг через конкретный CDN edge
Cloudflare WARP / ZTNA
прокси компании
личный VPS
туннель разработчика

Но специалисты уже знают как расшифровывать MTproxy без FakeTLS. Немудрено что и на других протоколах есть другие более эффективные способы. У нас просто нет столько логов и обучаемых данных — у них есть.

В любом случае — Per-app proxy или split proxy может выглядеть менее монолитно.

☺️ Скачать | ☺️ Premium (донаты) | ☺️ Android, MacOS и др. ссылки

Что делать пользователями VPN-проектов, мы не знаем, никто не знает, ведь любые блокировки раскатываются тихо, не спеша, ни шиша и так далее. Никто не приходит к нам в нашу уютную квартиру и говорят, и докладывают, что вот, значит, мы блокируем вот это, тогда-то, с таким-то анализом и паттерном на таких-то портах, если за такое-то количество времени происходит энное количество пакетов с такой периодичностью на таком-то протоколе. Никто этого не знает. И если мы этого не знаем, мы можем только отгадывать, искать пути решения и экспериментировать на себе, ну и на других людях, если они это, конечно, позволяют.

Победить в этой войне легко. Проблема не в том, чтобы победить. Проблема в том, чтобы найти пути решения того, что считается победой. Ведь если ты не знаешь, как победить, как бы странно это ни звучало, ты не победишь. И это основная проблема. обычно сейчас есть много дырок в заборе, которые видны, но с каждым разом они сужаются и становятся все менее заметными, и нужно всё больше опыта и всё лучшее зрение, чтобы эти дырки в заборе найти. А они, поверьте, будут всегда.

ТСПУ ловит туннель тремя способами: по L4-сигнатуре протокола (фиксированная форма пакетов), по TLS/SNI/сертификату на этапе хендшейка, и по поведению/статистике (длинный монолитный поток к одному IP в ДЦ). Приказ №51 добивает четвёртый вектор — корреляцию (какой пул/регион/ТСПУ/IPv4+IPv6 → какой внешний IP). Любая настройка в клиенте — это попытка сломать один из этих четырёх.

Голый WireGuard / OpenVPN / Shadowsocks — самые палевные. WG детектится тривиально по фиксированной форме: handshake initiation — это ровно 148 байт payload, начинающихся с 0x01000000 (response — 92 байта 0x02…, cookie — 64 0x03…). Это буквально то, что DPI и матчит по udp length 156 @ih,0,32 0x01000000. Никакие «настройки» это не лечат — форма пакета и есть подпись.

AmneziaWG (AWG) — тот же WG, но с разломанной подписью. Параметры Jc/Jmin/Jmax (мусорные пакеты до хендшейка), S1/S2 (добивка размеров init/response) и H1–H4 (подмена тех самых магических заголовков 0x01/02/03/04) ломают фиксированную длину и сигнатуру — DPI больше не видит «канонический WireGuard». Работает хорошо, но в регионах с особо жёсткой фильтрацией AmneziaWG иногда не заводится, и тогда переходят на VLESS+Reality.

VLESS + XTLS-Reality — текущий золотой стандарт. Он не шифрует «по-впновски», а маскирует трафик под обычный веб-трафик, делегируя защиту на TLS/Reality; заблокировать весь TLS на 443 нельзя, иначе ляжет весь интернет, поэтому остаётся бан по IP или статистические эвристики.

DPI сравнивает предъявленный сертификат с реальным сертификатом сайта в SNI — если они совпадают, отличить от настоящего сайта нельзя. dest/SNI должен указывать на реальный, доступный сайт, желательно живущий рядом с твоим сервером по IP-пространству.

17 февраля 2026 РКН резко усилил блокировку TLS 1.3 на базе которого работают все сайты у REALITY (для маскировки), поэтому пока что лучше держатся VLESS с транспортом XHTTP или gRPC, Hysteria2 (если конечно пока нет полного блока QUIC) и конфигурации с маскировкой через CDN и т.д.

RPRX (разработчик Xray) фактически объявил, что в 2026 голый незашифрованный трафик через впн-протоколы на публичных портах будет вне закона — то есть «VLESS без TLS на 80 порту» как временный трюк уходит.

Если self-hosted (свой VPS через 3x-UI): dest/SNI на CDN или хотя бы из той же подсети (либо создать свой сайт заглушку), ротация IP, ЖЁСТКАЯ (потому что есть подпольные сайты РКН для тестов которых нет в списках) блокировка любых RU-сайтов, разнести control-plane и exit айпи ноды и пр.

☺️ Скачать | ☺️ Premium (донаты) | ☺️ Android, MacOS и др. ссылки

Когда-то было замечено что ТСПУ блокирует любые ЧУЖИЕ dest, но не блокирует если не чужое (а что это такое додумайте сами — это направление мало кто изучал).

Видно что система ТСПУ состоит из 3, 4 а то и 5 стен которые работают по разному + у них есть свои триггеры которые иногда палятся и мы их замечаем. В этот момент они усиливают блокировки или активно мониторят траффик абонента.

Блока vlessa всё ещё пока не случился. И маловероятно что случится. Случится скорее блок одного из компонентов его шифрования, что можно будет быстро заменить на другой. Архитектурный его блок пока невозможен ввиду того что протокол без шифрования и полностью чистый сам по себе (никак себя не усложняет).

Например один из таких примеров "взлома" — недавно обнаружили то, что между TLS фингерпринтом настоящего Chrome и фингерпринтом uTLS была разница, что позволяло определить то, что это не TLS настоящего Chrome. Теоретически, это можно детектить. [URGENT] Maybe uTLS is reusing the same x25519EphemeralKey for both X25519MLKEM768 and X25519, unlike Chrome · Issue #342 · refraction-networking/utls · GitHub

Вскоре это пофиксили, и обновление с патчем уже есть в sing-box 1.12.10 и Xray-core v25.10.15.

Баг с TLS 1.3 вроде тоже пофиксили (это вам не Дуров со своим кривым мтпрокси).

🧿🧿🧿🧿🧿🧿🧿

В зонах с поведенческим порогом по ip:port логика переворачивается: вместо Vision (он с mux несовместим) → включаете mux → число TLS-соединений на ip:port падает ниже порога → динамический блок не срабатывает. Цена — вылезает tls-in-tls и растёт задержка..

Было и "убийство" xtls-rprx-vision по сигнатуре. Там, где TLS 1.3 в целом жив, ТСПУ научился ловить именно Vision: часть его параметров была захардкожена в ядре, и по ним строится сигнатура. Патч на рандомизацию готовится, но пока Vision — самый палевный элемент связки.

TLS fragment (если клиент умеет) — режет ClientHello, чтобы DPI не собрал SNI. По сути это клиентский аналог split из zapret, только внутри туннеля.

Вообще давно уже у нас в головах гуляет идея что использование ВПН с запретом создает НЕ-ВЫ-НО-СИ-МУ-Ю головную боль у цензоров и маловероятно что это можно победить хоть как-то кроме введением белых списков на проводе.

🧿🧿🧿🧿🧿🧿

Главный смысл каскада (сети типа Tor из цепочки узлов) против новой адресной карты:
— К выходному зарубежному IP в дата-центре пользователь напрямую не подключается — для ТСПУ и корреляционной карты видно лишь соединение к входному узлу.
— Если входной узел — на нейтральном или внутреннем IP, то связка российский пул → подозрительный зарубежный DC-IP, которую приказ №51 как раз и строит, не складывается так очевидно.
— Выходной IP можно менять, не трогая то, что видит пользователь.

Расплата: каждый лишний хоп — это tls-in-tls и задержка. Vision-сплайс (когда ядро Linux напрямую пробрасывает TLS 1.3 мимо памяти Xray) полноценно работает только на последнем хопе; через транзитный узел вы почти неизбежно получаете вложенный TLS, и его надо прикрывать mux + аккуратными таймингами.

И это только часть того что можно сделать. Это даже не 20% того что есть. Многое не разглашается в широкие массы или было упомянуто лишь в одном сообщении на каком-то NN-форуме.

Введут ли 52 приказ. Или 53 — смысл не меняется. Всё что можно собирать уже собирается и дальше начинается война умов и терпения на выдержку и истощение.

☺️ Скачать | ☺️ Premium (донаты) | ☺️ Android, MacOS и др. ссылки

В идеальных тепличных устройствах Zapret должен стоять на роутере при входе в помещение — чтобы все нужные пакеты дурить на всех устройствах без впн.

Тогда ваш дорогой vless будет под защитой Запрета. И векторы атак значительно уменьшатся. А скоро у запрета будут таймеры — а значит можно отправлять много много мусора на нужный адрес чтобы имитировать то что нужно ТСПУ.

Расширение инструкций по мере необходимости всегда будет тут.

☺️ Скачать | ☺️ Premium (донаты) | ☺️ Android, MacOS и др. ссылки

Вы не поверите. Но лёг. Российский. VPS. Сегмент.

Да частично. Но лёг. А за последние месяцы различные хостинги пишут о "неизвестных" DDoS-атаках.

☺️ Скачать | ☺️ Premium (донаты) | ☺️ Android, MacOS и др. ссылки

В этот раз РКН постарался на славу.

Кажется ТСПУ не справились с DDoS атаками 😣

Увы.

На удивление это совпало с новыми блокировками и последними новостями о магистральных ТСПУ.

Не стоит сомневаться что сейчас вкрутили что-то что опять сработало криво и заблокировало даже то что не следует блокировать.

Например у нас начались проблемы с EU-инфраструктурой. Буквально вчера всё работало исправно.

☺️ Скачать | ☺️ Premium (донаты) | ☺️ Android, MacOS и др. ссылки

И на удивление интернет ожидает только в одном случае. Вы не поверите (нет серьезно) — вы даже не представляете когда всё начинает работать.

Когда фильтры Zapret работают на все сайты и закидывают ТСПУ фейками.

Всё. Это единственный способ починить себе интернет — закидать фейками ТСПУ.

Сказать что это иррационально ничего не сказать.

Оборудование которое должно защищать от закидывание любыми фейками падает именно тогда — когда надо защищать.

Если это не кривое зеркало ТО ЧТО ЭТО тогда?

☺️ Скачать | ☺️ Premium (донаты) | ☺️ Android, MacOS и др. ссылки

Мда уж мда уж 🚬🚬🚬

Как же быть.

В комментариях — только неправильные ответы.

☺️ Скачать | ☺️ Premium (донаты) | ☺️ Android, MacOS и др. ссылки

Левый — коронный, правый — похоронный

Правда это выскакивает только если вы в нём зареганы. Ведь как известно БД ВК и Max — одно и тоже.

Стоп а как мне порнуху смотреть 😵😵😵

☺️ Скачать | ☺️ Premium (донаты) | ☺️ Android, MacOS и др. ссылки

По невероятным стечениям самых тупых обстоятельств кто-то до сих пор сидел с голым multisplit (то ли это копирки от flowseal то ли кто-то в интернет закинул готовый вариант стратегии для ютуба и копипастеры подсели всех на это).

Это всё ещё не победа РКН, не супер обновление. А просто небольшое изменение алгоритмов которые уже давным давно надо было сделать не на части регионов — а раскатать на всю страну. Видимо до этого тестировали как обычно их только в Сибири.

Мы также увидели что борьба с Zapret и с VPN (пока что в основном только с протоколами проекта xray core) происходит отдельно. Ведь 2 дня назад упал HandShake TLS/XHTTP/TCP RAW и прочее, а также Chrome. А сегодня Zapret.

Естественно "голый" сековл не самая лучшая идея. Аналогично в byedpi с одиночным параметром --oob 1.

Конечно от версии Zapret логика multisplit не зависит, но технологически возможностей у Zapret 2 для multisplit больше.

Другая проблема в том что ТСПУ у многих уже ютуб блокирует так что и multisplit целиком не работает, ведь порядок пакетов уже давно собирается как бы их не перекрывали.

☺️ Скачать | ☺️ Premium (донаты) | ☺️ Android, MacOS и др. ссылки

Пишут ещё что MTProxy сломали но там такой кривой протокол что там ломать не переломать. Бездари из РКН не сделали что-то уникальное.

Сигнатуры MTProto до сих пор может отслеживать даже обычный запрет, чего уж говорить про большую государственную команду. Определяется через AES дешифровку — проверяется магическая сигнатура 0xEFEFEFEF которую никуда не убрали.

Другое дело что скорее всего речь идёт не про ee режим с FakeTLS. И кажется не про teleproxy. А на голом MTProxy без дополнительной обфускации. Но что на самом деле сломали, мы не знаем, потому что никто анализ нормально не проводил, и, соответственно, паниковать рано, но что делать, уже понятно.

Сейчас всем рекомендуется уже сидеть на ee ключах, причем telemt работает кривовато. Официальный FakeTLS режим работает более чем корректно.

Главное чтобы домен для прикрытия был правильным. Единственная точка отказа в этом протоколе — именно правильное решение о выбранном домене для маскировки.

☺️ Скачать | ☺️ Premium (донаты) | ☺️ Android, MacOS и др. ссылки

О. Проснулись. Народ начал любить вас даже больше чем РКН. Жалко что о них говорят не так часто как о РКН или даже минцифры.

А своих героев страна должна знать в лицо.

☺️ Скачать | ☺️ Premium (донаты) | ☺️ Android, MacOS и др. ссылки

ВК плохо. После обновы ТСПУ кстати да-да.

☺️ Скачать | ☺️ Premium (донаты) | ☺️ Android, MacOS и др. ссылки

Вспомним классику.

☺️ Скачать | ☺️ Premium (донаты) | ☺️ Android, MacOS и др. ссылки

Вы. Бездари.

Хоть раз пишите новости самостоятельно?

Спасибо что картинку сменили.

☺️ Скачать | ☺️ Premium (донаты) | ☺️ Android, MacOS и др. ссылки

Пишут что забанили Фигму. Но скорее всего какой-то кривой блок амазона.

Кажется уже откатили. Вообще РКН в последние дни очень активно работает. Единственный успешный успех у них был в блокировке handshake и отпечатке chrome.

Всё остальное в принципе непонятно что там тестируется. И самое главное — некоторые баги уже команда xray core исправила. Но или клиенты не успели это подтянуть, либо сервер отдаёт старую версию ядра.

Но их плодовитости и работоспособности можно только позавидовать.

При этом, что стало уже нормой, всё делается тихо. Не спеша. Не шиша не узнаешь.

А блоки амазона надо давно обходить уже целыми ASN подсетями чтобы не мучиться с отдельными ресурсами.

☺️ Скачать | ☺️ Premium (донаты) | ☺️ Android, MacOS и др. ссылки

МТПрото — ВСЁ. Или как Дуров лапу сосал.

Протокол Дурова известен своей корявой архитектурой и уязвимостью. Но большой плюс что он всё же открытый. А значит его может менять любой пользователь.

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

Главное изменение: Qz3rK (неизвестно кто это но дай бог ему здоровье) переделал генерацию MTProto TLS ClientHello, чтобы он НЕ был одинаковым на каждом подключении.

🧿 ClientHello теперь генерируется на каждое подключение заново, а не берётся как один статический набор правил. В коде появились две функции-шаблона: PrepareClientHelloRulesChrome() и PrepareClientHelloRulesFirefox(), а PrepareClientHelloRules() случайно выбирает одну из них.

🧿 Случайный набор cipher suites.
В обеих схемах оставлены обязательные TLS 1.3 cipher suites, а остальные выбираются случайно из списка и перемешиваются. Для Chrome-like варианта это видно по списку allCiphers, выбору extraCount, ranges::shuffle и сборке finalCiphers.

🧿 Случайные TLS extensions.
SNI остаётся обязательным, а дополнительные расширения выбираются из заранее заданного списка, перемешиваются и добавляются в случайном количестве. У Chrome-like варианта может быть от 0 до 5 дополнительных расширений, у Firefox-like — от 1 до 6.

🧿 Изменена отправка ClientHello по TCP.
Вместо обычной отправки всего буфера код отправляет ClientHello кусками: первый кусок 1–32 байта, дальше куски 16–128 байт, между ними случайные задержки 3–25 мс, плюс начальная задержка 5–100 мс; после каждого write() вызывается flush().

Однако и это не является прям супер крутым и правильным решением проблемы.

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

Как заявляет сам Qz3rK (и он прав) нужна более правильная мимикрия под реальные браузеры, уникальный fingerprint на клиента, отсутствие грубого zero-padding и ClientHello, максимально похожий на реальный браузерный сценарий.

Форк пытается убрать единую DPI-сигнатуру Telegram Desktop MTProto-over-TLS, делая ClientHello переменным по шаблону, cipher suites, extensions, размеру/нарезке отправки и timestamp.

☺️ Скачать | ☺️ Premium (донаты) | ☺️ Android, MacOS и др. ссылки