Avant de commencer
Copiez le message complet, l’heure, l’édition du client et sa version. Relevez l’adresse et le port réellement attribués dans le panel. Vérifiez si un autre joueur peut rejoindre le même serveur. Conservez une sauvegarde du monde et des fichiers de configuration avant toute modification. Ne partagez pas de mots de passe RCON, d’identifiants de base de données ni de jetons dans les journaux transmis.
Utiliser la bonne édition et le bon protocole
Un client Java et un client Bedrock ne se connectent pas directement au même logiciel serveur. Un projet crossplay demande une passerelle explicitement configurée et compatible. La présence d’une adresse IP ne démontre pas qu’une telle passerelle est installée. Vérifiez l’édition choisie et les fonctions réellement proposées pour votre service.
Le jeu Java utilise généralement un endpoint TCP, tandis que le serveur Bedrock utilise UDP. Les ports habituels ne remplacent jamais l’allocation du panel. Sur un node partagé, copier un port par défaut depuis un tutoriel peut entrer en conflit avec une autre instance. Un test TCP ne permet pas de valider une connexion Bedrock UDP.
Confirmer que le serveur a fini de démarrer
Ouvrez les journaux et recherchez un démarrage terminé, une erreur de liaison réseau, un arrêt pour manque de mémoire ou une extension qui échoue. Le statut de la machine ou du conteneur ne suffit pas à prouver que le jeu accepte les connexions. Un monde en cours de génération peut demander plus de temps qu’un redémarrage ordinaire.
Après un ajout de plugin ou de mod, contrôlez ses dépendances et sa compatibilité avec le moteur. Paper, Fabric, Forge et NeoForge ne chargent pas automatiquement les mêmes extensions. Travaillez sur une copie de test et retirez uniquement l’ajout identifié ; ne supprimez pas le monde pour diagnostiquer une erreur de logiciel.
Séparer l’adresse du serveur et le DNS
Essayez l’adresse IP et le port attribués avant de tester le nom de domaine. Si cette connexion fonctionne mais pas le domaine, vérifiez les enregistrements DNS, leur destination et les éventuelles informations de port. Pour Java, un enregistrement SRV peut annoncer un port, mais tous les clients ou outils ne l’interprètent pas de la même manière.
Comparez ensuite depuis une autre connexion autorisée. Si un seul réseau échoue, relevez l’opérateur et les horaires au lieu de modifier immédiatement la configuration générale. Un ping ICMP bloqué n’établit pas que le jeu est inaccessible ; une réponse ping ne prouve pas non plus que son port est ouvert.
Contrôler versions, accès et configuration
Un refus de version, de liste blanche ou d’authentification doit être traité à partir du message correspondant. Conservez l’authentification et les protections d’accès ; les désactiver globalement ne répare pas un problème de route. Vérifiez les versions du client, du moteur et du modpack, puis les règles d’accès configurées.
Sur Bedrock, la découverte LAN peut aussi ouvrir des ports habituels en plus d’un port personnalisé. Sur un node partagé, utilisez la configuration adaptée par le panel et faites contrôler les conflits d’allocation. Pour un proxy Java ou une passerelle crossplay, vérifiez chaque étape du chemin, pas uniquement l’adresse publique.
Distinguer retard de simulation et problème réseau
Si les joueurs entrent puis sont déconnectés, comparez les journaux avec la charge CPU, la mémoire, l’espace libre et l’activité du monde au même moment. Une génération intensive, une base de données lente ou un plugin bloquant peut perturber le jeu alors que le réseau fonctionne. Une augmentation de RAM ne corrige pas toutes les causes.
Pour un moteur qui le permet, réalisez un profilage pendant la difficulté avec son outil compatible. Sur les versions récentes de Paper, spark est intégré. Un rapport pris sur un serveur vide est moins utile qu’un rapport correspondant au ralentissement. Limitez la collecte et protégez les liens de diagnostic qui pourraient contenir des informations sensibles.
Escalader avec des éléments précis
Transmettez au support l’édition, les versions, l’adresse utilisée, l’heure avec son fuseau, le message exact et les tests déjà effectués. Précisez si l’IP directe fonctionne, si le domaine échoue et quels réseaux sont touchés. Joignez les extraits utiles des journaux après avoir masqué les secrets.
Une suspicion DDoS doit être rapprochée de mesures de trafic ou d’événements de mitigation. Le timeout seul ne suffit pas. Évitez les redémarrages en boucle et les scans agressifs : ils ajoutent de la charge et compliquent le diagnostic. Testez la correction avec une connexion normale, puis vérifiez que les joueurs habituels peuvent revenir.
Selon votre situation
| Situation | Prochaine vérification |
|---|---|
| L’IP fonctionne, pas le domaine | Vérifier la destination DNS et, pour Java lorsqu’il est utilisé, l’enregistrement SRV. Garder le port attribué comme référence. |
| Un seul réseau échoue | Comparer les horaires et les routes depuis une autre connexion. Fournir l’opérateur et le message exact au support. |
| Le serveur ne termine pas son démarrage | Lire les erreurs de moteur, de mémoire, de ports et d’extensions. Vérifier le dernier changement sur une copie avant de toucher au monde. |
Sources officielles
Ces documents décrivent les protocoles et logiciels concernés. Les conditions de votre service et sa configuration restent à vérifier.