Перейти к основному содержимому

Устранение неполадок Resource Pack Manager

Эта страница описывает только поведение, на данный момент подтверждённое в кодовой базе ResourcePackManager.

Самый полезный первый шаг для любой проблемы RSPM:

/rspm status

Он печатает версию, режим развёртывания (standalone vs network-backend), короткий несекретный отпечаток сетевого ключа плюс источник этого ключа, состояние Java- и Bedrock-пака, активный путь доставки с URL, разрешённый внешний хост + авто-определённый публичный IP, все релевантные флаги конфига, напоминание о развёртывании прокси (сетевой прокси-jar — это тот же ResourcePackManager.jar) и обнаружение Floodgate / Geyser-Spigot. Такая же команда существует, когда jar работает на прокси, и печатает аналоги на стороне прокси (список бэкендов, результаты загрузки по каждому бэкенду, состояние объединённого пака).

Консоль намеренно выводит мало сообщений​

RSPM печатает одну строку при каждой свежей инициализации пути доставки — результат:

[ResourcePackManager] Resource pack is live via self-hosting — http://play.example.com:25566/rspm.zip
[ResourcePackManager] Resource pack is live via automatic hosting — https://magmaguy.com/rsp/<uuid>

Всё остальное — каждый подготовленный пак, каждый объединённый кластер, каждая проверка стабильности, каждая проба self-host и её результат — по умолчанию подавляется. Условие, из которого RSPM восстанавливается сам, не сообщается как предупреждение. Если проба self-host не прошла и RSPM молча переключился на удалённый хостинг — это успех, а не сбой, и консоль об этом ничего не говорит.

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

/rspm verbose on

затем выполните /rspm reload. Эта команда сама записывает verboseLogging: true в plugins/ResourcePackManager/config.yml, и настройка переживает перезапуски, поэтому выполните /rspm verbose off, когда закончите. Ручное редактирование ключа делает то же самое. У Bedrock-конвертера отдельный переключатель — bedrockConverterDebug, доступный только через конфиг.

Предупреждения сообщают о реальных сбоях: повторных ошибках доставки конкретному игроку, ответе клиента INVALID_URL, невозможности открыть HTTP-порт, отказе обоих способов доставки или нескольких циклах опроса прокси без содержимого от бэкендов.

Игроки не получают ресурс-пак​

Сначала проверьте следующее:

  • autoHost должен быть включён, если вы хотите обычную автоматическую доставку (selfHostForce — это явное переопределение для тестирования)
  • собранный пак должен существовать, и хотя бы один путь доставки (self-host или удалённый) должен был успешно отработать
  • игроки получают пак при входе. Игроки, вошедшие, пока пак не был опубликован, получают его, когда хостинг становится готов, в том числе когда хостинг повторно регистрируется позже в ходе сессии (например, после истечения удалённой сессии)
  • игроки Floodgate намеренно пропускаются Java-доставкой, потому что их Bedrock-сессией пака владеет Geyser

При необходимости:

  1. Выполните /rspm status и посмотрите секцию «Hosting». Active delivery показывает, используется ли сейчас self-host, удалённый, или ни один.
  2. Если «active delivery: not yet ready» — сборка или загрузка ещё идут. Плагин громко предупреждает в консоли, когда игрок подключается слишком рано, и автоматически отправит пак, как только доставка будет готова.
  3. Если «active delivery: none — hosting disabled or failed» — autoHost отключён, либо проверки self-host и удалённая загрузка обе не прошли. См. «Self-host sanity checks failed» и «Auto-hosting cannot reach the remote server» ниже.
  4. Задайте verboseLogging: true, выполните /rspm reload, следите в консоли за результатами загрузки / проверки self-host, затем перезайдите тестовым игроком. (Без этого флага шаги проб не печатаются — только итоговая строка результата «Resource pack is live via ...».)

Предложение пака при входе задерживается примерно на одну секунду. Если Java-клиент сообщает FAILED_DOWNLOAD или DISCARDED, RSPM автоматически повторяет попытку до трёх раз для этой сессии игрока. Он не повторяет попытку при отказе игрока, INVALID_URL или FAILED_RELOAD; исчерпание повторов и некорректные URL логируются как настоящие сбои.

