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

ResourcePackManager работает в прокси-сетях. Существует один jar — ResourcePackManager.jar — и вы устанавливаете тот же jar на каждый бэкенд и на прокси. На бэкенде он работает в роли бэкенда (объединение, хостинг, отправка, преобразование); на прокси Velocity или BungeeCord/Waterfall тот же jar автоматически определяет загрузчик платформы и работает в роли прокси (доставка Bedrock на стороне сети). Две роли связывают себя сами: прокси владеет сетевым ключом и отправляет его каждому бэкенду при первом подключении игрока туда — никаких отдельных прокси-jar под каждую платформу, никакого ключа для вставки.

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

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

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

1. Опрашивает небольшой HTTP-сервер каждого бэкенда каждые 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.

Прокси-плагин полезен только для Bedrock-игроков. Доставка Java-пака в сетях по-прежнему происходит на каждом бэкенде отдельно через обычный API setResourcePack / addResourcePack — Java-клиенты видят тот пак, который решил отправить бэкенд, на котором они находятся. Если ваша сеть только для Java, прокси-плагин вам не нужен.

Настройка — один шаг (плюс Floodgate, если вам нужен Bedrock)

Floodgate

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Какая бы ветка ни сработала, результат записывается в network-key и используется всегда после этого. Консоль прокси сообщает, что именно произошло (Network key loaded ✓, adopted from Floodgate key.pem или New network key generated). Если файл невозможно записать, прокси логирует ошибку на уровне [ERROR] — для текущей загрузки это не фатально, но следующий перезапуск сгенерирует другой ключ и молча отвяжет каждый бэкенд, поэтому исправьте права на папку.

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

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

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

Бэкенд, который дошёл до шага 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 / Waterfall.
3. paper-global.yml: proxies.velocity.enabled: true — современный форвардинг Velocity.

Единственная настройка, имеющая значение именно для сетевого режима, — это networkHttpOffset-v2, которая контролирует запасной HTTP-порт, на который прокси будет опрашивать каждый бэкенд (порт, который прокси угадывает до того, как бэкенд объявил порт, на который он реально привязался). По умолчанию 1 работает практически на любом хостинге. См. Self-hosting для полной истории разрешения портов.

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

Прокси: config.yml

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

Прокси-софт	Путь к конфигу
Velocity	plugins/resourcepackmanager/config.yml
BungeeCord / Waterfall	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 в той же папке. Это сгенерированное состояние, а не конфигурация: не редактируйте его и не копируйте между разными сетями. Удаление файла заставит прокси сгенерировать совершенно новый ключ при следующей загрузке, что отвяжет каждый уже снабжённый ключом бэкенд (каждый бэкенд сохранит старый ключ и не примет замену). Копировать его правильно только в одном случае: два прокси перед одним и тем же набором бэкендов, которые обязаны использовать один ключ.

Настройки 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 на прокси показывает по каждому бэкенду, какой порт был выбран и пришёл ли он из объявления или из запасного смещения.

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

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

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

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

Путь по умолчанию — прямая загрузка: прокси делает 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 по-прежнему нужен, чтобы Bedrock-игроки вообще смогли попасть на прокси.

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

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

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

После 4 последовательных пустых циклов опроса прокси записывает однократное многострочное предупреждение, перечисляющее каждый опрошенный бэкенд, 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-моделей, чтобы автогенерируемые хеши различались.

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

Прокси отправляет чат-баннер всем онлайн-Java-игрокам, когда сессия Bedrock загружается без работоспособного RSPM-пака:

⚠ [RSPM] Bedrock player Alice connected before the resource pack was ready — they're seeing plain armor stands instead of custom models. Tell them to disconnect and reconnect; the pack will load on their next session. (Cause: ...)

Сам 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: ... с указанием причины.

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

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