BungeeCord или Velocity: связка серверов

Момент, когда одного сервера становится мало, наступает по-разному. У кого-то выживание уже не тянет 80 человек и хочется вынести мини-игры отдельно. Кто-то устал каждый раз перезапускать весь проект ради одного плагина на творческом мире. А кто-то просто хочет, чтобы игрок заходил на один адрес и попадал в лобби с порталами.

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

Что вообще делает прокси

Прокси не хранит миры и не считает физику. Он держит соединение с клиентом и пересылает пакеты на нужный бэкенд-сервер. Игрок видит один IP, а внутри может быть пять процессов Minecraft на разных портах — лобби, выживание, креатив, мини-игры, тестовый.

Отсюда все плюшки: переход между серверами без переподключения (/server survival), общий чат и личные сообщения, единый список игроков, возможность перезапустить один сервер, не выкидывая всех остальных.

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

BungeeCord: заслуженный ветеран

BungeeCord появился в 2012 году от команды SpigotMC и почти десять лет был единственным вариантом. Waterfall — форк от Paper с патчами производительности — какое-то время был стандартом де-факто, но в 2024-м PaperMC официально прекратили его развитие и рекомендовали переходить на Velocity.

Сильная сторона BungeeCord — экосистема. Пятнадцать лет плагинов: BungeeGuard, LuckPerms-Bungee, старые системы банов, самописные штуки на форумах 2016 года. Если у вас проект с легаси или нужен конкретный редкий плагин — вероятно, он есть только под Bungee.

Слабых сторон больше. Однопоточная обработка сетевых событий упирается в потолок примерно на 400–600 одновременных соединений. Архитектура API устарела, обновления под новые версии протокола выходят с задержкой. И главное — модель безопасности изначально дырявая: IP forwarding в BungeeCord никак не подписывается, поэтому любой, кто узнает адрес и порт вашего бэкенда, может подключиться к нему напрямую от имени любого ника, включая админский.

Лечится это плагином BungeeGuard плюс жёстким файрволом. Но лечится вручную, и про это регулярно забывают.

Velocity: то, что стоит брать сейчас

Velocity написали в 2018-м с нуля, специально чтобы починить архитектурные проблемы Bungee. К 2026 году это дефолтный выбор для новых проектов.

Что он даёт по сравнению с BungeeCord:

Как именно работает modern forwarding и чем он лучше legacy-режима, описано в документации PaperMC.

Ограничение одно: плагины для Bungee не работают на Velocity, нужны нативные версии. Впрочем, всё живое и нужное давно портировано — LuckPerms, ViaVersion, MiniMOTD, Signed Velocity, LimboAuth.

Вывод простой: новый проект — Velocity. Существующая связка на Bungee, которая работает и не растёт — можно не трогать. Растущий проект на Bungee — планируйте миграцию, она делается за вечер.

Настройка Velocity: пошагово

Понадобится свежая Java и отдельный процесс под прокси. Минимальную версию Java смотрите в официальном руководстве Velocity: требования растут вместе с версиями прокси, на момент обновления статьи это Java 25.

1. Скачайте Velocity с papermc.io/downloads/velocity, положите в отдельную папку и запустите:

java -Xms1G -Xmx1G -XX:+UseG1GC -jar velocity.jar

Прокси памяти почти не ест: официальный стартовый скрипт выделяет 1 ГБ, и этого хватает даже на большой проект. Всю остальную память отдавайте бэкендам.

2. Правьте velocity.toml. Ключевые секции:

bind = "0.0.0.0:25565"
motd = "&aМой сервер"
show-max-players = 100
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", "survival"]

[forced-hosts]
"mc.example.ru" = ["lobby"]

Прокси занимает публичный порт 25565, бэкенды сидят на внутренних 25566+ и слушают только localhost.

3. Настройте бэкенды. В server.properties каждого сервера:

online-mode=false
server-ip=127.0.0.1
server-port=25566

