Pic de trafic DDoS ou alerte de l’hébergeur sur FiveM : comment le confirmer et que faire

Mis à jour le

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

VerdictPointe vers un DDoS une fois confirmé

Cela oriente vers un DDoS quand votre hébergeur a signalé une attaque ou que votre graphique montre un mur de trafic entrant, mais confirmez le sens, la forme et l’horaire avant d’agir.

La protection est la bonne étape suivante

FiveShield aide une fois l’attaque confirmée : les joueurs se connectent à un proxy et non à votre machine, ce qui ne fonctionne que si l’adresse d’origine change et reste privée.

Si votre hébergeur a signalé une attaque sur votre IP, ou si votre graphique entrant montre un mur de paquets qui commence et s’arrête avec les problèmes de vos joueurs, traitez-le comme un DDoS : c’est ici la lecture la plus probable. Trois vérifications permettent de trancher. Le sens : le trafic en trop est entrant. La forme : en général de nombreuses sources, bien au-delà de vos joueurs. L’horaire : la fenêtre donnée par l’hébergeur couvre les minutes où vos joueurs ont eu des problèmes.

Sauvegardez d’abord les preuves : l’e-mail de l’hébergeur, un export de son tableau de bord et sar -n DEV 1 10. Ne redémarrez pas à répétition, n’annoncez pas de nouvelle IP et ne cherchez pas à bannir les sources, le plus souvent usurpées.

Ce n’est pas une attaque quand la hausse est uniquement sortante et démarre à votre redémarrage, ou quand les sources sont vos propres joueurs. Un pic sans trace chez l’hébergeur reste non prouvé, pas écarté. Si l’hébergeur a mis votre IP en null route, plus rien ne vous parvient : la cause 5 explique comment le savoir.

Ce qu’une alerte de l’hébergeur ou un pic vous apprend

Ce symptôme n’affiche aucun message d’erreur : il arrive sous la forme d’une alerte de l’hébergeur ou d’une courbe. La documentation d’OVHcloud explique que, dès qu’une attaque est détectée contre une IP de votre service, un e-mail vous prévient que le trafic a été réacheminé vers l’infrastructure Anti-DDoS, et sa FAQ Anti-DDoS ajoute que sous mitigation « filtering may occur ». C’est le verdict d’un détecteur automatique : une preuve forte venue de l’extérieur de votre machine, à recouper quand même.

À vérifier en premier (deux minutes)

Quatre questions, dans l’ordre ; chacune mène à une cause ou à un guide.

  1. Existe-t-il une trace venue de l’extérieur de votre machine ?

    Regardez l’e-mail et le panel de votre hébergeur. OVHcloud : l’e-mail de réacheminement, puis Network > Network Security Dashboard (onglet « Journal du Centre de nettoyage », et état de Mitigation en mode avancé). Portail colocation de Leaseweb : une colonne Nulled. Autres hébergeurs : interrogez le support.

  2. Dans quel sens va le trafic en trop ?

    rxpck/s et rxkB/s sont ce qui arrive, txpck/s et txkB/s ce qui part (rxkB/s est en kibioctets : multipliez par 0,008 environ pour des mégabits). Sous Windows, utilisez la ligne Get-Counter plus bas. Comparez avec un jour calme.

    sar -n DEV 1 10

  3. Qui l’envoie ?

    La capture peut exiger les droits root. Lisez la colonne des sources ; les horodatages donnent le débit. status dans la console liste les endpoints de vos joueurs. Ne bannissez rien : OVHcloud indique que les sources sont le plus souvent usurpées.

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

  4. Le serveur répond-il depuis l’extérieur alors que le processus tourne ?

    Depuis un autre réseau que le vôtre, ouvrez http://ip:port/info.json et lancez connect IP:Port dans la console F8 d’un joueur. Ne vous fiez pas à txAdmin : avec un endpoint 0.0.0.0 ou [::], son health check interroge /dynamic.json sur 127.0.0.1, donc il peut afficher le serveur en ligne alors que personne ne l’atteint.

Causes, classées

