Quelqu’un menace de DDoS mon serveur FiveM : mon IP est-elle exposée ?

Mis à jour le

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

VerdictUne menace n’est pas une attaque

Une menace n’est pas une attaque. La vraie question : l’IP d’origine de votre serveur est-elle publiée ? Vous pouvez le vérifier en deux minutes.

FiveShield aide pour une partie du problème

Cacher l’origine derrière un proxy, c’est ce que fait FiveShield, mais des mesures que vous pouvez prendre vous-même en couvrent une partie : commencez par celles-ci.

Une menace n’est pas du trafic. Un message sur Discord ou un ticket montre que quelqu’un veut nuire à votre serveur, pas qu’un paquet a été envoyé. La menace change en revanche la question : non plus « suis-je attaqué ? », mais « quelqu’un peut-il trouver l’adresse à viser ? »

Commencez par ce que le listing cfx.re publie. Par défaut, un serveur est annoncé avec sa vraie adresse : la documentation dit que sv_forceIndirectListing (par défaut false) « prevents the server from being advertised using its real IP address ». Le CFX Finder lit le listing comme le ferait un inconnu, à partir de votre code cfx.re/join/. Une IP brute et un port, c’est une adresse publique. Un membre du staff de Cfx.re a écrit, dans le fil sur l’arrêt du reverse proxy Nucleus, que « finding out your server IP has always been possible » (retrouver l’IP d’un serveur a toujours été possible).

Seule une preuve extérieure à la machine transforme une menace en attaque : une alerte de l’hébergeur, une ligne de son journal de mitigation, un graphique de trafic entrant qui décolle. D’ici là, fermez les voies par lesquelles on peut retrouver votre adresse, et notez le trafic entrant d’un jour calme pour avoir une référence. Si une preuve apparaît, lisez le guide sur le pic de trafic ou l’alerte de l’hébergeur.

Messages que vous pouvez voir

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

    Dans la console du serveur, en rouge, à chaque envoi d’un heartbeat, quand sv_forceIndirectListing est activé sans sv_listingHostOverride

Ce que cela signifie vraiment

Cette page porte sur ce que votre serveur dit au monde extérieur. Toutes les 3 minutes, et plus tôt après la connexion ou le départ d’un joueur, FXServer (GameServer.cpp) envoie un heartbeat : une requête HTTPS POST sortante vers le point d’entrée du listing Cfx.re. Elle transporte votre port, un jeton de listing et ipOverride (issu de sv_listingIpOverride, vide par défaut). Le guide du proxy dit que cette valeur n’est nécessaire que si le backend ne peut pas retrouver l’IP lui-même, ce qui laisse penser que, normalement, il trouve votre adresse tout seul.

Un client détermine ensuite un connect endpoint (le champ connectEndPoints du listing, que sv_listingHostOverride permet de fixer), y appelle GET /info.json et POST /client, puis demande à getEndpoints le server endpoint, que fixe sv_endpoints et qui reçoit ensuite son trafic UDP. Cacher l’origine, c’est changer ce que publient les deux endpoints, puis faire refuser par la machine tout ce qui ne vient pas de votre proxy. Les convars qui fixent ces endpoints ne filtrent aucun paquet.

À vérifier en premier (deux minutes)

