Réseaux proxy (BungeeCord / Waterfall / Velocity)

ResourcePackManager fonctionne sur les réseaux proxy. Il y a un seul jar — ResourcePackManager.jar — et vous installez le même jar sur chaque backend et sur le proxy. Sur un backend, il s'exécute en rôle backend (fusion, hébergement, push, conversion) ; sur un proxy Velocity ou BungeeCord/Waterfall, le même jar détecte automatiquement le chargeur de plateforme et s'exécute en rôle proxy (distribution Bedrock côté réseau). Les deux rôles se lient d'eux-mêmes : le proxy possède la clé réseau et la transmet à chaque backend la première fois qu'un joueur s'y connecte — pas de jar proxy par plateforme, pas de clé à coller.

Tout au long de cette page, « le plugin proxy » est un raccourci pour ce même ResourcePackManager.jar s'exécutant en rôle proxy.

Ce que fait le plugin proxy

Le rôle du plugin proxy est la fusion et la distribution du pack Bedrock. Sur un réseau comportant plusieurs backends, chaque backend produit son propre pack Bedrock (la version convertie de son pack Java fusionné). Le plugin proxy :

1. Interroge le petit serveur HTTP de chaque backend toutes les 5 secondes pour récupérer /bedrock.zip et /mappings.json, en privilégiant les ETags forts avec If-None-Match tout en conservant la compatibilité If-Modified-Since pour les backends plus anciens. Les fichiers inchangés renvoient 304, donc ils coûtent quasiment zéro bande passante. Chaque backend annonce le port HTTP exact auquel il s'est lié, donc le proxy atteint normalement le bon port automatiquement (voir Résolution du port HTTP du backend).
2. Attend que l'état de la boîte de réception se stabilise — il fusionne dès que deux interrogations adjacentes observent le même ensemble de hachages de fichiers.
3. Fusionne le pack Bedrock de chaque backend en un seul pack à l'échelle du réseau.
4. Lorsque des mappings d'items existent, copie le fichier de mappings personnalisés Geyser fusionné dans plugins/Geyser-*/custom_mappings/ sur le proxy.
5. Sert le pack fusionné aux clients Bedrock à la connexion via le SessionLoadResourcePacksEvent de Geyser.

Le plugin proxy n'est utile que pour les joueurs Bedrock. La distribution des packs Java sur les réseaux continue de se faire par backend via l'API classique setResourcePack / addResourcePack — les clients Java voient le pack que le backend sur lequel ils se trouvent a choisi d'envoyer. Si votre réseau est uniquement Java, vous n'avez pas besoin du plugin proxy.

Installation — une seule étape (plus Floodgate, si vous voulez Bedrock)

Floodgate

Floodgate est requis pour que les joueurs Bedrock s'authentifient sur le proxy. Il n'est pas requis pour que RSPM lie le proxy à ses backends — un réseau uniquement Java peut faire tourner le plugin proxy sans Floodgate du tout.

Si Floodgate est installé sur le proxy au moment où RSPM y démarre pour la première fois, RSPM initialise sa clé réseau une seule fois à partir de plugins/floodgate/key.pem, de sorte qu'un réseau existant qui fonctionnait déjà conserve la même identité après la mise à jour. Passé ce premier démarrage, la clé vit dans le fichier network-key propre à RSPM et key.pem n'est plus jamais lu.

Copier ResourcePackManager.jar sur le proxy

Il n'y a qu'un seul jar. Le même ResourcePackManager.jar que vous installez sur les backends Bukkit/Paper est aussi le plugin proxy — il embarque ensemble les implémentations Velocity et BungeeCord/Waterfall dans un seul jar shadé et détecte automatiquement la plateforme sur laquelle il s'exécute. Il n'y a pas de jar proxy par plateforme distinct à extraire.

Si vous avez déjà démarré les backends sans mettre RSPM sur le proxy, vous n'avez pas besoin de partir à la recherche du téléchargement : chaque backend proxifié et non doté de clé prépare une copie octet par octet identique de son propre jar dans plugins/ResourcePackManager/proxy-extension/ResourcePackManager.jar et affiche ce chemin exact dans la console. Copier ce fichier garantit que le proxy et le backend ne pourront jamais être sur des versions différentes.

