FiveM bloqué sur Downloading content : pourquoi le téléchargement est lent et comment l’accélérer

Mis à jour le

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

VerdictNe prouve pas un DDoS à lui seul

Regardez d’abord votre bande passante sortante, la façon dont vos fichiers sont servis et la machine du joueur : un téléchargement lent ne montre pas à lui seul une attaque.

FiveShield aide pour une partie du problème

En partie : FiveShield ne concerne que la moitié côté serveur, un cache devant vos fichiers, et le cache nginx classique du cookbook officiel applique le même mécanisme.

Un joueur bloqué sur Downloading content attend des fichiers de votre serveur ou de votre serveur de fichiers. Cette page classe en premier trois causes : une bande passante sortante que de nombreux nouveaux joueurs saturent en même temps, un réglage de cache ou de serveur de fichiers qui rejette ou corrompt les requêtes, et le disque ou la connexion du joueur. Un DDoS reste possible, mais ce symptôme ne peut pas le démontrer à lui seul.

Vérifiez d’abord s’il s’agit d’un seul joueur ou de tout le monde (étape 2), puis si votre trafic sortant est saturé pendant l’attente (étape 3). Si la bande passante sortante est la limite, servez /files depuis un cache enregistré avec fileserver_add, comme le décrit le cookbook officiel ; si vous en avez déjà un, testez-le d’abord (cause 2).

Pour ce symptôme, ne soupçonnez un flood de requêtes de fichiers que si les adresses qui reçoivent vos fichiers ne sont pas vos joueurs.

