txAdmin Server is not responding ou panel inaccessible : causes et solutions

Mis à jour le

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

VerdictCherchez d’abord une autre cause

Un redémarrage Server is not responding vient de contrôles exécutés sur la machine elle-même : il désigne d’abord un serveur bloqué plutôt que le réseau, et un panel qui ne s’ouvre pas désigne d’abord son port.

FiveShield aide pour une partie du problème

FiveShield ne règle pas un serveur bloqué. Pour un panel exposé, limitez d’abord le port 40120 à vos propres IP, ce qui ne coûte rien ; un proxy devant le panel est une option pour plus tard.

Deux problèmes partagent cette recherche. Un redémarrage de txAdmin avec Server is not responding signifie que l’un de ses deux moniteurs est resté muet trop longtemps : le serveur est bloqué, ou manque tellement de ressources qu’il ne peut plus répondre. Un panel qui ne s’ouvre pas est une autre question, celle du port TCP 40120.

Lisez la ligne de redémarrage, Restarting server: Server is not responding (HB:<t>|HC:<t>)., pour voir quel moniteur a abandonné, puis cherchez dans les consoles Loop svMain seems hung! et Server process close detected. Sans Restarting server: devant, les mêmes mots ne sont qu’un avertissement. Pour le panel, ouvrez d’abord http://127.0.0.1:40120 sur le serveur lui-même.

N’envisagez un DDoS que si quelque chose en dehors de la machine le dit : une alerte de l’hébergeur pour les mêmes minutes, ou un graphique de trafic entrant qui grimpe quand les pannes commencent.

Messages que vous pouvez voir

  • Server is not responding

    Dans txAdmin, comme raison du redémarrage quand le health check ou le heartbeat a échoué trop longtemps

  • HealthChecks failing for the past <t>.

    Dans la console txAdmin, et dans l’infobulle du badge Server de la barre latérale du panel

  • Stopped receiving HeartBeats <t> ago.

    Dans la console txAdmin, et dans l’infobulle du badge Server de la barre latérale du panel

  • Due to a partial hang, this server will restart in 1 minute. Please disconnect now.

    Affiché aux joueurs en jeu, avant que txAdmin redémarre un serveur partiellement bloqué

  • Loop svMain seems hung! (last checkin %d seconds ago)

    Dans la console du serveur, depuis le watchdog de FXServer

Ce que cela signifie vraiment

txAdmin exécute deux moniteurs. Le health check envoie un HTTP GET sur /dynamic.json toutes les 1 000 ms et laisse 1 500 ms pour répondre ; le heartbeat est envoyé toutes les 3 secondes depuis l’intérieur de FXServer par une ressource txAdmin nommée monitor. Chacun a un seuil de retard de 10 secondes et un seuil fatal : 180 secondes pour le health check, 60 pour le heartbeat.

Au-delà d’un seuil fatal, txAdmin redémarre le serveur et écrit Restarting server: Server is not responding (HB:<t>|HC:<t>). ; HB et HC indiquent depuis quand le heartbeat et le health check ont réussi pour la dernière fois. Dès qu’un moniteur a 10 secondes de retard, les mêmes mots ne sont qu’un avertissement. txAdmin passe le statut à « offline » quand les deux sont en retard et à « partial » quand un seul l’est, puis affiche des lignes de problème après l’avertissement ou le redémarrage, comme HealthChecks failing for the past <t>. et Stopped receiving HeartBeats <t> ago. Si le heartbeat va bien mais que le health check est muet depuis plus de 120 secondes, les joueurs voient Due to a partial hang, this server will restart in 1 minute. Please disconnect now.

Le health check vise l’adresse des lignes endpoint_add_tcp et endpoint_add_udp de server.cfg, avec 0.0.0.0 ou [::] remplacé par 127.0.0.1 : le plus souvent, la machine s’interroge elle-même. Il prouve que FXServer répond en local, pas qu’un joueur peut l’atteindre.

Le watchdog de FXServer est distinct : une boucle (svMain, default, svNetwork, svSync) qui n’a pas donné signe de vie depuis 45 secondes écrit Loop svMain seems hung! (last checkin %d seconds ago), puis une ligne svMain watchdog stack: qui liste les ressources et événements où elle se trouvait.

À vérifier en premier (deux minutes)

Trois vérifications, chacune menant à une cause ou à un guide.

  1. Le panel s’ouvre-t-il sur le serveur lui-même ?

    Ouvrez http://127.0.0.1:40120 sur la machine de txAdmin, puis vérifiez que quelque chose écoute sur le port (Linux d’abord, puis PowerShell sous Windows ; remplacez le port si vous l’avez changé).

    ss -ltn 'sport = :40120'
