К контенту
habrforever
ЖИВА #vless 2026 · ~6 мин чтения

Как мы делали VPN под Китай — актуализация 2026

оригинал на Хабре habr.com/…/1053250
снимок Wayback не сохранялся
статус на Хабре (ноябрь 2026) доступна
права © автор, переиздание в архивных целях с указанием источника

Как мы делали VPN под Китай

Архивное переиздание с актуализацией. Оригинал опубликован на 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 «удалена по юридическим причинам») — именно поэтому появляются проекты-архивы вроде этого).

Статус оригинала

Минимальный сервер 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

  • клиенты: 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 года

  • uTLS-фingerprint клиента теперь критичен (chrome/firefox из коробки)
  • flow xtls-rprx-vision — норма; старые flow без vision уязвимы к детекту
  • XHTTP-транспорт добавился как альтернатива ws/gRPC за CDN
  • 3x-ui заменил большинство «костыльных» bash-панелей из статей 2023 года
  • iOS-клиенты требуют зарубежный Apple ID чаще, чем в 2024

Чек-лист 2026

  • dest — живой крупный сайт с TLS1.3, доступный С ВАШЕГО сервера
  • shortId непустой
  • uTLS fingerprint клиента совпадает с типичным браузером
  • сервер не «светится» сканерами (закрыть 80/8080-заглушки)
  • fallback на реальный сайт, если probe придёт без правильного SNI

Вердикт

Оригинальная статья была верной — просто Xray с тех пор обновился, панели стали удобнее, а сама тема — юридически горячей. Конфиг выше — минимальная «сегодня-работает»-версия; вся методология оригинала (x25519-ключи, SNI-подбор, проверка blockcheck) неизменна.

ОРИГИНАЛ СТАТЬИ (без изменений)

Мы с другом учимся в Китае. В апреле, в очередной раз меняя умерший VPN, решили собрать свой, заточенный под Great Firewall, на протоколе Reality: VPN‑трафик в нём выглядит для системы фильтрации как обычная HTTPS‑сессия с каким‑нибудь сторонним сайтом. Я взял на себя бэкенд, бота и Mini App. Друг отвечал за серверную часть и ноды.

Ниже — про два месяца разработки, три версии интерфейса и отказ от целой механики из‑за банков.

1. Интерфейс

Версия 1. Чат‑бот с конфигом

Первая версия была максимально простой: юзер пишет боту, оплачивает тариф, в ответ получает QR‑код с конфигом — копируй, импортируй, готово.

Проблема была в другом. Если посмотреть на большинство VPN‑сервисов в Telegram — это ровно такие же чат‑боты. Текст, кнопка «купить»,конфиг. Всё. Хочется сделать что‑то грандиознее, и выделиться.

Версия 2. Mini App с балансом и тарифами

Поэтому я взялся переделывать всё на Mini App. Mini App у VPN‑сервисов в Telegram почти нет, большинство ограничивается ботом. Решил, что вот тут можно нормально выделиться.

Что в итоге собралось во второй версии:

баланс и тарифы внутри одного экрана,

реферальный турнир с недельным топом,

ачивки за разные действия,

и **бесплатный **«барабан удачи» (про это чуть ниже). 

Казалось, всё готово. Mini app есть, логика прописана. Но… 

Версия 3. Mini App с bridge‑страницей и deeplink

Я показал бота знакомому — обычному пользователю никак не связанному с IT. Он оплатил тариф, получил конфиг, и дальше застрял. Куда выйти, что куда вставить, какой клиент скачать — всё это требовало отдельных объяснений. 

Тут до меня дошло, что вся идея с «вот тебе конфиг, импортируй сам» — сама по себе неудобная. Юзеру не должно требоваться никаких знаний про subscription URL, форматы, клиенты. Должен быть один тап.

Так появилась третья версия Mini App — с кнопкой «Подключить», которая запускает deeplink‑флоу через bridge‑страницу. Работает это так:

Юзер выбирает любимый клиент (Happ, v2box или Hiddify) и тапает «Открыть».

Mini App открывает HTTPS‑страницу на нашем домене — это bridge. Зачем она нужна: Telegram WebView блокирует кастомные схемы вроде happ://, поэтому напрямую из Mini App запустить клиент нельзя. Bridge открывается через tg.openLink() во внешнем браузере (Safari / Chrome), а там кастомные схемы уже работают.

