Pourquoi votre IP finit toujours par sortir
Un serveur FiveM doit être joignable pour être jouable. À un moment ou à un autre, quelque chose doit publier une adresse et un port que le client du joueur peut atteindre — sinon personne ne se connecte. Toute la question de la dissimulation d'IP tient là-dedans : faire en sorte que cette adresse publiée soit celle d'un proxy, et jamais celle de la machine qui fait tourner FXServer.
Le problème, c'est que FiveM publie beaucoup de choses par défaut. Le serveur expose ses propres endpoints HTTP, s'annonce auprès du backend de liste Cfx.re, et la plupart des propriétaires font tourner un site web, un panel txAdmin et un FastDL sur la même machine. Chacune de ces surfaces peut trahir l'adresse d'origine indépendamment des autres — et il suffit d'une seule pour que le masquage s'effondre.
Cet article couvre les convars qui masquent vraiment l'origine, ceux qui ne servent plus à rien même s'ils circulent encore dans tous les blocs de config copiés-collés, les fuites qui annulent tout le reste, et la vérification à faire vous-même en deux minutes. Aucune commande ici n'est inventée : chaque convar est cité d'après la documentation officielle FiveM.
Ce que voit quelqu'un qui cherche votre origine
Le modèle de menace est simple, et il ne demande aucune compétence particulière. Quelqu'un veut faire tomber votre serveur : il lui faut une IP à saturer. Il commence par ce que Cfx.re publie sur votre serveur, puis il élargit — l'historique DNS de votre domaine, le certificat TLS de votre site, l'IP du panel, celle du FastDL, les messages d'erreur de FXServer.
Ce n'est pas un exploit, c'est de la collecte. Chaque service que vous exposez depuis la même machine est une chance supplémentaire de recouper une adresse. C'est pour ça qu'un masquage partiel ne vaut rien : un attaquant n'a pas besoin de la meilleure source, juste d'une source qui marche.
La bonne nouvelle : la surface est finie et se ferme méthodiquement. Si quelqu'un a déjà menacé de DDoS votre serveur, voici comment vérifier si votre IP est exposée.
Le bloc server.cfg qui masque réellement l'origine
Commençons par le convar que tout le monde met en premier — et qui ne fait pas ce que la plupart des gens croient.
sv_endpointPrivacy : le malentendu le plus répandu
La documentation FiveM le décrit comme « a boolean variable that, if true, hides player IP addresses from public reports output by the server ». Notez bien : les adresses IP des joueurs, pas la vôtre. Il n'a jamais masqué l'adresse de votre serveur — il empêchait players.json de publier l'IP de chaque joueur connecté.
Et sur les builds FXServer actuels, il ne fait même plus ça, parce que le comportement est devenu inconditionnel. Si vous le laissez dans votre config, le serveur affiche au démarrage :
sv_endpointPrivacy has been removed. Player endpoint addresses are no longer
exposed on any HTTP endpoint. Please remove this ConVar from your server
configuration.
Conclusion : gardez-le si vous tournez sur un build ancien, retirez-le sinon, et surtout ne comptez pas dessus pour cacher votre origine. Le même raisonnement s'applique à sv_useDirectListing, qu'on retrouve dans quasiment tous les blocs « anti-DDoS » partagés sur les forums : il n'apparaît ni dans la référence des commandes serveur, ni dans le guide officiel de mise en place derrière un proxy. Le levier documenté, c'est sv_forceIndirectListing.
Les convars qui masquent vraiment
Le guide officiel de configuration derrière un proxy donne ce bloc de référence :
set sv_forceIndirectListing true
set sv_listingHostOverride "server1.example.com"
set sv_proxyIPRanges "100.64.1.1/32"
set sv_endpoints "100.64.1.2:30120"
Ce que fait chaque ligne :
| Convar | Ce que ça fait | Ce que ça ne fait pas |
|---|---|---|
sv_forceIndirectListing | Booléen (false par défaut) qui empêche le serveur d'être annoncé avec sa vraie adresse IP dans la liste | Ne filtre rien, ne bloque aucun paquet |
sv_listingHostOverride | Demande au backend de liste d'utiliser un domaine précis plutôt que la méthode de connexion par défaut | Ne change rien pour qui connaît déjà l'IP |
sv_endpoints | Déclare l'endpoint réel du serveur, ou un ou plusieurs proxies d'endpoint que les clients utilisent pour se connecter en UDP | Ne ferme pas l'accès direct à l'origine |
sv_proxyIPRanges | Liste de réseaux IPv4 en notation CIDR, séparés par des espaces, autorisés à envoyer un en-tête X-Real-IP — et à contourner le limiteur de débit | Rien d'autre : ce n'est pas une liste blanche de pare-feu |
sv_listingIpOverride | Sert uniquement quand le backend de liste n'arrive pas à déterminer l'IP seul (machine multi-IP, serveur derrière un pare-feu) | N'est pas nécessaire dans une installation proxy classique |
Le point de vigilance sur sv_proxyIPRanges : la documentation est explicite, les plages listées contournent le limiteur de débit. Mettre 0.0.0.0/0 ou une plage large « pour que ça marche » désactive donc une protection intégrée pour tout Internet, en plus de laisser n'importe qui usurper X-Real-IP. N'y mettez que les CIDR exacts de votre proxy — rien de plus.
Ces réglages masquent l'adresse ; ils ne filtrent aucun paquet. C'est le rôle d'un anti-DDoS FiveM, qui est un service distinct et un métier distinct.
Les fuites qui annulent tout le reste
Vous pouvez avoir le bloc parfait et rester exposé. Voici les sept fuites qu'on retrouve le plus souvent, dans l'ordre où elles se produisent réellement.
- Le site web sur la même machine. Votre domaine pointe en A vers la même IP que FXServer. Un
digsuffit. Passez le site derrière un proxy HTTP, ou hébergez-le ailleurs. - Un ancien enregistrement DNS. Vous avez mis le site derrière un proxy après coup, mais l'historique DNS et les journaux publics de certificats gardent trace de l'ancienne adresse. Si l'origine a déjà été publique, il faut souvent changer d'IP pour repartir propre.
- Le FastDL et le cache de ressources. Un
fileserver_addqui pointe vers votre propre machine sert les téléchargements depuis l'origine, à chaque joueur qui se connecte. Servez-les via un CDN. - Les messages d'erreur de FXServer. Certains échecs de connexion renvoient au client une adresse brute. C'est la fuite la plus discrète parce qu'elle ne se voit que quand quelque chose casse.
- txAdmin exposé. Le panel écoute sur son propre port sur la même machine. S'il répond depuis l'IP d'origine, il l'annonce. Restreignez-y l'accès ou faites-le passer par le proxy.
- Les webhooks Discord et les logs. Un webhook de log qui inclut l'endpoint du serveur, une capture d'écran de console postée dans un salon d'aide, une commande de debug lancée devant des joueurs — tout ça circule.
- Une IP codée en dur dans une ressource. Une ressource qui appelle votre propre API par IP plutôt que par nom d'hôte met l'adresse dans un fichier que n'importe quel joueur télécharge.
La règle générale : votre IP d'origine ne doit apparaître nulle part ailleurs que dans votre propre pare-feu et dans la configuration de votre proxy.
Vérifier vous-même, en deux minutes
Ne vous fiez pas à la config, vérifiez le résultat. Le CFX Finder part d'un code cfx.re/join/ et vérifie si l'adresse de connexion que Cfx.re publie pour ce serveur est exposée. Cherchez le vôtre et regardez l'adresse de connexion affichée :
- Si vous voyez le nom d'hôte de votre proxy, ou le domaine indiqué dans
sv_listingHostOverride, le listing indirect fonctionne. - Si vous voyez une IPv4 brute suivie de
:30120, votre origine est publiée telle quelle —sv_forceIndirectListingn'est pas actif, ou n'a pas été relu au démarrage. - Si l'outil affiche le serveur comme privé, sans aucune adresse, le listing est cassé, pas masqué : Cfx.re publie alors un endpoint
private-placeholder.cfx.reet le bouton de connexion est désactivé. C'est en général un problème de listing —sv_licenseKeymanquante ou non enregistrée,sv_master1vidé, ou plus de 32 slots sans OneSync. Corrigez cela d'abord : un listing privé n'est pas un masquage d'origine.
Complétez avec deux vérifications côté réseau : un dig +short votredomaine.com ne doit pas renvoyer l'IP de la machine de jeu, et une requête directe sur l'IP d'origine au port 30120 ne doit rien renvoyer depuis l'extérieur. Si vous êtes déjà passé par un proxy, ce test-là est le plus révélateur des deux.
Masquer n'est pas filtrer
Un point que les guides sautent presque toujours : cacher l'adresse ne réduit pas la surface d'attaque, cela la déplace. L'adresse publiée devient celle du proxy, et c'est cette adresse-là qui prend l'attaque. Si le proxy n'a ni la bande passante pour absorber un flood volumétrique, ni un filtrage qui comprend la poignée de main FiveM, vous avez simplement déplacé la cible d'un cran.
C'est aussi pour ça qu'un masquage seul ne tient pas dans la durée. Le jour où quelqu'un retrouve l'origine — via une des sept fuites plus haut, ou parce qu'elle était publique avant que vous vous en occupiez — il n'y a plus rien entre l'attaque et la machine. Le verrouillage du pare-feu d'origine sur les seules plages du proxy est donc la moitié obligatoire du travail, et le guide complet pour stopper les attaques DDoS sur un serveur FiveM détaille les règles à poser.
Une protection anti-DDoS FiveM avec masquage permanent de l'origine fait les deux : elle publie une adresse qui n'est pas la vôtre, et elle filtre ce qui arrive sur cette adresse. Chez nous, la configuration tient dans un bloc à coller en haut de server.cfg — le guide d'installation prend cinq minutes, et la tarification se fait au pic de joueurs quotidien, sans abonnement.
Questions fréquentes
Changer l'IP de mon serveur suffit-il à régler le problème ?
Ça règle le passé, pas l'avenir. Si l'ancienne adresse était publique, changer d'IP vous redonne une page blanche — mais sans listing indirect ni pare-feu d'origine, la nouvelle adresse sera publiée exactement comme l'ancienne dès le premier démarrage.
sv_endpointPrivacy protège-t-il l'IP de mon serveur ?
Non. Il concernait les adresses IP des joueurs dans les rapports HTTP publics du serveur, jamais celle du serveur lui-même. Sur les builds FXServer actuels, il est retiré et le serveur vous demande de l'enlever de votre configuration.
Un VPN ou un changement de port peut-il cacher mon serveur ?
Non. Le port n'est pas un secret — il est publié avec l'endpoint — et un VPN grand public ne change rien à l'adresse que FXServer annonce à la liste Cfx.re. C'est le listing qui décide de ce qui est public, pas la couche réseau en dessous.
Est-ce que je peux tout faire sans service payant ?
En partie, oui. Le listing indirect, le verrouillage du pare-feu d'origine et le nettoyage des sept fuites sont gratuits et valent la peine dans tous les cas. Ce que le gratuit ne vous donne pas, c'est la bande passante d'absorption en amont et un filtrage qui distingue un vrai joueur d'une fausse connexion.
Comment savoir si ma configuration est bien prise en compte ?
Redémarrez le serveur et relisez la console de démarrage : les convars sont lus dans l'ordre du fichier, donc un bloc placé après une ligne qui les écrase ne s'applique pas. Puis refaites la vérification par le CFX Finder — c'est le seul test qui reflète ce que le monde extérieur voit vraiment.