Прокси-сети (BungeeCord / Velocity)

ResourcePackManager работает в прокси-сетях. Установите один и тот же ResourcePackManager.jar на прокси и на каждый бэкенд, предоставляющий ресурс-паки. Остальные зарегистрированные серверы могут оставаться без RSPM. На бэкенде он объединяет, размещает, доставляет и преобразует паки. На Velocity или BungeeCord jar определяет платформу прокси и обеспечивает доставку Bedrock-паков для сети. Прокси владеет сетевым ключом и отправляет его каждому бэкенду при первом подключении игрока к нему.

На этой странице «прокси-плагин» — это сокращение для того же ResourcePackManager.jar, работающего в роли прокси.

Что делает прокси-плагин

Задача прокси-плагина — объединение и доставка Bedrock-пака. В сети с несколькими бэкендами каждый бэкенд производит свой собственный Bedrock-пак (преобразованную версию собранного на нём Java-пака). Прокси-плагин:

1. Определяет, какие зарегистрированные бэкенды используют RSPM, затем опрашивает этих участников каждые 5 секунд для получения /bedrock.zip и /mappings.json. Предпочитает сильные ETag с If-None-Match и сохраняет совместимость с If-Modified-Since для старых бэкендов. Неизменившиеся файлы возвращают 304. Каждый бэкенд объявляет точный HTTP-порт, который он занял, поэтому прокси обычно использует его автоматически. См. определение HTTP-порта бэкенда.
2. Ждёт, пока состояние входящих файлов стабилизируется — он объединяет, как только два соседних опроса видят один и тот же набор хешей файлов.
3. Объединяет Bedrock-пак каждого бэкенда в единый общесетевой пак.
4. Когда маппинги предметов существуют, копирует объединённый файл кастомных маппингов Geyser в plugins/Geyser-*/custom_mappings/ на прокси.
5. Раздаёт объединённый пак Bedrock-клиентам при подключении через SessionLoadResourcePacksEvent Geyser.

Java-паки в сети доставляются каждым бэкендом через обычный API setResourcePack / addResourcePack. Помимо объединения Bedrock-паков, роль прокси обеспечивает выдачу сетевых ключей и аутентифицированное распространение обновлений RSPM. Сети только для Java эта роль не нужна для доставки Java-паков.

Настройка

Floodgate

Floodgate позволяет игрокам Bedrock проходить аутентификацию без платного аккаунта Java Edition. Geyser также поддерживает онлайн-аутентификацию с аккаунтом Java; следуйте руководству по настройке Geyser для выбранного режима. RSPM может связывать прокси и бэкенды без Floodgate.

Если Floodgate установлен при первом запуске RSPM на прокси, RSPM выводит сетевой ключ из plugins/floodgate/key.pem, сохраняя идентичность существующей сети. При следующих запусках используется собственный файл RSPM network-key, пока он содержит действительный ключ. Если ключ отсутствует или недействителен, RSPM снова пробует источник Floodgate, прежде чем создать случайный ключ.

Скопируйте ResourcePackManager.jar на прокси

Существует только один jar. Тот же ResourcePackManager.jar, который вы устанавливаете на бэкенды Bukkit/Paper, является и прокси-плагином — он содержит реализации для Velocity и BungeeCord вместе в одном shaded-jar и автоматически определяет, на какой платформе он работает. Нет отдельного прокси-jar под каждую платформу, который нужно было бы извлекать.

Если вы уже запустили бэкенды без RSPM на прокси, повторно искать загрузку не нужно: каждый бэкенд за прокси без ключа подготавливает побайтово идентичную копию собственного jar в plugins/ResourcePackManager/proxy-extension/ResourcePackManager.jar и выводит точный путь в консоли. Копирование этого файла устанавливает версию, которая сейчас работает на этом бэкенде; обновите и остальные бэкенды, чтобы выровнять версии в сети.

