Белые списки добрались до Москвы: изучаем механику «отсечки» в 16 килобайт — актуализация 2026
Белые списки добрались до Москвы: изучаем механику «отсечки» в 16 килобайт
Архивное переиздание с актуализацией. Оригинал опубликован на Habr (2026), автор — неизвестен. оригинал доступен на Habr по состоянию на ноябрь 2026. Ниже — редакция ноября 2026: что работает сейчас, что изменилось и как правильно повторить рецепт сегодня. Полный текст оригинала — в конце, без купюр.
TL;DR — версия 2026
VLESS+REALITY (Xray) в 2026 — главный рекомендованный способ: маскировка под TLS к чужому крупному сайту, активное зондирование не проходит, домен и сертификат не нужны.
Оригинал попал в первую волну статей о VLESS+Reality — и с тех пор подход не просто выжил, а стал стандартом: фактическим стандартом антицензурного туннелирования в 2026 стал VLESS + REALITY (Xray-core): он маскируется под обычный HTTPS-трафик к крупному сайту и не требует собственного домена и сертификата; по данным РКН, за 2025 год в России заблокировано 258 VPN-сервисов, и почти все выжившие сервисы сидят именно на Xray. Что изменилось с публикации: пару-тройку версий Xray-ядра, новые клиенты, панели 3x-ui/Marzban с автонастройкой Reality, и — увы — статья о том, как это ставить, стала легальной мишенью (российские сайты и сами хабр-авторы начали массово удалять статьи о VPN (статьи отдают HTTP 451 «удалена по юридическим причинам») — именно поэтому появляются проекты-архивы вроде этого).
Статус оригинала
- URL: https://habr.com/ru/articles/1008164/
- Статус на Habr: ЖИВА
- Картинки: 3/3 сохранено локально
Клиенты и панели 2026
- клиенты: v2rayN (Windows), NekoBox/NekoRay, Hiddify (кросс), v2rayNG (Android), Streisand/Shadowrocket (iOS — ставить быстро, Apple вычищает их из стора волнами);
- панели: 3x-ui (мульти-протокол, лимиты трафика, подписки) и Marzban — обе ставятся docker-compose и закрывают тему «у меня 5 друзей»;
- подписка: ссылка
vless://...превращается в QR/URL, Hiddify сам обновляет; - проверка блокировок вокруг вашего сервера:
blockcheckот ValdikSS.
Почему REALITY до сих пор непробиваем
REALITY «крадёт» рукопожатие у настоящего TLS-сайта: ваш сервер, не имея сертификата, отдаёт клиенту handshake реального target-сайта (dest), а внутри договаривается о ключах. Со стороны (DPI, активный probe) это обычный HTTPS к популярному ресурсу. Ответить probe-ом «не тем» сервер не может — нечем отличить. В 2025–2026 у операторов блокировок остаётся один приём: резать «подозрительные» IP целиком. Лечится CDN-фронтом или сменой IP.
Минимальный сервер 2026
Актуальный Xray-core (ветка 2x/25.x) — ставится официальным скриптом; ключевые поля:
"inbounds": [{
"listen": "0.0.0.0",
"port": 443,
"protocol": "vless",
"settings": {
"clients": [{ "id": "<uuid>", "flow": "xtls-rprx-vision" }],
"decryption": "none"
},
"streamSettings": {
"security": "reality",
"realitySettings": {
"dest": "www.microsoft.com:443",
"serverNames": ["www.microsoft.com"],
"shortId": "",
"privateKey": "<x25519>"
}
}
}]
Выбор dest: крупный зарубежный сайт с TLS 1.3 + H2, НЕ ваш CDN, не российский, не «за Cloudflare» (цикл). Проверка: openssl s_client -connect dest:443 с сервера должна отдавать нужный SNI.
Иллюстрации из оригинала

Что изменилось с 2026 года
- uTLS-фingerprint клиента теперь критичен (chrome/firefox из коробки)
- flow xtls-rprx-vision — норма; старые flow без vision уязвимы к детекту
- XHTTP-транспорт добавился как альтернатива ws/gRPC за CDN
- 3x-ui заменил большинство «костыльных» bash-панелей из статей 2023 года
- iOS-клиенты требуют зарубежный Apple ID чаще, чем в 2024
- в тексте оригинала: у «ванильного» WireGuard статичный хендшейк — DPI его режет; обфусцированный вариант — AmneziaWG
Чек-лист 2026
- dest — живой крупный сайт с TLS1.3, доступный С ВАШЕГО сервера
- shortId непустой
- uTLS fingerprint клиента совпадает с типичным браузером
- сервер не «светится» сканерами (закрыть 80/8080-заглушки)
- fallback на реальный сайт, если probe придёт без правильного SNI
Вердикт
Оригинальная статья была верной — просто Xray с тех пор обновился, панели стали удобнее, а сама тема — юридически горячей. Конфиг выше — минимальная «сегодня-работает»-версия; вся методология оригинала (x25519-ключи, SNI-подбор, проверка blockcheck) неизменна.
ОРИГИНАЛ СТАТЬИ (без изменений)

