Réseaux proxy (BungeeCord / Velocity)

ResourcePackManager fonctionne sur les réseaux proxy. Installez le même ResourcePackManager.jar sur le proxy et sur chaque backend qui fournit des packs de ressources. Les autres serveurs enregistrés peuvent rester sans RSPM. Sur un backend, il fusionne, héberge, distribue et convertit les packs. Sur Velocity ou BungeeCord, le jar détecte la plateforme proxy et gère la distribution Bedrock du réseau. Le proxy possède la clé réseau et la transmet à chaque backend lorsqu'un joueur s'y connecte pour la première fois.

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.

Rôle du 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. Détecte les backends enregistrés qui exécutent RSPM, puis interroge ces participants toutes les 5 secondes pour obtenir /bedrock.zip et /mappings.json. Il privilégie les ETags forts avec If-None-Match et conserve la compatibilité If-Modified-Since pour les anciens backends. Les fichiers inchangés renvoient 304. Chaque backend annonce son port HTTP d'écoute exact, que le proxy utilise donc normalement automatiquement. Consultez la 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.

Sur les réseaux, les packs Java sont distribués par chaque backend via l'API classique setResourcePack / addResourcePack. En plus de la fusion des packs Bedrock, le rôle proxy fournit les clés réseau et propage les mises à jour RSPM par une route authentifiée. Un réseau exclusivement Java n'en a pas besoin pour distribuer ses packs Java.

Installation

Floodgate

Floodgate permet aux joueurs Bedrock de s'authentifier sans compte payant Java Edition. Geyser peut également utiliser l'authentification en ligne avec un compte Java ; suivez le guide d'installation de Geyser pour le mode choisi. RSPM peut relier son proxy et ses backends sans Floodgate.

Si Floodgate est installé au premier démarrage de RSPM sur le proxy, RSPM dérive sa clé réseau de plugins/floodgate/key.pem, préservant l'identité d'un réseau existant. Les démarrages suivants utilisent le fichier network-key de RSPM tant qu'il contient une clé valide. Si elle manque ou est invalide, RSPM réessaie la source Floodgate avant de générer une clé aléatoire.

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 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 installer RSPM sur le proxy, aucun nouveau téléchargement n'est nécessaire : chaque backend derrière un proxy et dépourvu de clé prépare une copie strictement identique de son propre jar dans plugins/ResourcePackManager/proxy-extension/ResourcePackManager.jar et affiche ce chemin exact dans la console. Copier ce fichier installe la version actuellement exécutée sur ce backend ; mettez aussi les autres backends à jour pour conserver la même version sur tout le réseau.

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

Logiciel proxy	Utilisez ce jar
Velocity	ResourcePackManager.jar
BungeeCord	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.

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.

Découverte des backends

Le proxy recherche RSPM sur les serveurs enregistrés sans faire attendre la synchronisation des packs pour ceux qui ne l'exécutent pas. Les annonces de points d'accès et le contenu en cache déjà validé peuvent identifier immédiatement les participants. Sinon, la découverte vérifie le point d'accès HTTP résolu en arrière-plan, avec au plus deux vérifications simultanées et un délai d'expiration de cinq secondes. Les serveurs non confirmés sont revérifiés après environ une minute.

/rspm status indique le nombre de participants confirmés et l'état de découverte de chaque serveur restant. RSPM not confirmed signifie que la découverte n'a pas établi la présence de RSPM ; cela ne prouve pas son absence. Vérifiez l'adresse, le port HTTP et l'accessibilité du backend s'il doit participer. L'installation de RSPM sur un autre backend est détectée automatiquement.

Une fois un backend confirmé, les échecs de connexion sont signalés comme des échecs d'actualisation de ce participant. Le contenu disponible déjà validé est conservé, et les résultats directs et par relais restent visibles dans /rspm status. Un compteur d'interrogations vides à zéro signifie que du contenu est disponible, pas que toutes les connexions fonctionnent.

La découverte n'accorde aucun accès aux mises à jour. L'authentification par clé réseau et la validation du jar restent nécessaires pour les mises à jour automatiques du plugin.

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.

La clé obtenue est enregistrée dans network-key et réutilisée tant qu'elle reste valide. La console indique sa source (Network key loaded ✓, adopted from Floodgate key.pem ou New network key generated). Un fichier network-key mal formé est remplacé. Si RSPM ne peut pas enregistrer une nouvelle clé, ou ne peut pas lire un fichier network-key existant, le rôle proxy ne démarre pas et affiche Could not establish persistent RSPM network identity ou Cannot read established RSPM network identity, plutôt que de fonctionner avec une clé qui pourrait changer au prochain redémarrage. Corrigez les permissions du dossier et redémarrez le proxy.

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 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.
3. paper-global.yml: proxies.velocity.enabled: true — transfert moderne Velocity.

