Client -> server connection timed out sur FiveM : DDoS ou autre chose ?

Mis à jour le

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

VerdictPeut-être un DDoS : les preuves tranchent

Ce peut être un DDoS, mais un thread serveur bloqué, des événements réseau trop volumineux ou une mauvaise route donnent la même fenêtre. Une preuve extérieure à la machine tranche.

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

FiveShield n’aide que si votre hébergeur ou votre graphique de trafic confirme une attaque. Il ne règle ni le spam d’événements réseau ni un thread serveur bloqué.

Le client a perdu sa connexion au serveur. FiveM fixe un délai maximal de 30 secondes aux deux extrémités, et la fenêtre ne dit pas pourquoi le trafic s’est arrêté : thread serveur bloqué, événements réseau trop volumineux, panne chez l’hébergeur, mauvaise route ou DDoS donnent tous la même fenêtre.

Commencez par les raisons de déconnexion des joueurs touchés. Pending commands: N avec une Command list: nomme des commandes envoyées par le serveur et jamais acquittées, comme des événements réseau : regardez d’abord les scripts. Un simple Last seen N msec ago près de lignes hitch warning ou seems hung désigne un serveur bloqué. La même ligne avec une console silencieuse et un txAdmin resté en ligne : regardez hors de la machine.

Ne parlez de DDoS qu’avec une preuve extérieure : l’alerte de votre hébergeur pour les mêmes minutes, ou un bond du trafic entrant que votre nombre de joueurs n’explique pas.

Messages que vous pouvez voir

  • Client -> server connection timed out. Please try again later.

    Dans la fenêtre de connexion du joueur

  • Timeout info: game=%s, recv=%s, send=%s

    Sous la fenêtre : pour les images du jeu, les données reçues et les données envoyées, l’intervalle moyen sur les 16 derniers événements, un écart type et le temps écoulé depuis le dernier

  • Server->client connection timed out. Last seen %d msec ago.

    Comme raison de déconnexion transmise à playerDropped et rangée par txAdmin dans timeout ; la fenêtre du joueur peut aussi l’afficher

  • Server->client connection timed out. Pending commands: %d.

    Comme raison de déconnexion, suivie des plus grosses commandes envoyées par le serveur et jamais acquittées

Ce que cela signifie vraiment

Le client affiche Client -> server connection timed out. Please try again later. quand, en jeu, sa couche réseau déclare la connexion au serveur expirée ou perdue (NetLibrary.cpp, NetLibraryImplV2.cpp). Si la raison de déconnexion du serveur arrive en premier chez le joueur, la même fenêtre Timed out affiche ce texte à la place. Chaque valeur de sa ligne Timeout info: game=%s, recv=%s, send=%s est un intervalle moyen en millisecondes sur les 16 derniers événements, puis, après ±, un écart type et, après ~, les millisecondes écoulées depuis le dernier événement.

Client et serveur fixent chacun à 30 secondes le délai maximal (NetLibraryImplV2.cpp, GameServerNet.ENet.cpp), et le commentaire du code client le dit équivalent à la vérification côté serveur. Notre lecture : un à-coup de quelques secondes se traduit par du lag et des pertes de paquets, pas par un timeout ; si beaucoup de joueurs passent en timeout ensemble, quelque chose est resté muet environ une demi-minute, ou une file ne s’est jamais vidée.

Le serveur déconnecte le joueur avec Server->client connection timed out. Last seen %d msec ago. ou, si le joueur a été vu moins de 1 500 ms avant la déconnexion alors que des commandes envoyées n’étaient pas encore acquittées, Server->client connection timed out. Pending commands: %d. suivi d’une Command list: des sept plus grosses au maximum, chacune avec son nom, sa taille en octets et les millisecondes écoulées depuis son envoi (GameServer.cpp, GameServerNet.ENet.cpp). txAdmin range les deux dans timeout (classifyDropReason.ts). Aucune ne dit pourquoi le trafic s’est arrêté ; les vérifications ci-dessous distinguent un serveur muet d’un chemin muet.

À vérifier en premier (deux minutes)

