Could not connect to a default or fallback server signifie que BungeeCord fonctionne, mais n'a pas pu transférer le joueur vers une destination de démarrage autorisée. La cause se situe généralement dans priorities, l'état du backend, l'adresse/le port, le pare-feu, le forwarding ou la compatibilité de protocole.

N'ouvre pas le port du backend à l'ensemble d'Internet pour le dépannage. Teste depuis la perspective du proxy et n'autorise toujours que son chemin vérifié. Le schéma cible sécurisé est présenté dans le pilier de configuration BungeeCord.

Arbre de diagnostic

Chaque nom de priorities existe-t-il sous servers ?
├─ non -> corriger le nom et la casse
└─ oui
   Au moins une cible est-elle complètement démarrée ?
   ├─ non -> résoudre l'erreur de démarrage du backend
   └─ oui
      Le proxy atteint-il exactement cette adresse et ce port ?
      ├─ non -> vérifier l'adresse, l'allocation, la route et le pare-feu
      └─ oui
         Le forwarding et les versions correspondent-ils ?
         ├─ non -> corriger la configuration de manière cohérente
         └─ oui -> vérifier la première stack trace concrète du proxy/backend

1. Comparer priorities avec servers

servers:
  lobby:
    address: <LOBBY-ADRESSE>:<PORT>
    restricted: false

listeners:
  - priorities:
      - lobby

lobby, Lobby et lobby ne sont pas la même clé. Chaque entrée dans priorities doit exister sous servers. Avec plusieurs cibles, BungeeCord les essaie dans l'ordre ; une première cible défaillante ne doit pas masquer également le deuxième fallback.

2. Démarrer réellement le backend

Un statut de conteneur « running » ne suffit pas. Lis le journal du backend jusqu'au message de fin de démarrage. Les blocages de démarrage typiques sont :

  • l'EULA non acceptée ;
  • une image Java incorrecte ;
  • un JAR de plugin corrompu ou incompatible ;
  • une erreur de monde/mod ;
  • un port déjà occupé ;
  • le serveur écoute sur une autre allocation.

Teste ensuite la valeur concrète de servers.<name>.address. Un ping vers l'IP de l'hôte ne prouve pas que le port TCP de Minecraft est accessible.

3. Vérifier l'adresse du point de vue du proxy

127.0.0.1 pointe, dans le conteneur du proxy, vers le conteneur du proxy lui-même. Ne l'utilise que si le backend et le proxy partagent de manière prouvée le même espace de noms réseau. Pour des instances séparées, tu as besoin de l'adresse du backend accessible depuis le proxy.

Modèles d'erreurs :

Message Signification typique
Connection refused rien n'écoute sur le port cible ou une règle rejette activement
Timeout la route ou le pare-feu rejette, la cible est bloquée ou l'adresse est incorrecte
Unknown host erreur DNS/de nom d'hôte
Address already in use listener en double/conflit de port

Sur game-serverhosting, le garde-fou actif du backend protège les chemins BungeeCord vérifiés. Si le proxy est arrêté ou si sa source concrète est manquante, le chemin du backend reste intentionnellement en mode « drop only ». Démarre le bon proxy et attends la réévaluation, au lieu de supprimer la règle de protection.

4. Vérifier le pare-feu avec précision

Le pare-feu doit remplir deux conditions simultanément :

  1. le proxy associé atteint le port TCP du backend ;
  2. une source indépendante ne l'atteint pas.

Si les deux échouent, vérifie d'abord l'association concrète du proxy et la résolution de la source. Si les deux fonctionnent, le backend n'est pas protégé. Une ouverture pour un sous-réseau d'hébergement mutualisé ou Docker complet n'est pas une réparation propre.

5. Comparer les valeurs de forwarding

Pour un BungeeCord classique avec Paper/Spigot :

  • Proxy online_mode: true ;
  • Proxy ip_forward: true ;
  • Backend server.properties avec online-mode=false ;
  • Backend spigot.yml avec settings.bungeecord: true ;
  • Paper proxies.bungee-cord.online-mode: true, si le proxy authentifie en ligne.

Un message comme If you wish to use IP forwarding... indique souvent une configuration proxy/backend incohérente. Ne modifie ces valeurs qu'après une sauvegarde et en suivant le guide de sécurité du forwarding, en raison d'éventuels changements d'UUID.

6. Isoler la version et les plugins

Compare les versions de protocole du client, du proxy et du backend. Un port TCP ouvert peut malgré tout refuser une connexion. Démarre si possible avec une lobby sans plugins proxy récemment ajoutés. Installe les plugins BungeeCord uniquement sur le proxy et les plugins Bukkit/Paper uniquement sur les backends ; le guide des plugins explique les différents niveaux.

Ne retire pas des plugins à l'aveugle d'une production. Sauvegarde plugins/ et la configuration, modifie une variable dans une copie et reviens en arrière en cas d'échec.

7. Vérifier le domaine seulement après le chemin direct

Teste d'abord l'IP publique du proxy avec le port. Si cela fonctionne mais pas le domaine, examine séparément les enregistrements A/AAAA et SRV. Le nom cible SRV doit pointer vers le proxy. Utilise le guide domaine/SRV.

Vérification finale

L'erreur n'est résolue que lorsque le TCP, le ping Minecraft et la véritable connexion à la lobby via le proxy sont au vert. Répète ensuite le test négatif indépendant vers le backend. Pour une reconfiguration ou un changement de version, utilise d'abord le chemin de sauvegarde et de retour en arrière. Le crossplay ne vient qu'après ; le TCP et l'UDP Geyser sont vérifiés séparément.

FAQ

Que signifie exactement ce message ?

Que BungeeCord lui-même fonctionne et a accepté le joueur, mais n'a pas pu le transférer vers une destination de démarrage autorisée. Le proxy n'est donc pas la source de l'erreur — la cause se situe dans priorities, dans l'état du backend, dans l'adresse et le port, dans le pare-feu, dans le forwarding ou dans la version du protocole.

Puis-je indiquer 127.0.0.1 comme adresse de backend ?

Seulement si le proxy et le backend partagent de manière prouvée le même espace de noms réseau. Dans le conteneur du proxy, 127.0.0.1 pointe vers le conteneur du proxy lui-même, pas vers le backend. Pour des instances séparées, tu as besoin de l'adresse sous laquelle le proxy atteint réellement le backend.

Connection refused ou timeout — quelle est la différence ?

Connection refused signifie que rien n'écoute sur le port cible ou qu'une règle rejette activement la connexion : généralement un backend non démarré ou un port incorrect. Un timeout indique une route ou un pare-feu qui rejette les paquets, une cible bloquée ou une adresse incorrecte.

Dois-je brièvement ouvrir le port du backend pour le dépannage ?

Non. Un port de backend ouvert en mode offline permet à des inconnus de se faire passer pour n'importe quel joueur. Teste plutôt depuis la perspective du proxy. Si le chemin du backend reste bloqué alors que le proxy fonctionne, vérifie l'association concrète du proxy — et ne supprime pas la règle de protection.

Le port TCP est accessible, mais la connexion échoue quand même — pourquoi ?

Un port ouvert prouve seulement que quelque chose écoute. Si la connexion échoue malgré tout, compare la version de protocole du client, du proxy et du backend, et démarre à titre de test une lobby sans plugins proxy récemment ajoutés. Vérifie également si des plugins BungeeCord se trouvent par erreur sur un backend.

Sources primaires