FiveM Failed to get info from server (tried 3 times) : que faire ?

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

La réponse UDP du serveur n’arrive pas, ce qui désigne d’abord le port UDP 30120 et sa redirection, les pare-feu et votre proxy plutôt qu’une attaque.

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

FiveShield n’aide que si le chemin vers votre serveur est attaqué. Si vous utilisez déjà un proxy, son saut UDP est la première chose à vérifier.

Le client a terminé la partie HTTP de la connexion, puis envoyé quatre fois une requête UDP getinfo, à cinq secondes d’intervalle environ, sans réponse. À vérifier d’abord : port UDP 30120 fermé ou non redirigé, endpoint_add_udp absent, proxy qui transporte le TCP mais pas l’UDP, ou (notre lecture) pare-feu Game de l’hébergeur qui bloque l’UDP de votre port de jeu.

Première vérification : depuis un réseau qui n’est pas le vôtre, lancez connect IP:Port dans la console F8 avec votre IP publique et votre port de jeu. Même message : le chemin UDP est coupé. Connexion réussie : le chemin peut fonctionner, examinez donc le joueur en échec.

Ne soupçonnez un DDoS que sur une preuve extérieure à la machine (alerte de l’hébergeur, graphique du trafic entrant, capture) ; ce message seul ne prouve rien.

Messages que vous pouvez voir

  • Failed to get info from server (tried 3 times).

    Fenêtre de connexion du joueur, après quatre requêtes UDP getinfo sans réponse

  • If you are the server owner, are you sure you are allowing UDP packets to and from the server?

    Dans la même fenêtre, sous l’erreur

  • Failed to connect to server after 3 attempts.

    Une étape plus tard : la connexion ENet

  • Handshaking with server...

    Un joueur bloqué ici n’a pas passé le handshake HTTP

  • Failed to fetch /info.json to obtain policy metadata.

    Une étape plus tôt : le GET HTTP de /info.json

Ce que cela signifie vraiment