Cinq vérifications séparent « quelqu’un a dit quelque chose » de « l’adresse est publique » et de « du trafic arrive ».

  1. Une preuve de trafic, ou seulement un message ?

    Une preuve est extérieure à la machine : une alerte de l’hébergeur sur une attaque visant votre IP, une ligne de son journal de mitigation, un graphique de trafic entrant qui décolle. Un message n’en est pas une.

  2. Cherchez votre serveur dans le CFX Finder

    Saisissez votre code cfx.re/join/ pour voir l’adresse de connexion que cfx.re publie.

    • Il affiche une IP brute et un port, sous « L’IP de ce serveur est exposée » ou sous un titre qui finit par « mais publie une IP brute ».: Lire la cause 1 : le listing publie votre vraie adresse

    • Il affiche un nom d’hôte, ou une adresse dans la plage d’un réseau proxy.: Passer à l’étape 3.

    • Il affiche « Listé comme privé » et c’est voulu.: Passer à l’étape 4 : le listing ne publie aucune adresse, mais les autres fuites restent possibles.

    • Il affiche « Listé comme privé » alors que ce n’est pas voulu.: Lire le guide sur un serveur absent de la liste des serveurs

    • Il affiche « Aucune adresse de connexion exploitable ».: Le listing ne donne rien à lire : passer à l’étape 3.

  3. Forcez un heartbeat et lisez la console

    Lancez heartbeat, cherchez une ligne rouge dans la console, puis cherchez de nouveau le serveur dans le CFX Finder.

    heartbeat

  4. Comparez trois adresses

    L’adresse publique de la machine ; l’adresse vers laquelle pointe chacun de vos noms d’hôte (votre site web, et le nom de sv_listingHostOverride ; demandez les enregistrements A et AAAA à un outil DNS) ; et sv_endpoints dans server.cfg.

  5. Testez l’origine depuis l’extérieur

    Depuis une machine qui n’est ni votre serveur ni votre proxy (un téléphone en données mobiles convient), ouvrez http://<origin-ip>:30120/info.json, l’URL que la documentation FiveM utilise pour tester l’accessibilité, puis http://<origin-ip>:40120 pour txAdmin.

Causes, classées

