Настройка BungeeCord: jar, config.yml и бэкенды

Настройка BungeeCord состоит из четырёх шагов: скачайте BungeeCord.jar со сборочного сервера md_5, запустите его один раз, чтобы он создал config.yml, укажите в этом файле ваши бэкенд-серверы и измените три настройки на каждом бэкенде, чтобы он принимал игроков через прокси и никого больше. Первые три шага занимают минут десять. Четвёртый - то место, где сети взламывают, потому что бэкенд BungeeCord доверяет любой личности, которую заявляет соединение, так что он должен быть недоступен из интернета либо защищён BungeeGuard.

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

Что делает BungeeCord, а что нет#

BungeeCord - это прокси, который говорит на протоколе Minecraft. Игроки подключаются к нему, он один раз проверяет их через Mojang, затем открывает собственное соединение с бэкенд-сервером и пересылает пакеты в обе стороны. Команда /server survival заставляет прокси закрыть соединение с лобби и открыть соединение с survival, пока соединение самого игрока остаётся живым. В этом весь фокус: несколько отдельных серверов Minecraft, один адрес и никаких отключений при переходе между ними.

У прокси нет мира, он не обрабатывает сущности и не запускает плагины Bukkit. Из этого следуют три вещи, которые люди обнаруживают на горьком опыте:

• Плагины не переносятся. Плагины Paper и Spigot ставятся на бэкенды. В папку plugins прокси попадают только плагины BungeeCord - собранные под API BungeeCord.
• Данные игроков хранятся на каждом бэкенде отдельно. Инвентари, дома, балансы и ops.json лежат на каждом бэкенде сами по себе. Прокси ничего из этого не разделяет.
• Версии он не переводит. Клиент и бэкенд, на который он попадает, должны говорить на одном протоколе. BungeeCord принимает широкий диапазон версий клиента на своём входе, но клиент 1.21 всё равно не сможет играть на бэкенде 1.20, если где-то в цепочке нет ViaVersion.

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

Требования и размер#

Прокси лёгкий. Он тратит процессор на сжатие и шифрование и очень мало памяти на всё остальное.

Запускайте на актуальной версии Java. Исторически jar был нетребователен, но свежие сборки ориентируются на современную Java, а раз вашим бэкендам на Paper для текущих версий Minecraft всё равно нужна Java 21, используйте Java 21 и для прокси, чтобы думать только об одной среде выполнения. JVM-флаги Minecraft и версии Java рассказывает, какая Java подходит к какой версии игры.

Деньги уходят на бэкенды. Сеть из прокси, лобби и двух режимов - это четыре процесса, у каждого свой лимит памяти, и лобби должно быть самым маленьким из бэкендов, потому что оно почти ничего не симулирует.

Скачивание официального BungeeCord.jar#

У BungeeCord один официальный источник: сервер сборок Jenkins от md_5 по адресу ci.md-5.net, ссылка на который есть на сайте SpigotMC. Файл называется BungeeCord.jar, а последняя успешная сборка всегда лежит по постоянному пути:

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

Установщика и шага BuildTools нет - в отличие от самого Spigot, jar прокси распространяется готовым к запуску. Не берите «BungeeCord download» с зеркал на случайных хостингах. Часть из них просто устарела, а некоторые раздавали изменённые jar. Если страница предлагает jar BungeeCord с номером версии в имени файла, он не от md_5.

Waterfall, форк, который вы ещё встретите в старых руководствах, больше не развивается. Не начинайте на нём новую сеть.

Первый запуск и создаваемые файлы#

Запустите прокси один раз с небольшим heap:

$ java -Xms512M -Xmx512M -jar BungeeCord.jar

Он создаст свои файлы, займёт порт по умолчанию и будет ждать. Введите end в консоли, чтобы корректно остановить его. Теперь у вас есть:

Два значения по умолчанию в созданном файле сбивают с толку почти всех. Listener занимает порт 25577, а не 25565, а пример записи сервера указывает на localhost:25565. Такая схема предполагает, что вы перенесёте существующий сервер Minecraft с 25565 и поставите прокси перед ним на другом порту - большинству нужно наоборот, поэтому поменяйте оба значения. Значение max_players у listener по умолчанию равно 1; оно влияет только на число в списке серверов, но из-за него рабочая сеть выглядит сломанной.

config.yml, ключ за ключом#

Вот полная рабочая конфигурация прокси с тремя бэкендами на одной машине. Комментарии отмечают ключи, которые нужно изменить.

