Ton serveur Minecraft est attaqué ou il lague juste ?

Tes joueurs rubber-bandent. Les logins timeout. Le serveur stutter, puis disparaît de la liste multijoueur. Vu du siège du joueur, une attaque DDoS et un gros lag sont identiques. Mauvaise réponse et tu perds une heure à tuner la view distance pendant qu’un attaquant garde ton serveur offline, ou tu accuses un attaquant alors qu’un redstone clock parti en sucette bouffe ton CPU.

Ce guide te montre comment savoir si ton serveur Minecraft est attaqué ou juste en train de laguer. Tu vas apprendre les signaux que chaque problème laisse derrière lui, les vérifications in-game et en ligne de commande à faire, et ce que chaque résultat indique.

À retenir : un vrai lag montre un CPU occupé à faire du vrai travail de jeu et un TPS bas que tu remontes aux entités, aux chunks ou à la redstone. Une attaque montre du trafic que tes joueurs n’ont pas généré : un pic de bande passante sans nouveaux logins, ou des milliers de tentatives de connexion qui inondent ta console. Confirme quel pattern tu as avant de toucher quoi que ce soit.

Comment un serveur Minecraft attaqué imite un lag ordinaire

Les deux problèmes finissent pareil pour le joueur. Timeouts, déconnexions massives, mobs figés, et un serveur que personne n’atteint. Les symptômes se chevauchent parce que les deux affament le même résultat : le serveur qui répond aux joueurs à temps.

L’asphyxie se produit à des endroits différents. Une attaque volumétrique affame le lien réseau. Un flood de bots affame le gestionnaire de connexions. Un lag ordinaire affame le thread principal. Trois goulets d’étranglement, un seul symptôme partagé. C’est pour ça qu’une mauvaise réponse te coûte cher. Tuner le chargement de chunks ne fait rien contre un flood de paquets, et ajouter de la bande passante ne fait rien contre une machine redstone qui fait 200 block updates par tick.

La question prend plus d’importance à chaque saison. Les données DDoS de Cloudflare montrent que les attaques ont fortement augmenté en 2025, les floods au niveau réseau étant à l’origine de la majeure partie de la croissance, et le gaming reste l’un des secteurs les plus ciblés. L’été, les tournois et les campagnes de dons sont les fenêtres de pointe, parce qu’un serveur offline te coûte le plus à ce moment-là.

Les trois choses que les gens appellent lag

Avant de diagnostiquer quoi que ce soit, sépare ce que veut dire lag. Ça se divise en trois types, chacun mesuré différemment.

• Lag de TPS serveur. Le serveur n’arrive pas à finir son travail dans le budget de tick. Minecraft vise 20 ticks par seconde, un tick toutes les 50 millisecondes. Quand un tick dure trop longtemps, le TPS baisse et le monde entier ralentit. Tout le monde le sent en même temps.
• Lag réseau. Les paquets entre les joueurs et le serveur prennent trop de temps ou sont droppés. Le TPS est correct. Les joueurs voient un ping élevé et du rubber-banding.
• Lag client. FPS bas sur la machine d’un seul joueur. Le serveur va bien. Les autres joueurs aussi.

Le découpage te dit où regarder. Si chaque joueur lague en même temps, la cause est côté serveur ou côté réseau. Si un seul joueur lague tout seul, c’est sa machine ou sa connexion. Une attaque DDoS vit dans les couches réseau et connexion, donc elle apparaît comme tout le monde en galère en même temps.

Signes d’une attaque DDoS sur un serveur Minecraft

Une attaque laisse des empreintes. Elles diffèrent selon le type d’attaque, donc vérifie les deux.

Attaques volumétriques : Layer 3 et 4

Une attaque volumétrique inonde ton lien réseau de paquets UDP ou TCP depuis un botnet. Le but est de saturer la bande passante avant que le trafic n’atteigne le processus Minecraft. Signaux à chercher :

• Les joueurs ne peuvent pas se connecter ou se prennent des timeouts instantanés, mais ton TPS est normal. La game loop est saine. Le tuyau qui mène à elle est bloqué.
• La bande passante entrante pique sans hausse correspondante du nombre de joueurs. Les vrais joueurs apportent quelques centaines de kbps chacun. Un flood apporte des gigabits sans que personne ne rejoigne.
• Le pic démarre et s’arrête brutalement. La plupart des attaques sont courtes, souvent moins de dix minutes, et beaucoup reviennent en rafales.
• Ton hébergeur ou ton fournisseur upstream signale du trafic sur leur netflow. Ils voient la saturation du lien que tu ne peux pas voir depuis l’intérieur du serveur.

Floods de bots et spam de login : Layer 7

Une attaque Layer 7 n’a pas besoin de bande passante massive. Elle abuse du protocole Minecraft lui-même. Les bots ouvrent connexion sur connexion, rejoignent et se déconnectent en boucle, ou envoient des paquets de handshake malformés. Signaux :

• Ta console serveur se remplit de lignes de connexion, login et déconnexion à un rythme qu’aucune communauté humaine ne produit.
• Les mêmes pseudos ou des noms style UUID aléatoires apparaissent et disparaissent en quelques secondes.
• Les slots joueurs se remplissent de comptes qui ne bougent ni ne chattent.
• Le flood arrive depuis beaucoup d’IPs qui tournent, donc bannir une adresse ne change rien.

Un flood de bots apparaît clairement dans tes logs parce que le trafic atteint le processus Minecraft. Un flood volumétrique ne montre souvent rien dans ces logs, parce que les paquets n’atteignent jamais le processus. L’emplacement de la preuve est lui-même un indice.

