BungeeCord et Velocity : créer un réseau Minecraft

BoxToPlay-helper · July 28, 2026, 4:29pm

Ce tutoriel vous accompagne dès la création des liaisons dans le panel BoxToPlay, puis jusqu’aux premiers transferts en jeu. Vous allez définir le serveur d’arrivée, tester les commandes, déterminer si certains serveurs doivent partager leur inventaire, créer un portail dans le lobby et comprendre quand une répartition de charge devient utile.

Si vous hésitez encore entre les deux proxies, commencez par notre comparatif BungeeCord vs Velocity. Vous pouvez aussi consulter les documentations officielles de BungeeCord et de Velocity.

Le parcours le plus court est le suivant :

Reliez chaque serveur Minecraft au proxy dans le panel.
Redémarrez d’abord les serveurs Minecraft concernés, puis le proxy.
Connectez-vous avec l’adresse et le port du proxy.
Vérifiez chaque destination avec /server.
Si plusieurs backends doivent partager l’inventaire, configurez une seule solution de synchronisation et sauvegardez d’abord les données des joueurs.
Installez Advanced Portals sur le lobby si vous voulez un portail en jeu.
Ajoutez un plugin de répartition sur le proxy uniquement si plusieurs instances proposent le même mode de jeu.

Comprendre le rôle du proxy

BungeeCord et Velocity se placent devant vos serveurs Minecraft. Les joueurs se connectent à une seule adresse publique, celle du proxy, qui les envoie ensuite vers l’un des serveurs reliés.

Joueur
  ↓
Adresse du proxy
  ↓
BungeeCord ou Velocity
  ├── lobby
  ├── survival
  ├── creative
  └── minigames

Dans ce tutoriel :

Un backend est un serveur Minecraft placé derrière le proxy.
Une destination est le nom d’une liaison, par exemple survival.
Une instance est un serveur concret parmi plusieurs serveurs qui proposent le même mode de jeu, par exemple survival-1.

Chaque backend conserve ses propres mondes, plugins et données. Le proxy permet de passer de l’un à l’autre, mais il ne synchronise pas automatiquement les inventaires, l’économie, les grades, les sanctions ou le chat.

1. Terminer la liaison côté BoxToPlay

Ouvrez votre serveur BungeeCord ou Velocity dans le panel BoxToPlay :

Cliquez sur Liaisons serveurs dans le menu de gauche.
Cliquez sur Lier un serveur Minecraft.
Dans Nom du serveur, saisissez un identifiant court sans espace, par exemple lobby ou survival.
Laissez BoxToPlay coché si le serveur Minecraft appartient au même compte, puis choisissez-le dans Choix du serveur.
Avec BungeeCord, vous pouvez aussi définir le MOTD associé à cette entrée et activer Restricted pour exiger la permission bungeecord.server.nom-du-serveur. Ces deux champs ne sont pas proposés dans le formulaire Velocity.
Cliquez sur Valider.

Cette première vue récapitule les serveurs déjà reliés. Le bouton Lier un serveur Minecraft ouvre la fenêtre ci-dessous.

Le nom de la liaison est un identifiant technique. Si vous choisissez survival, écrivez exactement survival dans les commandes, les portails et les plugins. Ce nom n’est ni le nom du monde, ni l’adresse IP, ni le port du serveur.

Serveur Minecraft hébergé chez BoxToPlay

Lorsque le backend appartient au même compte BoxToPlay, le panel enregistre la destination sur le proxy et prépare automatiquement les fichiers compatibles du serveur Minecraft. Pour un backend Paper, Purpur ou Spigot, cela comprend notamment le passage en mode hors ligne et l’activation du transfert d’informations adapté au proxy.

Le mode hors ligne est nécessaire parce que le proxy authentifie désormais le joueur. Il rend toutefois dangereux tout accès direct au backend : une personne qui contourne le proxy pourrait tenter d’usurper un joueur. Les ports des backends doivent donc rester accessibles uniquement depuis le proxy et les services techniques nécessaires.

BungeeCord utilise son transfert historique. Velocity peut utiliser le transfert compatible BungeeCord ou le transfert moderne de Velocity, avec un secret partagé. Paper prend en charge ce protocole moderne côté backend. Le secret ajoute une protection, mais ne remplace pas le filtrage réseau.

BoxToPlay automatise les réglages que le logiciel du backend sait gérer. Un serveur Forge, NeoForge ou Fabric peut demander un mod de compatibilité supplémentaire : le panel ne transforme pas automatiquement son logiciel et n’installe pas ce mod à votre place.

Serveur Minecraft hébergé ailleurs