online_mode: trueip_forward: truenetwork_compression_threshold: 256connection_throttle: 4000connection_throttle_limit: 3player_limit: -1timeout: 30000log_commands: falselog_pings: falseprevent_proxy_connections: falselisteners:- host: 0.0.0.0:25565  motd: '&bThe Longhouse Network'  max_players: 200  tab_list: GLOBAL_PING  tab_size: 60  force_default_server: true  priorities:  - lobby  forced_hosts:    survival.example.com: survival  ping_passthrough: false  query_enabled: false  query_port: 25565  proxy_protocol: false  bind_local_address: trueservers:  lobby:    address: 127.0.0.1:25566    motd: 'Lobby'    restricted: false  survival:    address: 127.0.0.1:25567    motd: 'Survival'    restricted: false  creative:    address: 127.0.0.1:25568    motd: 'Creative'    restricted: false

Блок listener

listeners - это список, и почти в каждой сети в нём ровно одна запись.

• host - адрес и порт, которые занимает прокси. 0.0.0.0:25565 означает все интерфейсы на стандартном порту. На хостинге с панелью он должен совпадать с выданным вам порядком выделения портов.
• motd и max_players - то, что показывает список серверов. Цветовые коды используют &.
• priorities - упорядоченный список серверов, на которые игрока пробуют отправить при входе. Побеждает первый, кто его принял. Каждое имя здесь должно существовать в servers и быть написано точно так же, иначе игроки получат ошибку fallback из раздела об устранении неполадок.
• force_default_server: true отправляет каждого игрока на первый сервер из приоритетов при каждом входе. При false модуль reconnect в BungeeCord возвращает игрока на сервер, где он был в последний раз, - это подходит сети, где в центре survival, и не подходит сети, где в центре лобби.
• forced_hosts сопоставляет имя хоста, которое ввёл игрок, с сервером, так что survival.example.com пропускает лобби. Для каждого имени хоста нужна DNS-запись, указывающая на прокси.
• ping_passthrough: true показывает в списке MOTD и число игроков бэкенда вместо собственных данных прокси. Оставьте false, если нет причин поступить иначе.
• tab_list принимает GLOBAL_PING, GLOBAL или SERVER. SERVER позволяет каждому бэкенду управлять своим списком вкладки, чего и ждут tab-плагины на бэкендах.
• proxy_protocol: true нужен только тогда, когда перед BungeeCord стоит что-то вроде HAProxy или TCP-балансировщика, который отправляет заголовки протокола PROXY. Включите его без этого - и все соединения будут падать.

Глобальные ключи

• online_mode: true - прокси проверяет игроков через Mojang. Оставьте включённым. Выключение создаёт пиратскую сеть, где любой может войти под чужим именем.
• ip_forward: true - передаёт бэкендам реальный IP, UUID и скин каждого игрока. По умолчанию выключено, и при выключенном параметре каждый игрок приходит на бэкенды с адресом прокси и UUID офлайн-режима. Включите; он работает в паре с настройкой бэкенда из следующего раздела.
• network_compression_threshold: 256 - пакеты крупнее этого числа байт сжимаются. Значение по умолчанию подходит для трафика к игрокам.
• connection_throttle и connection_throttle_limit - сколько входов может сделать один IP за окно времени, заданное в миллисекундах. Увеличьте лимит, если многие игроки сидят за одним адресом, например в школе или на LAN-вечеринке.
• player_limit: -1 - жёсткий предел на весь прокси, -1 означает отсутствие предела. Отличается от max_players, которое задаёт только отображаемое число.
• timeout: 30000 - через сколько миллисекунд молчащее соединение будет разорвано.

Блок servers

Каждая запись состоит из имени, address и флага restricted. Имя используют /server <name> и priorities, а также плагины на бэкендах, когда отправляют игроков между серверами, поэтому выбирайте короткие имена в нижнем регистре и не переименовывайте их без нужды. restricted: true означает, что игроку для подключения нужно право bungeecord.server.<name> - удобно для билд-сервера только для персонала.

Query и встроенные права

query_enabled включает протокол запросов GameSpy4, который используют некоторые сайты со списками серверов и боты статуса, на UDP-порту query_port. Большинство сетей оставляют его выключенным. Если вы его включаете, порт будет UDP, а на хостинге с фиксированными выделениями он должен быть тем, который у вас действительно есть - порты игровых серверов объясняет, зачем нужны query-порты.

