BungeeCord или Velocity: прокси для Minecraft

Для новой сети Minecraft берите Velocity. Это прокси, который поддерживает и рекомендует PaperMC, его режим modern forwarding защищает бэкенды без дополнительных плагинов, и на одно ядро он держит больше игроков, чем BungeeCord. BungeeCord по-прежнему поддерживается и по-прежнему обслуживает большую часть сетей в мире, и остаться на нём есть ровно одна веская причина: плагин, без которого вы не можете обойтись и у которого нет сборки под Velocity. Если это не про вас, переезд займёт полдня - новый конфиг, одна настройка на каждом бэкенде и ревизия плагинов, - и эта статья проводит через него, заодно честно разбирая различия между двумя прокси.

Полная настройка Velocity - каждая строка velocity.toml, общие права, forced hosts - описана в руководстве по сети на Velocity. Здесь - сравнение и переезд.

Что делают оба прокси и чем они различаются#

Обе программы одного типа. Игрок подключается к прокси, прокси один раз проверяет его через Mojang, затем открывает собственное соединение с бэкенд-сервером и пересылает пакеты в обе стороны. Переход между серверами - это когда прокси закрывает одно соединение с бэкендом и открывает другое, а соединение игрока при этом не рвётся. Ни один прокси ничего не симулирует: на прокси нет ни миров, ни блоков, ни сущностей, поэтому памяти ему нужно совсем немного.

Различия сосредоточены в четырёх местах:

Forwarding - различие, которое важнее всех остальных и которое понимают хуже всего. Ему посвящён отдельный раздел ниже, потому что именно от него зависит, сможет ли кто угодно зайти на ваши бэкенды напрямую, найдя их порт.

API плагинов несовместимы. Плагин для BungeeCord не загрузится на Velocity, плагин для Velocity не загрузится на BungeeCord, а плагины Paper не загрузятся ни там, ни там. Большинство крупных сетевых плагинов - LuckPerms, Geyser и Floodgate, ViaVersion, основные плагины чата и банов - выпускают сборки для обоих. Маленькие или заброшенные плагины часто существуют только для BungeeCord, который появился ещё в 2013 году.

Производительность на стороне Velocity. Он написан с нуля поверх Netty, в Linux использует нативные библиотеки сжатия и шифрования и делает меньше работы на каждый пакет. На практике это редко важно, пока одновременно играют меньше нескольких сотен человек: тогда любой прокси простаивает на доле ядра. Разница проявляется в больших сетях и у хостеров, где у каждого процесса жёсткий лимит CPU.

Конфигурация - в основном упражнение в переводе. Понятия - слушатели, список серверов, порядок подключения, forced hosts, порог сжатия - есть в обоих, просто под разными именами.

Waterfall закрыт, и что это значит для вас#

Waterfall был форком BungeeCord от PaperMC с исправлениями производительности и дополнительными настройками. Многие сети, которые считают, что работают «на BungeeCord», на самом деле работают на Waterfall. PaperMC прекратил разработку Waterfall и отправляет всех на Velocity. Он по-прежнему запускается, но обновлений больше не получает, а значит, не будет ни поддержки новых версий протокола Minecraft, ни исправлений безопасности.

Если вы сейчас на Waterfall, вариантов два: вернуться на оригинальный BungeeCord, который читает почти такой же config.yml и запускает те же плагины, или перейти на Velocity. Вернуться на BungeeCord - шаг поменьше; перейти на Velocity - шаг, который не придётся повторять. Раз уж вы всё равно будете трогать каждый бэкенд, сделайте это один раз.

Forwarding: разница в безопасности#

Когда игрок подключается через прокси, бэкенд видит соединение с адреса прокси, а не игрока. Без дополнительных мер каждый игрок приходил бы с IP прокси и UUID офлайн-режима, а это ломает баны, скины и все плагины, которые хранят данные по UUID. Forwarding - это способ, которым прокси сообщает бэкенду, кто на самом деле игрок.

ip_forward в BungeeCord

BungeeCord делает это, дописывая к handshake реальный адрес игрока, его UUID и свойства профиля. Включается это через ip_forward: true в config.yml прокси и settings.bungeecord: true в spigot.yml каждого бэкенда.

