Comment déboguer un serveur FiveM étape par étape

Déboguez un problème FiveM en reproduisant un symptôme, en trouvant la première erreur pertinente et en modifiant une cause sur un serveur de test. Conservez les derniers fichiers fonctionnels et la base de données correspondante avant de toucher à la production.

Choisissez les bonnes preuves

Un crash client uniquement ou une erreur d’interface utilisateur nécessite la sortie F8 du joueur affecté et les étapes de reproduction. Une sortie de processus serveur nécessite les logs FXServer/hôte et toute référence de crash. Un chargement lent nécessite un chronométrage par étape ; un faible FPS nécessite des preuves de temps de trame client. Plusieurs joueurs qui laguent ensemble peuvent nécessiter des mesures de serveur et de réseau.

Enregistrez l’heure UTC, les joueurs affectés, l’emplacement, l’action, l’artefact, les versions du framework/ressource et les changements récents. Masquez les identifiants et les informations personnelles des logs partagés.

Lisez la première erreur

Utilisez votre environnement de lancement réel : la console txAdmin et ses logs configurés, un journal de service ou une sortie de processus redirigée. Il n’existe pas de chemin server-data/server.log universel pour chaque installation.

Lisez la première erreur liée à la ressource, avec le fichier, le numéro de ligne et la trace de pile. Des exports manquants signalés ensuite peuvent résulter de l’échec antérieur d’une dépendance. Pour une valeur nil, examinez le code qui la produit et la manière dont elle est renvoyée avant d’insérer une valeur par défaut.

Reproduisez en toute sécurité

1. Créez une copie isolée avec une configuration représentative et des données de test. Confirmez que l’erreur s’y produit toujours.
2. Vérifiez les dépendances, les noms de dossiers exacts et l’ordre de démarrage avant de modifier la logique. Sur un hôte sensible à la casse, la capitalisation du chemin de fichier est importante.
3. Réduisez la reproduction à l’ensemble de ressources affectées le plus petit tout en préservant les dépendances requises. Désactivez un suspect à la fois.
4. Appliquez une correction ciblée, répétez l’action d’origine et testez le chemin d’échec pertinent avec un joueur non privilégié.
5. Reconnectez-vous, redémarrez la ressource et effectuez un redémarrage complet du serveur. Ne conservez la correction que si la persistance et les autorisations restent correctes.

Utilisez les diagnostics à leur fin réelle

Le référence des commandes de serveur documente refresh, ensure et restart. Ces commandes peuvent perturber l’état des ressources actives ; utilisez-les en préproduction ou pendant une maintenance coordonnée.

se_debug true active la journalisation ACL/sécurité, pas un mode de débogage de script général. Désactivez-le avec se_debug false après l’enquête sur les autorisations. Un set debug_mode true personnalisé n’a aucun effet à moins qu’une ressource ne lise explicitement cette convar.

Consultez profileur pour l’exécution du script. Resmon est côté client et ne rapporte pas le temps de requête de la base de données ni le coût total du GPU.

Transmettez un rapport utile au support

Incluez le comportement attendu par rapport au comportement réel, les étapes de reproduction exactes, la première erreur complète, les versions pertinentes et ce qui a changé. Fournissez un petit extrait de configuration avec les secrets supprimés. Gardez les dumps de ressources non liés et les données des joueurs privés.

Si le problème de production s’aggrave, restaurez la ressource/configuration la plus récemment acceptée. Restaurez une base de données uniquement si nécessaire et après avoir pris en compte la progression plus récente des joueurs.