Сеть Minecraft на Velocity: лобби, выживание, миниигры

Прокси для Minecraft ставит один адрес перед несколькими серверами. Игроки подключаются к mc.example.com, попадают в лобби и переходят между миром выживания, творческим миром и сервером миниигр командой /server survival или просто шагнув в портал - без отключений, без повторного ввода адреса и без экрана загрузки с надписью «подключение к серверу». Velocity - тот прокси, который стоит выбирать. Он быстрый, активно поддерживается, а его режим modern forwarding - единственный, который безопасен из коробки.

Вот вся настройка целиком: что прокси делает и чего не делает, те строки velocity.toml, которые важны, секрет пересылки и почему на нём хотя бы раз спотыкается каждая сеть, что менять на каждом бэкенде и как делить права и чат, когда каждый бэкенд - отдельный сервер Minecraft со своим представлением о том, кто вы такой.

Зачем нужен прокси и когда он не нужен#

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

Что это даёт:

• Один адрес и один порт для сети любого размера, так что игрокам достаточно знать mc.example.com.
• Мгновенное переключение между мирами, которые являются отдельными серверными процессами, каждый со своей памятью, своими плагинами и своим tick.
• Независимое масштабирование. Сервер миниигр можно перезапустить, и никто не покинет сеть, а тормозящий мир выживания не замедляет лобби.
• Больший суммарный онлайн, чем способен тикать один процесс, потому что работа распределена между несколькими JVM.
• Единое место для общесетевых вещей: межсерверный чат, очередь, трансляция Bedrock, трансляция протокола для старых клиентов.

Чего это не даёт. Прокси не ускоряет ни один сервер: мир выживания на 40 игроков за прокси так же тяжёл, как и без него. Он не делится инвентарями, домами, балансами и достижениями; каждый бэкенд хранит данные игроков у себя, пока вы не добавите то, что их синхронизирует. И он не переводит версии: клиент и бэкенд, с которым он общается, по-прежнему должны быть одной версии Minecraft - для этого на прокси и ставят ViaVersion.

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

Velocity, BungeeCord и Waterfall#

Обычно всплывают три названия, и актуальный ответ среди них только один.

Velocity - прокси, написанный с нуля, со своим API плагинов, рассчитанный на пропускную способность и безопасность. Modern forwarding, рекомендуемый по умолчанию режим, передаёт бэкенду настоящую личность игрока внутри подписанной нагрузки, так что бэкенд может отвергнуть всё, что пришло не через прокси. Для Velocity 3 нужна Java 17 или новее.

BungeeCord - оригинал, он всё ещё поддерживается и по-прежнему очень широко используется. Его режим пересылки не аутентифицирует: бэкенд просто верит той личности, которую заявляет соединение, поэтому каждой сети на BungeeCord нужен firewall или плагин BungeeGuard перед бэкендами. Velocity умеет говорить и в этом режиме, когда это необходимо, - как legacy или bungeeguard.

Waterfall был форком BungeeCord от PaperMC. Он больше не поддерживается, и сам PaperMC советует переходить на Velocity. Не начинайте на нём новую сеть.

Плагины между ними не переносятся. Плагин для BungeeCord на Velocity не запустится, как и плагин для Bukkit или Paper: прокси не является сервером Minecraft, в нём нет миров, блоков и сущностей, для которых можно было бы предоставить API плагинов. У большинства устоявшихся сетевых плагинов есть сборки и под BungeeCord, и под Velocity.

Установка Velocity и конфигурация, которая важна#

Velocity - это jar-файл. Скачайте его со страницы загрузок PaperMC, положите в пустой каталог и запустите один раз, чтобы сгенерировать конфиг:

$ java -Xms512M -Xmx512M -XX:+UseG1GC -XX:MaxGCPauseMillis=100 \    -jar velocity.jar

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

Сгенерированный velocity.toml хорошо прокомментирован. Менять стоит вот эти строки:

bind = "0.0.0.0:25565"motd = "<gradient:#5A9BD5:#FFFFFF>The Longhouse Network</gradient>"show-max-players = 200online-mode = trueforce-key-authentication = trueplayer-info-forwarding-mode = "modern"forwarding-secret-file = "forwarding.secret"kick-existing-players = falseping-passthrough = "disabled"[servers]lobby = "10.0.0.11:25566"survival = "10.0.0.12:25567"minigames = "10.0.0.13:25568"try = ["lobby"][forced-hosts]"survival.example.com" = ["survival"]"minigames.example.com" = ["minigames"][advanced]compression-threshold = 256failover-on-unexpected-server-disconnect = truelog-player-connections = true[query]enabled = falseport = 25577

Замечания к тем строкам, на которых чаще всего спотыкаются:

• online-mode = true относится к прокси и только к нему. Это единственная точка аутентификации для всей сети. Бэкенды запускаются с выключенным параметром, потому что игроки напрямую до них не добираются.
• player-info-forwarding-mode = "modern" - настройка, ради которой написана вся эта статья. На бэкенде для неё нужен Paper 1.13 или новее. Для бэкендов 1.12.2 и старше нужны "legacy" или "bungeeguard" с теми дополнительными мерами предосторожности, которых требуют эти режимы.
• try = ["lobby"] - упорядоченный список серверов, на которые игрок отправляется при подключении. Добавьте вторую запись, и прокси перейдёт к ней, если первый лежит.
• [forced-hosts] маршрутизирует по имени хоста, которое ввёл игрок, так что survival.example.com сразу отправляет его в выживание, минуя лобби. Для каждой записи нужна своя DNS-запись, указывающая на тот же прокси.
• ping-passthrough = "disabled" означает, что в списке серверов показываются собственные MOTD и онлайн прокси. Поставьте "description" или "all", если хотите показывать данные бэкенда.
• kick-existing-players = false означает, что второй вход с той же учётной записью отклоняется. Значение true вместо этого кикает старую сессию - именно это вам нужно, если игроки после сбоя сети регулярно зависают «призраками».
• motd в Velocity использует форматирование MiniMessage, а не старые секционные коды из server.properties. Градиенты и hex-цвета работают здесь и не работают там.

Modern forwarding и файл секрета#

Modern forwarding - то, что делает сеть безопасной без firewall. Когда прокси подключается к бэкенду, он отправляет настоящий UUID игрока, имя, свойства скина и адрес внутри нагрузки, подписанной общим секретом. Бэкенд, настроенный на modern forwarding, отклоняет любое соединение без корректной нагрузки, а значит, игрок, узнавший адрес и порт бэкенда, не сможет зайти на него напрямую.

Секрет лежит в файле рядом с velocity.toml, имя которого задано в forwarding-secret-file. Velocity создаёт его при первом запуске. Прочитайте его и впишите ту же строку на каждый бэкенд.

$ cat forwarding.secretkC7pQ2mZ9vXb4TfR

На бэкендах Paper секрет записывается в config/paper-global.yml:

proxies:  velocity:    enabled: true    online-mode: true    secret: 'kC7pQ2mZ9vXb4TfR'

Значение online-mode здесь должно совпадать с online-mode самого прокси, то есть быть true. Оно сообщает Paper, действительно ли личности, приходящие через прокси, были проверены в Mojang.

Для modern forwarding нужен Paper либо Fabric и Forge с соответствующим модом совместимости с прокси. Обычный Spigot так не умеет. Если ваш бэкенд не на Paper, перенесите его на Paper или смиритесь с legacy-пересылкой с BungeeGuard и firewall.

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

Каждый бэкенд - обычный сервер Minecraft с четырьмя правками.

server-port=25566online-mode=falseenforce-secure-profile=falsenetwork-compression-threshold=-1view-distance=6

online-mode=false здесь правильно и только здесь. Аутентификацию выполнил прокси; бэкенд берёт личность из подписанной нагрузки пересылки. Это единственное законное применение этой настройки, и безопасно оно именно потому, что поддержка Velocity в Paper отклоняет соединения без корректной нагрузки. Если вы выставите online-mode=false, не включив на бэкенде пересылку Velocity, у вас получится открытый сервер, на который любой может зайти под чьим угодно именем.

enforce-secure-profile=false не даёт бэкенду требовать подписанный профиль чата, который он сам проверить не может.

network-compression-threshold=-1 отключает сжатие между прокси и бэкендом. Это стоит делать, когда они на одной машине или в одной локальной сети: прокси и так сжимает трафик, уходящий к игрокам, а повторное сжатие только жжёт процессор. Если бэкенды удалены от прокси через интернет, оставьте 256.

Дайте каждому бэкенду свой порт, а лобби - куда меньшие ресурсы, чем миру выживания: view-distance=5, simulation-distance=4, gamemode=adventure, spawn-protection достаточно большой, чтобы накрыть постройки, и 1-2 ГБ памяти. Лобби, в котором нечего симулировать, не нужно то, что нужно миру выживания.

Права, чат и данные игроков между серверами#

Вот что удивляет тех, кто ждал, что прокси заставит несколько серверов вести себя как один. Он этого не делает. У каждого бэкенда свой world/playerdata, свой ops.json, свои базы плагинов. Зайдя на выживание, вы для этих файлов - другой человек, не тот, кто секунду назад был в лобби.

Что вы реально можете делить и как:

• Права. Запустите LuckPerms на каждом бэкенде, направьте все на одну и ту же базу данных вместо локальных файлов и включите его обмен сообщениями, чтобы изменения доходили без перезапусков. Это стандартное решение, и оно хорошо работает. Руководство по LuckPerms описывает группы, наследование и контексты, благодаря которым ранг может означать разное на разных серверах. На RE:NODE слот базы данных входит в игровые тарифы - панель сама создаёт хост, пользователя и пароль, - а если вы предпочитаете держать базу сети отдельно, хостинг баз данных предлагает PostgreSQL, который LuckPerms поддерживает напрямую.
• Чат. Плагин межсерверного чата на прокси либо на каждом бэкенде с общим каналом. Без него чат каждого бэкенда - остров.
• Инвентари и балансы. Только с плагином, который синхронизирует их явно, и у каждого такого плагина есть сценарий дублирования предметов, когда сервер падает посреди переноса. Надёжнее вообще не делить инвентари: не давайте лобби ничего, заведите каждому режиму свою экономику и смиритесь с тем, что снаряжение из выживания остаётся в выживании. EssentialsX и общая экономика описывает вариант на базе данных, когда он всё-таки нужен.
• Вайтлисты. При modern forwarding на каждый бэкенд приходит настоящий UUID, поэтому whitelist.json на каждом бэкенде работает как обычно. Общесетевым вайтлистом проще управлять с прокси плагином.