Скопируйте тот же ResourcePackManager.jar в папку plugins/ вашего прокси:

Прокси-софт	Используйте этот jar
Velocity	ResourcePackManager.jar
BungeeCord	ResourcePackManager.jar

Вы можете подтвердить это с бэкенда в любой момент, запустив /rspm status; секция Proxy deployment печатает Network proxy jar: ResourcePackManager.jar и Use the same jar on Bukkit/Paper, Velocity, and BungeeCord.

Перезапустите прокси. Это всё.

Нет обязательного конфига для редактирования и нет ключа для вставки. Прокси сам устанавливает сетевой ключ при загрузке и автоматически снабжает им каждый бэкенд — см. Как связываются прокси и бэкенды ниже. Сгенерированный config.yml прокси содержит только две необязательные настройки, обе описаны далее.

Первый опрос прокси срабатывает примерно через 2 секунды после загрузки, затем каждые 5 секунд. В сочетании с одноцикловым порогом стабильности первое объединение публикуется примерно через 7 секунд после того, как прокси сможет увидеть хотя бы один бэкенд, который уже производит контент.

Обнаружение бэкендов

Прокси проверяет зарегистрированные серверы на наличие RSPM, не заставляя синхронизацию паков ждать серверы без него. Объявления адресов и ранее проверенный кешированный контент могут сразу подтвердить участников. В остальных случаях обнаружение проверяет определённый HTTP-адрес в фоне, выполняя не более двух проверок одновременно с тайм-аутом пять секунд. Неподтверждённые серверы проверяются снова примерно через минуту.

/rspm status показывает число подтверждённых участников и состояние обнаружения каждого оставшегося сервера. RSPM not confirmed означает, что обнаружение пока не установило наличие RSPM; это не доказывает отсутствие плагина. Проверьте адрес бэкенда, HTTP-порт и доступность, если сервер должен участвовать. Установка RSPM на другом бэкенде обнаруживается автоматически.

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

Обнаружение не предоставляет доступ к обновлениям. Для автоматических обновлений плагина по-прежнему действуют аутентификация сетевым ключом и проверка jar.

Как связываются прокси и бэкенды

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

1. Прокси устанавливает ключ. При загрузке он разрешает ровно одно значение в следующем порядке:

1. свой сохранённый файл network-key в собственной папке данных прокси-плагина — устойчивое состояние при каждой загрузке после первой;
2. одноразовое зерно, выведенное из plugins/floodgate/key.pem на прокси, если этот файл существует;
3. свежесгенерированный случайный ключ.

Полученный ключ сохраняется в network-key и используется, пока остаётся действительным. Консоль сообщает источник (Network key loaded ✓, adopted from Floodgate key.pem или New network key generated). Некорректный файл network-key заменяется. Если RSPM не может сохранить новый ключ или прочитать существующий файл network-key, роль прокси прекращает запуск с сообщением Could not establish persistent RSPM network identity или Cannot read established RSPM network identity, вместо того чтобы работать с ключом, который может измениться при следующем перезапуске. Исправьте права на папку и перезапустите прокси.

2. Прокси отправляет ключ каждому бэкенду. Как только игрок подключается к бэкенду, прокси отправляет ему ключ по каналу плагин-сообщений rspm:network. Направление выбрано намеренно: бэкенд физически не может запросить ключ, потому что прокси не пересылает плагин-сообщение по каналу, который клиент самого игрока никогда не регистрировал.

3. Бэкенд принимает ключ и сохраняет его. Он записывает ключ в свой data.yml и сообщает Network key received from the proxy; this backend is now linked. Выдача ключа принимается только пока у бэкенда нет своего ключа — уже связанный бэкенд логирует предупреждение и сохраняет то, что у него есть, вместо того чтобы позволить сообщению перенаправить себя в другую сеть.

