Tropic Host

VPS сервер для VLESS, Reality, 3X-UI и Marzban: выбор хостинга и настройка необнаруживаемого VPN в 2026 году

33 мин чтения
Tropic

Краткий вывод: Для стабильной работы протокола VLESS Reality под управлением панелей 3X-UI или Marzban в 2026 году необходим VPS с аппаратной виртуализацией KVM, минимум 1 vCPU с поддержкой инструкций AES-NI (допустимый CPU Steal Time %st < 3%), 1 ГБ RAM, 10 ГБ NVMe-диска и портом 1 Гбит/с с поддержкой алгоритма контроля перегрузок TCP BBR. Контейнерная виртуализация OpenVZ и непривилегированный LXC категорически непригодны из-за изоляции ядра Linux, отсутствия модуля сокетов TUN/TAP и жестких ограничений сетевого стека nftables/iptables. Оптимальные локации для минимизации p99 latency и защиты от трансграничной деградации трафика — Нидерланды, Германия, Швеция, Финляндия и Турция.

Содержание

  1. Аппаратные требования и сайзинг: Какой VPS нужен для VLESS Reality и панелей 3X-UI / Marzban в 2026 году
  2. Физика блокировок ТСПУ и DPI: почему WireGuard и OpenVPN больше не работают
  3. Критерии выбора хостинга под VLESS: IP-пулы, аплинк, пинг и AUP политика хостера
  4. Сравнение инструментов управления: 3X-UI vs Marzban vs Amnezia VPN vs Xray CLI
  5. Пошаговое руководство: установка и настройка 3X-UI на Ubuntu 24.04 LTS
  6. Развертывание подписочного сервиса Marzban в Docker Compose
  7. Тюнинг ядра Linux под экстремальный трафик: BBR congestion control и sysctl
  8. Чек-лист безопасности и устранение неполадок (Troubleshooting)
  9. Часто задаваемые вопросы (FAQ)

Аппаратные требования и сайзинг: Какой VPS нужен для VLESS Reality и панелей 3X-UI / Marzban в 2026 году

Аппаратная и сетевая спецификация: сравнительная матрица

Выбирая vps для vless reality 3x-ui marzban, критично сопоставлять архитектурный оверхед стека с системными ресурсами. Если 3X-UI представляет собой скомпилированный Go-бинарник с прямым управлением ядром Xray, то Marzban — это распределенное приложение на Python (FastAPI/Uvicorn), работающее внутри Docker-контейнеров с базой данных (SQLite/PostgreSQL) и фоновыми воркерами.

Компонент / Метрика Минимальный базис (1–5 клиентов, 3X-UI) Production-профиль (10–50+ клиентов, Marzban) Критический порог отказа / Узкое место
Архитектура виртуализации KVM / bhyve / Proxmox QEMU KVM / VMware ESXi OpenVZ / LXC (блокировка sysctl, отсутствие кастомных модулей ядра)
CPU Core & Набор инструкций 1 vCPU @ 2.0+ GHz (AES-NI) 2 vCPU @ 2.5+ GHz (AES-NI, AVX2) %st (Steal Time) > 5%, отсутствие аппаратного AES (деградация TLS handshakes)
Оперативная память (RAM) 1 ГБ (DDR4/DDR5) 2 ГБ + 1 ГБ zram/swapfile < 768 МБ (OOM Killer аварийно завершает uvicorn/xray-core при ротации логов)
Дисковая подсистема 10 ГБ NVMe (IOPS $\ge$ 5 000) 20–30 ГБ NVMe (IOPS $\ge$ 15 000) SATA HDD / IO wait (%iowait) > 3% (задержки транзакций SQLite в WAL-режиме)
Пропускная способность порта 1 Гбит/с (Burst) 1 Гбит/с Full Duplex (Dedicated) 100 Мбит/с (джиттер при мультиплексировании потоков xMux)
Сетевой стек ядра Linux Kernel 6.1+ LTS, TCP BBRv1/v2 Linux Kernel 6.6+ LTS, TCP BBRv3, FQ Отсутствие tcp_bbr в /proc/sys/net/ipv4/tcp_available_congestion_control
Приоритетные гео-локации NL (Амстердам), DE (Франкфурт) SE (Стокгольм), FI (Хельсинки), TR (Стамбул) Перегруженные пулы Tier-3 провайдеров с высоким packet loss на аплинках

Архитектурные требования: почему KVM безальтернативен

Попытка запустить VLESS Reality на серверах с OpenVZ или устаревших шаблонах LXC приводит к критическим сетевым ошибкам на уровне системных вызовов:

  1. Изоляция сетевого пространства имен и сокетов TUN/TAP: OpenVZ использует общее ядро хост-ноды. Назначение кастомных правил маршрутизации через ip rule, создание виртуальных интерфейсов tun (/dev/net/tun) и перехват трафика через TPROXY блокируются гипервизором без выдачи привилегий CAP_NET_ADMIN.
  2. Алгоритм TCP BBR и управление очередями (Queueing Discipline): Реализация Reality маскирует трафик под валидные TLS 1.3 сессии к сторонним сайтам (SNI). Стандартный алгоритм TCP Cubic при малейшем дропе пакетов агрессивно режет congestion window (CWND) вдвое, выдавая аномальный паттерн для систем глубокого анализа пакетов (DPI). KVM позволяет загрузить модуль ядра tcp_bbr и выставить планировщик fq, гарантируя ровный пейсинг пакетов (packet pacing) и удержание скорости при потерях до 10–15%.
  3. Ограничения cgroups и OOM Killer: В OpenVZ оверселлинг оперативной памяти хостером приводит к внезапному завершению процессов (signal 9 / SIGKILL) без записи в системный журнал dmesg.

Проверка среды виртуализации и инструкций процессора выполняется однострочником:

# Проверка гипервизора и инструкций криптографии ядра
virt_type=$(systemd-detect-virt)
aes_support=$(grep -m1 -o 'aes' /proc/cpuinfo)
echo "Virtualization: $virt_type | AES-NI: ${aes_support:-NOT_FOUND}"

# Проверка загрузки модуля BBR
sysctl net.ipv4.tcp_congestion_control

Если вывод systemd-detect-virt возвращает openvz или lxc, сервер подлежит немедленной замене: полноценная настройка ядра под высокие сетевые нагрузки на нем невозможна.

Ресурсы под капотом: профилирование 3X-UI против Marzban

Разница в потреблении системных ресурсов между панелями диктует минимальный сайзинг сервера:

  • 3X-UI: Архитектура базируется на прямом управлении процессом xray-core через gRPC API. Потребление в состоянии покоя — 35–60 МБ RAM. Нагрузка на CPU линейно зависит от объема шифрования симметричным шифром AES-128-GCM или ChaCha20-Poly1305. Сервера с 1 vCPU и 1 ГБ RAM достаточно для утилизации канала до 500–700 Мбит/с.
  • Marzban: Построен на базе микросервисной контейнеризации (Docker Compose). Стек включает сервис ядра Xray, веб-интерфейс, фоновый процесс сбора сетевой статистики и базу данных SQLite/PostgreSQL. В момент старта контейнеров и ротации SSL-сертификатов пиковое потребление памяти достигает 650–850 МБ. На инстансах без настроенного swap-пространства объемом менее 1 ГБ RAM процесс uvicorn падает по Out-Of-Memory.

Минимальный тюнинг ядра для устранения узких мест сетевого буфера и предотвращения отбрасывания пакетов в сокетах:

cat << 'EOF' > /etc/sysctl.d/99-vless-tuning.conf
# Оптимизация буферов сетевого стека под гигабитный интерфейс
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
net.ipv4.tcp_mtu_probing = 1
net.ipv4.tcp_fastopen = 3
fs.file-max = 2097152
EOF
sysctl -p /etc/sysctl.d/99-vless-tuning.conf

Топология и выбор локаций в 2026 году

При выборе геолокации VPS решающее значение имеют сетевые маршруты (AS Path), связность через точки обмена трафиком (Internet Exchange) и профиль задержек (p99 latency).

  1. Нидерланды (Амстердам, AMS-IX, Serverius): Эталонная связность с Tier-1 магистральными операторами (Arelion, Lumen, NTT). Максимальная утилизация полосы пропускания и минимальный джиттер при TLS-хэндшейках VLESS Reality.
  2. Германия (Франкфурт, DE-CIX): Центральный сетевой хаб Европы. Обеспечивает стабильный p50/p99 пинг без перегрузок в часы пик. Оптимален для размещения мастер-нод Marzban с удаленными узлами.
  3. Швеция (Стокгольм, Netnod) и Финляндия (Хельсинки, FICIX): Прямые трансграничные оптические маршруты. Чистые адресные пространства хостинг-провайдеров, минимальный риск попадания под сопутствующие веерные блокировки подсетей дата-центров.
  4. Турция (Стамбул): Стратегическая локация для пользователей из южных регионов. Обеспечивает прямой маршрут в обход центральных европейских узлов, исключая задержки на транзитных магистралях и гарантируя RTT в пределах 25–45 мс.

Физика блокировок ТСПУ и DPI: почему WireGuard и OpenVPN больше не работают

Сигнатурный анализ и эвристика DPI: анатомия детекта классических протоколов

Блокировка трафика комплексами ТСПУ (технические средства противодействия угрозам) на базе DPI (Deep Packet Inspection) опирается не на IP-фильтрацию или блокировку портов, а на два детерминированных механизма: сигнатурный анализ L7-полезной нагрузки и статистический анализ энтропии потока в реальном времени.

       WireGuard Handshake Initiation (Фиксированный размер: ровно 148 байт)