В общем, то, о чем долго говорили в регионах, наконец-то полноценно пришло в Москву (в Питере уже давно). Если раньше мобильный интернет в столице был относительным «островком стабильности», то последние события в ЮАО и массовые отчеты из Петербурга показывают — систему белых списков и фильтрацию трафика включили на полную мощь.
Я решил немного пореверсить ситуацию, так как обычные жалобы на «плохую связь» уже не обьясняют того, что происходит на сетевом уровне. Это не технический сбой операторов (они, кстати, сами в шоке и разводят руками), а целенаправленная работа ”Продвинутого DPI”.
Это уже не новость, но теперь это у нас
На самом деле, те же абоненты МТС в Карелии с этой дичью живут чуть ли не с самого начала. Там схема простая: в городе всё более-менее, а за городом скорость на всё, что не входит в «белый список» (Яндекс, ВК и прочие «социально значимые»), режется до 250 кбит/c. При этом аплоад может быть под 40 мбит. Типичный шейпинг по списку разрешенных доменов.
Но в Москве и Питере пошли дальше. Тут мы столкнулись не просто с замедлением, а с фактическим отключением интернета, где доступными остаются только сервисы из «белых списков». О проблемах начали сообщать еще с раннего утра: сначала Москва (Южный округ сидел без связи более 3 часов), потом Питер.
Механика «16 килобайт»