Chaque étape se termine par une destination. Notez l’heure à laquelle les joueurs ont été déconnectés, avec votre fuseau horaire.

  1. Un seul joueur, quelques-uns d’une même région, ou tout le monde en même temps ?

    Demandez sur votre Discord qui est tombé et à quelle heure. Tout le monde en quelques secondes, c’est un événement du serveur ou du chemin ; un seul joueur, ou quelques-uns chez le même fournisseur d’accès, désigne leur propre connexion. Dans leur fenêtre, de grandes valeurs game= signifient que leur jeu s’est figé ; de grandes valeurs recv= avec un game= normal, que rien n’est arrivé du serveur (notre lecture).

  2. Lire les raisons de déconnexion des joueurs touchés

    Ouvrez le journal de la console du serveur, ou l’endroit où vous enregistrez playerDropped, pour la minute des déconnexions. Copiez les raisons avant tout redémarrage.

  3. Chercher un blocage dans la console du serveur

    Cherchez autour des déconnexions hitch warning et seems hung. Le chiffre de server thread hitch warning: timer interval of %d milliseconds est un intervalle entre deux ticks, pas une latence. S’ils reviennent, profilez :

    profiler record 500

  4. txAdmin, le processus et la machine sont-ils restés en ligne ?

    Dans la console et les journaux de txAdmin, cherchez txAdmin was frozen for N seconds et les lignes Restarting server: (Server is not responding, Server process close detected). Un txAdmin « en ligne » prouve peu : son health check est une requête de la machine vers l’adresse du serveur lui-même (0.0.0.0 devient 127.0.0.1), donc elle n’emprunte jamais le chemin des joueurs.

  5. Vérifier la machine et l’hébergeur pour les mêmes minutes

    Vérifiez processeur, mémoire, disque et réseau par processus, autres services compris (voix, web, base de données), puis le panel de votre hébergeur : une alerte, une entrée de mitigation ou un graphique du trafic entrant.

Causes, classées

Le DDoS est la cause 6 parce qu’il exige une preuve extérieure à la machine, pas parce qu’il n’arrive jamais.

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. Événements réseau trop volumineux ou en boucle

    Documenté

    La documentation indique qu’envoyer beaucoup de données par des événements ordinaires bloque le réseau du client, et que s’il reste bloqué trop longtemps le client finit en timeout. Un événement latent envoyé à -1 part vers chaque joueur à bps octets par seconde : bps fois le nombre de joueurs, par seconde.

    Comment le confirmer

    Lisez la Command list: des raisons de déconnexion : le même nom d’événement, de grande taille, pour beaucoup de joueurs. Les raisons reliable network event overflow relèvent d’un autre mécanisme : txAdmin les range en security, pas en timeout. Sur un client en mode développeur, neteventlog true affiche le sens, le nom et la taille de chaque événement.

    Que faire

    Envoyez les gros volumes avec TriggerLatentClientEvent ou TriggerLatentServerEvent, gardez un bps modeste (25 000 par défaut ; la documentation met en garde contre environ 10 000 000 et plus) et cessez de diffuser à -1 ce qu’un seul joueur doit recevoir. Relever rateLimiter_netEvent_* n’allège pas ce qu’un script envoie.

  2. Le thread du serveur se bloque

    Retours de propriétaires

    FXServer fait tourner plusieurs boucles, dont svMain, svNetwork et svSync. La principale écrit server thread hitch warning: timer interval of %d milliseconds quand deux ticks sont espacés de plus de 150 ms, et le watchdog écrit Loop %s seems hung! (last checkin %d seconds ago) au bout de 45 secondes. La documentation ne précise pas quelle boucle bloquée atteint la connexion ; des propriétaires signalent des timeouts de masse avec des hitch warnings, attribués dans certains fils à des scripts.

    Comment le confirmer

    Cherchez hitch warning (les threads serveur, réseau et sync écrivent chacun le leur) et seems hung autour des déconnexions. Le watchdog ne parle qu’après 45 secondes, donc après le délai de 30 secondes : cherchez le hitch warning écrit quand la boucle repart (notre lecture). Profilez avec profiler record 500, puis profiler view.

    Que faire

    Trouvez la ressource dans le profil et corrigez-la ou retirez-la. Un proxy ne change rien à la vitesse d’exécution d’un thread.

  3. Un défaut chez l’hébergeur, ou un voisin lourd sur la même machine

    Retours de propriétaires

    Le serveur peut aller bien pendant que la machine en dessous va mal. Des propriétaires signalent un défaut de processeur sur un VPS corrigé par l’hébergeur, un flot d’événements réseau qui a déclenché la sécurité de l’hébergeur et fait écarter des paquets répétés, et, dans un fil de timeouts de masse, une réponse qui attribue la solution à une machine dédiée pour la voix. txAdmin écrit txAdmin was frozen for N seconds for unknown reason (random issue, VPS Lag, DDoS, etc). quand sa surveillance se fige plus de 10 secondes. Le guide du pare-feu Game d’OVHcloud, pour ses serveurs Game, recommande « Default Deny », qui bloque tout trafic sans règle correspondante : une règle UDP manquante couperait les joueurs.

    Comment le confirmer

    Cherchez txAdmin was frozen dans la console et les journaux de txAdmin, comparez la charge par processus sur la plage exacte, interrogez votre hébergeur sur d’éventuels incidents et vérifiez que votre pare-feu de jeu a une règle pour le port UDP du jeu.

    Que faire

    Ouvrez un ticket avec les horodatages et les lignes exactes de déconnexion, rétablissez toute règle modifiée, et déplacez un voisin lourd (voix, base de données, panel web) sur sa propre machine ou plafonnez sa part.

  4. Un redémarrage ou un plantage qui ressemble à un timeout

    Notre déduction

    Un arrêt propre (quit avec une raison) déconnecte les joueurs avec Server shutting down: <reason>. Un processus tué n’envoie rien : les clients atteignent probablement leur propre délai de 30 secondes (notre lecture) ; sous Windows, FXServer peut envoyer le même message lors d’une fin anormale (GameServer.cpp). txAdmin redémarre un serveur dont les heartbeats cessent pendant 60 secondes ou dont le health check échoue pendant 180, en écrivant Restarting server: Server is not responding.

    Comment le confirmer

    Comparez l’heure de la première déconnexion avec le journal de txAdmin.

    Que faire

    Corrigez ce qui a arrêté le processus et éloignez les redémarrages planifiés des heures de pointe. Un serveur bloqué que txAdmin doit tuer, c’est de nouveau la cause 2.

  5. La connexion d’un joueur, ou la route d’une région

    Retours de propriétaires

    Le Wi-Fi, le VPN, l’antivirus ou le PC surchargé d’un seul joueur donne la fenêtre sur son écran seulement ; un défaut de routage entre un fournisseur d’accès ou un pays et votre hébergeur touche tous ceux qui passent par là.

    Comment le confirmer

    Comptez les joueurs touchés par fournisseur d’accès et par pays. Demandez à l’un d’eux de laisser cl_drawperf true activé : Ping (ms) et PL (perte de paquets, %) montrent si la perte a grimpé avant la déconnexion.

    Que faire

    Un joueur : son réseau, son VPN ou son PC. Une région : donnez à votre hébergeur le fournisseur d’accès, le pays et les minutes, et demandez une vérification de la route.

  6. Un DDoS, une null route ou un faux positif de la mitigation de l’hébergeur

    DocumentéLe cas du DDoS

    OVHcloud envoie un e-mail quand une attaque est détectée et que le trafic passe par son infrastructure Anti-DDoS, et ses guides invitent à contacter le support pour un réglage en cas de faux positif. Leaseweb indique, pour la colocation, que la mitigation par nulling ne peut pas être désactivée ; TransIP place en null route une adresse visée par une attaque de plusieurs Gbit/s, qui devient injoignable depuis l’extérieur. La connexion établie cesse de recevoir, atteint le délai de 30 secondes, et tous les joueurs voient la fenêtre ensemble (notre lecture).

    Comment le confirmer

    Cherchez une preuve extérieure pour les mêmes minutes : l’e-mail ou l’alerte de votre hébergeur et, chez OVHcloud, Network > Network Security Dashboard, dont l’onglet « Journal du Centre de nettoyage » affiche « Heure de détection », « Heure de fin », « IP de destination » et « Vecteurs d’attaque ».

    Que faire

    Avec une preuve, conservez-la, prévenez votre hébergeur et suivez la branche sous « Quand la protection est, ou n’est pas, la réponse ». Si sa mitigation a touché de vrais joueurs, demandez au support de l’ajuster.

