Résoudre les messages de démarrage, de connexion et de liaison sur le serveur Minecraft

Cet article traite des messages liés au démarrage du serveur, à la connexion des joueurs et aux liaisons réseau, par exemple vers des ports ou vers un proxy comme Velocity ou BungeeCord. Chaque section traite exactement un message. Certains empêchent le serveur de démarrer, d'autres ne concernent que certains joueurs ou une fonction supplémentaire.

Tu trouveras le texte complet dans la Console et sous Fichiers dans logs/latest.log. Les messages indiquant qu'un proxy n'atteint pas son serveur cible figurent dans le log du proxy. Lis aussi à chaque fois les lignes juste avant et juste après.

Avant de modifier server.properties, des configurations de plugins ou des fichiers de monde, crée une sauvegarde sous Sauvegardes. Ainsi, tu peux revenir à l'ancien état à tout moment.

Le port est déjà utilisé

Voici à quoi ressemble le message :

**** FAILED TO BIND TO PORT!
java.net.BindException: Address already in use
[<Plugin>] Failed to start HTTP server: Address already in use

Ce qui se cache derrière : Un port est comme un numéro de porte par lequel les connexions arrivent jusqu'au serveur. Pour chaque protocole, un port ne peut être occupé que par un seul programme à la fois. Si « FAILED TO BIND TO PORT » apparaît dans le message, le serveur Minecraft n'a pas pu ouvrir son port de jeu et ne démarre pas. La même BindException peut aussi venir d'un plugin qui ouvre son propre port, par exemple pour le chat vocal ou une carte web. Dans ce cas, le serveur tourne, mais cette fonction du plugin ne marche pas.

Voici comment le résoudre :

1. Lis la ligne située avant la BindException. Si un nom de plugin figure entre crochets, seul ce plugin est concerné.
2. S'il s'agit du port de jeu, arrête le serveur via la Console, attends qu'il soit complètement éteint, puis redémarre-le. Le panel gère automatiquement le port de jeu, ne modifie pas server-port à la main.
3. S'il s'agit d'un plugin, ouvre sa configuration dans plugins/<Plugin>/ sous Fichiers. Indique-y un port qui est attribué à ton serveur dans le panel et qu'aucun autre service n'utilise, ou désactive la fonction.
4. Redémarre et vérifie dans la console que le message ne réapparaît plus.

Bon à savoir : Pour le chat vocal, la marche à suivre se trouve ici : Configurer Simple Voice Chat.

Un plugin de connexion ne démarre pas, car le serveur est en mode en ligne

Voici à quoi ressemble le message :

[LibreLogin] !!!The server is running in online mode! LibreLogin won't start unless you set it to false!!!
[FastLogin] Server has to be in offline mode

Ce qui se cache derrière : En mode en ligne (online-mode=true dans server.properties), le serveur vérifie chaque compte Java directement auprès de Mojang. Les plugins d'authentification comme LibreLogin, AuthMe ou FastLogin sont conçus pour les serveurs qui n'effectuent pas eux-mêmes cette vérification, et gèrent alors la connexion avec des mots de passe. Si le serveur tourne quand même en mode en ligne, le plugin refuse de démarrer ou ne peut pas contrôler la connexion. Les joueurs sans compte acheté restent refusés.

Voici comment le résoudre :

1. Décide qui doit pouvoir rejoindre le serveur : uniquement les joueurs avec un compte Minecraft acheté, ou volontairement aussi d'autres.
2. Si seuls les comptes officiels doivent pouvoir rejoindre le serveur, supprime le plugin d'authentification sous Plugins et redémarre le serveur. Le mode en ligne protège alors tous les pseudos.
3. Si des joueurs sans compte acheté doivent volontairement pouvoir rejoindre le serveur, utilise l'onglet Autoriser les joueurs cracked / non premium dans les paramètres Minecraft de ton serveur. Il règle online-mode=false et configure le plugin de connexion en conséquence, de sorte que les pseudos des joueurs sont protégés par un mot de passe.
4. Ne mets pas online-mode sur false à la main uniquement pour faire disparaître le message. Sans plugin de connexion ni proxy sécurisé, n'importe qui peut alors se connecter avec n'importe quel pseudo, y compris celui d'un admin.

