Serveur FiveM absent de la liste des serveurs : causes et solutions

Mis à jour le

Vérifié le 7 octobre 2026 sur FXServer build 35245 (recommandé), 37150 (dernière) et txAdmin v8.1.1. Sources

VerdictNe prouve pas un DDoS à lui seul

Les causes que la documentation liste relèvent surtout de la configuration ou d’un serveur injoignable, pas d’une attaque.

FiveShield ne règle pas ce problème

FiveShield ne règle pas ce problème, et un proxy peut même le provoquer quand les paramètres de listing manquent.

Votre propre serveur alimente la liste. FXServer envoie toutes les 3 minutes un heartbeat, une requête HTTPS sortante, au service de listing de Cfx.re, et la page de la documentation consacrée aux proxys indique que le backend de listing interroge aussi votre serveur. Un serveur disparaît de la liste, ou s’y affiche en privé, quand le heartbeat ne part pas, quand la config le déclare privé ou LAN, quand des réglages obligatoires manquent, ou quand le backend n’arrive pas à le joindre.

Vérifiez dans l’ordre : depuis quand le serveur a démarré (la documentation admet jusqu’à 8 minutes), si quelqu’un sur un autre réseau peut ouvrir http://IP:Port/info.json et utiliser Direct Connect, ce qu’affiche heartbeat, puis cinq lignes de server.cfg. Le diagnostic ci-dessous prend deux minutes.

N’envisagez une attaque que si le serveur était listé avec des joueurs connectés, si votre hébergeur ou votre graphique de trafic entrant montre un événement à l’instant de sa disparition et si Direct Connect échoue pour tout le monde. La page officielle sur les problèmes de serveur ne cite aucune attaque parmi les causes.

Messages que vous pouvez voir

  • Server list query returned an error: <reason>

    Dans la console du serveur, en rouge, après un heartbeat. Non affiché pour la première réponse reçue après le démarrage

  • Error: Force indirect listing is enabled, but no host override is set. This is not supported!

    Dans la console du serveur, en rouge, à chaque heartbeat, quand sv_forceIndirectListing vaut true et que sv_listingHostOverride est vide

  • no license key was specified

    Cité par la page d’installation parmi les problèmes courants

Ce que cela signifie vraiment

Le listing fonctionne dans deux sens. Dans GameServer.cpp, FXServer envoie en POST un heartbeat à https://servers-frontend.fivem.net/api/serverlist/ingress, valeur par défaut de sv_master1, au démarrage puis toutes les 3 minutes. La connexion ou la déconnexion d’un joueur avance le suivant à 15 secondes au plus, et la commande heartbeat en force un. Le corps contient le port, un jeton de listing, une IP de remplacement facultative et un indicateur private.

L’autre sens, c’est le service de listing qui interroge votre serveur : la page sur les proxys l’appelle le server list backend et dit qu’il peut ne pas deviner l’IP à interroger dans certaines configurations. Quand sa réponse à un heartbeat contient un champ lastError, le serveur en affiche la première ligne en rouge : Server list query returned an error: <reason>. Ni le code ni la documentation n’en disent l’origine ou les raisons possibles. Notre lecture : l’échec d’une requête vers votre serveur ; prenez le texte après les deux-points comme un indice, pas comme un diagnostic.

À vérifier en premier (deux minutes)