L’ordre est éditorial : d’abord les causes qu’une source documente, en commençant par la vérification la moins coûteuse. Ce n’est pas une fréquence mesurée, et plusieurs causes peuvent se cumuler.

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 listing cfx.re publie votre vraie adresse

    Documenté

    Par défaut, le listing annonce la vraie adresse de la machine : sv_forceIndirectListing vaut false par défaut, et le commentaire du guide du proxy sur cette ligne dit « prevents the server list from advertising your server using its actual IP ». Le connect endpoint vient du champ connectEndPoints du listing, que sv_listingHostOverride permet de fixer. Quiconque a votre code cfx.re/join/ peut lire cette adresse.

    Comment le confirmer

    Cherchez votre code cfx.re/join/ dans le CFX Finder. Une IPv4 brute avec un port le confirme ; un nom d’hôte, non. « Listé comme privé » ne prouve pas une origine cachée : le listing ne publie aucune adresse, ce qui est autre chose.

    Que faire

    Placez un proxy de connexion sur un nom d’hôte que vous contrôlez, puis définissez sv_forceIndirectListing true et sv_listingHostOverride "server1.example.com" (votre nom d’hôte), avec sv_proxyIPRanges limité à votre proxy, car les plages listées contournent aussi le limiteur de débit. Attendez que le nom d’hôte réponde : un commentaire du code source de FXServer prévient que l’option « will break listings if the proxy host can not be reached ». Lancez ensuite heartbeat et revérifiez ; la documentation ne donne aucun délai de rafraîchissement pour un listing modifié (elle indique seulement qu’un nouveau serveur peut mettre jusqu’à 8 minutes à apparaître).

  2. sv_forceIndirectListing est activé sans sv_listingHostOverride, ou n’a jamais été appliqué

    Documenté

    Dans GameServer.cpp, le heartbeat n’ajoute forceIndirectListing et hostOverride que si sv_listingHostOverride n’est pas vide. Option activée sans valeur de remplacement, le serveur affiche l’erreur rouge ci-dessus et n’envoie aucun des deux champs. Le code source ne dit pas ce que fait alors le backend ; le CFX Finder le montre.

    Comment le confirmer

    Lancez heartbeat : la ligne rouge signifie que la valeur manque. Sans erreur et avec une IP brute toujours visible, vérifiez que les lignes sont dans le fichier que FXServer exécute, que vous avez redémarré, qu’un heartbeat est parti depuis, et que le nom est écrit exactement sv_listingHostOverride.

    Que faire

    Définissez les deux ensemble, une fois le nom d’hôte opérationnel. Sans proxy pour l’instant, retirez sv_forceIndirectListing : seul, le serveur ne l’envoie même pas.

  3. L’endpoint de jeu, sv_endpoints, désigne encore votre propre adresse

    Documenté

    Un nom d’hôte dans le listing ne cache que la première moitié. Le guide du proxy dit que le server endpoint « needs a raw TCP/UDP proxy on matching ports » : getEndpoints donne à chaque client « one or more IP/port combos » et le client y envoie son UDP. L’exemple du guide place dans sv_endpoints « the actual endpoint your server is hosted on ». Toute personne qui s’est connectée tant que cette valeur était en place, un joueur banni ensuite compris, a reçu cette adresse. Laissé vide, sv_endpoints ne décide pas : la documentation de la convar dit « the auto-detected public IP is used », mais dans InitConnectMethod.cpp une valeur vide fait renvoyer une liste vide au serveur, et le client (NetLibrary.cpp) envoie alors son UDP à l’hôte auquel il s’est connecté. Une IP brute dans le listing désigne donc l’origine ; un nom d’hôte désigne ce vers quoi ce nom pointe.

    Comment le confirmer

    Lisez sv_endpoints. Si c’est l’adresse même de la machine, l’endpoint de jeu est l’origine. S’il est vide, voir ci-dessus : le listing décide, regardez donc les causes 1 et 4. Le CFX Finder ne le voit pas, car il ne rapporte que l’adresse de connexion.

    Que faire

    Faites pointer sv_endpoints vers l’adresse publique d’un proxy qui relaie l’UDP et le TCP sur des ports identiques, puis fermez le port de jeu à tout ce qui n’est pas ce proxy. D’ici là, l’ancienne adresse continue de fonctionner pour quiconque la possède.

  4. Un enregistrement DNS, un site web, une capture d’écran ou une ressource publie l’adresse

    Notre déduction

    C’est notre raisonnement, pas un comportement de FXServer. Un nom d’hôte dont l’enregistrement A ou AAAA contient l’adresse de la machine la publie à quiconque sait taper ce nom : votre site web, un sous-domaine play., le nom de sv_listingHostOverride s’il pointe vers l’origine. Les adresses sortent aussi par le propriétaire : une capture d’écran de la console dans un canal d’aide, un webhook qui inclut l’endpoint, un script client qui appelle votre API par IP (les joueurs téléchargent les scripts client). Considérez comme connue toute adresse un jour publiée à côté de votre nom.

    Comment le confirmer

    Comparez les enregistrements A et AAAA de chaque nom d’hôte concerné avec l’adresse de la machine. Cherchez l’adresse en clair dans vos ressources et vos configurations, et relisez les modèles de vos webhooks.

    Que faire

    Déplacez le site web ailleurs ou derrière un proxy HTTP, faites pointer le nom d’hôte du listing vers le proxy uniquement, et retirez les adresses en clair. Si l’adresse de l’origine a un jour été publiée, demandez-en une nouvelle à votre hébergeur une fois le proxy en place : la changer avant ne ferait que faire apparaître la nouvelle adresse dans le listing dès les prochains heartbeats.

  5. txAdmin ou un autre service répond sur la même adresse

    Notre déduction

    La documentation de txAdmin dit qu’il écoute par défaut sur le port TCP 40120 (TXHOST_TXA_PORT), sur l’interface 0.0.0.0 (TXHOST_INTERFACE), donc sur toutes les interfaces. Qu’il soit joignable depuis Internet dépend de votre pare-feu, que la documentation ne décrit pas : le reste est une déduction. Un panel qui répond sur http://<origin-ip>:40120 apprend à quiconque le trouve que cette adresse fait tourner votre serveur.

    Comment le confirmer

    Depuis l’extérieur de votre réseau, ouvrez http://<origin-ip>:40120. Une page de connexion txAdmin signifie que le panel répond sur l’origine. Répétez l’opération pour tout autre panel ou service de la machine.

    Que faire

    Limitez le port 40120 aux adresses depuis lesquelles vous administrez, dans le pare-feu de la machine ou celui de l’hébergeur. N’utilisez pas TXHOST_INTERFACE pour le cacher : sa documentation indique que cette variable détermine aussi l’interface sur laquelle FXServer se lie.

  6. La menace est suivie d’une vraie attaque

    Notre déductionLe cas du DDoS

    Une menace peut être mise à exécution. Aucune source que nous connaissons ne mesure à quelle fréquence, donc cette page ne donne aucun taux. Dès que quelqu’un a l’adresse, il peut y viser du trafic de n’importe où, et les sources sont généralement usurpées, ce qui explique qu’OVHcloud ne les affiche pas. Seule une preuve extérieure à votre machine le montre.

    Comment le confirmer

    Cherchez une alerte de l’hébergeur, une ligne de journal ou un pic du trafic entrant (commandes plus bas). Chez OVHcloud, Network > Network Security Dashboard liste chaque attaque détectée, dans l’onglet « Journal du Centre de nettoyage », avec « Heure de détection », « Heure de fin », « IP de destination » et « Vecteurs d’attaque » ; un journal vide signifie « no suspected attacks have targeted your public IP addresses », mais il ne couvre que ce que la détection signale.

    Que faire

    Ne redémarrez pas à répétition et n’annoncez aucune nouvelle adresse. Sauvegardez dès maintenant le journal et le graphique de l’hébergeur (OVHcloud documente un an pour le journal, deux mois pour le graphique). Placez d’abord un proxy devant, puis changez l’adresse de l’origine et ne la publiez nulle part.