Pour en savoir plus : Activer le mode cracked / hors ligne ou Serveur cracked : connexion et limites

L'EULA de Minecraft n'est pas acceptée

Voici à quoi ressemble le message :

You need to agree to the EULA in order to run the server. Go to eula.txt for more info.

Ce qui se cache derrière : L'EULA est le contrat de licence de Mojang et Microsoft pour les serveurs Minecraft. Un serveur Java ne démarre que si la ligne eula=true figure dans le fichier eula.txt. Si elle est absente ou si eula=false y figure, le serveur s'arrête directement après le démarrage. Chez nous, cette valeur est définie automatiquement. Le message n'apparaît donc généralement que si eula.txt a été supprimé ou écrasé, par exemple lors de l'envoi de tes propres fichiers de serveur.

Voici comment le résoudre :

1. Sous Fichiers, ouvre le fichier eula.txt dans le dossier principal du serveur, là où se trouve aussi server.properties.
2. Remplace eula=false par eula=true et enregistre. Si le fichier n'existe pas, crée-le avec exactement cette seule ligne.
3. Démarre le serveur et suis le démarrage dans la Console.

Bon à savoir : Avec eula=true, tu acceptes les conditions de l'EULA de Minecraft.

Pour en savoir plus : EULA de Minecraft et premier démarrage du serveur

Un joueur sans compte Minecraft valide a été refusé

Voici à quoi ressemble le message :

Username '<Joueur>' tried to join with an invalid session

Ce qui se cache derrière : Un joueur a voulu rejoindre le serveur avec un client Java qui n'a pas pu présenter de compte Minecraft (Microsoft) valide et acheté. En mode en ligne (online-mode=true), le serveur refuse ces connexions. Cette ligne est précisément générée par les clients cracked ou TLauncher. Parfois, avec un vrai compte, il s'agit simplement d'une session expirée. Ton serveur est en bonne santé et continue de fonctionner normalement.

Voici comment le résoudre :

1. Demande au joueur s'il a acheté Minecraft : Java Edition avec un compte Microsoft et s'il est connecté avec celui-ci dans le launcher officiel.
2. S'il a un compte valide, il doit redémarrer complètement le client Minecraft. Cela renouvelle la session expirée.
3. S'il joue avec Bedrock sur mobile, console ou Windows, il peut rejoindre le serveur à la place via l'adresse crossplay de ton serveur, si le crossplay est activé.
4. Ne désactive pas le mode en ligne à la main pour cette raison.

Bon à savoir : Si tu veux n'autoriser que les vrais comptes, tu n'as rien à faire. Le message indique alors simplement que la protection fonctionne.

Pour en savoir plus : Activer le mode cracked / hors ligne ou Serveur cracked : connexion et limites

La connexion est perturbée, car Mojang ne répond pas

Voici à quoi ressemble le message :

Couldn't verify username because servers are unavailable

Ce qui se cache derrière : En mode en ligne, le serveur demande à chaque connexion aux serveurs d'authentification de Mojang et Microsoft si le compte est authentique. S'ils ne répondent pas, le serveur ne peut pas vérifier le compte et ne laisse pas le joueur entrer. Cela ne vient pas de ton serveur : en cas de panne chez eux, tous les serveurs avec vérification premium active sont touchés en même temps. Les nouveaux joueurs ne peuvent pas rejoindre le serveur tant que la panne dure, ceux qui sont déjà en ligne continuent en général à jouer.

Voici comment le résoudre :

1. Attends la fin de la panne. Elle se résout généralement d'elle-même en quelques minutes.
2. Tu peux voir l'état actuel sur la page de statut de Mojang.
3. Demande à tes joueurs de réessayer dans quelques minutes.
4. Ne désactive pas online-mode pour cette raison. Cela ouvrirait ton serveur de façon permanente aux faux comptes, au lieu de résoudre un court problème.

Bon à savoir : Si les joueurs peuvent rejoindre d'autres serveurs sans problème et que le message persiste longtemps chez toi, ouvre un ticket et indique l'heure du message.

Le système Query ne démarre pas

Voici à quoi ressemble le message :