Copiez le même ResourcePackManager.jar dans le dossier plugins/ de votre proxy :

Logiciel proxy	Utilisez ce jar
Velocity	ResourcePackManager.jar
BungeeCord	ResourcePackManager.jar
Waterfall (fork Bungee)	ResourcePackManager.jar

Vous pouvez le confirmer depuis un backend à tout moment en exécutant /rspm status ; la section Proxy deployment affiche Network proxy jar: ResourcePackManager.jar et Use the same jar on Bukkit/Paper, Velocity, and BungeeCord/Waterfall.

Redémarrez le proxy. C'est tout.

Il n'y a aucune configuration obligatoire à éditer et aucune clé à coller. Le proxy établit lui-même la clé réseau au démarrage et l'attribue automatiquement à chaque backend — voir Comment le proxy et les backends se lient ci-dessous. Le config.yml généré du proxy ne contient que deux réglages optionnels, tous deux décrits plus bas.

La première interrogation du proxy se déclenche environ 2 secondes après le démarrage, puis toutes les 5 secondes. Combinée à la porte de stabilité à un seul cycle, la première fusion est publiée environ 7 secondes après que le proxy peut voir au moins un backend produisant déjà du contenu.

Comment le proxy et les backends se lient

Tout ce qui suit se produit sans configuration. C'est documenté ici parce que lorsqu'un réseau ne se lie pas, connaître la séquence constitue tout le diagnostic.

1. Le proxy établit la clé. Au démarrage, il résout exactement une valeur, dans cet ordre :

1. son fichier network-key enregistré, dans le dossier de données propre au plugin proxy — l'état stable à chaque démarrage après le premier ;
2. une amorce unique dérivée de plugins/floodgate/key.pem sur le proxy, si ce fichier existe ;
3. une clé aléatoire fraîchement générée.

Quelle que soit la branche empruntée, le résultat est écrit dans network-key et réutilisé pour toujours ensuite. La console du proxy indique laquelle s'est produite (Network key loaded ✓, adopted from Floodgate key.pem, ou New network key generated). Si le fichier ne peut pas être écrit, le proxy journalise une erreur au niveau [ERROR] — cet état n'est pas fatal pour le démarrage en cours, mais le redémarrage suivant génère une clé différente et délie silencieusement chaque backend : corrigez donc les permissions du dossier.

2. Le proxy transmet la clé à chaque backend. Dès qu'un joueur se connecte à un backend, le proxy lui envoie la clé sur le canal de messages de plugin rspm:network. Le sens est délibéré : un backend ne peut physiquement pas la demander, car un proxy ne relaie pas un message de plugin sur un canal que le client du joueur n'a jamais enregistré.

3. Le backend l'adopte et la conserve. Il enregistre la clé dans son data.yml et signale Network key received from the proxy; this backend is now linked. Les attributions ne sont honorées que tant que le backend ne détient aucune clé — un backend déjà établi journalise un avertissement et conserve ce qu'il a plutôt que de laisser un message le rattacher à un autre réseau.

Sur Velocity avec le transfert moderne, les attributions sont signées avec un HMAC sur le forwarding.secret du proxy, et un backend configuré pour le transfert moderne exige cette signature. Sur BungeeCord, Waterfall et le transfert historique, il n'existe aucun secret partagé pour signer, donc les attributions sont non signées et acceptées comme telles.

Un backend qui atteint l'étape 2 mais jamais l'étape 3 conserve sa source de clé à not set. C'est exactement l'état qui déclenche la préparation de proxy-extension/ et la bannière d'avertissement spécifique à Bedrock.

Vérification du bon fonctionnement

Console du proxy

Dans les ~10 secondes suivant le redémarrage (en supposant que les backends tournent), vous devriez voir :

