Minecraft Java и Bedrock на одном сервере: Geyser, Floodgate и границы совместимости

Допустим, у Ильи Minecraft Java на ноутбуке, а у его друга Макса — Bedrock на консоли или телефоне. Мир у них хочется один: общая база, общие сундуки, общий нижний мир с неудачно расположенным порталом. Раньше такая просьба заканчивалась тем, что кто-то покупал вторую копию игры или все мирились с двумя разными мирами. Сейчас есть более аккуратный путь: один Java-сервер и слой, который позволяет Bedrock-клиенту к нему подключиться. Но у этого слоя есть устройство и пределы, и лучше узнать о них до того, как вы пригласите двадцать человек.

Ниже разберём, что именно делают Geyser и Floodgate, чем они отличаются, как проходит вход игрока каждого издания, откуда берётся идентичность игрока и почему от неё зависят права в плагинах. Затем пройдём один игровой маршрут двумя клиентами и поговорим об обновлениях. Базовую установку самого Java-сервера мы не повторяем: она описана в материале «Как установить и настроить Minecraft на VPS». Здесь предполагается, что обычный Java-сервер у вас уже запускается.

Два разных вопроса: на каком языке говорят и кто вы такой

Путаница начинается с того, что в разговорах Geyser и Floodgate упоминают в одной фразе, будто это одна программа с двумя названиями. На деле они отвечают на разные вопросы.

Первый вопрос — на каком языке клиент разговаривает с сервером. Java-издание и Bedrock-издание используют разные сетевые протоколы. Сервер на Java этот второй язык не понимает. Задача Geyser — стоять между ними: по документации проекта он позволяет Bedrock-клиентам подключаться к Java-серверу (руководство по настройке Geyser). Можно представить переводчика на переговорах: каждая сторона говорит на своём, а смысл переходит из одной речи в другую. Отсюда сразу вытекает важное следствие: переводчик не гарантирует, что в языке второй стороны есть слово для каждого понятия. К этому мы ещё вернёмся.

Второй вопрос — как сервер узнаёт, кто к нему пришёл. У Java-игрока есть учётная запись Java-издания, и проверка подлинности опирается на неё. У Bedrock-игрока учётная запись другая. Если пустить Bedrock-игроков через Geyser без дополнительных мер, им придётся иметь ещё и Java-аккаунт — а ради возможности обойтись без него всё и затевалось. Здесь появляется Floodgate. По документации он дополняет Geyser и позволяет входить с учётной записью Bedrock без отдельной покупки Java, а сам по себе Geyser не заменяет (страница Floodgate).

Получается простая и полезная схема различения:

• Geyser решает вопрос протокола: делает так, чтобы Bedrock-клиент вообще мог зайти на Java-сервер.
• Floodgate решает вопрос входа: позволяет Bedrock-игроку авторизоваться своей учётной записью, без Java-аккаунта.
• Floodgate без Geyser не работает как самостоятельное решение: он надстройка, а не замена.

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

Куда ставить: сервер, прокси или мод

В документации Floodgate сказано, что доступны плагины для поддерживаемых серверов и прокси, а также мод для Fabric; тип сборки выбирается под вашу платформу. Здесь удобно думать не «какой файл скачать», а «где у меня точка входа игроков». Таких точек бывает две.

Первая — простая: один игровой сервер, к которому игроки подключаются напрямую. Geyser и Floodgate ставятся на него в виде плагинов или мода, в зависимости от того, на чём построен сервер. Всё живёт в одном процессе, настроек немного.

Вторая — с прокси впереди. Игроки подключаются к прокси, а он раздаёт их по игровым серверам. Тогда естественно ставить компоненты на прокси: вход один, и Java-, и Bedrock-игроки проходят через одну дверь. Но прокси приносит собственный вопрос — как backend-серверу доверять тому, что ему присылает прокси. Это мы разберём в разделе об идентичности: именно там простая схема превращается в опасную, если её настроить небрежно.

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

Порты и сеть: почему старый совет больше нельзя повторять слепо

В старых заметках часто встречается короткий рецепт: Bedrock использует UDP, поэтому откройте порт 19132 по UDP, и готово. Применять его к современной сборке без проверки не стоит. По руководству Geyser на дату проверки описан вариант с NetherNet, отдельным портом Geyser и HTTPS для signaling; в этом варианте порт используется и по TCP, и по UDP и не должен конфликтовать с другими службами.