Unable to initialise query system on <IP>:<Port>
java.net.BindException: Address already in use

Ce qui se cache derrière : Query est une interface supplémentaire via UDP, par laquelle les listes de serveurs et les outils interrogent le nombre de joueurs et l'état en ligne. Si elle ne démarre pas, le serveur ne transmet plus ces informations vers l'extérieur. Le jeu lui-même n'est pas affecté, les joueurs peuvent rejoindre normalement. La BindException en dessous indique la cause : le port Query est déjà utilisé ou entre en conflit avec un autre service, souvent avec un autre service UDP comme Geyser ou un plugin de chat vocal sur le même port.

Voici comment le résoudre :

1. Regarde dans le panel quels ports sont attribués à ton serveur et lesquels sont déjà utilisés par Geyser ou un plugin de chat vocal.
2. Sous Fichiers, ouvre le fichier server.properties.
3. Règle enable-query=true et indique pour query.port un port attribué qu'aucun autre service n'utilise.
4. Enregistre et redémarre le serveur. Vérifie dans la Console que le message ne réapparaît plus.

L'icône du serveur ne fait pas 64 × 64 pixels

Voici à quoi ressemble le message :

Couldn't load server icon
java.lang.IllegalArgumentException: Invalid world icon size [<Largeur>, <Hauteur>], but expected [64, 64]

Ce qui se passe : L'image server-icon.png située dans le dossier principal s'affiche dans la liste des serveurs des joueurs, à côté du nom du serveur. Minecraft n'accepte pour cela qu'un PNG de exactement 64 × 64 pixels. Si l'image a une autre taille, le serveur ne la charge pas et les joueurs ne voient pas d'icône personnalisée. Le serveur continue de fonctionner normalement.

Comment résoudre le problème :

1. Ouvre ton image dans un logiciel de retouche d'image et redimensionne-la à exactement 64 × 64 pixels.
2. Enregistre-la au format PNG sous le nom server-icon.png.
3. Envoie-la dans le dossier principal du serveur via Fichiers et remplace l'ancien fichier.
4. Redémarre le serveur. La nouvelle icône apparaît dès que les joueurs actualisent leur liste de serveurs.

Bon à savoir : Si tu ne veux pas d'icône personnalisée, supprime server-icon.png et redémarre le serveur. Le message disparaît alors également.

Un client a envoyé un paquet de connexion invalide

Voici à quoi ressemble le message :

Failed to decode packet 'serverbound/minecraft:hello'

Ce qui se passe : « hello » est le premier paquet qu'un client envoie lors de la connexion, avec notamment le nom du joueur. Si le serveur n'a pas pu le lire, le client ne correspond pas à la version du serveur ou au protocole attendu, par exemple à cause d'une autre version de Minecraft ou d'un chargeur de mods manquant. Le serveur ne coupe que cette connexion et continue de fonctionner.

Comment résoudre le problème :

1. Vérifie si un joueur a essayé de se connecter à cette heure-là sans y parvenir.
2. Si oui, compare sa version de Minecraft avec la version de ton serveur sous Version. Pour un modpack, il lui faut le même pack avec le même chargeur de mods.
3. Si personne n'a essayé de se connecter, il s'agissait le plus souvent d'un scanner de ports automatique qui sonde les serveurs sur Internet. Dans ce cas, tu n'as rien à faire.

Bon à savoir : Si tu veux que des joueurs avec d'autres versions de client puissent se connecter, ViaVersion peut aider sur les serveurs Paper.

Le proxy n'atteint pas le serveur cible à temps

Voici à quoi ressemble le message :

io.netty.channel.ConnectTimeoutException: connection timed out after <Millisecondes> ms: /<Address>:<Port>

Ce qui se passe : Un proxy comme Velocity ou BungeeCord est le serveur d'entrée par lequel les joueurs se connectent avant d'être répartis sur les serveurs cibles enregistrés. Ici, le proxy a voulu joindre un serveur cible et n'a reçu aucune réponse dans le délai imparti. Le plus souvent, l'adresse ou le port ne sont pas corrects, ou le serveur cible est hors ligne ou en veille. Les joueurs n'arrivent alors pas sur ce serveur cible, tandis que le proxy lui-même continue de fonctionner.