À quoi ressemble un DDoS ici

Une attaque qui suit une menace se voit d’abord hors de votre machine, pas dans le message.

À quoi ressemble un DDoS ici

  • Votre hébergeur vous prévient : un e-mail ou une entrée de tableau de bord indiquant que le trafic vers votre IP a été réacheminé ou filtré, à partir du moment où les problèmes ont commencé.
  • Un graphique de trafic entrant qui bondit, en paquets ou en bits par seconde, par rapport au niveau habituel d’un jour calme. Le trafic sortant après un redémarrage, ce sont des téléchargements, pas une attaque.

Preuves que vous pouvez recueillir

  • L’alerte et le journal de votre hébergeur

    Chez OVHcloud : Network > Network Security Dashboard, onglet « Journal du Centre de nettoyage ». Les sources sont masquées car généralement usurpées : rien à bannir. Les autres hébergeurs diffèrent.

  • Débit de paquets entrants sous Linux

    Lancez cette commande pendant l’incident et un jour calme, puis comparez rxpck/s (paquets reçus par seconde) et rxkB/s.

    sar -n DEV 1 10

  • Débit de paquets entrants sous Windows

    La même comparaison avec le compteur de paquets reçus.

    Get-Counter -Counter '\Network Interface(*)\Packets Received/sec' -Continuous

  • Une courte capture du port de jeu

    Nécessite les droits root. Utilisez votre interface et votre port. Une poignée d’adresses de joueurs est normale ; de nombreuses sources dispersées qui envoient bien plus de paquets que vous n’avez de joueurs ne le sont pas. Les sources peuvent être usurpées : une capture vient étayer l’alerte de l’hébergeur et le graphique sans les remplacer. Ne bannissez pas les sources.

    tcpdump -n -i <iface> -c 2000 'udp dst port 30120'

Ce qui n’y ressemble pas

  • La menace elle-même, même si elle cite votre vraie adresse : elle montre que l’adresse est connue (fermez l’origine), pas qu’un trafic arrive.
  • Du lag, des hitch warnings ou des timeouts, pris isolément.
  • Une IP brute dans le CFX Finder seule, ou du trafic sortant après un redémarrage.

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

La protection est la réponse quand

  • Votre adresse a été publique (une IP brute dans le CFX Finder, une adresse citée, une capture) et vous voulez que cela cesse d’avoir de l’importance : le listing et l’endpoint de jeu doivent publier l’adresse d’un proxy, et la machine doit refuser tout le reste.
  • Vous avez confirmé un trafic d’attaque que la mitigation propre à votre hébergeur n’arrête pas. Les convars publient moins et un pare-feu refuse les inconnus, mais ni l’un ni l’autre n’absorbe un trafic qui a déjà atteint votre lien.
  • Vous ne pouvez pas faire tourner vous-même un proxy TCP et UDP sur des ports identiques, ce que le guide du proxy exige pour le server endpoint.

La protection n’est pas la réponse quand

  • Le CFX Finder affiche un nom d’hôte qui n’est pas votre machine, sv_endpoints désigne un proxy et l’origine refuse le trafic extérieur : l’adresse n’est plus publiée ; filtrer est une décision distincte.
  • La fuite vient de vous : un enregistrement DNS, un site web sur la machine, un port txAdmin ouvert, une adresse dans une ressource. Un proxy devant le port de jeu n’en ferme aucune.
  • Le symptôme est du lag, un hitch warning ou un timeout sans preuve extérieure. Un proxy ne change pas la vitesse d’exécution d’un thread.
  • L’origine accepte toujours le trafic direct : un proxy est contourné tant que l’adresse de l’origine ne change pas et que son pare-feu n’accepte pas uniquement le proxy.

