Six étapes pour aller d'un VPS nordique nu à votre propre monerod — binaires vérifiés, configuration durcie, complet ou élagué, joignable via SSH, WireGuard ou un onion v3. Un nœud distant ne peut pas lire votre solde, mais il peut voir votre IP diffuser votre transaction — ce guide comble cet unique écart. Testé sur Debian 12 avec la branche v0.18.
Provisionner
Le disque d'abord, puis le durcissement
Vérifier
La signature, puis l'installation
Configurer
monerod.conf + systemd
Synchronisation
Un jour ou deux, sous surveillance
Connecter
SSH, WireGuard ou onion
Anonymiser
Diffuser via Tor
Presque tous les portefeuilles Monero sont livrés pointés vers le démon de quelqu'un d'autre, car l'alternative représente un quart de téraoctet et deux jours d'attente. Ce choix par défaut est défendable, et la perte de confidentialité qui en résulte est régulièrement mal décrite dans les deux sens — par ceux qui pensent qu'un nœud distant lit leur solde, et par ceux qui pensent qu'il n'apprend rien du tout. Cerner correctement la forme de cette fuite est ce qui vous dira si ce guide vaut un après-midi de votre temps.
Ce qu'il ne peut pas faire. Il ne peut pas voir votre solde, vos adresses ni vos clés. Un portefeuille Monero ne dit pas à un nœud ce qu'il doit chercher ; il récupère des blocs entiers sur une plage de blocs et tente de déchiffrer localement chaque sortie avec la clé de vue privée, qui ne quitte jamais l'appareil. Le nœud remet les mêmes octets qu'il remettrait à n'importe qui. Il ne peut pas savoir lesquelles de ces sorties, le cas échéant, sont les vôtres — et c'est là une différence architecturale réelle avec le modèle de portefeuille léger utilisé ailleurs, où un serveur reçoit les adresses à surveiller et sait donc exactement ce qu'il surveille.
Ce qu'il peut faire. Il voit l'adresse IP qui s'est connectée. Il voit la plage de blocs que cette IP a demandée, ce qui encadre la date de création du portefeuille qui se trouve derrière. Il voit le rythme de vos rafraîchissements, ce qui constitue un profil d'usage. Et quand vous dépensez, il reçoit la transaction signée de votre part avant le reste du réseau — il est donc en mesure d'enregistrer que cette transaction est entrée sur le réseau depuis cette adresse, à cette seconde précise. Tout le reste, dans Monero, est conçu pour briser précisément ce genre de lien. Le remettre à un inconnu, gratuitement, avec une IP stable en prime, est la partie qui mérite d'être corrigée.
Et ce qu'il peut faire sans que personne n'en parle. Il peut mentir. Un nœud hostile ou simplement défaillant peut servir une tête de chaîne obsolète, si bien que votre portefeuille signale un paiement entrant qui n'a pas eu lieu, ou peut échouer à relayer une transaction que vous croyez avoir envoyée. Rien de tout cela ne vole des fonds — le portefeuille vérifie ce qu'il déchiffre — mais cela vous fait agir sur une vision faussée de la réalité, ce qui, pour un commerçant qui attend une confirmation, constitue une perte en soi. Un nœud que vous faites tourner vous-même est un nœud dont vous n'avez pas à peser les réponses.
| Ce qui est exposé | Nœud distant public | Votre nœud, clearnet | Votre nœud, via Tor |
|---|---|---|---|
| Votre solde et vos adresses | Jamais | Jamais | Jamais |
| Votre IP, à l'opérateur du nœud | Oui — un inconnu | Oui — vous | Non |
| Fenêtre de création du portefeuille | Oui — un inconnu | Oui — vous | Oui — vous |
| IP ↔ votre transaction sortante | Oui — un inconnu | L'IP de votre serveur, à ses pairs | Cassé par le tx proxy |
| Peut vous servir une fausse tête de chaîne | Oui | Non | Non |
« Fenêtre de création du portefeuille » reste visible pour vous sur votre propre nœud, car la requête a toujours lieu — elle cesse simplement d'être visible pour quiconque d'autre. C'est là tout l'objet de l'exercice : non pas faire disparaître les métadonnées, mais faire en sorte que vous soyez la seule partie à les détenir.
Un nœud Monero élagué conserve un huitième des données de signature en anneau pour les anciens blocs et jette le reste. Il télécharge et vérifie néanmoins lui-même chaque bloc — élaguer n'est pas faire confiance, c'est oublier après avoir vérifié — et il conserve intégralement tout ce qu'un portefeuille demande et tout ce dont un autre pair élagué a besoin. L'économie représente environ deux tiers du disque. Pour un nœud dont le rôle est de servir vos propres portefeuilles, il n'y a aucune différence fonctionnelle que vous remarquerez jamais.
L'argument en faveur d'un nœud complet est étroit mais réel : seul un nœud complet peut fournir à un nœud flambant neuf toutes les données historiques dont il a besoin pour vérifier la chaîne depuis zéro, si bien qu'un réseau entièrement composé de nœuds élagués ne fonctionnerait pas. Si vous avez le disque, faire tourner un nœud complet est une contribution. Si vous ne l'avez pas, faire tourner un nœud élagué n'est pas une forme de participation au rabais — c'est la configuration que la plupart des auto-hébergeurs devraient choisir.
Décidez avant de démarrer le démon. Passer --prune-blockchain dès le premier lancement élague au fur et à mesure de la synchronisation, ce qui est rapide et gratuit. Convertir ensuite une base de données complète implique d'arrêter le démon et de faire tourner sur elle l'outil séparé monero-blockchain-prune, ce qui prend des heures et nécessite de l'espace libre pour travailler. Bien faire les choses dès le départ coûte une ligne dans un fichier de configuration ; se tromper coûte une soirée.
| Forme | Disque, mi-2026 | L'offre qui convient | À choisir quand |
|---|---|---|---|
| Élagué · juste | ~90 GB | Sentinel · 2 vCPU / 4 GB / 120 GB · $3.90 | Vous voulez le nœud fonctionnel le moins cher et acceptez de revoir le disque plus tard |
| Élagué · confortable | ~90 GB | Garrison · 4 vCPU / 8 GB / 240 GB · $7.90 | La recommandation par défaut — des années de marge, un cache de base de données chaud |
| Complet | 240 GB+ | Ravelin · 8 vCPU / 16 GB / 480 GB · $16.90 | Vous voulez une copie d'archive, ou servir leur synchronisation initiale à de nouveaux nœuds |
| Complet + service public | 240 GB+ | Bulwark · 16 vCPU / 32 GB / 960 GB · $32.90 | Vous comptez porter du trafic de pairs réel — la bande passante illimitée compte ici |
Les tailles de chaîne sont une estimation pour la mi-2026, et elles n'évoluent que dans un seul sens. Vérifiez le chiffre actuel avant de vous engager sur une offre — chaque offre NordBastion inclut une bande passante illimitée, ce qu'un nœud avec des emplacements de pairs ouverts consomme réellement.
Une chose ne figure pas dans ce tableau : la RAM. Le démon lui-même est modeste, et 4 GB font tourner un nœud sans problème. Ce que la mémoire supplémentaire apporte, c'est du cache de pages devant la base de données, ce qui se ressent pendant la synchronisation initiale et lors de la première réanalyse complète d'un portefeuille, plutôt qu'au quotidien. Si vous devez choisir entre plus de RAM et plus de NVMe pour le même budget, prenez le NVMe — et jetez un œil à la liste des offres avant de trancher.
Dans le panneau : Commande → VPS → Garrison pour un nœud élagué, Ravelin si vous voulez la chaîne complète, image Debian 12. Aucune adresse e-mail n'est requise pour ouvrir le compte, aucune pièce d'identité n'est demandée à quelque étape que ce soit, et la facture se règle en Monero — ce qui est une symétrie agréable, et aussi le chemin le plus court d'un portefeuille à un serveur démarré que nous connaissions. Choisissez le bastion en fonction de la latence par rapport à vous-même, pas au réseau : les connexions entre pairs sont asynchrones et n'y sont pas sensibles, mais les rafraîchissements de votre portefeuille, eux, le seront.
Ensuite, passez la première heure sur le mur. Un nœud Monero est par nature un service public — il écoute sur un port P2P et parle à des inconnus — le socle n'est donc pas optionnel : SSH par clé uniquement sur un port non standard, un pare-feu qui refuse tout par défaut, des mises à jour de sécurité automatiques, fail2ban. La checklist de durcissement de la première heure en est le complément, et elle vaut la peine d'être suivie de bout en bout avant même que le démon existe.
La forme du pare-feu pour ce nœud est étonnamment simple. Exactement deux choses doivent être joignables depuis l'extérieur : votre port SSH, et le port P2P de Monero. Rien d'autre — en particulier pas le port RPC, que l'étape 05 atteint via un tunnel à la place.
ufw default deny incoming
ufw default allow outgoing
ufw allow 22/tcp # or your relocated SSH port
ufw allow 18080/tcp # Monero P2P — the only service port
ufw enable
ufw status numbered
Confirmez le disque que vous avez réellement obtenu avant d'y synchroniser un quart de téraoctet, car découvrir le manque quarante heures après le début d'une synchronisation initiale est un genre de désagrément bien particulier :
df -h /
# → the "Avail" column is your real budget, not the tier name
Vous êtes sur le point d'installer un programme qui détiendra la vue du réseau à laquelle vos portefeuilles feront confiance. Un monerod trafiqué est la position idéale d'où mentir à un portefeuille, donc l'étape de vérification, ici, n'est pas un rituel — c'est la raison même pour laquelle le projet Monero publie un fichier de sommes de contrôle signé. Faites-le, une fois, correctement.
Récupérez l'archive CLI Linux x86-64 et le fichier de sommes de contrôle signé depuis la page de téléchargement officielle, ainsi que la clé publique du mainteneur telle que publiée à cet endroit. Ne prenez pas la clé sur un miroir de serveur de clés tiers trouvé dans un message de forum — prenez-la sur le site du projet, via TLS, depuis la même page qui la mentionne.
apt update && apt install -y gnupg curl bzip2
cd /tmp
curl -LO https://downloads.getmonero.org/cli/linux64 # the release archive
curl -LO https://www.getmonero.org/downloads/hashes.txt # the signed hash list
# Import the signing key named on getmonero.org, then:
gpg --verify hashes.txt
# → "Good signature from ..." — anything else, stop here.
Ce n'est qu'une fois la signature vérifiée que la somme de contrôle a un sens. Hachez l'archive que vous avez téléchargée et retrouvez cette chaîne exacte dans le fichier que vous venez de vérifier :
sha256sum linux64
grep -F "$(sha256sum linux64 | cut -d' ' -f1)" hashes.txt
# → one matching line. No output means no match: do not install it.
Ensuite, décompressez et placez les deux binaires dont vous avez besoin. L'archive contient un répertoire versionné ; monerod est le démon, et monero-blockchain-prune est l'outil hors ligne que vous serez content d'avoir si jamais vous changez d'avis sur l'élagage.
tar -xjf linux64
cd monero-x86_64-linux-gnu-*/
install -m 0755 monerod monero-blockchain-prune /usr/local/bin/
monerod --version
Notez quelque part la chaîne de version que cette commande affiche, pour la retrouver plus tard. Quand une mise à jour du réseau est annoncée, vous voudrez savoir exactement depuis quelle version vous effectuez la mise à jour, et « latest » n'est pas une réponse.
Donnez au démon son propre utilisateur non privilégié et son propre répertoire. Rien, dans un nœud Monero, n'a besoin de root une fois qu'il tourne, et un service qui parle à l'internet ouvert toute la journée est précisément le service que vous ne voulez pas voir tourner en root.
useradd --system --home /var/lib/monero --shell /usr/sbin/nologin monero
mkdir -p /var/lib/monero /var/log/monero
chown -R monero:monero /var/lib/monero /var/log/monero
/etc/monerod.conf — les mêmes options que monerod accepte en ligne de commande, écrites sans les tirets initiaux. Retirez la ligne prune-blockchain si vous avez opté pour un nœud complet ; c'est la seule ligne qui soit irréversible.
# ── storage ────────────────────────────────────────────────
data-dir=/var/lib/monero
log-file=/var/log/monero/monerod.log
log-level=0
max-log-file-size=104857600
prune-blockchain=1
sync-pruned-blocks=1
# ── P2P: the only port the firewall opens ─────────────────
p2p-bind-ip=0.0.0.0
p2p-bind-port=18080
out-peers=32
in-peers=48
no-igd=1
# ── RPC A: unrestricted, loopback only, for you ───────────
rpc-bind-ip=127.0.0.1
rpc-bind-port=18081
# ── RPC B: restricted, what a wallet is allowed to ask ────
rpc-restricted-bind-ip=127.0.0.1
rpc-restricted-bind-port=18089
# ── misc ──────────────────────────────────────────────────
zmq-pub=tcp://127.0.0.1:18083
db-sync-mode=safe
Les deux interfaces d'écoute RPC sont la partie qui mérite d'être comprise. Le port 18081 répond à tout, y compris aux appels d'administration, et il est lié à loopback, là où est sa place. Le port 18089 est l'interface restreinte : des appels en lecture seule, aucun élément interne sensible pour la confidentialité, et c'est ce que tout nœud public du réseau expose. Les deux sont ici sur 127.0.0.1 volontairement — l'étape 05 atteint le 18089 via un tunnel plutôt qu'en l'ouvrant.
/etc/systemd/system/monerod.service
[Unit]
Description=Monero full node
After=network-online.target
Wants=network-online.target
[Service]
User=monero
Group=monero
Type=simple
ExecStart=/usr/local/bin/monerod --config-file /etc/monerod.conf \
--non-interactive
Restart=on-failure
RestartSec=30
TimeoutStopSec=300
KillSignal=SIGINT
StandardOutput=journal
StandardError=journal
NoNewPrivileges=true
PrivateTmp=true
ProtectSystem=full
ProtectHome=true
[Install]
WantedBy=multi-user.target
KillSignal et TimeoutStopSec ne sont pas de la décoration. La base de données veut se fermer proprement, et un démon tué brutalement en plein milieu d'une écriture peut redémarrer en ayant besoin d'une réparation — ou d'une resynchronisation. SIGINT lui demande de s'arrêter correctement, et cinq minutes sont la période de grâce pour le laisser terminer. Tout guide qui omet ces deux lignes n'est qu'à un redémarrage malheureux d'un week-end perdu.
systemctl daemon-reload
systemctl enable --now monerod
systemctl status monerod --no-pager
Le démon parcourt désormais la chaîne depuis le bloc genesis, vérifiant chaque signature en anneau et chaque preuve de plage qu'il rencontre. Sur NVMe avec quelques cœurs, cela prend un jour ou deux ; ce sont le CPU et le disque qui limitent, pas la bande passante, donc une connexion montante plus rapide ne raccourcira rien. Ce travail est tout le produit. Un nœud qui s'en dispenserait ne serait qu'une façon plus lente de faire confiance à quelqu'un d'autre.
Observez-le depuis un second shell. La ligne de statut vous indique la hauteur, le nombre de pairs et le temps restant estimé, et c'est la seule surveillance dont la plupart des nœuds auront jamais besoin :
monerod --rpc-bind-port 18081 status
journalctl -u monerod -f --no-pager
df -h /var/lib/monero # check this one more often than you think you need to
N'importez pas une blockchain téléchargée. Il existe sur l'internet des archives qui promettent de vous épargner l'attente, et en importer une transforme un nœud que vous avez vérifié en un nœud qui croit un fichier qu'un inconnu vous a donné. Cela ruine la seule chose pour laquelle vous êtes venu ici. Si le temps de synchronisation est réellement inacceptable, la solution honnête est une machine avec plus de cœurs, pas un raccourci qui contourne la vérification.
Le piège du démon bootstrap. monerod peut répondre aux requêtes du portefeuille depuis un nœud public pendant que sa propre synchronisation rattrape son retard, ce qui est une commodité à double tranchant : tant qu'elle est active, votre trafic de portefeuille est servi par exactement le genre de tiers que ce guide a pour but d'éliminer. Si vous l'activez pour être opérationnel dès la première heure, placez un rappel dans votre calendrier et désactivez-la dès que votre propre hauteur atteint la tête de chaîne. Un compromis temporaire que personne ne pense à terminer n'est jamais que l'ancien montage sous un nouveau nom.
Quand la hauteur cesse d'évoluer et correspond à celle d'un explorateur de blocs auquel vous faites confiance, le nœud est opérationnel. À partir de là, le démon vous coûte quelques gigaoctets de trafic par jour, un peu de CPU, et plus aucune attention en dehors des mises à jour.
L'interface RPC restreinte est liée à loopback, ce qui signifie qu'elle n'est actuellement joignable par rien. C'est le bon réglage par défaut, et le reste de cette étape consiste à choisir comment franchir cet écart. Choisissez-en une — elles se combinent mal entre elles, et une seule suffit.
Option A · Tunnel SSH — une machine, aucune configuration. La bonne réponse si vous utilisez un seul ordinateur portable. Rien de nouveau n'est installé, rien de nouveau n'écoute, et le tunnel meurt avec la session. Votre portefeuille pointe alors vers 127.0.0.1:18089 comme si le nœud était local.
ssh -N -L 18089:127.0.0.1:18089 monero-vps
# leave it running; point the wallet at 127.0.0.1:18089
Option B · WireGuard — plusieurs appareils, toujours actif. La bonne réponse pour un téléphone plus un ordinateur de bureau plus un ordinateur portable. Le nœud rejoint votre réseau privé et les portefeuilles s'adressent à lui via son IP de tunnel, sans aucun port exposé sur l'internet. Le guide WireGuard construit le tunnel ; la seule étape supplémentaire ici est de laisser le démon y répondre.
# in /etc/monerod.conf
rpc-restricted-bind-ip=10.8.0.1 # the node's WireGuard address
confirm-external-bind=1
# and in the firewall, only on the tunnel interface
ufw allow in on wg0 to any port 18089 proto tcp
Option C · onion v3 — de n'importe où, sans port, sans IP fixe. La bonne réponse si vous voyagez, ou si vous voulez que le nœud soit joignable sans aucun port entrant nulle part. Tor publie le service ; il n'y a rien à rediriger et rien à scanner. Le guide du service onion couvre l'intégralité du torrc ; la partie spécifique au nœud tient en trois lignes.
# /etc/tor/torrc
HiddenServiceDir /var/lib/tor/monero-rpc/
HiddenServiceVersion 3
HiddenServicePort 18089 127.0.0.1:18089
# then read the address Tor generated for you
cat /var/lib/tor/monero-rpc/hostname
Quelle que soit la porte que vous avez construite, côté portefeuille ce sont les trois mêmes champs. Dans Feather : Settings → Node → add a custom node, indiquez l'hôte et le port, et activez le proxy Tor si vous avez choisi l'onion. Dans le Monero GUI officiel : Settings → Node → Remote node, avec « connect to a remote node » sélectionné. Dans Cake Wallet : Settings → Nodes → add node, qui accepte directement une adresse onion. Si vous avez défini un nom d'utilisateur et un mot de passe sur l'interface RPC, les trois ont des champs prévus pour cela.
Ensuite, vérifiez que cela a fonctionné. Le portefeuille devrait afficher la même hauteur que votre nœud, et le nœud devrait afficher un client RPC de plus. Si le portefeuille s'actualise toujours en à peine une seconde, il parle probablement encore au nœud public par défaut — la plupart des portefeuilles gardent l'ancien dans la liste et y reviennent silencieusement.
Votre portefeuille ne remet plus ses transactions à un inconnu — il les remet à votre propre démon. Mais ce démon les annonce ensuite à ses pairs depuis l'adresse IP de votre serveur, et les pairs prennent note. Monero propage déjà une nouvelle transaction à travers une phase de relais randomisée avant qu'elle ne se diffuse largement, ce qui rend le premier saut difficile à identifier ; l'envoyer via Tor à la place élimine entièrement la question.
Une seule ligne suffit. Le démon continue de synchroniser les blocs sur le clearnet — ce qui permet à la synchronisation de rester rapide — et n'achemine que la diffusion de vos transactions sortantes via le port SOCKS local de Tor :
# in /etc/monerod.conf, with tor running locally
tx-proxy=tor,127.0.0.1:9050,16
Si vous voulez aller plus loin et aussi accepter des pairs via Tor, publiez un second service onion pour le volet P2P et indiquez au démon quelle adresse onion annoncer. Le numéro de port est à votre convenance, du moment que les deux moitiés s'accordent et que rien d'autre sur la machine ne l'utilise déjà :
# /etc/tor/torrc
HiddenServiceDir /var/lib/tor/monero-p2p/
HiddenServiceVersion 3
HiddenServicePort 18084 127.0.0.1:18084
# /etc/monerod.conf
anonymous-inbound=YOUR_ONION_ADDRESS.onion:18084,127.0.0.1:18084
Cette étape aide le réseau plus qu'elle ne vous aide, ce qui est une très bonne raison de la franchir. Elle coûte un peu de latence et quelques emplacements de pairs, et elle permet aux nœuds Tor uniquement d'avoir quelque part où se connecter.
En option : faire don d'un nœud public. Si vous disposez de la bande passante et du disque, vous pouvez annoncer votre point de terminaison RPC restreint afin que les portefeuilles d'autres personnes puissent l'utiliser. C'est une contribution réelle à un réseau dont le point faible est le trop petit nombre de personnes qui font tourner leur propre démon — et cela s'accompagne des obligations de tout service public : vous porterez le trafic d'autres personnes, et vous serez visible en tant qu'opérateur de nœud. Chaque offre proposée ici inclut une bande passante illimitée, ce qui fait de la première de ces obligations une décision plutôt qu'une facture.
# only if you mean it: expose the RESTRICTED port, never 18081
rpc-restricted-bind-ip=0.0.0.0
confirm-external-bind=1
public-node=1
# and open it: ufw allow 18089/tcp
Un nœud est aussi agréable à placer à côté d'autres infrastructures auto-hébergées — un nœud Lightning sur le même rack, par exemple. Gardez-les sur des machines séparées si le budget le permet : ils n'ont pas les mêmes exigences de disponibilité, et leurs scénarios de reprise sont très différents.
Le démon s'arrête, et la base de données peut avoir besoin d'une passe de réparation avant de pouvoir se rouvrir. Vérifiez l'espace libre quotidiennement pendant la synchronisation, et dimensionnez l'offre pour la chaîne telle qu'elle sera dans trois ans, pas aujourd'hui.
Le port 18081 répond aux appels d'administration. Sa place est sur 127.0.0.1, pour toujours. Si quelque chose de l'extérieur doit joindre le nœud, cela passe par l'interface d'écoute restreinte sur le 18089, via un tunnel.
Ajouter votre nœud à la liste ne le sélectionne pas, et la plupart des portefeuilles reviennent silencieusement à un autre nœud lorsqu'il est injoignable. Comparez les hauteurs, et confirmez que le nœud signale un client RPC connecté.
L'ajouter plus tard ne réduit pas une base de données existante. Convertir signifie arrêter le démon et exécuter monero-blockchain-prune, ce qui demande des heures et de l'espace de travail. Décidez avant le premier démarrage.
Une mise à jour du réseau est passée et le démon n'a jamais été mis à jour. Cela ne se voit pas de façon spectaculaire — la hauteur cesse simplement de correspondre à la réalité. Suivez les annonces de version et effectuez la mise à jour avant la hauteur du fork.
Un SIGKILL en plein milieu d'une écriture, généralement à cause d'une unité systemd sans KillSignal et avec un délai d'arrêt court. Utilisez SIGINT et laissez-lui cinq minutes, et laissez le démon fermer lui-même sa base de données.
Dix questions qui se posent avant, pendant et après le passage d'un portefeuille sur un démon que vous faites tourner vous-même.
Non. Les portefeuilles Monero analysent côté client : le portefeuille demande au nœud une plage de blocs, les télécharge intégralement, puis tente de déchiffrer localement chaque sortie avec votre clé de vue privée. Le nœud ne reçoit jamais votre clé de vue, votre clé de dépense ni votre adresse, et il ne peut pas savoir lesquelles des sorties qu'il vient de vous remettre vous appartiennent. C'est une réelle différence architecturale avec les portefeuilles légers de Bitcoin, où le serveur se voit généralement indiquer quelles adresses ou quels scripts surveiller. Ce qu'un nœud distant apprend bel et bien, c'est la couche réseau : votre adresse IP, le fait qu'un portefeuille à cette IP est en train de se synchroniser, la plage de blocs demandée — qui encadre la hauteur de restauration de votre portefeuille — et, surtout, toute transaction que vous lui remettez à diffuser. C'est cette dernière qui est la fuite qu'il vaut la peine de colmater.
Faites tourner un nœud élagué, sauf si vous avez une raison de ne pas le faire. Un nœud élagué jette sept huitièmes des données de signature en anneau pour les anciens blocs, conserve tout ce qu'un portefeuille ou un nouveau pair a réellement besoin d'obtenir de vous, valide néanmoins toujours la chaîne entière lui-même, et se retrouve à environ un tiers du disque d'un nœud complet. Pour un backend de portefeuille personnel, le comportement est indiscernable. Faites tourner un nœud complet si vous voulez pouvoir servir à un nœud tout neuf sa propre synchronisation initiale depuis zéro, si vous faites tourner un outillage de type explorateur de blocs qui lit des données de transaction historiques arbitraires, ou si vous voulez simplement une copie d'archive complète. Décidez avant la première synchronisation : --prune-blockchain élague au fur et à mesure de la synchronisation, alors que convertir une base de données complète déjà synchronisée implique d'arrêter le démon et de faire tourner sur elle l'outil séparé monero-blockchain-prune.
Un nœud complet dépasse les 240 GB à la mi-2026 et croît de l'ordre de quelques dizaines de gigaoctets par an ; dimensionnez donc pour la chaîne que vous aurez dans trois ans, pas celle que vous avez aujourd'hui. Un nœud élagué représente environ un tiers de cela — disons 85 à 95 GB actuellement. En pratique, cela signifie qu'un Garrison (240 GB NVMe) est l'endroit confortable pour un nœud élagué avec des années de marge devant lui, et qu'un Ravelin (480 GB) est la bonne machine pour un nœud complet. Un Sentinel à 120 GB accueillera un nœud élagué aujourd'hui, mais vous fera y repenser plus tôt que vous ne le souhaiteriez. Vérifiez la taille actuelle de la chaîne avant d'acheter le disque — c'est le seul chiffre de ce guide qui est garanti d'être dépassé.
Un jour ou deux sur NVMe pour une première synchronisation, et ce sont le CPU et le disque qui limitent, pas votre connexion. Le démon vérifie chaque signature en anneau et chaque preuve de plage depuis le bloc genesis ; c'est là le travail, et c'est la raison pour laquelle faire tourner le nœud en vaut la peine. Deux choses aggravent nettement la situation : un disque dur mécanique à la place d'un NVMe, qui peut transformer deux jours en une semaine, et manquer de disque à mi-parcours. Deux choses qui aident moins qu'on ne le croit : plus de bande passante, et plus de RAM au-delà de ce qui maintient les pages de la base de données en cache. N'importez pas une archive de blockchain téléchargée auprès d'un tiers pour vous épargner l'attente — vous feriez alors confiance exactement à la partie à laquelle vous cherchiez à ne plus faire confiance.
Jamais l'interface non restreinte. L'interface RPC non restreinte expose des appels d'administration, et elle doit rester liée à 127.0.0.1 pendant toute la vie du nœud. L'interface restreinte est un objet différent : elle ne répond qu'aux appels en lecture seule dont un portefeuille a besoin, et c'est elle que tout nœud public du réseau expose. Même ainsi, la publier sur un port clearnet annonce « un utilisateur Monero est ici » à quiconque scanne l'espace d'adressage. L'ordre de préférence retenu dans ce guide est le suivant : un service onion v3 en premier, un tunnel WireGuard en second, un tunnel SSH pour une seule machine en troisième, et un port public nu seulement si vous avez délibérément décidé de faire don d'un nœud public au réseau.
Un nœud ne détient aucune clé, ne conserve aucun fonds et ne peut déplacer l'argent de personne. Il valide des blocs et relaie des transactions déjà signées par d'autres — la même posture qu'un relais de messagerie qui achemine des messages qu'il ne peut pas lire. C'est là la réalité technique ; la réalité juridique dépend de la juridiction, et ce guide ne constitue pas un conseil juridique. Ce que la juridiction change, en revanche, c'est qui peut contraindre quoi : le guide sur les quatre juridictions nordiques détaille les textes de loi qui s'appliquent à un serveur situé à Stockholm, Helsinki, Oslo ou Reykjavík.
Seulement si vous le mettez à jour. Monero effectue des mises à jour du réseau programmées, et un démon qui tourne avec un jeu de règles de consensus obsolète cesse de suivre la chaîne principale à la hauteur du fork — cela ne vous avertit pas bruyamment, cela se contente de se figer ou de bifurquer, et votre portefeuille se met à signaler discrètement une hauteur qui ne correspond plus à la réalité. Abonnez-vous aux annonces de version, figez la version que vous avez installée plutôt que de suivre une étiquette mouvante, et placez un rappel dans votre calendrier à la hauteur de mise à jour annoncée. C'est la façon la plus courante pour un nœud auto-hébergé de cesser d'être utile : pas un plantage, juste un propriétaire qui a arrêté de lire les annonces.
Acheminez la diffusion de vos transactions sortantes via Tor — c'est le seul réglage qui offre un gain de confidentialité clair et peu coûteux, car il sépare « cette transaction est entrée sur le réseau » de « cette adresse IP existe ». Accepter aussi des pairs Tor entrants est une étape supplémentaire qui aide le réseau plus qu'elle ne vous aide, et coûte un peu de latence. Acheminer tout le trafic entre pairs via Tor est l'option agressive : cela fonctionne, et cela rendra votre synchronisation initiale nettement plus lente, si bien que la plupart des gens synchronisent sur le clearnet puis basculent ensuite le chemin des transactions vers Tor. Le guide du service onion Tor couvre le volet torrc plus en détail.
Presque toujours la hauteur de restauration. Un portefeuille sans hauteur de restauration, ou avec une hauteur à zéro, réanalyse la chaîne depuis le bloc genesis à chaque restauration, ce qui représente des heures de travail local pour rien. Réglez la hauteur de restauration sur le bloc qui existait au moment de la création du portefeuille. La deuxième cause est le chemin réseau : un portefeuille situé dans un autre pays et qui dialogue avec votre nœud via un circuit onion saturé sera plus lent que le même portefeuille sur un nœud public voisin — c'est le prix de la confidentialité, et un tunnel WireGuard récupère généralement l'essentiel de la vitesse perdue. La troisième cause, celle que l'on manque le plus souvent, est que votre nœud n'a pas terminé sa propre synchronisation initiale et répond encore depuis un démon bootstrap.
Parce qu'un nœud est un objet durable, joignable publiquement, à travers lequel transitent vos transactions. Un nœud complet colmate la fuite entre votre portefeuille et le nœud d'un inconnu — puis en ouvre une plus petite, entre votre nœud et celui qui vous a loué la machine. Si l'inscription pour cette machine s'est accompagnée d'un scan de passeport et d'une carte à votre nom légal, vous avez déplacé la corrélation plutôt que de la supprimer. Payer en Monero le serveur qui fait tourner votre nœud Monero n'est pas un slogan ; c'est la seule version du montage où les deux couches s'accordent entre elles. Le guide pilier sur l'hébergement VPS anonyme détaille les trois couches de bout en bout.
Garrison (4 vCPU, 8 GB, 240 GB NVMe, $7.90/mois) accueille un nœud élagué avec des années de marge ; Ravelin (480 GB) prend en charge la chaîne complète. Bande passante illimitée sur toutes les offres, aucun e-mail à l'inscription, aucune pièce d'identité, jamais.
Dernière révision · 2026-10-12 · Références · Guides utilisateur de getmonero.org (faire tourner un nœud, élagage, Tor et I2P), monerod --help sur la branche v0.18, documentation de Debian 12 et du Tor Project · Fréquence · annuellement
This guide is one spoke of a larger series. The pillar walks the three privacy layers end to end — the sibling spokes below dive into the specifics.
Three independent layers — signup, payment, network — explained, legal context included, common mistakes flagged.
Your own LN node — bitcoind + LND or Core Lightning, on a VPS.
Accept Bitcoin and Lightning with no processor — non-custodial, no fees.
Deploy your own MCP server on a no-KYC VPS — TLS, streamable HTTP, OAuth.
Host an MCP server with no ID — the privacy stack, crypto-paid.
Hébergement privé, conçu dans le Nord.