FiveM rubber banding, ping élevé et perte de paquets : DDoS ou autre chose ?

Mis à jour le

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

VerdictPeut-être un DDoS : les preuves tranchent

Cela peut être un DDoS ou la mitigation de l’hébergeur, mais commencez par le plus simple à vérifier : un tick serveur en retard, des événements réseau trop gros, la route d’une région.

FiveShield n’aide que si une attaque est confirmée

FiveShield n’aide que si les preuves montrent une attaque sur le chemin ou une mitigation qui filtre de vrais joueurs, et jamais face à un tick en retard ni à un script.

Le rubber banding, c’est une voiture ou un personnage qui revient d’un coup en arrière : une description, pas une mesure. La console du client documente Ping et PL (perte de paquets) et le serveur affiche des hitch warnings ; ensemble, ils montrent si la cause est dans les boucles du serveur, dans ce que vos scripts envoient ou sur le chemin vers vos joueurs.

Première vérification, deux minutes : cherchez les hitch warnings dans la console à la minute du problème, et relevez Ping et PL (cl_drawperf true), avec l’heure, chez trois à cinq joueurs de régions différentes. Des hitch warnings désignent votre serveur (causes 1 à 3) ; des valeurs élevées chez tous avec une console calme désignent le lien ou l’hébergeur (causes 4, 6, 7) ; un seul joueur ou un seul fournisseur d’accès, le joueur ou la route (cause 5).

Ne soupçonnez un DDoS que si une preuve extérieure au serveur le dit : enregistrement de l’hébergeur, pic de trafic entrant, sources dispersées dans une capture. Les symptômes seuls ne le prouvent jamais.

Ce que les chiffres signifient vraiment

cl_drawperf, une commande utilisateur que tout joueur peut lancer, décrit Ping (en ms) comme « How long it takes to get a response from the server (round trip time). » et PL (en %) comme « How many packets failed to reach their destination in time. »

Le serveur signale lui-même son retard (GameServer.cpp). Quand l’écart entre deux passages de la boucle principale ou réseau dépasse 150 ms, il affiche server thread hitch warning: timer interval of %d milliseconds ou network thread hitch warning: timer interval of %d milliseconds ; pour la boucle de synchronisation, la limite est de 100 ms (sync thread hitch warning: timer interval of %d milliseconds). Ce nombre est cet écart en millisecondes, pas la latence réseau.

Le thread réseau envoie aussi les paquets mis en file pour les joueurs et lit ceux qu’ils envoient (GameServer.cpp, GameServerNet.ENet.cpp) : quand cette boucle prend du retard, l’envoi et la réception attendent. La documentation ne dit pas comment cela apparaît dans Ping : selon notre raisonnement, Ping et PL seuls ne distinguent pas un serveur en retard d’un mauvais chemin, alors qu’un hitch warning à la minute de la plainte le permet.

À vérifier en premier (deux minutes)

Trois questions séparent un problème de serveur d’un problème de réseau.

  1. Qui est touché : tout le monde, un groupe ou un seul joueur ?

    status dans la console du serveur liste l’endpoint et le ping de chaque joueur (ressource rconlog). Relevez Ping et PL (cl_drawperf true), avec l’heure, chez trois à cinq joueurs de régions différentes.

    status

  2. Que dit la console du serveur à cette minute ?

    Cherchez les hitch warnings dans le journal de la console, avec les heures. Si des joueurs ont été déconnectés, leur motif de déconnexion peut être Server->client connection timed out. Pending commands: %d.

  3. Que dit un graphique extérieur à la machine pour la même minute ?

    Ouvrez le graphique de trafic de votre hébergeur, s’il en propose un, et tout enregistrement d’attaque ou de mitigation (OVHcloud : Network > Network Security Dashboard ; ailleurs, interrogez le support sur ces minutes).

Causes, classées