Get-NetTCPConnection -State Listen -LocalPort 40120

  2. Lisez la dernière ligne de redémarrage dans la console txAdmin

    Trouvez Restarting server: avec sa raison et (HB:<t>|HC:<t>) : HB est le temps écoulé depuis le dernier heartbeat, HC depuis le dernier health check réussi.

  3. Comparez la panne avec votre hébergeur

    Consultez le graphique de trafic et la liste d’événements de votre hébergeur pour les minutes exactes (OVH : Network, puis Network Security Dashboard). Seul un pic ou une alerte qui coïncide avec la panne désigne une attaque. Un enregistrement vide signifie seulement que l’hébergeur n’a rien détecté.

Causes, classées

Ordre éditorial : ce que les propriétaires signalent le plus, pondéré par la facilité de vérification. L’attaque vient en dernier : sa preuve doit venir de l’extérieur de 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. Un script bloque le thread principal

    Documenté

    Un gestionnaire qui ne rend jamais la main (boucle infinie, long appel bloquant) empêche la boucle svMain de donner signe de vie. Le heartbeat est une boucle de script à l’intérieur du serveur : il s’arrête donc aussi (notre lecture : les sources ne disent pas sur quel thread il tourne), et 60 secondes sans heartbeat redémarrent le serveur.

    Comment le confirmer

    Cherchez seems hung et watchdog stack: dans la console du serveur, et Detected server thread svMain hung with stack: dans la console txAdmin. Un svMain bloqué dépasse 45 secondes, donc écrit seems hung, avant que le heartbeat atteigne sa limite de 60 secondes. Les entrées de la pile ressemblent à <resource>: tick ou <resource>: event <name>, la plus interne d’abord ; une pile réduite à root ne nomme aucune ressource.

    Que faire

    Arrêtez la ressource désignée avec stop <resource> : si les redémarrages cessent, mettez-la à jour ou remplacez-la. Sous 45 secondes, le watchdog reste muet : ces blocages apparaissent comme des hitch warnings (voir le guide thread hitch warning).

  2. Le processus du serveur a planté

    Documenté

    txAdmin surveille le processus enfant. Quand FXServer se termine, txAdmin le redémarre aussitôt avec Server process close detected et écrit FXServer Exited (<exit code>). avec le code de sortie en hexadécimal, ou un nom de signal. Un arrêt dans les cinq secondes suivant le lancement ajoute FXServer didn't start. This is not an issue with txAdmin. Un port impossible à lier donne Detected FXServer error: Port <port> is busy!

    Comment le confirmer

    Lisez le code de sortie dans la console txAdmin. Sans ligne seems hung avant, Server process close detected pointe vers un plantage, pas un blocage. Un Port <port> is busy! répété signifie en général qu’un autre processus, comme un FXServer précédent, occupe le port.

    Que faire

    Publiez le code de sortie et les lignes de console qui le précèdent. Testez le build recommandé, repérez ce qui a changé avant le premier plantage, et libérez tout port occupé.

  3. Une ressource ne finit jamais de démarrer au lancement

    Documenté

    Au démarrage, txAdmin attend des événements de ressources à rythme régulier, et il ne juge pas un démarrage lent avant la fin de sa période de grâce. Ensuite, sans aucun événement de ressource après 30 secondes d’exécution, ou avec plus de 45 secondes d’écart après le dernier, il redémarre avec Server boot timed out. Une ressource qui dépasse la tolérance de démarrage configurée dans txAdmin donne Resource "<name>" failed to start within the <t> time limit.

    Comment le confirmer

    Les lignes de problème affichées après l’avertissement nomment la ressource : Resource "<name>" has been loading for <t>. ou Last resource finished loading <t> ago. Si vous lisez plutôt Resources started <t> ago but the HTTP endpoint is still unresponsive., les scripts tournent mais le health check n’a jamais réussi : relisez les lignes endpoint_add_* de server.cfg.

    Que faire

    Corrigez ou retirez cette ressource et voyez ce qu’elle attend (une base de données muette, par exemple). Augmenter resourceStartingTolerance ne fait que déplacer la limite.

  4. Le port du panel est fermé, modifié, ou rien n’y écoute

    Documenté

    Le panel a son propre port TCP, par défaut 40120 sur toutes les interfaces (TXHOST_TXA_PORT et TXHOST_INTERFACE, valeurs par défaut 40120 et 0.0.0.0). TXHOST_TXA_PORT prend le pas sur la convar obsolète txAdminPort et ne peut pas valoir 30120. Déplacé, ou derrière un pare-feu qui n’autorise que le port de jeu, il ne répond que sur le serveur : le guide du Game firewall d’OVH recommande Default Deny, qui bloque tout trafic sans règle correspondante, donc 40120 aussi.

    Comment le confirmer

    Lancez les commandes de l’étape 1 sur le serveur. Dans l’adresse locale, 0.0.0.0, * ou :: signifie toutes les interfaces, 127.0.0.1 la machine seule. Ouvert en local mais pas de l’extérieur : une règle intermédiaire (pare-feu du système ou de l’hébergeur, Game firewall en Default Deny). Rien n’écoute : txAdmin est arrêté ou utilise un autre port. Si aucune règle ne l’explique, comparez avec l’enregistrement de l’hébergeur pour ces minutes (cause 6).

    Que faire

    Ouvrez le port TCP 40120 (ou le vôtre) aux seules IP depuis lesquelles vous administrez. Ne pointez pas TXHOST_INTERFACE vers une adresse de bouclage pour cacher le panel : sa documentation précise que txAdmin impose aussi cette interface à FXServer.

  5. Toute la machine se bloque (lag du VPS ou panne côté hébergeur)

    Notre déduction

    Notre raisonnement à partir des seuils documentés : les deux moniteurs mesurent du temps écoulé, donc si la machine se fige ou prive FXServer de ressources pendant environ une minute, l’écart de heartbeat dépasse 60 secondes et txAdmin peut redémarrer un serveur dont les scripts n’ont rien fait de mal. txAdmin remarque aussi ses propres blocages : quand son contrôle, censé tourner chaque seconde, a plus de 10 secondes de retard, il écrit txAdmin was frozen for N seconds for unknown reason (random issue, VPS Lag, DDoS, etc). et saute ce contrôle.

    Comment le confirmer

    Cherchez txAdmin was frozen for dans la console txAdmin, et les trous dans les autres journaux de la machine à la même minute. Demandez à l’hébergeur les événements CPU et hôte pour cette fenêtre.

    Que faire

    Envoyez les horodatages exacts à l’hébergeur et demandez une explication côté hôte. Si les trous se répètent, changez d’offre ou de machine ; redémarrer le serveur ne résout rien quand c’est l’hébergeur qui se fige.

  6. Un flood sur un port TCP, ou une attaque qui bloque la machine

    Notre déductionLe cas du DDoS

    Notre raisonnement à partir de ce que mesurent les moniteurs ; aucune source ne chiffre ces cas. Le panel écoute par défaut sur un port TCP public, et le health check interroge le port TCP du jeu : l’un comme l’autre peut être visé seul. Un flood de requêtes sur le port de jeu pourrait ralentir la réponse HTTP qu’attend le health check alors que les scripts continuent de tourner (la page des commandes serveur de FiveM évoque les floods HTTP à propos de sv_requestParanoia). Si le trafic remplit votre lien, ou si l’hébergeur coupe l’adresse, joueurs et panel sont isolés mais le health check, resté sur la machine, réussit : txAdmin affiche le serveur en ligne. Un flood qui épuise le CPU peut bloquer FXServer et txAdmin assez longtemps pour déclencher les moniteurs, et le redémarrage ressemble alors exactement à celui de la cause 1.

    Comment le confirmer

    Seules comptent les preuves extérieures à la machine (section suivante : l’enregistrement de l’hébergeur et une capture du trafic entrant). Rien dans txAdmin ne distingue une attaque d’un blocage.

    Que faire

    Limitez dès maintenant 40120 à vos propres IP (cause 4). Si l’hébergeur confirme une attaque, ne redémarrez pas à répétition, n’annoncez pas de nouvelle IP et ne bannissez pas les adresses sources, le plus souvent usurpées (OVH l’indique pour ses journaux). Gardez les preuves et lisez le guide sur l’alerte de l’hébergeur.