Самое интересное — это то, как именно сейчас блокируют зарубежные платформы и тот же Cloudflare. Я провел серию тестов через curl и увидел довольно системную картину. Это не просто «не открывается», это имитация работы.
Суть в чем: соединение технически устанавливается. TCP-хендшейк проходит, вы даже начинаете получать данные. Но передача обрывается ровно после первых 16–20 килобайт (обычно это 10–14 пакетов).
Этого объема инфнормации достаточно, чтобы браузер начал отрисовывать страницу, но ключевые части сайта (тяжелые JS-бандлы, стили, API-запросы) просто не проходят. В итоге пользователь видит вечную загрузку.
$ curl -k https://cheburcheck.ru/100MB.bin -o/dev/null -r 0-65536 --max-time 5
...
24 65537 24 16101 0 0 3220 0 0:00:20 0:00:04 0:00:16 0
curl: (28) Operation timed out after 5000 milliseconds with 16101 out of 65537 bytes received
Как DPI решает, кого «казнить», а кого «помиловать»
Как именно система понимает, что вот этот запрос к ok.ru — нормальный, а вот этот к условному packagist.org надо обрубить после 16 килобайт? Всё дело в связке DPI-фильтров, которые анализируют TLS SNI или заголовок Host в случае обычного HTTP.
По сути, сейчас схема рабюотет так: по умолчанию все HTTP(s) запросы на адреса зарубежных подсетей и хостеров блокируются (или «душатся»). Но если в пакете обнаруживается SNI из разрешенного списка, фильтр отключается.
Я проверил это через простой HTTPS-запрос с подменой SNI. Результаты подтверждают теорию:
Берем «вражеский» IP.
Делаем запрос с SNI cheburcheck.ru — получаем таймаут на 16 КБ.
Делаем запрос на тот же IP, но подставляем SNI ok.ru — и данные пролетают мгновенно.
$ curl -k https://ok.ru/100MB.bin --resolve ok.ru:443:[заблокированный_IP]
...
100 65537 100 65537 0 0 55226 0 0:00:01 0:00:01 --:--:-- 55258
Причем, что важно: белые списки работают с масками по поддоменам. То есть, если разрешен основной сайт, то и любой test.ok.ru тоже будет пролетать через фильтры.
Масштабы «загона»
Чтобы понять реальныйй размер этого «белого списка», я прогнал через тесты около 1 000 000 доменов из рейтинга Tranco. Результаты, честно говоря, так себе. Из миллиона популярных сайтов в белом списке содержится всего около 1000 доменов.
То есть нам оставили буквально 0.1% от глобальной сети. При этом выявилась ка кая-то странная аномалия: домены в зоне .co.uk по какой-то причине вообще не трогаются фильтрами и все находятся в белом списке. Почему — вопрос открытый, возможно, просто баг в настройках ” Продвинутого DPI”.
Нюансы с ASN и подсетями
ВО время экспериментов возник вопрос: а должен ли ASN у заблокированного хоста совпадать с ASN домена из белого списка?
Мои тесты и наблюдения других «исследователей» показывают, что это желательно, но не всегда обязательно. У некоторых провайдеров фильтр срабатывает только если ASN совпадают. Но бывает и так, что какой-нибудь avito.ru помогает «пропихнуть» трафик даже на хосты из совершенно других сетей.
Инфрмация постоянно меняется: в какой-то момент стратегия работает, а через час данные в том же «чебурчеке» (сервисе проверки) уже другие. Видимо, настройки фильтров крутят в реальном времени, пытаясь найти баланс. Но общая логика неизменна — если твоего SNI нет в списке доверенных, ты получаешь свои 16 КБ и «разрыв соединения».
Технические маневры: что показывают тесты на VPS
Раз уж мы заговорили про реверс-инжиниринг, нельзя обойти стороной то, как ведут себя самописные решения на базе VPS. Сейчас в сообществе активно обсуждается, что «традиционные» методы начинают буксовать. Например, многие столкнулись с тем, что Роскомнадзор начал блочить подсети популярных хостеров целиком. Был у тебя сервер в Финляндии — и всё, он в бане не по протоколу, а по IP.
Интересен опыт людей, которые пытаются строить сложные цепочки. Одна из рабочих (пока что) схем, которую я заметил — это создание «мостиков». Например, берется VPS у какого-нибудь непопулярного хостера в Норвегии, и через него с помощью GOST (GO Simple Tunnel) пробрасывается туннель к заблокированному серверу в той же Финляндии. Для системы это выглядит как обращение к «чистому» IP в Норвегии.
Но тут нужно разбираться технически в этих нюансах, также постоянно администрировать все это.
Самый простой способ найти готовое решение. На данный момент знаю несколько вариантов которые могут помочь в этом:
hynet.space — этот проект часто мелькает в обсуждениях в профильных чатах как один из самых «живучих» на текущий момент. Используют 6+ протоколов, в том числе неубиваемый VLESS³ - TCP REALITY XTLS VISION.
AmneziaWG — это модифицированный WireGuard, который пытается маскироваться. В связке с Cloudflare WARP у некоторых еще подает признаки жизни, если поиграться с настройками внутри конфига, хотя сам WARP в РФ сейчас знатно лихорадит.
Zapret GUI — по сути, графическая морда для скриптов zapret. Позволяет подбирать стратегии под своего оператора. Штука мощная, но требует настройки «под себя».
По протоколам ситуация следующая (судя по дампам трафика):
VLESS + Reality: Пока держится лучше всего, так как пытается мимикрировать под обычный трафик. Но и тут есть нюансы — использование обычного TLS в VLESS-соединениях может вызывать срабатывание фильтров DPI из-за структуры пакетов (так называемый TLS-over-TLS).
Транспорты: Сейчас «живее» остальных выглядят конфиги на XHTTP, GRPC и WS (особенно в связке с Reality). Появились даже фишки типа Reality Seed, но это уже совсем для гиков.
Схема с двумя VPS: Самый «бронебойный», но дорогой вариант — это мост между RU-сервером и зарубежным. Трафик до RU-сервера для провайдера выглядит абсолютно легитимно.
Итоги:

Система «белых списков» — это полная перекройка того, как работает сеть. Когда из миллиона доменов тебе оставляют тысячу, интернет превращается в закрытую экосистему. Причем фильтрация становится всё более «умной»: она анализирует TTL, проверяет DNS-запросы и тупо обрывает сессию на 16-м килобайте, если ей что-то не понравилось.
Поможет ли смена порта? Мои тесты показывают, что на 80-м (http) или даже 7-м (ping) портах ПРОДВИНУТЫЙ DPI иногда ведет себя менее агрессивно, и видео на том же ютубе начинает худо-бедно прогружаться в 1080p. Но это всё временные костыли. Как только какая-то стратегия становится массовой — она тут же попадает под нож.
Похоже, единственный вариант сохранить хоть какую-то связность — это переходить на сложные схемы с раздельным туннелированием и постоянно мониторить актуальные стратегии для того же zapret или nfqws. Инфнормация устаревает буквально за дни.
Такие дела.