VPN·HUB·CRACK
Скрипт «4 протокола на одной ноде» (Reality + Hysteria2 + gRPC + XHTTP) · VPN HUB CRACK
Скрипт «4 протокола на одной ноде» (Reality + Hysteria2 + gRPC + XHTTP)
Скрипт «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 и при агрессивной фильтрации |
Клиент получает несколько плиток в подписке и переключается, когда один транспорт перестал ходить. Это дешёвая отказоустойчивость без второго сервера.
Что скрипт делает на самом деле
- Проверяет окружение: root, Docker и его daemon, наличие и статус контейнера
remnanode, NetworkMode, слушает ли уже443/tcp, есть ли серты в/etc/letsencrypt/live, статус UFW. - Открывает порты в UFW под выбранные протоколы:
443/udp(Hysteria2),8443/tcp(gRPC),4443/tcp(XHTTP). - Кладёт сертификаты в
/dev/shm: копируетfullchain.pemиprivkey.pemв/dev/shm/hysteria_cert.pemи/dev/shm/hysteria_key.pem, ставитchmod 644. - Ставит две cron-задачи: синхронизацию сертов
@reboot(соsleep 15и рестартом ноды) и ежедневно в0 4 * * *. - Перезапускает
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 под ТСПУ, см. Защита от блокировок.
Порядок действий по-человечески
- Нода уже добавлена в панель Remnawave и в статусе
running. - Выпустите серт на домен ноды (A-запись → IP ноды, свободный порт 80): рецепт в статье про Hysteria2.
- Добавьте
- '/dev/shm:/dev/shm'вvolumesноды и перезапустите контейнер. Это шаг, который скрипт не сделает. - Запустите скрипт (предварительно прочитав его): он откроет порты, разложит серты в RAM и поставит cron.
- Заведите инбаунды в конфиг-профиле панели: готовые рабочие JSON есть в «Все рабочие конфиги». Donor-домен не должен быть microsoft.
- Соберите хосты: Hysteria с
alpn: h3, Reality сfingerprint: firefox. - Переимпортируйте подписку у клиента и проверьте все четыре плитки.
🚀 Не хотите возиться со скриптами и конфигами? MultiScript поднимает ноду с нужным протоколом по одной форме: Reality-ключи, shortId и профиль в панели создаются автоматически, без ручных правок compose и cron.
Итого
Скрипт экономит рутину: порты, серты в RAM, cron, рестарт. Он не заменяет понимание конфигов и не монтирует /dev/shm за вас, а это ровно тот шаг, без которого Hysteria тихо не заработает. Прочитайте его перед запуском, добавьте маунт руками и держите в голове три ловушки выше: donor-домен, alpn: h3 и xray.out.log как единственное место, где написана правда о падении ноды.