VPN·HUB·CRACK
Маркет 0 ₽ +
Выйти?
VPN·HUB·CRACK Каскад: вход в РФ, чистый выход · VPN HUB CRACK
Все статьи
Remnawave PRO Remnawave

Каскад: вход в РФ, чистый выход

Обновлено 11 августа 2026 Проверено

Каскад (multihop)

ОБНОВЛЕНИЕ 5–6 июня 2026: каскад снова критически актуален. С 5–6 июня РКН начал активно резать VLESS-TCP (raw): прямые TCP-ноды либо не подключаются, либо рвутся и тормозят. Рабочих вариантов сейчас два: ① каскад по схеме ниже (RU-вход → загран-выход), он оживает там, где прямой TCP лёг; ② Hysteria2 (QUIC/UDP, TCP-фильтры его не трогают, см. «Профили подключений»). Мы перевесили свои каскады по этой схеме 5–6 июня, и они ожили. Если ваши прямые ноды встали в эти даты, переходите на каскад или Hysteria2.

Каскад это цепочка из двух (и более) нод: клиент → вход → выход → интернет. Клиент видит только IP входа, а сайты видят только IP выхода. Это даёт три вещи сразу:

  1. Живучесть. Заблокировали вход, меняете только его, выход и ключи клиентов не трогаются.
  2. Чистый выход. Вход это дешёвый «расходник» рядом с РФ, а выход это IP «хорошего» ASN, которому доверяют сервисы (меньше капч/«VPN detected»).
  3. Гибридный роутинг. На каскаде российские сервисы (банки, госуслуги) можно оставлять с российским IP входа, а всё иностранное гнать через заграничный выход.

📖 Незнакомые слова? Все термины простыми словами есть в Словаре терминов.

Рабочая 2-уровневая схема

Два независимых каскада + клиентский автовыбор между ними:

Каскад Вход (в РФ) Выход (за рубеж) Роль
Каскад 1 RU-вход 🇳🇱 NL-выход основной
Каскад 2 RU-вход 🇩🇪 DE-выход резерв/балансировка
  • На входе настроен серверный роутинг: geosite:category-ru и список банков/госуслуг → direct (выходят с российского IP входа), всё остальное → на заграничный выход.
  • Клиент получает «Автовыбор»: он пингует оба входа и гонит трафик через быстрейший (см. статью «Балансировщики»). Куда выйти наружу решает сам каскад на ноде.

Принцип: вход это расходник, выход это актив. Один выход может принимать много входов (fan-in): жжём входные IP пачками, выход и аккаунты живут.

Как каскад устроен в Xray

Цепочка строится через proxySettings на outbound (поле tag указывает на «верхний» outbound) или через routing (inboundTag → outbound на следующую ноду). Есть два подхода.

Подход A: «выход принимает вход» (рекомендуем)

Вход это обычная Reality-нода для клиента; её роутинг отправляет трафик VLESS-outbound'ом на выход. Выход это обычная Reality-нода, единственный «клиент» которой это вход.

Нода ВХОДА (/usr/local/etc/xray/config.json):

