Sechs Schritte von einem nackten nordischen VPS zu Ihrem eigenen monerod – verifizierte Binaries, eine gehärtete Konfiguration, full oder pruned, erreichbar über SSH, WireGuard oder eine v3-Onion-Adresse. Ein Remote-Node kann Ihren Kontostand nicht lesen, aber er sieht, wie Ihre IP Ihre Transaktion verbreitet – dieser Leitfaden schließt genau diese Lücke. Getestet auf Debian 12 mit der Reihe v0.18.
Bereitstellen
Erst der Speicher, dann härten
Verifizieren
Signatur, dann installieren
Konfigurieren
monerod.conf + systemd
Synchronisieren
Ein bis zwei Tage, beobachtet
Verbinden
SSH, WireGuard oder Onion
Anonymisieren
Verbreitung über Tor
Fast jede Monero-Wallet wird ab Werk auf den Daemon eines anderen gerichtet ausgeliefert, weil die Alternative ein Viertel Terabyte und zwei Tage Wartezeit bedeutet. Diese Voreinstellung ist vertretbar, und der daraus entstehende Verlust an Privatsphäre wird regelmäßig in beide Richtungen falsch beschrieben – von Leuten, die glauben, ein Remote-Node lese ihren Kontostand, und von Leuten, die glauben, er erfahre überhaupt nichts. Erst wenn Sie die genaue Form des Lecks kennen, wissen Sie, ob dieser Leitfaden einen Nachmittag Ihrer Zeit wert ist.
Was er nicht kann. Er kann Ihren Kontostand, Ihre Adressen und Ihre Schlüssel nicht sehen. Eine Monero-Wallet sagt einem Node nicht, wonach er suchen soll; sie holt ganze Blöcke über einen Blockbereich und versucht, jeden Output lokal mit dem privaten View-Key zu entschlüsseln, der das Gerät nie verlässt. Der Node liefert dieselben Bytes aus, die er jedem anderen liefern würde. Er kann nicht erkennen, welche Outputs – falls überhaupt – Ihnen gehörten, und das ist ein echter architektonischer Unterschied zum anderswo verwendeten Light-Wallet-Modell, bei dem einem Server die zu beobachtenden Adressen übergeben werden und er deshalb genau weiß, was er beobachtet.
Was er kann. Er sieht die IP-Adresse, die sich verbunden hat. Er sieht den Blockbereich, den diese IP angefragt hat, und der grenzt ein, wann die dahinterstehende Wallet erstellt wurde. Er sieht den Rhythmus Ihrer Aktualisierungen, und das ist ein Nutzungsmuster. Und wenn Sie etwas ausgeben, erhält er die signierte Transaktion zuerst von Ihnen, bevor der Rest des Netzes sie hat – er ist also in der Lage festzuhalten, dass diese Transaktion in dieser Sekunde von dieser Adresse aus ins Netz gelangt ist. Alles andere an Monero ist darauf ausgelegt, genau diese Art von Verknüpfung zu brechen. Sie einem Fremden gratis und zusammen mit einer festen IP zu überlassen, ist der Teil, den es zu beheben lohnt.
Und was er kann, worüber niemand spricht. Er kann lügen. Ein feindlicher oder auch nur defekter Node kann eine veraltete Blockspitze ausliefern, sodass Ihre Wallet einen Zahlungseingang meldet, den es nie gab, oder eine Transaktion nicht weiterleiten, die Sie für versendet halten. Nichts davon stiehlt Guthaben – die Wallet prüft, was sie entschlüsselt –, aber es bringt Sie dazu, auf Basis eines falschen Weltbilds zu handeln, was für einen Händler, der auf eine Bestätigung wartet, ein eigener Verlust ist. Ein Node, den Sie selbst betreiben, ist ein Node, dessen Antworten Sie nicht abwägen müssen.
| Was preisgegeben wird | Öffentlicher Remote-Node | Ihr Node, Clearnet | Ihr Node, über Tor |
|---|---|---|---|
| Ihr Kontostand und Ihre Adressen | Nie | Nie | Nie |
| Ihre IP, für den Node-Betreiber | Ja – ein Fremder | Ja – Sie selbst | Nein |
| Zeitfenster der Wallet-Erstellung | Ja – ein Fremder | Ja – Sie selbst | Ja – Sie selbst |
| IP ↔ Ihre ausgehende Transaktion | Ja – ein Fremder | Die IP Ihres Servers, für seine Peers | Durch den tx-Proxy gebrochen |
| Kann Ihnen eine falsche Blockspitze liefern | Ja | Nein | Nein |
„Zeitfenster der Wallet-Erstellung“ bleibt auf Ihrem eigenen Node für Sie sichtbar, weil die Anfrage weiterhin stattfindet – sie ist nur für niemanden sonst mehr sichtbar. Genau darum geht es bei der ganzen Übung: nicht darum, die Metadaten verschwinden zu lassen, sondern darum, dass nur noch Sie sie besitzen.
Ein Pruned-Monero-Node behält ein Achtel der Ring-Signatur-Daten alter Blöcke und wirft den Rest weg. Er lädt und prüft weiterhin jeden Block selbst – Pruning ist kein Vertrauen, sondern Vergessen nach dem Prüfen – und er behält vollständig alles, was eine Wallet anfragt und was ein anderer Pruned-Peer braucht. Die Ersparnis beträgt rund zwei Drittel des Speicherplatzes. Für einen Node, dessen Aufgabe es ist, Ihre eigenen Wallets zu bedienen, gibt es keinen funktionalen Unterschied, den Sie je bemerken würden.
Das Argument für einen Full-Node ist eng und real: Nur ein Full-Node kann einem brandneuen Node die vollständigen historischen Daten liefern, die dieser braucht, um die Blockchain von Grund auf zu prüfen; ein Netzwerk ausschließlich aus Pruned-Nodes würde also nicht funktionieren. Wenn Sie den Speicher haben, ist ein Full-Node ein Beitrag. Wenn nicht, ist ein Pruned-Node keine minderwertige Form der Teilnahme – es ist die Konfiguration, die die meisten Selbsthoster wählen sollten.
Entscheiden Sie, bevor Sie den Daemon starten. --prune-blockchain beim ersten Start prunet bereits während der Synchronisation, was schnell und kostenlos ist. Eine vollständige Datenbank nachträglich umzuwandeln bedeutet, den Daemon zu stoppen und das separate Werkzeug monero-blockchain-prune darüber laufen zu lassen, was Stunden dauert und freien Platz zum Arbeiten braucht. Das gleich zu Beginn richtig zu machen, kostet eine Zeile in einer Konfigurationsdatei; es falsch zu machen, kostet einen Abend.
| Variante | Speicher, Mitte 2026 | Passender Tarif | Wählen Sie sie, wenn |
|---|---|---|---|
| Pruned · knapp | ~90 GB | Sentinel · 2 vCPU / 4 GB / 120 GB · 3,90 $ | Sie wollen den günstigsten funktionierenden Node und nehmen in Kauf, den Speicher später erneut anzufassen |
| Pruned · bequem | ~90 GB | Garrison · 4 vCPU / 8 GB / 240 GB · 7,90 $ | Die Standardempfehlung – jahrelanger Spielraum, warmer Datenbank-Cache |
| Voll | 240 GB+ | Ravelin · 8 vCPU / 16 GB / 480 GB · 16,90 $ | Sie wollen eine Archivkopie oder neuen Nodes ihre Erstsynchronisation liefern |
| Full + öffentlicher Dienst | 240 GB+ | Bulwark · 16 vCPU / 32 GB / 960 GB · 32,90 $ | Sie wollen echten Peer-Verkehr tragen – hier zählt die unbegrenzte Bandbreite |
Die Größen der Blockchain sind eine Schätzung für Mitte 2026, und sie bewegen sich nur in eine Richtung. Prüfen Sie den aktuellen Wert, bevor Sie sich auf einen Tarif festlegen – jeder NordBastion-Tarif enthält unbegrenzte Bandbreite, und genau die verbraucht ein Node mit offenen Peer-Slots.
Eines steht nicht in dieser Tabelle: RAM. Der Daemon selbst ist genügsam, und mit 4 GB läuft tatsächlich ein Node. Was der zusätzliche Speicher kauft, ist Page-Cache vor der Datenbank, und der macht sich bei der Erstsynchronisation und beim ersten vollständigen Rescan einer Wallet bemerkbar, nicht im Alltagsbetrieb. Wenn Sie beim gleichen Budget zwischen mehr RAM und mehr NVMe wählen müssen, nehmen Sie das NVMe – und werfen Sie einen Blick auf die Tarifübersicht, bevor Sie sich entscheiden.
Im Panel: Order → VPS → Garrison für einen Pruned-Node, Ravelin, wenn Sie die vollständige Blockchain wollen, Image Debian 12. Für die Kontoeröffnung ist keine E-Mail-Adresse nötig, zu keinem Zeitpunkt wird ein Ausweisdokument verlangt, und die Rechnung wird in Monero beglichen – eine hübsche Symmetrie und zugleich der kürzeste Weg von einer Wallet zu einem gebooteten Server, den wir kennen. Wählen Sie die Bastion nach der Latenz zu Ihnen, nicht zum Netzwerk: Peer-Verbindungen sind asynchron und stört das nicht, Ihre Wallet-Aktualisierungen dagegen schon.
Verbringen Sie die erste Stunde dann mit der Mauer. Ein Monero-Node ist von Natur aus ein öffentlicher Dienst – er lauscht auf einem P2P-Port und spricht mit Fremden –, deshalb ist die Grundausstattung nicht optional: SSH nur mit Schlüssel auf einem nicht standardmäßigen Port, eine Firewall, die im Zweifel ablehnt, automatische Sicherheitsupdates, fail2ban. Die Härtungs-Checkliste für die erste Stunde ist das Begleitstück, und es lohnt sich, sie vollständig durchzugehen, bevor der Daemon überhaupt existiert.
Die Firewall für diesen Node hat eine ungewöhnlich einfache Form. Genau zwei Dinge sollen von außen erreichbar sein: Ihr SSH-Port und der Monero-P2P-Port. Sonst nichts – insbesondere nicht der RPC-Port, den Schritt 05 stattdessen durch einen Tunnel erreicht.
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
Prüfen Sie den tatsächlich gelieferten Speicher, bevor Sie ein Viertel Terabyte darauf synchronisieren, denn den Engpass erst vierzig Stunden nach Beginn der Erstsynchronisation zu entdecken, ist eine ganz eigene Art von Ärgernis:
df -h /
# → the "Avail" column is your real budget, not the tier name
Sie installieren gleich ein Programm, das die Netzwerksicht bereithält, der Ihre Wallets vertrauen. Ein manipuliertes monerod ist die ideale Position, um eine Wallet zu belügen; der Verifikationsschritt hier ist deshalb kein Ritual – er ist der Grund, warum das Monero-Projekt überhaupt eine signierte Hashes-Datei veröffentlicht. Machen Sie es einmal, und machen Sie es richtig.
Laden Sie das CLI-Archiv für Linux x86-64 und die signierte Hashes-Datei von der offiziellen Download-Seite, dazu den dort veröffentlichten öffentlichen Schlüssel des Maintainers. Holen Sie den Schlüssel nicht von einem fremden Keyserver-Spiegel, den Sie in einem Forenbeitrag gefunden haben – holen Sie ihn beim Projekt, über TLS, von derselben Seite, die ihn nennt.
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.
Erst wenn die Signatur stimmt, bedeutet die Prüfsumme etwas. Bilden Sie den Hash des heruntergeladenen Archivs und suchen Sie genau diese Zeichenkette in der eben verifizierten Datei:
sha256sum linux64
grep -F "$(sha256sum linux64 | cut -d' ' -f1)" hashes.txt
# → one matching line. No output means no match: do not install it.
Entpacken Sie dann und legen Sie die beiden benötigten Binaries ab. Das Archiv enthält ein versioniertes Verzeichnis; monerod ist der Daemon, und monero-blockchain-prune ist das Offline-Werkzeug, über das Sie froh sein werden, falls Sie Ihre Meinung zum Pruning je ändern.
tar -xjf linux64
cd monero-x86_64-linux-gnu-*/
install -m 0755 monerod monero-blockchain-prune /usr/local/bin/
monerod --version
Notieren Sie die Versionszeichenkette, die dieser Befehl ausgibt, an einer Stelle, an der Sie sie wiederfinden. Wenn ein Netzwerk-Upgrade angekündigt wird, wollen Sie genau wissen, wovon Sie aktualisieren, und „latest“ ist keine Antwort.
Geben Sie dem Daemon einen eigenen unprivilegierten Benutzer und ein eigenes Verzeichnis. Nichts an einem Monero-Node braucht im laufenden Betrieb root, und ein Dienst, der den ganzen Tag mit dem offenen Internet spricht, ist genau der Dienst, den Sie nicht als root laufen lassen wollen.
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 – dieselben Optionen, die monerod auf der Kommandozeile entgegennimmt, nur ohne die führenden Bindestriche. Entfernen Sie die Zeile prune-blockchain, wenn Sie sich für einen Full-Node entschieden haben; das ist die einzige Zeile, die unumkehrbar ist.
# ── 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
Die zwei RPC-Listener sind der Teil, den man verstehen sollte. Port 18081 beantwortet alles, auch administrative Aufrufe, und ist an das Loopback-Interface gebunden, wo er hingehört. Port 18089 ist die beschränkte Schnittstelle: nur lesende Aufrufe, keine datenschutzrelevanten Interna, und genau das bietet jeder öffentliche Node im Netz an. Beide liegen hier mit Absicht auf 127.0.0.1 – Schritt 05 erreicht 18089 durch einen Tunnel, statt ihn zu öffnen.
/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 und TimeoutStopSec sind keine Zierde. Die Datenbank will sauber geschlossen werden, und ein Daemon, der mitten in einem Schreibvorgang hart abgeschossen wird, kommt unter Umständen mit Reparaturbedarf zurück – oder mit einer neuen Synchronisation. SIGINT bittet ihn, sich ordentlich zu beenden, und fünf Minuten sind die Frist, damit er fertig wird. Jeder Leitfaden, der diese beiden Zeilen weglässt, ist einen unglücklichen Neustart von einem verlorenen Wochenende entfernt.
systemctl daemon-reload
systemctl enable --now monerod
systemctl status monerod --no-pager
Der Daemon läuft nun die Blockchain vom Genesis-Block an durch und prüft jede Ring-Signatur und jeden Range-Proof, die ihm begegnen. Auf NVMe mit ein paar Kernen dauert das ein bis zwei Tage; begrenzend sind CPU und Datenträger, nicht die Bandbreite, eine schnellere Anbindung verkürzt es also nicht. Diese Arbeit ist das ganze Produkt. Ein Node, der sie überspringt, wäre nur eine langsamere Art, jemand anderem zu vertrauen.
Beobachten Sie ihn aus einer zweiten Shell. Die Statuszeile nennt Höhe, Peer-Anzahl und geschätzte Restzeit, und sie ist das einzige Monitoring, das die meisten Nodes je brauchen:
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
Importieren Sie keine heruntergeladene Blockchain. Im Internet kursieren Archive, die versprechen, die Wartezeit zu überspringen; eines davon zu importieren, macht aus einem Node, den Sie verifiziert haben, einen Node, der einer Datei von einem Fremden glaubt. Damit ist genau das dahin, wofür Sie hergekommen sind. Wenn die Synchronisationszeit wirklich untragbar ist, lautet die ehrliche Lösung: eine Maschine mit mehr Kernen, keine Abkürzung an der Verifikation vorbei.
Die Bootstrap-Daemon-Falle. monerod kann Wallet-Anfragen über einen öffentlichen Node beantworten, während die eigene Synchronisation aufholt – eine Bequemlichkeit mit scharfer Kante: Solange sie aktiv ist, wird Ihr Wallet-Verkehr von genau der Art Dritter bedient, die dieser Leitfaden beseitigen soll. Wenn Sie das aktivieren, um in der ersten Stunde arbeitsfähig zu sein, setzen Sie sich eine Erinnerung in den Kalender und schalten Sie es ab, sobald Ihre eigene Höhe die Blockspitze erreicht. Ein vorübergehender Kompromiss, an dessen Ende niemand denkt, ist einfach der alte Aufbau unter neuem Namen.
Wenn die Höhe stehen bleibt und mit einem Block-Explorer übereinstimmt, dem Sie vertrauen, ist der Node live. Ab hier kostet Sie der Daemon ein paar Gigabyte Traffic pro Tag, ein wenig CPU und darüber hinaus keine Aufmerksamkeit außer bei Upgrades.
Die beschränkte RPC-Schnittstelle ist an das Loopback-Interface gebunden, damit ist sie derzeit für nichts erreichbar. Das ist die richtige Voreinstellung, und im Rest dieses Schritts geht es darum, wie Sie diese Lücke überbrücken. Wählen Sie einen Weg – sie lassen sich schlecht kombinieren, und Sie brauchen nur einen.
Option A · SSH-Tunnel – eine Maschine, kein Aufwand. Die richtige Antwort, wenn Sie ein einziges Notebook nutzen. Nichts wird neu installiert, nichts lauscht zusätzlich, und der Tunnel stirbt mit der Sitzung. Ihre Wallet zeigt dann auf 127.0.0.1:18089, als wäre der Node lokal.
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 – mehrere Geräte, immer verfügbar. Die richtige Antwort für Handy plus Desktop plus Notebook. Der Node tritt Ihrem privaten Netzwerk bei, und die Wallets sprechen ihn über seine Tunnel-IP an, ohne dass überhaupt ein Port zum Internet offen steht. Der WireGuard-Leitfaden baut den Tunnel; der einzige zusätzliche Schritt hier ist, den Daemon darauf antworten zu lassen.
# 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 · v3-Onion – überall, kein Port, keine feste IP. Die richtige Antwort, wenn Sie reisen oder wenn der Node ohne jeden eingehenden Port erreichbar sein soll. Tor veröffentlicht den Dienst; es gibt nichts weiterzuleiten und nichts zu scannen. Der Leitfaden zum Hidden Service behandelt die vollständige torrc; der Node-spezifische Teil sind drei Zeilen.
# /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
Welche Tür Sie auch gebaut haben, auf der Wallet-Seite sind es immer dieselben drei Felder. In Feather: Settings → Node → eigenen Node hinzufügen, Host und Port, und den Tor-Proxy aktivieren, falls Sie die Onion-Adresse gewählt haben. In der offiziellen Monero-GUI: Settings → Node → Remote node, mit ausgewähltem „connect to a remote node“. In Cake Wallet: Settings → Nodes → Node hinzufügen, was eine Onion-Adresse direkt akzeptiert. Wenn Sie auf der RPC-Schnittstelle Benutzername und Passwort gesetzt haben, gibt es in allen dreien Felder dafür.
Prüfen Sie dann, ob es funktioniert hat. Die Wallet sollte dieselbe Höhe anzeigen wie Ihr Node, und der Node sollte einen RPC-Client mehr melden. Wenn die Wallet immer noch in einer knappen Sekunde aktualisiert, spricht sie vermutlich weiterhin mit dem öffentlichen Standard-Node – die meisten Wallets behalten den alten in der Liste und fallen stillschweigend darauf zurück.
Ihre Wallet übergibt Transaktionen nicht mehr einem Fremden – sie übergibt sie Ihrem eigenen Daemon. Aber dieser Daemon kündigt sie seinen Peers dann von der IP-Adresse Ihres Servers aus an, und Peers machen sich Notizen. Monero verteilt eine neue Transaktion bereits über eine zufällige Relay-Phase, bevor sie sich ausbreitet, was den ersten Sprung schwer identifizierbar macht; sie stattdessen über Tor hinauszuschicken, beseitigt die Frage vollständig.
Eine Zeile genügt. Der Daemon synchronisiert Blöcke weiterhin über das Clearnet – das hält die Synchronisation schnell – und leitet nur die Verbreitung Ihrer ausgehenden Transaktionen über den lokalen Tor-SOCKS-Port:
# in /etc/monerod.conf, with tor running locally
tx-proxy=tor,127.0.0.1:9050,16
Wenn Sie weiter gehen und auch Peers über Tor annehmen wollen, veröffentlichen Sie einen zweiten Hidden Service für die P2P-Seite und teilen dem Daemon mit, welche Onion-Adresse er bekannt machen soll. Die Portnummer ist Ihre Wahl, solange beide Hälften übereinstimmen und nichts anderes auf der Maschine sie bereits nutzt:
# /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
Dieser Schritt hilft dem Netzwerk mehr als Ihnen, was ein vollkommen guter Grund ist, ihn zu gehen. Er kostet ein wenig Latenz und ein paar Peer-Slots, und er sorgt dafür, dass reine Tor-Nodes irgendwo eine Verbindung finden.
Optional: einen öffentlichen Node spenden. Wenn Sie die Bandbreite und den Speicher haben, können Sie Ihren beschränkten RPC-Endpunkt bekannt machen, damit die Wallets anderer Leute ihn nutzen können. Das ist ein echter Beitrag zu einem Netzwerk, dessen schwächster Punkt darin besteht, wie wenige Menschen einen eigenen Daemon betreiben – und es bringt die Pflichten jedes öffentlichen Dienstes mit sich: Sie tragen den Verkehr anderer Leute, und Sie sind als Node-Betreiber sichtbar. Jeder Tarif hier enthält unbegrenzte Bandbreite, das Erste davon ist also eine Entscheidung und keine Rechnung.
# 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
Ein Node steht außerdem gut neben anderer selbst gehosteter Infrastruktur – etwa einem Lightning-Node im selben Rack. Halten Sie sie auf getrennten Maschinen, wenn das Budget es zulässt: Sie haben unterschiedliche Verfügbarkeitsanforderungen und sehr unterschiedliche Wiederherstellungswege.
Der Daemon stoppt, und die Datenbank braucht möglicherweise einen Reparaturlauf, bevor sie sich wieder öffnen lässt. Prüfen Sie den freien Speicher während der Synchronisation täglich und wählen Sie den Tarif für die Blockchain in drei Jahren, nicht für die von heute.
Port 18081 beantwortet administrative Aufrufe. Er gehört für immer auf 127.0.0.1. Wenn etwas von außen den Node erreichen muss, erreicht es den beschränkten Listener auf 18089, und zwar durch einen Tunnel.
Ihren Node der Liste hinzuzufügen wählt ihn nicht aus, und die meisten Wallets fallen stillschweigend zurück, wenn er nicht erreichbar ist. Vergleichen Sie die Höhen und stellen Sie sicher, dass der Node einen verbundenen RPC-Client meldet.
Es später hinzuzufügen verkleinert eine bestehende Datenbank nicht. Umwandeln heißt, den Daemon zu stoppen und monero-blockchain-prune laufen zu lassen, was Stunden und Arbeitsspeicherplatz braucht. Entscheiden Sie vor dem ersten Start.
Ein Netzwerk-Upgrade ist durchgelaufen, und der Daemon wurde nie aktualisiert. Er schreit nicht – die Höhe passt einfach nicht mehr zur Realität. Verfolgen Sie die Release-Ankündigungen und aktualisieren Sie vor der Fork-Höhe.
SIGKILL mitten in einem Schreibvorgang, meist aus einer systemd-Unit ohne KillSignal und mit kurzem Stopp-Timeout. Verwenden Sie SIGINT, geben Sie ihm fünf Minuten und lassen Sie den Daemon seine Datenbank selbst schließen.
Zehn Fragen, die vor, während und nach dem Umzug einer Wallet auf einen selbst betriebenen Daemon aufkommen.
Nein. Monero-Wallets scannen clientseitig: Die Wallet fordert vom Node einen Blockbereich an, lädt die Blöcke vollständig herunter und versucht, jeden Output lokal mit Ihrem privaten View-Key zu entschlüsseln. Der Node erhält niemals Ihren View-Key, Ihren Spend-Key oder Ihre Adresse, und er kann nicht erkennen, welche der eben ausgelieferten Outputs Ihnen gehören. Das ist ein echter architektonischer Unterschied zu Bitcoin-Light-Wallets, bei denen dem Server üblicherweise mitgeteilt wird, welche Adressen oder Scripts er beobachten soll. Was ein Remote-Node sehr wohl erfährt, ist die Netzwerkebene: Ihre IP-Adresse, die Tatsache, dass eine Wallet an dieser IP synchronisiert, den angefragten Blockbereich – der die Restore-Height Ihrer Wallet eingrenzt – und vor allem jede Transaktion, die Sie ihm zum Verbreiten übergeben. Genau dieses letzte Leck lohnt es zu schließen.
Betreiben Sie einen Pruned-Node, sofern nichts dagegen spricht. Ein Pruned-Node verwirft sieben Achtel der Ring-Signatur-Daten alter Blöcke, behält alles, was eine Wallet oder ein neuer Peer tatsächlich von Ihnen braucht, validiert die gesamte Blockchain weiterhin selbst und landet bei rund einem Drittel des Speicherplatzes eines Full-Nodes. Als Backend für die eigene Wallet ist das Verhalten nicht zu unterscheiden. Betreiben Sie einen Full-Node, wenn Sie einem frisch aufgesetzten Node dessen eigene Erstsynchronisation von Grund auf liefern können wollen, wenn Sie Werkzeuge im Stil eines Block-Explorers betreiben, die beliebige historische Transaktionsdaten lesen, oder wenn Sie schlicht eine vollständige Archivkopie möchten. Entscheiden Sie vor der ersten Synchronisation: --prune-blockchain prunet bereits während der Synchronisation, während die Umwandlung einer schon synchronisierten vollständigen Datenbank bedeutet, den Daemon zu stoppen und das separate Werkzeug monero-blockchain-prune darüber laufen zu lassen.
Ein Full-Node liegt Mitte 2026 jenseits von 240 GB und wächst um mehrere zehn Gigabyte pro Jahr – dimensionieren Sie also für die Blockchain, die Sie in drei Jahren haben werden, nicht für die von heute. Ein Pruned-Node braucht rund ein Drittel davon – derzeit etwa 85 bis 95 GB. In der Praxis heißt das: Ein Garrison (240 GB NVMe) ist das bequeme Zuhause für einen Pruned-Node mit jahrelangem Spielraum, und ein Ravelin (480 GB) ist die richtige Maschine für einen Full-Node. Ein Sentinel mit 120 GB fasst heute einen Pruned-Node und wird Sie früher wieder beschäftigen, als Ihnen lieb ist. Prüfen Sie die aktuelle Größe der Blockchain, bevor Sie den Speicher kaufen – das ist die eine Zahl in diesem Leitfaden, die garantiert veraltet ist.
Ein bis zwei Tage auf NVMe für die erste Synchronisation, und begrenzend sind CPU und Datenträger, nicht Ihre Leitung. Der Daemon prüft jede Ring-Signatur und jeden Range-Proof vom Genesis-Block an; das ist die eigentliche Arbeit, und sie ist der Grund, warum sich ein eigener Node überhaupt lohnt. Zwei Dinge verschlechtern das dramatisch: rotierende Festplatten statt NVMe, was aus zwei Tagen eine Woche machen kann, und ein Datenträger, der auf halbem Weg volläuft. Zwei Dinge helfen weniger, als viele erwarten: mehr Bandbreite und mehr RAM über das hinaus, was die Datenbankseiten warm hält. Importieren Sie kein heruntergeladenes Blockchain-Archiv von Dritten, um die Wartezeit zu überspringen – Sie würden damit genau der Partei vertrauen, der Sie das Vertrauen entziehen wollten.
Den unbeschränkten niemals. Die unbeschränkte RPC-Schnittstelle gibt administrative Aufrufe frei und sollte für die gesamte Lebensdauer des Nodes an 127.0.0.1 gebunden bleiben. Die beschränkte Schnittstelle ist etwas anderes: Sie beantwortet nur die rein lesenden Aufrufe, die eine Wallet braucht, und ist genau das, was jeder öffentliche Node im Netz anbietet. Trotzdem verkündet ihre Veröffentlichung auf einem Clearnet-Port jedem, der den Adressraum scannt: „Hier ist ein Monero-Nutzer.“ Die Rangfolge in diesem Leitfaden lautet: zuerst ein v3-Onion-Service, zweitens ein WireGuard-Tunnel, drittens ein SSH-Tunnel für eine einzelne Maschine – und ein offener öffentlicher Port nur dann, wenn Sie sich bewusst entschieden haben, dem Netzwerk einen öffentlichen Node zu spenden.
Ein Node hält keine Schlüssel, verwahrt keine Guthaben und kann niemandes Geld bewegen. Er validiert Blöcke und leitet Transaktionen weiter, die andere bereits signiert haben – dieselbe Rolle wie ein Mail-Relay, das Nachrichten transportiert, die es nicht lesen kann. Das ist die technische Realität; die rechtliche Realität hängt von der Jurisdiktion ab, und dieser Leitfaden ist keine Rechtsberatung. Was die Jurisdiktion sehr wohl ändert, ist die Frage, wer was erzwingen kann: Der Leitfaden zu den vier nordischen Jurisdiktionen geht die Gesetze durch, die für einen Server in Stockholm, Helsinki, Oslo oder Reykjavík gelten.
Nur, wenn Sie ihn aktualisieren. Monero führt geplante Netzwerk-Upgrades durch, und ein Daemon mit einem älteren Konsens-Regelwerk folgt der Hauptkette ab der Fork-Höhe nicht mehr – er warnt Sie nicht lautstark, er bleibt einfach stehen oder zweigt ab, und Ihre Wallet meldet klaglos eine Höhe, die nicht mehr der Realität entspricht. Abonnieren Sie die Release-Ankündigungen, fixieren Sie die installierte Version, statt einem beweglichen Tag zu folgen, und tragen Sie sich die angekündigte Upgrade-Höhe in den Kalender ein. Das ist die mit Abstand häufigste Art, wie ein selbst gehosteter Node unbrauchbar wird: kein Absturz, sondern ein Betreiber, der aufgehört hat zu lesen.
Leiten Sie das Verbreiten Ihrer ausgehenden Transaktionen über Tor – das ist die eine Einstellung mit klarem, billigem Gewinn an Privatsphäre, denn sie trennt „diese Transaktion ist ins Netz gelangt“ von „diese IP-Adresse existiert“. Auch eingehende Tor-Peers anzunehmen, ist ein weiterer Schritt, der dem Netzwerk mehr hilft als Ihnen und ein wenig Latenz kostet. Sämtlichen Peer-Verkehr über Tor zu leiten, ist die aggressive Variante: Sie funktioniert und macht Ihre Erstsynchronisation deutlich langsamer, weshalb die meisten über Clearnet synchronisieren und danach den Transaktionspfad auf Tor umstellen. Der Leitfaden zum Tor-Hidden-Service behandelt die torrc-Seite ausführlicher.
Fast immer die Restore-Height. Eine Wallet ohne Restore-Height oder mit dem Wert null durchsucht bei jeder Wiederherstellung die Blockchain erneut ab dem Genesis-Block – stundenlange lokale Arbeit für nichts. Setzen Sie die Restore-Height auf den Block, der zum Zeitpunkt der Wallet-Erstellung existierte. Die zweite Ursache ist der Netzwerkpfad: Eine Wallet in einem anderen Land, die über einen ausgelasteten Onion-Circuit mit Ihrem Node spricht, ist langsamer als dieselbe Wallet an einem öffentlichen Node nebenan – das ist der Preis der Privatsphäre, und ein WireGuard-Tunnel holt meist den größten Teil der Geschwindigkeit zurück. Die dritte Ursache, die gern übersehen wird: Ihr Node hat seine eigene Erstsynchronisation noch nicht abgeschlossen und antwortet weiterhin über einen Bootstrap-Daemon.
Weil ein Node ein langlebiges, öffentlich erreichbares Objekt ist, durch das Ihre Transaktionen laufen. Ein eigener Full-Node schließt das Leck zwischen Ihrer Wallet und dem Node eines Fremden – und öffnet dann ein kleineres, zwischen Ihrem Node und demjenigen, der Ihnen die Maschine vermietet hat. Wenn zur Anmeldung für diese Maschine ein Passscan und eine Karte auf Ihren bürgerlichen Namen gehörten, haben Sie die Verknüpfung nur verschoben, nicht beseitigt. Den Server, der Ihren Monero-Node betreibt, in Monero zu bezahlen, ist kein Slogan; es ist die einzige Variante dieses Aufbaus, in der beide Ebenen zueinander passen. Der übergeordnete Leitfaden zum anonymen VPS-Hosting geht die drei Ebenen von Anfang bis Ende durch.
Garrison (4 vCPU, 8 GB, 240 GB NVMe, 7,90 $/Monat) fasst einen Pruned-Node mit jahrelangem Spielraum; Ravelin (480 GB) nimmt die vollständige Blockchain auf. Unbegrenzte Bandbreite in jedem Tarif, keine E-Mail bei der Anmeldung, niemals ein Ausweisdokument.
Zuletzt überprüft · 2026-10-12 · Quellen · Nutzerhandbücher auf getmonero.org (Node betreiben, Pruning, Tor und I2P), monerod --help auf der Reihe v0.18, Dokumentation von Debian 12 und des Tor Project · Rhythmus · jährlich
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.
Privates Hosting, im Norden gebaut.