server thread hitch warning sur FiveM : causes et solutions

Mis à jour le

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

VerdictNe prouve pas un DDoS à lui seul

L’une des boucles du serveur a pris du retard ; les causes que rapportent les propriétaires sont les scripts, les événements réseau, le CPU ou l’hébergeur, et l’avertissement ne prouve pas une attaque à lui seul.

FiveShield ne règle pas ce problème

FiveShield ne règle pas l’avertissement lui-même : un proxy ne change rien à la vitesse d’exécution des threads de votre serveur.

Un hitch warning signale qu’une boucle du serveur a pris du retard. server thread hitch warning: timer interval of %d milliseconds s’affiche quand deux ticks de la boucle principale sont espacés de plus de 150 millisecondes (thread réseau : 150, thread de synchronisation : 100). Le nombre est cet écart sur votre machine, pas un ping, et il ne dit pas où le temps est passé.

Scripts lourds, gros événements réseau et CPU faible ou partagé sont les causes que rapportent les propriétaires ; la charge OneSync et un flood relèvent de notre raisonnement à partir du code. Le contrôle de deux minutes ci-dessous les départage ; le classement est éditorial, pas une statistique.

Ne suspectez un DDoS que si un élément extérieur à la machine, comme l’alerte d’attaque de votre hébergeur ou un graphique de trafic entrant, coïncide avec les minutes des avertissements. Un flood qui sature votre connexion est surtout éliminé en amont, avant d’atteindre votre machine : le serveur peut alors n’écrire que peu ou rien (notre raisonnement).

Messages que vous pouvez voir

  • server thread hitch warning: timer interval of %d milliseconds

    Console du serveur ; boucle principale, écart de plus de 150 ms

  • network thread hitch warning: timer interval of %d milliseconds

    Console du serveur ; boucle réseau, écart de plus de 150 ms

  • sync thread hitch warning: timer interval of %d milliseconds

    Console du serveur ; boucle de synchronisation, écart de plus de 100 ms

  • hitch warning: net frame time of %d milliseconds

    Console du serveur ; le thread réseau de repli, dès 150 ms

Ce que cela signifie vraiment

FXServer fait tourner trois boucles cadencées par un timer (GameServer.cpp). svMain, planifiée toutes les 50 millisecondes, exécute le cycle du serveur : commandes de console en attente, contrôle qui déconnecte les clients qui ne répondent plus, ticks de vos ressources (ServerResources.cpp) et d’autres tâches. svNetwork (toutes les 10 millisecondes) traite les paquets réseau et la file d’envoi. svSync (toutes les 8 millisecondes) met à jour l’état de jeu OneSync quand OneSync est actif (ServerGameState.cpp).

Chaque boucle retient l’instant où son tick précédent a commencé et écrit une ligne quand l’écart dépasse sa limite : 150 millisecondes pour svMain et svNetwork, 100 pour svSync. hitch warning: net frame time of %d milliseconds vient d’un thread réseau de repli, dès 150 ; la couche réseau des builds 35245 et 37150 ne l’utilise pas, vous y verriez donc plutôt la ligne network thread. Le nombre est l’écart mesuré : une boucle principale saine mesure environ 50 et n’écrit rien. Une ligne dit qu’autant de temps s’est écoulé entre deux ticks, jamais pourquoi.

Tout ce qui tourne sur une boucle en retard attend avec elle. Quelques centaines de millisecondes sont loin d’une déconnexion : la couche réseau du serveur applique un délai maximal de 30 secondes à une connexion silencieuse (GameServerNet.ENet.cpp), donc, selon notre lecture, les joueurs ressentent du lag ou du rubber banding, pas une déconnexion. Des propriétaires rapportent pourtant que beaucoup de joueurs sont déconnectés ensemble pendant que des avertissements network thread s’affichent ; le guide sur Connection timed out couvre ce cas. Un blocage de plusieurs dizaines de secondes a son propre message : après 45 secondes, le watchdog (ServerWatchdog.cpp) écrit Loop svMain seems hung! (last checkin %d seconds ago), répété avec STILL après 90, plus une ligne watchdog stack: qui nomme la ressource et le tick ou l’événement.

À vérifier en premier (deux minutes)