Pour un serveur externe, le panel enregistre la destination sur le proxy, mais vous devez configurer manuellement le backend chez l’autre hébergeur. Utilisez le même mode de transfert des deux côtés, renseignez le secret de Velocity si nécessaire et interdisez l’accès direct au port du backend.

Appliquer les changements

Après avoir ajouté ou modifié une liaison :

Redémarrez les backends concernés.
Redémarrez ensuite BungeeCord ou Velocity.
Vérifiez que chaque backend est démarré avant le premier essai.

Velocity propose /velocity reload pour relire velocity.toml, mais le parcours de liaison BoxToPlay peut modifier plusieurs éléments. Un redémarrage complet reste donc la méthode attendue. Avec BungeeCord, ne comptez pas sur /greload pour appliquer de façon fiable une modification importante.

2. Choisir le serveur d’arrivée

Le serveur d’arrivée est généralement un lobby. C’est là que les joueurs peuvent lire les informations du réseau, choisir un mode de jeu et utiliser un portail, un PNJ ou un menu.

Avec BungeeCord

Dans la configuration du serveur proxy BoxToPlay, choisissez votre serveur par défaut. Il devient la première priorité BungeeCord.

Le réglage Forcer le serveur par défaut change le comportement à la reconnexion :

Activé : le joueur revient toujours sur le serveur par défaut.
Désactivé : BungeeCord peut essayer de le renvoyer vers son dernier serveur connu, si celui-ci est disponible.

Les priorités constituent un ordre d’essai. Si le premier serveur ne répond pas, BungeeCord peut tenter le suivant. Ce n’est pas une répartition selon le nombre de joueurs ou la consommation de ressources.

Avec Velocity

Velocity utilise une liste ordonnée appelée try. Le premier serveur disponible devient le point d’arrivée. Les suivants servent de solutions de repli lors de la connexion. Ils peuvent aussi recevoir un joueur après une déconnexion inattendue d’un backend si l’option failover-on-unexpected-server-disconnect est activée.

Dans le panel BoxToPlay, le serveur sélectionné comme prioritaire est placé en tête, puis les autres liaisons suivent. Là encore, Velocity parcourt un ordre. Il ne choisit pas nativement le serveur le moins chargé.

3. Tester les transferts avec des commandes

Les commandes permettent de valider le réseau avant d’ajouter un portail ou un menu. Connectez-vous en jeu avec l’adresse et le port du proxy, puis utilisez :

/server

Cette commande indique le serveur actuel et propose les destinations accessibles. Pour en rejoindre une :

/server lobby
/server survival
/server minigames

Pour consulter les joueurs connectés :

/glist

Sur Velocity, /glist exige la permission velocity.command.glist et /glist all détaille les joueurs par serveur. Sur BungeeCord, /glist utilise bungeecord.command.list.

Un membre autorisé de l’équipe d’administration peut déplacer un joueur ou tous les joueurs :

/send Steve survival
/send all lobby

BungeeCord et Velocity acceptent aussi current pour déplacer tous les joueurs présents sur le même backend que la personne qui exécute la commande :

/send current lobby

current doit être lancé par un joueur connecté, car la console du proxy n’a pas de serveur actuel. Les permissions bungeecord.command.send et velocity.command.send doivent rester réservées à l’équipe d’administration. La commande /server suffit pour la navigation normale des joueurs.

4. Synchroniser l’inventaire entre plusieurs serveurs

BungeeCord et Velocity ne transportent pas l’inventaire du joueur. Une solution de synchronisation doit être installée sur chaque serveur qui partage la même progression.

Toutes les offres de serveur Minecraft BoxToPlay incluent déjà une base de données MySQL, sans supplément. Activez-la depuis la page Base de données MySQL du panel en choisissant un mot de passe administrateur, puis utilisez ses identifiants dans la configuration ci-dessous. Vous n’avez pas besoin d’ajouter une base de données externe.

Paper, Spigot, Purpur et Folia

MC-Data-Bridge convient aux réseaux Minecraft 1.21.x, 26.1.x et 26.2. Installez le même fichier JAR dans le dossier plugins de chaque backend concerné ainsi que sur le proxy BungeeCord ou Velocity. Configurez partout la même base MySQL ou MariaDB, puis attribuez un server-id unique à chaque serveur.

Les versions 2.1.3 à 2.1.8 de MC-Data-Bridge nécessitent Java 25, y compris avec Minecraft 1.21.x. Les versions 2.1.2 et antérieures fonctionnent sous Java 21, mais elles ne disposent pas des derniers correctifs liés aux transferts et à la protection contre la duplication d’objets. Utilisez donc de préférence la dernière version stable compatible.

