Всё началось стандартно — поднял для себя VPS, закинул 3x‑ui, настроил VLESS+Reality. Работало хорошо. Поделился с друзьями, те поделились дальше. В какой‑то момент обнаружил, что уже администрирую инфраструктуру для нескольких десятков пользователей и делаю это руками, без какой‑либо автоматизации. В феврале 2026 оформил это в нормальный сервис с базой данных и Telegram‑ботом.
Ниже — хроника того, с чем пришлось столкнуться за время разработки, что было сделано реактивно, а что превентивно.
Стек и архитектура
Сервис построен на двух независимых бэкендах, работающих с одной БД.
Первый — Telegram-бот (Node.js). Пользователь пишет боту, получает конфиг, импортирует в клиент. Серверная сторона — российские VPS с панелью 3x-ui (XRay, VLESS).
Второй бэкенд (тоже Node.js) — основа для будущего мобильного приложения. Сейчас в нём живёт вся логика подписок, серверов и пользователей. В планах на этой базе запустить приложение для iOS и Android — получаю много фидбека о том что многим пользователям сложно разобраться с установкой приложения самостоятельно и цитата — «хотелось бы одну кнопку нажать и чтобы все работало».
Серверная инфраструктура: 12 машин. 4 входящих (ENTRY) — российские. 8 выходящих (EXIT) — Европа и США.
Вы в зоне «белых списков»
Первая серьёзная проблема пришла ещё до официального запуска сервиса — пока я тестировал инфраструктуру.
Одни пользователи жаловались на то что VPN не работает, у других все было отлично. Как потом выяснилось, (это происходило только с моб. сети) в некоторых городах были проблемы с подключением в зоне «белых списков»: у одних соединение устанавливается, но не грузит ничего, у других сервера не пингуются вообще. Видимо операторы моб. связи по разному блокируют доступ в зонах БС.
Прочитав эту статью решил попробовать цепочку из входящего - выходящего сервера. Клиент подключается к российской ENTRY ноде (внутрироссийский трафик ТСПУ не трогает), та пробрасывает трафик на европейский EXIT. Системы мониторинга видят это как обмен данными между двумя серверами, а не как пользователь ломящийся напрямую в Европу.
Именно поэтому в архитектуре появилось разделение ENTRY/EXIT, как прямой ответ на конкретную технику блокировки.
Поиск «белых» IP: лотерея, которую нельзя выиграть
IP российского ENTRY-сервера в этой схеме должен находиться в так называемом «белом списке» — пуле IP‑адресов, которые ТСПУ пропускает без шейпинга. Проверка простая: поднимаешь веб‑сервер на 443-м порту, открываешь с телефона в зоне белых списков, без VPN. Открылся — адрес рабочий.
На практике нашёл рабочие адреса только у двух провайдеров — Яндекса и ВК. На других российских хостингах найти подходящие IP не удалось вообще.
Что Яндекс, что ВК — те еще конторы… Но выбирать не приходится.
С ВК вообще случилась отдельная история, после которой я бы дал этой конторке статус «гопника»:
В какой-то момент — без предупреждения и уведомлений отвалился один (из четырех) сервак. Зайдя в панель я увидел что у него просто нет IP адреса (Да он был белый и его забрали) и установить новый возможности нет, (так как IP выдан автоматически с машиной, а не куплен, я не могу купить еще один и привязать к этой машине. Кто в теме тот знает). Затем забрали второй, третий и четвертый по такой же схеме. Поддержка отвечала в духе: Ой, а кто это сделал? Мы ничего не знаем… А потом просто вывесили объявление для всех. В итоге на вк у меня осталось только 2 сервера из 4х, как раз те, у которых IP был куплен. Я просто купил новые и заменил. С остальными двумя машинами пришлось распрощаться.
Первое падение бота
В какой-то момент Telegram оказался заблокирован со всех российских IP. И VPS на Timeweb, который до этого не знал проблем внезапно потерял связь с t.me и бот перестал отвечать.
Быстрым решением стал SOCKS5-прокси — накатил, бот поднялся. Но такое решение было нельзя оставлять надолго: скорость ответов бота упала в 2–3 раза, надёжность прокси вызывала вопросы в долгосрочной перспективе. И сталкиваться с этой проблемой еще раз не было желания.
Было принято решение — переезжаем.
Блокировка VPN на российских хостингах: вынужденный переезд
Следующим ударом (от которого я уже начал уворачиваться) стала новость о том, что российские хостинги начали получать предписания ограничивать работу VPN‑сервисов на своих мощностях — прямое следствие пакета поправок «Антифрод 2.0», о котором подробно писали тут. Там же Минцифры открыто потребовало от аккредитованных IT-компаний внедрения модулей, помогающих блокировать персональные VPN-серверы.
Я понимал что решение о переносе бэкенда на европейский сервер было сделано верно и на ближайших выходных после полуночи достал бубен и начал танцевать.
Справился за 2 часа и с довольным видом пошел спать. Технически переезд прошел без потерь, но утром я проснулся от уведомлений и звонков от друзей со словами «Саня, все пропало!!! АОАОААОА»...
Проблема оказалась прозаичной — DNS-записи обновляются до 48 часов, а Happ автоматически обновлял подписку каждый час! У части пользователей в этот период отвалились подписки — клиент продолжал ходить на старый IP, которого уже не было и удалял сервера из подписки. Спустя двое суток у всех все восстановилось.
На заметку: отключайте автообновление подписок если пойдете по этой дорожке))
Вокруг одни агенты
Параллельно с техническими блокировками шёл процесс детекции VPN на уровне приложений.
В марте 2026 исследователь runetfreedom опубликовал разбор мессенджера MAX. Реверс-инжиниринг показал: приложение асинхронно получает внешний IP пользователя сразу через несколько источников (ipify, ifconfig.me, ip.mail.ru, checkip.amazonaws.com — список перемешивается при каждом запуске), одновременно проверяет доступность Telegram, WhatsApp, Google через ping и TCP:443, и отправляет всё это на серверы с полем vpn: 1 если активно VPN-соединение.
Модуль включается удалённо — таргетно для конкретных аккаунтов. Множественные источники IP — специально, чтобы ловить пользователей с split-tunneling, которые не заворачивают российский трафик в туннель.
Чуть позже Минцифры официально разослало методичку с требованием внедрять подобные модули в продукты аккредитованных компаний. То есть MAX был не инициативой ВКонтакте — это де-факто регуляторный стандарт, который распространится на все крупные российские приложения.
Для нашей инфраструктуры это означало следующее: архитектура с единым IP на входе и выходе — идеальная мишень. Если детектор получает выходной IP и блокирует его, сервис падает целиком. Разделённые ENTRY и EXIT здесь оказались правильным решением — детектор получает IP российского ENTRY, который ничего не выдаёт.
Позже фича с детектом VPN появилась почти в каждом российском приложении — я сталкивался с ней в Ozon, hh, ВК, Госуслуги. Все приложения (кроме Госуслуг, хаха) с включенным VPN работать отказывались.
В 3x-ui панели был настроен роутинг — на ру сайты и приложения по geoip и geosite трафик шел с российского ENTRY сервера. Это работало, но не у всех и не всегда стабильно. Плюс IP хоть и российский, но все же это IP от VPS.
Поэтому в дополнение я настроил конфиг для Happ, для раздельной маршрутизации на уровне клиента по geoip и geosite, который рассылкой предложил установить всем юзерам.
Детекция VPN западными сервисами и WARP
Отдельная история — детекция со стороны зарубежных сервисов. Google, OpenAI, Claude, Roblox и многие другие блокируют или замедляют VPN-трафик. Причины у всех свои — антифрод, лицензионные ограничения, геоблокировка. Метод детекции преимущественно один: репутация IP.
Датацентровые адреса — а VPS всегда датацентр — размечены в базах IPinfo, MaxMind и аналогах. Категория datacenter или vpn/proxy автоматически означает повышенное подозрение или прямую блокировку.
Решение, которое сейчас стоит — Cloudflare WARP на EXIT‑серверах. Весь исходящий трафик с EXIT заворачивается в WARP‑туннель и наружу выходит уже с Cloudflare IP.
Cloudflare — CDN‑провайдер с огромной сетью, его адреса не размечены как «VPN IP». Для целевого сервиса это выглядит как корпоративный трафик.
Добавляется лишний хоп и несколько миллисекунд задержки. Зато ChatGPT, Google, Claude работают без капч и блокировок. Даже с задержкой USA сервера работать комфортно.
Вместо заключения
За несколько месяцев работы сервис пережил: смену архитектуры из‑за новой тактики ТСПУ, потерю «белых» IP у провайдера без предупреждения, вынужденный переезд российских нод с частичным падением подписок, появление обязательных шпионских модулей в российских приложениях и публичную уязвимость в самих VPN‑клиентах.
Проект из формата «для себя» перерос в большую партию в шахматы с РКН и другими игроками рынка. Каждый новый вызов только увеличивает интерес!
Будем надеяться, что все игроки будут ходить по правилам. Хотя опыт последних месяцев показывает, что правила здесь меняются прямо во время партии.