┌──────────────┬──────────────┬────────────────────────┬──────────────────────┬─────────────┐
│ Type: 0x01   │ Sender Index │ Ephemeral Key (x25519) │ Encrypted Static Key │ MAC1 / MAC2 │
│ (1+3 байта)  │  (4 байта)   │       (32 байта)       │      (48 байт)       │  (32 байта) │
└──────────────┴──────────────┴────────────────────────┴──────────────────────┴─────────────┘
                                          │
                                          ▼
                      DPI / ТСПУ: Детект сигнатуры за 1 пакет ──> DROP / Blackhole

Классический протокол OpenVPN выдает себя статическим форматом служебных пакетов: * Байт опкода в первом байте UDP-дейтаграммы: маска (opcode << 3) | key_id, где управляющие пакеты P_CONTROL_HARD_RESET_CLIENT_V2 (байт 0x38 или 0x40) идут в строгой последовательности при инициализации сессии. * В случае TCP-транспорта OpenVPN передает 16-битный префикс длины пакета перед каждым TLS-фреймом, что позволяет DPI-парсерам с нулевой вычислительной сложностью классифицировать сессию без анализа криптографического контекста.

WireGuard уязвим еще сильнее из-за жесткой стандартизации структуры протокола Noise_IK: 1. Фиксированные размеры служебных сообщений: * Пакет Handshake Initiation (Type 1) имеет неизменный размер ровно 148 байт. Первые 4 байта содержат идентификатор типа 0x01 0x00 0x00 0x00, за которыми следуют 4 байта sender_index, 32 байта эфемерного открытого ключа Curve25519, 48 байт зашифрованного статического ключа, 28 байт зашифрованного таймстемпа и два 16-байтных поля MAC1/MAC2. * Ответный пакет Handshake Response (Type 2) всегда имеет размер ровно 92 байта (0x02 0x00 0x00 0x00 в заголовке). 2. Анализ энтропии Шеннона: Полезная нагрузка WireGuard шифруется ChaCha20-Poly1305. Энтропия полезной нагрузки стремится к максимуму ($H \approx 7.99$ бит/байт), при этом в потоке отсутствуют заголовки прикладных L7-протоколов (таких как DTLS, WebRTC/SRTP или DNS). 3. Эвристический триггер ТСПУ: Сессия UDP на нестандартном порту, начинающаяся с дейтаграммы размером 148 байт с последующим ответом 92 байта и переходом в непрерывный поток высокоэнтропийных данных без STUN-заголовков, однозначно классифицируется классификатором как VPN. Нода ТСПУ отправляет правило в TCAM (Ternary Content-Addressable Memory) аппаратного коммутатора, и сессия сбрасывается (RST для TCP или drop без ICMP unreachable для UDP) в течение 3–5 секунд с момента инициализации.

Проверить структуру исходящих handshake-пакетов на интерфейсе можно через tshark:

tshark -i any -f "udp port 51820" -T fields \
  -e frame.len -e data -Y "frame.len == 148 || frame.len == 92"

Архитектура Xray-core и протокол VLESS: избавление от оверхеда

Попытки маскировать трафик с помощью старых протоколов вроде VMess поверх TLS потерпели неудачу по двум причинам: * Двойное шифрование: VMess шифрует полезную нагрузку собственным алгоритмом (AES-128-GCM или Chacha20-Poly1305), после чего весь поток повторно шифруется внешним TLS-туннелем. На бюджетных VPS с ядрами низкой производительности или высоким CPU Steal Time (%st > 5%) это вызывает просадку пропускной способности, рост задержки (p99 latency вырастает с 20 до 120+ мс) и падение IOPS из-за блокировок context switch в пространстве ядра. * Сигнатурные аномалии заголовков: Собственные механизмы синхронизации VMess вызывают задержки handshake, позволяющие DPI вычислять промежутки между фазами аутентификации.

Протокол VLESS (Virtual Lightweight Encrypted Stateless Protocol) спроектирован как stateless-прокси без собственного уровня шифрования данных. Безопасность и сокрытие полностью делегируются нижележащему транспортному протоколу (TLS 1.3 / XTLS).

Формат запроса VLESS на уровне байтов: * 1 байт: Версия протокола (0x00). * 16 байт: UUID пользователя (аутентификация). * 1 байт: Длина дополнительных protobuf-параметров. * M байт: Протокольные команды (TCP/UDP, целевой IP/домен, порт). * N байт: Необработанная полезная нагрузка приложения.

Поскольку VLESS не накладывает вторичного шифрования, нагрузка на CPU снижается до базовых операций копирования буферов сокетов (splice() в ядре Linux), исключая деградацию пропускной способности на 10-гигабитных интерфейсах.

XTLS и технология Reality: эмуляция TLS 1.3 Handshake

Использование стандартного TLS-проксирования с собственным доменом и сертификатом Let's Encrypt уязвимо перед активным зондированием (Active Probing). Обнаружив подозрительный поток трафика к неизвестному серверу, сенсор ТСПУ отправляет самостоятельный TCP SYN-пакет на порт 443 целевого IP-адреса и запрашивает TLS-сертификат. Если сервер возвращает самоподписанный сертификат, пустую страницу default nginx, ошибку 403 Forbidden или сертификат подозрительного динамического домена, IP-адрес хоста немедленно вносится в реестр блокировок.

Технология VLESS-Reality внутри Xray-core полностью устраняет необходимость владения собственным доменным именем и сертификатом, решая проблему активного зондирования на уровне эмуляции рукопожатия TLS 1.3.

КЛИЕНТ (v2rayN / sing-box)             ТСПУ / DPI                   XRAY СЕРВЕР                  САЙТ-ПРИКРЫТИЕ (apple.com)
      │                                    │                             │                                    │
      │── 1. ClientHello (SNI: apple.com) ─┼────────────────────────────>│                                    │
      │      + x25519 Auth в Session ID    │                             │                                    │
      │                                    │                             │── 2. Проксирование Handshake ─────>│
      │                                    │                             │<── 3. ServerHello + Cert (Apple) ──│
      │<─ 4. Модифицированный ServerHello ─┼─────────────────────────────│                                    │
      │                                    │                             │                                    │
      │ [DPI видит валидный TLS 1.3 с реальным сертификатом Apple]       │                                    │
      │                                                                  │                                    │
      │── 5. Зашифрованный VLESS-трафик ───┼────────────────────────────>│ (Авторизован: перехват в прокси)    │
      │                                                                  │                                    │
      │── [ЗОНД ТСПУ: Невалидный Auth] ────┼────────────────────────────>│── [Transparent Fallback] ──────────>│
      │                                    │                             │<── [Ответ 200 OK от apple.com] ────│
      │<─ [Ответ от реального apple.com] ──┼─────────────────────────────│                                    │

Механизм работы Reality:

  1. Маскировка под легитимный ресурс (SNI Camouflage): В качестве целевого сервера выбирается крупный CDN или публичный сервис, поддерживающий протоколы TLS 1.3, HTTP/2 и расширение h2 в ALPN (например, dl.google.com, apple.com, gateway.icloud.com).
  2. Аутентификация через открытый ключ: На сервере генерируется ключевая пара x25519 (Private Key и Public Key) и статический идентификатор shortId (HEX-строка от 8 до 16 символов).
  3. Модификация ClientHello: Клиент формирует стандартный TLS 1.3 ClientHello, в поле SNI (Server Name Indication) прописывает домен сайта-прикрытия, а в поле Session ID внедряет временный эфемерный открытый ключ, зашифрованный с использованием PublicKey сервера Reality.
  4. Реакция на входящий трафик:
  5. Авторизованный клиент: Xray-core перехватывает пакет, расшифровывает Session ID своим PrivateKey, сверяет shortId. При совпадении данных сервер подменяет симметричный ключ шифрования сессии и переходит в режим передачи VLESS-потока.
  6. Активный зонд ТСПУ или внешний сканер: Если пакет ClientHello не содержит валидного криптографического токена Reality, Xray-core прозрачно перенаправляет соединение на реальный сервер сайта-прикрытия (dest: "apple.com:443"). Вся цепочка TLS-рукопожатия завершается между зондом ТСПУ и реальным сервером Apple без участия прокси. Зонд получает официальный сертификат, шифронаборы и корректные HTTP-заголовки. Для цензора сервер выглядит как транзитный CDN-узел, исключая классификацию в качестве прокси.

Системный тюнинг ядра Linux и конфигурация Inbound Reality

Развертывая надежный vps для vless reality 3x-ui marzban, необходимо исключить аппаратные и системные узкие места. При высоких сетевых нагрузках узким горлом становятся стандартные буферы сетевого стека ядра Linux и параметры планировщика TCP.

1. Оптимизация сетевого стека через sysctl

Для минимизации задержек и предотвращения потери пакетов в моменты резких всплесков трафика параметры ядра на сервере тюнятся под алгоритм BBR:

cat << 'EOF' > /etc/sysctl.d/99-xray-tuning.conf
# Отключение медленного старта после простоя
net.ipv4.tcp_slow_start_after_idle = 0

# Увеличение размеров очередей сокетов
net.core.rmem_max = 67108864
net.core.wmem_max = 67108864
net.core.netdev_max_backlog = 100000
net.ipv4.tcp_rmem = 4096 87380 67108864
net.ipv4.tcp_wmem = 4096 65536 67108864

# Буферы соединений
net.core.somaxconn = 65535
net.ipv4.tcp_max_syn_backlog = 3240000
net.ipv4.tcp_fin_timeout = 15
net.ipv4.tcp_tw_reuse = 1

# Алгоритм контроля перегрузок BBR
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr

# Защита от зондирования MTU
net.ipv4.tcp_mtu_probing = 1
EOF

sysctl -p /etc/sysctl.d/99-xray-tuning.conf

2. Эталонный фрагмент inbound-секции config.json для Xray-core