Что из этого следует практически. Во-первых, правило «только UDP» может оставить половину маршрута закрытой, и тогда Bedrock-клиент будет упираться в таймаут, хотя Java-игроки заходят без проблем. Во-вторых, порт Geyser — отдельный от порта Java-сервера. Это две разные двери, и у каждой своя задача. В-третьих, раз порт нужен и по TCP, и по UDP, брандмауэр на VPS нужно настраивать для обоих протоколов, а не копировать пример для одного.

Конкретные номера и параметры берите из настроек выбранной сборки и актуального руководства, а не из чужих заметок: версии Geyser и способы подключения меняются, и то, что верно для одной сборки, может не подходить для другой. Хороший порядок такой: открыть порт, который указан в конфигурации именно вашей установки, для тех протоколов, которые там перечислены, и сразу проверить подключение реальным Bedrock-клиентом. Проверка Java-клиентом здесь ничего не доказывает: он ходит другим путём.

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

Два пути к одному миру: что происходит, когда игрок нажимает «подключиться»

Проследим вход каждого игрока по очереди. Это не отчёт о конфигурации, а способ увидеть, где могут возникнуть различия.

Илья с Java

Илья вводит адрес в клиенте Java, клиент обращается к порту Java-сервера, и сервер проверяет подлинность его учётной записи. Дальше Илья получает профиль со своим именем и постоянным идентификатором. В этом пути нет переводчика, и всё работает как на обычном Java-сервере.

Макс с Bedrock

Макс вводит адрес и порт Geyser. Его клиент говорит на языке Bedrock, и принимает его Geyser. Дальше Geyser превращает происходящее в понятное Java-серверу и обратно: движение, взаимодействие с блоками, действия с инвентарём. Если установлен Floodgate, Макс заходит своей Bedrock-учётной записью, и Java-аккаунт ему не требуется. Сервер при этом должен увидеть его как игрока и выдать ему профиль.

Важная деталь: для самого сервера Макс — такой же игрок, как Илья, но получивший свой профиль иным путём. Именно поэтому дальнейшие вопросы — права, имена, списки доступа — лучше решать с учётом того, что игроков два типа.

Идентичность: имя, которое нельзя считать надёжным

Когда сервер видит игрока, ему нужен идентификатор: по нему хранятся инвентарь, постройки-владения, права и баны. У Java-игрока это идентификатор его учётной записи. У Bedrock-игрока он берётся иначе, и разработчики Floodgate обычно решают задачу так, чтобы Bedrock-игроки отличались от Java-игроков и не сталкивались с ними в одном пространстве имён. Конкретные детали (например, как выглядит префикс имени и что делать при совпадении ников) определяются настройками выбранной версии, поэтому сверяйте их с конфигурацией вашей установки.

Рассуждение для практики такое. Допустим, у вас в мире есть плагин защиты участков, плагин экономики и плагин прав. Все три обращаются к игроку по идентификатору или по имени. Если Bedrock-игрок получает профиль с другим форматом идентификатора, то:

• права придётся выдавать именно этому профилю, а не «по имени, как у Ильи»;
• списки доступа к участкам, где вы вписали ник текстом, могут не сработать для Макса;
• плагин, который предполагает, что идентификатор всегда соответствует Java-аккаунту, может вести себя странно или давать сбой.

Это не повод отказываться от схемы, а повод сделать одну простую проверку до открытия сервера: выдайте тестовому Bedrock-игроку роль, защитите участок и убедитесь, что права действительно привязались к нему, а затем сделайте то же самое, если нужно, для Java-игрока. Отдельно проверьте плагины, которые работают с игроками вне сети, — например, добавление в список доступа заранее: для Bedrock-профиля такая операция может отличаться.

Прокси и подмена игрока: единственное место, где нельзя экономить

Теперь вернёмся к схеме с прокси. Когда игроки подключаются к прокси, а он передаёт их на backend, сам backend обычно не выполняет проверку подлинности: она проходит на прокси. Backend работает в режиме, в котором доверяет тому, что ему сообщили. Это удобно и одновременно опасно, и документация Velocity говорит об этом прямо: backend за прокси требует ограничения подключений только от прокси, поскольку offline mode иначе позволяет подменять игрока, а modern forwarding не заменяет firewall (защита backend в документации Velocity).

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

Из документации следуют два практических варианта:

• Один сервер. Прокси и backend живут на одном VPS: backend можно привязать к localhost, и снаружи он недоступен вовсе.
• Разные узлы. Тогда применяют firewall, разрешающий подключения к backend только от прокси, а при необходимости — зашифрованный туннель. Секрет для forwarding должен оставаться секретным: не лежать в публичных репозиториях и не пересылаться в чатах.

Отсюда прямое следствие для нашей темы: не стоит отключать проверку подлинности у произвольного backend ради того, чтобы «всё заработало быстрее». Режим без проверки допустим только в описанной защищённой схеме, где к backend нельзя подключиться иначе, чем через прокси. Если вы не можете уверенно сказать, что это так, оставьте проверку включённой. Обычная ошибка — открыть порт backend наружу «на время теста» и забыть о нём, и именно такая забытая дверь делает подмену возможной.

Для небольшой компании самая безопасная конфигурация и самая простая: один VPS, один набор компонентов, backend на localhost, наружу смотрят только порты, которые действительно нужны игрокам. Меньше открытых портов — меньше мест для ошибки.

Один маршрут двумя клиентами: вход, инвентарь, взаимодействие, возвращение

Теперь, когда схема понятна, проверим её так, как играют люди. Вместо длинного списка функций возьмём один сквозной маршрут и пройдём его дважды — Java-клиентом и Bedrock-клиентом, лучше одновременно, чтобы игроки видели друг друга.

Вход

Оба игрока заходят в мир. Смотрим не только «подключились ли», но и что показывает сервер: правильные ли имена в списке игроков, одинаково ли выданы стартовые права, нет ли ошибок в журнале при входе Bedrock-игрока. Если Bedrock-клиент не заходит, а Java заходит, это почти всегда проблема сети или версий в части Geyser, а не самого мира.

Инвентарь

Игроки берут предметы, перекладывают их по слотам, открывают сундук, наковальню, верстак. Инвентарь — одно из мест, где переводчику приходится сложнее всего: интерфейсы в двух изданиях отличаются, и многие действия реализованы по-разному. Нужно проверить, что предметы не пропадают и не дублируются при перекладывании, что содержимое сундука одинаково видно обоим, и что предметы с особыми свойствами (зачарования, названия) отображаются так, как задумано. Если на сервере есть плагин с собственным меню, откройте его с обеих сторон — такие меню самые частые источники различий.

Взаимодействие

Теперь заставим игроков что-то делать вместе: ломать и ставить блоки, открывать двери, нажимать кнопки, взаимодействовать с жителем или с командными блоками, если они у вас есть. Отдельно проверьте защищённый участок: Макс не должен получить доступ туда, куда его не пускали, и должен получить туда, куда его пустили. Это прямое продолжение разговора об идентичности: именно здесь выясняется, привязались ли права к Bedrock-профилю.

Переподключение

Заключительная часть маршрута — самая неприятная и самая полезная. Оба игрока выходят и заходят снова. Проверьте, что инвентарь и позиция сохранились, что профиль Макса остался тем же (его права и участки не «потерялись»), что при перезапуске сервера оба возвращаются в мир без особых действий. Затем сымитируйте типичную неприятность: пусть Макс на мобильном устройстве переключится с Wi-Fi на мобильную сеть, и клиент потеряет соединение. Возвращается ли он без ошибок? Если вход каждый раз создаёт нового игрока, значит, вы нашли проблему идентичности до того, как её нашли пользователи.

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

Таблица условная: это форма записи, а не результат чьего-то замера. Заполняйте её своими наблюдениями.

Где переводчик честно разводит руками

Теперь о границах. Geyser переводит протокол, но не превращает два издания в одно. У Java и Bedrock различаются некоторые механики, элементы интерфейса и отдельные возможности, и на этом стыке чаще всего возникают сюрпризы. Поэтому не стоит обещать игрокам, что «всё будет одинаково». Честнее обещать другое: что они смогут играть вместе в одном мире теми механиками, которые вы проверили.

Особый случай — моды. Java-моды изменяют сам сервер или клиент, и Bedrock-клиент о них ничего не знает. Серверный мод, добавляющий новые блоки или существа, не становится понятным Bedrock-клиенту только потому, что подключён переводчик: клиент не имеет ресурсов и правил, чтобы их показать. Поэтому «любой Java-мод заработает на Bedrock» — неверное ожидание. Если ваш мир строится на модах с новым содержимым, Bedrock-игроки получат в лучшем случае урезанный опыт. Если же вам важна прежде всего простая серверная логика — плагины, права, защита участков, экономика, — шансов на совместную игру значительно больше. Но и здесь каждый плагин проверяется отдельно, особенно те, что открывают собственные меню или используют нестандартные действия.