FAILED_RELOAD означает, что клиент скачал пак, но его собственная перезагрузка ресурсов не удалась, поэтому повторное скачивание того же пака не поможет. RSPM записывает в лог Client <name> reported FAILED_RELOAD for the resource pack. Check that client's latest.log for the resource reload error; not retrying. Прочитайте клиентский latest.log этого игрока, чтобы найти ресурс или метаданные пака, которые клиент отклонил.

Если хостингом и доставкой управляет другая система (autoHost: false), RSPM не отправляет URL игрокам. Для HTTPS-прокси перед RSPM оставьте autoHost: true и используйте selfHostExternalUrl. Это сохраняет автоматическую доставку и удалённый хостинг в качестве резерва.

ItemsAdder установлен, но его содержимое отсутствует в итоговом паке​

Обычно это означает, что ItemsAdder всё ещё настроен так, что мешает ResourcePackManager читать или хостить его вывод.

Используйте:

/rspm itemsadder configure

Эта команда сейчас:

  • включает resource-pack.hosting.no-host.enabled
  • отключает protection_1, protection_2 и protection_3
  • устанавливает resource-pack.zip.compress-json-files: false
  • запускает /iareload, затем /iazip
  • ждёт, пока RSPM объединит пересозданный экспорт ItemsAdder, и сообщает, удалось ли объединение

Она не перезагружает ResourcePackManager. После сообщения об объединении проверьте хостинг в /rspm status.

Если команда сообщает, что ItemsAdder уже хостит собственный пак, сначала вручную отключите хостинг ItemsAdder и запустите команду снова.

Собранный пак некорректен или не загружается​

Интеграция авто-хоста ResourcePackManager явно обрабатывает следующие типы серверных ошибок:

  • отсутствуют требуемые файлы
  • файл слишком большой
  • неверный формат файла
  • отсутствующая сессия
  • удалённый сервер недоступен

RSPM сам проверяет ограничение размера файла перед загрузкой: Java-пак больше 50 000 КиБ (51 200 000 байт) не загружается, а консоль выводит Automatic hosting skipped: resource pack is <size> bytes; the limit is 51200000 bytes. Затем RSPM пробует проверенный собственный хостинг. См. Собственный хостинг.

Если вы столкнулись с одной из них:

  1. Выполните /rspm reload, чтобы пересобрать пак.
  2. Проверьте, не повреждён ли, не зашифрован ли или иначе нечитаем один из исходных паков.
  3. Проверьте, содержит ли итоговый собранный пак валидные pack.mcmeta и pack.png в корне.

Если включённый пак не удаётся извлечь или подготовить, текущая сборка прерывается, и консоль называет проблемный пак. Почините этот пак, удалите добавленный вручную ZIP или задайте isEnabled: false в его конфиге автоматической интеграции перед перезагрузкой.

Метаданные оверлеев и структура архива​

Итоговое объединение сохраняет авторские объявления форматов оверлеев, включая formats, min_format, max_format и дополнительные метаданные. Если несколько паков используют один каталог оверлея, побеждает запись с более высоким приоритетом.

Выполняется одно изменение. Minecraft 1.21.9 и новее отклоняет весь pack.mcmeta, если какой-либо оверлей в списке достигает формата пака 64 или ниже, а другой оверлей не объявляет formats. Два пака, каждый из которых корректен, могут нарушить это правило после объединения их списков оверлеев. Если объединённый список содержит оверлей с нижней границей 64 или ниже, RSPM добавляет диапазон formats каждой записи, которая объявляет только min_format и max_format. Диапазон охватывает тех же клиентов, что и собственные границы записи, и ограничивается значением 64, если начинается с 64 или ниже. Журнал коллизий записывает Added the formats range to N overlay entries. Записи, которые уже объявляют formats или чьи границы не удаётся разобрать, остаются как есть. В остальном RSPM не согласует диапазоны разных поколений клиентов и не исправляет неверные объявления; несовместимые метаданные исправляйте в исходном паке.

RSPM проверяет, что каталог оверлея задан непустым относительным путём внутри корня собранного пака. Абсолютные и недопустимые пути, а также пути, выходящие из корня после нормализации, отклоняются. Успешная проверка не гарантирует, что Minecraft примет имя или метаданные формата оверлея.