Рабочая конфигурация VLESS-Reality на 443 порту с перенаправлением неавторизованного трафика на CDN-серверы Apple:

{
  "inbounds": [
    {
      "port": 443,
      "protocol": "vless",
      "tag": "vless-reality-in",
      "settings": {
        "clients": [
          {
            "id": "e4b6c310-8b1e-4c7b-a2c6-3d2f1a9e8b7c",
            "flow": "xtls-rprx-vision"
          }
        ],
        "decryption": "none"
      },
      "streamSettings": {
        "network": "tcp",
        "security": "reality",
        "realitySettings": {
          "show": false,
          "dest": "apple.com:443",
          "xver": 0,
          "serverNames": [
            "apple.com",
            "www.apple.com"
          ],
          "privateKey": "aAA...[Base64_X25519_PrivateKey]...=",
          "shortIds": [
            "0123456789abcdef",
            "fedcba9876543210"
          ]
        }
      },
      "sniffing": {
        "enabled": true,
        "destOverride": ["http", "tls", "quic"],
        "routeOnly": true
      }
    }
  ]
}

Активация примитива xtls-rprx-vision в параметре flow динамически выравнивает размеры пакетов (TLS padding) в начале сессии, предотвращая классификацию потока по сигнатуре длин TLS Record. Сочетание VLESS, XTLS-Vision и Reality полностью лишает аппаратные модули ТСПУ статических маркеров классификации, гарантируя устойчивость соединения даже в условиях постоянного обновления сигнатурных баз цензуры.

Критерии выбора хостинга под VLESS: IP-пулы, аплинк, пинг и AUP политика хостера

Развертывание производительного прокси-узла на базе Xray/Sing-box требует жесткого отбора серверной инфраструктуры. Если для типового веб-сервера критичны объем NVMe и тактовая частота vCPU, то надежный VPS для VLESS Reality, 3x-ui и Marzban оценивается по принципиально иным метрикам: чистоте ASN-профиля, устойчивости аплинка к пиковому PPS (packets per second), отсутствию CPU Steal Time (%st) и юридической лояльности дата-центра к входящему и исходящему шифрованному трафику.

1. Репутация IP-пула: Datacenter vs. Residential и аудит подсетей

Протокол VLESS Reality маскирует TLS-рукопожатие под легитимный трафик стороннего домена (SNI), однако сетевой уровень (Layer 3/4) остается открытым для эвристического анализа систем ТСПУ и DPI. Если публичный IPv4-адрес сервера находится в пуле с высоким показателем Fraud Score или помечен как токсичный дата-центр, соединение попадает под пристальный скоринг еще до завершения фазы ClientHello.

Скоринг подсетей и проверка через CLI

При выборе локации и провайдера необходимо проводить превентивный аудит выданного IP по базам MaxMind, IPinfo, DB-IP и ScamAnalytics. Провайдеры с типом автономной системы hosting или datacenter мгновенно триггерят Cloudflare Turnstile, Google reCAPTCHA Enterprise и блокируются стриминговыми сервисами. Идеальный сценарий — пулы с классификацией isp или чистые подсети региональных телеком-операторов.

Проверка параметров IP и флагов анонимизации через терминал:

# Быстрый аудит репутации и флагов приватности через IPinfo API
curl -s "https://ipinfo.io/$(curl -s https://api.ipify.org)?token=$IPINFO_TOKEN" | jq '{
  ip: .ip,
  org: .org,
  asn: .asn.asn,
  type: .asn.type,
  company_type: .company.type,
  privacy: .privacy
}'

Если блок .privacy возвращает "hosting": true наряду с "proxy": true или "relay": true, IP-адрес уже занесен в спам-листы.

Для анализа апстримов и маршрутизации префикса используется сервис Hurricane Electric (BGP Toolkit):

# Проверка анонса префикса и BGP-соседей целевой AS
whois -h whois.radb.net -- "-i origin AS$(curl -s https://ipinfo.io/org | awk '{print $1}' | sed 's/AS//')" | grep -E "route:|descr:"

Критически важно убедиться, что подсеть не фигурирует в Spamhaus DROP/EDROP и реестрах AbuseIPDB с процентом уверенности атаки (Confidence Score) выше 0%. Чистый IP гарантирует, что TLS-рукопожатия Reality не будут дропаться граничными маршрутизаторами по префиксному ACL.

2. AUP (Acceptable Use Policy) и блокировки: специфика Hetzner, OVH и Tier-1 провайдеров

Большинство администраторов совершают фатальную ошибку, арендуя под VPS для VLESS Reality, 3x-ui и Marzban дешевые серверы у Tier-1 провайдеров вроде Hetzner Online GmbH, OVHcloud, Netcup или Scaleway.

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

  1. Автоматизированный мониторинг аномалий PPS: Панели 3x-ui и Marzban при обслуживании сотен клиентов генерируют нетипичные паттерны: тысячи параллельных UDP-потоков (QUIC/HTTP3, WebRTC), резкие всплески исходящего трафика и высокое количество SYN-пакетов в секунду. Мониторинг Hetzner классифицирует такой профиль как участие в DoS-амплификации или брутфорс-сканировании, переводя сервер в статус Hetzner Rescue System с блокировкой сетевого интерфейса на уровне гипервизора.
  2. Abuse-репорты от правообладателей: Если пользователь туннеля откроет торрент-клиент без включенного сплит-туннелирования (outbound block BitTorrent в Xray), через 15–30 минут на abuse-почту хостера придет DMCA-жалоба от Shadowserver или OpSec Security. Hetzner и OVH дают на устранение проблемы от 12 до 24 часов, после чего безвозвратно удаляют проект вместе с привязанными дисковыми массивами без права манибэка.
  3. Tor/Proxy AUP Violation: В правилах использования (AUP) Hetzner прямо запрещена эксплуатация общедоступных прокси, открытых relay-узлов и VPN-серверов без строгой верификации пользователей.

Защита инстанса от Abuse-инцидентов на уровне iptables и Xray

Если сервер развернут в юрисдикции со строгим AUP, необходимо принудительно заблокировать опасный трафик на уровне ядра Linux и конфигурации маршрутизации Xray:

# Блокировка стандартных портов BitTorrent/DHT и исходящего SMTP (спам-фильтр хостера)
iptables -A FORWARD -p tcp -m multiport --dports 25,465,587 -j DROP
iptables -A FORWARD -p udp -m multiport --dports 6881:6889,1024:65535 -m string --algo bm --string "BitTorrent" -j DROP
iptables -A FORWARD -m string --algo bm --string "peer_id=" -j DROP

В конфигурации config.json ядра Xray (внутри контейнеров Marzban/3x-ui) секция routing.rules обязана содержать правила с outboundTag: "blocked" для категорий geoip:private, geosite:category-ads-all и geosite:torrent.

3. Аплинк, пинг и сетевой стек ядра: 1 Гбит/с без троттлинга

Протоколы VLESS с инкапсуляцией XTLS-Reality чувствительны к джиттеру (jitter) и потерям пакетов (packet loss). Троттлинг порта со стороны хостера ломает TCP-окно, что приводит к лавинообразным ретрансмиссиям и падению скорости до нуля.

Диагностика сетевого канала: latency p99 и CPU Steal Time

При выборе тарифа VPS необходимо ориентироваться на нелимитированный порт 1 Гбит/с с гарантированным профилем (dedicated/fair-share не менее 300 Мбит/с в пике). Недопустимо использовать оверселлящих бюджетных провайдеров (например, Contabo), где показатель CPU Steal Time (%st в утилите top) превышает 2–3%. Шифрование потока через AES-GCM или ChaCha20-Poly1305 требует стабильных процессорных циклов; если гипервизор забирает vCPU для соседних VM, задержка обработки пакетов p99 подскакивает со стандартных 15 мс до 1500 мс.

Аудит сетевого маршрута и потерь до целевого провайдера:

# MTR-трассировка по протоколу TCP на порт 443 с оценкой джиттера на 100 пакетах
mtr -rwzbc 100 --tcp -P 443 1.1.1.1

Тюнинг TCP-стека под высокие нагрузки в sysctl.conf

Чтобы пропускная способность канала 1 Гбит/с раскрывалась полностью при высоком Round-Trip Time (RTT > 80ms), сетевой стек Linux переводится на алгоритм управления перегрузками BBRv3/BBRv1 и планировщик пакетов FQ:

# /etc/sysctl.d/99-vless-network.conf
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr
net.ipv4.tcp_fastopen = 3
net.core.rmem_max = 67108864
net.core.wmem_max = 67108864
net.ipv4.tcp_rmem = 4096 87380 67108864
net.ipv4.tcp_wmem = 4096 65536 67108864
net.ipv4.tcp_mtu_probing = 1
net.ipv4.ip_local_port_range = 1024 65535
net.ipv4.tcp_max_syn_backlog = 8192
net.core.netdev_max_backlog = 10000

Применение изменений без перезагрузки:

sysctl --system

4. Сравнительная матрица хостинг-провайдеров под узлы VLESS Reality

