TL;DR: Поднял VPN-инфраструктуру на VLESS+REALITY с нуля. Telegram-бот + мини-приложение, горячее управление пользователями через gRPC без рестартов XRay, балансировка между серверами, почасовой биллинг. В статье — полный разбор протокола, почему DPI его не видит, как устроена архитектура на 670+ юзеров, и все грабли, на которые я наступил в production.

Предыстория

Полгода назад я решил разобраться, как работают современные VPN-протоколы. Не на уровне «скачал WireGuard, поставил, работает», а глубже — как устроено шифрование, почему одни протоколы детектируются DPI, а другие нет, и можно ли собрать что-то своё.

Начал с OpenVPN. Потом WireGuard. Потом Shadowsocks. И каждый раз натыкался на одну и ту же проблему: DPI-системы провайдеров со временем учатся распознавать любой нестандартный трафик.

А потом я нашёл VLESS+REALITY. И понял, что это принципиально другой подход.

Спойлер: в итоге я на этом стеке собрал полноценный VPN-сервис с Telegram-ботом, мини-приложением, биллингом и балансировкой. Но обо всём по порядку.

Эволюция: почему всё до REALITY — полумеры

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

Ключевое отличие REALITY: это не маскировка. Это мимикрия на уровне протокола.

Как работает REALITY: разбор по байтам

TLS-хендшейк

Обычный VPN с TLS:

1. Клиент → сервер: ClientHello

2. Сервер отдаёт свой сертификат

3. Prober видит: «Это не Google, это VPN»

REALITY:

1. Клиент → VPN-сервер: ClientHello с SNI www.google.com

2. VPN-сервер → Google: проксирует ClientHello

3. Google → VPN-сервер: настоящий ServerHello + настоящий сертификат Google

4. VPN-сервер → клиент: отдаёт этот реальный сертификат

5. Клиент проверяет REALITY-авторизацию через shortId + X25519 ключ

6. Туннель установлен

Клиент                      VPN-сервер                google.com
  |                             |                          |
  |-- ClientHello (SNI:google)->|                          |
  |                             |-- ClientHello (SNI) ---->|
  |                             |<- ServerHello + Cert ----|
  |<- ServerHello + Real Cert --|                          |
  |                             |                          |
  |  [REALITY auth: shortId     |                          |
  |   + X25519 public key]      |                          |
  |                             |                          |
  |===== Encrypted tunnel ======|                          |

Что видит DPI:

• SNI = www.google.com — легитимный

• Сертификат = настоящий Google (валидный, не self-signed)

• TLS fingerprint = Chrome (fingerprint эмулируется)

• Паттерн = обычный HTTPS

Что видит active prober, который подключается к вашему IP:

• Настоящий сайт Google. Потому что без правильного shortId и ключа сервер просто проксирует запрос к реальному Google.

Сервер буквально неотличим от reverse proxy. Нет правильного ключа — нет VPN. Есть ключ — есть туннель. Элегантно.

X25519: аутентификация без сертификатов

Никаких Let's Encrypt. Никаких ACME. Никаких доменов. Генерируем пару ключей:

docker exec xray-container xray x25519

# Private key: SGxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
# Public key:  Qnxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Приватный на сервер, публичный — клиентам. Всё. Это X25519 ECDH — та же криптография, что в Signal и WhatsApp.

Конфиг XRay: минимум для работы

{
  "inbounds": [{
    "tag": "vless-reality",
    "port": 443,
    "protocol": "vless",
    "settings": {
      "clients": [],
      "decryption": "none"
    },
    "streamSettings": {
      "network": "tcp",
      "security": "reality",
      "realitySettings": {
        "dest": "www.google.com:443",
        "serverNames": ["www.google.com"],
        "privateKey": "<приватный_ключ>",
        "shortIds": ["abcdef1234"]
      }
    }
  }]
}

"decryption": "none" — это не ошибка. VLESS не шифрует поверх TLS, потому что TLS и так шифрует. Двойное шифрование — это двойная нагрузка на CPU без пользы. Именно поэтому VLESS+REALITY быстрее WireGuard на реальных замерах.

Production-архитектура: от конфига до 670 пользователей

Теория закончилась. Дальше — то, ради чего я писал эту статью. Реальная архитектура production-системы, которая обслуживает 670+ пользователей на двух серверах.

Общая схема

┌─────────────────────────────────────────────────────┐
│                   Telegram Bot                       │
│               (aiogram 3 + aiohttp)                  │
│                                                      │
│  Mini-App (WebApp)  ←→  API Server (порт 3000)       │
│  HTML/JS/CSS            aiohttp + aiosqlite          │
└──────────────────────────┬──────────────────────────-┘
                           │
              ┌────────────┼────────────┐
              │                         │
     ┌────────┴────────┐      ┌────────┴────────┐
     │  XRay Server 1   │      │  XRay Server 2   │
     │  (local, gRPC)   │      │  (remote, SSH)   │
     │  94 устройства    │      │  49 устройств    │
     └──────────────────┘      └──────────────────┘

