Un serveur FiveM ou RedM qui disparaît soudainement de la cfx server list génère une perte de joueurs immédiate. Le heartbeat envoyé vers la masterlist Cfx.re repose sur plusieurs paramètres techniques, et une seule directive mal configurée dans le server.cfg suffit à rendre le serveur invisible. Cet article examine les causes les moins documentées de ce problème, au-delà des vérifications classiques de clé de licence ou d’ouverture de port.
Directives server.cfg et impact sur la visibilité dans la cfx server list
La plupart des guides se concentrent sur la clé de licence et le port 30120. Mais certaines combinaisons de directives dans le fichier server.cfg produisent des effets de bord sur le listage que peu de documentations détaillent.
Lire également : Voici comment les KPI peuvent impacter votre culture d'entreprise
| Directive | Valeur attendue pour listage public | Effet si mal configurée |
|---|---|---|
| sv_endpointPrivacy | false | Le serveur apparaît comme « privé » ou ne s’affiche plus |
| sv_master1 | « » (chaîne vide, activée) | Aucun heartbeat envoyé vers la masterlist |
| sv_forceIndirectListing | false (par défaut) | Listage indirect : le serveur peut sembler absent |
| sv_disableInactiveListing | false (par défaut) | Serveur retiré automatiquement s’il est jugé inactif |
| sv_useDirectListing | true | Sans cette directive, certains hébergeurs ne listent pas le serveur |
Le piège le plus courant concerne la combinaison de sv_forceIndirectListing et sv_disableInactiveListing. Selon un guide technique de HG-Hosting publié en 2026, activer ces deux directives ensemble (souvent pour protéger le serveur contre les attaques L7) peut rendre le serveur invisible sur servers.fivem.net. Le serveur est alors listé via une façade, ou pas listé du tout s’il est considéré inactif.
Avant toute autre vérification, ouvrez votre server.cfg et contrôlez chaque directive une par une. Une protection anti-DDoS activée par un script ou un tutoriel copié-collé peut avoir modifié ces valeurs sans que vous le réalisiez.
A lire en complément : Pourquoi faire appel à un expert en données web à Lyon
Réécriture de port UDP par le firewall : une cause fréquente et sous-documentée
La documentation officielle Cfx.re mentionne explicitement un problème que les guides d’hébergeurs ignorent presque systématiquement : les passerelles NAT et firewalls qui réécrivent les ports UDP source empêchent le serveur de s’enregistrer dans la masterlist.
Le mécanisme est le suivant. Le serveur FiveM envoie un heartbeat UDP vers live-internal.fivem.net. Si un équipement réseau (routeur, firewall géré, solution de sécurité du FAI) modifie le port source de ce paquet, la masterlist ne peut pas associer la réponse au serveur d’origine. Le serveur ne reçoit jamais la confirmation, et il n’apparaît pas.
Identifier le problème de réécriture UDP
- Vérifiez la configuration NAT de votre routeur ou de votre panel d’hébergement. Certains firewalls « managés » activent par défaut la randomisation des ports UDP source pour des raisons de sécurité
- Testez avec un outil de capture réseau (tcpdump, Wireshark) que le port source du heartbeat correspond bien au port configuré dans server.cfg (par défaut 30120)
- Sur un VPS, désactivez temporairement toute règle iptables ou nftables qui effectue du SNAT/MASQUERADE avec randomisation de port, puis redémarrez le serveur pour observer le résultat
Ce diagnostic est particulièrement pertinent si le serveur fonctionnait correctement et a disparu de la liste après un changement de fournisseur, une mise à jour firmware du routeur, ou l’activation d’une protection DDoS côté hébergeur.
Clé de licence Cfx.re : les cas de révocation silencieuse
Une clé sv_licenseKey invalide empêche le listage, ce qui est connu. En revanche, une clé révoquée ne génère pas toujours un message d’erreur explicite dans la console du serveur. Le serveur démarre, les joueurs en connexion directe (via IP) peuvent parfois encore se connecter, mais le heartbeat échoue silencieusement.
Situations qui provoquent la révocation
Chaque clé est liée à un seul serveur. Si vous avez utilisé la même clé sur deux instances (par exemple un serveur de test et un serveur de production), Cfx.re peut désactiver la clé. Le portail portal.cfx.re affiche le statut de chaque clé dans la section Server Keys.
Un changement d’adresse IP du serveur peut aussi poser problème si la clé a été générée en mode « IP-locked » plutôt qu’en mode « Any-IP ». Après une migration d’hébergeur ou un changement d’IP publique, vérifiez la correspondance entre l’IP déclarée sur le portail Cfx.re et l’IP réelle du serveur.
Délai de propagation et cache de la masterlist Cfx.re
Après correction d’un problème de configuration, le serveur ne réapparaît pas instantanément. La masterlist Cfx.re met généralement entre cinq et quinze minutes à indexer un nouveau heartbeat. Pendant cette fenêtre, le serveur semble absent alors qu’il est en cours d’enregistrement.
Deux points méritent attention ici. Premièrement, un redémarrage propre du serveur (arrêt complet puis relance, pas un simple restart de ressource) est nécessaire pour que le heartbeat soit renvoyé. Deuxièmement, le cache côté client FiveM peut afficher une liste périmée. Rafraîchir la server list côté client ne force pas un nouveau pull depuis la masterlist : il faut parfois redémarrer le client FiveM lui-même.
Diagnostic serveur FiveM : vérifications à mener dans l’ordre
Pour éviter de tourner en rond, appliquez les vérifications dans un ordre logique qui élimine les causes les plus fréquentes en premier.
- Ouvrez le portail portal.cfx.re et confirmez que la clé de licence est active, associée à la bonne IP, et non utilisée par un autre serveur
- Dans le server.cfg, vérifiez que sv_endpointPrivacy est à false, que sv_master1 est présent et non commenté, et que sv_forceIndirectListing n’est pas à true
- Testez l’ouverture du port 30120 en TCP et UDP depuis l’extérieur du réseau (pas depuis le serveur lui-même, ce qui ne prouve rien)
- Contrôlez les logs de la console pour toute erreur liée au heartbeat ou à la connexion vers live-internal.fivem.net
- Vérifiez qu’aucun équipement réseau intermédiaire ne réécrit les ports UDP source du serveur
Si toutes ces vérifications sont conformes et que le serveur reste invisible après trente minutes, le problème peut venir d’une interruption temporaire de la masterlist Cfx.re elle-même. Dans ce cas, la page de statut de Cfx.re et les forums communautaires confirmeront si d’autres opérateurs rencontrent le même souci au même moment.
La disparition d’un serveur de la cfx server list est rarement aléatoire. Dans la grande majorité des cas, une directive modifiée, une clé révoquée ou un firewall trop zélé explique le problème. Le diagnostic méthodique reste le seul raccourci fiable.
