BungeeCord и Velocity: сеть Minecraft-серверов

MAATRIX GAMES

Есть лобби, есть выживание, есть отдельный сервер под мини-игры — и три раза объяснять игрокам, какой IP куда вбивать, уже надоело. Решение — не три отдельных проекта, а один вход и прокси-сервер, который тихо перекидывает игрока между "мирами" без переподключения к игре заново. Разберём, как это работает на BungeeCord и Velocity, чем они отличаются и как всё это настроить, не сломав ничего на живом проекте.

Зачем вообще нужна прокси-сеть

Без прокси у вас просто несколько независимых серверов Minecraft, каждый со своим IP и портом. Игрок, чтобы перейти с лобби на выживание, обязан выйти из игры и подключиться заново — это неудобно и разрывает саму идею "единого проекта": нет общего онлайна, нет команды /server, нет единого баланса или прав между частями сети.

Прокси-сервер (BungeeCord или Velocity) решает это иначе: игрок подключается один раз к прокси по одному адресу, а тот сам маршрутизирует соединение на нужный бэкенд-сервер — прозрачно, включая переключение между "мирами" командой /server <имя> или через плагин с меню-лобби, без выхода в главное меню клиента. С точки зрения игрока это один сервер с несколькими зонами; с точки зрения администратора — несколько независимых процессов Java, каждый следит только за своим куском.

Плюс прокси даёт то, чего изнутри одного сервера не получить: общий онлайн-счётчик по всей сети, единую защиту от DDoS и ботов на входе, распределение нагрузки (лобби отдельно от тяжёлого выживания с редстоуном и фермами), и возможность перезапускать один бэкенд-сервер, не отключая всю сеть. Если вы ещё не поднимали базовый Minecraft-сервер — начните с инструкции по установке сервера Minecraft, прокси-сеть имеет смысл добавлять уже поверх работающих бэкендов, а не вместо них.

Честно: это усложняет администрирование. Вместо одного процесса вы следите за несколькими, конфигов и логов становится больше, а часть плагинов (экономика, чат, права) нужно синхронизировать между серверами отдельно. Ставить прокси ради одного-единственного сервера смысла нет — это инструмент именно под сеть из двух и более логических серверов за одним входом.

BungeeCord: проверенная временем классика

BungeeCord — прокси-платформа от команды SpigotMC (тот же разработчик md_5, что стоял у истоков Spigot), существует с 2013 года и остаётся самым распространённым решением просто в силу возраста и охвата плагинов. Написан под старую модель обработки сети, из-за чего под реальной нагрузкой (тысячи одновременных подключений, частые переключения между серверами) периодически упирается в однопоточные узкие места — для небольших и средних сетей это на практике не критично.

Официальные сборки собираются через CI md-5.net, готового jar-файла с постоянной ссылкой на "последнюю версию" там нет — берётся конкретный номер сборки:

mkdir -p ~/proxy && cd ~/proxy
wget https://ci.md-5.net/job/BungeeCord/lastSuccessfulBuild/artifact/bootstrap/target/BungeeCord.jar

Запуск ничем не отличается от обычного сервера — тот же java -jar, только имя файла другое:

java -Xms512M -Xmx1G -jar BungeeCord.jar

Памяти прокси нужно немного — он не хранит мир и не считает физику, только маршрутизирует пакеты и держит список игроков, поэтому 512 МБ-1 ГБ хватает даже на сеть в пару сотен онлайна.

Главный плюс BungeeCord — колоссальная библиотека плагинов на SpigotMC, накопленная за больше чем десятилетие: кросс-серверный чат, синхронизация экономики через Redis (например, RedisBungee), античит на уровне прокси, защита от бот-атак на подключение. Если ищете конкретное узкое решение под сеть — велика вероятность, что под BungeeCord оно уже написано и проверено годами эксплуатации.

Velocity: современная архитектура от PaperMC

Velocity — более новый прокси от той же команды, что делает Paper (проект PaperMC), написан с нуля под современную асинхронную модель Netty и рассчитан на высокие нагрузки больших сетей, где через прокси одновременно проходят тысячи подключений. Разработчики Velocity позиционируют его как более производительный и стабильный под нагрузкой вариант по сравнению с BungeeCord, хотя точные цифры зависят от конкретной сети, плагинов и железа — ориентируйтесь на это как на общее направление, а не гарантированный процент прироста.

Скачивается через тот же API, что и Paper — фиксированную ссылку на "последний билд" удобнее получать через API-эндпоинт PaperMC:

mkdir -p ~/proxy && cd ~/proxy
wget https://api.papermc.io/v2/projects/velocity/versions/3.4.0/builds/latest/downloads/velocity-3.4.0-latest.jar -O velocity.jar

Актуальную версию 3.x стоит свериться на papermc.io/downloads/velocity — номера сборок и версий там обновляются регулярно.

Запуск:

java -Xms512M -Xmx1G -jar velocity.jar

При первом запуске Velocity сам создаёт velocity.toml и forwarding.secret — про них ниже.

Минус у Velocity один, но заметный: плагинная экосистема моложе и меньше, чем у BungeeCord. Часть популярных BungeeCord-плагинов на Velocity либо не работает вообще, либо требует прослойки совместимости, которая покрывает не весь API. Перед миграцией проверьте на странице нужного плагина в Hangar (hangar.papermc.io) или SpigotMC, поддерживается ли Velocity нативно.

BungeeCord или Velocity: что выбрать

