Le fichier config.yml définit où BungeeCord écoute, quels backends il connaît et vers où les nouveaux joueurs sont dirigés. Génère toujours ce fichier avec ta version installée. D'anciens exemples de blog peuvent contenir des champs ou des valeurs par défaut qui ne correspondent plus au build actuel.

Une configuration syntaxiquement valide n'est pas encore un réseau sécurisé. Dès que des backends utilisent online-mode=false, leur port TCP doit être protégé contre les connexions directes. Le déroulement complet se trouve dans le pilier de configuration BungeeCord.

Structure de base sécurisée

online_mode: true
ip_forward: true
player_limit: -1
server_connect_timeout: 5000
remote_ping_timeout: 5000

servers:
  lobby:
    address: <ADRESSE-LOBBY>:<PORT>
    motd: '&aLobby'
    restricted: false
  survival:
    address: <ADRESSE-SURVIVAL>:<PORT>
    motd: '&aSurvival'
    restricted: false

listeners:
  - host: 0.0.0.0:<PORT-PROXY>
    motd: '&aMon réseau'
    priorities:
      - lobby
      - survival
    force_default_server: true
    forced_hosts:
      survival.example.net: survival
    max_players: 100
    tab_list: GLOBAL_PING
    query_enabled: false
    proxy_protocol: false

Les espaces réservés doivent être remplacés par les adresses de ton panel. Une adresse de backend publique dans l'exemple n'est pas une autorisation de laisser le port ouvert publiquement.

Champs globaux

Champ Signification Classification sécurisée
online_mode Authentification au niveau du proxy pour un réseau premium normal, true
ip_forward IP, UUID et profil transmis au backend nécessaire, mais ne constitue pas un contrôle d'accès
player_limit limite globale stricte de joueurs 0 ou moins signifie illimité
server_connect_timeout délai pour la connexion au backend trop court génère de fausses alertes, trop long entraîne de longs temps d'attente
remote_ping_timeout délai d'expiration pour les pings backend un ping n'équivaut pas à une vraie connexion
remote_ping_cache cache pour le statut du backend peut afficher brièvement un ancien statut
connection_throttle fenêtre de temps pour les nouvelles connexions ne constitue pas une protection complète contre les bots/DDoS
forge_support prise en charge supplémentaire du handshake Forge vérifier séparément la compatibilité du modloader

servers : nommer les backends

Chaque clé sous servers est un nom interne. address doit être accessible du point de vue du processus proxy. restricted: true exige la permission bungeecord.server.<name>, mais n'empêche pas un accès réseau direct au port du backend.

Évite d'utiliser le même nom de domaine public du proxy comme adresse de backend : cela peut créer une boucle. Utilise une adresse interne, privée ou spécifiquement autorisée pour le proxy.

listeners : points d'entrée publics

host doit correspondre à l'allocation proxy attribuée. priorities est la liste ordonnée pour le démarrage et le repli. Une simple faute de frappe comme Lobby au lieu de lobby suffit pour qu'aucune cible par défaut ne soit trouvée.

force_default_server: true démarre les nouvelles connexions via la logique des priorités/forced-hosts. Avec false, BungeeCord peut tenter de restaurer une cible précédemment utilisée.

max_players n'est pas player_limit

listeners.*.max_players contrôle le nombre de joueurs affiché dans la liste des serveurs. player_limit est la limite globale stricte. Définis les deux consciemment ; un affichage flatteur ne remplace pas une véritable mesure de capacité.

forced_hosts et DNS

forced_hosts associe un nom d'hôte à un nom de serveur interne. Le DNS pointe malgré tout vers BungeeCord. Pour un domaine avec un port différent, utilise le guide domaine/SRV.

Ne pas confondre ces champs

  • proxy_protocol est destiné à un émetteur HAProxy/PROXY Protocol en amont, pas au forwarding BungeeCord classique.
  • query_enabled ouvre au besoin un service UDP séparé ; ne l'active pas par précaution.
  • ping_passthrough reprend le MOTD et le statut d'une cible, mais rend une panne de backend plus visible.
  • restricted est une permission BungeeCord, pas un pare-feu.
  • /greload ne recharge pas de façon fiable chaque modification de plugin ou de permission ; prévois un redémarrage.

Configurer le backend en conséquence

Configure server.properties avec online-mode=false et settings.bungeecord: true dans spigot.yml. Sous Paper, proxies.bungee-cord.online-mode doit correspondre au online_mode du proxy. Avant toute modification, lis le guide de forwarding sécurisé et crée une sauvegarde testée via le chemin de copie/restauration décrit dans le guide de changement de version.

Validation

  1. N'utilise que des espaces, pas de tabulations.
  2. Vérifie l'indentation et les chaînes contenant des caractères spéciaux.
  3. Compare tous les noms dans priorities et forced_hosts avec servers.
  4. Redémarre complètement le backend et le proxy.
  5. Teste séparément le TCP, le ping Minecraft et une vraie connexion à la lobby.
  6. Vérifie depuis une source indépendante que le port du backend est bien bloqué.

Si BungeeCord n'atteint aucune lobby, le guide de dépannage du fallback peut t'aider. N'installe des plugins proxy et backend au bon niveau qu'après ce test de base.

FAQ

Pourquoi ne dois-je pas copier le config.yml depuis un tutoriel ?

Parce que les champs et les valeurs par défaut changent d'un build à l'autre. Laisse BungeeCord générer lui-même le fichier avec ta version installée, puis reprends uniquement les valeurs que tu souhaites vraiment adapter. Un champ issu d'un ancien exemple peut être absent de ton build ou avoir une autre signification.

Quelle est la différence entre max_players et player_limit ?

listeners.*.max_players n'est qu'un affichage : le nombre que les clients voient dans la liste des serveurs. player_limit est la limite globale stricte à partir de laquelle le proxy refuse les connexions (0 ou moins signifie illimité). Définis les deux consciemment — un chiffre élevé affiché ne remplace pas une véritable mesure de capacité.

restricted: true suffit-il pour protéger un backend ?

Non. restricted est une permission BungeeCord qui exige bungeecord.server.<name> pour changer via le proxy. Cela n'empêche personne d'accéder directement au port du backend. La protection à ce niveau relève du pare-feu ou du réseau privé, pas de la configuration du proxy.

Dois-je redémarrer après une modification, ou /greload suffit-il ?

Prévois un redémarrage. /greload relit la configuration, mais ne transmet pas de façon fiable chaque modification de plugin ou de permission à l'état en cours d'exécution. Pour les modifications des listeners, des serveurs ou du forwarding, le redémarrage complet est la seule méthode fiable.

Pourquoi le domaine du proxy ne doit-il pas servir d'adresse de backend ?

Parce que le proxy se ciblerait alors lui-même, créant une boucle. Sous servers.<name>.address doit figurer l'adresse par laquelle le processus proxy accède au backend — une adresse interne ou privée, pas le nom public vers lequel pointe le DNS de ton réseau.

Sources principales