À quoi ressemble un DDoS ici

txAdmin ne peut pas montrer une attaque ; ses messages décrivent le processus et une requête HTTP locale. Seules des preuves extérieures à la machine, pour les mêmes minutes, le peuvent.

À quoi ressemble un DDoS ici

  • Votre hébergeur signale une attaque ou un événement de mitigation sur votre adresse pour les minutes de la panne.
  • Le trafic entrant grimpe quand les pannes commencent et retombe quand elles s’arrêtent, très au-dessus d’un jour normal. Les journaux peuvent ne rien montrer d’inhabituel, ou ressembler à un script bloqué, car une attaque qui bloque la machine y ressemble.
  • Le panel est injoignable de l’extérieur alors que http://127.0.0.1:40120 répond sur le serveur, et l’enregistrement de l’hébergeur montre un vecteur TCP contre votre adresse.

Preuves que vous pouvez recueillir

  • L’enregistrement de l’hébergeur pour les mêmes minutes

    Chez OVH : Network, puis 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 », et ce journal est conservé un an ; exportez vite les graphiques de trafic (deux mois selon la documentation, deux semaines selon la FAQ commerciale d’OVH). Les adresses sources ne sont pas affichées : elles sont le plus souvent usurpées, donc les bannir ne sert à rien. Les autres hébergeurs diffèrent : demandez une trace écrite.

  • Le trafic entrant sur la machine

    Capturez dix secondes pendant une panne et autant un jour calme, puis comparez les paquets reçus par seconde (rxpck/s avec sar ; Packets Received/sec sous Windows, à arrêter avec Ctrl+C). Le trafic qui suit un redémarrage est sortant (des joueurs qui retéléchargent) ; une attaque est entrante.

    sar -n DEV 1 10
