Осенью 2026 года за шесть недель заблокировали четыре зарубежных VPN-сервера, и каждый следующий прожил меньше предыдущего, три последних заблокировали за пять дней. Все настроено серьезно: VLESS поверх REALITY с self steal SNI на собственном домене, XHTTP, разные провайдеры, страны и ASN. Их все равно заблокировали. Явление массовое. Смена IP помогает ненадолго. В начале ноября адреса зарубежных серверов живут от нескольких часов до 1-3 суток.

Предыстория

Сроки жизни серверов:

До осени сервера с той же схемой жили месяцами.

Все блокировки одинаковые, IP адрес полностью недоступен по сети. Соседние адреса из той же подсети (проверялись /29 и /24) остаются доступны, то есть блокировка точечная, по конкретному IP. Исходящие соединения с заблокированного адреса к российским сайтам при этом проходят.

Часть адресов через некоторое время становятся доступны. Из четырех заблокированных серверов два снова доступны из РФ, один примерно через неделю после блокировки. Еще два мне уже не принадлежат, поэтому их состояние ничего сказать не может.

От протокола, версии ядра, провайдера и страны блокировки не зависели. За подключения из РФ тоже не блокируют (если оно не вычисляется DPI). Особенность моей настройки в том, что для клиента используется только один хост, а отдаваемый конфиг производит балансировку ядром xray между двумя серверами, что если один ляжет, то клиенты автоматически подключаются к рабочему (observatory + routing.balancers). Так надежнее и удобнее, чем каждого учить переключать хост в приложении.

Итак, оба сервера заблокировали с разницей в три дня, хотя клиент с определенной частотой проверяет доступность обоих и подключения к ним видны одинаково. Это говорит о том, что если бы научились определять VLESS + REALITY трафик, то сервера стали бы недоступны плюс-минус одновременно, поэтому причину надо искать в другом месте.

Остается один вариант, приложения пользователя проверяют его IP адрес, отправляют куда надо и через какое-то время его блокируют. Минцифры сказало следить выпустило методичку и все мгновенно принялись исполнять (все 30 самых популярных российских приложений определяют VPN).

Прямых доказательств цепочки “приложение передало адрес -> адрес заблокирован” нет, поэтому, строго говоря, это не доказано. Но совокупность фактов говорит однозначно, адрес блокируют когда российские приложения видят его как внешний адрес.

Основное правило: пользовательский трафик не должен выходить с того же IP, на который входит. Оно не ново, еще в апреле runetfreedom предлагал готовиться к тому, что цензор узнает выходной IP, держать вход и выход на разных адресах, а без второго IP выпускать трафик через WARP. Осенью прогноз сбылся.

Правила построения

1. Соединение с сервером не должно детектироваться DPI как запрещенное

Всем уже известно, что соединение анализируется DPI и блокируется при совпадении определенных паттернов, поэтому трафик необходимо маскировать. Способов маскировки несколько: Xray (VLESS, REALITY) мимикрирует под HTTPS, Hysteria2 - под HTTP/3 поверх QUIC, AmneziaWG обфусцирует WireGuard. Остальная методичка от способа не зависит, Xray взят за пример и описание дано в его терминах.

Мастхэв для Xray сейчас:

• VLESS поверх REALITY. Настоящее TLS рукопожатие с сертификатом сайта, соединение без ключа клиента уходит на этот сайт. Активное зондирование видит обычный веб-сервер.

• Self steal SNI. Маскировка под собственный домен, настоящий сайт работает на том же сервере. Чужой SNI использовать нельзя, соединение быстро палят.

• XHTTP. Данные идут обычными HTTP/2-запросами. C февраля 2026 года VLESS+REALITY поверх голого TCP массово режут - первые ~16 КБ проходят, дальше соединение замерзает (разбор), поэтому raw TCP использовать нельзя.

• TLS отпечаток браузера (uTLS, fingerprint). Отпечаток Go по умолчанию выдает прокси.

Общие правила настройки:

• Одинаковые интервалы дают паттерн. Где ядро допускает диапазон, не должно быть фиксированного значения: паддинг, время жизни соединения, число запросов на соединение.

• Параллельных TLS-рукопожатий к одному SNI должно быть минимум. По реконструкции поведения ТСПУ, больше трех рукопожатий к одному SNI за короткий интервал вместе с другими признаками (подсеть хостинга, TLS отпечаток) замораживают трафик к узлу примерно на две минуты, а смена отпечатка во время заморозки продлевает ее до десяти.