Le réglage de port de secours du mode réseau est networkHttpOffset-v2. Il contrôle le port HTTP de repli interrogé sur chaque backend, avant que celui-ci annonce son port d'écoute réel. La valeur par défaut est 1 ; le port correspondant doit être joignable entre le proxy et le backend, ou le relais doit être disponible. Consultez Auto-hébergement pour le détail 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	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 proxy écrit network-key. Préservez cet état généré et ne le copiez pas entre réseaux distincts. Le supprimer relance la résolution au prochain démarrage ; une source Floodgate disponible peut reproduire la même clé. Si elle change, les backends déjà liés conservent l'ancienne et refusent la nouvelle. Deux proxys desservant les mêmes backends doivent partager une clé : copiez le fichier entre ces proxys.

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

Les préférences d'hébergement Java s'appliquent aussi aux backends de proxy. Si une sonde d'auto-hébergement Java échoue, RSPM peut passer à l'hébergement distant pour Java tout en maintenant le serveur HTTP du backend pour /bedrock.zip et /mappings.json.

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 et relais de secours

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, sans choix à faire pour l'administrateur. La récupération directe est privilégiée pour ne pas consommer de bande passante sur magmaguy.com ; le relais est utilisé automatiquement au besoin.

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 exécutent le rôle proxy. Waterfall n'est pas pris en charge.

Le key.pem de Floodgate n'intervient plus dans cette procédure. L'absence de plugins/floodgate/key.pem sur le proxy est parfaitement prise en charge : le proxy génère sa propre clé. L'authentification Floodgate est distincte de la liaison réseau RSPM.

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 environ 20 secondes

Après quatre cycles d'interrogation vides consécutifs avec des participants RSPM confirmés, le proxy enregistre un avertissement listant ces participants, les URL essayées et leurs résultats. Un nouveau proxy qui cherche encore son premier participant ne compte pas les autres serveurs enregistrés comme des backends de packs en échec. 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 proxy a consigné sa première ligne Merged Bedrock pack published. RSPM déploie les mappings précédents avant chaque démarrage du proxy : ils peuvent ainsi être chargés avant l'analyse de Geyser. L'ajout ou la suppression d'objets personnalisés modifie aussi cet ensemble enregistré au démarrage et exige un redémarrage. Il en va de même pour de nouveaux identifiants d'entités personnalisées ou types de propriétés.

Avertissements « Duplicate bedrock_identifier » au démarrage du proxy

Des identifiants Bedrock différents peuvent partager le même sélecteur Java d’objet/modèle/prédicats. Renommer uniquement le modèle source résolu ne suffit pas à distinguer ces objets. Attribuez des sélecteurs distincts, par exemple des valeurs custom-model-data différentes. Le fusionneur actuel préfère une définition moderne à une entrée legacy du même sélecteur ; à type égal, la dernière gagne. La déduplication conserve un seul objet.

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

Le proxy envoie une bannière dans le chat au personnel connecté disposant de resourcepackmanager.* lorsqu'une session Bedrock se charge sans pack RSPM utilisable :

⚠ [RSPM] Alice s'est connectée depuis Bedrock avant que le pack de ressources soit prêt et voit de simples supports à armure au lieu des modèles personnalisés. Demandez-lui de se déconnecter puis de se reconnecter ; le pack sera chargé lors de sa prochaine 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.

Échecs d'authentification des mises à jour exécutables

Une réponse HTTP 401 sur /rspm-update.jar suspend uniquement la propagation automatique du jar depuis ce backend. Les interrogations directes du pack Bedrock et des mappings continuent. La route de mise à jour est réessayée avec un délai progressif commençant à une minute et plafonnant à quinze minutes. Comparez les empreintes de clé réseau de /rspm status des deux côtés, puis vérifiez que l'URL signalée mène au bon backend et que les versions correspondent.

Si les empreintes diffèrent, /rspm status sur le proxy indique la procédure actuelle : vérifiez qu'il s'agit bien du proxy et du backend prévus, arrêtez le backend concerné, sauvegardez son plugins/ResourcePackManager/data.yml, retirez uniquement son entrée networkKey, puis démarrez-le et connectez-vous via ce proxy afin qu'il reçoive de nouveau une clé. Conservez le network-key du proxy et toutes les clés Floodgate. L'avertissement 401 de la console du proxy recommande encore de copier le key.pem de Floodgate ; ce conseil est obsolète, car RSPM conserve sa propre identité réseau et modifier key.pem ne remplace pas une clé RSPM déjà établie. Conservez les deux sorties d'état pour le support.

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é uniquement s'il n'en possède pas et refuse les messages de remplacement. Tous les composants arrêtés, supprimer network-key du proxy et networkKey du data.yml de chaque backend permet une nouvelle attribution. Cela ne garantit pas une nouvelle clé : le proxy peut dériver la même clé de key.pem de Floodgate.