В созданном файле также есть блок groups с md_5 в качестве примера администратора и блок permissions, который даёт группе default команды /server и /glist. Эта крошечная встроенная система работает, но ничего не знает о рангах. Удалите запись md_5, при желании добавьте своё имя в admin и планируйте заменить её на LuckPerms на прокси - руководство по LuckPerms показывает, как ограничивать права прокси контекстом server.

Что изменить на каждом бэкенде#

Каждый бэкенд - обычный сервер Spigot или Paper. Меняются три файла.

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

settings:  bungeecord: true

settings:  connection-throttle: -1

Зачем нужна каждая:

• online-mode=false обязателен. Прокси уже проверил игрока; бэкенд в online-режиме попытался бы сделать это снова, и прокси отказывает с сообщением Server is online mode!.
• bungeecord: true в spigot.yml заставляет бэкенд читать переданные IP и UUID, которые отправляет ip_forward. Без него игроки получают UUID офлайн-режима и теряют свои данные в тот момент, когда вы позже это исправите.
• connection-throttle: -1 в bukkit.yml отключает ограничение частоты входов на бэкенде. Все входы идут с адреса прокси, так что собственный throttle бэкенда иначе выкидывал бы честных игроков в напряжённые моменты с сообщением «Connection throttled».

На Paper проверьте также config/paper-global.yml (или paper.yml до 1.19): proxies.bungee-cord.online-mode должно быть true, это сообщает Paper, что личности, пришедшие через прокси, проверены. Плагины, которым важны лицензионные аккаунты, читают это значение.

Каждому бэкенду нужен свой порт, и каждый бэкенд должен работать на той же версии Minecraft, что и клиенты, которые к нему попадают, либо иметь ViaVersion. Перезапустите бэкенды после этих изменений; spigot.yml не перечитывается на лету. server.properties: разбор описывает остальные настройки, которые стоит урезать на лобби, например view-distance и spawn-protection.

Файрвол для бэкендов#

Вот почему это важно. Бэкенд с online-mode=false и bungeecord: true верит любому handshake, который утверждает, что несёт переданные данные. Любой, кто может достучаться до его порта, может подключиться с подделанным handshake, где сказано, что он ваш оператор, и бэкенд пустит его с UUID, правами и инвентарём этого игрока. Публичные инструменты делают именно это, а сканеры быстро находят открытые бэкенды.

Есть три способа закрыть дыру, по возрастанию надёжности.

1. Привязка к localhost. Когда прокси и бэкенды стоят на одной машине, server-ip=127.0.0.1 на каждом бэкенде делает их недоступными снаружи. Это самый простой и лучший вариант, и именно он используется в примере конфигурации выше.
2. Файрвол на портах. Когда бэкенды на других машинах, разрешите их порты только с адреса прокси и запретите всем остальным. Пример с ufw ниже делает именно это.
3. BungeeGuard. Когда файрвол недоступен - на большинстве общих панельных хостингов каждый сервер является отдельным контейнером со своим публичным портом - установите BungeeGuard на прокси и на каждый бэкенд. Плагин на прокси генерирует секретный токен и добавляет его к передаваемым данным; плагин на бэкенде хранит этот токен в списке allowed-tokens и отклоняет соединения без него. Идея та же, что у modern forwarding в Velocity, только прикрученная сбоку.

Для варианта 2, на бэкенде, чей прокси живёт по адресу 203.0.113.10, важен порядок правил - ufw применяет первое совпадение, поэтому разрешение идёт раньше запрета:

$ sudo ufw allow from 203.0.113.10 to any port 25566 proto tcp$ sudo ufw deny 25566/tcp

На RE:NODE каждый сервер, будь то прокси или бэкенд, - отдельный контейнер со своим публичным выделением, поэтому варианты 1 и 2 между серверами вам недоступны. Здесь нужно использовать BungeeGuard на прокси и на каждом бэкенде, а тест прямого входа выше подтверждает, что он работает. Более широкий список того, что нужно закрыть, есть в чек-листе безопасности сервера Minecraft.

Запуск, плагины и команды#

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

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

Плагины прокси кладутся в plugins/ в виде jar, и чтобы их загрузить, прокси нужно перезапустить. В BungeeCord есть команда /greload, но она не перезагружает плагины и никогда не была надёжной ни для чего, кроме списка серверов, - большинство администраторов просто перезапускают прокси, что отключает всех, так что копите изменения и перезапускайте в тихий час. Типичные плагины прокси: LuckPerms (сборка для BungeeCord), BungeeGuard, ViaVersion, если вы хотите держать его на прокси, Geyser и Floodgate для игроков Bedrock (Geyser и кроссплей с Bedrock), а также плагин сетевого чата или банов. Проверяйте, что на странице загрузки указан BungeeCord, а не Spigot - плагин Bukkit в папке прокси не загрузится и выдаст ошибку при запуске.