Cinq vérifications qui distinguent un problème de script d’un problème de machine, et l’un comme l’autre d’un problème de trafic.

  1. Quel thread a écrit la ligne ?

    Le mot avant thread hitch warning : server est la boucle principale, network la boucle des paquets, sync la boucle OneSync.

  2. Quand les lignes apparaissent-elles ?

    Comparez les horodatages avec votre journal de modifications.

  3. Enregistrer un profil pendant une rafale de lignes

    Attendez la fin de l’enregistrement, puis profiler view (sur un serveur, la commande affiche un lien à ouvrir dans Chrome) ou profiler saveJSON filename.json (à charger dans les DevTools de Chrome, onglet Performance). Le guide ne dit pas quels threads une capture couvre : un profil propre ne met hors de cause ni la boucle réseau ni la boucle de synchronisation.

    profiler record 500

  4. Toute la machine est-elle occupée, ou seulement FXServer ?

    Sous Linux, sar -u lit toute la machine : regardez %steal, le temps pendant lequel le CPU virtuel a attendu que l’hyperviseur serve un autre processeur virtuel. Une valeur qui grimpe pendant les rafales désigne l’hébergeur (notre lecture). Sous Windows, Get-Counter -Counter '\Process(*)\% Processor Time' liste l’usage CPU par processus (les noms de compteurs sont localisés sur un Windows non anglais ; Get-Counter -ListSet * affiche les vôtres).

    sar -u 1 10

  5. Des joueurs sont-ils déconnectés, et votre hébergeur signale-t-il quelque chose ?

    Demandez la minute exacte à deux joueurs et consultez le tableau de bord de votre hébergeur.

Causes, classées

Commencez par la fiche que désignent vos vérifications. La dernière exige des preuves extérieures à la machine.

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 ressource lourde ou en boucle sur le thread principal

    Documenté

    La boucle principale exécute les ticks de vos ressources dans chaque cycle (GameServer.cpp, ServerResources.cpp) ; une ressource trop gourmande dans son tick étire le cycle au-delà de 150 millisecondes et tout le reste de cette boucle attend. Le guide du profiler montre un script retrouvé par fichier et ligne. Sur le forum, les réponses incriminent souvent d’abord un script précis.

    Comment le confirmer

    Profilez une rafale (profiler record 500, puis profiler view) : survoler un événement du tick de ressource affiche durée, fichier et ligne. Si les lignes cessent quand vous arrêtez cette ressource sur un serveur de test, c’est confirmé.

    Que faire

    Corrigez ou remplacez la ressource : faites attendre les boucles entre deux passages, ne parcourez plus tous les joueurs ou entités à chaque cycle, mettez les résultats en cache, sortez le travail lourd du tick.

  2. Démarrer ou redémarrer des ressources avec des joueurs connectés

    Notre déduction

    Le cycle principal exécute aussi les commandes de console en attente (GameServer.cpp) : démarrer une grosse ressource se fait donc dans un cycle et peut retarder le tick suivant. Notre raisonnement ; la documentation ne décrit pas le coût d’un démarrage.

    Comment le confirmer

    Rapprochez les horodatages des moments où vous avez lancé start, restart ou ensure. Une rafale au démarrage du serveur relève du même effet.

    Que faire

    Redémarrez les ressources lourdes hors des heures de pointe, en un seul lot planifié.

  3. Événements réseau volumineux ou trop fréquents, sur le thread réseau

    Retours de propriétaires

    La boucle réseau traite les paquets échangés avec les joueurs (GameServer.cpp). La documentation prévient qu’un gros TriggerClientEvent bloque le canal réseau du client et peut finir en timeout, et recommande les événements latents pour les grosses charges. Des propriétaires rapportent des avertissements du thread réseau, avec de nombreux joueurs déconnectés ensemble, liés à des scripts qui envoient des événements à tous les joueurs (-1) en boucle ou en une grosse synchronisation, même sous forme d’événements latents ; aucune taille critique n’est documentée.

    Comment le confirmer

    Sur un client en mode développeur, neteventlog true liste les événements avec sens, nom et taille (les commandes développeur exigent +set moo 31337 ou un canal de mise à jour hors production). La raison de déconnexion Server->client connection timed out. Pending commands: %d. se poursuit par un Command list: (événements en file et tailles).

    Que faire

    Les événements latents sont la voie documentée pour les grosses charges (TriggerLatentClientEvent, TriggerLatentServerEvent), avec un bps modeste : il s’applique par destinataire, donc envoyer à -1 coûte bps fois le nombre de joueurs chaque seconde, et vers 10 000 000 et plus il peut causer ses propres problèmes. N’envoyez les événements qu’aux joueurs concernés, et pas en boucle serrée.

  4. Charge d’entités OneSync, sur le thread de synchronisation

    Notre déduction

    Avec OneSync, la boucle de synchronisation met à jour l’état de jeu (ServerGameState.cpp). Nous déduisons que davantage d’entités et de joueurs allongent chaque tick et peuvent donc mettre la boucle en retard ; la documentation ne donne aucune limite.

    Comment le confirmer

    Les lignes sont des sync thread hitch warning, onesync vaut on ou legacy, et elles augmentent avec les joueurs, les véhicules ou les maps riches en entités. Avec onesync off, le tick de synchronisation se termine aussitôt : ces lignes viendraient d’ailleurs.

    Que faire

    Un réglage à la fois. Préférez onesync on à legacy si vos scripts le permettent (déconseillé pour les performances selon la documentation), gardez onesync_distanceCulling activé et essayez onesync_distanceCullVehicles true (false par défaut ; documenté comme pouvant améliorer les performances en réduisant la fréquence de synchronisation des véhicules).

  5. Une machine faible, survendue ou partagée, ou une tâche planifiée

    Retours de propriétaires

    Si le CPU virtuel attend que l’hyperviseur serve une autre machine, ou si un autre programme prend le CPU, les timers se déclenchent en retard et la boucle alerte même avec des scripts sains. Des propriétaires rapportent une panne CPU d’un VPS réparée par l’hébergeur, et un cas résolu en déplaçant le serveur vocal vers un hôte dédié ; une sauvegarde ou une base de données qui partage le CPU relève de notre raisonnement.

    Comment le confirmer

    Lancez sar -u 1 10 pendant une rafale et pendant une minute calme : un %steal qui grimpe pendant les rafales désigne l’hébergeur. Comparez les heures des lignes avec les tâches cron, sauvegardes et autres services. Sous Windows, comparez les compteurs par processus de l’étape sur le CPU.

    Que faire

    Envoyez à votre hébergeur les horodatages (et la sortie de sar sous Linux), éloignez les autres services et les tâches planifiées, ou passez à des cœurs dédiés.

  6. Un flood qui atteint la machine et qu’il faut traiter

    Notre déductionLe cas du DDoS

    Un flood ne peut ralentir une boucle qu’en consommant quelque chose sur votre machine : le processus lit ce qui arrive et répond aux requêtes HTTP et aux handshakes, et traiter des paquets coûte aussi du temps CPU. La documentation de FiveM décrit des limiteurs à jetons pour les endpoints HTTP et les handshakes (comme http_info et http_players, 4 jetons par seconde, burst de 10), sans chiffre sur le trafic qui met une boucle en retard, et elle ne dit pas si un flood provoque ces lignes. Un flood qui sature votre connexion est surtout éliminé en amont, avant d’atteindre votre machine (notre raisonnement).

    Comment le confirmer

    Cherchez à l’extérieur de la machine, aux mêmes minutes : journal ou alerte d’attaque de votre hébergeur, paquets entrants par seconde, paquets capturés venant de sources dispersées (commandes ci-dessous). Rien d’extérieur ne concorde : ce n’est pas la cause.

    Que faire

    Si les preuves sont là, demandez à votre hébergeur ce qu’il filtre, horodatages à l’appui. Contre les floods HTTP passant par des proxys, il y a sv_requestParanoia (0 à 3, endpoints HTTP uniquement), traité dans l’article sur le Layer 7 ci-dessous. Les sources d’une attaque sont généralement usurpées (guide d’OVHcloud) : bannir les adresses que vous voyez a peu de chances d’aider.