Les vérifications peu coûteuses passent d’abord ; l’attaque vient en dernier, car l’affirmer exige une preuve extérieure au serveur.

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. Le tick du serveur est en retard

    Documenté

    La boucle principale du serveur affiche server thread hitch warning quand l’écart entre deux de ses passages dépasse 150 ms : tout ce qui dépend d’elle attend la ressource lente, l’appel bloquant ou le CPU saturé qui la retarde. Avertissement, seuil et profiler sont documentés ; l’effet pour un joueur est notre raisonnement.

    Comment le confirmer

    Lancez profiler record 500 dans la console du serveur, puis profiler view (copiez le lien dans Chrome) ou profiler saveJSON filename.json : les pics de temps CPU sont les frames lentes, et le détail du tick des ressources montre le thread de script et le fichier en cause. Si le profil reste plat alors que les lignes continuent, regardez ensuite le CPU de la machine (notre raisonnement).

    Que faire

    Corrigez, bridez ou retirez la ressource désignée par le profil, puis vérifiez que les lignes cessent.

  2. Événements réseau trop gros ou en boucle

    Documenté

    La documentation des événements latents vers les clients dit que « sending a large amount of data blocks the network for the client, and if blocked for too long, will result in the client timing out. » De grosses charges bloquent donc le réseau de chaque joueur destinataire ; nous en déduisons que cela se traduit par du rubber banding avant tout timeout.

    Comment le confirmer

    Sur un client en mode développeur (+set moo 31337 ou canal non production), neteventlog true liste chaque événement réseau avec direction, nom et taille. Le motif de déconnexion d’un joueur (transmis aussi à playerDropped) peut être Server->client connection timed out. Pending commands: %d. puis Command list:, avec jusqu’à sept des plus grosses commandes en attente (nom, taille, ancienneté).

    Que faire

    Envoyez les gros volumes avec TriggerLatentClientEvent ou TriggerLatentServerEvent et un bps raisonnable : par défaut (-1 ou 0), 25 000 octets par seconde et par cible, donc un envoi à tous coûte bps fois le nombre de joueurs chaque seconde, et, à partir d’environ 10 000 000, la connexion et les performances peuvent en pâtir.

  3. Charge OneSync

    Documenté

    OneSync envoie à chaque joueur des mises à jour sur les entités proches ; le culling existe pour que le serveur évite « sending a lot of unneeded data to and from the server ». Le thread de synchronisation avertit au-delà de 100 ms d’écart. Plus de joueurs et d’entités, c’est plus de travail par tick (notre raisonnement).

    Comment le confirmer

    Notez si les lignes sync thread hitch warning suivent le nombre de joueurs ou les zones chargées.

    Que faire

    Réduisez d’abord les entités (véhicules et peds que vos scripts créent sans jamais les supprimer) et gardez onesync_distanceCulling à true, sa valeur par défaut.

  4. Lien réseau du serveur saturé ou congestion chez l’hébergeur

    Notre déduction

    Tout ce que reçoivent les joueurs sort par l’interface réseau de la machine, puis par le réseau de l’hébergeur. Si l’un des deux est plein ou partagé, les paquets s’empilent et se perdent pour tous alors que le serveur de jeu paraît sain.

    Comment le confirmer

    Lisez aussi le trafic sortant : sous Linux, sar -n DEV 1 10 affiche txkB/s à côté de rxkB/s, plus %ifutil, et sar -n EDEV 1 10 ajoute txdrop/s ; sous Windows, les compteurs Network Interface incluent Bytes Sent/sec et Packets Outbound Discarded. Aucun ne voit la congestion au-delà de votre machine.

    Que faire

    Déplacez les services lourds (voix, web, sauvegardes) hors de la machine ou des heures de pointe, et demandez à l’hébergeur si le nœud est congestionné. Un lien plein de trafic légitime demande de la bande passante, pas un filtre.

  5. La connexion ou la route d’un joueur ou d’un fournisseur d’accès

    Notre déduction

    Du Wi-Fi, une connexion domestique saturée, un VPN ou un PC qui ne tient pas sa cadence d’images donnent du rubber banding à un seul joueur. Un même fournisseur d’accès ou une même zone traverse aussi des réseaux que vous ne contrôlez pas : une route saturée ou coupée peut donc ne toucher que ce groupe.

    Comment le confirmer

    Comparez ce joueur ou ce groupe aux autres joueurs connectés au même moment. cl_drawperf true affiche FPS, usage CPU et GPU à côté de Ping et PL ; demandez pays, fournisseur d’accès, connexion filaire et VPN coupé.

    Que faire

    Les réglages du serveur n’y peuvent rien. Des FPS bas avec un CPU ou un GPU proche de sa limite désignent le PC, un Ping ou PL élevé avec des FPS sains la connexion ou la route (notre raisonnement) : envoyez la comparaison à l’hébergeur.

  6. Mitigation ou game firewall de l’hébergeur qui gêne de vrais joueurs

    Documenté

    Le guide du Network Security Dashboard d’OVHcloud dit que le système « may need additional tuning ». Son guide du Game firewall recommande « Default Deny », qui bloque tout trafic sans règle : une règle manquante pour votre port de jeu bloquerait de vrais joueurs. Il renvoie au support en cas de « false positives from Anti-DDoS Infrastructure systems ».

    Comment le confirmer

    Dans l’espace client OVHcloud, ouvrez Network > Network Security Dashboard avec le mode avancé activé : Mitigation indique Forced tant que le centre de nettoyage agit, et l’onglet « Journal du Centre de nettoyage » donne chaque « Heure de détection » et « Heure de fin ». Sur un serveur Game, vérifiez sous Network > Public IP Addresses que le Game firewall a une règle pour votre port de jeu.

    Que faire

    Ajoutez la règle manquante. Si une mitigation était active et que de vrais joueurs ont souffert, ouvrez un ticket avec ce qu’OVHcloud demande : début et fin, IP concernées, trafic légitime bloqué ou non.

  7. Un flood qui dégrade le lien sans le mettre hors service

    Notre déductionLe cas du DDoS

    Un flood visant votre port de jeu ou le lien peut remplir l’interface, ou le travail du thread réseau, de trafic qui ne vient pas des joueurs. Les paquets légitimes s’empilent ou se perdent : Ping et PL élevés côté joueurs, alors que le processus tient et que personne n’est déconnecté pour timeout.

    Comment le confirmer

    Un enregistrement d’attaque de l’hébergeur qui recoupe la plainte est l’indice le plus fort. À défaut, cherchez un débit entrant très au-dessus de votre référence d’un jour calme et de nombreuses sources dispersées dans une courte capture. Le graphique d’OVHcloud n’existe que pendant les détections : l’absence d’enregistrement ne prouve pas un lien calme.

    Que faire

    Gardez les preuves, puis suivez la branche attaque ci-dessous : pas de redémarrages en boucle, pas de nouvelle IP annoncée.