Полезно разделить будущий набор функций на три группы:

• Проверено на обоих клиентах — это можно обещать игрокам.
• Работает с оговорками — об этом стоит предупредить в правилах сервера.
• Не работает для Bedrock — честно перечислите и не скрывайте.

Такой список на странице сервера экономит и время администратора, и нервы игроков: никто не пишет в чат «почему у меня не открывается меню», если заранее знает, что в этом издании оно устроено иначе.

Что просит такая сборка у VPS

Geyser и Floodgate добавляют работу: сервер не только считает мир, но и переводит сетевой обмен для Bedrock-игроков. Сколько именно ресурсов это съедает, зависит от числа игроков, плагинов и размера мира, и универсальной цифры здесь нет — любое число без замера было бы выдумкой. Практический подход такой: взять тариф как отправную точку, нагрузить его реальными сценариями и смотреть на процессор, память и отклик.

Для ориентира: на VPS MAATRIX доступны тарифы Ba (1 vCPU, 2 ГБ RAM, 40 ГБ NVMe), Uab (2 vCPU, 4 ГБ, 80 ГБ), Heka (4 vCPU, 8 ГБ, 160 ГБ), Maat (8 vCPU, 16 ГБ, 240 ГБ) и Djed (16 vCPU, 32 ГБ, 320 ГБ). Это ресурсы плана, а не обещание, сколько игроков он выдержит. Для двух друзей и тестового мира можно начать с небольшого тарифа и поднимать его, если замеры показывают нехватку памяти или процессора. Если планируется прокси, несколько режимов и плагины с тяжёлой логикой, разумнее сразу заложить запас и проверять его на тесте.

Несколько свойств платформы здесь действительно к месту. Root-доступ нужен, чтобы настроить брандмауэр на нужные порты и привязать backend к localhost — а это как раз те меры, о которых шла речь в разделе о защите. NVMe помогает при загрузке мира и сохранении данных. Расположение сервера влияет на задержку: в предложении перечислены локации UK, US, RU и FR, и для игровой компании имеет смысл выбрать ближайшую к большинству игроков, а затем проверить отклик с обоих клиентов. Оплата картой РФ и через СБП, а также создание VPS в течение пары минут после оплаты позволяют быстро поднять тестовый стенд, не затягивая подготовку. Конкретную доступность ОС и образов смотрите в форме заказа. Подробнее с условиями можно познакомиться на странице аренды VPS MAATRIX.

Обновления: как не сломать то, что только что заработало

Самая коварная часть этой схемы — не установка, а жизнь после неё. Здесь сразу несколько компонентов, каждый из которых развивается независимо: сам Java-сервер, Geyser, Floodgate, возможно прокси и плагины. Руководство Geyser напоминает важную связь: сервер должен принимать версию Java-протокола, которую использует установленный Geyser, а актуальные требования указаны в руководстве. Значит, обновление одного компонента без оглядки на другие легко превращает рабочую связку в нерабочую. Новая версия игры выходит, Java-клиенты обновляются, а переводчик ещё не готов — и Bedrock-игроки внезапно остаются за дверью.

Разумный порядок действий выглядит так:

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

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

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

Договор между друзьями

Вернёмся к Илье и Максу. Когда сервер собран, имеет смысл не просто прислать адрес, а договориться, во что именно они играют вместе. Не «всё, что есть в Minecraft», а конкретный набор: общий мир, общие постройки, защищённые участки, экономика и привычные плагины, которые вы проверили обоими клиентами. Всё, что не проходит проверку — особый мод, нестандартное меню, редкий механизм, — честно вынесите в отдельный список «пока только для Java» или откажитесь от него ради общего мира.

Такой договор ничего не отнимает у игры. Он просто делает обещание сервера совпадающим с тем, что сборка действительно умеет: Geyser переводит, Floodgate пускает без Java-аккаунта, правильная защита backend не даёт чужаку назваться чужим именем, а вы знаете, где две версии игры расходятся. Остальное — стройка, пещеры и спор о том, чей это был сундук.