🇬🇧 English · 🇫🇷 Français

S'applique à Hydranos 4.4.

Cette page liste chaque clé de [race], [hoard], des blocs engine (tableau de tables TOML) et de [race_drain] dans default.toml. Pour chaque clé, vous trouvez son type, la valeur du modèle livré, la valeur qu'utilise Hydranos quand la clé est absente, ce qu'elle fait réellement en 4.4, et quand une modification prend effet. C'est une page de référence. Pour comprendre ce que sont les moteurs et pourquoi en ajouter un, lisez d'abord Moteurs : race & hoard.

Comment le fichier est trouvé, modifié et rechargé est expliqué dans Configuration : vue d'ensemble. Les réglages qui ne concernent pas les moteurs sont dans Config : démon, auth & global.

• race et hoard tournent toujours. Ils prennent leurs réglages dans [race] et [hoard]. Si une section manque, son moteur démarre quand même, avec chaque clé à sa valeur « absente » (voir les tableaux ci-dessous).
• Chaque bloc engine ajoute un moteur. Ses réglages sont la section [race] ou [hoard] de son rôle, avec par-dessus les clés de sa propre table [engine.session].
• Les réglages des moteurs sont lus une seule fois, au démarrage des moteurs, sauf les clés marquées à chaud dans les tableaux. Une clé à chaud modifiée depuis l'interface web ou l'API (POST /api/settings, les routes par moteur) s'applique aux moteurs en cours sans redémarrage : les plafonds de débit, peer_timeout, le choker, la file, la règle des torrents lents et les limites de partage. Le port d'écoute et les limites de connexions sortantes ont leurs propres routes à chaud. Une modification du fichier à la main est lue au démarrage suivant, ou dès qu'une modification faite par l'interface ou l'API réécrit le fichier (ce qui recharge le fichier entier).
• Si une clé de [race] ou [hoard] a le mauvais type (par exemple listen_port = "16171"), le fichier ne s'analyse pas et Hydranos s'arrête au démarrage. L'éditeur web refuse une modification qui n'est pas du TOML valide, mais pas un mauvais type (max_connections = 4000.5) : une telle modification est enregistrée, et Hydranos refuse ensuite de démarrer. La même erreur dans une table [engine.session] ne fait qu'écarter ce remplacement (voir plus bas).
• Une clé qu'Hydranos ne connaît pas est acceptée et ignorée, et une clé mal orthographiée ne fait simplement rien. Les clés connues pour être mortes (restes de la 3.x, voir Clés qui ne font rien en 4.4) sont nommées au démarrage, un avertissement par clé : config: race.listen_interfaces is ignored: <why>. Instead: <what to use>.

Comment la liste des moteurs est construite à partir du fichier au démarrage :

flowchart TD
    T["default.toml"] --> R["section [race]"]
    T --> H["section [hoard]"]
    T --> B["Chaque ancien bloc agent,<br/>puis chaque bloc engine"]
    R --> ER["Moteur race, rôle race, toujours"]
    H --> EH["Moteur hoard, rôle hoard, toujours"]
    B --> A{"addr renseigné, ou role vide ?"}
    A -- oui --> SK["Sauté : pas un moteur local"]
    A -- non --> RO{"role vaut race ou hoard ?"}
    RO -- non --> W["Avertissement rôle inconnu,<br/>aucun moteur"]
    RO -- oui --> ID{"engine_id, sinon name,<br/>non vide ?"}
    ID -- non --> W2["Avertissement, sauté"]
    ID -- oui --> M["Section de ce rôle,<br/>table session appliquée par-dessus"]
    M --> V{"Réglages fusionnés valides ?"}
    V -- non --> P["Avertissement remplacement refusé,<br/>section du rôle utilisée telle quelle"]
    V -- oui --> SAME{"Id déjà dans la liste ?"}
    P --> SAME
    SAME -- oui --> REP["Remplace ce moteur,<br/>race et hoard compris"]
    SAME -- non --> ADD["Un moteur de plus"]
    ER --> L["Liste des moteurs"]
    EH --> L
    REP --> L
    ADD --> L
    L --> WG["Mode WireGuard : chaque moteur tunnelé<br/>épinglé à son interface de tunnel"]
    WG --> PC{"Pour chaque moteur dans l'ordre :<br/>listen_port 0 ?"}
    PC -- oui --> DEF["16171 pour le rôle race,<br/>16172 pour le rôle hoard, avertissement"]
    PC -- non --> WR["Port tel qu'écrit"]
    DEF --> TK{"Pris par un moteur précédent ?"}
    WR --> TK
    TK -- non --> KEEP["Port conservé"]
    TK -- oui --> FREE["+1 jusqu'à un port libre, avertissement"]

