Créer un réseau de serveurs Minecraft avec Velocity

Un seul serveur Minecraft, c'est bien, mais un jour vous voulez plus : un monde survie et un monde créatif, ou un serveur de mini-jeux dédié aux événements. Tout entasser sur un seul serveur devient vite lent et confus. La solution, c'est un réseau : plusieurs serveurs derrière une seule adresse, avec un proxy qui dirige les joueurs au bon endroit.

Velocity est aujourd'hui le choix logique pour ce proxy. Vous découvrirez ci-dessous pourquoi, comment un tel réseau est construit et quels pièges éviter — avec le forwarding secret comme point le plus important de tous.

Que fait un proxy, au juste ?

Un proxy est un petit serveur qui ne fait tourner aucun monde lui-même. Les joueurs se connectent à l'adresse du proxy, qui les redirige vers l'un de vos vrais serveurs : les backends. Pour les joueurs, tout ressemble à un seul grand serveur. Ils tapent /server survival ou franchissent un portail dans le lobby, et se retrouvent dans un autre monde sans se reconnecter.

Concrètement, cela apporte ceci :

• Une seule adresse pour tout. Les joueurs n'ont qu'une IP ou un nom de domaine à retenir, quel que soit le nombre de serveurs derrière.
• Changer de serveur sans se reconnecter. Du lobby à la survie puis aux mini-jeux, sans déconnexion ni liste de serveurs.
• Maintenance sans coupure totale. Si vous redémarrez le serveur survie, le reste du réseau continue de tourner et les joueurs sont accueillis dans le lobby.
• Répartir la charge. Un mini-jeu gourmand ou un événement très fréquenté ne tire pas tout votre réseau vers le bas ; chaque backend dispose de ses propres ressources.

Il y a aussi un revers honnête : vous gérez soudain plusieurs serveurs, et les fonctions à l'échelle du réseau comme le chat, les grades et l'économie demandent des plugins qui partagent leurs données entre ces serveurs, souvent via une base de données. Un réseau devient donc surtout rentable dès qu'un seul serveur devient vraiment trop petit — pas quand vous jouez à quatre entre amis.

Velocity ou BungeeCord ?

BungeeCord est le vétéran des proxys et a longtemps été la référence. Velocity est son pendant moderne, développé par l'équipe derrière Paper. Les différences en résumé :

• Performances. Velocity est conçu pour gérer de nombreux joueurs simultanés avec peu de mémoire et monte en charge nettement mieux.
• Sécurité. Le modern forwarding de Velocity signe les données de joueurs transmises avec une clé secrète. BungeeCord transmet ces données sans signature et a besoin d'un plugin supplémentaire comme BungeeGuard pour combler la même faille.
• Plugins. Ici, BungeeCord marque des points grâce à son ancienneté : il existe tout simplement plus d'anciens plugins Bungee. En pratique, presque tous les grands plugins réseau ont désormais aussi une version Velocity.
• Maintenance. Velocity est activement développé, tandis que BungeeCord n'est plus entretenu que pour la compatibilité.

Si vous démarrez un nouveau réseau aujourd'hui, choisissez Velocity. BungeeCord ne reste vraiment pertinent que si vous dépendez d'un plugin Bungee précis sans alternative Velocity — vérifiez-le donc avant de choisir, pas après.

Comment votre réseau est structuré

Un réseau minimal se compose de trois éléments : un proxy Velocity, un lobby et au moins un backend de jeu. La configuration du proxy se trouve dans velocity.toml et son cœur est étonnamment court. Sous [servers], vous donnez à chaque backend un nom et une adresse, par exemple lobby = "127.0.0.1:25566" et survival = "127.0.0.1:25567". Avec try = ["lobby"], vous définissez ensuite que les joueurs entrants démarrent dans le lobby.

Les backends eux-mêmes sont des serveurs Minecraft ordinaires, de préférence sous Paper. Bon à savoir :