À quoi ressemble un DDoS ici

Une attaque est un changement à la périphérie du réseau ; sa preuve se trouve donc hors du processus FXServer : l’alerte de votre hébergeur, un graphique du trafic entrant, des paquets capturés.

À quoi ressemble un DDoS ici

  • Beaucoup de joueurs tombent en quelques secondes, avec la raison simple Last seen N msec ago. et non Pending commands.
  • Aucun hitch warning ni seems hung, et txAdmin reste en ligne (son health check ne quitte pas la machine). Cela correspond à un chemin extérieur mort, sans le prouver.
  • Votre hébergeur le signale : un e-mail sur le réacheminement vers la mitigation, une entrée de journal pour les mêmes minutes, ou une note indiquant que l’adresse a été mise en null route.

Preuves que vous pouvez recueillir

  • Le relevé de votre hébergeur

    Selon sa documentation, OVHcloud garde son « Journal du Centre de nettoyage » un an et le graphique de trafic deux mois : conservez vite ce qu’il vous faut. Les autres hébergeurs diffèrent : interrogez le vôtre.

  • Trafic entrant sur le serveur (Linux)

    Faites une mesure de référence un jour calme. rxpck/s et rxkB/s sont les paquets et kibioctets reçus par seconde ; sar -n EDEV 1 10 donne rxdrop/s. Un flood qui remplit la liaison avant la machine peut paraître normal ici : le graphique de l’hébergeur passe en premier.

    sar -n DEV 1 10

  • Trafic entrant sur le serveur (Windows)

    Le même jeu de compteurs comprend Packets Received Discarded. Comparez avec une référence d’un jour calme.

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

  • Un échantillon des sources du trafic

    Droits root requis ; remplacez 30120 par votre port de jeu. Quelques adresses correspondant à vos joueurs, c’est normal ; beaucoup de sources distinctes et dispersées, bien au-delà de votre nombre de joueurs, évoquent un flood. Servez-vous-en pour confirmer, jamais pour bannir : OVHcloud indique que les sources sont généralement usurpées.

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