ZIP с Pack Name/assets/ и Pack Name/pack.mcmeta содержит лишний внешний каталог. RSPM предупреждает об этом; перепакуйте содержимое так, чтобы assets/ и pack.mcmeta находились в корне ZIP. Архивы с дедупликацией содержимого читаются через центральный каталог, поэтому сохраняются записи с общими сжатыми данными, включая метаданные анимации текстур.

Текстуры атласа блоков​

В объединённом атласе блоков источники-каталоги разворачиваются в конкретные PNG-ресурсы пака. Порядок источников и ID спрайтов сохраняются. Для текстур, размеры кадров которых не подходят требуемым уровням mip, создаются детерминированные копии с масштабированием методом ближайшего соседа в resourcepackmanager_internal:mip_safe/. Исходные файлы остаются неизменными для шрифтов и других загрузчиков.

Не создавайте содержимое в зарезервированном пространстве имён resourcepackmanager_internal: конфликт будет отклонён. Этот процесс не является преобразованием Java в Bedrock и не гарантирует поддержку всех пользовательских шейдеров клиента или расширений атласа.

Повреждённый пак больше не блокирует доставку навсегда​

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

[ResourcePackManager] Resource pack X.zip failed to stage 3 times in a row and has been excluded
from the merge so the remaining packs can be delivered. The merged pack is now INCOMPLETE ...

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

Исключение снимается само. Запись о сбое привязана к размеру и времени модификации файла, поэтому починка или замена файла автоматически снимает карантин, и пак возвращается в следующее объединение — без команды, без перезапуска. /rspm reload также сбрасывает все записи карантина с нуля. Счётчики сбоев, не достигшие трёх, обнуляются после любой успешной сборки, поэтому не связанные между собой кратковременные сбои за долгий аптайм не могут накопиться в исключение.

При ошибке SESSION_NOT_FOUND от удалённого авто-хоста RSPM очищает свой UUID сессии и пере-инициализируется на следующем keep-alive тике — ручное вмешательство не требуется.

Ресурсы одного плагина перекрывают ресурсы другого​

Это контролируется параметром priorityOrder в:

plugins/ResourcePackManager/config.yml

Записи выше побеждают записи ниже.

Для не-объединяемых файлов ResourcePackManager заменяет файл с более низким приоритетом. Для объединяемых JSON-файлов он объединяет содержимое. Текущие объединяемые категории JSON:

  • sounds.json
  • языковые файлы
  • ванильные JSON моделей предметов в minecraft/models/item (нерекурсивное объединение: между паками комбинируется только массив overrides, остальная часть файла следует правилу «побеждает наивысший приоритет»)
  • файлы атласов
  • файлы шрифтов
  • определения моделей предметов формата 1.21.4+ в items/ (формат-зависимое объединение, учитывающее структуру дерева предикатов)

pack.mcmeta объединяется отдельно: используется наибольший pack_format, а объявленные диапазоны форматов пака совмещаются. Оверлеи сохраняют авторские диапазоны и дополнительные метаданные; для повторяющихся каталогов берётся запись с более высоким приоритетом. Единственное дополнение — диапазон formats у записей, которым он нужен, чтобы объединённый список загружался на клиентах 1.21.9+ (см. Метаданные оверлеев). В остальном RSPM не исправляет несовместимые метаданные. Другие непротиворечащие метаданные также сохраняются. Источники базового атласа добавляются в атласы оверлеев, чтобы оверлеи не скрывали базовые записи.

Если вам нужно изучить, что произошло при последнем объединении, проверьте:

plugins/ResourcePackManager/collision_log.txt

Текст GUI или элементы на основе шрифтов выглядят неправильно​

Файлы шрифтов — одна из категорий JSON, которые ResourcePackManager объединяет, но это не гарантирует, что две разные шрифтовые системы будут хорошо работать вместе в Minecraft.

Если меню или HUD на основе шрифта выглядит неправильно:

  1. Измените priorityOrder так, чтобы пак, который вы хотите видеть победителем, был выше.
  2. Выполните /rspm reload.
  3. Проверьте collision_log.txt, чтобы убедиться, что коллизии произошли там, где вы ожидали.

Изменения ресурс-пака не появляются сразу​

В ResourcePackManager есть watchdog для источников поддерживаемых паков.

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