Rejoindre un serveur suit une séquence (documentation FiveM sur les proxys) : /info.json, initConnect et getEndpoints sur l’endpoint de connexion ; getConfiguration et les téléchargements /files/* sur l’endpoint serveur ou un serveur de fichiers ; puis une requête d’information UDP vers l’endpoint serveur et la connexion ENet. Toutes les étapes avant la requête UDP sont du HTTP sur TCP.

Le message vient de NetLibrary.cpp, côté client. Après les téléchargements, le client affiche Fetching info from server... et envoie en UDP le paquet getinfo xyz, qu’il renvoie dès que plus de cinq secondes ont passé, en ajoutant (attempt 2), (attempt 3). Le client abandonne dès la quatrième requête envoyée, soit environ 15 secondes après la première.

Le client n’accepte la réponse, un paquet infoResponse, que de l’adresse à laquelle il a envoyé getinfo. Le message dit donc une chose : la requête ou sa réponse ne sont pas passées, sans dire pourquoi.

À vérifier en premier (deux minutes)

Les étapes 4 et 5 demandent un terminal sur la machine du serveur.

  1. Quel message voient les joueurs ?

  2. Un seul joueur ou tous, et qu’est-ce qui a changé ?

  3. Rejoignez en Direct Connect depuis l’extérieur de votre réseau

    Appuyez sur F8, puis saisissez votre IP publique et votre port de jeu depuis un partage de connexion mobile ou la ligne d’un ami : depuis votre réseau, le trafic contourne souvent la redirection de votre routeur et le pare-feu de votre fournisseur, donc une réussite ne prouve pas grand-chose.

    connect IP:Port

  4. FXServer écoute-t-il sur le port UDP 30120 ?

    Première ligne sous Linux, seconde dans PowerShell sous Windows. FXServer doit posséder un socket UDP sur votre port de jeu (sous Windows, OwningProcess est l’identifiant du processus).

    ss -lunp
Get-NetUDPEndpoint -LocalPort 30120

    • Aucun socket UDP sur le port, ou un autre programme le possède: Lire la cause 2 : la ligne endpoint_add_udp

    • Aucun processus FXServer: Démarrez le serveur et lisez sa console : il est arrêté, ce n’est pas un problème réseau.

    • FXServer possède le socket UDP: Passer à l’étape 5

  5. Les paquets arrivent-ils, et une réponse repart-elle ?

    Sur la machine qui reçoit le trafic des joueurs (origine ou proxy), capturez pendant qu’un joueur se connecte (Ctrl+C pour arrêter). Droits root requis ; sous Windows, le guide d’OVHcloud cite Wireshark.

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

Causes, classées

Chaque cause indique la vérification qui la tranche.

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 port UDP 30120 est bloqué ou non redirigé

    Documenté

    getinfo voyage en UDP ; toutes les étapes précédentes passaient en TCP. Un pare-feu ou un routeur qui laisse passer le TCP 30120 mais pas l’UDP 30120 donne exactement ce symptôme : les étapes HTTP réussissent, puis quatre requêtes UDP restent sans réponse.

    Comment le confirmer

    Faites l’étape 3 depuis l’extérieur, puis examinez chaque couche : pare-feu du système, routeur ou fournisseur, pare-feu de l’hébergeur. Un site de test de port ne tranche pas (la documentation ne dit pas qu’il teste l’UDP ; un intervenant d’un forum signale l’erreur alors qu’un tel site montrait le port ouvert), ni txAdmin « en ligne » : son health check interroge /dynamic.json depuis la machine du serveur.

    Que faire

    Autorisez l’UDP et le TCP dans les deux sens sur le port de jeu, à chaque couche. Le server.cfg par défaut déclare les deux : endpoint_add_tcp "0.0.0.0:30120" et endpoint_add_udp "0.0.0.0:30120". À domicile, redirigez les deux protocoles.

  2. endpoint_add_udp manque ou utilise un autre port que le TCP

    Documenté

    La documentation décrit endpoint_add_udp comme la commande qui crée l’instance d’hôte UDP, et son adresse et son port doivent être valides et non déjà utilisés. Sans cette ligne, le TCP sert quand même les étapes HTTP et la requête UDP ne trouve personne à l’écoute (notre lecture). txAdmin signale une config sans adresse et port communs aux deux lignes, avec un message qui se termine par Players would not be able to connect.

    Comment le confirmer

    L’étape 4 montre si FXServer possède un socket UDP sur le port ; lisez ensuite server.cfg et chaque fichier qu’il charge avec exec.

    Que faire

    Mettez les deux lignes sur la même adresse et le même port : endpoint_add_udp "0.0.0.0:30120" et endpoint_add_tcp "0.0.0.0:30120". Si un proxy TLS local ne déplace que le port TCP, mettez la ligne UDP en premier, comme le dit la documentation. Libérez le port si un autre processus l’occupe.

  3. Un proxy ou une redirection sans UDP, ou qui publie la mauvaise adresse UDP

    Documenté

    La documentation FiveM distingue deux proxys : l’endpoint de connexion peut être un reverse proxy HTTPS ordinaire, alors que l’endpoint serveur demande un proxy TCP/UDP brut sur des ports identiques. Un relais qui transmet le TCP sans l’UDP laisse passer getConfiguration et les téléchargements, puis la requête UDP n’a nulle part où aller. L’adresse UDP vient de sv_endpoints (vide : votre IP publique détectée automatiquement, pas celle du relais) ; avec plusieurs adresses, le client en choisit une au hasard, donc un relais mort ne fait échouer que certaines connexions. Le client ignore aussi un infoResponse venu d’une autre adresse que celle de son getinfo (notre lecture de NetLibrary.cpp).

    Comment le confirmer

    Rejoignez par le proxy puis, depuis une adresse autorisée, par l’origine : si seule l’origine répond, le relais est en cause. Capturez aux deux bouts (étape 5) pour voir où les paquets s’arrêtent.

    Que faire

    Donnez à l’endpoint serveur son propre relais TCP et UDP brut sur des ports identiques (la documentation montre un bloc nginx stream avec listen 30120; et listen 30120 udp reuseport;), réglez sv_endpoints sur son adresse et laissez le pare-feu de l’origine accepter son UDP.

  4. Un pare-feu Game de l’hébergeur qui bloque l’UDP de votre port de jeu

    Notre déduction

    Le guide du pare-feu Game d’OVHcloud (réservé aux serveurs dédiés Game) fait ajouter, par IP, des règles qui nomment un protocole de jeu et une plage de ports, et recommande vivement « Default Deny », qui bloque tout trafic ne correspondant à aucune règle. Il s’applique après l’Edge Network Firewall, qui ne doit pas être trop strict selon le guide. Le guide ne dit pas comment une règle FiveM traite le TCP et l’UDP ; notre lecture : un port sans aucune règle bloquerait aussi les étapes HTTP (erreur plus tôt), donc ce message désigne une règle qui les laisse passer sans couvrir le côté UDP de votre port.

    Comment le confirmer

    Chez OVHcloud : Network > Public IP Addresses, puis Configure Game firewall sur l’IP des joueurs (règles et option Default Deny) ; le statut Game firewall de l’IP doit être Configured pour que les règles s’appliquent. Network > Network Security Dashboard en mode avancé : état du Firewall et du GAME firewall par IP. Cherchez une règle qui couvre votre port de jeu, 30120 par défaut.

    Que faire

    Ajoutez ou corrigez la règle de votre port de jeu sur cette IP et sur chaque IP supplémentaire qui sert des joueurs. Les règles s’appliquent quelques minutes après l’enregistrement.

  5. Côté joueur : VPN ou réseau domestique

    Retours de propriétaires

    Le client affiche ce message pour n’importe quel serveur : un joueur dont l’UDP ne sort pas de son réseau le voit donc partout (déduit du code client). Dans le seul fil de forum lu, un intervenant signale un VPN dont il a fallu activer l’option UDP, un autre que l’erreur apparaissait derrière un routeur et pas branché directement sur le modem.

    Comment le confirmer

    Essayez d’autres serveurs, un partage de connexion mobile, le VPN coupé (ou activé : un autre intervenant dit qu’un VPN a réglé le problème), le PC branché sur le modem.

    Que faire

    Changez une seule chose à la fois. Si une région entière échoue, retournez aux causes 1 à 4.

  6. Un DDoS, ou une mitigation de l’hébergeur qui bloque l’UDP

    Notre déductionLe cas du DDoS

    Un flood visant le port de jeu peut laisser la requête UDP sans réponse, et la mitigation d’un hébergeur peut bloquer de l’UDP légitime pendant qu’elle filtre (OVHcloud demande aux propriétaires qui constatent des faux positifs de contacter le support). Nous la classons en dernier : les étapes HTTP ont réussi d’abord, et un flood assez fort pour perturber les réponses UDP perturberait en général aussi les étapes HTTP, selon notre raisonnement ; un flood ou un filtre limité à l’UDP ne le ferait pas, d’où sa place dans la liste.

    Comment le confirmer

    Cherchez les preuves extérieures de la section suivante.

    Que faire

    Notez les heures, recueillez ces preuves, puis contactez l’hébergeur avec l’IP de destination, le protocole et le port, en précisant si du trafic légitime est bloqué.

À quoi ressemble un DDoS ici

Ce message seul ne prouve jamais une attaque : il faut une trace relevée hors du jeu, par votre hébergeur ou au niveau de l’interface réseau.

À quoi ressemble un DDoS ici

  • Votre hébergeur signale une attaque sur l’IP des joueurs, aux heures des échecs, par e-mail ou dans son tableau de bord.
  • Les étapes HTTP échouent aussi (Failed to fetch /info.json to obtain policy metadata., ou http://IP:port/info.json cesse de charger depuis l’extérieur), même si une attaque limitée à l’UDP peut les laisser intactes.
  • Des paquets entrants par seconde très au-dessus d’une référence prise un jour calme, ou de l’UDP capturé vers le port de jeu depuis de nombreuses sources dispersées, bien plus nombreuses que vos joueurs.

Preuves que vous pouvez recueillir

  • Le relevé de l’hébergeur

    Demandez les heures, l’IP de destination et les vecteurs (chez OVHcloud, colonnes « Heure de détection », « Heure de fin », « IP de destination » et « Vecteurs d’attaque » de l’onglet « Journal du Centre de nettoyage ») et enregistrez-les vite : un an de conservation pour ce journal, deux mois pour le graphique de trafic. Les adresses sources ne sont pas affichées, car généralement usurpées : rien à bannir.

  • Débit de paquets sur l’interface

    Comparez rxpck/s, les paquets entrants par seconde, à une référence prise un jour calme (première ligne Linux, seconde PowerShell).

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

  • Qui envoie

    Avec les droits root, capturez 2 000 paquets vers le port de jeu et lisez la colonne des sources : quelques adresses de vos joueurs, c’est normal ; de nombreuses sources dispersées, non. La capture ne montre que ce qui survit au filtrage de l’hébergeur : calme, elle ne prouve rien.

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

Ce qui n’y ressemble pas

  • (attempt 2) puis (attempt 3) après Fetching info from server... : les nouvelles tentatives normales, pas un flood.
  • Des échecs limités aux joueurs d’un même fournisseur, VPN ou routeur : cela pointe vers la cause 5, pas vers le chemin de votre serveur.

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

La protection est la réponse quand

  • Le tableau de bord ou l’alerte de l’hébergeur montre une attaque sur l’IP des joueurs, aux heures des échecs.
  • Une capture montre de l’UDP vers le port de jeu depuis de nombreuses sources dispersées, bien plus nombreuses que vos joueurs.

La protection n’est pas la réponse quand

  • endpoint_add_udp manque ou vise un autre port que le TCP.
  • Le port UDP 30120 est fermé sur votre routeur, votre système ou le pare-feu de l’hébergeur : un proxy ne fait que déplacer le saut, qui a besoin de la même règle.

Si le chemin vers votre serveur est attaqué

Quand le relevé de l’hébergeur ou une capture montre une attaque, l’erreur est un symptôme et la solution est en amont : filtrer le trafic avant qu’il atteigne l’adresse qui répond aux joueurs. Ne redémarrez pas à répétition et ne publiez pas de nouvelle IP.

Placez devant le serveur un proxy qui transporte le TCP et l’UDP, restreignez l’origine pour que seul ce proxy l’atteigne, puis changez l’IP d’origine. Testez d’abord le saut UDP (étapes 3 et 5) : une voie UDP non configurée produit précisément cette erreur.

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

Masquez votre IP publique si le fil est public, et ne publiez jamais de mots de passe ni votre clé de licence.

  • Le message exact vu par les joueurs, votre build FXServer et votre version de txAdmin.
  • Vos lignes endpoint_add_tcp, endpoint_add_udp et sv_endpoints, et la sortie de ss -lunp ou de Get-NetUDPEndpoint -LocalPort 30120.
  • Le résultat de Direct Connect depuis l’extérieur, vingt lignes de la capture de l’étape 5 (adresses des joueurs masquées) et les heures des échecs avec votre fuseau horaire.
  • Avec un proxy : son type et sa configuration UDP. Avec un pare-feu d’hébergeur : Default Deny activé ou non, et les règles de l’IP des joueurs. Toute alerte de l’hébergeur.

Questions fréquentes

Failed to get info from server veut-il dire que je suis victime d’un DDoS ?

Pas à lui seul. Quatre requêtes UDP getinfo sont restées sans réponse acceptée alors que les étapes HTTP avaient fonctionné : cherchez d’abord du côté du port UDP, de endpoint_add_udp, d’un proxy ou d’un pare-feu d’hébergeur. Une attaque demande des preuves extérieures à votre machine.

Depuis que j’ai mis un proxy devant mon serveur, tous les joueurs ont cette erreur. Pourquoi ?

Toutes les étapes avant la requête UDP passent en TCP : un relais qui transmet le TCP sans l’UDP les laisse toutes passer. Vérifiez la cause 3 : un relais UDP brut sur des ports identiques, un sv_endpoints qui indique l’adresse des joueurs, et un pare-feu d’origine qui accepte l’UDP du relais.

Quelle différence avec Failed to connect to server after 3 attempts ?

Une autre étape : ce message vient de la connexion ENet, plus loin dans la séquence, donc le getinfo a reçu sa réponse. Mêmes vérifications d’abord ; la documentation ne liste pas ses causes.

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.