Проблема в том, что бэкенд никак не может проверить, что данные пришли именно от вашего прокси. Он верит всему, что написано в handshake. Поскольку бэкенды работают с online-mode=false (аутентификацию выполнил прокси), любой, кто может достучаться до порта бэкенда напрямую, может отправить поддельный handshake, представившись любым игроком, в том числе оператором, и бэкенд его пустит. Это не теоретическая уязвимость: есть публичные инструменты, которые делают ровно это, а открытые бэкенды BungeeCord сканеры находят за считаные часы.

Исправлений два: файрвол, который пускает к бэкендам только прокси, или BungeeGuard - пара плагинов, которая добавляет к передаваемым данным секретный токен, чтобы бэкенды отклоняли соединения без него. На машине, которой вы управляете сами, файрвол надёжнее. У хостера с панелью, где каждый сервер - отдельный контейнер со своим публичным портом, закрыть собственные бэкенды файрволом от интернета обычно нельзя, и BungeeGuard становится обязательным.

Modern forwarding в Velocity

Режим modern в Velocity передаёт те же данные о личности игрока внутри пакета, подписанного секретом, общим для прокси и каждого бэкенда. Paper проверяет подпись и отклоняет всё, у чего нет корректной подписи, ещё до завершения входа. Игрок, который нашёл адрес бэкенда и подключился напрямую, получает кик. Ни файрвола, ни дополнительного плагина.

Цена - совместимость: modern forwarding нужен бэкенд, который его понимает, то есть Paper 1.13 или новее либо бэкенд на Fabric или NeoForge с модом для совместимости с прокси. Для старых бэкендов у Velocity есть legacy (в стиле BungeeCord, с той же уязвимостью) и bungeeguard (legacy плюс токен BungeeGuard).

Конфиги рядом#

Типичный config.yml BungeeCord, сокращённый до той части, которая переносится:

online_mode: trueip_forward: truenetwork_compression_threshold: 256connection_throttle: 4000player_limit: -1listeners:- host: 0.0.0.0:25565  motd: '&bThe Longhouse Network'  max_players: 200  force_default_server: true  priorities:  - lobby  forced_hosts:    survival.example.com: survival  ping_passthrough: false  query_enabled: falseservers:  lobby:    address: 10.0.0.11:25566    restricted: false    motd: 'Lobby'  survival:    address: 10.0.0.12:25567    restricted: false    motd: 'Survival'

И та же сеть в velocity.toml:

bind = "0.0.0.0:25565"motd = "<aqua>The Longhouse Network"show-max-players = 200online-mode = trueplayer-info-forwarding-mode = "modern"forwarding-secret-file = "forwarding.secret"[servers]lobby = "10.0.0.11:25566"survival = "10.0.0.12:25567"try = ["lobby"][forced-hosts]"survival.example.com" = ["survival"][advanced]compression-threshold = 256login-ratelimit = 3000

Как соотносятся ключи:

Два поведения отличаются так, что это застаёт людей врасплох. Во-первых, force_default_server: true в BungeeCord при каждом входе отправляет игрока на первый сервер по приоритету; Velocity при первом подключении всегда использует список try и не запоминает последний сервер, если этого не делает плагин. Во-вторых, BungeeCord поставляется с простой системой прав в config.yml (блоки groups и permissions, с md_5 в качестве примера администратора). У Velocity её нет: без плагина прав доступ к админским командам есть только у консоли. Ставьте LuckPerms на прокси в рамках переезда, а не после него.

Переезд с BungeeCord на Velocity по шагам#

Заложите короткое окно простоя. На бэкендах нужно поменять одну настройку и перезапустить их, а принимать оба вида forwarding одновременно они не умеют.