Плагины на бэкендах, которые отправляют игроков между серверами - меню выбора, таблички лобби, возврат в лобби из мини-игр, - общаются с прокси через канал plugin messaging BungeeCord. Им ничего не нужно устанавливать на прокси, но имена серверов в config.yml должны совпадать с теми, что вы настроили в них.

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

Устранение первых ошибок#

«If you wish to use IP forwarding, please enable it in your BungeeCord config as well!» У бэкенда в spigot.yml стоит bungeecord: true, но прокси не пересылает данные. Задайте ip_forward: true в config.yml прокси и перезапустите прокси. Это сообщение вы увидите и тогда, когда кто-то подключается к бэкенду напрямую, минуя прокси, - а если это вообще работает, значит, бэкенд доступен снаружи.

«Could not connect to a default or fallback server, please try again later», обычно с последующим Connection refused. Прокси попробовал все серверы из priorities, и никто не ответил. Проверьте по порядку: запущен ли бэкенд на самом деле; совпадает ли address в servers с server-ip и server-port бэкенда; написано ли имя в priorities точно так же, как ключ в servers; и, если бэкенд на другой машине, пропускает ли ваш файрвол прокси. Бэкенд, привязанный к 127.0.0.1, недоступен для прокси на другой машине.

`Server is online mode!` На бэкенде всё ещё online-mode=true. Поставьте false и перезапустите.

Все заходят как новые игроки без инвентаря. UUID приходят в офлайн-форме, значит, на прокси выключен ip_forward или на бэкенде выключен bungeecord. Остановитесь и исправьте это, пока не играло больше людей; каждый вход создаёт данные игрока, которые потом придётся чистить.

`Connection throttled! Please wait before reconnecting.` от бэкенда в часы пик. На бэкенде всё ещё включён connection-throttle в bukkit.yml; поставьте -1.

`Address already in use` при запуске. Порт listener занят чем-то другим, часто бэкендом, который остался на 25565 после того, как вы поставили туда прокси. Перенесите бэкенд или измените host.

`Outdated server!` или `Outdated client!` Версии клиента и бэкенда различаются. Держите каждый бэкенд на версии клиента или добавьте ViaVersion. Обновления версий Minecraft описывает, в каком порядке обновлять сеть.

Игроки заходят, но в списке серверов 1 слот. Это значение по умолчанию max_players: 1 у listener. Это косметика; поставьте то число, которое хотите показывать.

FAQ#

Где безопасно скачать BungeeCord.jar?

С Jenkins от md_5 по адресу ci.md-5.net, артефакт lastSuccessfulBuild задачи BungeeCord, на который ссылается сайт SpigotMC. Он распространяется как готовый jar без шага BuildTools. Зеркала на других сайтах не нужны, а иногда устарели или изменены.

Что выбрать для новой сети: BungeeCord или Velocity?

Velocity, если только нужный вам плагин не существует лишь для BungeeCord. Modern forwarding в Velocity подписан, поэтому бэкенды отклоняют прямые подключения без файрвола или BungeeGuard, и он обслуживает больше игроков на ядро. BungeeCord работает, но для безопасности ему нужна эта дополнительная защита.

Нужны ли бэкендам те же плагины, что и прокси?

Нет, это отдельные миры. Плагины Bukkit, Spigot и Paper ставятся на бэкенды; плагины BungeeCord - на прокси. Несколько плагинов, такие как LuckPerms, Floodgate и BungeeGuard, выпускают обе сборки и работают в обоих местах, каждый со сборкой, сделанной под него.

Почему BungeeCord по умолчанию использует порт 25577?

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

Могут ли бэкенды работать на разных версиях Minecraft?

Только если каждый клиент всё ещё может говорить с бэкендом, на который попадает. Прокси версии не переводит. Либо держите все бэкенды на одной версии, либо установите ViaVersion на прокси или на каждый бэкенд, но не туда и туда сразу.

Опасен ли офлайн-режим на бэкендах?

Сам по себе - очень. Он безопасен только тогда, когда до бэкендов нельзя добраться иначе как через прокси: они привязаны к 127.0.0.1, закрыты файрволом для адреса прокси или защищены BungeeGuard. Проверьте, зайдя на бэкенд напрямую; он должен вам отказать.