{
  "inbounds": [
    {
      "tag": "in-client",
      "listen": "0.0.0.0",
      "port": 443,
      "protocol": "vless",
      "settings": {
        "clients": [
          {
            "id": "UUID-КЛИЕНТА",
            "flow": "xtls-rprx-vision"
          }
        ],
        "decryption": "none"
      },
      "streamSettings": {
        "network": "tcp",
        "security": "reality",
        "realitySettings": {
          "dest": "www.cloudflare.com:443",
          "serverNames": [
            "www.cloudflare.com"
          ],
          "privateKey": "PRIVKEY-ВХОДА",
          "shortIds": [
            "",
            "0123456789abcdef"
          ]
        }
      }
    }
  ],
  "outbounds": [
    {
      "tag": "to-exit",
      "protocol": "vless",
      "settings": {
        "vnext": [
          {
            "address": "IP-ВЫХОДА",
            "port": 443,
            "users": [
              {
                "id": "UUID-ДЛЯ-СВЯЗКИ",
                "flow": "xtls-rprx-vision",
                "encryption": "none"
              }
            ]
          }
        ]
      },
      "streamSettings": {
        "network": "tcp",
        "security": "reality",
        "realitySettings": {
          "fingerprint": "firefox",
          "serverName": "www.cloudflare.com",
          "publicKey": "PUBKEY-ВЫХОДА",
          "shortId": "abcdef12"
        }
      }
    },
    {
      "tag": "direct",
      "protocol": "freedom"
    },
    {
      "tag": "block",
      "protocol": "blackhole"
    }
  ],
  "routing": {
    "rules": [
      {
        "type": "field",
        "protocol": [
          "bittorrent"
        ],
        "outboundTag": "block"
      },
      {
        "type": "field",
        "domain": [
          "geosite:category-ru",
          "domain:sberbank.ru",
          "domain:gosuslugi.ru",
          "domain:nalog.ru"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": [
          "geoip:ru",
          "geoip:private"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "inboundTag": [
          "in-client"
        ],
        "outboundTag": "to-exit"
      }
    ]
  }
}

Это и есть гибрид: РФ-сервисы выходят с российского IP (входа), а остальное уходит через заграничный выход.

Нода ВЫХОДА это обычный Reality-сервер, чей единственный клиент это вход:

{
  "inbounds": [
    {
      "tag": "in-relay",
      "listen": "0.0.0.0",
      "port": 443,
      "protocol": "vless",
      "settings": {
        "clients": [
          {
            "id": "UUID-ДЛЯ-СВЯЗКИ",
            "flow": "xtls-rprx-vision"
          }
        ],
        "decryption": "none"
      },
      "streamSettings": {
        "network": "tcp",
        "security": "reality",
        "realitySettings": {
          "dest": "www.cloudflare.com:443",
          "serverNames": [
            "www.cloudflare.com"
          ],
          "privateKey": "PRIVKEY-ВЫХОДА",
          "shortIds": [
            "abcdef12"
          ]
        }
      }
    }
  ],
  "outbounds": [
    {
      "protocol": "freedom",
      "tag": "direct"
    }
  ]
}

Важно: у входа и выхода разные serverNames/dest (microsoft на входе, cloudflare на выходе), каждое плечо самостоятельно переживает блокировку по SNI.

Подход B: «тупой релей» (вход ничего не расшифровывает)

Вход это прозрачная труба (dokodemo-door), тянет соединение к выходу через proxySettings с transportLayer:true. На входе нет клиентских ключей: низкое доверие к расходному IP.

"outbounds": [
  { "tag": "proxy1", "protocol": "vless", "settings": {/* vnext relay */},
    "streamSettings": {/* reality */} },
  { "tag": "proxy2", "protocol": "vless", "settings": {/* vnext exit */},
    "streamSettings": {/* reality */}, "proxySettings": { "tag": "proxy1", "transportLayer": true } }
]

transportLayer:true опускается до sockopt.dialerProxy, proxy2 сохраняет свой Reality-транспорт, но идёт «внутри» proxy1.

sing-box: то же через detour

В sing-box цепочка строится полем detour (указывает на «верхний» outbound):

"outbounds": [
  { "type": "vless", "tag": "hop1", "server": "relay", "server_port": 443, "uuid": "...", "tls": {/*reality*/} },
  { "type": "vless", "tag": "hop2", "server": "exit",  "server_port": 443, "uuid": "...", "tls": {/*reality*/}, "detour": "hop1" }
]

Путь: hop2 → detour → hop1 → интернет.

Когда каскад НЕ нужен

  • Где важна максимальная скорость/низкий пинг, каждый хоп это +RTT и ×2 трафик на входе. Прямая нода быстрее.
  • Каскад держите для выживания и чистого выхода, прямые ноды для скорости.

Каскад в Remnawave (на практике)

  • Вход и выход это две отдельные ноды с двумя Config Profile (RU-вход с роутингом на выход; загран-выход обычный).
  • Связка вход→выход это VLESS-outbound в конфиге входа (правится в Config Profile входа).
  • Клиенту в подписке отдаём только вход (хост на инбаунд входа); выход скрыт.
  • Автовыбор между «Каскад 1» и «Каскад 2» это клиентский балансер в шаблоне подписки (см. «Балансировщики»).

Готовый пример: RU-вход → EU-выход (vless-in → vless-out)

Два Config Profile (по одному на ноду). Заменяете только отмеченные значения (// ←). SNI-донор (your-donor.de) это любой крупный сайт с TLS 1.3, одинаковый на входе и выходе.

Config Profile ноды ВХОДА (RU):

{
  "log": { "loglevel": "none" },
  "inbounds": [
    {
      "tag": "VLESS_PUBLIC_INBOUND",            // сюда подключаются ваши клиенты
      "port": 443,
      "listen": "0.0.0.0",
      "protocol": "vless",
      "settings": { "clients": [], "decryption": "none" },   // clients заполнит панель из сквадов
      "sniffing": { "enabled": true, "destOverride": ["http", "tls", "quic"] },
      "streamSettings": {
        "network": "raw",
        "security": "reality",
        "realitySettings": {
          "target": "your-donor.de:443",         // ← SNI-донор (тот же, что на выходе)
          "shortIds": [""],
          "privateKey": "PRIVATE_KEY_RU_NODE",   // ← приватный ключ Reality ВХОДА (свой)
          "serverNames": ["your-donor.de"]       // ← = домен донора
        }
      }
    }
  ],
  "outbounds": [
    { "tag": "DIRECT", "protocol": "freedom" },
    { "tag": "BLOCK",  "protocol": "blackhole" },
    {
      "tag": "VLESS_OUTBOUND_TO_FREEDOM",        // связка ВХОД → ВЫХОД
      "protocol": "vless",
      "settings": {
        "id": "BRIDGE_USER_VLESS_UUID",          // ← VLESS-UUID пользователя bridge_user (см. ниже)
        "flow": "xtls-rprx-vision",
        "port": 443,
        "address": "de-exit.your-domain.com",    // ← домен/IP ноды-ВЫХОДА
        "encryption": "none"
      },
      "streamSettings": {
        "network": "raw",
        "security": "reality",
        "realitySettings": {
          "publicKey": "EU_NODE_PUBLIC_KEY",      // ← публичный ключ Reality ВЫХОДА
          "serverName": "your-donor.de"
        }
      }
    }
  ],
  "routing": {
    "rules": [
      { "ip": ["geoip:private"], "outboundTag": "BLOCK" },
      { "domain": ["geosite:private", "geosite:category-ads-all"], "outboundTag": "BLOCK" },
      { "protocol": ["bittorrent"], "outboundTag": "BLOCK" },
      { "ip": ["geoip:ru", "geoip:google"], "outboundTag": "DIRECT" },          // РФ + Google → напрямую с РФ-IP входа
      { "domain": ["geosite:category-ru", "geosite:youtube"], "outboundTag": "DIRECT" },
      { "inboundTag": ["VLESS_PUBLIC_INBOUND"], "outboundTag": "VLESS_OUTBOUND_TO_FREEDOM" }  // остальное → на выход
    ]
  }
}

Config Profile ноды ВЫХОДА (EU):

{
  "log": { "loglevel": "warning" },
  "inbounds": [
    {
      "tag": "VLESS_EU_INBOUND",                 // сюда подключается ТОЛЬКО вход (под именем bridge_user)
      "port": 443,
      "listen": "0.0.0.0",
      "protocol": "vless",
      "settings": { "clients": [], "decryption": "none" },   // bridge_user попадёт сюда из сквада
      "sniffing": { "enabled": true, "destOverride": ["http", "tls", "quic"] },
      "streamSettings": {
        "network": "raw",
        "security": "reality",
        "realitySettings": {
          "dest": "your-donor.de:443",           // ← тот же SNI-донор, что на входе
          "shortIds": [""],
          "privateKey": "PRIVATE_KEY_EU_NODE",   // ← приватный ключ Reality ВЫХОДА; его publicKey → в outbound входа
          "serverNames": ["your-donor.de"]
        }
      }
    }
  ],
  "outbounds": [
    { "tag": "DIRECT", "protocol": "freedom" },
    { "tag": "BLOCK",  "protocol": "blackhole" }
  ],
  "routing": {
    "rules": [
      { "ip": ["geoip:private"], "outboundTag": "BLOCK" },
      { "domain": ["geosite:private"], "outboundTag": "BLOCK" },
      { "protocol": ["bittorrent"], "outboundTag": "BLOCK" }
    ]
  }
}

Зачем нужен bridge_user и его VLESS-UUID

Нода-выход это обычная Reality-нода. Она принимает соединения только от пользователей, которых знает (список clients её инбаунда), а этот список Remnawave заполняет из сквадов. Нода-вход подключается к выходу как обычный VLESS-клиент, значит ей нужен валидный UUID пользователя, которого выход считает «своим». Этим «техническим клиентом» и служит bridge_user.

Что сделать:

  1. Создайте пользователя bridge_user (имя любое, это служебный аккаунт-мост, не для людей).
  2. Выдайте ему всё безлимитом: трафик = ∞, лимит устройств (HWID) = ∞/выключен, срок = бессрочно. Почему: через этот один аккаунт идёт агрегированный трафик ВСЕХ ваших клиентов (вход мультиплексирует их в одно соединение к выходу). Упрётся в лимит трафика или устройств, ляжет весь каскад.
  3. Добавьте bridge_user во внутренний сквад выхода (можно включить все inbound выхода), так его UUID попадёт в clients инбаунда EU-ноды.
  4. Откройте пользователя и скопируйте его VLESS-UUID.
  5. Вставьте этот UUID в конфиг RU-ноды → outbounds → VLESS_OUTBOUND_TO_FREEDOM → settings.id.
Служебные пользователи bridge_user в панели
Служебные пользователи bridge_user_*: все ACTIVE, трафик ∞ (объёмы скрыты), каждый привязан к своему скваду-выходу («Каскад 1», «Каскад 2» и т.д.). По одному мосту на каждый каскад.
VLESS UUID пользователя bridge_user
Карточка пользователя → «Информация о подключении»: копируете VLESS UUID и вставляете его в id outbound'а RU-ноды. (Пароли и UUID на скрине скрыты.)

Ключевой момент vless-in → vless-out: UUID в id outbound'а входа обязан совпадать с UUID bridge_user на выходе, иначе выход отклонит соединение («нет такого клиента»). Аналогично serverName/донор и publicKey выхода должны соответствовать его privateKey.

Хитрое правило: YouTube/Google без рекламы (RU-direct)

В routing RU-входа выше есть две строки:

{ "ip": ["geoip:ru", "geoip:google"], "outboundTag": "DIRECT" },
{ "domain": ["geosite:category-ru", "geosite:youtube"], "outboundTag": "DIRECT" }

geoip:google + geosite:youtube → DIRECT значит, что трафик к Google/YouTube выходит с российского IP входа, а не через заграничный выход. Есть приятный побочный эффект, YouTube почти без рекламы: Google с марта 2022 свернул продажу рекламы в РФ, поэтому ролики, отданные на российский IP, идут практически без пре-роллов. Бонусом: не жжёте загран-трафик выхода и часто ниже пинг к Google (пиринг РФ-датацентра). ⚠️ Важно про скорость: РФ-IP убирает рекламу, но не снимает замедление: ТСПУ (российское DPI-оборудование операторов, что «замедляет») душит YouTube и на РФ-датацентрах. Чтобы видео не буферило, РФ-вход/нода под YouTube должны обходить замедление (zapret, см. «Быстрый YouTube без рекламы на отдельном РФ-хосте»).

⚠️ Нюанс: YouTube в РФ замедляют (ТСПУ режет маршрут к Google-CDN). Если у конкретного входа YouTube тормозит, у его хостера «плохой» маршрут к Google: возьмите другой РФ-хостер/IP. На хороших датацентровых маршрутах получаете и скорость, и отсутствие рекламы. Кому скорость важнее рекламы, уберите geosite:youtube/geoip:google из DIRECT, тогда YouTube пойдёт через загран-выход (быстро, но с рекламой).

Каскад на будущее: зарубежный трафик могут сделать платным

Обсуждается, что мобильные операторы РФ начнут тарифицировать зарубежный трафик отдельно. Каскад это обходит «в лоб»: оператор видит, что вы коннектитесь к российскому IP входа (донор вида yandex.ru, IP в РФ), для него вы не сидите на зарубежном сервисе, тарифицировать нечего. Самое забавное: за зарубежный трафик в итоге заплатит российский ДЦ, где стоит ваш вход. То есть ценность каскада со временем только вырастет.

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

Соблазн «собрать свой сервер и сэкономить деньги и нервы» есть, но для выходных нод, к которым подключаются клиенты, ответ категорически нет. Через такую ноду идёт чужой трафик: если кто-то полезет на запрещённый контент (вплоть до CSAM), запросы пойдут с вашего IP, и «дяденька полицейский» придёт интересоваться к вам, даже если делали это не вы. Отмазка «это я VPN-сервис поднял» положение только усугубит (это осознанное предоставление канала).

  • Свои/дешёвые серверы только под панель, сайт, бота или релей-вход без расшифровки (то, через что не ходит клиентский выходной трафик).
  • Выходные ноды только нормальный зарубежный хостинг с внятным abuse-процессом (см. «Где брать серверы»).

Экономия: «чистому» IP каскад может не понадобиться

Если вам достался «чистый» IP (см. «Чистые IP» и MultiRoller), необязательно вешать на него каскад. У крупных ДЦ обычно нет ограничений на WhatsApp/Telegram (а вот на YouTube частенько есть, что иронично). Выгода двойная:

  • Экономите на отдельной зарубежной ноде-выходе;
  • При «глушилках» клиенты не сольют ваши гигабайты на YouTube (за который платите вы), он просто не пойдёт через этот канал.

Дальше про балансировщики: как раздать нагрузку и собрать «Автовыбор» по нескольким каскадам.

Связанные статьи
⚡СУПЕР-АВТОВЫБОР 🔗РФ-релей (socat) 🧭Маршрутизация 🚑Заблокировали IP?