À quoi ressemble un DDoS ici

Seule une preuve extérieure au serveur montre une attaque : l’enregistrement de votre hébergeur, un graphique de trafic entrant ou des paquets capturés.

À quoi ressemble un DDoS ici

  • Ping et PL montent en même temps chez des joueurs de régions très variées, et commencent et s’arrêtent avec un enregistrement d’attaque de l’hébergeur.
  • Les paquets ou bits entrants par seconde dépassent largement une référence d’un jour calme, CPU et tick restant normaux. Un flood que le processus doit analyser pourrait aussi retarder le thread réseau (notre raisonnement) : des lignes network thread hitch warning n’écartent donc pas une attaque à elles seules.

Preuves que vous pouvez recueillir

  • L’enregistrement de votre hébergeur

    Chez OVHcloud, l’onglet « Journal du Centre de nettoyage » affiche « Heure de détection », « Heure de fin », « IP de destination » et « Vecteurs d’attaque » pendant un an ; le graphique de trafic est conservé deux mois et n’est alimenté que pendant les événements de détection : conservez-en une copie sans attendre et gardez vos propres compteurs. Les adresses sources ne sont pas affichées (généralement usurpées) : ne les bannissez pas.

  • Débit de paquets entrants sous Linux

    Lisez rxpck/s et rxkB/s, et rxdrop/s avec sar -n EDEV 1 10. Mesurez d’abord un jour calme : une référence donne un sens à un chiffre isolé.

    sar -n DEV 1 10

  • Débit de paquets entrants sous Windows

    Surveillez votre carte réseau ; Packets Received Discarded est le compteur de pertes correspondant.

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

  • Qui envoie

    Droits root ou équivalents requis ; remplacez <iface> et le port. Quelques adresses correspondant à vos joueurs, c’est normal ; de nombreuses sources dispersées, très au-dessus du nombre de joueurs, évoquent un flood (notre raisonnement).

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