L’ordre suppose que vous arrivez avec une alerte de l’hébergeur ou une hausse entrante, d’où l’attaque en premier ; avec une simple bosse sortante, commencez à la cause 2.

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. Une vraie attaque : un mur de paquets entrants depuis de nombreuses sources

    Notre déductionLe cas du DDoS

    Le trafic d’attaque atteint votre IP depuis de nombreuses sources, à un débit que l’hébergeur détecte. Le reste est notre déduction à partir du sens : le trafic d’attaque arrive, donc les compteurs de réception montent, alors qu’une vague de reconnexions part. OVHcloud n’affiche pas les sources, car elles sont « usually spoofed ».

    Comment le confirmer

    Commencez par la trace de l’hébergeur. Confirmez ensuite le sens avec sar -n DEV 1 10 et la forme avec un échantillon tcpdump. Si la trace, le sens et l’horaire concordent, traitez cela comme une attaque.

    Que faire

    Sauvegardez les preuves, puis ouvrez un ticket avec horodatages. Pas de redémarrages répétés, de nouvelle IP annoncée ni de bannissement des sources.

  2. Une vague de reconnexions après un redémarrage ou une mise à jour : téléchargements sortants

    Notre déduction

    Quand beaucoup de joueurs se reconnectent ensemble, surtout après une mise à jour qui a changé des ressources, leurs clients récupèrent des fichiers via GET /files/* (ou un serveur de fichiers déporté). Ces octets sortent de votre machine : le sortant monte, l’entrant monte bien moins. Redémarrer encore refait la vague.

    Comment le confirmer

    Le sortant (txpck/s, txkB/s) monte juste après l’heure du redémarrage dans votre console ou txAdmin, puis retombe. L’entrant monte bien moins que le sortant et l’hébergeur n’a aucune trace.

    Que faire

    Arrêtez de redémarrer. Si chaque mise à jour provoque cela, soulagez votre bande passante sortante : le cookbook de docs.fivem.net décrit un proxy de cache pour le serveur de fichiers (fileserver_add).

  3. Un trafic connu : un événement très fréquenté, ou une autre tâche sur la même machine

    Notre déduction

    Plus de joueurs, c’est plus de trafic dans les deux sens, et une salle comble peut égaler une attaque sans source hostile. Sauvegardes, mises à jour système, site web ou serveur vocal ajoutent du trafic sur la même adresse.

    Comment le confirmer

    Comparez les sources de tcpdump aux endpoints affichés par status (derrière un proxy, ce peuvent être les adresses du proxy). Lancez iftop -n -N -P -i <iface>, qui liste tous les ports, et cherchez des ports autres que 30120.

    Que faire

    Rien à combattre. Gardez le pic comme nouvelle référence ; déplacez toute tâche vers une autre machine ou IP, ou hors des heures de pointe.

  4. Une mitigation de l’hébergeur en mode forcé qui filtre de vrais joueurs

    Documenté

    OVHcloud affiche un état de Mitigation par IP : Automatic, où le centre de nettoyage « reroutes traffic for deeper analysis when needed », et Forced, où il est en train d’agir (« taking action »). Sous mitigation, « filtering may occur », et son guide du Game firewall invite les propriétaires de gros services qui constatent encore des « false positives » à contacter le support. De vrais joueurs peuvent être pris dans le filtre, ce qui ressemble à l’attaque elle-même.

    Comment le confirmer

    Dans le Network Security Dashboard, activez le mode avancé et lisez l’état de Mitigation ; comparez « Heure de détection » et « Heure de fin » (onglet « Journal du Centre de nettoyage ») avec les minutes où de vrais joueurs étaient refusés.

    Que faire

    Ouvrez un ticket avec les éléments listés dans la FAQ et précisez si du trafic légitime est rejeté.

  5. L’hébergeur a mis votre IP en null route : plus rien ne vous parvient

    Documenté

    Une null route fait rejeter par le réseau chaque paquet destiné à une adresse. TransIP écrit qu’il met automatiquement un VPS en nullroute quand il détecte un DDoS de plusieurs Gbit/s, et que l’adresse « will not be reachable from the outside » dans l’intervalle ; le portail colocation de Leaseweb laisse aussi le client mettre une IP en null route, pour un nombre d’heures ou jusqu’à ce qu’il la retire (« you remove it »). Les hébergeurs diffèrent. Une null route montre ce que l’hébergeur a fait, pas pourquoi.

    Comment le confirmer

    Le panel ou l’e-mail indique que l’adresse est en null route. Le processus répond en local, http://ip:port/info.json échoue depuis tous les réseaux extérieurs, et, les paquets étant rejetés en amont, sar -n DEV 1 10 devrait montrer un entrant proche de zéro, pas un mur.

    Que faire

    Demandez par écrit à l’hébergeur pourquoi, depuis quand, comment elle se termine et ce qui la lève. N’annoncez pas de nouvelle IP en attendant.

À quoi ressemble un DDoS ici

Une attaque laisse des traces hors de votre machine ; les causes ordinaires non.

À quoi ressemble un DDoS ici

  • Une trace venue de l’extérieur : un e-mail de l’hébergeur sur du trafic réacheminé, une ligne de l’onglet « Journal du Centre de nettoyage » (« Heure de détection », « Heure de fin », votre IP comme « IP de destination », « Vecteurs d’attaque »), un état de mitigation Forced, ou un indicateur Nulled.
  • Le sens : entrant. rxpck/s et rxkB/s montent en général, txpck/s ne suit pas.
  • La forme : en général de nombreuses sources, bien au-delà de vos joueurs. Regardez combien et à quel point elles sont dispersées, pas qui : les adresses sont le plus souvent usurpées.
  • L’horaire : la fenêtre de l’hébergeur couvre les minutes où vos joueurs ont eu des problèmes, et les raisons de déconnexion Server->client connection timed out. du journal de txAdmin s’y regroupent. Le hard timeout ENet est de 30 secondes des deux côtés : nous en déduisons qu’une perturbation plus courte cause du lag, pas un timeout de masse.

Preuves que vous pouvez recueillir

  • La trace propre à l’hébergeur

    Gardez l’e-mail avec son fuseau horaire et exportez le tableau de bord. Chez OVHcloud, la documentation garde les entrées du journal un an et le graphique deux mois ; sa FAQ commerciale annonce deux semaines pour le graphique : exportez vite.

  • Paquets et octets par seconde (Linux)

    Mesurez pendant l’événement et un jour calme. sar -n EDEV 1 10 ajoute rxdrop/s, les paquets rejetés faute de place dans les tampons.

    sar -n DEV 1 10

  • Paquets reçus par seconde (Windows)

    Même objectif ; utilisez Packets Sent/sec pour le sortant. Microsoft liste aussi Packets Received Discarded parmi ses compteurs de problèmes réseau.

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

  • Un échantillon de qui envoie

    La capture peut exiger les droits root. Chaque ligne porte un horodatage, d’où le nombre de paquets par seconde. Si rien n’apparaît pendant un événement signalé, l’attaque vise peut-être un autre port : retirez le filtre.

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

  • Une capture que votre hébergeur peut demander

    OVHcloud documente cette commande Linux pour les captures destinées au support, et renvoie les utilisateurs Windows vers Wireshark avec 100 000 paquets.

    tcpdump -w capture-ovh -c 100000 port not ssh

Ce qui n’y ressemble pas

  • Des hitch warnings, des timeouts ou un ping élevé, seuls : des scripts et un CPU faible les produisent aussi.
  • Une hausse uniquement sortante dès votre redémarrage : c’est une vague de reconnexions.
  • Des sources qui sont vos propres joueurs, ou une hausse qui suit leur nombre.
  • Un « Journal du Centre de nettoyage » vide pris pour preuve de calme : il signifie seulement que le détecteur n’a rien soupçonné, et selon OVHcloud, les attaques venues de son propre réseau relèvent de ses équipes de sécurité et « will not be reported by Anti-DDoS infrastructure systems ».

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

Le filtrage de votre hébergeur et un proxy n’ont pas le même rôle ; vos preuves disent lequel il vous faut.

La protection est la réponse quand

  • La trace, le sens, la forme et l’horaire concordent, et l’attaquant revient taper sur la même adresse d’origine.
  • L’adresse a été mise en null route ou vous avez dû la changer, et la nouvelle doit rester privée.
  • La protection de votre hébergeur est générique : OVHcloud décrit son Anti-DDoS comme surtout centré sur les couches 3 et 4, et son profil FiveM relève de Game DDoS Protection, réservé aux serveurs Bare Metal Game.

La protection n’est pas la réponse quand

  • Rien d’inhabituel n’arrive de l’extérieur : un proxy ne change rien à une vague de reconnexions, à une soirée chargée ou à une sauvegarde.
  • La panne est dans le serveur : hitch warnings, script bloqué, spam d’events.
  • Vous garderiez la même adresse d’origine : les paquets qui la visent ne passent pas par votre proxy.

Si l’attaque est confirmée

Protégez d’abord les preuves et l’adresse : pas de redémarrages répétés, pas de nouvelle IP annoncée, pas de bannissement des sources. Ouvrez un ticket avec horodatages, IP, port et, si on la demande, une capture.

Faites ensuite ce que votre hébergeur ne peut pas faire à votre place : placez un proxy devant le serveur, demandez à l’hébergeur une nouvelle IP d’origine, ne la publiez nulle part et ne laissez que le proxy y accéder. L’ordre compte : un proxy devant une adresse que l’attaquant connaît déjà laisse cette adresse sous le feu.

Vérifiez que rien d’autre ne révèle la nouvelle adresse : le listing cfx.re, d’anciens enregistrements DNS, un site web sur la même machine, une adresse codée en dur dans une ressource.

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.

Anti-DDoS FiveM : comment fonctionne FiveShield

Toujours bloqué ? Ce qu’il faut publier

Publiez des lignes et des heures, pas des impressions, et omettez les adresses IP complètes de vos joueurs.

  • La trace de l’hébergeur, mot pour mot : l’e-mail, ou la ligne du « Journal du Centre de nettoyage » et l’état de Mitigation.
  • La sortie de sar -n DEV 1 10 pendant l’événement et un jour calme (ou les lignes Get-Counter), et le nombre de sources distinctes de l’échantillon tcpdump.
  • Les lignes du journal txAdmin et de la console autour de l’événement, dont les raisons de déconnexion qui commencent par Server->client connection timed out., avec les horodatages.
  • Votre build FXServer, votre version de txAdmin, votre hébergeur et votre offre, et la présence d’un proxy devant.
  • Une chronologie dans un seul fuseau horaire : premier signalement d’un joueur, début et fin de l’hébergeur, première hausse entrante, chaque redémarrage.

Questions fréquentes

Dois-je redémarrer mon serveur pendant un DDoS ?

Pas à répétition. Le trafic visant votre adresse arrive que FXServer tourne ou non : un redémarrage ne l’arrête pas et ramène tous les joueurs d’un coup, d’où une vague de reconnexions (cause 2). Prenez d’abord les preuves ; un redémarrage unique pour débloquer un processus figé est une autre décision.

Comment lire le tableau de bord d’attaques de mon hébergeur ?

Chez OVHcloud, l’onglet « Journal du Centre de nettoyage » donne « Heure de détection », « Heure de fin », « IP de destination » et « Vecteurs d’attaque » ; Mitigation indique Automatic ou Forced ; le graphique montre en rouge le trafic rejeté et en vert le trafic propre. Les autres hébergeurs diffèrent.

Comment savoir si mon IP est en null route, et combien de temps cela dure-t-il ?

Votre hébergeur vous le dit (e-mail, indicateur du panel). De l’extérieur, le processus reste actif en local mais http://ip:port/info.json échoue depuis tous les réseaux et l’entrant tombe à presque rien. Personne ne peut annoncer une durée sans la politique de l’hébergeur : chez Leaseweb en colocation, une null route posée par vous dure les heures saisies ou jusqu’à son retrait ; pour celle de l’hébergeur, demandez par écrit.

Que mettre dans un ticket à mon hébergeur ?

OVHcloud demande, pour ajuster sa protection : le service hébergé, l’heure de début et de fin de l’attaque, les IP touchées, le protocole et le port, la taille du service, les autres services et ports, si du trafic légitime est rejeté, et si la connexion au serveur a été perdue. Envoyez la même chose à tout hébergeur.

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.