VPN·HUB·CRACK Скрипт «4 протокола на одной ноде» (Reality + Hysteria2 + gRPC + XHTTP) · VPN HUB CRACK
Все статьи
Remnawave PRO Remnawave

Скрипт «4 протокола на одной ноде» (Reality + Hysteria2 + gRPC + XHTTP)

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

Скрипт «4 протокола на одной ноде»

Есть готовый community-скрипт, который на одной ноде Remnawave поднимает сразу четыре транспорта: VLESS-Reality, Hysteria2, VLESS-gRPC-Reality и VLESS-XHTTP-Reality. Полезно, когда не хочется держать четыре сервера ради разных сценариев обхода.

Репозиторий: Rrezzak09VPN/remnanode-VLESS-Reality-Hysteria2

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

⚠️ Это чужой скрипт, который вы запускаете от root одной строкой bash <(curl …). Так вы отдаёте серверу право выполнить любой код. Откройте setup.sh глазами перед запуском: это правило для ЛЮБОГО установщика из интернета, не только этого. Ниже разбор, что он делает на самом деле, чтобы вы понимали, на что подписываетесь.

Зачем несколько транспортов на одной ноде

У каждого свои сильные стороны, подробнее в обзоре «Какой протокол выбрать»:

Транспорт Порт Когда выручает
VLESS-Reality (TCP) 443/tcp База для РФ, маскировка под реальный TLS-сайт
Hysteria2 (QUIC) 443/udp Потери пакетов, мобильные сети, где душат TCP
VLESS-gRPC-Reality 8443/tcp Когда 443 «залип», gRPC переживает часть DPI-фильтров
VLESS-XHTTP-Reality 4443/tcp Работа за CDN и при агрессивной фильтрации

Клиент получает несколько плиток в подписке и переключается, когда один транспорт перестал ходить. Это дешёвая отказоустойчивость без второго сервера.

Что скрипт делает на самом деле

  1. Проверяет окружение: root, Docker и его daemon, наличие и статус контейнера remnanode, NetworkMode, слушает ли уже 443/tcp, есть ли серты в /etc/letsencrypt/live, статус UFW.
  2. Открывает порты в UFW под выбранные протоколы: 443/udp (Hysteria2), 8443/tcp (gRPC), 4443/tcp (XHTTP).
  3. Кладёт сертификаты в /dev/shm: копирует fullchain.pem и privkey.pem в /dev/shm/hysteria_cert.pem и /dev/shm/hysteria_key.pem, ставит chmod 644.
  4. Ставит две cron-задачи: синхронизацию сертов @reboot (со sleep 15 и рестартом ноды) и ежедневно в 0 4 * * *.
  5. Перезапускает remnanode, если серты изменились.

Идемпотентность частичная, но разумная: правила UFW проверяются перед добавлением, серты сравниваются через cmp -s, cron не дублируется (crontab -l | grep -q). Повторный запуск не ломает.

⚠️ Главные грабли: скрипт НЕ монтирует серты в контейнер

Самое важное, что легко пропустить читая README. Скрипт кладёт серты в /dev/shm на хосте и лишь проверяет, есть ли /dev/shm среди маунтов контейнера:

docker inspect remnanode --format '{{json .Mounts}}' | grep -q '/dev/shm'

Сам он docker-compose.yml не трогает. Если маунта нет, xray внутри контейнера сертов не увидит, Hysteria-inbound не соберётся, и нода будет «работать», но трафика по Hysteria не будет. Добавьте маунт руками в /opt/remnanode/docker-compose.yml:

    volumes:
      - '/dev/shm:/dev/shm'
cd /opt/remnanode && docker compose down && docker compose up -d

В конфиг-профиле панели пути к серту тогда указываются как /dev/shm/hysteria_cert.pem и /dev/shm/hysteria_key.pem.

Зачем серты в /dev/shm, а не как обычно

/dev/shm это tmpfs, то есть RAM, а не диск. Отсюда две особенности, которые объясняют всю конструкцию:

  • Плюс: приватный ключ не лежит на диске, а контейнеру не нужно монтировать всю папку Let's Encrypt с её симлинками live → ../../archive (частая причина «серт есть, а xray его не видит», см. Hysteria2).
  • Минус, и он же причина @reboot-крона: tmpfs очищается при перезагрузке. Без крона после ребута серты исчезнут и Hysteria молча отвалится. Поэтому в задаче стоит sleep 15, чтобы дать Docker подняться раньше, чем мы дёрнем docker restart remnanode.