Пользователь открывает Telegram-бот → запускает мини-приложение → добавляет устройство → система генерирует UUID, выбирает наименее нагруженный сервер, добавляет пользователя через gRPC → отдаёт VLESS-ключ. Всё за 2 секунды.

Проблема #1: рестарты убивают соединения

Первая версия работала так: новый пользователь → правим config.json → docker restart xray. При каждой регистрации.

На 5 пользователях — нормально. На 50 — все текущие соединения рвутся каждый раз, когда кто-то регистрируется. Люди посреди созвона получают дисконнект. Не годится.

Решение — gRPC API XRay-core. Добавляем в конфиг:

{
  "api": {
    "tag": "api",
    "services": ["HandlerService"]
  },
  "inbounds": [{
    "tag": "api-inbound",
    "listen": "127.0.0.1",
    "port": 10085,
    "protocol": "dokodemo-door",
    "settings": { "address": "127.0.0.1" }
  }],
  "routing": {
    "rules": [{
      "inboundTag": ["api-inbound"],
      "outboundTag": "api",
      "type": "field"
    }]
  }
}

Теперь добавление пользователя — один вызов, ноль рестартов, ноль дисконнектов:

# Добавить (hot, без рестарта)
xray api adu --server=127.0.0.1:10085 \
  -inbound=vless-reality \
  -users='[{"email":"user_abc","id":"<uuid>","flow":"xtls-rprx-vision"}]'

# Удалить
xray api rmu --server=127.0.0.1:10085 \
  -inbound=vless-reality \
  -users='"user_abc"'

670 пользователей — ноль рестартов за последний месяц.

Проблема #2: gRPC не переживает рестарт

Подвох: gRPC API управляет только runtime. Перезапустил контейнер — все пользователи, добавленные через API, пропали. XRay загружает config.json, а там пусто.

Нужна синхронизация. Но писать конфиг при каждом добавлении — тоже плохо (файловый I/O, возможные race conditions). Решение — debounced sync:

_sync_task = None

async def schedule_config_sync():
    """Откладываем запись на 5 секунд.
    Новый вызов — таймер перезапускается."""
    global _sync_task
    if _sync_task:
        _sync_task.cancel()
    _sync_task = asyncio.create_task(_delayed_sync())

async def _delayed_sync():
    await asyncio.sleep(5)
    await write_full_config_from_db()

Пришло 10 регистраций за секунду? Один файловый write через 5 секунд после последней. А gRPC добавил всех десятерых мгновенно.

Проблема #3: второй сервер

Когда первый сервер набрал 90+ устройств, я добавил второй. И тут начинается интересное.

Локальный сервер — gRPC по 127.0.0.1. Удалённый — нужно SSH.

async def add_client(uuid: str, server: Server):
    user_json = json.dumps({
        "email": uuid, "id": uuid,
        "flow": "xtls-rprx-vision"
    })
    cmd = (
        f"docker exec {server.xray_container} "
        f"xray api adu --server=127.0.0.1:10085 "
        f"-inbound=vless-reality "
        f"-users='[{user_json}]'"
    )
    if server.is_local:
        proc = await asyncio.create_subprocess_shell(cmd, ...)
        await proc.wait()
    else:
        async with asyncssh.connect(server.ssh_host, ...) as conn:
            result = await conn.run(cmd)

Балансировка — простейший least-loaded:

SELECT s.*, COUNT(d.id) as device_count
FROM servers s
LEFT JOIN devices d ON d.server_id = s.id
    AND d.is_active = 1
WHERE s.is_active = 1
GROUP BY s.id
ORDER BY device_count ASC
LIMIT 1

Новый сервер стартует с 0 устройств → получает все новые регистрации → постепенно выравнивается с первым. Просто и работает.

Проблема #4: биллинг

Модель: 100 руб./мес за устройство. Но подписки я делать не хотел — слишком много головной боли с рекуррентными платежами, отменами, пропорциональным списанием.

Вместо этого — баланс + почасовое списание:

MONTHLY_COST = 100.0        # руб/мес за устройство
HOURLY_RATE = MONTHLY_COST / 30 / 24  # ~0.14 руб/час