Six vérifications, de la moins coûteuse à la plus coûteuse, chacune menant à une cause.

  1. Depuis combien de temps le serveur a-t-il démarré ?

    La documentation indique que cela peut prendre jusqu’à 8 minutes.

  2. Quelqu’un hors de votre réseau peut-il joindre le serveur ?

    Demandez à un joueur sur un autre réseau de lancer la commande ci-dessous dans la console F8, avec votre IP publique et votre port. Depuis un téléphone en données mobiles, ouvrez http://IP:Port/info.json : un objet JSON doit s’afficher. Un test depuis votre propre réseau ne montre pas ce que voient les joueurs extérieurs.

    connect IP:Port

  3. Lancez heartbeat deux fois dans la console du serveur

    Relancez-le après quelques secondes : la première réponse reçue après le démarrage n’est jamais signalée, et un heartbeat qui n’a pas pu partir n’affiche aucune ligne rouge.

    heartbeat

    • Error: Force indirect listing is enabled, but no host override is set. This is not supported! en rouge: Lire la cause 5 : paramètres de listing derrière un proxy

    • Server list query returned an error: <reason> en rouge: Garder le texte après les deux-points pour votre demande d’aide sur le forum, puis passer à l’étape 4 : l’étape 2 a déjà testé le port.

    • Aucune ligne rouge n’apparaît: Passer à l’étape 4.

  4. Relisez cinq réglages de server.cfg

    Cherchez sv_master1, sv_lan, sets sv_projectName, sets sv_projectDesc et sv_licenseKey dans server.cfg et dans chaque fichier qu’il charge avec exec.

  5. Un proxy devant le serveur, ou du HTTPS sortant bloqué ?

    Tout reverse proxy ou tunnel compte, tout comme une ligne sv_forceIndirectListing ou sv_listingHostOverride. Testez le HTTPS sortant de la machine du serveur vers servers-frontend.fivem.net (commandes dans la cause 7).

  6. Tout passe et le serveur reste absent de la liste

    Comparez l’heure de sa disparition avec ce que votre hébergeur a enregistré.

Causes, classées

Les trois premières suivent la page officielle sur les problèmes de serveur : port, sv_master1, réglages du projet. Les suivantes vont à peu près de la vérification la moins coûteuse à la plus difficile. L’ordre repose sur la documentation et le coût, pas sur des retours de propriétaires : aucune cause ci-dessous n’a le badge « Retours de propriétaires ». La cause 9 est le cas de l’attaque.