Если вы активно перегенерируете пак другого плагина, дайте ему несколько секунд после окончания записи в файлы. Если сомневаетесь — выполните /rspm reload после того, как плагин-источник закончит.

/rspm status сообщает об удалённом хостинге вместо собственного​

Это может произойти при preferSelfHost: true (по умолчанию), если проверка собственного хостинга не пройдена. Проверки доступности записываются в подробный журнал и скрыты без verboseLogging: true; некоторые сообщения содержат «This is OK.». При успехе удалённого хостинга результат — Resource pack is live via automatic hosting — .... Неверные настройки, сбои HTTP-сервера и удалённой связи по-прежнему могут вызывать предупреждения.

Выполните /rspm verbose on (или задайте verboseLogging: true) и /rspm reload, чтобы увидеть, какой из трёх уровней не прошёл:

  1. Уровень 1 (эвристика) — разрешённый внешний хост — это RFC1918 / loopback / link-local. Либо установите selfHostExternalHost на ваше реальное публичное имя хоста, либо убедитесь, что плагин может достучаться до api.ipify.org / checkip.amazonaws.com.
  2. Уровень 2 (локальное скачивание и объявленный URL) — RSPM скачивает первые байты, максимум 1 КиБ, с http://127.0.0.1:<port>/rspm.zip и точного URL игрока, сравнивая оба образца с локальным паком. Требуются HTTP 200 или 206, совпадающие заявленные длины и ожидаемый Content-Range для 206. Перенаправления, неверные байты, отсутствие файлов и серверные сбои NAT loopback отклоняют собственный хостинг.
  3. Уровень 3 (проверка внешней доступности) — magmaguy.com должен сообщить о доступности объявленного URL с HTTP 200 или 206. Закрытый HTTP-порт, неудачный запрос или недоступная служба проверки отклоняют автоматический собственный хостинг. Статус и имеющийся код причины выводятся при verboseLogging.

Рекомендуемый порядок действий: откройте HTTP-порт в брандмауэре и маршрутизаторе, задайте доступное имя хоста в selfHostExternalHost или установите preferSelfHost: false, чтобы сначала пробовать удалённый хостинг. Если собственный хостинг нельзя использовать даже как резерв, также задайте selfHostEnabled: false и оставьте selfHostForce: false.

Если служба проверки недоступна, собственный хостинг остаётся неподтверждённым и RSPM пробует удалённый. Резерв после удалённого сбоя должен пройти те же проверки собственного хостинга. Только selfHostForce: true обходит проверку; при отказе обоих автоматических путей RSPM не может объявить новый URL доставки. Успешные проверки всё равно не доказывают полное скачивание и принятие пака из сети каждого игрока.

См. Самостоятельный хостинг для полного дерева решений.

Автоматический хостинг не может связаться с удалённым сервером​

Встроенный удалённый хост ResourcePackManager связывается с:

https://magmaguy.com/rsp/

Если это соединение не удаётся, плагин записывает предупреждения о связи и не может использовать удалённый резерв до успешного восстановления соединения.

Ваши варианты:

  1. починить исходящую HTTPS-связность сервера
  2. подождать, пока удалённый сервис снова станет доступным
  3. отключить autoHost и самостоятельно хостить сгенерированный zip
  4. открыть HTTP-порт, задать публичное имя в selfHostExternalHost и оставить preferSelfHost: true. Явное имя пропускает автоматическое определение публичного IP, но локальная проверка, скачивание объявленного URL и внешняя проверка всё равно должны пройти успешно. Недоступная служба проверки препятствует автоматическому выбору собственного хостинга.

Я хочу размещать собранный пак на своём веб-сервере​

Поддерживаемый кодом сценарий:

  1. Установите autoHost: false.
  2. Установите resourcePackRerouting, если хотите, чтобы ResourcePackManager записывал дополнительную копию в существующую папку.
  3. Самостоятельно хостите ResourcePackManager_RSP.zip.

resourcePackRerouting разрешается относительно каталога plugins, и целевая папка должна уже существовать.

Если вместо этого вы хотите использовать встроенный self-host HTTP-сервер RSPM (другое дело — та же JVM, что и плагин), см. Самостоятельный хостинг.

Мне нужно проверить, какие удалённые данные хранятся для этого сервера​

Используйте:

/rspm data_compliance_request