Ce qui n’y ressemble pas

  • Un seul joueur, fournisseur d’accès ou pays est touché.
  • Un trafic qui bondit juste après un redémarrage est en général du trafic sortant (téléchargements de ressources) ; une attaque arrive en entrant.

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

La protection est la réponse quand

  • L’hébergeur a enregistré une attaque sur votre IP aux minutes signalées par les joueurs, et le trafic entrant de la machine a monté avec elle.
  • La mitigation de l’hébergeur était active, de vrais joueurs ont perdu des paquets et une demande de réglage n’a rien changé : alors seulement, un filtre en amont de l’hébergeur mérite d’être évalué.

La protection n’est pas la réponse quand

  • La console affiche des hitch warnings, ou une raison de déconnexion avec Pending commands, et rien d’extérieur au serveur ne montre d’attaque : regardez d’abord vos threads et vos scripts, car un proxy n’y change rien.
  • Un seul joueur, fournisseur d’accès ou région est touché : c’est d’abord le joueur ou une route, et rien ne promet qu’un proxy la change.

Si les preuves disent que c’est une attaque

Ne redémarrez pas en boucle et n’annoncez pas de nouvelle IP : un redémarrage ne change rien au trafic qui arrive sur l’adresse, et une adresse publiée est visible de l’attaquant.

Sauvegardez d’abord les preuves : enregistrements et graphique de l’hébergeur, sortie de sar ou Get-Counter, courte capture, Ping et PL des joueurs avec les heures.

Si la mitigation de l’hébergeur gêne de vrais joueurs, commencez par la demande de réglage de la cause 6. Décidez ensuite où placer le filtrage : la mitigation de l’hébergeur absorbe le volume, et OVHcloud documente un profil FiveM pour ses serveurs Game récents ; si cela ne suffit pas, mettez d’abord un proxy devant, puis déplacez l’origine sur une nouvelle IP que seul le proxy connaît.

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

Collez ceci dans cet ordre, après avoir retiré adresses IP, identifiants et sv_licenseKey.

  • Le build de votre FXServer, onesync et sv_maxClients.
  • Les hitch warnings de la minute du problème, tels quels, avec l’heure, et toute raison de déconnexion avec Pending commands.
  • Ping, PL et FPS (cl_drawperf true) de trois à cinq joueurs, avec heure, pays et fournisseur d’accès.
  • Votre hébergeur et votre offre, son enregistrement pour ces minutes, et la sortie de sar -n DEV 1 10 pendant l’incident et un jour calme.

Questions fréquentes

Le rubber banding est-il le signe d’un DDoS ?

Pas à lui seul : une boucle serveur en retard, des événements trop gros, une mauvaise route ou la connexion d’un joueur peuvent le provoquer aussi. Seule une preuve extérieure au serveur désigne une attaque.

Comment mesurer le ping et la perte de paquets sur FiveM ?

Dans la console F8, lancez cl_drawperf true : elle affiche Ping, PL, les FPS, l’usage CPU et GPU. netgraph true et net_statsFile metrics.csv sont des commandes développeur (il faut +set moo 31337 ou un canal de mise à jour non production).

Un proxy fera-t-il baisser mon ping ?

Cette page ne l’affirme pas. Un proxy ne change rien à un tick en retard ni à un script ; son intérêt se limite à une attaque sur le chemin ou à une mitigation qui filtre de vrais joueurs, preuves à l’appui.

Sources et versions vérifiées

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

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.