1. Проведите ревизию плагинов прокси. Перечислите все jar-файлы в папке plugins BungeeCord и найдите для каждого сборку под Velocity. Где её нет, найдите замену или решите, что обойдётесь. Сделайте это первым: именно на этом шаге переезд может остановиться.
2. Проверьте версии и ядра бэкендов. Для modern forwarding нужен Paper 1.13 или новее. Бэкенды на Spigot стоит перевести на Paper - он читает те же миры и запускает те же плагины. Всё, что старше 1.13, остаётся на forwarding legacy или bungeeguard.
3. Установите Velocity рядом с BungeeCord. Положите velocity.jar в новую папку, запустите его один раз, чтобы он сгенерировал velocity.toml и forwarding.secret, и остановите.
4. Переведите конфиг по таблице соответствий выше. Сохраните имена серверов из BungeeCord: плагины на бэкендах, которые отправляют игроков по имени (lobby, survival), продолжат работать, если имена не поменяются.
5. Установите плагины прокси, найденные на шаге 1, начиная с LuckPerms. Если LuckPerms на BungeeCord уже работал с общей базой данных, направьте копию на Velocity на ту же базу, и всё перенесётся само.
6. Остановите сеть. Сначала BungeeCord, потом каждый бэкенд.
7. Переключите каждый бэкенд. В spigot.yml задайте settings.bungeecord: false. В config/paper-global.yml заполните блок Velocity и вставьте секрет. Если на бэкенде стоял BungeeGuard, удалите его.
8. Запустите Velocity на публичном порту, затем бэкенды. Следите в консоли Velocity за ошибкой forwarding, описанной в разделе об устранении проблем.
9. Проверьте прямые подключения к каждому бэкенду и убедитесь, что их отклоняют.
10. Не трогайте папку BungeeCord неделю. Откат - это шаг 7 в обратную сторону и запуск старого jar.

Изменение на бэкенде из шага 7 выглядит так:

settings:  bungeecord: false

proxies:  bungee-cord:    online-mode: true  velocity:    enabled: true    online-mode: true    secret: 'paste-the-contents-of-forwarding.secret'

В версиях Paper до 1.19 эти настройки находились в paper.yml, а не в config/paper-global.yml, в разделе settings.velocity-support. Если ваши бэкенды настолько старые, прежде чем править путь из какого-нибудь гайда, проверьте, какой файл у вас на самом деле.

Plugin messaging и плагины бэкендов#

Многие плагины на бэкендах общаются с прокси через канал plugin messaging BungeeCord: меню выбора сервера, таблички со счётчиком игроков, плагины мини-игр, которые возвращают игроков в лобби. Их писали под BungeeCord, и на Velocity они продолжают работать, потому что Velocity реализует этот канал. В velocity.toml это bungee-plugin-message-channel = true в разделе [advanced], включено по умолчанию.

Не переносится всё, что рассчитывало на присутствие плагина BungeeCord на прокси. Если плагину бэкенда нужен парный плагин на прокси, у этого парного плагина тоже должна быть сборка под Velocity. Ищите «Velocity support» на странице каждого плагина до ночи переезда, а не во время неё.

Вторая частая зависимость - трансляция версий. Сеть на BungeeCord, которая пускает клиентов нескольких версий, обычно держит ViaVersion (а иногда ViaBackwards и ViaRewind) на прокси или на бэкендах. У ViaVersion есть сборка для Velocity, и с тем же успехом он может стоять на каждом бэкенде Paper; где именно - дело вкуса, лишь бы не в обоих местах сразу.

Игроки Bedrock через Geyser и Floodgate работают с любым прокси. На Velocity ставьте Geyser и Floodgate на прокси, а Floodgate ещё и на каждый бэкенд, с одним и тем же key.pem, чтобы бэкенды узнавали игроков Floodgate, - подробности в руководстве по Geyser.

Команды и администрирование#

Админские команды пересекаются, но не совпадают полностью, и это важно для привычек персонала и для любых скриптов или Discord-ботов, которые отправляют команды в консоль прокси.

/velocity reload действительно полезен: он подхватывает добавленные и удалённые в velocity.toml серверы, никого не выкидывая. Перезагрузке BungeeCord никогда нельзя было доверять, и большинство администраторов BungeeCord вместо неё перезапускают прокси, что отключает всю сеть.

У каждой команды Velocity есть свой узел прав (velocity.command.server, velocity.command.glist, velocity.command.send), поэтому выдаются они через LuckPerms на прокси, а не в конфиге.

Сколько ресурсов нужно прокси у хостера с панелью#

Ни один из прокси не тяжёлый. Полгигабайта heap с запасом хватает любому из них на несколько сотен игроков; основная работа - это время CPU на сжатие и шифрование трафика. Прокси на тарифе 1-2 ГБ с одним ядром - нормальное дело. Деньги уходят на бэкенды.

