Mon serveur FiveM est-il victime d’une attaque DDoS ? Comment le savoir
Mis à jour le
Vérifié le 7 octobre 2026 sur FXServer build 35245 (recommandé), 37150 (dernière) et txAdmin v8.1.1. Sources
Les joueurs passent en timeout, la console se remplit d’avertissements ou le serveur disparaît de la liste, et le premier mot qui vient à l’esprit est DDoS. Le soupçon est légitime, mais difficile à trancher à l’instinct : un flot de paquets, un script qui fige le serveur et une règle de pare-feu oubliée peuvent se ressembler du côté du joueur.
Cette page est un arbre de décision : trois mesures, un tableau qui mène de chaque message à son guide, et ce qu’il faut sauvegarder avant de redémarrer. Dans les fils de forum que nous avons lus, les propriétaires attribuent les blocages à des scripts, à des événements réseau trop volumineux, à la machine et à sa configuration ; c’est une lecture éditoriale d’une poignée de fils, pas une statistique, et nous ne connaissons aucun jeu de données public sur les causes de panne FiveM. Une attaque est une possibilité documentée, et sa preuve se trouve hors de votre machine.
Les symptômes seuls ne prouvent pas un DDoS. Il faut une preuve extérieure à la machine : le tableau de bord ou l’alerte de votre hébergeur, ou un graphique de trafic entrant.
- Le trafic entrant a-t-il augmenté chez l’hébergeur ou sur l’interface réseau ?
- Le processus serveur se bloque-t-il ou affiche-t-il des hitch warnings ?
- Est-ce un seul joueur, ou tout le monde en même temps ?
Trois questions pour classer une panne
Posez-les dans cet ordre, avant de changer un réglage ou de redémarrer. Chacune écarte ou confirme une couche.
Le trafic entrant a-t-il augmenté chez l’hébergeur ?
Ouvrez le tableau de bord de votre hébergeur à la minute où le problème a commencé. Chez OVHcloud, Network > Network Security Dashboard liste les attaques détectées par son système Anti-DDoS (« Heure de détection », « Heure de fin », « IP de destination », « Vecteurs d’attaque ») dans l’onglet « Journal du Centre de nettoyage », et OVHcloud vous envoie un e-mail quand il réachemine le trafic ; les autres hébergeurs diffèrent : interrogez le vôtre. Sur une machine Linux,
sar -n DEV 1 10affiche les paquets et les kibioctets reçus par seconde (rxpck/s,rxkB/s) ; comparez avec un jour calme (le guide sur l’alerte de l’hébergeur, plus bas, donne l’équivalent Windows). Un trafic entrant très au-dessus de la normale, à la minute où les joueurs ont décroché, rend une attaque probable ; une hausse légitime donnerait la même mesure, demandez donc confirmation à votre hébergeur. Un journal OVHcloud vide signifie qu’il n’a vu aucune attaque suspecte : cela plaide contre un flood sans l’exclure, car OVHcloud précise que des attaques très spécifiques peuvent échapper à la détection automatique. Une mesure calme sur la machine ne met pas non plus le chemin hors de cause : des paquets perdus sur le lien en amont, ou par une null route, n’y apparaissent jamais (notre lecture). Un flood arrive en trafic entrant ; un fort trafic sortant après un redémarrage correspond plus probablement à des joueurs qui téléchargent (notre lecture).Le processus serveur se bloque-t-il ou affiche-t-il des hitch warnings ?
Lisez la console autour de cette minute.
server thread hitch warning: timer interval of N millisecondssignifie que deux ticks de la boucle principale ont été espacés de N millisecondes ; l’avertissement s’affiche quand N dépasse 150 (network threadau-delà de 150,sync threadau-delà de 100). Un N élevé veut dire que la boucle a pris du retard, pas que le réseau est lent. Après plus de 45 secondes sans signe de vie, le watchdog affiche une ligne commeLoop svMain seems hung! (last checkin N seconds ago). Des avertissements placent le problème dans le processus ou sur la machine ; une attaque n’apparaît ici que si assez de son trafic atteint la machine pour ralentir le processus (notre lecture). Sans avertissement alors que les joueurs ne peuvent pas se connecter, le problème est plutôt ailleurs que dans un processus saturé : processus arrêté, pare-feu ou chemin entre les joueurs et la machine. txAdmin ne tranche pas : son health check est une requête que la machine s’envoie à elle-même, normalement vers127.0.0.1, donc un serveur affiché en ligne dans txAdmin ne dit rien du chemin extérieur.Est-ce un seul joueur ou tout le monde ?
Comptez les joueurs touchés à la même minute et demandez-leur où ils se trouvent. Un seul joueur, un seul fournisseur d’accès ou une seule région : cela désigne d’abord leur route, leur VPN ou leur installation. Tout le monde à la fois désigne quelque chose de partagé : le processus, la machine ou le chemin qui y mène, là où une attaque se verrait aussi. Demandez à deux ou trois d’entre eux de lancer
cl_drawperf truedans la console F8 et de lire Ping et PL (perte de paquets) à la même minute.
Pour commencer : ce que vous voyez, et le guide à ouvrir
Le client récupère /info.json, puis affiche Handshaking with server..., Downloading content, Fetching info from server... (UDP) et Connecting to server... (ENet). Le message à l’écran oriente vers l’étape en échec : choisissez la ligne qui le cite.
Ce que vous voyez
Les joueurs voient
Failed to get info from server (tried 3 times)Couche la plus probable
Le chemin UDP : les étapes HTTP sont déjà passées
Guide
Ce que vous voyez
Les joueurs voient
Failed to connect to server after 3 attempts., ou restent surHandshaking with server...Couche la plus probable
La connexion ENet, ou le handshake HTTP
Guide
Ce que vous voyez
Beaucoup de joueurs voient
Client -> server connection timed outen même temps, ou la console afficheServer->client connection timed out. Pending commands: NCouche la plus probable
Environ 30 secondes sans réponse (un serveur bloqué, ou le chemin), un plantage ou un redémarrage, ou des commandes en attente pour le joueur
Guide
Ce que vous voyez
La console affiche
server thread hitch warning,network thread hitch warningousync thread hitch warningCouche la plus probable
Le processus serveur : scripts, CPU, événements réseau
Guide
Ce que vous voyez
La console affiche
Server list query returned an error, ou le serveur est absent de la listeCouche la plus probable
Le listing, ou l’accessibilité
Guide
Ce que vous voyez
Le ping et la perte de paquets sont élevés pour tout le monde, sans hitch warning ni plantage
Couche la plus probable
Le tick du serveur, les événements réseau ou le chemin
Ce que vous voyez
Un seul joueur, un seul fournisseur d’accès ou une seule région est touché
Couche la plus probable
Leur route, leur VPN ou leur installation, plus probablement que votre serveur
Ce que vous voyez
Rejoindre le serveur est lent, ou les joueurs restent sur
Downloading contentCouche la plus probable
La bande passante sortante de votre serveur, ou le côté joueur
Ce que vous voyez
txAdmin affiche
Server is not responding, annonce un blocage partiel, ou le panel ne s’ouvre pasCouche la plus probable
Un serveur bloqué, ou le port 40120
Ce que vous voyez
Votre hébergeur signale une attaque ou une mitigation, ou le graphique entrant montre un mur de trafic
Couche la plus probable
Probablement une attaque : faites confirmer la plage horaire et l’IP par l’hébergeur
Ce que vous voyez
Quelqu’un a envoyé une menace, ou vous vous demandez si votre IP est exposée
Couche la plus probable
Une exposition, pas encore une attaque
Quoi relever avant de redémarrer quoi que ce soit
Un redémarrage met fin au processus que vous diagnostiquez et ne change rien au trafic dirigé vers votre adresse. Copiez d’abord ceci.
- La plage horaire : début, fin et nombre approximatif de joueurs déconnectés, dans un fuseau horaire que vous précisez.
- Les lignes de la console pour cette plage, en texte : les hitch warnings, toute ligne
Loop svMain seems hung!et les raisons de déconnexion,Server->client connection timed out. Last seen N msec ago.ouServer->client connection timed out. Pending commands: N.avec saCommand list:des commandes en file d’attente et de leur taille. - La ligne de redémarrage de txAdmin. Son moniteur écrit une ligne qui commence par
Restarting server: Server is not respondingdans sa console et ses journaux, puis des lignes commeHealthChecks failing for the past <t>.ouStopped receiving HeartBeats <t> ago. - La ligne
Timeout infode la fenêtre de timeout de deux ou trois joueurs touchés. - Ce que montre le tableau de bord de l’hébergeur sur la plage (capture d’écran ou export) et tout e-mail qu’il a envoyé. La conservation est limitée (la documentation d’OVHcloud indique deux mois pour le graphique de trafic) : sauvegardez ces données dès maintenant.
- Une mesure sur la machine pendant que cela se produit, par exemple
sar -n DEV 1 10sous Linux, et la même mesure un jour calme pour avoir une référence.
Les guides par symptôme
Chaque guide s’ouvre sur un verdict : est-ce un DDoS ou non ? Il dit aussi quand FiveShield n’aide pas.
- Peut-être un DDoS : les preuves tranchent
Connection timed out
Beaucoup de joueurs sont déconnectés en même temps avec
Client -> server connection timed out.FiveShield n’aide que si une attaque est confirmée - Ne prouve pas un DDoS à lui seul
Thread hitch warning
La console affiche
server thread hitch warningounetwork thread hitch warning.FiveShield ne règle pas ce problème - Cherchez d’abord une autre cause
Failed to get info
Les joueurs voient
Failed to get info from server (tried 3 times)et ne peuvent pas se connecter.FiveShield n’aide que si une attaque est confirmée - Ne prouve pas un DDoS à lui seul
Absent de la liste
Le serveur tourne et accepte les connexions directes, mais il est absent de la liste ou s’affiche en privé.
FiveShield ne règle pas ce problème - Peut-être un DDoS : les preuves tranchent
Rubber banding, ping élevé
Tout le monde subit du rubber banding, ou un ping élevé avec de la perte de paquets, sans aucun plantage.
FiveShield n’aide que si une attaque est confirmée - Ne prouve pas un DDoS à lui seul
Bloqué au téléchargement
Rejoindre le serveur prend des minutes, ou les joueurs restent sur
Downloading content.FiveShield aide pour une partie du problème - Cherchez d’abord une autre cause
txAdmin ne répond pas
txAdmin redémarre le serveur avec
Server is not responding, ou le panel ne s’ouvre pas.FiveShield aide pour une partie du problème - Pointe vers un DDoS une fois confirmé
Pic de trafic ou alerte
Votre hébergeur a signalé une attaque, ou votre graphique montre soudain un mur de paquets entrants.
La protection est la bonne étape suivante - Une menace n’est pas une attaque
Menace DDoS, IP exposée
Quelqu’un a menacé de vous mettre hors ligne, ou vous voulez savoir si votre IP est publique.
FiveShield aide pour une partie du problème
Quand c’est un DDoS
Un DDoS, c’est du trafic, et sa preuve est donc du trafic : un événement signalé par l’hébergeur sur votre IP, ou un graphique entrant très au-dessus de la normale, à la minute où les joueurs ont décroché. La console peut rester calme, car le trafic perdu sur le lien ou filtré par l’hébergeur ne devient jamais du travail pour le processus (notre lecture ; la documentation ne le dit pas). OVHcloud n’affiche pas les adresses sources des événements détectés parce qu’elles sont généralement usurpées : ne perdez pas de temps à les bannir.
Les hébergeurs réagissent différemment : OVHcloud décrit un réacheminement du trafic par ses centres de nettoyage, avec un e-mail d’alerte ; TransIP indique, pour ses VPS, qu’il met en null route une adresse visée par une attaque de plusieurs Gbit/s, qui devient alors injoignable de l’extérieur ; Leaseweb indique, pour la colocation, que sa protection permanente agit par nulling et scrubbing et ne peut pas être désactivée, et qu’une null route arrête le trafic d’une IP au niveau de son routeur central. Demandez au vôtre : mon IP est-elle filtrée ou en null route, et depuis quand ?
Dès que les preuves désignent une attaque : notez la plage horaire, sauvegardez le tableau de bord et vos mesures, donnez à l’hébergeur la plage, l’IP et le port, sans redémarrer à répétition ni annoncer de nouvelle adresse.
Quand la protection n’aidera pas
Un proxy ou un service de filtrage agit sur le trafic avant qu’il n’arrive à votre serveur. Il n’accélère pas un script, ne réduit pas un événement réseau, n’ajoute pas de CPU, n’ouvre pas le port du jeu dans un pare-feu et ne corrige pas un réglage de listing. Si les trois questions désignent le processus ou la machine, la solution est là, et certains guides disent franchement, dans leur encadré de verdict, que FiveShield n’aide pas.
Un proxy mal configuré peut aussi provoquer les erreurs que vous traquez : la documentation des proxys indique qu’un endpoint serveur placé derrière un proxy a besoin d’un proxy TCP/UDP brut sur des ports identiques ; selon notre lecture, un proxy qui ne transmet pas l’UDP laisserait donc sans réponse la requête d’information UDP du client, ce qui se termine par Failed to get info from server (tried 3 times).
Questions fréquentes
Comment distinguer un DDoS d’un hitch de thread ?
Un hitch se mesure dans le processus : la console affiche server thread hitch warning: timer interval of N milliseconds quand deux ticks de la boucle principale ont été espacés de plus de 150 millisecondes. Un DDoS se mesure à l’extérieur : une alerte de l’hébergeur, une entrée de l’onglet « Journal du Centre de nettoyage » ou un graphique entrant très au-dessus de la normale. Des hitch warnings avec un graphique d’hébergeur plat orientent vers un blocage ; une alerte de l’hébergeur avec une console calme est compatible avec du trafic perdu avant d’atteindre le processus (notre lecture), et ce n’est pas forcément ce qui a gêné vos joueurs. Avec les deux, regardez lequel a commencé en premier.
Les hitch warnings sont-ils toujours le signe d’un DDoS ?
Non. FXServer les affiche quand l’une de ses boucles prend du retard, et le code source n’enregistre pas pourquoi. Dans les fils de forum que nous avons lus, les propriétaires les attribuent à des scripts, à de gros événements réseau, à un serveur trop lent ou à un CPU de VPS défaillant. Un flood n’y contribue que si son trafic atteint votre machine (notre lecture) ; le graphique de votre hébergeur montre si le trafic entrant a augmenté.
Pourquoi tout le monde passe-t-il en timeout au même moment ?
Le code source fixe un délai maximal (hard timeout) de 30 secondes côté client comme côté serveur : lorsque la cause est un serveur bloqué ou un chemin coupé, un Client -> server connection timed out massif survient donc après environ une demi-minute sans réponse pour beaucoup de joueurs à la fois ; selon notre lecture, un blocage plus court se voit comme du lag et des pertes. Le client peut aussi afficher cette fenêtre lorsque sa connexion au serveur se termine pour une autre raison ; selon notre lecture, un plantage ou un redémarrage peut donc passer pour un timeout : vérifiez les raisons de redémarrage de txAdmin. Pending commands: N remplace la raison simple Last seen seulement si le joueur avait été vu moins de 1,5 seconde avant la déconnexion et que des commandes fiables (reliable) attendaient encore un accusé de réception ; sa Command list: nomme les plus volumineuses (sept au plus) avec leur taille, ce qui désigne des événements trop volumineux ou en boucle (notre lecture).
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.
- FiveM docs: proxy setup and the connection process (s’ouvre dans un nouvel onglet)
- FiveM docs: server issues (server not in the list, or marked private) (s’ouvre dans un nouvel onglet)
- FiveM docs: client console commands (s’ouvre dans un nouvel onglet)
- FXServer source: NetLibrary.cpp (connection stages) (s’ouvre dans un nouvel onglet)
- FXServer source: NetLibraryImplV2.cpp (client timeout) (s’ouvre dans un nouvel onglet)
- FXServer source: GameServerNet.ENet.cpp (server timeout) (s’ouvre dans un nouvel onglet)
- FXServer source: GameServer.cpp (hitch warnings, drops, list errors) (s’ouvre dans un nouvel onglet)
- FXServer source: ServerWatchdog.cpp (hung loops) (s’ouvre dans un nouvel onglet)
- txAdmin source: FxMonitor (health check, restart lines) (s’ouvre dans un nouvel onglet)
- txAdmin source: fxsConfigHelper.ts (health check address) (s’ouvre dans un nouvel onglet)
- txAdmin docs: env-config.md (default panel port 40120) (s’ouvre dans un nouvel onglet)
- OVHcloud docs: Network Security Dashboard (s’ouvre dans un nouvel onglet)
- Leaseweb knowledge base: nulling, scrubbing and null routing (colocation) (s’ouvre dans un nouvel onglet)
- TransIP knowledge base: DDoS attacks and null routes (s’ouvre dans un nouvel onglet)
- Linux man page: sar(1) (s’ouvre dans un nouvel onglet)
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.