Если есть активная удалённая сессия хостинга, ResourcePackManager скачивает ответ в:

plugins/ResourcePackManager/data_compliance/data.zip

RSPM также записывает ReadMe.md в ту же папку data_compliance.

Если удалённой сессии нет (например, вы используете self-host), команда сообщит, что удалённых данных для запроса нет.

Bedrock-пак не генерируется​

bedrockConversionEnabled по умолчанию true, поэтому он должен запускаться автоматически. Сначала запустите /rspm status — секция Bedrock Pack скажет вам, почему пака нет на диске:

  • «No Bedrock target detected» — нет локального Geyser-Spigot, нет локального Floodgate и нет сетевого режима. Преобразование намеренно пропускается. Установите Floodgate (для прокси-настроек) или Geyser-Spigot (для отдельностоящих настроек) и выполните /rspm reload.
  • «Network mode is active so this backend SHOULD produce a Bedrock pack. The file is missing» — обычно первый цикл сборки ещё не завершился (подождите ~30 с после загрузки), либо преобразование не нашло ни конвертируемых маппингов предметов, ни разрешённых комплектов сущностей, либо преобразование выбросило ошибку. Поищите в консоли предупреждения [BedrockConverter]. При bedrockConverterDebug: true сканер также записывает Generic scanner: discovered N item definitions; число 0 означает, что в собранном паке нет конвертируемых определений предметов. (Диагностика статуса цитирует эту строку как discovered 0 items definition files.)

Если авто-определение Geyser не срабатывает:

  1. Задайте bedrockGeyserFolder в config.yml в путь к папке данных вашего Geyser (например, Geyser-Spigot).
  2. Абсолютные пути работают. Относительный путь сначала пробуется от рабочего каталога сервера, затем относительно каталога plugins.

Конвертер авто-определяет Geyser в plugins/Geyser-Spigot/, в любом варианте plugins/Geyser-*/ или в config/Geyser-*/ для установок Fabric/NeoForge.

Для логирования по каждому предмету / каждой кости установите bedrockConverterDebug: true и перезагрузите.

Bedrock: поставщик паков для сессий отключён из-за старого пака​

Если консоль сообщает Legacy RSPM Bedrock pack detected, значит Geyser уже просканировал старый ResourcePackManager_Bedrock.zip из своей папки паков при загрузке. Удаление этого файла во время работы процесса оставило бы Geyser с кодеком в памяти для пути, которого больше нет, поэтому RSPM намеренно пропускает свой живой провайдер пака на эту загрузку.

Полностью остановите сервер, удалите только тот точный путь к устаревшему файлу, который напечатал RSPM, и запустите сервер снова. Не используйте /reload для этой миграции. Текущий пак остаётся в plugins/ResourcePackManager/output/ и раздаётся посессионно; ему не место в папке packs/ Geyser.

Игроки Bedrock видят предметы в руке в неправильной позиции​

Сначала убедитесь, что загружены нужная модель и последний пак: переподключите клиент Bedrock, чтобы он получил текущий пак. RSPM выводит позу в руке из трансформаций Java-модели display.firstperson_righthand и display.thirdperson_righthand, поэтому поза, неверная и на Java, исправляется в Java-модели. Если на Java всё выглядит правильно, а на Bedrock нет, сообщите об этом, приложив файл модели.

bedrock_display_offsets.yml и его настройки смещений удалены и больше не читаются; редактирование старой копии ничего не даёт. См. Позы предмета в руке.

Пользовательские текстуры брони отсутствуют у игроков Bedrock​

Кастомная броня рендерится на Bedrock путём комбинирования ванильной геометрии брони с Java-текстурой в качестве видимого слоя. Чтобы это работало, пак исходного плагина должен определять equipment-файл в assets/<namespace>/equipment/<material>.json рядом с определением предмета. Если лог конвертации показывает предмет, но в игре текстура брони не появляется — убедитесь, что этот файл присутствует в собранном паке.

Прокси: бэкенд сообщает об отсутствии сетевого ключа​

На бэкенде /rspm status показывает Network key source: not set — the proxy sends one when a player next connects here, а консоль повторяет «This backend is behind a proxy but has no network key yet».