Get-Counter -Counter '\Network Interface(*)\Packets Received/sec' -Continuous

Ce qui n’y ressemble pas

  • Un redémarrage juste après Loop svMain seems hung! avec une pile qui nomme une ressource, alors que le graphique de trafic reste plat : un script.
  • Server boot timed out, Resource "<name>" failed to start within the <t> time limit ou Server process close detected : ces raisons décrivent le processus, pas le réseau.

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

Rien devant un serveur ne corrige un script bloqué : un proxy change qui peut atteindre la machine, pas ce que font vos scripts.

La protection est la réponse quand

  • Votre hébergeur confirme une attaque sur votre adresse pour ces minutes et le graphique de trafic correspond. L’étape suivante est la décision « sous attaque », pas les réglages de txAdmin (lisez le guide sur l’alerte de l’hébergeur).
  • Le panel est ouvert à tout Internet, vous ne pouvez pas le limiter à vos propres IP et vous voulez le placer derrière autre chose. Limiter 40120 ne coûte rien et passe en premier ; un proxy devant le panel vient après.

La protection n’est pas la réponse quand

  • La raison du redémarrage est Server is not responding et l’hébergeur ne montre rien pour ces minutes : cherchez du côté d’un script bloqué ou d’une machine figée, pas d’une attaque.
  • Une règle de pare-feu ou un port modifié bloque le panel : un proxy rencontrerait la même règle et ajouterait un saut.
  • Server boot timed out, Loop svMain seems hung! ou txAdmin was frozen avec un graphique de trafic plat : corrigez la ressource, ou interrogez votre hébergeur.

Anti-DDoS FiveM : comment fonctionne FiveShield

Toujours bloqué ? Ce qu’il faut publier

Collez des lignes, pas des descriptions : elles permettent à d’autres de lire la cause.

  • La dernière ligne Restarting server: de la console txAdmin, avec ses durées (HB:<t>|HC:<t>).
  • Chaque ligne seems hung, watchdog stack:, Detected server thread, FXServer Exited ( ou Port <port> is busy! des minutes précédentes.
  • Votre build FXServer, votre version de txAdmin et le résultat de la vérification de l’étape 1.
  • Si vous soupçonnez une attaque : une capture de l’enregistrement de l’hébergeur pour les mêmes minutes et la sortie de sar ou Get-Counter, pendant une panne et un jour calme.

Questions fréquentes

Pourquoi txAdmin indique-t-il que le serveur est en ligne alors que personne ne peut se connecter ?

Le health check est une requête HTTP de la machine vers elle-même (0.0.0.0 dans vos lignes endpoint_add_tcp et endpoint_add_udp devient 127.0.0.1), et il ne touche jamais le port UDP des joueurs. Une règle de pare-feu, un filtre chez l’hébergeur, un lien saturé ou une mauvaise redirection de port peuvent laisser txAdmin afficher « en ligne » alors que personne ne vous atteint. Voyez le guide Failed to get info from server et comparez avec l’enregistrement de l’hébergeur.

Quel est le port txAdmin par défaut, et doit-il être public ?

Le port TCP 40120, défini par TXHOST_TXA_PORT, sur toutes les interfaces (TXHOST_INTERFACE vaut 0.0.0.0 par défaut). La documentation de txAdmin consultée ne dit pas s’il doit être public. Les joueurs rejoignent le serveur par les endpoints de server.cfg (30120 par défaut), pas par le panel : nous vous conseillons de n’autoriser 40120 que depuis les IP de vos administrateurs.

Un DDoS peut-il faire redémarrer mon serveur par txAdmin ?

Pas par le seul réseau. Un trafic qui ne fait que remplir le chemin réseau ne peut pas faire échouer le health check, puisqu’il ne quitte jamais la machine. Un flood qui atteint le côté HTTP du port de jeu, que le health check interroge, ou qui bloque la machine assez longtemps le pourrait, et le message de gel de txAdmin cite le DDoS parmi ses raisons possibles. Dans les deux cas, le redémarrage ressemble à un blocage ordinaire, et seule une preuve extérieure à la machine permet de les distinguer. Aucune source consultée ne dit à quelle fréquence cela arrive.

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.