À quoi ressemble un DDoS ici

Un hitch warning est un symptôme sur votre machine : il ne désigne une attaque que si un élément extérieur concorde.

À quoi ressemble un DDoS ici

  • Les lignes démarrent dans une fenêtre d’attaque signalée par votre hébergeur, ou le trafic entrant monte sur son graphique aux mêmes minutes, et les deux cessent ensemble.
  • Les paquets reçus par seconde bondissent à ces minutes par rapport à un jour calme, et une capture du port de jeu montre de nombreuses sources dispersées, bien au-delà de vos joueurs.

Preuves que vous pouvez recueillir

  • Le relevé de votre hébergeur

    Chez OVHcloud, ouvrez Network > Network Security Dashboard : l’onglet « Journal du Centre de nettoyage » affiche « Heure de détection », « Heure de fin », « IP de destination » et « Vecteurs d’attaque ». OVHcloud envoie un e-mail quand le trafic est réacheminé et indique qu’un journal vide signifie qu’aucune attaque suspectée n’a visé vos adresses IP publiques, mais son guide précise aussi que certaines attaques sont trop spécifiques pour être détectées et nettoyées automatiquement. Les entrées sont conservées un an, les graphiques de trafic deux mois. Ailleurs, demandez au support le journal d’attaque pour ces minutes exactes.

  • Paquets reçus par seconde (Linux)

    Relevez-les un jour calme et pendant une rafale : rxpck/s est le nombre de paquets reçus par seconde. Un bond aux minutes des avertissements justifie d’interroger votre hébergeur. Une courbe plate signifie qu’aucun flood n’a atteint cette machine, mais le trafic éliminé en amont n’y apparaît pas : consultez aussi le graphique de votre hébergeur.

    sar -n DEV 1 10

  • Paquets reçus par seconde (Windows)

    La même comparaison dans PowerShell, un jour calme contre une rafale ; Ctrl+C pour arrêter. Les noms de compteurs sont localisés : sur un Windows non anglais, Get-Counter -ListSet * affiche les vôtres.

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

  • Qui envoie

    Peut exiger root. Remplacez 30120 par le port de votre ligne endpoint_add_udp et <iface> par votre interface ; la capture s’arrête après 2000 paquets. Lisez la colonne des sources (notre lecture) : quelques adresses de joueurs récurrentes sont normales, des milliers d’adresses différentes non. Les sources sont souvent usurpées : servez-vous-en pour juger l’ampleur, jamais pour bannir.

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

