Un serveur FiveM peut tourner sans accroc pendant des semaines et rester totalement absent de la Cfx Server List. Le problème vient rarement d’un bug logiciel : c’est presque toujours un paramètre manquant ou mal renseigné dans le fichier server.cfg, une clé Keymaster liée à la mauvaise IP, ou un port bloqué que personne n’a pensé à vérifier.
Cet article détaille les paramètres techniques qui conditionnent réellement l’apparition d’un serveur dans la liste publique, en insistant sur les points que les guides classiques traitent trop vite.
A découvrir également : Logiciel de caisse mapap : la solution pour votre boutique
Clé Keymaster et liaison IP : le verrou que beaucoup découvrent trop tard
La clé de licence générée sur le portail Cfx.re (Keymaster) est le premier maillon de la chaîne de listing. Sans elle, aucune communication avec la masterlist ne s’établit. La directive correspondante dans server.cfg est simple :
sv_licenseKey "cfxk_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
Lire également : Comment choisir entre puissance et portabilité pour votre PC portable
Ce que la plupart des tutoriels mentionnent moins, c’est le fonctionnement en mode « locked to IP ». La clé Keymaster est associée à l’adresse IP renseignée lors de sa création. Un changement d’hébergeur ou d’IP publique casse cette liaison et le serveur disparaît de la Cfx Server List sans message d’erreur explicite dans la console.
La procédure après migration consiste soit à régénérer une nouvelle clé pour la nouvelle IP, soit à mettre à jour l’IP associée directement sur le portail Cfx.re. Tant que cette étape n’est pas faite, l’authentification échoue silencieusement et le listing reste bloqué.
Directives server.cfg qui conditionnent le listing FiveM
Plusieurs lignes du fichier server.cfg agissent comme des interrupteurs pour la visibilité publique. L’absence d’une seule suffit à rendre le serveur invisible.
sv_master1 : la directive obligatoire
La ligne sv_master1 "" (avec deux guillemets vides) active l’inscription auprès de la masterlist Cfx. Sans sv_master1, le serveur ne sera jamais listé, quels que soient les autres paramètres. C’est la directive la plus souvent oubliée par les administrateurs débutants.
Listing direct et confidentialité endpoint
Deux autres paramètres complètent le dispositif :
sv_usedirectlisting trueactive le listing direct, recommandé pour accélérer l’apparition du serveur dans la liste publique.sv_endpointprivacy trueoufalsecontrôle l’exposition de certaines informations réseau. Régler cette valeur surtrueprotège l’IP du serveur dans la liste, ce qui est préférable pour les serveurs exposés à des attaques DDoS.- Les directives
endpoint_add_tcp "0.0.0.0:30120"etendpoint_add_udp "0.0.0.0:30120"définissent les points d’écoute. Un serveur derrière un NAT qui ne redirige pas correctement ces endpoints vers l’IP publique restera invisible.
Identité du serveur dans la liste
sv_hostname définit le nom affiché. sv_projectName et sv_projectDesc alimentent les métadonnées visibles dans le navigateur de serveurs. Ces champs n’ont pas d’impact technique sur le listing lui-même, mais un serveur sans nom lisible ni description a très peu de chances d’attirer des joueurs.
Port 30120 et pare-feu : la couche réseau que le server.cfg ne gère pas
Le fichier de configuration ne peut rien si le réseau bloque les connexions entrantes. Le port 30120 doit être ouvert en TCP et en UDP sur le pare-feu de la machine hôte. Sur un serveur Linux avec UFW, les commandes sont directes :
sudo ufw allow 30120/tcpsudo ufw allow 30120/udp
Sur un VPS géré via un panel comme Pterodactyl, la redirection de port se configure dans l’interface d’administration. Un décalage entre le port interne du conteneur et le port exposé publiquement est une source fréquente de problèmes. Le serveur démarre normalement, les logs ne signalent rien d’anormal, mais la masterlist ne parvient pas à joindre l’instance.
Pour vérifier que le port répond, un scan externe (via un outil en ligne ou nmap depuis une autre machine) reste la méthode la plus fiable. Tester depuis la machine elle-même ne prouve rien : le trafic local ne traverse pas le pare-feu de la même façon que le trafic entrant.
Stabilité serveur et OneSync : rester listé sous charge
Apparaître dans la Cfx Server List est une chose. Y rester de façon stable en est une autre. Un serveur qui crash régulièrement ou qui dépasse ses capacités mémoire finit par accumuler des timeouts vis-à-vis de la masterlist. Techniquement, il reste « listé », mais son indisponibilité répétée le rend quasi invisible pour les joueurs qui filtrent par serveurs en ligne.
Les paramètres de performance dans server.cfg jouent un rôle direct :
set onesync onactive la synchronisation réseau optimisée, indispensable au-delà de quelques dizaines de joueurs simultanés.sv_maxclientsdéfinit le nombre de slots. Fixer une valeur trop élevée par rapport aux ressources RAM et CPU disponibles provoque des crashs en charge, ce qui dégrade la présence effective dans la liste.- La connexion à la base de données (MySQL ou MariaDB) doit être dimensionnée pour supporter les requêtes simultanées. Un pool de connexions sous-dimensionné génère des blocages en cascade sur les scripts ESX ou QBCore, jusqu’au freeze complet du serveur.
Un serveur stable avec moins de slots attire plus qu’un serveur ambitieux qui tombe toutes les heures. Les retours terrain divergent sur le seuil exact à partir duquel OneSync Infinity devient nécessaire, mais au-delà de la soixantaine de joueurs, la plupart des administrateurs constatent une dégradation sans cette option.
Vérifications après déploiement sur la Cfx Server List
Une fois le server.cfg complété et le serveur redémarré, la console doit afficher un message confirmant l’enregistrement auprès de la masterlist. L’absence de ce message indique un problème sur l’un des points abordés plus haut.
Chercher le nom exact du serveur dans le navigateur FiveM (onglet « Servers ») reste le test final. Si le serveur n’apparaît pas après quelques minutes, il faut reprendre la chaîne dans l’ordre : clé Keymaster valide et liée à la bonne IP, sv_master1 présent, ports ouverts, endpoints correctement déclarés.
Les vérifications automatisées de Cfx.re se sont renforcées ces dernières années. Un serveur qui ne respecte pas les conditions de licence ou qui utilise une clé partagée entre plusieurs instances risque un retrait silencieux de la liste, sans notification préalable. Chaque instance doit disposer de sa propre clé unique, générée pour son IP spécifique.