Comment résoudre le problème :

1. Relève à la fin du message l'adresse et le port que le proxy a essayé de joindre.
2. Compare-les dans velocity.toml (section [servers]) ou dans le config.yml de BungeeCord (section servers) avec les informations que le panel affiche pour le serveur cible. Elles doivent correspondre exactement.
3. Démarre le serveur cible et attends qu'il soit entièrement lancé. Réveille d'abord les serveurs en veille.
4. Redémarre le proxy pour qu'il prenne en compte les entrées modifiées, puis teste la connexion.

Pour aller plus loin : BungeeCord: Could not connect to a default or fallback server

La prise en charge de Velocity est activée sans secret

Voici à quoi ressemble le message :

Velocity is enabled, but no secret key was specified. A secret key is required. Disabling velocity...

Ce qui se passe : Velocity est un proxy qui transmet les joueurs aux serveurs Paper. Pour que Paper puisse faire confiance à ces transferts, le proxy et le serveur partagent un mot secret commun, le secret. Dans la configuration de Paper, la prise en charge de Velocity est activée, mais le secret est absent. Paper désactive donc cette prise en charge, et le transfert des joueurs via le proxy ne fonctionne pas.

Comment résoudre le problème :

1. Récupère le secret depuis le proxy Velocity. Dans les versions récentes de Velocity, il se trouve dans le fichier forwarding.secret auquel renvoie velocity.toml, dans les versions plus anciennes directement dans velocity.toml.
2. Sur le serveur Paper, ouvre via Fichiers le fichier config/paper-global.yml et cherche la section proxies → velocity.
3. Mets enabled: true et renseigne exactement le même secret dans secret.
4. Si tu n'utilises aucun proxy Velocity, mets plutôt enabled: false à cet endroit.
5. Redémarre le serveur Paper et vérifie que le message a disparu.

Bon à savoir : Dans velocity.toml, player-info-forwarding-mode doit pour cela être réglé sur modern. Pour les versions de Paper antérieures à 1.19, le paramètre ne se trouve pas dans config/paper-global.yml, mais dans paper.yml sous settings → velocity-support. Traite le secret comme un mot de passe.

Le serveur cible refuse la connexion du proxy

Voici à quoi ressemble le message :

io.netty.channel.AbstractChannel$AnnotatedConnectException: finishConnect(..) failed with error(-111): Connection refused: /<Address>:<Port>

Ce qui se passe : Le proxy a atteint l'adresse enregistrée du serveur cible, mais aucun service n'y accepte de connexions sur ce port. Contrairement à un dépassement de délai, l'adresse répond donc, mais rien n'y écoute. Causes typiques : le serveur cible est arrêté, est encore en cours de démarrage, ou le port indiqué dans le proxy n'appartient pas à ce serveur. Les joueurs n'arrivent pas sur ce serveur cible tant que le problème persiste.

Comment résoudre le problème :

1. Relève l'adresse et le port à la fin du message.
2. Démarre le serveur cible et attends dans sa Console qu'il soit entièrement démarré.
3. Compare l'adresse et le port dans velocity.toml ou dans le config.yml de BungeeCord avec les informations que le panel affiche pour le serveur cible.
4. N'indique pas 127.0.0.1 si le proxy et le serveur cible sont des serveurs distincts. Cette adresse pointe vers le proxy lui-même.

Bon à savoir : Pendant le redémarrage d'un serveur cible, le message est normal et disparaît de lui-même.

Pour aller plus loin : BungeeCord: Could not connect to a default or fallback server

Ton message n'est pas dans la liste ?

Lis le message en entier dans la Console ou dans logs/latest.log, y compris les lignes juste avant. Souvent, on y voit ce qui a échoué en premier. Si une stacktrace suit, c'est-à-dire une liste de lignes commençant par « at », les noms de dossiers et de fichiers qu'elle contient, comme plugins/<Plugin> ou <Plugin>.jar, indiquent le plugin ou le mod concerné. En cas de problème de proxy, lis les logs du proxy et du serveur cible à la même heure. Crée une sauvegarde avant toute modification. Si tu n'avances pas, ouvre un ticket et indique l'heure du message.