Ce qui n’y ressemble pas

  • Des lignes seulement au démarrage, après le lancement d’une ressource, à la même heure chaque jour, ou croissantes avec le nombre de joueurs.
  • Un profil où une ressource domine le tick, ou un %steal qui reste élevé.
  • Une console silencieuse. Un flood qui sature votre connexion est surtout éliminé en amont (notre raisonnement) : des joueurs qui ne se connectent pas alors que la console reste silencieuse forment un autre symptôme, traité ailleurs.

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

Un proxy ou un service de filtrage agit sur les paquets avant qu’ils n’atteignent votre serveur ; un hitch warning concerne ce que le serveur fait du temps dont il dispose.

La protection est la réponse quand

  • Votre hébergeur signale du trafic d’attaque, ou votre graphique de paquets entrants bondit, aux mêmes minutes que les lignes, et elles cessent avec le trafic. C’est un problème réseau avec un symptôme de hitch : voir les guides sur l’alerte de l’hébergeur ou le pic de trafic et sur les timeouts en masse.

La protection n’est pas la réponse quand

  • Une ressource domine le profil, ou les événements viennent de vos propres scripts et joueurs : c’est du trafic légitime, qu’un proxy transmet.
  • %steal est élevé ou d’autres services partagent le CPU : les timers sont en retard sur la machine elle-même.

À quoi ressemble une attaque DDoS contre FiveM

Toujours bloqué ? Ce qu’il faut publier

Collez ceci, après avoir retiré de votre server.cfg toute clé et tout mot de passe (sv_licenseKey compris).

  • Dix lignes de console autour d’une rafale, avec horodatages.
  • La fréquence, les regroupements (démarrage, heure fixe, heures de pointe), et ce que vous avez lancé, mis à jour ou redémarré peu avant.
  • Build d’artifact de FXServer, réglage onesync, sv_maxClients, joueurs connectés.
  • Le profil : capture d’écran du tick de ressource, ou fichier profiler saveJSON filename.json.
  • La sortie de sar -u 1 10 pendant une rafale, et votre offre d’hébergement.
  • Si vous suspectez une attaque : l’alerte de l’hébergeur avec ses heures, et sar -n DEV 1 10 en minute calme puis en rafale.

Questions fréquentes

Un hitch warning est-il toujours le signe d’un DDoS ?

Non. Une boucle écrit la ligne quand deux de ses ticks sont espacés de plus de 150 millisecondes (100 pour la synchronisation). La documentation de FiveM ne dit pas si un flood la provoque, ni quelle quantité de trafic il faudrait. Le test est une preuve extérieure à la machine : journal d’attaque de l’hébergeur ou graphique entrant aux mêmes minutes.

Quelle différence entre les avertissements des threads serveur, réseau et synchronisation ?

server est la boucle principale (ressources, vérification des timeouts, commandes de console ; toutes les 50 millisecondes, alerte au-delà de 150), network la boucle des paquets (toutes les 10, au-delà de 150), sync la boucle OneSync (toutes les 8, au-delà de 100). Celle qui écrit la ligne indique où regarder d’abord.

Comment trouver la ressource à l’origine d’un hitch warning ?

Lancez profiler record 500 dans la console du serveur pendant une rafale, puis profiler view (sur un serveur, la commande affiche un lien à ouvrir dans Chrome) ou profiler saveJSON filename.json, et chargez la capture dans Chrome. resmon est une commande client qui exige le mode développeur et montre les ressources du client, pas un hitch du serveur.

Sources et versions vérifiées

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

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.