• Новые соединения должны открываться по мере нагрузки. Залп соединений при запуске клиента является признаком из пункта выше. Параметры мультиплексирования стоит задавать явно и не полагаться на дефолты ядра (могут меняться от версии к версии) и новый дефолт может сам по себе дать залп.

Дальше считается, что маскировка настроена.

2. Трафик не выходит в интернет с адреса входа

Вход (IP, к которому подключаются клиенты) и выход (IP, с которого трафик уходит в интернет) должны быть разными. Адрес входа раскрываться не должен. Приложения палят адрес, с которого трафик уходит в интернет. Если он совпадает с адресом входа, его блокируют, и все превразается в тыкву. Поэтому пользовательский трафик должен выходить одним из трех способов:

• Отдельная выходная нода (шлюз). Сервер, адрес которого не скрывается. Подходит сервер с уже заблокированным из РФ адресом, клиенты к нему не подключаются и его блокировка не влияет на вход. Пока блокировка односторонняя - это работает, сейчас исходящие соединения с заблокированного адреса к российским сайтам проходят. Если начнут блокировать и исходящий трафик, российские сайты открываться перестанут и его придется гнать через WARP.

• Второй IP-адрес на том же сервере. Клиенты подключаются к одному адресу, трафик уходит с другого (sendThrough в outbound).

• WARP. Выходной IP адрес Cloudflare, как у пользователей сервиса 1.1.1.1. Бесплатно и без дополнительных затрат, но это чужая инфраструктура, регистрация упирается в лимиты и может быть ограничена из локации сервера. Подходит как временная замена первым двум вариантам.

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

Дальше под выходом подразумевается шлюз.

Правила:

• Трафик пользователей никогда не должен выходить с адреса входа. Если все выходы недоступны - blackhole. Порядок отказа: шлюз [-> WARP] -> blackhole.

• Служебные соединения узла (туннели к шлюзам и WARP, DoH ядра) должны быть перечислены явно. Других соединений с адреса узла быть не должно.

• Сервисы определения IP (ipify, 2ip) отдельно маршрутизировать или блокировать не стоит, они должны идти по общим правилам. Приложение может узнать внешний адрес через запрос к собственному серверу за рубежом, поэтому специальная обработка таких сервисов не только теряет смысл, но и выделяет трафик перед DPI.

Можно развести российский и остальной трафик по разным выходам (например, российское через WARP, остальное через шлюз), но это не обязательно. Тогда понадобятся правила по geosite:category-ru и geoip:ru и те же предосторожности, что в каскаде.

3. Типичные ошибки

• Утечка IPv6. Если IPv6 не используется, лучше его блокировать.

• Правила по IP не срабатывают для доменов. С domainStrategy: IPIfNonMatch ядро резолвит имя, только если ни одно правило не совпало. Последнее правило “весь остальной трафик” совпадает всегда, поэтому правила по IP (geoip:ru и подобные) работают только для соединений по голому IP. Нужен IPOnDemand, а доменные правила - выше правил по IP.

• Выключен сниффинг. Телефон в режиме TUN присылает адрес назначения как IP, имя сайта есть только в SNI. Без sniffing в инбаунде доменные правила не срабатывают, и трафик уходит не в тот выход.

• Панель управления на адресе входа. Открытый порт панели на том же IP, что и вход, выдает сервер при первом сканировании. Панель должна жить на другом адресе или быть доступна только через туннель.

• fallbackTag балансировщика ведет в freedom. Касается outbound’ов, объединенных балансировщиком со стратегией по замерам (leastPing, leastLoad с observatory). После каждого перезапуска ядра, до первой проверки, балансировщик не знает, какие outbound’ы живы, и отдает все в fallbackTag. Если там freedom, в эти секунды трафик пользователей выходит с адреса входа. В fallbackTag должен стоять WARP или blackhole.

4. Каскад через российский сервер

В схеме выше весь трафик выходит с зарубежного сервера, в том числе к российским ресурсам. Часть из них не пускает иностранные IP и просит отключить VPN или вообще не открывается. Приходится постоянно переключать в зависимости какой из ресурсов нужен. Отчасти решается раздельным туннелированием, но сделать это должен сам пользователь и у способа свои проблемы (описаны далее).

