La liste serveur emul repose sur un fichier de configuration, server.met, qui référence les adresses IP et ports des serveurs eD2k actifs. Sans mise à jour régulière de ce fichier, eMule tente de se connecter à des adresses obsolètes, ce qui ralentit ou bloque l’accès au réseau. La mise à jour automatique au démarrage du client est la méthode la plus stable pour maintenir une liste utilisable.
Configurer la mise à jour automatique du server.met dans eMule
Dans eMule, la mise à jour automatique de la liste serveur passe par l’onglet Préférences > Serveur. Un champ y permet de renseigner une URL pointant vers un fichier server.met distant. À chaque démarrage du client, eMule télécharge ce fichier et intègre les nouvelles entrées à sa liste locale.
La procédure de configuration suit quelques étapes précises.
- Ouvrir eMule, puis accéder à Préférences (icône clé ou menu Outils selon la version).
- Dans l’onglet Serveur, repérer le champ intitulé « Mise à jour de la liste des serveurs au démarrage » et cocher l’option correspondante.
- Coller dans le champ prévu une URL valide vers un fichier server.met maintenu activement. Certaines listes publiques sont régulièrement vérifiées ; d’autres ne le sont pas, ce qui rend le choix de la source aussi important que la fréquence de mise à jour.
Il est préférable de supprimer au préalable les serveurs déjà présents dans la liste, pour éviter d’accumuler des adresses mortes aux côtés des nouvelles entrées. Un clic droit dans la liste des serveurs permet de sélectionner « Effacer tous les serveurs ».
server.met et nodes.dat : deux fichiers, deux réseaux distincts
Une confusion fréquente consiste à traiter la mise à jour du server.met comme une action globale qui améliore toute la connectivité d’eMule. Ce n’est pas le cas. server.met concerne uniquement le réseau eD2k ; le réseau Kad, lui, utilise un fichier séparé appelé nodes.dat, qui contient des contacts de démarrage pour ce réseau décentralisé.
Mettre à jour l’un ne met donc pas à jour l’autre. Si Kad ne se connecte pas correctement, remplacer ou actualiser le server.met ne changera rien à la situation Kad. Les deux fichiers se configurent indépendamment, et certaines versions d’eMule permettent de renseigner une URL pour chacun.
Liste mise à jour, serveurs injoignables : identifier la vraie cause
Le cas le plus trompeur survient quand la mise à jour automatique se déroule sans erreur visible, mais qu’aucun serveur ne répond. eMule affiche « Connexion… » indéfiniment, ou bascule de serveur en serveur sans parvenir à s’établir. Télécharger un nouveau server.met n’a pas suffi.
Plusieurs causes distinctes peuvent produire ce résultat.
La première est la qualité de la liste elle-même. Une liste courte et maintenue vaut mieux qu’une longue liste ancienne. Un fichier server.met peut contenir de nombreuses entrées dont la majorité ne correspond plus à des serveurs actifs. La longueur de la liste n’est pas un indicateur de fiabilité.
La deuxième cause, distincte de la précédente, est le pare-feu ou la configuration NAT. Si les ports TCP et UDP utilisés par eMule sont bloqués, le client obtiendra un « Low ID » ou ne parviendra pas à contacter les serveurs, même si ces serveurs sont actifs et correctement référencés dans le server.met. Mettre à jour la liste ne modifie en aucun cas les ports ni les règles du routeur.
Comment distinguer l’un de l’autre ? Si eMule parvient à se connecter à au moins un serveur et affiche un ID élevé, le problème vient de la liste. Si eMule reste systématiquement en Low ID ou ne se connecte jamais, même avec une liste fraîchement importée, la configuration réseau est en cause. L’onglet Serveur affiche l’ID attribué après connexion : c’est le premier indicateur à consulter.
Kad inaccessible après mise à jour de la liste
Kad peut rester déconnecté indépendamment de tout ce qui concerne le réseau eD2k. Si l’onglet Kad affiche « Déconnecté » alors que le server.met vient d’être rafraîchi, le nodes.dat est probablement absent, corrompu ou obsolète. La démarche consiste à télécharger un nodes.dat récent et à le placer dans le répertoire de configuration d’eMule, généralement sous %AppData%\eMule\config sur Windows.
Si le nodes.dat est en ordre mais que Kad reste inaccessible, la vérification porte sur le port UDP : certains routeurs bloquent ce trafic par défaut, et la redirection de port ne s’applique parfois qu’au TCP.
aMule sur Linux et Mac : même logique, quelques différences d’interface
Sur Linux ou macOS, le client aMule applique le même principe pour la mise à jour de la liste serveur. L’option se trouve dans Préférences > Réseaux. Le champ d’URL pour le server.met y est présent, et la logique server.met / nodes.dat reste identique.
Les versions récentes d’aMule ont renforcé les contrôles autour des mises à jour automatiques de listes, ce qui peut se traduire par des avertissements ou des comportements plus prudents lors de l’import depuis des sources externes. Si une URL précédemment fonctionnelle ne produit plus de mise à jour, il peut être nécessaire de passer par un import manuel du fichier server.met, en le plaçant directement dans le répertoire de configuration du client.
Choisir une source de liste serveur fiable
La qualité d’une liste serveur dépend de la fréquence à laquelle elle est vérifiée, et non de sa taille. Une source qui publie un server.met mis à jour régulièrement, avec suppression active des serveurs injoignables, est plus utile qu’un agrégat statique rarement maintenu.
Quelques critères pour évaluer une source :
- La date de dernière mise à jour est visible et récente. Un fichier server.met non daté ou modifié il y a plusieurs mois offre peu de garanties.
- La liste distingue les serveurs testés des serveurs simplement référencés. Certains sites publient des statistiques de disponibilité pour chaque entrée.
- L’URL est en HTTPS et pointe vers un domaine stable. Les redirections multiples ou les hébergeurs temporaires exposent à des interruptions de mise à jour automatique.
Une fois l’URL sélectionnée, la cohérence est préférable au changement fréquent de source : modifier l’URL à chaque problème de connexion masque souvent une cause réseau qui mérite d’être traitée séparément.