• Chaque backend tourne séparément, avec son propre port et ses propres plugins, mondes et réglages.
• Sur chaque backend, online-mode passe à false dans server.properties : le proxy vérifie déjà les comptes à l'entrée, les backends lui font confiance.
• Idéalement, seul le proxy est accessible publiquement et les backends n'acceptent que le trafic venant du proxy.

Si votre proxy et vos backends tournent chez le même hébergeur, la liaison entre eux est courte et le transfert est en pratique quasiment imperceptible. La deuxième règle ci-dessus — désactiver la vérification des comptes — semble pourtant aller à l'encontre de tous les conseils de sécurité que vous avez lus, et cela nous amène à l'élément le plus important de toute l'installation.

Le forwarding secret : petit fichier, grand enjeu

Comme vos backends sont en online-mode=false, ils ne vérifient plus les comptes eux-mêmes. Sans mesure supplémentaire, quiconque connaît l'adresse d'un backend peut s'y connecter directement, sous n'importe quel pseudo — y compris le vôtre en tant que propriétaire. C'est LA faille classique des réseaux mal configurés, et elle est activement exploitée.

Velocity résout ce problème avec le modern forwarding. Au premier démarrage, Velocity génère un fichier forwarding.secret contenant une clé secrète. Le proxy signe avec elle les données de joueurs qu'il transmet, et un backend n'accepte que les connexions dotées d'une signature valide. Voici comment le configurer :

1. Dans velocity.toml, réglez le mode de forwarding sur modern.
2. Sur chaque backend Paper, activez le forwarding Velocity dans la configuration Paper et collez-y exactement le même secret que sur le proxy.
3. Redémarrez le proxy et les backends, connectez-vous et vérifiez que votre skin habituel s'affiche — c'est le signe que vos vraies infos de compte passent correctement et que le forwarding fonctionne.

Traitez le secret comme un mot de passe : ne le partagez avec personne et ne le collez pas dans des captures d'écran ou des tickets de support. Si vous optez malgré tout pour BungeeCord, utilisez au minimum BungeeGuard ou une solution équivalente pour combler la même faille.

Un lobby qui porte votre réseau

Le lobby est à la fois la vitrine et le filet de sécurité de votre réseau : tout le monde y arrive, et si un backend redémarre ou tombe, les joueurs y sont renvoyés. Gardez-le donc léger et sagement stable :

• Utilisez une petite map construite à l'avance ; un monde vide avec une seule île n'est pas populaire par hasard.
• Mettez les joueurs en mode aventure, pour que rien ne soit cassé ni détruit.
• Limitez les plugins à la navigation et à la décoration : un menu boussole ou des PNJ permettant de rejoindre un serveur.
• Désactivez ce dont vous n'avez pas besoin, comme l'apparition des mobs et la météo. Cela économise des ressources et évite le bruit dans la console.
• Vérifiez que la liste try dans velocity.toml pointe vers le lobby, pour qu'en cas de crash d'un backend les joueurs y atterrissent automatiquement au lieu de voir un message d'erreur.

Un lobby n'a besoin que de très peu de ressources ; le gros du travail se fait sur les backends. C'est là qu'il faut voir large, surtout pour un monde survie où beaucoup de chunks restent chargés.

Combien coûte un réseau chez MC-Node ?

L'avantage d'un réseau composé d'offres séparées : vous payez pour chaque élément exactement ce dont il a besoin, et vous les faites évoluer indépendamment les uns des autres. Un réseau de départ peut par exemple ressembler à ceci :

Un réseau de départ complet tourne ainsi pour 12,60 € par mois. Si votre serveur survie devient trop à l'étroit, vous n'agrandissez que cette offre-là. Toutes les offres sont résiliables chaque mois et tournent sur du stockage NVMe avec protection DDoS incluse ; vous trouverez la gamme complète avec les spécifications dans la boutique Minecraft de MC-Node.

Commencez petit : proxy, lobby et un seul backend. Une fois le forwarding secret bien en place et les joueurs passant d'un serveur à l'autre sans accroc, chaque backend supplémentaire n'est plus qu'une question de commander un serveur, copier la configuration et ajouter une ligne dans velocity.toml.