online-mode=false на бэкенде не означает пиратский сервер — авторизацию берёт на себя прокси, у которого online-mode = true. Но именно поэтому бэкенды обязаны быть недоступны снаружи.

4. Включите modern forwarding на Paper. В config/paper-global.yml:

proxies:
  velocity:
    enabled: true
    online-mode: true
    secret: сюда_содержимое_forwarding.secret

Секрет копируется из файла forwarding.secret, который Velocity создаёт при первом запуске. Не совпал — игроки будут получать «Unable to connect you, you are not connecting through a proxy».

5. Закройте порты. На Linux:

ufw allow 25565/tcp
ufw deny 25566:25570/tcp

Если бэкенды на одной машине и слушают 127.0.0.1 — снаружи они и так недоступны. Если разнесены по машинам, файрвол обязателен.

Пошаговый разбор конфигов есть в справке по настройке Velocity, для старой связки — по настройке BungeeCord.

Три ошибки, на которых горят все

Бэкенды торчат в интернет. Самая частая и самая дорогая. Кто-то сканирует диапазон IP хостера, находит открытый 25566 с online-mode=false, заходит ником вашего админа и выносит сервер. Проверить просто: попробуйте подключиться к ваш-ip:25566 со своего компьютера. Подключилось — вы уязвимы.

Разные версии на бэкендах. Прокси не конвертирует протокол. Если лобби на 1.21.4, а выживание на 1.20.1, игрок при переходе получит кик. Держите одинаковые версии либо ставьте ViaVersion на каждый бэкенд.

UUID и права разъезжаются. При неправильном форвардинге бэкенд видит игрока с офлайн-UUID, а не с настоящим. Результат: пропавшие инвентари, слетевшие права, дубли в базе LuckPerms. Всегда проверяйте после настройки: зайдите и выполните /lp user Ник info — UUID должен совпадать с реальным mojang-UUID. Про сами права — в разборе настройки LuckPerms.

Сколько это стоит по ресурсам

Связка — это не бесплатно. Каждый бэкенд держит свою JVM со своей кучей, и суммарно вы потратите больше памяти, чем на один большой сервер.

Прикидка для проекта на 40 онлайна:

Это больше 8 ГБ, которые ушли бы на один сервер с тем же онлайном. Взамен вы получаете изоляцию: лаги на мини-играх не роняют TPS выживания, потому что это разные процессы на разных ядрах. Для проектов с разнородным контентом обмен выгодный. Если у вас один режим и 20 человек — прокси не нужен, это лишний слой. Общие подходы к производительности разобраны в статье про оптимизацию сервера Minecraft.

Миграция с BungeeCord на Velocity

Занимает примерно вечер. Порядок такой:

1. Поднять Velocity рядом, на другом порту, не трогая Bungee.
2. Перенести список серверов из config.yml в velocity.toml.
3. Найти Velocity-версии плагинов. LuckPerms, ViaVersion, MiniMOTD есть нативно; для чего-то экзотического — искать аналог.
4. Переключить бэкенды на modern forwarding: включить секцию proxies.velocity в config/paper-global.yml и выставить settings.bungeecord: false в spigot.yml.
5. Проверить на тестовом бэкенде: заход, переход между серверами, права, UUID.
6. Поменять порты местами, Bungee остановить.

Откат простой: вернуть settings.bungeecord: true в spigot.yml, выключить proxies.velocity и поднять старый прокси обратно.

Итог

Velocity выигрывает почти по всем пунктам: производительность, безопасность форвардинга, скорость поддержки новых версий. BungeeCord имеет смысл, только если вы держитесь за конкретный неперенесённый плагин. И независимо от выбора — первым делом закройте бэкенды от внешнего мира, это не опциональный шаг.

Под связку нужен запас памяти и несколько ядер — на слабой одноядерной виртуалке прокси-схема смысла не имеет. Что брать под такой проект, видно в тарифах на игровые серверы.