Каскад решает это дополнительным сервером в РФ. Клиент подключается к нему, российский сервер сам выпускает российские сайты со своего адреса, а все остальное отправляет на зарубежный узел: клиент -> российский узел -> зарубежный узел -> шлюз/WARP. В итоге ру ресурсы открываются, поскольку ру трафик не покидает границы рунета.

Прямой выход ру трафика с ру узла противоречит правилу раздела 2. Это противоречие допустимо:

• Блокируют зарубежные адреса. Все блокировки из предыстории - зарубежные сервера. По методичке Минцифры первый признак VPN - зарубежный адрес пользователя, российский адрес эту проверку проходит.

• Защита дороже риска. Отдельный российский шлюз - еще один сервер и новая точка отказа, а свидетельств, что российские адреса блокируют за то, что их видят российские приложения, пока нет. Усложнять схему стоит, когда такие свидетельства появятся.

Отдельный риск - хостинг. По данным статьи Как я делал VPN-сервис в 2026 году, российские хостинги получают предписания ограничивать VPN на своих мощностях, автор связывает это с “Антифрод 2.0”.

Правила российского узла:

• Заблокированное выше ру трафика. Заблокированные сайты могут находится в ру сегменте. Если правило для ру адресов стоит выше, такой трафик выходит в РФ, где ресурс закрыт.

• DoH к зарубежным резолверам из РФ периодически не проходит и без DNS узел перестает открывать ру ресурсы. Вторым в списке DNS-серверов ядра должен стоять системный резолвер сервера (localhost).

5. Другие риски

Локальные прокси клиента должны быть закрыты паролем. Клиент поднимает на устройстве SOCKS и HTTP прокси на 127.0.0.1. Без пароля через них может пройти любое приложение на этом устройстве, в том числе исключенное из туннеля. Через прокси приложение узнает факт VPN и внешний адрес в обход любой маршрутизации: при разделенных входе и выходе это адрес шлюза, при одном адресе - адрес сервера. В Happ пароль задается заголовками ответа подписки (socks-auth-mode, http-auth-mode), JSON-конфиг на него не влияет.

Разбор мнений

В сообществе звучат советы, которые расходятся с правилами выше. Далее самые частые и почему они не помогут.

Надо блокировать весь ру трафик на зарубежном сервере

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

Обратный каскад надежнее

Схема: клиент -> зарубежный узел -> российский выход. Клиент подключается к зарубежному серверу, тот отправляет российский трафик на узел в РФ, остальное выпускает сам. Расчет на то, что российские приложения увидят российский адрес, и вход не засветится.

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

Чтобы вход не светился, остальной трафик тоже должен уходить через шлюз или WARP, и правила раздела 2 действуют полностью. Тогда российский выход - просто дополнительный шлюз в России для удобства: российские сервисы видят российский адрес и реже просят отключить VPN. Если его заблокируют или хостер его отключит, клиенты не падают, российское уходит в WARP. За удобство придется заплатить:

• Двойной путь. Российский трафик дважды проходит маршрут. Задержка выше, а зарубежный сервер гонит российский трафик дважды, на вход и на выход.

• Вход остается зарубежным. Схема ничего не меняет для входа: он по-прежнему виден ТСПУ как соединение с зарубежным хостингом, и разделы 1 и 2 все еще актуальны.

Настроить раздельное туннелирование на клиенте

Через VPN идут только выбранные приложения, все остальное в direct. На защиту адреса входа это не влияет: при отдельном выходе сервисы и так видят адрес шлюза. Зато выдает самого пользователя. Например, браузер идет через VPN на зарубежный сайт, на котором стоит Яндекс Метрика, и Яндекс получает запросы с адреса VPN, хотя приложение Яндекса на том же телефоне ходит в direct. Один пользователь с двумя адресами - явный признак VPN. Кроме того, пользователь обязательно ошибется в настройке, не добавит новое приложение или добавит не то, поэтому всерьез рассматривать такой подход нельзя. Весь трафик клиента должен идти в туннель. Если его нужно делить, делать это лучше на сервере.

1 ноября собрал систему по этим правилам и выждал почти неделю, чтобы проверить работоспособность. Как говорится, ни единого разрыва. Конечно, быть полностью уверенным пока нельзя, но вспоминая про скорость блокировки от нескольких часов до 3 суток, кажется, есть все шансы.