Провайдер / Инфраструктура Тип пула IP / Fraud Score Политика AUP / Риск блокировок Гарантия порта и аплинк Оверселлинг (%st / IOPS) Пригодность под Marzban / 3x-ui
Hetzner Cloud (DE, FI, US) Datacenter / Низкий (чистые подсети, но жесткий DC-флаг) Критический: бан за аномальный outgoing traffic, автолоки по жалобам за 12 часов 1–10 Гбит/с, строгий учет трафика (20 ТБ), далее шейпинг %st < 0.5%, выделенные vCPU отличные, NVMe IOPS > 50k Не рекомендуется: высокий риск аннулирования аккаунта без манибэка
OVHcloud / Kimsufi (FR, PL, CA) Hosting / Средний (часто попадает в базы антифрода) Высокий: агрессивная анти-DDoS фильтрация VAC дропает нестандартный UDP/WireGuard трафик 100–500 Мбит/с, безлимит, жесткий шейпинг при превышении PPS %st 1–3%, низкая производительность CPU на бюджетных линейках Ограниченно: подходит только как транзитный бэкхоул с кастомным MTU
Contabo (DE, US, SG) Datacenter / Высокий (заспамленные пулы) Средний: медленная реакция техподдержки, жалобы пересылаются тикетом 200–1000 Мбит/с shared, постоянный троттлинг в часы пик Критический: %st достигает 15–30%, сильная деградация дисков Категорически запрещено: непригоден из-за зависания шифрования и джиттера
BuyVM / Frantech (US, LU) Datacenter / Чистый, доступна аренда BGP-сессий Минимальный (Люксембург): игнорирование DMCA, лояльность к частным VPN 1 Гбит/с нелимитированный, честный unmetered без скрытого шейпинга %st < 1%, стабильный KVM на AMD Ryzen, NVMe IOPS > 40k Отлично: идеальный оффшорный узел для развертывания VLESS
Aeza / Servercore (NL, AT, SE) ISP/DC Mix / Минимальный Fraud Score Нулевой: лояльная политика к VPN/VLESS трафику, встроенный L4-фильтр 1–10 Гбит/с без троттлинга, низкий RTT до магистральных точек обмена %st = 0% (KVM-виртуализация без скрытого переподключения ядер) Эталонно: оптимален под высоконагруженные кластеры Marzban

При выборе площадки критическим приоритетом является связка «BBR-совместимое ядро KVM + чистый ASN без флага спам-хауса + локация в юрисдикции с мягким DMCA/AUP». Попытка сэкономить на базе перегруженных дискаунтеров приводит к регулярному попаданию IP в черные списки DPI и потере клиентской базы из-за нестабильного TLS-хендшейка.

Сравнение инструментов управления: 3X-UI vs Marzban vs Amnezia VPN vs Xray CLI

Выбор стека управления определяет не только удобство администрирования, но и требования к аппаратному обеспечению сервера. При развертывании продакшн-ноды VPS для VLESS Reality (3X-UI, Marzban или голый CLI) критично учитывать накладные расходы на среду исполнения (Go runtime vs Python/FastAPI), дисковый I/O при логировании сессий и архитектуру взаимодействия с ядром Xray-core.

1. Архитектурный анализ участников

3X-UI (Fork MHSanaei)

Монолитный бинарник на Golang со встроенной базой SQLite и скомпилированным веб-интерфейсом. * Архитектура: Управляет процессом xray-core локально через gRPC API. Статистика трафика сбрасывается из памяти Xray в локальную SQLite-базу по таймеру. * Потребление ресурсов: 35–65 МБ RSS в режиме ожидания. При 200–300 активных клиентах с xtls-rprx-vision потребление памяти редко превышает 120–150 МБ RAM. * Узкое место: При высоких значениях IOPS-задержки на сверхбюджетных тарифах частая запись статистики в SQLite может вызывать блокировки database is locked. Для предотвращения деградации базы режим журнала принудительно переводят в WAL: bash sqlite3 /etc/x-ui/x-ui.db "PRAGMA journal_mode=WAL;"

Marzban

Инженерная панель корпоративного уровня. Бэкенд написан на Python (FastAPI + SQLAlchemy + Alembic), веб-интерфейс — отдельное SPA на Vue.js. * Архитектура: Полная контейнеризация через Docker Compose. Включает оркестратор, фоновые задачи (Celery/APScheduler) и проксирует вызовы в инстанс Xray по gRPC через сокет или изолированную сеть Docker. * Потребление ресурсов: Базовый оверхед Python-рантайма и контейнеров держит стек на отметке 220–380 МБ RAM в простое. При активном веб-хукинге и обработке подписок свыше 1 000 пользователей рекомендуется выделить не менее 1 ГБ RAM, настроив лимиты памяти в cgroups v2. * Узкое место: Не подходит для минималистичных инстансов с 512 МБ RAM без настроенного zRAM или swap-файла: OOM Killer принудительно завершит процесс Uvicorn при пиковых запросах к API.

Amnezia VPN

Клиент-серверное решение, где роль панели управления выполняет десктопное приложение на Qt/C++, конфигурирующее сервер по SSH. * Архитектура: На хосте нет постоянного веб-сервера. Клиент поднимает изолированные Docker-контейнеры под каждый сервис (AmneziaWG, Shadowsocks, Xray Reality). Конфигурация компилируется на стороне клиента и передается через SSH-туннель. * Потребление ресурсов: Ограничено потреблением запущенных контейнеров (~80–140 МБ суммарно). * Узкое место: Полное отсутствие централизованного мультипользовательского учета и биллинга. Передача доступа возможна только через импорт сырых конфигурационных профилей/ключей клиентам. Сложная ручная отладка сетевого стека внутри цепочки контейнеров при падении интерфейсов.

Xray CLI (Raw Core)

Каноничная эксплуатация ядра xray через systemd с ручной декларацией JSON/JSON5-конфигов. * Архитектура: Чистый Go-бинарник, взаимодействующий напрямую с сетевым стеком ядра Linux через сокеты и системные вызовы epoll. Никаких баз данных, ORM и интерпретаторов. * Потребление ресурсов: 15–28 МБ RSS в idle-режиме. Достигает минимального показателя latency p99 за счет полного отсутствия IPC-накладных расходов (межпроцессного взаимодействия веб-панели и ядра). * Узкое место: Отсутствие нативного механизма генерации клиентских ссылок vless://, QR-кодов и динамических подписок. Любая автоматизация требует написания кастомных bash-скриптов или плейбуков Ansible.

2. Сводная техническая матрица

Критерий 3X-UI (MHSanaei) Marzban Amnezia VPN Xray CLI
Стек ядра / Runtime Go + SQLite (Single binary) Python 3 (FastAPI) + Node.js + Xray C++ (Client) / Docker (Server) Golang (xray-core)
Footprint RAM (Idle / 100 сессий) ~45 МБ / ~110 МБ ~260 МБ / ~380 МБ ~90 МБ / ~160 МБ ~18 МБ / ~70 МБ
Минимальные требования к VPS 1 vCPU / 512 МБ RAM 1 vCPU / 1024 МБ RAM 1 vCPU / 512 МБ RAM 1 vCPU / 256 МБ RAM
VLESS Reality (XTLS Vision) Встроен, автогенерация ключей Встроен, полная поддержка Поддерживается в контейнере Нативная реализация
Hysteria 2 / TUIC v5 Ограничено (внешние форки) Через кастомное ядро / Sing-box Нет (фокус на AmneziaWG) Нет (требует Sing-box)
Мультипользовательский учет Базовый (квота, срок действия) Продвинутый (RBAC, API, Webhooks) Отсутствует (децентрализованный) Ручной (inbounds.settings.clients)
Генерация подписок Base64-ссылки, базовая веб-страница Clash, Sing-box, Quantumult, Base64 Только внутренний формат Amnezia Нет (сторонние утилиты)
Автоматизация / API Недокументированный REST/Web API Полноценный OpenAPI (FastAPI/Swagger) SSH-only через GUI-клиент gRPC API ядра Xray

3. Специфика протоколов: VLESS Reality, Hysteria 2 и TUIC

Ядро Xray-core изначально разрабатывалось с упором на протоколы семейства TCP/TLS. Это напрямую ограничивает перечень поддерживаемых технологий во всех инструментах на базе Xray:

  1. VLESS Reality + XTLS Vision: Эталонно поддерживается всеми четырьмя решениями. С точки зрения сетевого стека ядро подменяет SNI и эмулирует TLS-хэндшейк целевого сайта без локального сертификата.
  2. Hysteria 2 и TUIC: Построены на базе протокола UDP и кастомных реализаций QUIC (с агрессивным congestion control алгоритмом вроде BBR или Brutal). Xray-core нативно не поддерживает Hysteria 2 и TUIC.
  3. В 3X-UI и Xray CLI запустить их без пересборки ядра с Sing-box невозможно.
  4. Marzban позволяет подменить исполняемый бинарник ядра на sing-box (экспериментальная ветка) и прописать соответствующие входящие порты в шаблонах JSON.
  5. Amnezia VPN решает задачу обхода DPI через собственный протокол AmneziaWG (модификация WireGuard с рандомизацией заголовков initiation, response и cookie), игнорируя QUIC-протоколы.

4. Мультипользовательский режим и экосистема подписок

Организация клиентского доступа радикально различается по глубине автоматизации:

[3X-UI]  ──> SQLite DB ──> Простой Base64 инлайн-текст ──> V2RayN / Streisand
[Marzban] ──> SQLAlchemy ──> Subscription Service ──> Синтез форматов:
                              ├── Clash Meta / Mihomo (.yaml)
                              ├── Sing-box JSON (.json)
                              └── Base64 Raw links
  • 3X-UI: Генерирует универсальный vless://-URI и QR-код прямо в модальном окне панели. Поддерживает простую страницу подписки (Base64-список нод). Не умеет на лету конвертировать конфиги под сложные селекторы групп правил в Clash или маршруты Sing-box.
  • Marzban: Выдает динамический эндпоинт подписки (/sub/{token}). Сервер анализирует заголовок User-Agent входящего запроса: если запрос идет от Clash.Meta, сервер возвращает валидный YAML с proxy-провайдерами; если от v2rayNG — отдает Base64.
  • Xray CLI: Требует ручной генерации ключей x25519 и ручной сборки строки подключения: bash # Генерация ключевой пары Reality для CLI-развертывания xray x25519 # Private key: u...= # Public key: K...= После чего администратор вручную генерирует UUID (xray uuid) и прописывает его в /usr/local/etc/xray/config.json.