Si votre réseau doit rester sous Java 21, MySql Player Bridge constitue une autre possibilité. Installez d’abord NBT-API, puis MySql Player Bridge dans plugins sur chaque backend à synchroniser. Configurez la même base MySQL ou MariaDB dans plugins/MySqlPlayerBridge/mysql.yml, puis activez uniquement les données voulues dans plugins/MySqlPlayerBridge/config.yml. Aucun plugin supplémentaire n’est nécessaire sur le proxy.

Forge et NeoForge

Pour Forge ou NeoForge, PlayerSync fournit des versions adaptées à plusieurs couples Minecraft et loader. Choisissez impérativement le fichier correspondant exactement à votre version de Minecraft et à Forge ou NeoForge. Placez-le dans mods sur chaque backend, configurez la même base MySQL ou MariaDB dans config/playersync.toml, puis attribuez un Server_id différent à chaque serveur.

Utilisez le même modpack et les mêmes versions de mods dans un groupe synchronisé. Testez les objets provenant des mods avant l’ouverture du réseau.

Faut-il synchroniser le lobby ?

Pour retrouver le même inventaire sur le lobby et le serveur PvP, les deux backends doivent utiliser la même solution et le même stockage. Dans la plupart des réseaux, il reste préférable de séparer le lobby : sa boussole, ses menus et ses objets cosmétiques ne doivent pas remplacer l’inventaire PvP ou Survival.

Vous pouvez par exemple laisser lobby indépendant, synchroniser pvp-1 et pvp-2 ensemble, puis conserver survival dans un autre groupe.

Avant la première activation, sauvegardez les données des joueurs et testez plusieurs changements de serveur avec un compte secondaire. Gardez la même version de Minecraft dans chaque groupe et ne mélangez pas plusieurs solutions de synchronisation dans un même groupe. Les grades, les sanctions, l’économie et le chat se partagent séparément avec des plugins conçus pour fonctionner en réseau.

5. Créer un portail en jeu avec Advanced Portals

La liaison dans le panel apprend au proxy qu’une destination existe. La commande /server survival demande ensuite au proxy d’y transférer un joueur. Un plugin installé sur le lobby peut déclencher le même transfert lorsqu’un joueur entre dans une zone.

La liaison ne crée aucun portail physique. Un portail du Nether classique change de dimension sur le même backend : il n’envoie pas le joueur vers un autre serveur.

Nous utilisons Advanced Portals, un plugin Bukkit compatible notamment avec Paper, Spigot, Purpur et Folia.

La méthode ci-dessous utilise le tag bungee:. Pour ce cas, installez le plugin sur le backend qui sert de lobby, là où le portail sera construit. Ne l’installez pas sur le serveur de destination et les joueurs n’ont rien à ajouter sur leur ordinateur. Advanced Portals propose aussi un composant proxy pour son tag proxy: et des fonctions avancées, mais ce n’est pas nécessaire pour le portail simple de ce tutoriel.

Si le lobby fonctionne uniquement sous Vanilla, Forge, NeoForge ou Fabric, ce plugin Bukkit ne peut pas y être installé directement. La section consacrée aux serveurs moddés présente les options à vérifier.

Installer Advanced Portals sur le lobby

Dans le panel BoxToPlay :

Ouvrez le serveur Minecraft qui sert de lobby.
Allez dans Plugins & Mods, puis Installation de plugins.
Ouvrez l’onglet Modrinth.
Recherchez Advanced Portals.
Installez une version compatible avec votre version de Minecraft.
Redémarrez complètement le lobby.

Préparer Velocity

Si votre proxy est Velocity et que vous utilisez le tag bungee:, vérifiez avant de créer le portail que bungee-plugin-message-channel est activé dans velocity.toml. Cette option autorise les plugins des backends à utiliser le canal de messages compatible BungeeCord. Elle est indépendante du mode de transfert des informations joueur.

Elle ne permet pas à Velocity de charger directement un plugin BungeeCord sur le proxy.

Construire le portail vers `survival`

Connectez-vous par le proxy et confirmez d’abord que /server survival fonctionne. Ensuite, depuis le lobby avec un compte administrateur :

Construisez le cadre et laissez son intérieur vide.
Tapez /portal wand pour recevoir l’outil de sélection.
Faites un clic gauche sur un coin intérieur, puis un clic droit sur le coin opposé.
Créez le portail :

/portal create name:portail_survival bungee:survival triggerblock:NETHER_PORTAL

Tapez /portal portalblock, puis placez les blocs reçus dans la zone sélectionnée.
Traversez le portail et vérifiez que vous arrivez sur la bonne destination.

Dans cette commande :