Classement établi d’après ce que les propriétaires signalent le plus souvent et d’après le coût de chaque vérification. C’est un ordre éditorial, pas une statistique : personne ne publie de jeu de données sur les causes de panne FiveM. Documenté : la documentation officielle ou le code source de FXServer et de txAdmin l’indique. Retours de propriétaires : des fils de forum et des tickets le rapportent. Notre déduction : notre raisonnement à partir de faits documentés, présenté pour que vous puissiez le vérifier.

  1. Le port du jeu (30120 par défaut) est bloqué ou non redirigé

    Documenté

    La page officielle place cette cause en premier : le plus souvent une mauvaise redirection de port ou un pare-feu mal configuré. N’importe quelle couche peut le bloquer : pare-feu du système, routeur, panel de l’hébergeur ou pare-feu de jeu. Le guide Game firewall d’OVH recommande Default Deny, qui bloque tout trafic sans règle créée par vous.

    Comment le confirmer

    Depuis un autre réseau, ouvrez http://IP:Port/info.json et essayez Direct Connect (étape 2) avec l’IP publique ; 127.0.0.1 prouve seulement que le serveur répond en local. endpoint_add_tcp et endpoint_add_udp doivent partager un même ip:port, sinon txAdmin ne démarre pas le serveur. Si le port fonctionnait jusqu’à un moment précis et que rien n’a changé de votre côté, comparez cet instant avec l’enregistrement de votre hébergeur (cause 9).

    Que faire

    Ouvrez le port en TCP et en UDP à chaque couche, puis refaites le test depuis l’extérieur.

  2. sv_master1 "" est actif, ou sv_lan vaut true

    Documenté

    La documentation dit que sv_master1 déclare un serveur « private » (bouton de connexion désactivé) et ne peut pas servir à retirer un serveur de la liste. Dans GameServer.cpp, l’indicateur private du heartbeat reste vrai tant que sv_master1, sv_master2 ou sv_master3 ne contient pas l’adresse d’ingress par défaut : une valeur vide non commentée rend donc le serveur privé. sv_lan true est distinct : le serveur n’apparaît pas dans la liste publique.

    Comment le confirmer

    Cherchez dans server.cfg et dans chaque fichier qu’il charge avec exec. Formes sûres : #sv_master1 "" ou aucune ligne, et pas de sv_lan true. Avec votre code cfx.re/join/, CFX Finder affiche « Listé comme privé » quand cfx.re marque le listing comme privé.

    Que faire

    Commentez ou supprimez la ligne sv_master1 (la documentation précise qu’il n’est pas nécessaire de la remettre), retirez sv_lan ou mettez-le à false, puis redémarrez.

  3. sets sv_projectName ou sets sv_projectDesc manque

    Documenté

    Si l’une des deux variables manque, le serveur affiche une erreur au démarrage et peut ne pas apparaître dans la liste. Le nom doit être un nom, sans liste ni tags : un nom non conforme est tronqué dans la liste. sv_hostname ne les remplace pas : le fichier d’exemple précise qu’il n’est en général affiché nulle part dans les listes.

    Comment le confirmer

    Cherchez les deux lignes dans server.cfg, écrites avec sets comme dans la documentation, et lisez les premières lignes de la console après un redémarrage pour y repérer l’erreur de démarrage.

    Que faire

    Ajoutez sets sv_projectName "Votre Projet" et sets sv_projectDesc "Une phrase de description.", puis redémarrez.

  4. sv_licenseKey manque ou n’est pas valide, ou server.cfg n’a jamais été exécuté

    Notre déduction

    Le guide d’installation exige sv_licenseKey (clés sur portal.cfx.re ; le fichier d’exemple fournit changeme) et dit que no license key was specified peut venir d’un FXServer lancé hors du dossier de server.cfg, ou sans +exec server.cfg. Dans GameServer.cpp, le bloc du heartbeat ne s’exécute que si une valeur interne sv_licenseKeyToken n’est pas vide ; les sources citées plus bas ne disent pas comment elle est produite : relier une mauvaise clé à un listing absent est donc notre lecture.

    Comment le confirmer

    Cherchez no license key was specified au démarrage, et vérifiez que le lancement part du dossier qui contient server.cfg avec +exec server.cfg.

    Que faire

    Renseignez votre propre clé de portal.cfx.re et redémarrez. Ne la publiez jamais.

  5. Derrière un proxy : paramètres de listing absents, ou hôte de remplacement qui ne répond pas

    Documenté

    sv_forceIndirectListing true empêche d’annoncer le serveur avec sa vraie IP et, dans GameServer.cpp, va avec sv_listingHostOverride : sans lui, la console affiche l’erreur rouge citée en haut de cette page et le heartbeat part sans les champs de remplacement. Avec un hôte de remplacement, la page sur les proxys indique que le backend de listing interroge cet hôte au lieu de l’adresse par défaut, et un commentaire de GameServer.cpp prévient que le listing indirect forcé « will break listings if the proxy host can not be reached ». La même page précise que sv_listingIpOverride est nécessaire quand le backend ne peut pas deviner l’IP à interroger, par exemple pour un serveur dont le pare-feu refuse tous les hôtes sauf son proxy.

    Comment le confirmer

    Ouvrez /info.json, /players.json, /dynamic.json et /client sur votre hôte de remplacement : une installation qui fonctionne sert les trois premiers et /client affiche /client is POST only.

    Que faire

    Définissez sv_listingHostOverride sur le nom d’hôte que sert le proxy, faites-le relayer vers le serveur, et réglez sv_proxyIPRanges et sv_endpoints comme le montre la page sur les proxys. N’ajoutez sv_listingIpOverride que si le backend ne peut pas deviner l’IP à interroger.

  6. Le serveur vient de démarrer

    Documenté

    La documentation indique jusqu’à 8 minutes après le lancement si aucun autre heartbeat n’est envoyé. Le code source en envoie un toutes les 3 minutes et avance le suivant quand un joueur se connecte ou se déconnecte.

    Comment le confirmer

    Notez l’heure du démarrage, lancez heartbeat une fois et cherchez à nouveau après quelques minutes.

    Que faire

    Attendez les 8 minutes complètes. Un redémarrage est un nouveau lancement : il remet l’attente à zéro.

  7. Le HTTPS sortant de la machine du serveur est bloqué

    Notre déduction

    Le heartbeat est un POST HTTPS sortant vers servers-frontend.fivem.net, avec l’option ipv4 activée : route sortante bloquée, panne DNS ou absence de route IPv4 l’empêchent de partir. Un POST que le client HTTP signale comme échoué n’apparaît que dans un affichage de débogage distinct (error submitting to ingress) : la ligne rouge ne peut alors pas apparaître. Aucun document ne décrit les besoins en trafic sortant : c’est notre lecture du code.

    Comment le confirmer

    Sous Windows, lancez Test-NetConnection -ComputerName servers-frontend.fivem.net -Port 443 et cherchez TcpTestSucceeded : True. Sous Linux, curl -4 -I https://servers-frontend.fivem.net/ doit afficher une ligne de statut HTTP ; n’importe quel statut, même une erreur, prouve que la connexion aboutit.

    Que faire

    Autorisez le TCP sortant sur le port 443 et vérifiez le DNS depuis la machine ; demandez à votre hébergeur s’il filtre le trafic sortant.

  8. Autres causes citées par la documentation : un NAT qui masque les ports source UDP, ou le service de listing

    Documenté

    La page officielle dit qu’un serveur derrière un NAT ou une passerelle qui masque les ports source UDP peut ne pas apparaître, et qu’un problème peut toucher le service de listing lui-même (patientez). Elle ne dit pas quelle étape du listing dépend du port source, ni où consulter un statut.

    Comment le confirmer

    Ne les soupçonnez que si les tests extérieurs passent, si la config est correcte, si aucun proxy n’est en jeu et si plus de 8 minutes se sont écoulées. Une ligne rouge Server list query returned an error: <reason> qui revient en boucle entre aussi dans ce cas : gardez son texte.

    Que faire

    Cherchez dans la documentation de votre routeur ou pare-feu comment il réécrit les ports source UDP (la page cite le guide de pfSense), sinon patientez et demandez de l’aide sur le forum ou le Discord, avec les informations de « Toujours bloqué ? Ce qu’il faut publier ».

  9. L’adresse est saturée ou coupée, donc le service ne peut pas interroger le serveur

    Notre déductionLe cas du DDoS

    Le listing exige une requête qui atteint votre serveur (cause 1). Si l’adresse est saturée, filtrée ou coupée en amont, cette requête échoue en même temps que la connexion de chaque joueur. La documentation ne cite aucune attaque parmi les causes. Classée en dernier : elle exige une preuve extérieure et les précédentes coûtent moins à vérifier.

    Comment le confirmer

    Comparez l’heure où le serveur a quitté la liste avec le tableau de bord ou l’alerte de votre hébergeur et votre graphique de trafic entrant ; Direct Connect doit échouer pour tout le monde dans la même fenêtre.

    Que faire

    Demandez à votre hébergeur ce qu’il a enregistré et exportez-le rapidement. Ne redémarrez pas à répétition et ne publiez pas de nouvelle IP.