$ java -Xms512M -Xmx512M -XX:+UseG1GC -jar velocity.jar

Сеть у любого хостера с панелью - это один сервер на процесс: прокси плюс лобби плюс два режима - это четыре сервера, у каждого свой лимит памяти, порт и резервные копии. В RE:NODE каждый тариф Minecraft идёт с одним выделенным портом, а дополнительные можно добавить на вкладке Network; реквизиты SFTP у каждого сервера свои, и так вы разносите один и тот же forwarding.secret по всем бэкендам, не перепечатывая его. Каждый сервер - отдельный контейнер со своим публичным портом, поэтому проверка прямого подключения из раздела о forwarding - не формальность: именно modern forwarding закрывает эти порты бэкендов от самозванцев. Общие соображения о таком разделении нагрузки - в статье CPU или RAM для игровых серверов.

Когда прокси заработает, дайте ему имя с помощью записей A и SRV, чтобы игроки вводили mc.example.com и больше ничего, - точная запись есть в статье SRV-записи для Minecraft.

Проблемы при переходе#

Velocity пишет «Your server did not send a forwarding request to the proxy». Бэкенд не настроен на modern forwarding: proxies.velocity.enabled всё ещё false, отредактирован не тот файл для этой версии Paper, или бэкенд не перезапустили.

Игроков выкидывает с «Unable to verify player details» или ошибкой декодера. Секрет на бэкенде не совпадает с forwarding.secret. Поищите лишний перевод строки или пробел, попавший при копировании.

«If you wish to use IP forwarding, please enable it in your BungeeCord config as well!» Это бэкенд сообщает, что в его spigot.yml всё ещё стоит bungeecord: true, а прокси не присылает данные в стиле BungeeCord. На Velocity с modern forwarding выставьте false.

Все заходят как новые игроки. Forwarding выключен или стоит в режиме none, поэтому бэкенды видят UUID офлайн-режима. Никого не пускайте играть, пока это не исправлено: каждый вход создаёт данные игрока, которые потом придётся вычищать.

Плагин, который работал на BungeeCord, ничего не делает. Это был плагин BungeeCord, лежащий в папке plugins у Velocity. При запуске Velocity пишет в лог, что не смог его загрузить; прокрутите выше.

Персонал потерял админские команды. Права раздавали группы в config.yml BungeeCord. Выдайте узлы Velocity через LuckPerms. В руководстве по LuckPerms показано, как ограничить их прокси с помощью контекста server.

FAQ#

BungeeCord всё ещё поддерживается?

Да. md_5 обновляет его под новые версии Minecraft, и он по-прежнему широко используется. Он не заброшен; просто по умолчанию он менее безопасен и медленнее Velocity, а его forwarding требует файрвола или BungeeGuard, чтобы быть безопасным.

Можно ли запускать плагины BungeeCord на Velocity?

Нет. У них разные API плагинов. Ищите сборку каждого плагина под Velocity; у большинства популярных сетевых плагинов она есть. Плагины бэкендов, которые пользуются только каналом сообщений BungeeCord, продолжают работать.

Нужно ли что-то менять на бэкендах при переезде?

Да, по одному переключателю на каждом: выключить bungeecord в spigot.yml, включить поддержку Velocity в глобальном конфиге Paper и вставить секрет forwarding. Миры, плагины и данные игроков остаются как есть.

Мои бэкенды на 1.12.2. Можно ли всё равно использовать Velocity?

Да, с forwarding legacy или bungeeguard вместо modern. Встроенную защиту вы теряете, поэтому добавьте BungeeGuard или держите бэкенды недоступными из интернета - те же меры предосторожности, что нужны и BungeeCord.

Заметят ли игроки переезд?

Только простой и, если вы его поменяли, MOTD. Адрес остаётся прежним, UUID остаются прежними, если forwarding был правильным до и после, а имена серверов можно не менять, чтобы существующие меню выбора продолжили работать.

Безопасно ли и дальше держать Waterfall?

Он работает, но больше не получает ни обновлений протокола, ни исправлений безопасности. Переходите на Velocity или обратно на BungeeCord до выхода следующей версии Minecraft, которую хотите поддерживать.