Pourquoi mon serveur Minecraft lague sans attaque

Si tes vérifications ne montrent pas de trafic d’attaque, la cause est la performance. Le vrai lag remonte généralement à un de ces points :

• Trop d’entités. Mob farms, items au sol et item frames coûtent chacun du tick time. Quelques milliers d’entités dans des chunks chargés vont tirer le TPS vers le bas.
• Trop de chunks chargés. Joueurs dispersés sur la carte, chunk loaders et view distance élevée gardent plus de chunks actifs que ton CPU n’en gère.
• Redstone et hoppers. Les cascades de redstone complexes déclenchent des block updates à chaque tick. Les hoppers cherchent des items constamment, même vides.
• Un single core faible. Minecraft fait la majeure partie du travail sur un seul thread. La vitesse mono-cœur du CPU compte plus que le nombre de cœurs.
• Mémoire basse. Trop peu de RAM force des pauses fréquentes de garbage collection, ressenties comme des freezes périodiques.

Le trait commun : le CPU est occupé à faire du vrai travail de jeu. Une attaque ne fait pas calculer plus à ton serveur. Elle empêche le trafic légitime de passer. Cette différence est le cœur du diagnostic.

Lag Minecraft ou DDoS : un diagnostic en cinq minutes

Fais ces vérifications dans l’ordre. Arrête-toi quand la preuve pointe clairement dans une direction.

1. 1

   Vérifie TPS et tick time

   Lance /tps et /mspt sur Paper ou un fork. TPS proche de 20 avec un MSPT bas signifie que la game loop est saine, donc un ralentissement pointe vers le réseau. TPS bas avec MSPT au-dessus de 50 ms signifie que le thread principal est en retard : un problème de performance, pas une attaque.

2. 2

   Profile le thread principal

   Si le MSPT est élevé, lance un profil Spark ou timings. Il nomme le plugin, l'entité ou la mécanique qui bouffe du tick time. Un coupable clair confirme un vrai lag.

3. 3

   Compare la bande passante au nombre de joueurs

   Ouvre le graphique de trafic de ton panel d'hébergeur. Des gigabits entrants sans hausse correspondante de joueurs sont une attaque volumétrique. Un trafic qui monte au pas avec ton nombre de joueurs est normal.

4. 4

   Compte les connexions sur la machine

   Sur Linux, lance ss pour compter les sockets sur ton port Minecraft. Des centaines ou milliers de connexions semi-ouvertes ou qui cyclent rapidement depuis beaucoup d'IPs signalent un flood.

5. 5

   Lis la console et les crash logs

   Un mur de spam de login et de déconnexion signifie un flood de bots. Un log propre avec une chute réseau soudaine pointe vers une attaque volumétrique en amont.

Le compte de connexions et la lecture de la console sont les indicateurs les plus rapides. Voici à quoi ressemble un flood de bots sur une machine Linux :

Quatre mille sockets sur le port Minecraft avec une petite communauté n’est pas un trafic normal. Combine ça avec des lignes de console qui défilent à travers beaucoup d’adresses IP à chaque seconde et tu as un flood de bots, pas du lag.

Ce tableau résume dans quelle direction chaque signal pointe :

Le pattern de crash compte aussi. Si ton serveur Minecraft continue de crasher, lis quand et comment. Un crash out-of-memory avec un heap dump après des heures d’uptime pointe vers un problème de mémoire ou de plugin. Un processus serveur que l’OS tue, ou un hébergeur qui reboot ton nœud sous le trafic, pointe vers une attaque qui submerge la machine ou le lien. Des crashs synchronisés avec un ban, un événement d’un rival ou une menace publique sont un signal d’attaquant fort.

Comment Infinity-Filter stoppe les attaques avant qu’elles n’atteignent ton serveur

Si tes vérifications confirment une attaque, le correctif n’est pas sur le serveur. Il est devant. Tuner un serveur déjà noyé sous le trafic hostile ne fonctionne pas, parce que le trafic n’a jamais eu à calculer quoi que ce soit pour te faire mal.

Infinity-Filter se place entre internet et ton origine comme reverse proxy et firewall. Il absorbe et filtre le trafic hostile à la périphérie, donc ton processus Minecraft ne voit jamais que des connexions propres.

• La mitigation Layer 3 et 4 drop les floods volumétriques, UDP et TCP, avant qu’ils ne saturent ton lien. Ton IP d’origine reste cachée derrière le proxy, ce qui retire la cible directe.
• Le filtrage Layer 7 inspecte le protocole Minecraft. Il rejette les paquets malformés, les floods de bots et le spam de login, donc les attaques sur le gestionnaire de connexions s’arrêtent au proxy au lieu de remplir tes slots.

Sois clair sur le compromis. Router à travers un proxy ajoute un peu de latence, quelques millisecondes quand le proxy est proche de tes joueurs. Le filtrage demande aussi un peu de config pour correspondre à ton serveur. Ce coût t’achète un serveur qui reste joignable quand quelqu’un décide de le faire tomber.

Confirme d’abord, corrige ensuite

Diagnostique avant d’agir. Vérifie TPS et tick time, compare la bande passante au nombre de joueurs, compte les connexions et lis tes logs. Si la preuve montre un CPU occupé, corrige la performance. Si elle montre du trafic que tes joueurs n’ont jamais généré, tu as affaire à une attaque, et aucun tuning du serveur ne la terminera.

Pour une attaque, mets du filtrage devant ton origine pour que le prochain flood s’arrête avant d’atteindre ton serveur. Configure Infinity-Filter devant ton serveur Minecraft et laisse le proxy prendre la prochaine attaque à la place de ton origine.