Отсутствие plugins/floodgate/key.pem — не причина; теперь этот файл необязателен. Ключом владеет прокси: он загружает собственный файл network-key, либо один раз берёт зерно из key.pem Floodgate, если тот есть, либо генерирует свежий ключ, а затем отправляет его каждому бэкенду, когда туда подключается игрок.

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

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

См. Прокси-сети для полной последовательности.

Если /rspm status сообщает NetworkSync isn't running и предполагает отсутствие key.pem Floodgate, прочитайте предшествующую ошибку запуска. Подсказка устарела: текущий прокси может создать и сохранить ключ без Floodgate. Дальнейшие действия зависят от ошибки инициализации, прав на файлы и доступности бэкендов. Если команды /rspm на прокси нет вовсе, поищите в журнале запуска ошибку сетевой идентичности.

Неполный откат публикации​

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

Прокси: «Could not establish persistent RSPM network identity»​

Текущие версии не работают с несохранённым ключом. Если прокси не может сохранить вновь определённый ключ в network-key или прочитать существующий файл network-key, роль прокси останавливается при запуске с сообщением Could not establish persistent RSPM network identity: ... или Cannot read established RSPM network identity. Сетевая синхронизация, доставка Bedrock и команда /rspm на прокси не запускаются, поэтому бэкенды сохраняют свои существующие ключи, а не привязываются к ключу, который может измениться при следующем перезапуске.

Исправьте права файловой системы на папку данных прокси-плагина (plugins/resourcepackmanager/ на Velocity, plugins/ResourcePackManager/ на BungeeCord), затем перезапустите прокси. Некорректный, но читаемый файл network-key заменяется автоматически.

Прокси: «no merged pack» после нескольких циклов опроса​

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

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

  • CONNECT_FAILED на каждом бэкенде → прокси не может достучаться до HTTP-порта бэкенда. Проверьте, что адрес в velocity.toml / config.yml — это адрес, до которого прокси действительно может дозваниться (а не, например, внутрисетевое Docker-имя, которое не резолвится из сети прокси), и что объявленный HTTP-порт бэкенда открыт между прокси и бэкендом. Баннер печатает точный URL, который он пробовал; до того как бэкенд объявил свой порт, прокси откатывается на mcPort + network-http-offset-v2, поэтому ранний CONNECT_FAILED может также означать, что этот запасной порт ещё недоступен.
  • NOT_FOUND_404 на каждом бэкенде → бэкенды работают, но не производят Bedrock-пак. Запустите /rspm status на каждом бэкенде; диагностический блок Bedrock Pack скажет вам, почему.

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

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

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

Перезапустите прокси после сообщения Merged Bedrock pack published at .... При запуске RSPM заранее размещает сохранённые сопоставления предыдущего запуска, чтобы Geyser мог их зарегистрировать. Новые идентификаторы, добавленные после запуска, могут потребовать повторного перезапуска.

Бэкенд: «Backend HTTP server failed to bind on port X»​

В сетевом режиме бэкенд выставляет свои Bedrock-выводы через небольшой HTTP-сервер. Если порт занят или недоступен, вы увидите многострочный блок [ERROR] в консоли. Исправления:

  • Установите selfHostPort в другое положительное значение в config.yml.
  • Или измените networkHttpOffset-v2, чтобы сместить авто-выводимый порт от коллизии (например, RCON на mcPort + 1? установите 2 или 3). Вам не нужно обновлять прокси для совпадения: как только бэкенд успешно привязался, он автоматически объявляет прокси свой реальный HTTP-порт, поэтому собственный network-http-offset-v2 прокси имеет значение только как догадка до объявления.

Пока HTTP-сервер бэкенда упал, Bedrock-пак этого бэкенда не доходит до прокси через прямую загрузку. Резервная ретрансляция magmaguy.com по-прежнему работает (бэкенд пушит свои файлы на ретранслятор, и прокси забирает их оттуда).

Очистка устаревшего конфига v1​

Администраторы, обновляющиеся с RSPM v1, могут иметь мёртвый ключ networkHttpOffset (без -v2) в своём config.yml. RSPM v2 намеренно не читает старый ключ — вы получите дефолт v2 (1), записанный в конфиг при следующей загрузке автоматически. Мёртвый ключ v1 сидит в вашем конфиге как безвредный артефакт, пока вы не уберёте его вручную.