На Velocity с современным форвардингом выдача подписывается HMAC поверх forwarding.secret прокси, и бэкенд, настроенный на современный форвардинг, требует эту подпись. На BungeeCord и при устаревшем форвардинге нет общего секрета, которым можно подписать, поэтому выдача не подписывается и принимается как есть.

Бэкенд, который дошёл до шага 2, но так и не дошёл до шага 3, сохраняет источник ключа в состоянии not set. Это ровно то состояние, которое запускает выкладку proxy-extension/ и предупреждающий баннер, специфичный для Bedrock.

Проверка работоспособности

Консоль прокси

В течение ~10 секунд после перезапуска (при условии, что бэкенды запущены) вы должны увидеть:

[ResourcePackManager] Network key loaded ✓
[ResourcePackManager] Network key provisioning ready on rspm:network; backends are keyed as players connect.
[ResourcePackManager] NetworkSync starting (poll interval 5000 ms, network-http-offset 1 - endpoint announcements preferred, fallback HTTP port = mcPort + offset)
[ResourcePackManager] NetworkSync: inbox stabilized — merging 2 Bedrock zip(s) and 2 mappings file(s) across 2 backend(s).
[ResourcePackManager] Merged Bedrock pack published at .../merged/Bedrock.zip (sha1=...).
[ResourcePackManager] ✔ Network resource pack is now ready (... KB, sha1 ABCD1234)

/rspm status на прокси

Выводит снимок состояния: отпечаток сетевого ключа, список бэкендов, результаты загрузки по каждому бэкенду и каждому пути (200 / 304 / 404 / CONNECT_FAILED) для /bedrock.zip, /mappings.json и /rspm-update.jar, полученные объявления endpoint'ов, видимые записи ретранслятора, счётчик последовательных пустых опросов, наличие на диске объединённого Bedrock-пака и объединённых маппингов (с их размерами) плюс префикс SHA-1 текущего объединённого пака, запасное значение network-http-offset, обнаруженную папку плагина Geyser и выложенный файл маппингов, а также наличие Floodgate / Geyser на прокси. Velocity принимает resourcepackmanager.command.status или resourcepackmanager.*; BungeeCord регистрирует точный узел resourcepackmanager.command.status, который плагины прав могут удовлетворить через раскрытие wildcard. Консоль может её запускать. Вывод не раскрывает секретов (сетевой ключ появляется только как короткий односторонний хеш-отпечаток, токены аутентификации не печатаются), поэтому щедрая выдача прав безопасна.

/rspm status на бэкенде

Строка Deploy mode должна показывать network-backend. Network key fingerprint должен показывать короткий хеш — он обязан совпадать с отпечатком, который печатает прокси. Network key source говорит, как этот бэкенд его получил:

Строка источника	Значение
provided by the proxy	Нормальное связанное состояние. Прокси выдал ключ при подключении игрока.
saved on this server	Ключ уже был получен при предыдущей загрузке (или это отдельный сервер, сгенерировавший собственный).
adopted from Floodgate's key	Один раз взят из локального plugins/floodgate/key.pem этого бэкенда.
not set — the proxy sends one when a player next connects here	Не связан. Либо ни один игрок не подключался с момента запуска прокси, либо на прокси нет RSPM / это неподдерживаемый прокси.

Bedrock-клиент

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

Справочник по конфигурации

Бэкенд: plugins/ResourcePackManager/config.yml

Сетевой режим определяется автоматически — нет флага networkMode: true, который нужно было бы выставлять. Сигналы для обнаружения (достаточно любого одного):

1. Floodgate присутствует, Geyser-Spigot отсутствует — сильнейший сигнал в пользу случая «Bedrock через прокси».
2. spigot.yml: settings.bungeecord: true — устаревший переключатель IP-форвардинга BungeeCord.
3. paper-global.yml: proxies.velocity.enabled: true — современный форвардинг Velocity.