name:portail_survival est le nom unique du portail.
bungee:survival demande au proxy de rejoindre la destination survival.
survival doit correspondre exactement au nom défini dans Liaisons serveurs.
triggerblock:NETHER_PORTAL déclenche le transfert dans les blocs violets du portail.

Le nom historique bungee: fonctionne avec BungeeCord et Velocity lorsque le canal compatible est activé. Utilisez /portal show pour afficher les zones et /portal remove portail_survival pour supprimer cet exemple.

La capture suivante, issue de la documentation officielle des commandes Advanced Portals, montre le résultat de /portal show. Les particules vertes délimitent les portails proches et la zone actuellement sélectionnée. Elles permettent donc de repérer une sélection trop grande, trop petite ou décalée.

Advanced Portals sait aussi créer des destinations locales avec les commandes /desti. La commande /desti show les représente par une flèche de particules, comme dans la capture officielle ci-dessous.

Cette seconde commande n’est pas nécessaire pour le portail de ce tutoriel : bungee:survival demande directement au proxy de transférer le joueur vers le serveur survival. Les commandes /desti servent seulement aux portails qui téléportent vers une position locale.

Vous pouvez remplacer NETHER_PORTAL par WATER. Pour un PNJ ou un menu, installez un plugin adapté et configurez-le avec le même identifiant de destination.

Ce portail pointe vers une destination fixe. Il ne choisit pas automatiquement entre survival-1 et survival-2.

6. Mettre en place une répartition de charge

Relier lobby, survival et minigames répartit les joueurs par activité. Ce n’est pas une répartition de charge, car chaque destination remplit un rôle différent.

Le besoin apparaît lorsque plusieurs instances proposent le même mode Survie :

survival-1 : 78 joueurs
survival-2 : 24 joueurs
survival-3 : maintenance

Ici, survival-1 est un identifiant de destination, tandis que Survie est le mode de jeu proposé.

Un plugin de répartition installé sur le proxy peut choisir une instance selon les fonctions qu’il fournit. Avant de le retenir, vérifiez qu’il sait gérer :

La disponibilité réelle des instances.
Le nombre de joueurs et la capacité maximale.
Les instances placées en maintenance.
Le comportement attendu lorsqu’une instance tombe.
La destination à utiliser lors d’une reconnexion.

Principe général de mise en place

Reliez chaque instance avec un nom distinct, par exemple survival-1, survival-2 et survival-3.
Testez chaque nom avec /server.
Installez un plugin compatible avec votre proxy et votre version.
Suivez sa documentation pour déclarer les instances et exposer sa commande ou sa destination de répartition.
Configurez le portail, le PNJ ou le menu pour appeler cette fonction.
Testez une instance disponible, une instance pleine et une instance arrêtée.

Les plugins de répartition n’emploient pas tous la même notion de groupe, d’alias ou de contrôle d’état. Ne recopiez donc pas une configuration prévue pour un autre plugin.

Advanced Portals ne mesure aucune charge. Le tag bungee:survival-1 envoie toujours le joueur vers cette destination précise. De même, priorities dans BungeeCord et try dans Velocity définissent un ordre d’arrivée ou de repli : ils n’alternent pas automatiquement les joueurs et ne sélectionnent pas l’instance la moins chargée.

Enfin, plusieurs instances ne deviennent pas interchangeables par simple copie du serveur. Les inventaires, permissions, monnaies, sanctions et données de plugins doivent être conçus pour fonctionner en réseau, souvent avec des plugins adaptés et une base de données partagée.

7. Les sous-domaines ne remplacent pas les portails

Une configuration avancée peut associer des adresses comme survival.exemple.fr ou minigames.exemple.fr à différentes destinations initiales. BungeeCord appelle ce mécanisme forced_hosts, et Velocity propose une section forced-hosts équivalente.

Ce routage agit au moment où le joueur rejoint le réseau. Il ne déplace pas un joueur déjà connecté et ne choisit pas automatiquement l’instance la moins chargée. Les sous-domaines sont donc une porte d’entrée supplémentaire, pas un remplacement des commandes, portails ou menus.

Avec BungeeCord, le réglage Forcer le serveur par défaut doit rester désactivé pour que les forced hosts déterminent correctement la destination d’arrivée.

8. Sécuriser les serveurs backend

Les joueurs doivent entrer par le proxy. Les ports des backends ne doivent pas offrir un second point d’entrée public.

Le transfert moderne de Velocity vérifie un secret partagé, mais il ne remplace pas un pare-feu. Avec le transfert historique compatible BungeeCord, une restriction réseau, une liste d’adresses autorisées ou BungeeGuard est particulièrement importante. Dans tous les cas, seuls le proxy et les services techniques nécessaires doivent pouvoir joindre les backends.