Le port choisi à la dernière étape n'est pas écrit dans le fichier. L'avertissement dit listen_port missing or taken: using a free one.

En 4.4, chaque clé des tableaux ci-dessous est lue. Elles se répartissent en cinq groupes : pairs et réseau, file/partage/débit, annonces et démarrage, les clés qu'écrit l'onglet Réseau (Network) (proxy, relais, gluetun), et les clés WireGuard géré. Seules deux clés que vous pouvez encore rencontrer dans ces sections ne sont lues par rien et nommées nulle part : inactivity_timeout et announce_rate_limit. Les restes de la 3.x ne sont lus par rien non plus, mais Hydranos nomme chacun d'eux dans un avertissement au démarrage. Les deux listes sont dans Clés qui ne font rien en 4.4 ci-dessous.

Modèle = valeur dans le configs/default.toml livré (race / hoard). Absente = ce qu'utilise Hydranos quand la clé manque. À chaud ? = si une modification s'applique sans redémarrage (voir Comment les réglages des moteurs sont lus).

Comment ils fonctionnent, avec des exemples et les remplacements par torrent : File d'attente, limites de partage et de débit. Chaque clé ici est à chaud : la file tourne toutes les 30 secondes et le traitement des limites de partage toutes les 2 minutes, et chaque passage lit les valeurs en cours.

Config › Paramètres avancés (default.toml) (Advanced settings (default.toml)) › Réseau › Enregistrer ce mode (Save this mode) écrit [network] mode, les clés du mode choisi dans [race], [hoard] et les blocs des moteurs supplémentaires, et supprime les clés des autres modes. Les modes et leurs champs : Réseau : ports & redirection. Toutes ces clés sont lues au démarrage du moteur (redémarrage).

Le kill switch lui-même ([daemon] kill_switch) et la route propre du démon ([daemon] egress, [proxy]) ne sont pas des clés de moteur : voir Config : démon, auth & global et VPN & sortie réseau.

Les sous-onglets Session Race et Session Hoard masquent les clés que possède l'onglet Réseau (listen_port, bind_interface, enable_ipv6, les clés SOCKS5, PROXY-v2 et d'annonce, allow_direct) : changez-les dans l'onglet Réseau. Les clés gluetun_* et wireguard_* y restent affichées quand le fichier les contient.

En [network] mode = "wireguard", l'onglet Réseau écrit par moteur wireguard_enabled, wireguard_config (un nom de fichier dans <data_dir>/wireguard, jamais la clé elle-même), wireguard_provider, wireguard_port et wireguard_port_forward, ou allow_direct = true pour un moteur laissé sur la route par défaut. Aucune ne figure dans le modèle. Ce que chacune signifie et ce qui est écrit : WireGuard géré.