Практическое правило: если у вас уже есть сеть на BungeeCord с набором рабочих плагинов, специально мигрировать на Velocity ради самой миграции обычно не стоит — только если реально упираетесь в производительность прокси под нагрузкой. Если сеть строится с нуля на Paper-бэкендах — Velocity логичнее как более современный и лучше интегрированный вариант, при условии что все нужные плагины под него есть или легко заменяются аналогами.

Настройка прокси: config.yml и velocity.toml

Оба прокси на старте создают конфиг с одним обязательным разделом — списком бэкенд-серверов и портом, на который заходят игроки.

BungeeCord, файл config.yml:

listeners:
- query_port: 25577
  motd: '&bМоя сеть серверов'
  host: 0.0.0.0:25577
  max_players: 200
  force_default_server: false
  priorities:
  - lobby
servers:
  lobby:
    motd: '&aЛобби'
    address: localhost:25566
    restricted: false
  survival:
    motd: '&aВыживание'
    address: localhost:25567
    restricted: false
  minigames:
    motd: '&aМини-игры'
    address: localhost:25568
    restricted: false

Здесь host — порт, на который клиенты Minecraft подключаются к сети (25577 — конвенция BungeeCord, но подойдёт и 25565, если хотите привычный порт для игроков). servers — список бэкендов с внутренними адресами: обратите внимание, что адреса указаны на localhost — если прокси и бэкенды крутятся на одной машине, наружу торчит только прокси, а бэкенды доступны лишь изнутри. priorities задаёт сервер, на который попадает игрок при первом входе в сеть.

Velocity, файл velocity.toml:

bind = "0.0.0.0:25577"
motd = "<#55ffff>Моя сеть серверов"
show-max-players = 200
online-mode = true
player-info-forwarding-mode = "modern"
forwarding-secret-file = "forwarding.secret"

[servers]
lobby = "127.0.0.1:25566"
survival = "127.0.0.1:25567"
minigames = "127.0.0.1:25568"
try = ["lobby"]

try — аналог priorities у BungeeCord: сервер по умолчанию для нового подключения. player-info-forwarding-mode = "modern" — рекомендованный режим передачи данных игрока (UUID, скин, реальный IP) от прокси к бэкенду через защищённый секрет из файла forwarding.secret, который Velocity генерирует сам при первом запуске — этот же секрет нужно будет прописать на каждом бэкенд-сервере.

Настройка бэкендов: приём соединений именно от прокси

Это шаг, на котором чаще всего спотыкаются — бэкенд-сервер по умолчанию не доверяет прокси и либо не примет форвардинг данных игрока, либо (что хуже) останется доступен напрямую в обход прокси, если порт торчит наружу.

Для BungeeCord на каждом бэкенде (Spigot/Paper) правим spigot.yml:

settings:
  bungeecord: true

И в server.properties того же бэкенда обязательно отключаем встроенную проверку лицензии — её теперь делает прокси на входе:

online-mode=false

Для Velocity на бэкендах Paper правим config/paper-global.yml:

proxies:
  velocity:
    enabled: true
    online-mode: true
    secret: 'содержимое-файла-forwarding.secret'

Значение secret должно дословно совпадать с содержимым forwarding.secret, который сгенерировал Velocity — проще всего скопировать файл на каждый бэкенд или вставить его содержимое напрямую. online-mode: true в этом блоке означает не проверку лицензии самим бэкендом (её всё ещё делает прокси), а то, что бэкенд доверяет данным игрока, пришедшим через modern forwarding.

Дальше — обязательный шаг безопасности для обеих схем: бэкенд-серверы не должны быть доступны из интернета напрямую, иначе прокси-настройка обходится тривиально — кто угодно подключается прямо на 25566/25567 в обход авторизации прокси. В файрволе открываем публично только порт прокси, а порты бэкендов режем для всех, кроме локального интерфейса:

sudo ufw allow 25577/tcp
sudo ufw deny 25566/tcp
sudo ufw deny 25567/tcp
sudo ufw deny 25568/tcp

Если бэкенды и прокси на разных машинах — вместо deny настраивайте разрешение только с IP-адреса машины с прокси, а не полный запрет.

Плагины и синхронизация между серверами

Сеть из нескольких серверов почти сразу поднимает вопрос: как сделать так, чтобы экономика, права и чат были общими, а не отдельными на каждом бэкенде. Прокси сам этого не делает — маршрутизация подключений и синхронизация игровых данных это разные задачи.

Рабочая практика — общая база данных (обычно MySQL) для плагинов вроде LuckPerms (права) и EssentialsX или Vault-совместимой экономики, плюс Redis для мгновенной синхронизации онлайн-статусов между процессами — например, RedisBungee для BungeeCord-сетей. LuckPerms из коробки умеет работать через общую базу сразу на несколько серверов сети — один из немногих плагинов, действительно рассчитанных на такой сценарий. Базовую установку плагинов на бэкенд мы разбирали отдельно — см. Bukkit и Spigot плагины: с чего начать, логика с plugins/ и config.yml применима и к бэкендам сети.

Кросс-серверный чат и целиковое меню выбора сервера (GUI-лобби с иконками) обычно закрывают отдельные плагины уровня прокси — под BungeeCord это, например, ChatControl или BungeeChat, под Velocity — их аналоги из экосистемы Hangar. Ставятся они не в plugins/ бэкенда, а в plugins/ самого прокси-процесса — это отдельная папка рядом с BungeeCord.jar/velocity.jar.

Частые вопросы