> ## Content Index > Fetch the complete content index at: https://hostwolf.net/blog/fr/llms.txt > Use this file to discover other available public pages before exploring further. # Propriétés du serveur Minecraft 26.4 : allowed-connection-ids, status-contact-details et enable-legacy-status expliqués - URL: https://hostwolf.net/blog/fr/proprietes-du-serveur-minecraft-26-4-allowed-connection-ids-status/ - Published: 2026-10-05T00:16:07.000Z - Updated: 2026-10-05T01:12:57.000Z - Description: Deux snapshots de septembre ont discrètement ajouté trois clés server.properties qui compteront pour les administrateurs de serveurs. Voici ce que chacune fait, les mises en garde de Mojang, et si vous deviez toucher aux snapshots 26.4 ou non. - Author: Hostwolf Team - Tags: Actualités, Minecraft, Guides Les snapshots 26.4 sont là : le Snapshot 1 est arrivé le 22 septembre 2026, et le Snapshot 2 a suivi le 29 septembre. Entre les deux, les snapshots Minecraft 26.4 ont ajouté trois nouvelles clés `server.properties` qui intéresseront les administrateurs de serveurs dédiés : `allowed-connection-ids`, `status-contact-details` et `enable-legacy-status`. Aucune n’est encore dans une version stable, et 26.4 lui-même est seulement prévu pour le T4 2026 sans date officielle. **TL;DR :** ces clés valent la peine d’être apprises dès maintenant, mais ne les utilisez pas en production tant que la 26.4 n’est pas réellement sortie. Les serveurs snapshot signifient pas de Paper, pas de plugins, et des mises à niveau du monde à sens unique. Le Snapshot 1 est le plus intéressant. Il a ajouté les trois clés, ainsi qu’une modification du protocole destinée à prendre en charge la nouvelle façon dont le client envoie l’adresse du serveur. Le Snapshot 2 se composait de corrections de bugs, de changements sur le brouillard de la distance de rendu et d’une refonte de l’écran de débogage, sans nouvelles propriétés ([versions de développement 26.4, minecraft.wiki](https://minecraft.wiki/w/Java%5FEdition%5F26.4/Development%5Fversions?ref=hostwolf.net)). La source principale pour tout ce qui suit est [le journal des modifications du Snapshot 1 de Mojang](https://www.minecraft.net/en-us/article/minecraft-26-4-snapshot-1?ref=hostwolf.net). Une note sur la dénomination : depuis le changement de numérotation de décembre 2025, les snapshots sont nommés selon le style `26.4-snapshot-1` plutôt que l’ancien format de numéro de semaine `25w44a`. La séquence de Mojang est snapshots → `-pre-N` → `-rc-N` → release. Avant d’aller clé par clé, vous devez comprendre pourquoi ces clés existent. L’analyse du nouveau champ hôte est la fondation de tout ce qui suit. ## Le contexte d’abord : comment fonctionnent les propriétés-dans-l’adresse-du-serveur Le champ `host` dans le paquet serverbound `minecraft:intention` transporte désormais des paramètres au style requête URI. (Mojang écrit tantôt `minecraft:intent`, tantôt `minecraft:intention` dans le même journal des modifications. Même paquet, faute de frappe, ne vous y laissez pas prendre.) Cela signifie qu’une adresse de serveur peut ressembler à `example.com?key1=value1&key2`, avec des clés et des valeurs encodées en pourcentage selon les règles URI, et des valeurs vides autorisées pour ignorer le `=`. Le champ a également été étendu à 1024 caractères, et les joueurs peuvent saisir ces propriétés dans n’importe quel champ « Adresse du serveur ». Il y a aussi un raccourci : une adresse comme `myid@play.example.com` est analysée comme `play.example.com?_id=myid`. Le wiki SAS Gaming ajoute que l’identifiant est « tous les caractères avant le premier @ » dans l’adresse. C’est un détail de wiki communautaire, indirect, mais il correspond à l’exemple de Mojang. Les clés commençant par `_` sont réservées au vanilla. `_id` est celle à laquelle `allowed-connection-ids` est comparée. Il y a aussi une interaction SRV à connaître : si un enregistrement SRV résout l’adresse vers un domaine différent, le domaine résolu devient le principal et l’original est transmis en tant que propriété `_o` (origine). Selon le journal des modifications, cela corrige le comportement SRV incohérent que Mojang suit sous l’ID de bug MC-278651. L’avertissement propre de Mojang, cité exactement : *"Note : puisque le paquet minecraft:intent n’est pas chiffré, les propriétés ne doivent pas être utilisées à des fins sensibles à la sécurité."* Gardez cela à l’esprit pour tout ce qui suit. Un autre élément du journal des modifications pour exhaustivité : le paquet `minecraft:transfer` a gagné un champ `properties`, une map chaîne-à-chaîne ajoutée au champ hôte envoyé au serveur cible. Cela compte pour les configurations de transfert et de proxy une fois 26.4 stable. ## status-contact-details : la clé que les admins utiliseront réellement À notre avis, c’est la plus utile des trois pour les serveurs communautaires. Si `status-contact-details` n’est pas vide, sa valeur est envoyée dans le JSON du paquet `minecraft:status_response` sous la propriété `contact`, ce qui signifie qu’elle apparaît dans l’entrée de votre liste de serveurs. L’intention déclarée de Mojang : un moyen lisible par l’humain pour que les joueurs contactent les propriétaires du serveur lorsqu’il n’y a pas de site web ou d’autre information. Il n’y a aucune restriction de format. Notre suggestion éditoriale : une invitation Discord ou une adresse e-mail fonctionne bien. Toutes deux sont courtes, toutes deux se copient-collent facilement, et elles résolvent exactement le problème que Mojang décrit : les joueurs qui trouvent votre serveur et n’ont aucune idée de comment vous joindre. La valeur par défaut est vide (déduite du journal des modifications, non explicitement documentée). Une mise en garde : les informations de contact n’apparaissent que lorsque `enable-status=true` est défini. Si vous gérez un serveur amis-et-communauté sans site web, c’est la seule clé valeureuse à définir tôt sur la version stable. ## allowed-connection-ids : un filtre de connexion léger avec un gros piège En citant le journal des modifications : *"Une liste d’identifiants séparés par des virgules. S’il n’est pas vide, le serveur correspondra les valeurs contre la propriété `_id` dans le paquet minecraft:intention. S’il n’y a pas de correspondance, le serveur rejettera la connexion. Cela fonctionne à la fois pour les connexions de statut et de login, donc tout utilisateur se connectant sans le correct `_id` dans l’adresse du serveur ne verra pas le statut et ne pourra pas rejoindre le serveur."* Un exemple travaillé (notre dérivation, pas d’une source) : disons que vous définissez ``` allowed-connection-ids=friends,alt-night ``` Les joueurs rejoignent ensuite via `friends@your.server.ip` dans le champ d’adresse du serveur, ou la forme complète `your.server.ip?_id=friends`. L’un ou l’autre analyse en `_id=friends`, qui correspond, et ils sont dedans. Le piège : parce que le filtre gère aussi les pings de statut, un identifiant incorrect ou manquant signifie que le serveur ne répond pas du tout au statut. Votre serveur apparaît comme mort dans la liste des serveurs. C’est de loin la mauvaise configuration la plus probable. Quelqu’un définit la clé, oublie de dire à ses joueurs l’identifiant, et passe une soirée convaincu que le serveur a planté. Les clients rejetés voient le message « Connexion rejetée par le serveur » (selon [MC Toolkit](https://mctoolkit.net/blog/minecraft-26-4-snapshot-1?ref=hostwolf.net)). Soyons clairs : il s’agit d’opacité, pas d’authentification. L’identifiant circule en clair lors de la poignée de main, exactement comme Mojang l’a averti. Quiconque analyse le trafic ou lit le format des paquets peut le lire, et n’importe qui peut le saisir. Ne considérez pas cela comme un substitut à votre liste blanche. Conservez la vraie liste blanche activée. Considérez `allowed-connection-ids` comme un filtre pratique pour un serveur semi-privé où vous préférez que les inconnus soient refusés plutôt que de passer par une procédure de bannissement. Deux inconnues que nous ne devinerons pas : la valeur par défaut n’est pas documentée (le vide est déduit), ni les caractères autorisés ni les limites de longueur pour les ids. Non vérifié également : le comportement derrière Velocity ou BungeeCord. Les administrateurs réseau devraient attendre et tester au stade RC, car les proxys analysent eux-mêmes le format de la poignée de main. ## enable-legacy-status : nettoyage pour les anciens outils de ping C’est le seul des trois à avoir une valeur par défaut documentée : `true`, préservant ainsi le comportement existant. Le définir sur `false` désactive la gestion du protocole de statut/ping legacy pré-1.7\. Cela nécessite également `enable-status=true` pour que toute information de statut, moderne ou legacy, soit envoyée. Quand devriez-vous changer cette valeur ? Notre recommandation : uniquement si vous êtes certain qu’aucun outil de votre chaîne ne pingue encore avec le protocole legacy. Certains anciens bots de liste de serveurs, tableaux de bord et scanners le font encore. Si un outil de surveillance cesse de détecter votre serveur après ce changement, cette clé est le premier suspect. Remettez-la en place et mettez à jour l’outil. Rien ici ne bloque les joueurs ; cela affecte uniquement la manière dont les très anciennes requêtes de ping sont répondues. ## Référence rapide : les trois clés en un coup d’œil | Clé | Valeur par défaut | Ce qu’elle fait | Restreint-elle le statut ? | Quand l’utiliser | | ---------------------- | ----------------- | -------------------------------------------------------------------- | --------------------------------------------- | -------------------------------------------------------- | | status-contact-details | vide (déduit) | Publie les coordonnées dans la réponse de statut (propriété contact) | Non | Serveurs communautaires sans site web | | allowed-connection-ids | vide (déduit) | Rejette les connexions et pings de statut sans \_id correspondant | Oui, un id incorrect = le serveur semble mort | Serveurs amis semi-privés, par commodité et non sécurité | | enable-legacy-status | true (documenté) | Désactive la gestion du ping pré-1.7 lorsque false | Clients legacy uniquement | Admins retirant les anciens outils de ping | Rappel pour l’édition de `server.properties` : c’est de l’UTF-8, des lignes `key=value` avec des commentaires `#`, et le serveur réécrit le fichier au démarrage, copiant les valeurs existantes et réinitialisant les clés manquantes ou invalides aux valeurs par défaut. Un redémarrage est requis après les modifications, et sauvegardez le fichier avant d’expérimenter. Ces trois clés sont actuellement réservées aux snapshots et pourraient changer avant la sortie de la 26.4. ## Tester sur un serveur snapshot : la procédure raisonnable L’avertissement de Mojang s’applique : les versions de test peuvent corrompre votre monde, donc sauvegardez et exécutez les snapshots dans un dossier séparé de vos mondes principaux. Les mondes de snapshot se mettent à niveau dans un seul sens vers la version de données du snapshot. Pas d’invite, pas d’annulation, et la seule voie de retour est une sauvegarde pré-snapshot. Les mondes peuvent même être endommagés entre deux snapshots consécutifs. ![Une tour de serveur aux intérieurs faiblement lumineux sur un plateau enneigé à côté d’un feu de camp orange chaleureux, avec une lumière bleu-violet froide sur les falaises glacées en arrière-plan](https://hostwolf.net/blog/fr/content/images/2026/10/minecraft-26-4-snapshot-server-properties-img-test-server.webp) Un serveur snapshot jetable : lancez-en un, testez les nouvelles propriétés, puis laissez-le partir. Support des frameworks en premier. Fin septembre, Vanilla et Fabric peuvent exécuter des snapshots, tandis que Paper, Purpur, Spigot, Forge et NeoForge n’ont pas publié de builds de snapshot 26.4 ; ils construisent uniquement des versions finales et des candidats de release. Cela provient d’une seule source (GameServerKings, vérifié le 28 sep 2026) et mérite d’être recontrôlé via l’API de build de Paper avant de s’y fier. Pour l’instant, cela signifie aucun plugin sur un serveur snapshot. Pour tester spécifiquement les nouvelles clés : ajoutez-les à `server.properties`, redémarrez le serveur, connectez-vous en utilisant le raccourci `friends@ip`, et vérifiez que votre entrée dans la liste des serveurs affiche vos coordonnées. Ensuite, effectuez les vérifications de cohérence plus larges : 1. Sauvegardez votre monde de production et vos configurations. 2. Lancez un serveur séparé et jetable. Ne touchez pas à la production. 3. Copiez-y vos configurations. 4. Au premier démarrage, lisez les logs pour les clés rejetées ou inconnues. 5. Parcourez vos fermes et constructions redstone pour vérifier que rien n’est cassé. 6. Jetez-le une fois terminé. Si vous souhaitez une instance secondaire pour les tests de snapshot à côté de votre serveur de production, [l’hébergement de serveurs Minecraft avec sauvegardes quotidiennes et installation en un clic](https://hostwolf.net/games/minecraft.html?ref=hostwolf.net) vous donne votre propre machine avec une restauration en un clic, ce qui est exactement ce dont vous avez besoin avant de toucher à quoi que ce soit. ## Devriez-vous exécuter les snapshots 26.4 en production maintenant ? (Verdict : non) Non. Attendez la version finale, ou au minimum les release candidates (RC) si vous êtes un admin Paper, car Paper construit des builds RC. Trois raisons : aucun support des plugins ou des frameworks de mods sur les snapshots, des mises à niveau du monde à sens unique, et ces trois clés sont trop récentes pour être figées avant la sortie de la 26.4. Sur le calendrier, soyez honnête avec vous-même : la 26.4 est prévue pour le T4 2026 selon le wiki, sans date officielle de Mojang. Une estimation de décembre 2026 circule basée sur le rythme d’environ 10 à 14 semaines entre les snapshots et les releases de 26.1 à 26.3\. Il s’agit d’une projection calendaire, pas d’une déclaration de Mojang. Que faire maintenant : rien sur la production. Si vous le souhaitez, lancez un serveur snapshot jetable en vanilla ou sur Fabric pour essayer `status-contact-details` et voir à quoi ressemble la chaîne de coordonnées dans la liste des serveurs. À surveiller : si vous utilisez Velocity ou BungeeCord, vous êtes le groupe qui doit garder un œil sur la 26.4, car les proxys analysent eux-mêmes le format du handshake et le champ hôte étendu change ce qu’ils voient. SyntaxMine identifie les administrateurs réseau comme étant exactement ce groupe. Nous reviendrons sur cet article lorsque la 26.4 atteindra les release candidates ou la version stable, et nous mettrons à jour les détails clés si quelque chose change. ## Questions fréquentes ### Que font réellement allowed-connection-ids, status-contact-details et enable-legacy-status ? allowed-connection-ids rejette les connexions (statut et connexion) qui ne portent pas un \_id correspondant dans l’adresse du serveur. status-contact-details publie une chaîne de contact dans la réponse de statut de votre serveur. enable-legacy-status=false désactive la gestion legacy du ping pré-1.7\. Seul enable-legacy-status a une valeur par défaut documentée (true) ; les deux autres sont vides à moins que vous ne les définissiez. ### Comment un joueur entre-t-il l’identifiant de connexion dans l’adresse de son serveur ? Soit le raccourci friends@your.server.ip (analysé comme your.server.ip?\_id=friends), soit la forme complète de requête your.server.ip?\_id=friends. Tout ce qui précède le premier @ est traité comme l’identifiant. ### Pourquoi mon serveur apparaît-il hors ligne dans la liste des serveurs après avoir défini allowed-connection-ids ? Le filtre s’applique aux pings de statut ainsi qu’aux connexions. Si le client qui se connecte n’envoie pas de \_id correspondant, le serveur ne répondra pas au statut — donc la liste des serveurs l’affichera comme hors ligne. Corrigez l’identifiant dans l’adresse du serveur ou effacez la clé. ### Puis-je utiliser allowed-connection-ids comme liste blanche ? Non. Mojang note explicitement que le paquet minecraft:intent n’est pas chiffré, donc l’identifiant peut être lu ou usurpé. Traitez-le comme un filtre pratique pour un serveur semi-privé et conservez votre vraie allowlist en place. ### Ces nouvelles clés fonctionnent-elles avec Velocity ou BungeeCord ? Non vérifié. Les proxys analysent eux-mêmes le champ hôte de la poignée de main, donc le comportement derrière un proxy n’est pas confirmé pour les snapshots 26.4\. Les administrateurs réseau devraient attendre les builds release candidate et tester avant de s’appuyer sur quoi que ce soit.