Ne communiquez aux joueurs que l’adresse du proxy.

9. Cas particuliers : Forge, NeoForge et Fabric

Le parcours le plus simple consiste à utiliser un lobby Paper ou Purpur avec Advanced Portals, même si les destinations utilisent Forge ou NeoForge. Les joueurs devront toujours posséder la version et le modpack exigés par la destination.

Avec Velocity 3.3.0 ou une version suivante :

Le support natif du protocole Forge concerne les versions strictement supérieures à 1.20.2.
Pour Forge 1.13 à 1.20.1, installez Ambassador sur le proxy Velocity.
Ne supposez pas que Forge 1.20.2 est couvert par l’une de ces deux plages : vérifiez la documentation et la version exacte de votre serveur.

Pour le transfert moderne de Velocity vers un backend Forge ou NeoForge, installez une version compatible de Proxy Compatible Forge sur ce backend et utilisez le même secret que le proxy. Pour Fabric, la documentation de Velocity recommande FabricProxy-Lite.

Ambassador gère la compatibilité du protocole Forge avec Velocity. Proxy Compatible Forge et FabricProxy-Lite gèrent le transfert des informations joueur. Aucun de ces composants ne crée un portail.

Si le lobby lui-même utilise Forge ou NeoForge, recherchez un mod maintenu qui fournit explicitement deux fonctions pour votre version exacte : la détection d’une zone en jeu et l’envoi du joueur vers un nom de serveur BungeeCord ou Velocity. À la date de rédaction, nous ne retenons pas de solution universelle prête à l’emploi pour ce cas. Le projet forge-plugin-message annonce plusieurs versions sur sa fiche, mais ne propose actuellement aucun fichier public téléchargeable sur Modrinth. Il ne peut donc pas servir de recommandation générale dans ce tutoriel.

Liste de vérification

Avant d’ouvrir le réseau :

La connexion à l’adresse du proxy aboutit au lobby attendu.
Chaque nom visible dans Liaisons serveurs fonctionne avec /server nom.
Les serveurs BoxToPlay compatibles ont été préparés automatiquement et les backends externes ont été configurés manuellement.
Les backends ont été redémarrés avant le proxy.
Si des inventaires sont synchronisés, chaque groupe utilise une seule solution, le même stockage et des identifiants de serveur distincts, après une sauvegarde et un test avec un compte secondaire.
Le portail utilise exactement le même identifiant de destination que le panel.
Sous Velocity, bungee-plugin-message-channel est activé avant d’utiliser le tag bungee:.
Une destination de repli fonctionne lorsqu’un backend est arrêté.
Une connexion directe à l’adresse et au port d’un backend est refusée.
Les permissions de /send, de rechargement et d’administration restent réservées à l’équipe d’administration.

Quelle méthode choisir ?

Pour vérifier une liaison : utilisez /server.
Pour partager l’inventaire entre plusieurs backends : utilisez une solution compatible avec leur logiciel, un stockage commun et des identifiants de serveur distincts.
Pour guider les joueurs depuis un lobby : utilisez un portail, un PNJ ou un menu.
Pour choisir une destination dès la connexion : configurez le serveur d’arrivée ou des sous-domaines avancés.
Pour répartir plusieurs instances équivalentes : ajoutez un plugin de répartition compatible sur le proxy.

Une fois ces vérifications terminées, le proxy devient le point d’entrée unique du réseau. Vous pouvez alors améliorer le lobby, synchroniser uniquement les données qui doivent être partagées et ajouter une répartition de charge lorsque plusieurs instances remplissent réellement le même rôle.

Ressources utiles

BungeeCord

Velocity

Plugins et mods

Prêt à créer le point d’entrée de votre réseau ? Découvrez les serveurs BungeeCord et Velocity de BoxToPlay, reliez vos serveurs Minecraft depuis le panel, puis validez chaque transfert avec ce tutoriel.

Mathieu_293985 · July 30, 2026, 5:25pm

Comment peut t’on relier l’inventaire de chaque joueurs sur le bungee ? (en gros avoir le meme inventaire sur le lobby et sur mon serveur pvp par exemple)

BoxToPlay-helper · July 30, 2026, 6:42pm

Bonjour Mathieu,

Vous avez bien fait de poser la question en effet la synchronisation des inventaires entre plusieurs serveurs n’était effectivement pas expliquée assez clairement dans le tutoriel. Nous venons donc d’ajouter un paragraphe dédié à ce sujet, avec les solutions adaptées selon le type de serveur utilisé.

Merci pour votre retour !