À quoi ressemble un DDoS ici

Une attaque explique un serveur listé puis devenu injoignable, pas un serveur jamais apparu ni marqué privé. Les symptômes sur la machine ne la prouvent pas : il faut une preuve extérieure.

À quoi ressemble un DDoS ici

  • Le serveur était listé avec des joueurs connectés, et a disparu à une heure que vous pouvez nommer.
  • Dans cette fenêtre, le tableau de bord ou l’alerte de votre hébergeur signale une attaque, ou votre graphique de trafic entrant montre un pic.
  • Direct Connect et info.json échouent pour tout le monde, depuis plusieurs réseaux, alors que le processus du serveur tourne normalement.

Preuves que vous pouvez recueillir

  • L’enregistrement de l’événement chez votre hébergeur

    Le Network Security Dashboard d’OVH (Network > Network Security Dashboard) liste les attaques détectées par son centre de nettoyage (onglet « Journal du Centre de nettoyage »), avec « Heure de détection », « Heure de fin », « IP de destination » et « Vecteurs d’attaque », pendant un an. Un journal vide n’est pas concluant : OVH indique que les attaques parties de l’intérieur de son propre réseau n’y sont pas signalées. Les adresses sources ne sont pas affichées (le plus souvent usurpées) : rien à bannir. Le graphique de trafic est conservé moins longtemps : exportez-le. Les autres hébergeurs diffèrent : demandez le même relevé.

  • Le trafic entrant sur la machine, comparé à une référence d’un jour calme

    Relevez une référence un jour calme, puis comparez paquets et volume de données reçus par interface (rxpck/s, rxkB/s). Sous Windows, lisez \Network Interface(*)\Packets Received/sec avec Get-Counter ; les noms de compteurs sont traduits sur un Windows non anglophone, et Get-Counter -ListSet * les affiche. Un flood éliminé en amont n’apparaît pas ici : le relevé de l’hébergeur est un meilleur témoin.

    sar -n DEV 1 10