Si vous êtes réellement attaqué, ou voulez cacher l’origine

Si une attaque est en cours : ne redémarrez pas à répétition, car le trafic qui arrive de l’extérieur ne s’arrête pas quand le processus redémarre et chaque redémarrage déconnecte vos joueurs ; n’annoncez aucune nouvelle adresse, car la personne qui vous a menacé est peut-être dans le canal ; sauvegardez les preuves de votre hébergeur avant qu’elles n’expirent.

Placez un proxy devant avant de changer l’adresse de l’origine : tant que le listing et sv_endpoints ne pointent pas vers le proxy, la nouvelle adresse est de nouveau listée en quelques heartbeats. Une fois le proxy opérationnel, demandez une nouvelle adresse d’origine à votre hébergeur et ne la publiez nulle part.

FiveShield assure cette partie. Les joueurs se connectent via ses instances proxy : le listing et l’endpoint de jeu publient donc un nom d’hôte FiveShield au lieu de votre adresse, et son filtrage s’applique à ce qui atteint le proxy. Les fuites que vous avez vous-même créées, comme aux causes 4 et 5, restent à votre charge.

Commencer l'essai gratuit

Votre premier serveur reçoit 10 $ CA de crédit d’essai gratuit (comptes éligibles, sans carte bancaire) : environ quatre jours de protection jusqu’à 50 joueurs.

Ce que doit faire une protection anti-DDoS FiveM, y compris cacher l’origine

Toujours bloqué ? Ce qu’il faut publier

Remplacez votre vraie adresse par x.x.x.x dans tout ce que vous collez : un fil d’aide est public.

  • Le numéro de build de votre FXServer, et la version de txAdmin si vous l’utilisez.
  • Ce que le CFX Finder indique (IP brute, nom d’hôte ou privé), adresse masquée.
  • Les lignes de server.cfg qui commencent par sv_forceIndirectListing, sv_listingHostOverride, sv_endpoints et sv_proxyIPRanges, adresses masquées.
  • La sortie de la console après heartbeat, y compris toute ligne Error: Force indirect listing ou Server list query returned an error:.
  • Si votre site web et votre panel tournent sur la même machine que FXServer : oui ou non.
  • Si vous soupçonnez une attaque : la ligne de journal de l’hébergeur (masquée) et votre sortie sar ou Get-Counter.

Questions fréquentes

Quelqu’un m’a menacé de DDoS. Que dois-je faire ?

Une menace n’est pas du trafic. Cherchez votre code cfx.re/join/ dans le CFX Finder et parcourez les cinq vérifications ci-dessus. Si votre hébergeur ou un graphique montre du trafic, lisez le guide sur le pic de trafic ou l’alerte de l’hébergeur. Ne redémarrez pas à répétition et n’annoncez pas de nouvelle adresse.

Comment vérifier si l’IP de mon serveur FiveM est exposée ?

Saisissez votre code cfx.re/join/ dans le CFX Finder : une IP brute et un port signifient que le listing publie votre adresse. Comparez ensuite vos noms d’hôte et sv_endpoints avec l’adresse de la machine, et depuis l’extérieur ouvrez http://<origin-ip>:30120/info.json et http://<origin-ip>:40120.

Changer l’IP de mon serveur suffit-il ?

Cela efface le passé, pas l’avenir. Le guide du proxy laisse entendre que le backend du listing retrouve votre adresse tout seul : en quelques heartbeats (envoyés toutes les 3 minutes), attendez-vous donc à ce que le listing affiche la nouvelle adresse comme il affichait l’ancienne, sauf si le listing et sv_endpoints pointent vers un proxy. Mettez d’abord le proxy en place.

sv_endpointPrivacy cache-t-il l’IP de mon serveur ?

Non. Il concernait les adresses des joueurs et a été supprimé. Si vous le définissez encore, FXServer affiche « sv_endpointPrivacy has been removed. Player endpoint addresses are no longer exposed on any HTTP endpoint. » Votre propre adresse dépend de sv_forceIndirectListing, sv_listingHostOverride et sv_endpoints.

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.

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.