5. Практический пример: Изоляция ресурсов в Marzban через cgroups

При выборе VPS для VLESS Reality (3X-UI, Marzban) на серверах начального уровня (1 vCPU, 1 GB RAM) стек Marzban требует обязательного ограничения ресурсов. В противном случае пиковая сборка подписок или spike входящих соединений приведет к вытеснению страниц ядра и зависанию ноды из-за высокого %st (CPU Steal Time) гипервизора.

Рабочий docker-compose.yml с жесткими лимитами памяти и CPU:

services:
  marzban:
    image: gozargah/marzban:latest
    restart: always
    env_file: .env
    network_mode: host
    volumes:
      - /var/lib/marzban:/var/lib/marzban
    deploy:
      resources:
        limits:
          cpus: '0.85'
          memory: 384M
        reservations:
          memory: 128M

  marzban-node:
    image: gozargah/marzban-node:latest
    restart: always
    network_mode: host
    volumes:
      - /var/lib/marzban-node:/var/lib/marzban-node
      - /var/run/xray:/var/run/xray
    deploy:
      resources:
        limits:
          cpus: '0.90'
          memory: 256M

6. Инженерный вердикт по выбору стека

  • Xray CLI: Выбор для высоконагруженных шлюзов, высокоскоростных 10 Gbps линков или ультрабюджетных VPS (128–256 МБ RAM), где критичен каждый мегабайт RSS и требуется минимальный latency p99. Полный контроль через GitOps и Ansible.
  • 3X-UI: Оптимальный выбор для персонального использования и небольших групп (до 15–20 пользователей). Предельно прост в настройке, минимально нагружает CPU, запускается на любом одноядерном инстансе с 512 МБ RAM без риска OOM.
  • Marzban: Промышленный стандарт для развертывания публичных и распределенных сервисов. Незаменим при необходимости отдавать профили под Clash/Sing-box, интегрировать Telegram-ботов для авторизации и управлять распределенным кластером нод через единую панель управления.
  • Amnezia VPN: Решение для конечных пользователей без опыта системного администрирования Linux, которым необходим доступ к нестандартным обфусцированным протоколам (AmneziaWG) в «один клик».

Пошаговое руководство: установка и настройка 3X-UI на Ubuntu 24.04 LTS

Развертывание стека VLESS-Reality требует прямого контроля над сетевыми буферами ядра, корректной утилизации дескрипторов файлов и изоляции панели управления от внешнего сканирования. Настраивая надежный vps для vless reality 3x-ui marzban, системный инженер должен минимизировать накладные расходы на контекстные переключения, исключить задержки планировщика и настроить маскировку протокола так, чтобы метрики рукопожатия TLS не отличались от реального HTTPS-сервера целевого домена.

Шаг 1. Подготовка Ubuntu 24.04 LTS и тюнинг сетевого стека ядра Linux

Перед запуском инсталлятора выполните аудит виртуального окружения. На KVM-хосте показатель CPU Steal Time (%st в утилите top или vmstat 1 5) обязан быть строго ниже 3%. Если значение скачет до 10–15%, хостер перегрузил физический сокет vCPU, что приведет к непредсказуемому джиттеру и росту latency p99 при шифровании потоков Xray-core.

Обновите пакетную базу и установите базовые сетевые утилиты:

apt update && apt upgrade -y
apt install -y curl socat tar jq ufw iproute2 dnsutils

Активируйте алгоритм управления перегрузками TCP BBR и увеличьте лимиты очередей сокетов. Создайте конфигурационный файл /etc/sysctl.d/99-network-tuning.conf:

cat << 'EOF' > /etc/sysctl.d/99-network-tuning.conf
# Управление перегрузками TCP
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr

# Лимиты сетевых буферов и сокетов для high-load
fs.file-max = 2097152
net.ipv4.tcp_max_syn_backlog = 8192
net.core.netdev_max_backlog = 16384
net.core.somaxconn = 32768
net.ipv4.tcp_fin_timeout = 15
net.ipv4.tcp_tw_reuse = 1
net.ipv4.ip_local_port_range = 10240 65535

# Буферы приема и отправки TCP (до 16 МБ под длинные RTT-маршруты)
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216

# Защита от SYN-флуда
net.ipv4.tcp_syncookies = 1
EOF

sysctl --system

Проверьте применение BBR в работающем ядре:

sysctl net.ipv4.tcp_congestion_control
# Ожидаемый вывод: net.ipv4.tcp_congestion_control = bbr

Шаг 2. Развертывание 3X-UI и защита портов

Для развертывания используется поддерживаемый форк 3X-UI (репозиторий MHSanaei), включающий последние релизы ядра Xray с нативной поддержкой протокола Reality и механизма xtls-rprx-vision.

Запустите официальный скрипт автоматизированной установки:

bash <(curl -Ls https://raw.githubusercontent.com/mhsanaei/3x-ui/master/install.sh)

В интерактивном диалоге инсталлятора задайте параметры безопасности: 1. Change internal port? — выберите y и укажите нестандартный порт из диапазона приватных портов (например, 54321 или 49152–65535). Использование стандартного порта 2053 запрещено: сканеры Shodan и Censys массово сканируют этот порт на наличие интерфейсов веб-панелей. 2. Setup username & password — задайте криптостойкие учетные данные (минимум 16 псевдослучайных символов). 3. Web base path — обязательно укажите секретный URL-префикс (например, /mgmt-route-x82/). Это предотвратит обнаружение веб-сервиса автоматическими сканерами корневых URI (/ или /login).

Настройте межсетевой экран ufw, открыв только системный SSH, управляющий порт панели и порт 443 для входящих VLESS-подключений:

ufw default deny incoming
ufw default allow outgoing
ufw allow 22/tcp
ufw allow 54321/tcp
ufw allow 443/tcp
ufw --force enable

После завершения службы веб-интерфейс будет доступен по адресу http://<IP_СЕРВЕРА>:54321/mgmt-route-x82/.

Шаг 3. Инженерия маскировки Reality: выбор SNI и генерация ключей

Принцип работы VLESS-Reality заключается в перенаправлении неавторизованного TLS-трафика (активных зондов цензуры) на реальный сторонний веб-сайт (fallback destination). При этом клиент использует протокол uTLS, точно имитирующий ClientHello браузера Google Chrome или Safari.

Критерии подбора стороннего SNI-домена (маскировки): 1. Поддержка TLS 1.3 и ALPN h2: Целевой сервер обязан поддерживать TLS 1.3 и отдавать HTTP/2 или HTTP/3. Если целевой сервер согласовывает только HTTP/1.1 или TLS 1.2, активный зонд сетевого фильтра зафиксирует несоответствие профилю современного браузера. 2. Сетевая близость (RTT) к VPS: Целевой сайт должен физически обслуживаться в том же регионе/дата-центре, где расположен ваш VPS (минимальный ping и latency p99 < 15 мс между сервером и маскируемым хостом). Разница в задержке между рукопожатием с прокси и оригинальным сайтом выдает туннель. 3. Отсутствие HTTP-редиректов на корневом адресе: Сервер должен отдавать код 200 OK на запрос GET /. Редиректы 301 Moved Permanently или 302 Found усложняют валидацию зондов. 4. Сертификаты крупных УЦ: Домен должен иметь валидный сертификат от Let's Encrypt, DigiCert или Google Trust Services с поддержкой OCSP Stapling.

Тестирование кандидата в терминале через curl:

curl -Iv --http2 https://gateway.icloud.com 2>&1 | grep -E "ALPN|SSL connection|HTTP/"

Примеры надежных SNI для серверов в Европе и США: gateway.icloud.com, swdist.apple.com, addons.mozilla.org, images.unsplash.com.

Генерация ключевой пары x25519 через бинарный файл xray:

xray x25519

Команда выдаст приватный (Private key) и публичный (Public key) ключи. Приватный ключ остается в конфигурации ядра на сервере, публичный ключ вносится в клиентские конфигурации.

Сгенерируйте уникальный Short ID (шестнадцатеричная строка из 8 или 16 символов):

openssl rand -hex 8

Шаг 4. Настройка входящего соединения (Inbound) в 3X-UI

В веб-интерфейсе перейдите в раздел Inbounds (Подключения) и нажмите Add Inbound:

  • Remark: VLESS-Reality-443
  • Protocol: vless
  • Listening IP: 0.0.0.0
  • Port: 443 (использование любого другого порта разрушает маскировку Reality, так как легитимный HTTPS-трафик на внешние SNI идет строго по 443 порту)
  • Network: tcp
  • Security: Reality
  • Flow: xtls-rprx-vision (критически важный параметр: активирует прямое соединение без повторного шифрования и устраняет TLS-in-TLS сигнатуры)
  • uTLS: chrome
  • Dest (Fallback): gateway.icloud.com:443
  • Server Names (SNI): gateway.icloud.com
  • Private Key: вставьте сгенерированный ранее Private key
  • Short IDs: вставьте сгенерированный hex-код (например, a1c3e4b7890f1234)
  • SpiderX: оставьте пустым или укажите /

Сохраните конфигурацию и перезапустите ядро Xray через меню панели.

Шаг 5. Конфигурация клиентских приложений

После добавления пользователя скопируйте строку подключения vless:// или откройте QR-код в панели 3X-UI. Клиенты импортируют конфигурацию с автоматическим заполнением параметров Reality.

v2rayN (Windows)

  1. Скопируйте ссылку vless:// в буфер обмена.
  2. В интерфейсе v2rayN нажмите Ctrl + V для импорта.
  3. Откройте свойства добавленного узла (клавиша Enter):
  4. Проверьте, что в поле Core type указан Xray.
  5. Поле Flow должно содержать строго xtls-rprx-vision.
  6. В блоке Reality убедитесь в наличии publicKey, sni и fingerprint: chrome.
  7. Включите режим маршрутизации: System Proxy -> Set System Proxy и Routing Rules -> Bypass mainland/direct.

NekoBox / Nekoray (Windows, Linux, Android)

  1. Выберите ядро Sing-box или Xray в меню предпочтений (Preferences -> Core -> Xray).
  2. Импортируйте URL через меню Server -> Add profile from clipboard.
  3. В настройках профиля включите галочку Multiplexing в состояние Disabled (MUX категорически несовместим с VLESS Reality xtls-rprx-vision и демаскирует поток).
  4. Активируйте TUN Mode для перехвата всего системного трафика на уровне виртуального сетевого адаптера wintun (Windows) или интерфейса ядра tun (Linux).

Streisand (iOS)

  1. Скопируйте vless:// в буфер и откройте приложение Streisand.
  2. Нажмите + в правом верхнем углу, подтвердите импорт из буфера.
  3. Перейдите в конфигурацию узла, проверьте блок TLS:
  4. Reality: включен.
  5. Flow: xtls-rprx-vision.
  6. SNI / Peer: совпадает с адресом маскировки.
  7. uTLS: Chrome или Safari.
  8. Запустите туннель и проверьте сетевой статус.

FoXray (iOS, iPadOS, macOS)

  1. Нажмите иконку QR-кода или импортируйте через буфер обмена.
  2. Откройте детальные настройки соединения:
  3. Проверьте соответствие полей Server Address (IP вашего VPS), Port (443), User ID (UUID из 3X-UI).
  4. В разделе Reality Security Configuration проверьте наличие Public Key, Short ID и Server Name.
  5. Параметр Flow обязан иметь значение xtls-rprx-vision.
  6. Подключитесь и протестируйте соединение встроенным бенчмарком RTT: тест пинга должен отправлять реальный TCP SYN на порт 443 с замером задержки первого пакета.

Развертывание подписочного сервиса Marzban в Docker Compose

Выбирая между панелями управления на VPS для VLESS Reality (3X-UI vs Marzban), системные инженеры отдают предпочтение Marzban при необходимости жесткого контроля над клиентскими подписками, биллингом и мультипротокольной раздачей конфигураций. В отличие от монолитной архитектуры 3X-UI, где веб-интерфейс на Go напрямую управляет процессом ядра через локальные вызовы и требует регулярных рестартов или прямой работы с SQLite, Marzban разделяет плоскость управления (Control Plane) и плоскость пересылки данных (Data Plane).

Архитектура: FastAPI, Uvicorn и IPC-взаимодействие с Xray-core

Платформа Marzban состоит из двух ключевых компонентов: 1. Control Plane (Бэкенд): Асинхронное приложение на Python (FastAPI, SQLAlchemy, Uvicorn с циклом событий uvloop). Отвечает за REST API, веб-интерфейс, генерацию динамических подписок (V2Ray Base64, Clash.Meta / Mihomo, Sing-box), учет биллинга и интеграцию с внешними сервисами (включая Telegram-бота). 2. Data Plane (Сетевое ядро): Стандартный бинарный файл xray-core. Marzban не форкает Xray, а взаимодействует с ним через gRPC API (обычно на порту 127.0.0.1:10085).

Взаимодействие реализовано через встроенные сервисы Xray: HandlerService и StatsService. Когда администратор создает пользователя или аннулирует ключ по исчерпанию трафика/срока действия, бэкенд отправляет вызовы AddUserOperation или RemoveUserOperation через gRPC в runtime Xray. Это исключает перезапуск сетевого демона, сохраняет активные TCP-состояния других клиентов и предотвращает всплески задержек ($p99$ latency) на высоконагруженных узлах.

Подготовка ядра хоста перед запуском контейнеров

При агрегации сотен входящих VLESS Reality-соединений стандартные лимиты ядра Linux вызывают сбросы пакетов на уровне сокетов и утечки дескрипторов. Перед запуском Docker примените сетевой тюнинг в /etc/sysctl.d/99-marzban.conf:

# Увеличение буферов TCP и очереди сокетов
net.core.somaxconn = 65535
net.core.netdev_max_backlog = 16384
net.ipv4.tcp_max_syn_backlog = 8192

# Защита от исчерпания таблицы conntrack при высоких pps
net.netfilter.nf_conntrack_max = 262144

# Активация BBR и FQ для снижения jitter на трансграничных маршрутах
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr

# Лимиты файловых дескрипторов
fs.file-max = 2097152

Примените параметры командой:

sudo sysctl --system

Продакшн docker-compose.yml и конфигурация volumes

Создайте рабочую директорию /opt/marzban и настройте изоляцию ресурсов. Рекомендуется использовать режим network_mode: host для Xray-контейнера — это исключает накладные расходы docker-proxy, разгружает процессор от двойного NAT через iptables/nftables и минимизирует паразитный CPU Steal (%st) со стороны гипервизора VPS.

Разверните структуру файлов:

sudo mkdir -p /opt/marzban/{data,xray_config}
cd /opt/marzban

Создайте /opt/marzban/docker-compose.yml:

services:
  marzban:
    image: gozargah/marzban:latest
    container_name: marzban
    restart: always
    network_mode: host
    env_file: .env
    volumes:
      - /opt/marzban/data:/var/lib/marzban
      - /opt/marzban/xray_config:/var/lib/marzban/xray-core
    ulimits:
      nofile:
        soft: 65535
        hard: 65535
    deploy:
      resources:
        limits:
          memory: 1024M

Конфигурация переменных окружения (.env)

Файл .env определяет сетевые привязки, безопасность и параметры выдачи подписок. Создайте /opt/marzban/.env:

# Порт и адрес внутренней веб-панели Marzban
UVICORN_HOST = "127.0.0.1"
UVICORN_PORT = 8000
UVICORN_SSL_CERTFILE = ""
UVICORN_SSL_KEYFILE = ""

# База данных (SQLite по умолчанию, для >500 пользователей переключать на PostgreSQL)
SQLALCHEMY_DATABASE_URL = "sqlite:////var/lib/marzban/db.sqlite3"

# Безопасность
SECRET_KEY = "GENERATE_WITH_OPENSSL_RAND_HEX_32"
DOCS = False

# Настройки генерации ссылок подписки (Subscription URL)
XRAY_SUBSCRIPTION_URL_PREFIX = "https://sub.domain.com"
SUB_PROFILE_TITLE = "Private-VLESS-Cluster"
SUB_SUPPORT_URL = "https://t.me/your_support"
SUB_UPDATE_INTERVAL = 12

# Интеграция с Telegram-ботом
TELEGRAM_API_TOKEN = "1234567890:ABCdefGHIjklMNOpqrSTUvwxYZ"
TELEGRAM_ADMIN_ID = 987654321

Генерация криптографического ключа SECRET_KEY:

openssl rand -hex 32

Настройка автовыдачи клиентских подписок

Marzban закрывает ключевую проблему ручной конфигурации — фрагментацию форматов. По URL подписки https://sub.domain.com/sub/<token> сервер отдает универсальный эндпоинт.

Алгоритм работы подсистемы: 1. Запрос клиента валидируется через User-Agent. 2. Если обращается ядро Sing-box (клиенты NekoBox, SagerNet, Sing-box CLI), бэкенд на лету генерирует валидный JSON с блоками outbounds, настраивая vless-reality с актуальными publicKey и shortId. 3. Если заголовок содержит сигнатуру Clash Meta (Mihomo, Verge, Flclash), выдается структурированный YAML-конфиг с готовыми proxy-groups и правилами маршрутизации. 4. Для стандартных V2Ray-клиентов (v2rayN, v2rayNG, Streisand) возвращается массив base64-строк формата vless://....

Чтобы подписочный узел работал через HTTPS без конфликта с портом 443, выделенным под Reality SNI, используйте Nginx или Caddy на отдельном субдомене (например, sub.domain.com), проксируя входящие HTTP-запросы на 127.0.0.1:8000:

server {
    server_name sub.domain.com;
    listen 80;
    listen 443 ssl http2;

    ssl_certificate /etc/letsencrypt/live/sub.domain.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/sub.domain.com/privkey.pem;

    location / {
        proxy_pass http://127.0.0.1:8000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Интеграция с Telegram-ботом для делегирования доступа

Встроенный демон Telegram-бота в Marzban функционирует в фоновом пуле задач FastAPI. Бот устраняет необходимость ручного входа администратора в веб-панель для создания тестовых или персональных конфигов.

  1. Создание бота: Через @BotFather регистрируется новый бот, токен вносится в параметр TELEGRAM_API_TOKEN файла .env.
  2. Ограничение прав: Параметр TELEGRAM_ADMIN_ID жестко фиксирует Telegram ID администратора (узнается через @userinfobot). Доступ к генерации ключей блокируется для всех остальных аккаунтов.
  3. Автоматизация выдачи:
  4. Администратор вводит команду /new_user прямо в чате с ботом.
  5. Бот запрашивает лимит трафика (например, 50GB) и срок действия (например, 30d).
  6. Marzban создает профиль в базе данных, вызывает Xray gRPC API для добавления UUID пользователя во все активные Reality Inbounds и генерирует персональную подписочную ссылку.
  7. Готовое сообщение с кнопками быстрого импорта подписки (для iOS, Android, Windows, macOS) пересылается конечному пользователю.

Инициализация сервиса и валидация runtime-состояния

Запустите контейнеры и создайте учетную запись суперпользователя:

docker compose up -d
docker compose exec marzban marzban-cli admin create --sudo

Проверьте корректность биндинга портов и IPC-каналов:

# Проверка запуска процессов внутри контейнера
docker compose ps

# Проверка прослушивания gRPC и Xray сокетов
ss -tulpn | grep -E '(8000|10085|443)'

# Мониторинг системных журналов в реальном времени
docker compose logs -f --tail=100 marzban

При корректном развертывании в логах фиксируется успешная инициализация gRPC-клиента: Xray core connected successfully via gRPC, подтверждающая готовность ноды к обработке клиентских VLESS Reality подключений без рестартов демона.

Тюнинг ядра Linux под экстремальный трафик: BBR congestion control и sysctl

Стандартные конфигурации дистрибутивов Debian 12 и Ubuntu 22.04/24.04 рассчитаны на ненагруженные утилитарные серверы в локальных сетях с минимальной задержкой. Когда разворачивается высоконагруженный vps для vless reality 3x-ui marzban, сетевой стек ядра Linux упирается в дефолтные лимиты: арбитраж очередей пакетов по алгоритму TCP Cubic, консервативные размеры буферов сокетов (часто ограниченные 4 МБ) и жесткие лимиты файловых дескрипторов.

На трансграничных маршрутах с физическим RTT от 80 до 250 мс и неизбежной потерей пакетов (1–3% из-за перегрузки аплинков или DPI-фильтрации) поведение алгоритма TCP Cubic катастрофично: фиксируя единичный packet drop, он срезает размер окна перегрузки (cwnd) на 30–50%. Результат — деградация скорости VLESS-туннеля с 1 Гбит/с до 30–50 Мбит/с на клиента и скачки latency p99.

Физика BBR и необходимость Fair Queueing (FQ)

Алгоритм BBR (Bottleneck Bandwidth and RTT) разработки Google принципиально меняет модель управления перегрузкой. Вместо реакции на потери пакетов (loss-based congestion control) BBR непрерывно строит математическую модель соединения: 1. Вычисляет максимальную доступную полосу пропускания (max_bw), отслеживая темп доставки пакетов за последние несколько RTT. 2. Фиксирует минимальное время кругового обращения (min_rtt) за последние 10 секунд. 3. Рассчитывает оптимальный объем данных «в полете» (BDP, Bandwidth-Delay Product):
$$\text{BDP} = \text{max_bw} \times \text{min_rtt}$$

BBR поддерживает объем данных в сети ровно на уровне BDP, предотвращая заполнение буферов промежуточных маршрутизаторов (bufferbloat) и не реагируя на случайные дропы пакетов.

Для работы BBR на уровне планировщика пакетов сетевого интерфейса (qdisc) критически необходим fq (Fair Queueing). В отличие от fq_codel или pfifo_fast, алгоритм fq аппаратно реализует TCP-пейсинг (pacing) — распределяет передачу пакетов равномерно по времени в течение RTT, исключая микроберсты (microbursts). Микроберсты переполняют кольцевые буферы сетевых карт (NIC ring buffers) хоста и триггерят сброс пакетов коммутаторами провайдера.

Расчет буферов сокетов под Bandwidth-Delay Product

Чтобы TCP-сессия могла утилизировать гигабитный интерфейс на трансконтинентальном маршруте, буферы сокетов на прием (rmem) и передачу (wmem) обязаны вмещать полный BDP.

При полосе 1 Гбит/с и RTT 120 мс: $$\text{BDP} = \frac{10^9 \text{ бит/с} \times 0.12 \text{ с}}{8 \text{ бит/байт}} = 15\,000\,000 \text{ байт} \approx 14.3 \text{ МБ}$$

С учетом накладных расходов протоколов TCP/IP (до 25–30% структуры ядра sk_buff) максимальный размер буфера сокета должен составлять не менее 16–32 МБ. Значения по умолчанию в Linux (212 КБ для передачи) искусственно блокируют расширение TCP Window Scale Option (RFC 7323), физически не позволяя туннелю разогнаться.

Преодоление лимитов дескрипторов (nofile)

Каждое входящее подключение к панели 3x-ui или Marzban на базе Xray/Sing-box генерирует минимум два файловых дескриптора: входящий сокет от клиента и исходящий сокет к целевому веб-ресурсу (Reality destination / upstream). При активном мультиплексировании (Mux) или пуле из 500 активных клиентов дефолтный лимит системы nofile = 1024 исчерпывается за секунды, вызывая системную ошибку EMFILE (Too many open files) и аварийный сброс соединений демоном Xray-core.

Настройка требует одновременного подъема лимитов на трех уровнях: ядро (fs.file-max), PAM-аутентификация (limits.conf) и менеджер сервисов systemd.

Производственный конфиг /etc/sysctl.d/99-vless-bbr.conf

Создайте конфигурационный файл оптимизации ядра:

cat <<'EOF' > /etc/sysctl.d/99-vless-bbr.conf
# ====================================================================
# Тюнинг ядра Linux под VLESS/Reality (Xray / Sing-box / Marzban)
# ====================================================================

# 1. Алгоритм контроля перегрузки и планировщик пакетов
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr

# 2. Буферы приема (rmem) и передачи (wmem) под высокий BDP (до 32MB)
# формат: min default max (в байтах)
net.core.rmem_max = 33554432
net.core.wmem_max = 33554432
net.core.rmem_default = 1048576
net.core.wmem_default = 1048576
net.ipv4.tcp_rmem = 4096 1048576 33554432
net.ipv4.tcp_wmem = 4096 1048576 33554432
net.ipv4.udp_rmem_min = 8192
net.ipv4.udp_wmem_min = 8192

# 3. Очереди соединений и защита от переполнения backlog
net.core.somaxconn = 65535
net.core.netdev_max_backlog = 16384
net.ipv4.tcp_max_syn_backlog = 8192
net.ipv4.tcp_syncookies = 1

# 4. Управление жизненным циклом TCP-сокетов и TIME_WAIT
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_fin_timeout = 15
net.ipv4.tcp_slow_start_after_idle = 0
net.ipv4.tcp_max_tw_buckets = 1440000

# 5. Оптимизация задержки (low-latency) и борьба с bufferbloat сокетов
net.ipv4.tcp_notsent_lowat = 16384
net.ipv4.tcp_window_scaling = 1
net.ipv4.tcp_timestamps = 1
net.ipv4.tcp_sack = 1
net.ipv4.tcp_mtu_probing = 1

# 6. Общесистемные лимиты файловых дескрипторов
fs.file-max = 2097152
fs.nr_open = 2097152
EOF

Настройка системных лимитов процессов (Limits & Systemd)

Добавьте правила в /etc/security/limits.conf:

cat <<'EOF' >> /etc/security/limits.conf
* soft nofile 1048576
* hard nofile 1048576
root soft nofile 1048576
root hard nofile 1048576
EOF

Для корректной работы Docker-контейнеров Marzban и нативных демонов 3x-ui отредактируйте параметры systemd в /etc/systemd/system.conf и /etc/systemd/user.conf:

DefaultLimitNOFILE=1048576:1048576
DefaultLimitNPROC=512000

Применение параметров и верификация

Примените изменения ядра без перезагрузки ноды:

# Подгрузка модуля ядра (если BBR не был скомпилирован монолитно)
modprobe tcp_bbr
echo "tcp_bbr" > /etc/modules-load.d/bbr.conf

# Применение конфигурации sysctl
sysctl --system

Чек-лист аппаратной проверки

1. Проверка загрузки модуля BBR в ядре:

lsmod | grep bbr

Ожидаемый вывод: строка tcp_bbr с размером занятой памяти (например, 20480 14). Если вывод пуст, ядро Linux устарело (требуется версия $\ge 4.9$, в Debian 12 штатно идет ядро 6.1+).

2. Проверка активного qdisc и congestion control:

sysctl net.ipv4.tcp_congestion_control net.core.default_qdisc

Ожидаемый вывод:

net.ipv4.tcp_congestion_control = bbr
net.core.default_qdisc = fq

3. Инспекция живых сокетов VLESS/Reality: Выполните инспекцию сокетов входящих клиентских соединений Reality на 443 порту:

ss -tin 'sport = :443'

Анализ метрик сокета:

ESTAB 0 0 198.51.100.10:443 203.0.113.45:51234
    bbr wscale:7,7 rto:220 rtt:112.4/1.2 ato:40 mss:1460 rcvspace:14600
    cwnd:84 ssthresh:56 bytes_acked:14285040 bytes_received:412030
    delivery_rate 89.4Mbps pacing_rate 178.8Mbps minrtt:108.2

В строке состояния сокета обязаны присутствовать теги: * bbr: ядро обрабатывает поток именно этим алгоритмом. * pacing_rate: планировщик fq динамически рассчитывает скорость сброса пакетов в сетевой интерфейс. * minrtt: вычисленный BBR минимальный RTT маршрута. * rcvspace и cwnd: окно приема и перегрузки масштабированы выше стандартных лимитов.

4. Контроль дескрипторов запущенного процесса: Проверьте фактический лимит процесса Xray или Docker-контейнера:

cat /proc/$(pgrep -f "xray|sing-box" | head -n1)/limits | grep "Max open files"

Ожидаемый результат: в колонках Soft Limit и Hard Limit зафиксировано значение не ниже 1048576. Значение 1024 указывает на то, что сервис запускается через systemd-юнит без директивы LimitNOFILE=infinity или LimitNOFILE=1048576.

Чек-лист безопасности и устранение неполадок (Troubleshooting)

Эксплуатация серверной инфраструктуры обхода блокировок требует непрерывного мониторинга сетевого стека, изоляции процессов и контроля сетевых аномалий. При развертывании связки vps для vless reality 3x-ui marzban типовые ошибки конфигурации приводят либо к деанонимизации трафика через внешние резолверы, либо к блокировке хоста DPI-системами вследствие неудачной маскировки при активном зондировании.

1. Предотвращение DNS-утечек (DNS Leak Prevention) и изоляция резолвинга

DNS-утечка — первичный маркер для систем ТСПУ. Если клиентский софт или сервер выполняет стандартный системный вызов getaddrinfo() через открытый сокет UDP:53 к DNS-серверу хостинг-провайдера (Hetzner, OVH, DigitalOcean), целевой домен перехватывается провайдерским анализатором еще до инициации TLS-хендшейка.

Серверная изоляция (Server-Side)

По умолчанию демон systemd-resolved перехватывает локальный трафик на 127.0.0.53:53 и передает его апстримам из /etc/resolv.conf. Для Xray-core (внутри Marzban или 3x-ui) системный резолвер должен быть исключен из цепочки обработки целевых запросов.

Маршрутизация DNS настраивается внутри блока dns конфигурационного файла Xray с принудительным DoH (DNS over HTTPS) или DoT (DNS over TLS):

{
  "dns": {
    "servers": [
      {
        "address": "https://1.1.1.1/dns-query",
        "domains": ["geosite:geolocation-!cn"],
        "expectIPs": ["geoip:!cn"]
      },
      {
        "address": "1.1.1.1",
        "port": 53,
        "domains": ["domain:cloudflare.com"]
      }
    ],
    "tag": "dns_inbound",
    "queryStrategy": "UseIPv4"
  },
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "inboundTag": ["dns_inbound"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "port": 53,
        "network": "udp,tcp",
        "outboundTag": "dns_outbound"
      }
    ]
  }
}

Чтобы предотвратить утечки на сетевом уровне хоста, запретите нешифрованный исходящий трафик на 53-й порт для всех непривилегированных процессов через iptables:

# Блокировка утечки открытого DNS с хоста мимо туннелей
iptables -A OUTPUT -p udp --dport 53 -m owner ! --uid-owner 0 -j REJECT
iptables -A OUTPUT -p tcp --dport 53 -m owner ! --uid-owner 0 -j REJECT

Клиентская изоляция (FakeDNS)

На стороне клиентов (v2rayN, Sing-box, FoXray, Nekoray) критически важно активировать механизм FakeDNS. Клиент не выполняет резолвинг локально, а мапит доменное имя в виртуальный пул 198.18.0.0/15. Запрос передается внутри зашифрованного VLESS-туннеля, а сопоставление IP с целевым хостом происходит исключительно на удаленной стороне.

Аудит утечек с рабочей станции выполняется утилитой tcpdump на сервере:

# Проверка отсутствия открытого трафика DNS на внешнем интерфейсе (eth0)
tcpdump -nn -i eth0 udp port 53 or tcp port 53

Если при активном серфинге в выводе появляются запросы к внешним IP — цепочка изоляции нарушена.

2. Диагностика отказов: «Connection Refused» и «Bad Gateway»

Ошибки соединения в панелях 3x-ui и Marzban указывают на сбои на разных уровнях модели OSI — от транспортного L4 до межпроцессного взаимодействия через Unix-сокеты.

Клиент (TLS Hello) ──► Port 443 [TCP LISTEN?] ──► Xray Core ──► gRPC/UDS ──► Marzban / 3x-ui
                              │                         │
                     Connection Refused            Bad Gateway (502)
                     (OOM / Port conflict)         (Core Crash / Perms)

Сценарий 1: «Connection Refused» (Транспортный уровень L4)

Клиент не может установить TCP-соединение на порт 443.

  1. Смерть процесса ядра через Linux OOM Killer. На недорогих конфигурациях памяти (1–2 ГБ) пиковые скачки буферов ядра приводят к немедленному уничтожению xray-core. Проверьте системный лог: bash dmesg -T | grep -E -i "killed process|oom_reaper|xray" Решение: настройте лимиты в docker-compose.yml и задайте swap: yaml services: marzban: deploy: resources: limits: memory: 768M
  2. Конфликт биндинга портов. Проверьте, какой процесс удерживает сокет 0.0.0.0:443: bash ss -tulpn | grep ':443' Если порт занят nginx, caddy или зависшим экземпляром старого демона, VLESS-инбаунд не инициализируется.
  3. Переполнение очереди соединений (Backlog Drop). При сканировании хоста ботнетами очередь полуоткрытых соединений tcp_max_syn_backlog переполняется, и ядро отбрасывает новые SYN-пакеты. Исправьте параметры через sysctl: bash sysctl -w net.core.somaxconn=4096 sysctl -w net.ipv4.tcp_max_syn_backlog=8192

Сценарий 2: «Bad Gateway» (502 / Ошибка проксирования)

Ошибка возникает, когда веб-панель (Marzban на базе Uvicorn/FastAPI или веб-сервер 3x-ui) не может получить ответ от ядра Xray через внутренний gRPC API (127.0.0.1:10085 или Unix Domain Socket).

  • Конфликт прав Unix-сокета: Если Marzban работает в контейнере без root-прав, а сокет Xray создан с маской 0644, обмен падает с кодом 502: bash chmod 666 /var/run/xray/xray.sock
  • Фатальная ошибка синтаксиса Xray: Неверный публичный/приватный ключ Reality или синтаксическая ошибка в JSON ломает демон при рестарте: bash # Для Marzban docker compose logs --tail=100 -f marzban-node # Для 3x-ui journalctl -u x-ui -n 100 --no-pager

3. Fallback-проксирование и защита от активного зондирования (Active Probing)

Ключевое преимущество архитектуры VLESS Reality — устойчивость к активному сканированию ТСПУ (DPI). Системы цензуры фиксируют сессии с высокой энтропией и отправляют прямой зондирующий запрос на целевой IP:443 без SNI, с фейковым SNI или через обычный HTTP/1.1 GET.

Механизм Fallback в Reality

Протокол Reality анализирует TLS ClientHello. Внутренний парсер Xray проверяет наличие и валидность ShortId и факт подписи публичным ключом сервера. * Авторизованный клиент: Трафик направляется в туннель VLESS. * Цензор / Сканер: Запрос прозрачно проксируется на уровень L4 к легитимному ресурсу, указанному в директиве dest (например, dl.google.com:443 или gateway.icloud.com:443).

"streamSettings": {
  "network": "tcp",
  "security": "reality",
  "realitySettings": {
    "show": false,
    "dest": "dl.google.com:443",
    "xver": 0,
    "serverNames": [
      "dl.google.com"
    ],
    "privateKey": "YOUR_PRIVATE_KEY_HERE",
    "shortIds": [
      "0123456789abcdef",
      ""
    ]
  }
}

Что видит цензор при прямом сканировании

Если инспектор ТСПУ отправляет команду:

curl -Iv https://<YOUR_SERVER_IP>:443 --resolve dl.google.com:443:<YOUR_SERVER_IP>

Сервер отдает легитимный сертификат Google, согласовывает ALPN (h2, http/1.1), возвращает оригинальные HTTP-заголовки и стандартный ответ целевого веб-сервера. Цензор не может отличить ваш сервер от реального CDN-узла или прокси-кэша.

Критические ошибки при выборе Dest

  1. Использование заблокированного SNI: Выбор домена, который уже заблокирован по IP или SNI в локальном сегменте сети, приводит к мгновенной блокировке вашего VPS по IP.
  2. Перенаправления (301/302 Redirect): Если целевой сервер перенаправляет запросы с IP на корневой домен с другим сертификатом, DPI зафиксирует несоответствие хендшейка. Выбирайте серверы с прямым ответом HTTP 200 или 404 без сторонних редиректов.
  3. Несовпадение отпечатков TLS: Используйте только цели с поддержкой TLS 1.3 и шифров TLS_AES_128_GCM_SHA256 / TLS_CHACHA20_POLY1305_SHA256.

4. Оптимизация сетевого стека ядра Linux под высокий p99 Latency

Для предотвращения деградации пропускной способности при агрессивном шейпинге пакетов внесите изменения в /etc/sysctl.d/99-vless-tuning.conf:

# Активация BBRv3 / BBR и алгоритма планирования FQ
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr

# Включение TCP Fast Open для снижения latency хендшейков (3 = клиент + сервер)
net.ipv4.tcp_fastopen = 3

# Оптимизация буферов под высокие значения RTT
net.ipv4.tcp_rmem = 4096 87380 67108864
net.ipv4.tcp_wmem = 4096 65536 67108864

# Защита от исчерпания памяти сокетов при атаках
net.ipv4.tcp_moderate_rcvbuf = 1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_fin_timeout = 15

Примените параметры:

sysctl --system

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

Часто задаваемые вопросы (FAQ)

Сколько клиентов выдержит 1 VPS с 3X-UI или Marzban?

Сервер с 1 vCPU и 1 GB RAM на KVM легко обслуживает 15–30 одновременных активных пользователей на протоколе VLESS Reality благодаря низкому оверхеду Xray-core.

Законно ли поднимать свой VPN на арендованном VPS?

Аренда зарубежного сервера и настройка шифрованного туннеля для личных и рабочих задач полностью законна при соблюдении правил хостинг-провайдера (AUP) и законодательства страны размещения ноды.

Почему нельзя использовать бесплатные или публичные SNI?

Публичные заезженные SNI (например, google.com или cloudflare.com) часто вызывают аномалии в проверках DPI из-за несоответствия целевого IP и сертификата. Необходимо выбирать локальные незаблокированные CDN-сайты с поддержкой TLS 1.3.

Что делать, если IP-адрес сервера заблокировали?

При использовании Reality блокировка IP происходит крайне редко (в отличие от WireGuard). В случае блокировки достаточно заказать смену дополнительного IPv4 в панели хостера за $1–2 или настроить промежуточный IPv6/Cloudflare туннель.

Назад к блогу