Messages que vous pouvez voir

  • Downloading content

    Sur l’écran de connexion pendant que le client télécharge /files/* depuis votre serveur ou le serveur de fichiers déporté

  • Downloading completed

    Sur l’écran de connexion une fois l’étape des fichiers terminée

  • Failure downloading %s: %s

    Dans l’erreur que le client signale quand un fichier échoue de façon répétée ; le journal du client contient une ligne voisine, ResourceCacheDevice reporting failure downloading ...

  • %s hash %s does not match %s

    Dans le journal du client quand un fichier téléchargé échoue à la vérification SHA-1

  • Host %s is not allowed to access this endpoint.

    Dans le corps du 403 de votre serveur de fichiers quand sv_httpFileServerProxyOnly est activée et que le demandeur est hors de sv_proxyIPRanges

  • Not found. (missing requested file: %s/%s)

    Dans le corps du 404 de votre serveur de fichiers quand le fichier demandé n’est ni un fichier empaqueté de la ressource ni un fichier de streaming

Ce que cela signifie vraiment

Le client affiche Downloading content dès que votre serveur a accepté la connexion, puis Downloading completed quand il signale que les téléchargements sont terminés (NetLibrary.cpp). Ce sont des lignes de progression, pas des erreurs ; l’étape UDP, Fetching info from server..., vient après elles.

Les fichiers viennent de GET /files/*, servi par votre FXServer sauf si vous avez enregistré un serveur de fichiers déporté avec fileserver_add (documentation du proxy). FilesHttpHandler.cpp n’accepte que GET, ne répond que pour les fichiers empaquetés d’une ressource (resource.rpf et les éventuelles archives file_set, d’après ResourceFilesComponent.cpp) et ses fichiers de streaming, et les envoie depuis le disque, qu’un client en cours de connexion corresponde ou non.

Le client cherche chaque fichier par SHA-1 dans son propre cache (fichiers nommés cache_<hash>) et recalcule le hash de la copie en cache ; seul un fichier absent ou différent est téléchargé (ResourceCache.cpp, ResourceCacheDeviceV2.cpp). Les nouveaux joueurs, ceux qui ont vidé leur cache et tout le monde après une modification de ressource téléchargent le plus.

Une requête échouée est retentée. À notre lecture de ResourceCacheDeviceV2.cpp, un fichier reçoit jusqu’à cinq tentatives, avec une attente de 1, 2, 4, 8 puis 16 secondes après les échecs successifs (valeur par défaut de cl_rcdFailureBackoff : 500 millisecondes) : un seul fichier impossible à livrer peut bloquer sa ressource plus d’une demi-minute avant que le client signale une erreur. Nous ne l’avons pas chronométré sur un client réel.

À vérifier en premier (deux minutes)

Quatre questions distinguent votre serveur, votre cache et la machine du joueur.

  1. Sur quelle ligne l’écran de connexion est-il bloqué ?

    Demandez le texte exact. Parmi les lignes que le client affiche, celles-ci se suivent dans cet ordre : Handshaking with server..., Downloading content, Downloading completed, Fetching info from server..., Connecting to server... (d’après NetLibrary.cpp).

  2. Est-ce un seul joueur, ou tous ceux qui se connectent ?

    Faites rejoindre ensemble deux ou trois joueurs sur des connexions différentes, dont un qui ne s’est jamais connecté à votre serveur.

  3. Votre lien sortant est-il saturé pendant l’attente ?

    Relevez le débit émis sur l’interface publique et comparez-le au débit sortant de votre offre (txkB/s est en kibioctets par seconde : multipliez par 0,008192 pour obtenir des Mbit/s). Sous Windows, utilisez Get-Counter -Counter '\Network Interface(*)\Bytes Sent/sec' -Continuous, en octets par seconde (divisez par 125 000 pour obtenir des Mbit/s). Les noms de compteurs sont traduits sous un Windows non anglophone et le chemin anglais échoue alors ; sous Windows en français, essayez Get-Counter -Counter '\Interface réseau(*)\Octets envoyés/s' -Continuous, ou listez les vôtres avec Get-Counter -ListSet *.

    sar -n DEV 1 10

  4. Servez-vous déjà /files depuis un cache ?

    Dans la console du serveur, fileserver_list affiche chaque serveur de fichiers enregistré sous la forme <motif de ressource> -> <url> et n’affiche rien s’il n’y en a aucun (le cookbook la documente ; GetConfigurationMethod.cpp l’implémente). Vous pouvez aussi chercher fileserver_add dans server.cfg. Sans serveur de fichiers enregistré, FXServer répond lui-même à chaque requête de fichier. Cherchez aussi sv_httpFileServerProxyOnly.

    fileserver_list

Causes, classées

Votre propre capacité et votre configuration d’abord, puis le côté joueur, puis les transferts qui échouent, et le cas de l’attaque en dernier. Le badge indique d’où vient chaque affirmation.

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. Trop de données pour votre bande passante sortante : nombreux nouveaux joueurs, gros assets

    Notre déduction

    Sauf si un serveur de fichiers déporté les sert, chaque fichier qui manque à un nouveau joueur sort de votre serveur par GET /files/* et partage votre lien avec le trafic de jeu de tous les connectés. Servir une vague de connexions prend au moins (octets par nouveau joueur × nombre de nouveaux joueurs) ÷ bande passante sortante. À titre d’illustration seulement : 40 nouveaux joueurs qui téléchargent chacun 1,5 Go font 60 Go, soit environ huit minutes à 1 Gbit/s si rien d’autre ne circule.

    Comment le confirmer

    Pendant l’attente, relevez txkB/s avec sar -n DEV 1 10 sur l’interface publique et comparez-le au débit sortant de votre offre. Triez ensuite par taille le dossier de chaque ressource démarrée : un dossier surestime ce que reçoivent les joueurs (les scripts serveur, par exemple, ne sont pas dans resource.rpf), mais une ressource qui domine la liste est la première piste.

    Que faire

    Déchargez l’origine avec un proxy de cache enregistré par fileserver_add, comme le montre le cookbook officiel avec nginx, et testez-le d’abord (cause 2). Retirez les ressources inutilisées, remplacez les packs trop lourds par des versions plus légères et évitez les mises à jour aux heures de pointe. Un cache ne rend pas un fichier plus petit, et la documentation du serveur ne liste aucune convar qui accélère le serveur de fichiers intégré.

  2. Le cache devant vos fichiers est périmé ou mal réglé

    Documenté

    Le cookbook, publié en 2019, décrit adhesive_cdnKey comme « required to not get corrupted cache entries » et prévient qu’il n’existe pas d’invalidation du cache fondée sur les hashes : videz donc le cache avant de modifier ou de redémarrer une ressource. Le client rejette un fichier dont le SHA-1 diffère de celui annoncé (ResourceCacheDeviceV2.cpp), le retélécharge et abandonne au bout de cinq tentatives. À notre lecture, le client ajoute ?hash=<sha1> à ses URL de fichiers (CachedResourceMounter.cpp) et le serveur ignore cette query (FilesHttpHandler.cpp) : un cache dont la clé reprend l’URL complète, comme celui du cookbook, enregistre un fichier modifié comme une nouvelle entrée, alors qu’un cache réglé pour ignorer la query string continue de servir l’ancien fichier. Un cache peut aussi oublier des fichiers : nginx supprime ce qui n’a pas été demandé pendant la durée inactive (10 minutes par défaut ; le proxy_cache_path du cookbook ne la définit pas) et évince les données les moins récemment utilisées au-delà de max_size.

    Comment le confirmer

    Connectez-vous avec un compte de test et lisez le journal d’accès du cache, où la configuration du cookbook journalise chaque requête avec $status et $upstream_cache_status : MISS pour chaque joueur signifie que le fichier n’est pas conservé, HIT qu’il l’est, un 403 que le serveur de fichiers refuse la requête (cause 3) et un 404 que le serveur de fichiers ne connaît pas ce fichier pour cette ressource. Ou demandez deux fois une URL relevée dans le journal et lisez l’en-tête X-Cache-Status que le cookbook renseigne.

    Que faire

    Définissez adhesive_cdnKey, retirez toute barre oblique finale de l’URL de fileserver_add, gardez la query string dans la clé de cache, dimensionnez inactive et max_size pour vos fichiers (l’exemple de la page du proxy utilise max_size=20g et inactive=2h) et videz le cache quand une ressource change.

  3. Le serveur de fichiers refuse les requêtes : sv_httpFileServerProxyOnly

    Documenté

    sv_httpFileServerProxyOnly (par défaut false) limite le serveur de fichiers aux adresses comprises dans sv_proxyIPRanges (par défaut 10.0.0.0/8 127.0.0.0/8 192.168.0.0/16 172.16.0.0/12). FilesHttpHandler.cpp répond à tous les autres par un 403 et Host %s is not allowed to access this endpoint., sauf pour un fichier nommé resource.rpf. Activée sans cache devant, ou avec l’adresse du cache hors des plages, elle refuse tous les autres fichiers, et le client réessaie chacun avant d’abandonner.

    Comment le confirmer

    Cherchez-la dans server.cfg. Si elle vaut true, vérifiez qu’un motif fileserver_add pointe vers votre cache et que l’adresse depuis laquelle votre serveur voit le cache se connecter est comprise dans sv_proxyIPRanges.

    Que faire

    Mettez-la à false, ou ajoutez l’adresse du cache telle que votre serveur la voit (l’exemple de la page du proxy utilise set sv_proxyIPRanges "100.64.1.1/32") ; derrière un terminateur TLS ou une couche semblable, c’est l’adresse de cette couche.

  4. La machine ou le réseau du joueur

    Retours de propriétaires

    Le client écrit chaque fichier dans son dossier de cache, le hache et le renomme dans le cache, puis recalcule le hash des fichiers en cache avant de les réutiliser (ResourceCache.cpp, ResourceCacheDeviceV2.cpp). Un disque lent ou plein, un logiciel de sécurité qui analyse les nouveaux fichiers ou une mauvaise ligne peuvent ralentir ces étapes ; c’est notre raisonnement, et la page officielle des problèmes client ne rattache l’antivirus qu’aux problèmes de lancement : cette cause repose sur des réponses dans des fils du forum Cfx.re, pas sur la documentation.

    Comment le confirmer

    Faites rejoindre au joueur un autre serveur, ou le vôtre depuis un autre réseau. Si seul le vôtre est lent pour lui, regardez de votre côté ; si tous les serveurs sont lents, c’est sa machine ou sa ligne.

    Que faire

    Libérez de la place sur le disque, vérifiez si un logiciel de sécurité ou un filtre d’URL analyse ou bloque les nouveaux fichiers, essayez un autre réseau avec le VPN coupé puis activé, et videz le cache du client en dernier, car tout est alors retéléchargé.

  5. Les transferts sont coupés en cours de route

    Retours de propriétaires

    Des fils de joueurs sur le forum Cfx.re citent des erreurs de client comme Failure downloading resource.rpf: transfer closed with 12324864 bytes remaining to read - CURL error code 18 (Transferred a partial file) ; libcurl documente le code 18 ainsi : « A file transfer was shorter or larger than expected. » La ligne ne dit pas qui a coupé le transfert : votre serveur, un proxy ou un cache intermédiaire, ou le réseau du joueur. Les réponses que nous avons lues désignent la connexion ou la machine du joueur et ne montrent aucun correctif confirmé.

    Comment le confirmer

    Recueillez les lignes du journal autour de l’échec chez un joueur concerné, et regardez si des joueurs sur d’autres réseaux le subissent au même moment. Si plusieurs le font, regardez de votre côté : bande passante sortante (cause 1), journaux et délais d’attente du cache (cause 2).

    Que faire

    Un seul joueur : sa ligne (cause 4). Plusieurs en même temps : réduisez la charge de l’origine (cause 1) et lisez les journaux d’erreurs de votre cache et de votre proxy à la recherche de délais d’attente ou de coupures en amont.

  6. Un flood de téléchargements

    Notre déductionLe cas du DDoS

    /files/* est un simple GET auquel FXServer répond, pour un fichier existant, même quand aucun client en cours de connexion ne correspond (FilesHttpHandler.cpp) : un flood de requêtes de fichiers est donc techniquement possible. La documentation ne décrit pas de limite par adresse pour cela : son tableau des rate limiters cite res_http_handler et resourceList sans dire ce qu’ils limitent, et FilesHttpHandler.cpp n’appelle aucun limiteur. Sa fréquence est inconnue ; rien de ce que nous avons lu ne la mesure.

    Comment le confirmer

    Comparez qui reçoit vos fichiers et qui est connecté, et lisez le graphique de votre hébergeur (section suivante).

    Que faire

    Placez les fichiers derrière un cache et définissez sv_httpFileServerProxyOnly avec un sv_proxyIPRanges correct, sans oublier l’exception de resource.rpf. Si votre hébergeur ou une capture confirme une attaque, suivez le guide sur les pics de trafic.

À quoi ressemble un DDoS ici

L’attaque qui correspond à ce symptôme est un flood de requêtes de fichiers, et le symptôme ne peut pas le montrer : une vague de connexions et un flood saturent tous deux votre lien sortant. Ce qui les sépare, c’est qui reçoit les données ; des adresses qui ne sont pas vos joueurs changeraient le verdict. Un flood de paquets dirigé vers votre serveur est un autre problème, avec une autre signature (voir le guide sur les pics de trafic).

À quoi ressemble un DDoS ici

  • Le lien sortant reste saturé sans vague de connexions derrière : pas d’événement, de redémarrage ni de ressource modifiée, et votre nombre de joueurs n’explique pas le volume.
  • Une courte capture montre de nombreuses adresses qui reçoivent du trafic de fichiers de votre serveur sans correspondre à aucun joueur connecté. Le journal d’accès d’un cache montre la même chose depuis l’extérieur du serveur de jeu.
  • Le graphique de votre hébergeur montre un volume sortant que votre nombre de joueurs n’explique pas. Exportez-le avant de changer quoi que ce soit : les hébergeurs ne conservent les graphiques que pendant une durée limitée (voir le guide sur les pics de trafic).

Preuves que vous pouvez recueillir

  • Sens et débit sur l’interface publique

    Le trafic de téléchargement sort de votre machine : comparez txkB/s (émis) à rxkB/s (reçu). Un flood de paquets dirigé vers vous apparaît dans les paquets reçus (rxpck/s) et c’est un autre problème. Relevez une référence un jour calme.

    sar -n DEV 1 10

  • Qui reçoit vos fichiers

    Sous Linux, une courte capture de ce que votre serveur envoie depuis son port de jeu TCP, qui sert aussi /files (30120 par défaut ; la capture peut exiger des droits élevés). Lisez chaque destination et comparez les adresses à vos joueurs d’après vos propres enregistrements : la documentation ne décrit aucun journal de téléchargement intégré. Derrière un cache ou un proxy, vous verrez son adresse et non celle des joueurs : lisez plutôt son journal d’accès.

    tcpdump -n -i <iface> -c 2000 'tcp src port 30120'

Ce qui n’y ressemble pas

  • Un pic de trafic sortant juste après un redémarrage, une mise à jour ou un événement avec beaucoup de nouveaux joueurs est une vague de connexions (cause 1) ; il s’arrête quand les téléchargements s’arrêtent.
  • Un seul joueur lent, ou des joueurs sur un même réseau, pointe vers le côté joueur (cause 4). Un trafic sortant faible pendant que les joueurs attendent signifie que le volume n’est pas la limite (causes 2, 3 et 5).

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

Ici, « protection » désigne un cache devant /files : il garde chaque fichier après la première requête et répond lui-même aux requêtes répétées pour la même URL. Le cookbook officiel montre nginx ; un CDN géré est une autre façon de l’exploiter. Cette page n’a mesuré le cache d’aucun fournisseur, et tout ce qui suit fonctionne avec un cache que vous exploitez vous-même.

La protection est la réponse quand

  • Le lien sortant est saturé pendant que de nombreux joueurs téléchargent des fichiers qu’ils n’ont pas encore, et le calcul de la cause 1 indique que la bande passante sortante est la limite.
  • Vous avez confirmé un flood de requêtes de fichiers depuis des adresses qui ne sont pas vos joueurs : un cache répond aux requêtes répétées pour une même URL, et, avec le cache enregistré par fileserver_add, sv_httpFileServerProxyOnly et un sv_proxyIPRanges correct font refuser les autres demandeurs par l’origine, sauf pour resource.rpf.

La protection n’est pas la réponse quand

  • Un seul joueur, ou des joueurs sur un même réseau, sont lents : rien devant votre serveur ne change leur disque, leur logiciel de sécurité ou leur ligne (cause 4).
  • Le trafic sortant est faible pendant que les joueurs attendent : la bande passante sortante n’est pas la limite, et une couche devant une requête refusée (cause 3) ou un cache périmé (cause 2) masque la panne. Regardez plutôt les causes 4 et 5.
  • Les assets sont énormes : un cache ne rend pas un fichier plus petit, donc le premier téléchargement de chaque fichier traverse quand même le lien (cause 1).

Anti-DDoS FiveM : comment fonctionne FiveShield

Toujours bloqué ? Ce qu’il faut publier

Collez ces éléments quand vous demandez de l’aide à un hébergeur ou à une communauté.

  • Le texte exact de l’écran de connexion et le temps pendant lequel il est resté affiché.
  • Le numéro de build de votre FXServer, le résultat de fileserver_list, et si sv_httpFileServerProxyOnly est définie.
  • Le débit émis pendant le blocage (sar -n DEV 1 10, txkB/s ; Bytes Sent/sec sous Windows) et le débit sortant de votre offre.
  • Chez un joueur concerné, le texte de toute erreur affichée à l’écran et les lignes du journal du client qui mentionnent failure downloading ou CURL error code (recherche sans tenir compte de la casse), et si ce joueur est lent sur d’autres serveurs (les pages officielles que nous avons consultées n’indiquent pas l’emplacement du journal).
  • Si vous exploitez un cache, quelques lignes du journal d’accès avec leur $upstream_cache_status, et ce qui a changé juste avant le début.

Questions fréquentes

Un téléchargement de ressources lent est-il le signe d’un DDoS ?

Pas à lui seul. Une bande passante sortante saturée, un réglage de cache ou de serveur de fichiers et la machine du joueur le produisent tous, et une vague de connexions et un flood se ressemblent sur votre lien sortant ; seules les adresses qui reçoivent les fichiers les distinguent. Un flood de requêtes de fichiers est techniquement possible, puisque /files/* sert un fichier existant à toute requête GET, sans client en cours de connexion, mais rien de ce que nous avons lu ne mesure sa fréquence.

Ai-je besoin d’un CDN pour accélérer le téléchargement des ressources FiveM ?

Non. Un CDN est une façon d’exploiter un cache. Le cookbook officiel montre le même mécanisme avec nginx : fileserver_add, adhesive_cdnKey, et vider le cache quand une ressource change. Savoir si un cache géré est plus rapide que le vôtre, cette page ne l’a pas mesuré.

Pourquoi seuls les nouveaux joueurs sont-ils bloqués, et un redémarrage fait-il tout retélécharger ?

Le client conserve les fichiers téléchargés dans son propre cache, nommés par SHA-1, et ne demande que les fichiers qui lui manquent ou dont la copie en cache échoue à la vérification du hash. Les joueurs qui reviennent récupèrent ce qui a changé, les nouveaux récupèrent tout (cause 1). À notre lecture du code serveur (ResourceFilesComponent.cpp, ResourceFileDatabase.cpp, ResourceConfigurationCacheComponent.cpp), le serveur ne reconstruit le resource.rpf d’une ressource que si un fichier qu’il contient a été ajouté, retiré ou modifié, et annonce le SHA-1 du paquet qu’il détient : un redémarrage qui ne touche aucun fichier ne devrait donc pas faire retélécharger les joueurs qui reviennent. Nous ne l’avons pas testé sur un serveur réel, ni comparé octet par octet un paquet reconstruit.

Sources et versions vérifiées

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

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.