На bridge‑странице две кнопки: «Открыть в Happ» (запускает deeplink, который импортирует подписку прямо в приложение) и «Установить» (ведёт в App Store / Google Play, если приложения ещё нет).

Юзер ставит клиент, возвращается на bridge, тапает «Открыть» — приложение подхватывает подписку автоматически. На bridge ещё лежит копия URL в clipboard на случай, если автоимпорт не сработал и нужно вставить руками.

Иллюстрация из оригинала статьи

happ://add/<encoded-subscription-url>

Тот же знакомый с этой версии подключился без каких‑либо вопросов.

2. Что под капотом

Архитектурно сервис разнесён на два сервера. Один — под бэкенд (бот, API, Mini App, база данных, админ‑панель). Второй — под VPN‑панель, которая управляет всеми нодами.

Бэкенд написан на Python, FastAPI как основной фреймворк, PostgreSQL для базы данных, Redis для кэша и сессий. Mini App — React, собранный через Vite.

Авторизация юзеров идёт через стандартный механизм Telegram WebApp с проверкой подписи на бэке, дальше JWT‑токены на сессию, чтобы не дёргать Telegram на каждый запрос.

С панелью история была еще длиннее. За два месяца мы прошли через три варианта:

3x‑ui. То, с чего начинают, когда поднимают что‑то для себя и пары друзей. Ставится одной командой, работает прозрачно. Для прода не годится. Нормального API для управления подписками нет, учёта устройств тоже нет, в логи ходишь руками по каждой ноде. Как только пользователей становится несколько десятков, it’s over.

Marzban. Следующая остановка. Есть REST API, есть концепция тарифов и лимитов. Но столкнулись с двумя проблемами. Первая: репозиторий толком не обновляется, крупных коммитов давно нет. Для VPN, где блокировки меняются раз в пару месяцев, это критично. Вторая: добавить что‑то нестандартное (новый протокол, HWID‑привязку, кастомный routing) сложно. Архитектура на это не рассчитана.

Remnawave. Где мы остановились. Самая молодая из трёх, но активно развивается: разработчики оперативно реагируют на issues, добавляют протоколы под актуальные реалии. Из коробки есть HWID‑привязка (один конфиг = ограниченное число устройств), возможность ограничивать торренты на стороне ноды. 

3. Проблемы

Большую часть из двух месяцев заняли не сами фичи, а вещи, которые я не закладывал в план. 

Бесплатные «барабаны удачи» и payment processors

Сначала про игровой раздел, почему его в итоге не стало.

Внутри Mini App у нас был блок с тремя ежедневными бесплатными прокрутами: за активность можно было выиграть неделю Pro‑подписки.

Когда мы пошли подключать платёжных провайдеров для оплат картами, менеджер на той стороне посмотрел Mini App и предупредил: пока в продукте есть любые элементы рандома, даже бесплатные — подключиться к банковской системе будет сильно сложнее. Для банков любая «прокрути и выиграй» механика автоматически попадает в gambling‑категорию, и дальше длинные процедуры, дополнительные вопросы, риск что в какой‑то момент скажут нет.

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

Devops, в котором у меня был пробел

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

Что в итоге собралось:

Бэкапы в трёх местах — на VPS, в Backblaze B2, и копия у меня на компьютере. У меня паранойя по поводу потери данных пользователей — кто‑то заплатил, у кого‑то активная подписка. Пусть будет на всякий случай.

Sentry для error tracking — алерты летят на почту и в отдельный Telegram‑канал для уведомлений. Любой 500-й ответ, любой необработанный exception — видно сразу, не приходится узнавать от пользователей.

CI/CD через GitHub Actions — push в main триггерит build, тесты и деплой. 

Health checks — пингует на основные эндпоинты бота и API каждую минуту. 

Прод стоит на VPS в Германии, под доменом, SSL через certbot с автообновлением. 

4. Что в итоге

Два месяца, три панели, три версии Mini App, отменённый игровой раздел и переписанный с нуля флоу выдачи конфига. В результате получился Mini App с подпиской, балансом, картой серверов и реферальным турниром. Сейчас порядка десяти серверов в Европе, Азии и Америке, дальше будем расширять под спрос.

Если бы начинали сейчас, пропустили бы 3x‑ui и Marzban и сразу ставили Remnawave. И раньше показывали бы бета‑версию человеку, который не разбирается в VPN. Один такой тест сэкономил бы пару недель.

по теме #vless