Avant de commencer
Notez le message exact, l’heure avec son fuseau, la version de FiveM, l’artifact FXServer et les dernières modifications. Copiez l’adresse et le port affichés dans le panel, sans supposer que le port est 30120. Conservez les journaux côté client et serveur. Avant toute modification de configuration, sauvegardez les fichiers concernés et prévoyez un retour arrière. Masquez les mots de passe, clés de licence, jetons et données personnelles avant de partager un diagnostic.
Déterminer qui est touché et à quel moment
Demandez si le problème concerne un seul joueur, un opérateur internet ou toute la communauté. Comparez une connexion habituelle avec une autre connexion autorisée, sans multiplier les tentatives simultanées. Un échec isolé peut venir du client, d’un DNS, d’une route ou d’un filtrage local. Si tous les joueurs échouent après une mise à jour, commencez par cette modification.
Relevez l’étape affichée et les erreurs de la console F8. Une connexion impossible, un téléchargement qui ne progresse plus et un écran de chargement après téléchargement ne désignent pas le même composant. Testez un changement à la fois et gardez une trace de son résultat.
Vérifier l’adresse et les ports attribués
Dans FiveM, utilisez la console F8 pour essayer une connexion directe à l’adresse et au port de jeu attribués. Ce test permet de séparer la recherche dans la liste publique de la connexion au serveur. Il ne faut pas utiliser le port d’administration txAdmin à la place du port de jeu.
Vérifiez que FXServer a démarré, que ses endpoints correspondent à l’allocation et que les règles réseau couvrent les protocoles nécessaires. Un test TCP réussi ne démontre pas que le trafic UDP fonctionne. Sur un hébergement géré, utilisez les paramètres du panel et demandez une vérification de l’allocation avant de changer les règles de l’hôte.
Isoler les ressources et leurs dépendances
Si le téléchargement ou le chargement bloque, cherchez une ressource nommée dans les erreurs. Contrôlez ses dépendances, ses chemins et les fichiers attendus. Une ressource incompatible ou absente peut produire un échec même avec des ressources matérielles disponibles. Les accès à la base de données doivent également fonctionner lorsque le framework en dépend.
Reproduisez le problème sur une copie de test avec un ensemble minimal de ressources, puis réintroduisez les ajouts progressivement. Ne désactivez pas au hasard les scripts d’une communauté en production. Contrôlez le volume des fichiers et l’espace libre : déplacer une ressource lourde vers un cache ne corrige pas ses erreurs de script ou de dépendance.
Distinguer proxy de connexion, fichiers et trafic de jeu
Un reverse proxy HTTP peut traiter une partie de la connexion et du téléchargement. Le trafic de jeu utilise aussi un endpoint distinct, notamment en UDP. Un site accessible ou une réponse HTTP de FXServer ne valide donc pas tout le trajet suivi par un joueur. Examinez chaque composant et les journaux du proxy si votre architecture en possède un.
Comparez les adresses annoncées, les endpoints de connexion et la destination des fichiers avec la documentation de votre version. Une adresse d’origine exposée peut contourner une protection distante. Faites confirmer les routes et les flux couverts avant de filtrer l’origine : bloquer un service légitime, la voix ou un port requis peut aggraver la panne.
Contrôler la charge et la compatibilité des artifacts
Examinez CPU, mémoire, stockage et journaux pendant le problème. Un pic ponctuel ne suffit pas à conclure ; cherchez une corrélation avec les échecs et les scripts en cours. Un processeur saturé, une erreur de base de données ou un disque plein peut ralentir le chargement sans attaque réseau.
Avant de changer d’artifact, vérifiez les prérequis du framework et des ressources, sauvegardez puis testez une version choisie. FiveM pour GTA V Enhanced introduit des changements incompatibles avec certaines configurations Legacy. La disponibilité d’un artifact récent ne certifie pas automatiquement la compatibilité de votre installation, de vos scripts ou du modèle d’hébergement.
Transmettre un diagnostic exploitable
Si le problème persiste, préparez l’heure, les réseaux touchés, l’étape de chargement, les erreurs utiles et les tests déjà faits. Ajoutez la version du serveur, la dernière modification et les mesures correspondantes. Le support peut alors comparer les journaux d’application, les allocations de ports et les informations réseau sans vous faire recommencer toute la recherche.
En cas de suspicion d’attaque, demandez une corrélation avec les événements de mitigation ou les mesures du réseau. Un timeout seul ne démontre pas un DDoS. Évitez les redémarrages en boucle, les tests de charge improvisés et les désactivations globales de sécurité : ils peuvent masquer le problème ou créer une panne supplémentaire.
Selon votre situation
| Situation | Prochaine vérification |
|---|---|
| Un joueur échoue | Comparer son message, son client, son DNS et sa connexion avec un joueur qui réussit. Vérifier ensuite si un opérateur ou une route particulière est concerné. |
| Les fichiers ne se chargent pas | Examiner les erreurs de ressource et les destinations HTTP ou de cache. Vérifier les fichiers et leurs dépendances avant de modifier le trafic de jeu. |
| Tous les joueurs échouent | Contrôler le démarrage, l’allocation de ports, la dernière modification et les journaux. Demander des preuves réseau avant de conclure à une attaque. |
Sources officielles
Ces documents décrivent les protocoles et logiciels concernés. Les conditions de votre service et sa configuration restent à vérifier.