Ce qui n’y ressemble pas

  • Un serveur jamais apparu, ou affiché en privé : ce sont les réglages des causes 2 à 5.
  • La ligne rouge Server list query returned an error: <reason> seule : elle signale l’échec d’une requête, et la documentation n’en liste pas les raisons.
  • Un txAdmin au vert. Avec endpoint_add_tcp "0.0.0.0:30120", son health check interroge /dynamic.json sur 127.0.0.1 : il peut afficher le serveur comme en ligne alors que personne à l’extérieur ne le joint.

Quand la protection est, ou n’est pas, la réponse

La protection est la réponse quand

  • Le serveur était listé et fréquenté, il a quitté la liste quand votre hébergeur ou votre graphique entrant signale une attaque, et Direct Connect échoue pour tout le monde : les guides sur le DDoS s’appliquent alors.
  • Vous placez un reverse proxy devant le serveur et voulez que la liste affiche son nom d’hôte plutôt que votre IP. La cause 5 est votre liste de contrôle.

La protection n’est pas la réponse quand

  • Le serveur n’est jamais apparu ou s’affiche en privé : ce sont sv_master1, sv_lan, les réglages du projet ou la clé de licence.
  • Un port est fermé, une règle manque ou le HTTPS sortant est bloqué : un proxy ne répare rien de cela.
  • Des paramètres de listing faux ou absents : un proxy ajoute cette cause, il ne la supprime pas.

Comment fonctionne un proxy anti-DDoS pour FiveM, et quand il s’applique

Toujours bloqué ? Ce qu’il faut publier

Publiez ces éléments ensemble, sans votre clé de licence, votre rcon_password ni aucun jeton.

  • Le numéro de build de votre FXServer et votre jeu (FiveM ou RedM).
  • Si http://IP:Port/info.json se charge depuis un téléphone en données mobiles et si Direct Connect fonctionne depuis un autre réseau, avec l’erreur exacte.
  • Les lignes rouges de la console après deux exécutions de heartbeat, en texte.
  • Les cinq réglages de server.cfg, avec la clé remplacée par xxxx.
  • Avec un proxy : vos paramètres de listing et ce que renvoie l’hôte de remplacement pour ses quatre URL.
  • Le moment de la dernière apparition du serveur, depuis combien de temps il tourne, et tout événement chez l’hébergeur à ce moment.

Questions fréquentes

Combien de temps faut-il pour qu’un serveur FiveM apparaisse dans la liste ?

La documentation indique jusqu’à 8 minutes après le lancement si aucun autre heartbeat n’est envoyé. Le serveur en envoie un toutes les 3 minutes et heartbeat en force un. Au-delà, parcourez les causes plutôt que de redémarrer.

Pourquoi mon serveur s’affiche-t-il en privé ?

La documentation désigne sv_master1 comme la variable qui marque un serveur privé et désactive son bouton de connexion. Un sv_master1 "" actif dans server.cfg suffit : placez un # devant la ligne, ou supprimez-la, puis redémarrez.

Est-ce que Server list query returned an error signifie que je suis attaqué ?

Pas à lui seul. La ligne affiche le texte lastError que le service de listing renvoie à votre heartbeat, et la documentation n’en liste pas les raisons. Testez d’abord depuis un autre réseau ; une attaque exige une preuve issue du tableau de bord ou de l’alerte de votre hébergeur.

Définir sv_maxclients au-dessus de 48 masque-t-il mon serveur ?

La documentation ne le dit pas. Sa page sur les problèmes de serveur traite « My Server Can Only Use 48 Slots » comme un problème connexe : plus de 48 places exigent un abonnement Element Club Argentum ou supérieur. Elle décrit un plafond de places, pas une absence de la liste.

Un reverse proxy peut-il faire disparaître mon serveur de la liste ?

Oui, cela peut arriver. Un commentaire de GameServer.cpp indique que le listing indirect forcé « will break listings if the proxy host can not be reached », et la page sur les proxys précise que sv_listingIpOverride est nécessaire quand le backend de listing ne peut pas deviner l’IP à interroger. La cause 5 donne les vérifications.

Sources et versions vérifiées

Vérifié le 7 octobre 2026 sur FXServer build 35245 (recommandé), 37150 (dernière) et txAdmin v8.1.1.

Les sources d’entreprises concurrentes de FiveShield sont citées avec leur nom de domaine, mais sans lien.

Le comportement du serveur change d’un build à l’autre. Si votre build affiche autre chose, les numéros de build ci-dessus indiquent la version sur laquelle cette page a été vérifiée.