Ce qui n’y ressemble pas

  • Des hitch warnings ou seems hung seuls : ils correspondent à des scripts ou à un processeur saturé, et ne comptent pour une attaque que si votre hébergeur ou un graphique montre du trafic entrant.
  • Une hausse de bande passante après un redémarrage : les joueurs qui se reconnectent peuvent télécharger les ressources modifiées, c’est du trafic sortant. Une attaque est entrante.

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

La protection est la réponse quand

  • L’alerte ou le tableau de bord de votre hébergeur, ou un graphique du trafic entrant, montre du trafic d’attaque aux minutes des déconnexions, et cela se répète.
  • Votre hébergeur a mis l’adresse en null route, ou sa mitigation filtre sans cesse de vrais joueurs : il vous faut un trafic de jeu filtré et une origine tenue privée.
  • L’attaquant connaît déjà votre adresse : l’origine doit donc changer aussi.

La protection n’est pas la réponse quand

  • Pending commands et une liste de commandes : un proxy transmet les mêmes événements.
  • Des hitch warnings ou seems hung et aucun événement chez l’hébergeur : un proxy ne change rien à la vitesse d’exécution d’un thread.
  • Votre hébergeur ne montre rien et le graphique du trafic entrant est plat aux minutes des déconnexions.

Si les preuves disent que c’est une attaque

Gardez d’abord les preuves : le journal ou le graphique de votre hébergeur, les lignes de déconnexion avec horodatages, toute capture du trafic entrant. Ne redémarrez pas en boucle, n’annoncez pas de nouvelle adresse aux joueurs et ne bannissez pas les adresses sources, généralement usurpées.

Décidez ensuite quelle couche manque. La mitigation de votre hébergeur absorbe le volume sur son propre réseau ; une couche de protection devant le serveur garde en plus l’adresse d’origine privée, ce qui suppose de changer l’adresse d’origine une fois, après la mise en place de la protection.

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 du texte, pas des captures d’écran, avec le fuseau horaire de chaque horodatage. Retirez d’abord les identifiants de joueurs et les adresses IP.

  • Build de FXServer, version de txAdmin, système d’exploitation, et VPS, serveur dédié ou connexion personnelle.
  • La fenêtre complète de deux ou trois joueurs touchés, ligne Timeout info comprise.
  • La console du serveur, et vos enregistrements de playerDropped si vous en gardez, d’une minute avant la première déconnexion à une minute après : chaque raison Server->client connection timed out. (Command list: entière comprise) et chaque ligne hitch warning ou seems hung.
  • Depuis la console ou les journaux de txAdmin, toute ligne Restarting server:, txAdmin was frozen ou HealthChecks failing for the past dans cette plage.
  • Combien de joueurs sont tombés, en combien de secondes ; l’alerte ou le graphique de votre hébergeur pour cette plage ; ce qui a changé dans les 24 heures précédentes.

Questions fréquentes

Un seul joueur en timeout, est-ce un DDoS ?

Pris isolément, non. Une attaque visant votre adresse atteint en général tous les joueurs connectés, donc elle se voit sur beaucoup de joueurs à la fois. Un seul joueur désigne d’abord son PC, son VPN, son Wi-Fi ou son fournisseur d’accès.

Pourquoi les timeouts commencent-ils aux heures de pointe ?

Les heures de pointe augmentent tout ce qui dépend du nombre de joueurs : les événements réseau (un événement latent envoyé à -1 envoie bps octets par seconde à chaque joueur), la synchronisation des entités, le travail des scripts. Une attaque peut aussi tomber aux heures de pointe : comparez les raisons de déconnexion avec le graphique de votre hébergeur.

Pourquoi un redémarrage règle-t-il le problème pour un temps ?

Un redémarrage vide les événements en file, les entités et la mémoire des scripts : une cause qui s’accumule avec le temps de fonctionnement disparaît, puis revient. Une cause extérieure au processus, comme une route ou un défaut chez l’hébergeur, ignore les redémarrages, et c’est déjà un indice.

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.