💡 Проверка после ребута: ls -l /dev/shm/hysteria_*.pem. Пусто: крон не отработал, смотрите crontab -l и логи.

Что скрипт за вас НЕ закроет

Он готовит транспорт и серты, но конфиги протоколов вы всё равно заводите в панели. Вот ловушки, на которых спотыкаются чаще всего: они не в README, но стоят вам рабочей ноды.

1. Reality с dest/serverNames на www.microsoft.com: не заработает

На xray 26.6.27 и новее Reality с donor-доменом Microsoft ломается: TLS-запись их сертификата (8273 байт) больше хардкод-лимита парсера в 8192 байта, «стилить» серт не выходит, и аутентифицированное рукопожатие падает.

Коварство в том, что нода выглядит живой: - openssl s_client -connect NODE:443 -servername www.microsoft.com вернёт настоящий серт Microsoft ✅ (неаутентифицированная проба просто проксируется); - а реальный клиент с правильными ключами получит EOF / failed to find an available destination.

Легко принять за битый ключ или uuid. Фикс: сменить donor на www.cloudflare.com (или apple.com, dl.google.com): и в dest, и в serverNames, с обеих сторон каскада. Подробнее читайте в конфигах инбаундов.

2. Hysteria2 «видна, но не пингуется» → alpn должен быть h3

Hysteria2 работает поверх HTTP/3, сервер отдаёт ALPN h3. Если в хосте панели прописан alpn: ["h2"], общего ALPN нет, QUIC-рукопожатие рвётся, клиент показывает «нет пинга» при полностью исправном сервере. Проверяйте хост, а не сервер.

Ещё из практики диагностики Hysteria: слушатель ищется через ss -ulnp | grep :443 (UDP, не -tln: на TCP будет пусто и вы решите, что ничего не слушает), а процесс xray внутри ноды называется rw-core, поэтому pgrep xray ничего не найдёт.

3. Нода падает с SPAWN_ERROR после правки конфига

Если после добавления инбаунда панель отдаёт SPAWN_ERROR: xray или 500, xray падает на старте, и настоящая причина не в логе панели:

docker exec remnanode tail -30 /var/log/supervisor/xray.out.log

Там прямым текстом будет, на чём споткнулись: недоступный серт, неизвестный ключ в streamSettings, занятый порт 443, отсутствующие geo-файлы. После серии падений supervisord уходит в FATAL: too many start retries, тогда docker restart remnanode и подождите ~30 секунд, пока панель пере-синхронит ноду.

4. Для РФ: отпечаток firefox, а не chrome

В настройках клиента/хоста для российской аудитории ставьте fingerprint: firefox (или qq). Это мелочь, которая заметно влияет на выживаемость Reality под ТСПУ, см. Защита от блокировок.

Порядок действий по-человечески

  1. Нода уже добавлена в панель Remnawave и в статусе running.
  2. Выпустите серт на домен ноды (A-запись → IP ноды, свободный порт 80): рецепт в статье про Hysteria2.
  3. Добавьте - '/dev/shm:/dev/shm' в volumes ноды и перезапустите контейнер. Это шаг, который скрипт не сделает.
  4. Запустите скрипт (предварительно прочитав его): он откроет порты, разложит серты в RAM и поставит cron.
  5. Заведите инбаунды в конфиг-профиле панели: готовые рабочие JSON есть в «Все рабочие конфиги». Donor-домен не должен быть microsoft.
  6. Соберите хосты: Hysteria с alpn: h3, Reality с fingerprint: firefox.
  7. Переимпортируйте подписку у клиента и проверьте все четыре плитки.

🚀 Не хотите возиться со скриптами и конфигами? MultiScript поднимает ноду с нужным протоколом по одной форме: Reality-ключи, shortId и профиль в панели создаются автоматически, без ручных правок compose и cron.

Итого

Скрипт экономит рутину: порты, серты в RAM, cron, рестарт. Он не заменяет понимание конфигов и не монтирует /dev/shm за вас, а это ровно тот шаг, без которого Hysteria тихо не заработает. Прочитайте его перед запуском, добавьте маунт руками и держите в голове три ловушки выше: donor-домен, alpn: h3 и xray.out.log как единственное место, где написана правда о падении ноды.