Собственные команды Velocity коротки, и у каждой есть узел прав, так что раздавать их можно через LuckPerms:

/velocity reload подхватывает добавленные и удалённые серверы, не отключая подключённых игроков, так что добавление четвёртого бэкенда - рядовое событие.

Порты, адреса и публичное лицо#

Направьте запись A на прокси, затем добавьте запись SRV, чтобы игроки вводили mc.example.com вообще без порта. В статье SRV-записи для Minecraft есть точная запись и типичные ошибки; поддомены для серверов описывают имена для отдельных бэкендов, которые нужны для [forced-hosts]. Бэкендам публичный DNS не нужен вовсе, а запоминающиеся имена для них только помогают людям их найти.

Сеть на панельном хостинге - это один платный сервер на процесс, и об этом стоит сказать прямо: прокси плюс три бэкенда - это четыре сервера. Прокси среди них самый дешёвый, потому что памяти ему нужно очень мало. Тарифы Minecraft на RE:NODE начинаются с 2 ГБ и одного выделенного порта на каждый, а дополнительные порты добавляются на вкладке Network; персональные данные SFTP каждого сервера и файловый редактор панели - то, чем вы будете раскладывать один и тот же forwarding.secret по бэкендам, а вкладка Schedules может каждую ночь перезапускать сервер миниигр так, что никто этого не заметит, ведь прокси удерживает всех подключёнными.

Игрокам Bedrock Geyser и Floodgate ставятся на прокси, а не на каждый бэкенд, и это один из лучших доводов за то, чтобы поставить прокси даже перед единственным сервером - см. Geyser и кроссплей с Bedrock.

Что ломается и как выглядит ошибка#

`Your server did not send a forwarding request to the proxy. Is it set up correctly?` в консоли Velocity. Бэкенд не настроен на modern forwarding: proxies.velocity.enabled всё ещё false, либо бэкенд не на Paper, либо его не перезапустили после изменения.

Игроков сразу кикает с ошибкой пересылки или декодера. Секрет не совпадает. Сравните две строки символ за символом и проверьте, нет ли перевода строки в конце файла или пробела, захваченного при копировании.

`Unable to connect you to survival`, показанное игроку, и исключение отказа в соединении в логе прокси. Бэкенд лежит, слушает другой порт или привязан к адресу, до которого прокси не достаёт. Проверьте адрес и порт бэкенда из собственной оболочки прокси, прежде чем винить пересылку.

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

Все выглядят новыми игроками без инвентаря. UUID приходят в форме offline-режима, то есть пересылка на самом деле не работает, даже если игроки подключаются. Так выглядит legacy-пересылка без BungeeGuard, и именно поэтому режим важен.

`You are already connected to this proxy!` Призрачная сессия после оборвавшегося соединения. kick-existing-players = true в velocity.toml делает так, что побеждает новый вход.

Несовпадение версий на одном бэкенде после обновления. Velocity передаёт протокол, а не переводит его. Клиент 1.21 не может зайти на бэкенд 1.20 через прокси точно так же, как и напрямую. Либо держите все бэкенды на одной версии, либо поставьте ViaVersion на прокси. Обновление версий Minecraft описывает правильный порядок, а в сети это сначала плагины прокси, потом лобби, потом всё остальное.

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

FAQ#

Нужен ли прокси для двух серверов?

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

Снижает ли прокси лаги?

Нет. Каждый пакет проходит один лишний переход, так что задержка чуть растёт. Прокси позволяет разделить работу между несколькими процессами, так что у каждого весь бюджет tick в единоличном распоряжении. Если лагает один мир, прокси ему не поможет.

Можно ли запускать Velocity на той же машине, что и бэкенд?

Да, это обычная схема. Дайте прокси отдельный небольшой контейнер или процесс, привяжите бэкенд к порту, до которого прокси дотянется, и выставьте на бэкенде network-compression-threshold=-1, поскольку трафик не покидает машину.

Безопасен ли online-mode=false на бэкендах?

Только если пересылка настроена и проверена. При включённом modern forwarding на бэкенде Paper соединения без корректной подписанной нагрузки от вашего прокси отклоняются, так что бэкенд не открыт. Без него бэкенд в offline-режиме с публичным портом - самая опасная конфигурация в хостинге Minecraft.

Как поделиться инвентарями между серверами?

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

Стоит ли использовать BungeeCord?

Не для новой сети. Velocity быстрее, его modern forwarding безопасен без дополнительных плагинов, и именно на него PaperMC теперь указывает людям, раз Waterfall закрыт. Единственная причина выбрать BungeeCord - плагин, без которого не обойтись и у которого нет сборки для Velocity.