Настройка резервного порта для сетевого режима называется networkHttpOffset-v2. Она определяет HTTP-порт, который прокси предполагает до объявления бэкендом фактически занятого порта. Значение по умолчанию 1; соответствующий порт всё равно должен быть доступен между прокси и бэкендом, либо должен работать маршрут ретрансляции. Подробности определения порта см. в разделе самостоятельного размещения.

В обычной работе каждый бэкенд автоматически объявляет прокси свой реальный HTTP-порт (через реестр endpoint'ов на magmaguy.com), поэтому смещение используется только как запасной вариант при старте/сбое. См. Разрешение HTTP-порта бэкенда ниже.

Прокси: config.yml

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

Прокси-софт	Путь к конфигу
Velocity	plugins/resourcepackmanager/config.yml
BungeeCord	plugins/ResourcePackManager/config.yml

Он содержит ровно две настройки, обе необязательные:

# FALLBACK offset added to each backend's Minecraft port to derive the HTTP
# port this proxy will hit for /bedrock.zip and /mappings.json BEFORE that
# backend has announced its real ResourcePackManager HTTP port. Default 1.
# In normal operation the backend announces the exact port it bound, so this
# value is only used at startup or if announcement fails — but if it IS used,
# it should match each backend's networkHttpOffset-v2.
network-http-offset-v2: 1

# Installs and updates this universal ResourcePackManager.jar in the proxy's
# Geyser extensions folder, which is what makes custom Bedrock ENTITIES render.
# Default true. Setting it to false stops future installation and update
# staging; it does not delete an extension jar that is already installed —
# remove that by hand while Geyser is stopped.
geyser-extension-auto-install: true

Эквиваленты на стороне бэкенда — это networkHttpOffset-v2 и geyserExtensionAutoInstall в config.yml бэкенда. Это две отдельные настройки — отключение установки расширения на прокси не отключает её на бэкендах, и наоборот.

Рядом с config.yml прокси записывает network-key. Сохраняйте это сгенерированное состояние и не копируйте его между разными сетями. Удаление повторяет определение ключа при следующем запуске; доступный файл Floodgate может дать тот же ключ. Если ключ изменится, уже связанные бэкенды сохранят старый и отклонят новый. Два прокси перед одними и теми же бэкендами должны иметь общий ключ: скопируйте файл между этими прокси.

Настройки force-resource-pack на стороне прокси нет. Принуждение к принятию пака — решение на стороне бэкенда (forceResourcePack в config.yml бэкенда), потому что прокси-плагин обрабатывает только доставку Bedrock-пака — он никогда не отправляет Java-паки. Если в старом config.yml прокси всё ещё есть строка force-resource-pack, она просто игнорируется и её можно удалить.

Намеренно нет записи конфига network-key — вставляемый вручную ключ был убран ещё до релиза, потому что опечатки молча ломали связь прокси↔бэкенд без единой ошибки где-либо. Ключ устанавливается прокси и автоматически передаётся бэкендам, как описано в разделе Как связываются прокси и бэкенды.

Разрешение HTTP-порта бэкенда

Прокси нужно знать, на какой HTTP-порт опрашивать каждый бэкенд для /bedrock.zip и /mappings.json. Он разрешает этот порт в таком порядке:

1. Объявленный бэкендом endpoint (предпочтительно). Каждый бэкенд загружает точный HTTP-порт, на который привязался, в реестр endpoint'ов на magmaguy.com, привязанный к сетевому ключу. При каждом опросе прокси обновляет этот список и сопоставляет объявленный порт бэкенда с записью списка серверов по Minecraft-порту (и хосту, когда тот доступен). Это означает, что администратор, задавший явный selfHostPort на бэкенде, или чей бэкенд автоматически попал на mcPort + 1, обрабатывается одинаково — прокси использует то, на что бэкенд реально привязался.
2. mcPort + network-http-offset-v2 (запасной вариант). Используется только когда нет совпадающего объявления (например, первый опрос до того, как какой-либо бэкенд объявил, или реестр endpoint'ов кратковременно недоступен). Вот почему два смещения всё же должны совпадать, если вы полагаетесь на запасной вариант.

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

/rspm status на прокси показывает по каждому бэкенду, какой порт был выбран и пришёл ли он из объявления или из запасного смещения.

Стабильность и частота объединения

Настройки размещения Java-паков также действуют на бэкенды за прокси. Если проверка самостоятельного размещения Java-пака не удалась, RSPM может переключить его доставку на удалённый хостинг, сохранив HTTP-сервер бэкенда для /bedrock.zip и /mappings.json.

Прокси ждёт, пока состояние входящих файлов стабилизируется, прежде чем объединять: первый опрос задаёт базовый набор хешей файлов, а следующий опрос, который видит тот же набор, запускает объединение (одноцикловый порог стабильности). С начальной задержкой ~2 с и интервалом опроса 5 с это ставит первое объединение примерно через 7 с после того, как прокси сможет увидеть хотя бы один бэкенд, производящий контент. Последующие объединения перепаковывают zip только если меняется набор SHA-1 файлов в инбоксе, поэтому длительный период покоя стоит почти ничего.

Бэкенды записывают свой bedrock.zip во временный файл и атомарно его переименовывают, поэтому маршрут /bedrock.zip всегда раздаёт полный zip — прокси никогда не приходится защищаться от чтения наполовину записанных файлов, поэтому порог составляет один цикл, а не два.

Прямая загрузка и резервная ретрансляция

Путь по умолчанию — прямая загрузка: прокси делает HTTP GET по адресу http://<backend-host>:<mcPort + offset><path> для каждого бэкенда.

Если прокси не может напрямую достучаться до HTTP-порта бэкенда (типично для shared / managed Minecraft-хостингов, где MC-порты открыты, но соседние порты блокируются файрволом), бэкенд отправляет свои bedrock.zip и mappings.json на endpoint ретрансляции на magmaguy.com под пространством имён сети (выведенным из сетевого ключа). Прокси перечисляет и скачивает из ретранслятора, когда прямая загрузка жёстко падает.

Оба пути ведут в один и тот же шаг объединения, поэтому администратору никогда не нужно выбирать — прямая загрузка предпочтительна (нулевой трафик на magmaguy.com), ретранслятор подключается прозрачно, когда нужно.

У ретранслятора TTL 30 минут на стороне сервера. Бэкенды пушат каждые 25 минут, чтобы запись оставалась активной; чистое выключение немедленно удаляет запись, не дожидаясь TTL.

Устранение типичных проблем

Бэкенд никогда не получает сетевой ключ

Симптом: /rspm status на бэкенде показывает Network key source: not set — the proxy sends one when a player next connects here, а консоль бэкенда повторяет:

[ResourcePackManager] This backend is behind a proxy but has no network key yet, so it is not linked to the proxy.
[ResourcePackManager] The proxy sends one automatically the first time a player connects to this server.

Проверьте это по порядку:

1. Кто-нибудь вообще подключался к этому бэкенду с момента запуска прокси? Выдача ключа едет вместе с подключением игрока. Лобби, которое никто ещё не посещал, законно остаётся без ключа.
2. Есть ли RSPM на прокси вообще? Бэкенд выкладывает копию собственного jar по пути plugins/ResourcePackManager/proxy-extension/ResourcePackManager.jar ровно для этого случая. Скопируйте его в папку plugins/ прокси и перезапустите прокси.
3. Современный форвардинг Velocity: совпадает ли forwarding secret бэкенда с секретом прокси? Бэкенд, настроенный на современный форвардинг, намеренно отклоняет неподписанную или неверно подписанную выдачу ключа — эта проверка и есть единственное, что мешает неавторизованному прокси раздать ключи вашим бэкендам. Лог бэкенда называет, какой из двух случаев произошёл. Исправьте секрет с обеих сторон, и следующее подключение игрока повторит попытку автоматически; перезапуск ни одной из сторон для этого не нужен.
4. Не является ли прокси неподдерживаемым? Роль прокси выполняют только Velocity и BungeeCord. Waterfall не поддерживается.

key.pem Floodgate больше не участвует в этом процессе. Отсутствие plugins/floodgate/key.pem на прокси полностью поддерживается: прокси генерирует собственный ключ. Аутентификация Floodgate и сетевое связывание RSPM независимы.

Два прокси перед одними и теми же бэкендами

Оба прокси обязаны предъявлять один и тот же сетевой ключ, иначе каждый бэкенд свяжется с тем, кто добрался до него первым, и отклонит второго (записав в лог A proxy offered a network key that differs from the one this backend already uses). Скопируйте файл network-key из папки данных RSPM основного прокси в папку другого прокси и перезапустите его.

Предупреждение «No merged pack content» через ~20 секунд

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

• CONNECT_FAILED на каждом бэкенде — прокси вообще не может достучаться до HTTP-порта бэкенда. Проверьте, что адрес в velocity.toml / config.yml — это адрес, до которого прокси действительно может дозваниться (а не, например, внутрисетевое Docker-имя, которое не резолвится из сети прокси), и что HTTP-порт бэкенда открыт между прокси и бэкендом. Предупреждение печатает точный HTTP host:port, который оно пробовало для каждого бэкенда, и пришёл ли этот порт из объявления бэкенда или из запасного варианта mcPort + networkHttpOffset-v2. Если у вас нет способа открыть этот порт (managed-хостинг), смотрите раздел про резервную ретрансляцию выше — бэкенд должен автоматически загружать в ретранслятор.
• NOT_FOUND_404 на каждом бэкенде — бэкенды работают, но не производят Bedrock-пак. Запустите /rspm status на каждом бэкенде; диагностический блок Bedrock Pack скажет вам, почему (чаще всего: в собранном паке нет конвертируемых маппингов предметов или бандлов сущностей, либо первый цикл миксинга ещё не завершился).

Предупреждение срабатывает один раз за период «застоя». Строка NetworkSync: recovered записывается, когда хотя бы один бэкенд снова начинает возвращать контент.

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

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

Решение: перезапустите прокси один раз после того, как сам прокси запишет первую строку Merged Bedrock pack published. RSPM заранее размещает маппинги предыдущего запуска при каждом старте прокси, поэтому следующие запуски могут загрузить сохранённые маппинги до сканирования Geyser. Добавление или удаление пользовательских предметов позже также меняет регистрируемый при запуске набор и требует перезапуска. Новые идентификаторы пользовательских сущностей или типы свойств требуют того же.

Предупреждения «Duplicate bedrock_identifier» при загрузке прокси

Разные идентификаторы Bedrock могут иметь одинаковый Java-селектор предмета/модели/предикатов. Одного переименования исходной модели недостаточно, чтобы различить такие предметы. Назначьте разные селекторы, например разные значения custom-model-data. Текущий объединитель предпочитает современную definition записи legacy с тем же селектором; при одинаковом типе побеждает последняя запись. Дедупликация сохраняет только один предмет.

Bedrock-игрок подключился, но не видит пак

Когда сессия Bedrock загружается без пригодного RSPM-пака, прокси отправляет сообщение в чат подключённым сотрудникам с разрешением resourcepackmanager.*:

⚠ [RSPM] Игрок Bedrock Alice подключился до готовности ресурс-пака и видит обычные стойки для брони вместо пользовательских моделей. Попросите его отключиться и подключиться снова; пак загрузится в следующей сессии. (Причина: ...)

Сам Bedrock-игрок также получает модальное всплывающее окно, а консоль прокси получает баннер. Если нужно копнуть глубже, включите debug-поток (доступен как на Velocity, так и на BungeeCord):

/rspm debug bedrock on

Это включает подробные строки лога [RSPM-BedrockDebug] от GeyserBinder. Воспроизведите проблему, затем выключите:

/rspm debug bedrock off

Настройка сбрасывается в off при перезапуске прокси, чтобы её нельзя было случайно оставить включённой.

Обновление RSPM в сети

Это один и тот же jar на каждом бэкенде и на прокси, поэтому держите все компоненты на одной версии.

При ручном обновлении замените jar плагина на бэкенде, снова скопируйте этот ResourcePackManager.jar в папку plugins/ прокси и перезапустите прокси.

RSPM также может сделать половину работы на прокси сам. Каждый бэкенд предлагает прокси свой универсальный jar плагина по аутентифицированному маршруту (/rspm-update.jar, защищённому токеном, выводимым из общего сетевого ключа — сам ключ никогда не передаётся). Прокси проверяет, что предложенный файл — это полноценный универсальный jar RSPM с совпадающими версиями дескрипторов платформ и ожидаемыми точками входа, отказывается от понижения версии и сверяет размещённые байты с заявленным размером и SHA-256, прежде чем что-либо заменять. Он размещает один и тот же jar для прокси-плагина и, если обнаружен Geyser на прокси, его встроенное расширение Geyser; эти файлы применяются при выключении прокси, а предыдущие сохраняются как копии для отката.

Это аутентифицированная граница доверия внутри сети, а не независимая проверка происхождения относительно Nightbreak: любому бэкенду, снабжённому общим сетевым ключом, доверяется предлагать структурно валидный jar RSPM той же или более новой версии. Берегите этот ключ и относитесь к каждому бэкенду, который им владеет, как к доверенной инфраструктуре.

Поэтому на практике обновления бэкендов и последующего перезапуска прокси обычно достаточно — прокси уже разместит подходящий jar для себя. Отклонённое обновление логируется как Rejected backend-offered ResourcePackManager update: ... с указанием причины.

Ошибки аутентификации обновлений исполняемых файлов

HTTP 401 на /rspm-update.jar приостанавливает только автоматическое распространение jar с этого бэкенда. Прямой опрос Bedrock-пака и маппингов продолжается. Маршрут обновления повторяет попытки с возрастающей задержкой от одной до пятнадцати минут. Сравните отпечатки сетевого ключа в /rspm status с обеих сторон, затем убедитесь, что указанный URL ведёт на нужный бэкенд, а версии совпадают.

Если отпечатки различаются, /rspm status на прокси описывает текущую процедуру: убедитесь, что это нужные прокси и бэкенд, остановите затронутый бэкенд, сделайте резервную копию его plugins/ResourcePackManager/data.yml, удалите только запись networkKey, затем запустите его и зайдите через этот прокси, чтобы ключ был выдан заново. Сохраните network-key прокси и все ключи Floodgate. Предупреждение 401 в консоли прокси всё ещё рекомендует копировать key.pem Floodgate; этот совет устарел, потому что RSPM сохраняет собственную сетевую идентичность и изменение key.pem не заменяет уже установленный ключ RSPM. Сохраните оба вывода состояния для поддержки.

Что пока не поддерживается

• Java-паки в сетях через прокси-плагин. Java-клиенты получают паки от каждого бэкенда напрямую через обычный API. На стороне прокси нет миксера Java-пака.
• Объединение Java-паков между бэкендами. Java-пак каждого бэкенда независим. Если игрок переключает бэкенд, он получает пак нового бэкенда.
• Ротация сетевого ключа без остановки. Бэкенд принимает ключ только при отсутствии собственного и отклоняет сообщения с заменой. Когда все компоненты остановлены, удаление network-key на прокси и networkKey из data.yml каждого бэкенда позволяет выдать ключ заново. Это не гарантирует смену ключа: прокси может снова вывести тот же ключ из key.pem Floodgate.