async def check_balance_deductions():
    """Запускается каждый час через APScheduler."""
    for user, device_count in await get_users_with_active_devices():
        if user.is_lifetime:
            continue

        hours = (now - user.last_deduction) / 3600
        hours = max(0.5, min(hours, 48.0))  # сервер мог лежать

        cost = hours * device_count * HOURLY_RATE
        new_balance = user.balance - cost

        if new_balance <= 0:
            await set_balance(user.id, 0)
            await deactivate_all_devices(user.id)  # gRPC remove
            await bot.send_message(user.id, "Баланс исчерпан!")
        else:
            await set_balance(user.id, new_balance)

max(0.5, min(hours, 48.0)) — защита от крайних случаев. Сервер лежал 3 дня? Списываем максимум за 48 часов, а не за 72. Честнее по отношению к пользователю.

При балансе на 3 дня — предупреждение. При нуле — деактивация всех устройств через gRPC API и уведомление в Telegram.

Проблема #5: шаринг ключей

VLESS-ключ — это строка. Скопировал, отправил другу, оба пользуетесь. Как бороться?

Hardware ID fingerprinting. Клиентское приложение при подключении отправляет хэш железа:

async def check_hardware(device_id: int, hw_hash: str):
    count = await count_unique_hw_for_device(device_id)
    if count >= MAX_HW_PER_DEVICE:  # лимит 3 физических устройства
        return {"blocked": True}
    await upsert_hardware_id(device_id, hw_hash)
    return {"blocked": False}

Не серебряная пуля, но отсекает 90% абьюза.

Бенчмарк: а что со скоростью?

Замеры на одном сервере (4 vCPU, 8GB RAM, 1Gbps):

VLESS+REALITY быстрее WireGuard по throughput. Звучит контринтуитивно, но объяснение простое: VLESS не добавляет своего шифрования поверх TLS. А WireGuard шифрует всё с нуля через ChaCha20-Poly1305.

WireGuard выигрывает по CPU (kernel-space vs userspace), но в реальных условиях это не критично.

Грабли, на которые я наступил

Выбор SNI

Не каждый сайт годится. Требования:

• TLS 1.3

• Быстрый ответ на 443

• Желательно тот же AS/хостинг (минимальный RTT)

Хорошо: www.google.com, www.microsoft.com, dl.google.com

Плохо: Cloudflare-сайты (проверяют fingerprints), маленькие сайты (подозрительно мало трафика к ним с вашего IP).

Логирование списаний

Нашёл баг через месяц после запуска: balance_history записывал amount = 0 для всех списаний. Баланс списывался корректно (через set_balance), но в историю транзакций попадал ноль. Месяц без нормальных логов.

Причина: вызывал add_balance(user_id, 0, "deduction", ...) — нужно было log_balance_history(user_id, -cost, ...).

Мораль: если у вас есть отдельная функция для set + отдельная для log — не смешивайте. Или используйте одну атомарную операцию.

SQLite в Docker

aiosqlite прекрасно работает до ~10K пользователей на одном сервере. Но:

• WAL mode обязателен (без него — блокировки на каждую запись)

• journal_mode=WAL + synchronous=NORMAL — золотой баланс скорости и надежности

• Volumes в Docker: не монтируйте БД в tmpfs. Потерял данные один раз, хватило

VLESS-ключ: что получает пользователь

Каждому устройству генерируется уникальный UUID. Из него собирается ссылка:

vless://<uuid>@<server_ip>:443?type=tcp&security=reality
    &pbk=<public_key>&fp=chrome&sni=www.google.com
    &sid=<short_id>&flow=xtls-rprx-vision#SonicVPN

Пользователь копирует эту строку → вставляет в клиент (Hiddify, v2rayNG, v2RayTun) → подключается. Или сканирует QR-код с экрана мини-приложения.

Стек

Если кто-то захочет собрать подобное:

Что дальше

• Больше серверов + гео-балансировка — сейчас least-loaded, хочу добавить выбор по GeoIP

• WireGuard fallback — для случаев, когда VLESS почему-то медленнее (бывает на некоторых мобильных операторах)

• Prometheus + Grafana — нормальный мониторинг вместо docker logs | grep

• PostgreSQL — когда SQLite станет узким местом

Вместо заключения

VLESS+REALITY — это, на мой взгляд, лучшее, что есть сейчас для шифрования трафика. Не потому что он «самый быстрый» или «самый безопасный» в вакууме, а потому что он решает главную проблему: неотличимость от легитимного HTTPS. Всё остальное — вопрос инженерии вокруг.

Если хотите поковырять XRay — исходники открыты: XTLS/Xray-core. Документация — xtls.github.io.

Если не хотите поднимать всё самостоятельно — я на этом стеке собрал SonicVPN. Можно потыкать бесплатно (10 руб. на балансе при регистрации, хватает на ~3 дня).

Вопросы по архитектуре, gRPC, биллингу — в комментариях, постараюсь ответить.