Ce qui vide vraiment un serveur RP en pleine soirée — et ce qui l'en empêche.
server.cfg peut masquer votre adresse. Il ne peut pas rejeter un flood avant qu'il n'atteigne votre lien réseau. Voici la différence, et comment Vanta s'insère exactement là où ça compte.
Le serveur tourne. Plus personne ne peut y entrer.
C'est le symptôme le plus déroutant d'un vrai DDoS : le CPU et la RAM de la machine restent normaux, le processus FXServer répond toujours en console — mais les connexions timeout simultanément, pour tout le monde, d'un coup. Le problème n'est jamais dans le serveur : il est sur le lien réseau qui y mène, saturé avant même d'arriver au jeu.
La cause la plus fréquente n'est pas un concurrent organisé, mais un joueur banni ou en conflit qui loue un « booter » pour quelques dollars — un service de DDoS à la demande qui ne demande aucune compétence technique pour être utilisé.
Quatre formes, un seul point commun.
Aucune ne se joue à l'intérieur de FXServer — elles se traitent avant votre serveur, ou pas du tout.
Flood volumétrique (L3/L4)
FiveM fait circuler le jeu par ENet, au-dessus d'UDP. Aucun accord préalable n'est requis pour qu'un paquet soit traité — un booter loué quelques dollars dirige plusieurs gigabits vers votre IP, et c'est le lien réseau qui sature en premier, pas le CPU du serveur.
Flood de connexions (L7)
Une fois le volume brut absorbé en amont, l'attaque change de forme : des poignées de main cfx.re parfaitement valides, envoyées par milliers à la seconde. Rien dans leur structure ne les distingue d'un vrai joueur — un filtre qui ne juge que la forme du paquet les laisse passer.
Flood de téléchargement de ressources
Le serveur sert aussi ses fichiers (scripts, textures, cartes) à chaque connexion. Une vague de fausses connexions qui redemandent ces mêmes fichiers en boucle épuise la bande passante sortante — sans jamais toucher au port de jeu lui-même.
Flood getinfo / getstatus
Le protocole d'annonce de serveur (utilisé par les navigateurs de serveurs) répond à quiconque interroge le port. Le saturer de requêtes le fait disparaître des listes publiques ou ralentit ses réponses, sans forcément faire tomber le jeu.
Ce que server.cfg peut — et ne peut pas — faire.
Ces convars sont utiles et Vanta les inclut dans la configuration générée automatiquement. Mais aucune ne filtre un paquet avant qu'il n'arrive : elles gèrent la confiance et la visibilité, pas le réseau.
| Convar | Ce qu'elle fait | Ce qu'elle ne fait pas |
|---|---|---|
| sv_forceIndirectListing | Empêche votre IP réelle d'apparaître dans la liste publique des serveurs. | N'empêche rien si votre IP est déjà connue par un autre canal (ancien admin, scan, fuite). |
| sv_proxyIPRanges / sv_listingHostOverride | Indique aux joueurs de passer par une IP de façade plutôt que la vôtre. | Ne bloque aucun paquet — c'est une convention de confiance, pas un filtre réseau. |
| sv_endpointPrivacy | Réduit les informations exposées sur l'endpoint du serveur. | N'a aucun effet sur le volume de trafic qui atteint déjà votre machine. |
| sv_requestParanoia | Ajoute une vérification supplémentaire sur certaines requêtes entrantes. | Coûte du CPU par paquet reçu — sous un vrai flood volumétrique, la file d'attente déborde avant que la vérification ne serve à quoi que ce soit. |
Ce qui bloque quoi, et où.
| Approche | Volumétrique L3/L4 | Protocole L7 | Note |
|---|---|---|---|
| Cloudflare (plan gratuit) | Protège le HTTP/HTTPS — ne touche pas au port UDP du jeu. | ||
| Anti-DDoS générique de l'hébergeur | Filtre les attaques massives évidentes, sans connaître le protocole FiveM. | ||
| iptables fait maison | Fonctionne, mais le paquet a déjà traversé votre lien avant d'être jeté. | ||
| Ressource Lua côté serveur | S'exécute après que FXServer a déjà encaissé la connexion — utile en complément, pas en remplacement. | ||
| Vanta Shield | Filtré avant même d'atteindre votre lien réseau, sur un relais dédié devant votre origine. |
Le filtrage se fait avant votre lien réseau, pas dedans.
Filtrage volumétrique L3/L4
Chaque source est limitée en débit sur le relais, en amont de votre origine. Le trafic qui dépasse le seuil est journalisé puis rejeté avant de consommer votre bande passante.
Validation du protocole L7
Le trafic est vérifié contre le protocole FiveM/RedM avant d'être acheminé — ce qui ne s'y conforme pas n'entre jamais dans le réseau qui mène à votre serveur.
IP d'origine masquée
Les joueurs se connectent à une adresse dédiée à votre serveur, générée automatiquement. Votre IP réelle n'est jamais communiquée au client.
Aucune migration requise
Vanta se place devant votre serveur existant, chez n'importe quel hébergeur. Un bloc dans server.cfg, un redémarrage, c'est tout.
Quatre couches actives, aucune décorative.
Chacune bloque un type d'abus différent. Aucune ne remplace les autres — c'est leur superposition qui fait la différence quand une attaque change de forme en cours de route.
Filtrage réseau en amont
Avant même d'atteindre notre relais, le trafic traverse la protection réseau de l'infrastructure sous-jacente — une première couche qui absorbe une partie du volume brut, en continu, sans configuration de votre part.
Limitation de débit par IP, en temps réel
Chaque adresse source est mesurée en direct sur le relais. Au-delà d'un seuil de paquets par seconde, elle est rejetée immédiatement — avant de consommer la bande passante qui mène à votre serveur.
Rejet au niveau de la carte réseau (XDP)
Les adresses les plus insistantes sont bloquées directement au niveau du pilote réseau, avant même que le système d'exploitation ne construise le paquet — le point le plus rapide possible pour jeter du trafic indésirable.
Liste noire dynamique, deux étages
Une adresse qui insiste après avoir été limitée est bannie automatiquement pendant 6 heures — jamais de façon permanente, pour ne jamais pénaliser une IP légitime réattribuée plus tard. Le bannissement s'applique aux deux couches ci-dessus à la fois.
Noyau réseau durci contre les floods SYN
Le système d'exploitation du relais est réglé spécifiquement contre les tentatives de connexion massives et non finalisées (SYN cookies, table de connexions agrandie) — moins de ressources gaspillées par connexion suspecte, plus de marge pour absorber un pic.
Trois réflexes, dans le bon ordre.
Ne redémarrez pas le serveur
Un redémarrage ne fait rien contre un flood réseau et coupe tous les joueurs légitimes encore connectés pour rien.
Confirmez que c'est réel
Vérifiez le CPU/RAM du serveur et le débit réseau avant de conclure — un problème de script mal optimisé ressemble parfois à du lag, pas à un DDoS.
Masquez, puis seulement changez d'IP
Si votre IP a fuité, une nouvelle IP sans protection devant repart du même problème. Mettez le masquage en place d'abord.
Quelques minutes, pas de migration.
Créez un compte, ajoutez votre serveur : une adresse de connexion et un bloc server.cfg sont générés automatiquement. Collez-le, redémarrez FXServer, partagez la nouvelle adresse à vos joueurs.
Questions fréquentes
Comment savoir si c'est vraiment une attaque et pas juste du lag ?
Un vrai DDoS touche tout le monde en même temps, de façon abrupte — timeouts simultanés, CPU/RAM du serveur qui restent normaux pendant que plus personne n'arrive à se connecter. Du lag classique dégrade progressivement, et touche généralement certains joueurs plus que d'autres selon leur connexion.
Mon petit serveur RP risque-t-il vraiment d'être visé ?
Oui. La majorité des attaques sur des serveurs FiveM ne viennent pas de concurrents organisés mais de joueurs bannis ou en conflit avec un autre, qui louent un booter pour quelques dollars. La taille du serveur n'entre pas en compte.
Est-ce que je dois changer d'hébergeur pour utiliser Vanta Shield ?
Non. Vanta se place devant votre serveur existant, peu importe l'hébergeur — vous ajoutez un bloc dans server.cfg, vous redémarrez, c'est tout.
Cloudflare ne suffit pas ?
Cloudflare (plan gratuit) protège le trafic HTTP/HTTPS. Le jeu FiveM passe par un port UDP dédié que Cloudflare ne filtre pas sans un plan payant spécifique (Spectrum), qui reste généraliste et ne connaît pas le protocole FiveM/RedM.
Une ressource Lua anti-DDoS ne fait pas la même chose ?
Une ressource Lua s'exécute à l'intérieur de FXServer — elle ne voit une connexion qu'après qu'elle a déjà consommé de la bande passante et du CPU. Elle peut aider à filtrer des comportements suspects une fois connecté, mais ne peut rien contre un flood volumétrique qui sature le lien avant même d'arriver au jeu.
Est-ce que ça fonctionne avec txAdmin ?
Le port de jeu passe par le relais et bénéficie du filtrage. Le port txAdmin peut être exposé séparément via un sous-domaine dédié pour l'accès web — sa protection réseau complète est en cours d'extension, contactez-nous pour le statut actuel sur votre configuration.
Mon adresse IP peut-elle fuiter autrement ?
Oui — un ancien admin, un joueur qui inspecte le trafic, un site de scan communautaire. Une fois l'IP connue, toute protection basée uniquement sur le nom de domaine ou la liste publique est contournée. C'est pourquoi le filtrage doit se faire au niveau réseau, pas seulement à la configuration.
Combien de temps prend la mise en place ?
Quelques minutes. Vous créez un compte, on génère votre configuration et votre adresse de connexion, vous collez le bloc en haut de server.cfg et vous redémarrez FXServer.
D'autres questions ? Consultez la FAQ générale ou rejoignez notre Discord.