[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 sur le proxy

Affiche un instantané : l'empreinte de la clé réseau, la liste des backends, les résultats de récupération par backend et par chemin (200 / 304 / 404 / CONNECT_FAILED) pour /bedrock.zip, /mappings.json et /rspm-update.jar, les annonces de points d'accès reçues, les entrées de relais visibles, le compteur d'interrogations vides consécutives, la présence sur le disque du pack Bedrock fusionné et des mappings fusionnés (avec leurs tailles) ainsi que le préfixe SHA-1 du pack fusionné actuel, le repli network-http-offset, le dossier du plugin Geyser détecté et le fichier de mappings déployé, et la présence de Floodgate / Geyser sur le proxy. Velocity accepte resourcepackmanager.command.status ou resourcepackmanager.* ; BungeeCord enregistre exactement le nœud resourcepackmanager.command.status, que les plugins de permissions peuvent satisfaire par expansion de joker. La console peut l'exécuter. La sortie ne révèle aucun secret (la clé réseau n'apparaît que sous la forme d'une courte empreinte de hachage à sens unique, et aucun jeton d'authentification n'est affiché), donc des autorisations larges sont sans danger.

/rspm status sur un backend

La ligne Deploy mode devrait afficher network-backend. Network key fingerprint devrait afficher un court hachage — il doit correspondre à l'empreinte affichée par le proxy. Network key source vous indique comment ce backend l'a obtenue :

Ligne de source	Signification
provided by the proxy	L'état lié normal. Le proxy a attribué la clé lors de la connexion d'un joueur.
saved on this server	Déjà doté d'une clé lors d'un démarrage précédent (ou serveur autonome ayant généré la sienne).
adopted from Floodgate's key	Initialisée une seule fois à partir du plugins/floodgate/key.pem local de ce backend.
not set — the proxy sends one when a player next connects here	Non lié. Soit aucun joueur ne s'est connecté depuis le démarrage du proxy, soit le proxy n'a pas RSPM / est un proxy non pris en charge.

Client Bedrock

Connectez-vous en Bedrock. Vous devriez voir la fenêtre de téléchargement du pack de ressources avant d'arriver dans le monde. Les items personnalisés s'affichent avec leurs modèles prévus au lieu de simples supports à armure.

Référence de configuration

Backend plugins/ResourcePackManager/config.yml

Le mode réseau est auto-détecté — il n'y a pas de drapeau networkMode: true à activer. Signaux de détection (un seul suffit) :

1. Floodgate présent, Geyser-Spigot absent — signal le plus fort pour le cas Bedrock-via-proxy.
2. spigot.yml: settings.bungeecord: true — ancien commutateur de transfert d'IP BungeeCord / Waterfall.
3. paper-global.yml: proxies.velocity.enabled: true — transfert moderne Velocity.

Le seul réglage qui compte spécifiquement pour le mode réseau est networkHttpOffset-v2, qui contrôle le port HTTP de repli que le proxy interrogera sur chaque backend (le port que le proxy devine avant qu'un backend ait annoncé le port auquel il s'est réellement lié). La valeur par défaut 1 fonctionne sur pratiquement tous les hébergeurs. Voir Auto-hébergement pour l'explication complète de la résolution des ports.

En fonctionnement normal, chaque backend annonce automatiquement son vrai port HTTP au proxy (via le registre de points d'accès magmaguy.com), donc le décalage n'est consulté qu'en repli au démarrage ou en cas d'échec. Voir Résolution du port HTTP du backend ci-dessous.

config.yml du proxy

Le plugin proxy écrit une configuration par défaut minimale au premier démarrage. Le dossier diffère selon la plateforme, car chaque proxy le dérive de son propre identifiant de plugin :

Logiciel proxy	Chemin de configuration
Velocity	plugins/resourcepackmanager/config.yml
BungeeCord / Waterfall	plugins/ResourcePackManager/config.yml

Elle contient exactement deux réglages, tous deux optionnels :

# 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

Les équivalents côté backend sont networkHttpOffset-v2 et geyserExtensionAutoInstall dans le config.yml du backend. Les deux côtés sont des réglages distincts — désactiver l'installation de l'extension sur le proxy ne la désactive pas sur les backends, et inversement.

À côté de config.yml, le plugin proxy écrit également un fichier network-key dans le même dossier. C'est un état généré, pas de la configuration : ne l'éditez pas, et ne le copiez pas d'un réseau à un autre. Le supprimer fait générer au proxy une toute nouvelle clé à son prochain démarrage, ce qui délie chaque backend déjà approvisionné (chaque backend conserve l'ancienne clé et n'en adoptera pas une nouvelle). Le copier est la bonne manœuvre dans un seul cas : deux proxys devant le même ensemble de backends, qui doivent partager une seule clé.

Il n'existe aucun réglage force-resource-pack côté proxy. Forcer l'acceptation du pack est une décision côté backend (forceResourcePack dans le config.yml du backend), car le plugin proxy ne gère que la distribution du pack Bedrock — il n'envoie jamais de packs Java. Si un ancien config.yml de proxy contient encore une ligne force-resource-pack, elle est simplement ignorée et peut être supprimée.

Il n'y a délibérément aucune entrée de configuration network-key — une clé à coller a été retirée avant la sortie publique parce que les fautes de frappe cassaient silencieusement le lien proxy↔backend sans la moindre erreur nulle part. La clé est établie par le proxy et attribuée automatiquement aux backends, comme décrit dans Comment le proxy et les backends se lient.

Résolution du port HTTP du backend

Le proxy doit savoir quel port HTTP interroger sur chaque backend pour /bedrock.zip et /mappings.json. Il résout ce port dans cet ordre :

1. Point d'accès annoncé par le backend (préféré). Chaque backend téléverse le port HTTP exact auquel il s'est lié vers le registre de points d'accès magmaguy.com, indexé par la clé réseau. À chaque interrogation, le proxy actualise cette liste et fait correspondre le port annoncé d'un backend à l'entrée de la liste de serveurs par port Minecraft (et par hôte lorsque disponible). Cela signifie qu'un administrateur qui définit un selfHostPort explicite sur un backend, ou dont le backend atterrit automatiquement sur mcPort + 1, est géré de façon identique — le proxy utilise le port auquel le backend s'est réellement lié.
2. mcPort + network-http-offset-v2 (repli). Utilisé uniquement lorsqu'aucune annonce correspondante n'est disponible (par ex. à la première interrogation avant qu'un backend ait annoncé, ou si le registre de points d'accès est brièvement inaccessible). C'est pourquoi les deux décalages devraient quand même s'accorder si vous comptez sur le repli.

Le proxy ne scanne délibérément pas les ports d'un backend en repli — cela ressemblerait à un comportement abusif aux yeux de l'hébergeur. Lorsque la récupération directe ne peut pas fonctionner du tout, le chemin de relais (ci-dessous) est la réponse catégorique.

/rspm status sur le proxy montre, pour chaque backend, quel port a été choisi et s'il provient d'une annonce ou du repli sur le décalage.

Stabilité et cadence de fusion

Le proxy attend que l'état de la boîte de réception se stabilise avant de fusionner : la première interrogation établit l'ensemble de référence des hachages de fichiers, et l'interrogation suivante qui observe le même ensemble déclenche la fusion (une porte de stabilité à un cycle). Avec le délai initial d'environ 2 s et l'intervalle d'interrogation de 5 s, cela place la première fusion environ 7 s après que le proxy peut voir au moins un backend produisant du contenu. Les fusions suivantes ne re-zippent que lorsque l'ensemble SHA-1 des fichiers de la boîte de réception change, donc une longue période calme ne coûte quasiment rien.

Les backends écrivent leur bedrock.zip dans un fichier temporaire et le renomment de façon atomique, de sorte que la route /bedrock.zip sert toujours un zip complet — le proxy n'a jamais à se prémunir contre des lectures à moitié écrites, ce qui explique pourquoi la porte est à un seul cycle plutôt que deux.

Récupération directe vs repli relais

Le chemin par défaut est la récupération directe : le proxy effectue un GET HTTP vers http://<backend-host>:<mcPort + offset><path> pour chaque backend.

Si le proxy ne peut pas atteindre directement le port HTTP d'un backend (typique des hébergements Minecraft mutualisés / managés où les ports MC sont exposés mais les ports adjacents sont bloqués par le pare-feu), le backend envoie ses fichiers bedrock.zip et mappings.json vers un point de relais sur magmaguy.com, sous l'espace de noms du réseau (dérivé de la clé réseau). Le proxy liste et télécharge depuis le relais lorsque la récupération directe échoue durement.

Les deux chemins alimentent la même étape de fusion, donc l'opérateur n'a jamais à choisir — la récupération directe est préférée (zéro coût de bande passante vers magmaguy.com), le relais prend le relais de manière transparente quand c'est nécessaire.

Le relais a un TTL de 30 minutes côté serveur. Les backends envoient toutes les 25 minutes pour maintenir l'entrée en vie ; un arrêt propre supprime l'entrée immédiatement plutôt que d'attendre le TTL.

Dépannage des problèmes courants

Un backend ne reçoit jamais de clé réseau

Symptôme : /rspm status sur le backend affiche Network key source: not set — the proxy sends one when a player next connects here, et la console du backend répète :

[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.

Passez ces points en revue dans l'ordre :

1. Quelqu'un s'est-il réellement connecté à ce backend depuis le démarrage du proxy ? L'attribution voyage avec une connexion de joueur. Un lobby que personne n'a encore visité est légitimement sans clé.
2. RSPM est-il seulement présent sur le proxy ? Le backend prépare une copie de son propre jar dans plugins/ResourcePackManager/proxy-extension/ResourcePackManager.jar exactement pour ce cas. Copiez-la dans le dossier plugins/ du proxy et redémarrez le proxy.
3. Transfert moderne Velocity : le secret de transfert du backend correspond-il à celui du proxy ? Un backend configuré pour le transfert moderne rejette volontairement une attribution non signée ou mal signée — cette vérification est la seule chose qui empêche un proxy non autorisé de doter vos backends d'une clé. Le log du backend indique lequel des deux cas s'est produit. Corrigez le secret des deux côtés et la prochaine connexion de joueur réessaie automatiquement ; aucun redémarrage n'est nécessaire d'un côté ou de l'autre pour réarmer.
4. Le proxy est-il un proxy non pris en charge ? Seuls Velocity et BungeeCord/Waterfall exécutent le rôle proxy.

Notez que le key.pem de Floodgate ne fait plus partie de tout cela. Un plugins/floodgate/key.pem absent sur le proxy est un état pleinement pris en charge — le proxy génère sa propre clé à la place. Floodgate reste requis pour que les joueurs Bedrock puissent atteindre le proxy tout court.

Deux proxys devant les mêmes backends

Les deux proxys doivent présenter la même clé réseau, sinon chaque backend se lie à celui qui l'a atteint en premier et rejette l'autre (en journalisant A proxy offered a network key that differs from the one this backend already uses). Copiez le fichier network-key du dossier de données RSPM du proxy principal vers celui de l'autre proxy, puis redémarrez-le.

Avertissement « No merged pack content » après ~20 secondes

Après 4 cycles d'interrogation vides consécutifs, le proxy enregistre un avertissement unique sur plusieurs lignes listant chaque backend interrogé, l'URL essayée et le résultat. L'avertissement explique les correctifs les plus courants :

• CONNECT_FAILED sur chaque backend — le proxy ne peut pas du tout atteindre le port HTTP du backend. Vérifiez que l'adresse dans velocity.toml / config.yml est bien une adresse que le proxy peut réellement atteindre (et non un nom interne Docker qui ne se résout pas depuis le réseau du proxy), et que le port HTTP du backend est ouvert entre le proxy et le backend. L'avertissement affiche l'hôte:port HTTP exact qu'il a essayé pour chaque backend et indique si ce port provenait de l'annonce du backend ou du repli mcPort + networkHttpOffset-v2. Si vous n'avez aucun moyen d'ouvrir ce port (hébergement managé), voir la section repli relais ci-dessus — le backend devrait téléverser automatiquement vers le relais.
• NOT_FOUND_404 sur chaque backend — les backends sont en ligne mais ne produisent pas de pack Bedrock. Exécutez /rspm status sur chaque backend ; le bloc de diagnostic Bedrock Pack vous indiquera pourquoi (le plus souvent : aucun mapping d'item convertible ni bundle d'entité dans le pack fusionné, ou le premier cycle de fusion n'est pas encore terminé).

L'avertissement se déclenche une seule fois par période bloquée. Une ligne NetworkSync: recovered est enregistrée quand au moins un backend recommence à renvoyer du contenu.

Les joueurs Bedrock ne voient aucun modèle personnalisé au premier démarrage du proxy

Geyser enregistre sa table d'items personnalisés uniquement au démarrage du proxy. Si le proxy a démarré avant qu'un backend produise un pack Bedrock, Geyser tourne avec une table de mappings vide et le reste pour le reste de la session.

Solution : redémarrez le proxy une fois après que le backend a enregistré sa première ligne Merged Bedrock pack published. RSPM pré-déploie les mappings du run précédent à chaque démarrage du proxy, donc cela ne se produit que sur une toute nouvelle installation — les démarrages suivants ont déjà quelque chose de prêt avant que Geyser scanne.

Avertissements « Duplicate bedrock_identifier » au démarrage du proxy

Deux backends ont émis le même identifiant Bedrock pour le même item de base. Le dernier qui écrit l'emporte ; sans conséquence si vous n'avez besoin que d'un seul backend pour fournir cet item. Si les deux backends doivent héberger des items personnalisés distincts sous le même item de base, renommez l'un des modèles Java source pour que les hachages auto-générés diffèrent.

Un joueur Bedrock est connecté mais ne voit pas le pack

Le proxy déclenche une bannière de chat pour tous les joueurs Java en ligne lorsqu'une session Bedrock se charge sans pack RSPM utilisable :

⚠ [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: ...)

Le joueur Bedrock lui-même reçoit également une fenêtre modale, et la console du proxy reçoit une bannière. Si vous avez besoin de creuser davantage, activez le flux de débogage (disponible sur Velocity comme sur BungeeCord) :

/rspm debug bedrock on

Cela active des lignes de log verbeuses [RSPM-BedrockDebug] depuis GeyserBinder. Reproduisez le problème, puis désactivez-le :

/rspm debug bedrock off

Le paramètre revient à off au redémarrage du proxy afin qu'il ne puisse pas être accidentellement laissé activé.

Mise à jour de RSPM sur un réseau

C'est le même jar sur chaque backend et sur le proxy, donc maintenez tous les composants sur la même version.

La voie manuelle est : mettre à jour le jar du backend, recopier ce même ResourcePackManager.jar dans le dossier plugins/ du proxy, redémarrer le proxy.

RSPM peut aussi faire la moitié « proxy » lui-même. Chaque backend propose son jar de plugin universel au proxy via une route authentifiée (/rspm-update.jar, protégée par un jeton dérivé de la clé réseau partagée — la clé elle-même n'est jamais transmise). Le proxy valide que le fichier proposé est bien un jar RSPM universel complet, avec des versions de descripteurs de plateforme concordantes et les points d'entrée attendus, refuse les rétrogradations, et vérifie les octets préparés par rapport à la taille et au SHA-256 annoncés avant de remplacer quoi que ce soit. Il prépare le même jar pour le plugin proxy et, lorsqu'un Geyser hébergé sur le proxy est détecté, son extension Geyser embarquée ; il applique ces fichiers à l'arrêt du proxy et conserve les fichiers précédents comme copies de repli.

Il s'agit d'une frontière de confiance réseau authentifiée, pas d'une vérification indépendante de provenance auprès de Nightbreak : tout backend qui a été approvisionné avec la clé réseau partagée est considéré comme habilité à proposer un jar RSPM structurellement valide de version égale ou plus récente. Protégez cette clé et traitez chaque backend qui la partage comme une infrastructure de confiance.

En pratique, mettre à jour les backends puis redémarrer le proxy suffit donc généralement — le proxy aura préparé le jar correspondant pour lui-même. Une mise à jour rejetée journalise Rejected backend-offered ResourcePackManager update: ... avec la raison.

Ce qui n'est pas encore pris en charge

• Packs Java sur les réseaux via le plugin proxy. Les clients Java reçoivent les packs directement depuis chaque backend via l'API classique. Il n'y a pas de mixeur de pack Java côté proxy.
• Fusion de packs Java entre backends. Le pack Java de chaque backend est indépendant. Si un joueur change de backend, il reçoit le pack du nouveau backend.
• Rotation à chaud de la clé réseau. Un backend adopte une clé exactement une fois et n'acceptera pas de remplacement venant d'un message. La faire tourner implique de supprimer le fichier network-key du proxy et d'effacer networkKey du data.yml de chaque backend, puis de tout redémarrer.