[network] mode vaut direct, wireguard, gluetun, socks5 ou proxy_v2. Absent (un fichier d'avant la 4.4) ou inconnu, le mode est déduit des clés ci-dessus, et jamais comme wireguard.

Accepté mais ignoré en 4.4 : inactivity_timeout et announce_rate_limit ressemblent à des réglages de pairs et d'annonces et ne sont lues par rien — aucun avertissement au démarrage ne les nomme — utilisez peer_timeout pour les pairs inactifs ; les annonces ne peuvent pas être limitées en débit.

Les quatre clés nommées au démarrage sont masquées dans l'éditeur Paramètres avancés. inactivity_timeout est affichée, avec l'indication default: 20 pour race et default: 90 pour hoard.

Depuis la 4.4, la plupart des valeurs Absente correspondent au modèle : DHT, PEX et webseeds sont activés, LSD suit le rôle, et chaque moteur reçoit un vrai port d'écoute. Deux différences demeurent. Une section [race] ou [hoard] écrite par vous, une section que vous avez allégée, ou la configuration écrite par le script d'enrôlement de nœud (install.sh, qui n'écrit que listen_port 16371/16372 et enable_ipv6 = true) a :

• aucun plafond sur les connexions aux pairs (max_connections absente = 0), là où le modèle a 4000 / 12000 ;
• pour hoard, aucun plafond de téléchargement (active_downloads absente = 0), là où le modèle a 10.

Un moteur sans listen_port reçoit la valeur par défaut de son rôle (16171 race, 16172 hoard) ; si ce port, ou celui qu'il a écrit, est déjà pris par un moteur précédent, il reçoit le port libre suivant au-dessus. Dans les deux cas, avec un avertissement. Ce port n'est pas enregistré, il peut donc changer quand des moteurs sont ajoutés : écrivez listen_port pour chaque moteur.

L'éditeur Paramètres avancés (default.toml) change les clés qui existent déjà dans le fichier. Les exceptions sont les clés à chaud des tableaux file, limites de partage, débit et choker, ainsi que enable_lsd : l'éditeur les liste pour [race] et [hoard] à leur valeur par défaut même quand le fichier ne les contient pas, et en enregistrer une la crée — sauf active_downloads, max_uploads_per_torrent et peer_timeout, que l'éditeur ne liste que quand le fichier les contient (Bug connu en 4.4 : le serveur les créerait ; le modèle de race n'a pas d'active_downloads : ajoutez-la à la main). Toute autre clé absente du modèle (enable_webseed, enable_udp_trackers, aio_threads, start_paused) doit être ajoutée avec un éditeur de texte ; max_dials_per_sec aussi via POST /api/engines/:id/dial-limits. Une section avec les clés écrites en entier :

[race]
listen_port = 16171
bind_interface = ""
enable_ipv6 = false
enable_dht = true
enable_pex = true
enable_lsd = true
enable_webseed = true
enable_udp_trackers = true
max_connections = 4000
aio_threads = 256
peer_timeout = 300
registration_retry_minutes = 6
# active_downloads non définie : aucun plafond de téléchargement pour race

[hoard]
listen_port = 16172
bind_interface = ""
enable_ipv6 = false
enable_dht = true
enable_pex = true
enable_lsd = false
enable_webseed = true
enable_udp_trackers = true
max_connections = 12000
aio_threads = 256
peer_timeout = 300
active_downloads = 10

Les clés de file, de limites de partage, de débit et de choker figurent dans le modèle livré comme indiqué dans les tableaux ci-dessus.

Un moteur supplémentaire se déclare avec un bloc engine (tableau de tables TOML) et une sous-table [engine.session] facultative. Nodes › This node › + Add an engine écrit exactement ce bloc pour vous. Ensuite, l'onglet Réseau et les routes par moteur changent certaines clés (voir Modifier un moteur supplémentaire par la suite) ; toute autre clé se modifie à la main.

Règles à connaître :

• Additif. race et hoard existent toujours ; chaque bloc valide ajoute un moteur. Ajouter un bloc ne désactive jamais [race] ni [hoard].
• Même identifiant = remplacement. Un bloc dont l'identifiant est déjà pris remplace ce moteur. Cela inclut race et hoard : un bloc avec engine_id = "race" redéfinit le moteur race (rôle et réglages compris). Donnez leurs propres identifiants aux moteurs supplémentaires.
• Le remplacement est tout ou rien. Si une seule clé de [engine.session] a le mauvais type (par exemple listen_port = "16473"), tout le remplacement est écarté avec l'avertissement agent session override refused, using the role profile, et le moteur tourne avec la section de son rôle inchangée : les réglages et l'interface de son rôle, et le port libre suivant après celui de son rôle (avertissement listen_port missing or taken: using a free one).
• Les clés inconnues du remplacement sont écartées sans un mot (une clé mal orthographiée, par exemple). Les clés mortes de Clés qui ne font rien en 4.4 y sont aussi nommées au démarrage, avec le nom du bloc et session.<key>.
• Ce dont hérite un moteur supplémentaire. Tout ce que contient la section de son rôle, y compris le proxy SOCKS5 et announce_proxy, sauf quatre clés qu'il n'obtient qu'en les écrivant dans sa propre session : listen_port_proxy_v2 (un port de relais par hôte), gluetun_port_forward (un seul port redirigé), wireguard_enabled (un tunnel par moteur) et allow_direct (un moteur ajouté plus tard n'est pas attribué, et le kill switch armé le bloque jusqu'à ce que vous choisissiez).
• Définissez toujours listen_port dans le remplacement, unique parmi les moteurs. Au démarrage, un moteur dont le port manque ou est déjà pris par un moteur précédent est déplacé vers le port libre suivant (avec un avertissement, non enregistré) : il écoute donc, mais pas sur un port que vous avez publié ou redirigé. + Add an engine refuse un port qu'un moteur en cours utilise déjà (409) ; l'onglet Réseau ne compare pas les ports des moteurs supplémentaires à ceux de race et hoard.
• Où placer le bloc dans le fichier. Un bloc TOML possède toutes les lignes situées en dessous jusqu'au prochain [header]. Ajoutez les blocs de moteur à la fin du fichier (l'interface le fait), sinon vous déplacerez dans le bloc les clés qui suivent. La sous-table doit utiliser le nom du bloc : [engine.session] sous un bloc engine. Mélanger les écritures peut rendre le fichier impossible à analyser, et Hydranos refuse alors de démarrer.
• Les anciens blocs agent (l'écriture 3.x, mêmes champs) sont toujours lus, avant les blocs engine. Quand les deux déclarent le même identifiant, le bloc engine l'emporte. Les nouveaux blocs sont toujours écrits en engine. Historique : Mettre à jour depuis la 3.x.
• Un sous-tableau engine à l'intérieur d'un bloc (le remplacement de moteur par agent de la 3.x, avec une clé id) ne correspond à aucun champ et ne fait rien ; Hydranos le nomme au démarrage. Mettez les clés remplacées dans la sous-table session du bloc.

# À la FIN de default.toml
[[engine]]
name = "vpn1"
role = "hoard"
engine_id = "vpn1"
  [engine.session]
  listen_port = 16473
  bind_interface = "wg1"

C'est ce qu'écrit + Add an engine pour Id vpn1, Rôle (Role) hoard, Listen port 16473, Interface wg1. Le moteur hérite de tout le reste de [hoard] (DHT, PEX, max_connections, active_downloads = 10, …). Ensuite :

1. Redémarrez Hydranos (ajouter ou supprimer un moteur demande toujours un redémarrage ; l'interface affiche Redémarrer maintenant (Restart now)).
2. Avec Docker, publiez le port vous-même : 16473:16473/tcp et 16473:16473/udp. Le compose livré ne publie que 16171 et 16172.
3. Vérifiez Nodes › This node : la ligne doit indiquer listening. n'écoute pas (not listening) signifie généralement que wg1 n'était pas montée au démarrage du moteur. + Add an engine refuse une interface qui n'est pas montée (400 no interface named wg1 is up), et refuse toute interface hors de Linux (400).

bind_interface épingle chaque socket de ce moteur à wg1 : écouteur, uTP, ses propres connexions sortantes vers les pairs, annonces, DHT, LSD et webseeds. Si wg1 manque, il ne se replie sur rien (ni écouteur, ni uTP), jamais sur la route par défaut. Un moteur supplémentaire sans interface, sans tunnel et sans proxy hérité de son rôle est tenu hors du réseau tant que le kill switch est armé (tous les modes sauf Direct), jusqu'à ce que vous lui donniez une sortie ou allow_direct = true. Lisez VPN & sortie réseau pour ce qui reste en dehors de l'épinglage.

Toute clé peut être remplacée par moteur. Ici, un second moteur hoard reste hors du DHT et du PEX, ignore les trackers UDP, plafonne son envoi et arrête ses seeds au ratio 2, tandis que [hoard] garde ses propres valeurs :

[[engine]]
name = "quiet"
role = "hoard"
engine_id = "quiet"
  [engine.session]
  listen_port = 16474
  enable_dht = false
  enable_pex = false
  enable_udp_trackers = false
  active_downloads = 2
  upload_rate_limit = 1048576   # octets/s = 1 MiB/s
  max_ratio = 2.0

• Port d'écoute et interface : l'onglet Réseau affiche Port d'écoute de {id} ({id} listen port) et Interface de l'moteur {id} ({role}) ({id} engine interface ({role})) pour chaque moteur supplémentaire. Enregistrer ce mode les écrit dans le [engine.session] du bloc (en le créant si besoin). Redémarrez.
• Limites de partage, plafonds de débit, limites de connexions sortantes, port d'écoute : les routes par moteur écrivent dans le [engine.session] du bloc : POST /api/engines/:id/share-limits, /rate-limits, /dial-limits, /listen-port (à chaud, sans redémarrage).
• Toute autre clé : modifiez le bloc à la main. L'éditeur Paramètres avancés (default.toml) ne peut pas changer les blocs de moteur : ils n'y sont pas affichés du tout.
• Suppression : Supprimer (Remove) sur la ligne du moteur supprime le bloc (non proposé pour race et hoard). Un moteur qui détient encore des torrents est refusé (409 <id> still holds <n> torrent(s): move them to another engine or remove them first). Un moteur vide garde son écouteur jusqu'à votre redémarrage. Son dossier <config dir>/<id>/ reste sur le disque (voir Moteurs : race & hoard).

Équivalents API : POST /api/engines avec {"id","role","listen_port","bind_interface"} et DELETE /api/engines/:id. Les deux répondent restart_required: true (API REST).

Réglages de la libération automatique des volumes race. Un drain tourne par moteur de rôle race, un passage par volume. Ce qu'il supprime, ce qu'il fait graduer et comment les obligations de seed protègent les torrents est expliqué dans Drain race & graduation.

À chaud ? « prochain passage » / « prochain ajout » signifie : une modification faite depuis l'interface web ou l'API s'applique sans redémarrage, car ces chemins d'écriture mettent à jour la configuration en cours. L'interface des réglages affiche quand même Réglages daemon/auth modifiés, un redémarrage complet est nécessaire. (Daemon/auth settings changed, a full restart is required.) pour cette section ; pour ces clés, vous pouvez l'ignorer. Une modification faite à la main dans le fichier est lue au démarrage suivant.

Le Quota et le TRIM après drain (TRIM after drain) par volume ne sont pas des clés de cette section : réglez-les sur la carte du volume dans l'onglet Race ou avec POST /api/drain/policy (quota_gb, trim_after_drain) ; ils sont enregistrés dans hydra.db.

min_age_minutes ne figure plus dans le modèle. Elle n'a jamais rien fait (un torrent est protégé par la durée de seed minimale de son tracker, pas par son âge) ; une valeur restée dans un ancien fichier est ignorée, masquée dans l'éditeur et nommée au démarrage : config: race_drain.min_age_minutes is ignored: …. Voir Drain race & graduation.

Piège : sans high_watermark_pct ni low_watermark_pct, un drain activé démarre un passage à chaque intervalle et tente de libérer tout ce qu'il a le droit de libérer (seules les obligations de seed le retiennent). Si vous écrivez [race_drain] vous-même, définissez les quatre clés du modèle :

[race_drain]
enabled = true
check_interval_seconds = 60
high_watermark_pct = 95
low_watermark_pct = 85
# facultatif : refuser les races qui ne tiendraient pas
add_block_enabled = true
reserve_free_gb = 50

Si [race_drain] est entièrement absente, le drain global par défaut et le blocage d'ajout sont désactivés ; un volume dont la politique propre est activée (onglet Race) est quand même drainé.

La table de la 3.x (enabled, tick_interval_seconds, strategy, max_unchoked, rarity_weight, speed_weight) ne figure plus dans le modèle. Dans un fichier qui la contient encore, rien ne la lit ; elle est masquée dans l'éditeur, et Hydranos journalise au démarrage config: race.custom_choking is ignored: a 3.x choking strategy; the engine has one built-in choker and no strategy to pick. Instead: choking = true and max_uploads_per_torrent = <slots> (off by default; read their help first). Supprimez-la. Le choker intégré est décrit dans File d'attente, limites de partage et de débit.

Les anciens modèles se terminaient par un exemple commenté de [hoard.disk_slots] (une limite d'envois actifs par disque pour les disques rotatifs, avec des sous-entrées disk contenant key, type, max_active, wake_below). Il ne figure plus dans le modèle, et Hydranos 4.4 n'a pas cette fonction : un fichier qui contient la table est accepté, la table est masquée dans l'éditeur et nommée au démarrage (config: hoard.disk_slots is ignored: …).

Accepté mais ignoré en 4.4 : [hoard.disk_slots] décrit des emplacements de seed par disque pour laisser les disques durs au repos — aucun code ne la lit et chaque torrent en seed reste actif — il n'existe pas d'équivalent ; arrêtez vous-même les torrents si un disque doit se reposer.

• Configuration : vue d'ensemble : fonctionnement du fichier, niveaux de redémarrage, et tableau complet des clés qui ne font rien.
• Moteurs : race & hoard : ce que change le rôle, moteurs supplémentaires, protocoles pairs.
• File d'attente, limites de partage et de débit : la file, les torrents lents, les limites de partage, les plafonds de débit, le choker et la pause au démarrage.
• Réseau : ports & redirection : ports, changement de port à chaud, modes de l'onglet Réseau, LSD.
• WireGuard géré : les clés wireguard_*.
• VPN & sortie réseau : ce que bind_interface épingle, le kill switch, allow_direct.
• Drain race & graduation : comportement du drain et cartes des volumes de l'onglet Race.
• Limites connues de la 4.4 : toutes les lacunes en une liste.