Monero GUI connects to custom remote nodes in Advanced mode

Monero GUI requires Advanced mode to select a custom remote node. Simple mode chooses a remote connection automatically, while Simple mode (bootstrap) downloads a local blockchain alongside temporary remote access. Selecting Remote node in Advanced mode avoids that local download, although the wallet still needs to scan transaction history.

How do you enable a custom remote node?

Custom node selection belongs to Advanced mode, and the Node settings become available after you open your wallet in that mode.

Locate the mode selector

Settings, then Info shows the current Wallet mode. To change it, close the open wallet through Settings, then Wallet and Close this wallet. The welcome screen contains Change wallet mode, where Advanced mode is available. Reopen the existing wallet file afterward. Changing this interface setting does not require creating another wallet or entering its recovery seed.

Select the saved endpoint

Settings, then Node contains the Remote node option. Add remote node opens the endpoint fields. Enter the daemon's address, RPC port and any required login credentials. Confirm the daemon uses the same network as the wallet, then save and select the entry to connect. Advanced mode also retains local node controls, so choosing it alone does not determine whether you download the blockchain.

The wallet scans data supplied by the daemon

The remote daemon, monerod, supplies blockchain data and relays submitted transactions. The wallet contacts its RPC interface, meaning remote procedure calls. The GUI scans blockchain data for its wallet's outputs even when it connects to a remote node. That scan lets the wallet recognize incoming payments and update its balance. The node's database remains separate from the wallet files storing keys and transaction history.

Normal GUI remote-node configuration does not require sending the daemon your private view key. A remote scanning service which receives that key searches transaction data on the wallet's behalf. Handing over this scanning task creates a different privacy boundary from supplying the GUI with blockchain data.

View full-size image

Connection parameters identify the intended daemon

A custom connection needs the daemon's address and wallet-facing RPC port, plus its login credentials when the operator requires authentication for access.

The RPC port serves wallets; a peer-to-peer port serves communication between nodes. Public endpoints may use different port configurations, so a familiar number is not sufficient to identify the right interface. Daemon credentials also differ from the password protecting your wallet file. The endpoint requires its own login only when its operator enables authentication. Authentication alone does not encrypt the connection.

Bootstrap access accompanies a local blockchain download

Simple mode (bootstrap) starts a local node and uses temporary remote access while that node synchronizes a pruned blockchain in the background.

Automatic bootstrap selection

The simplified bootstrap mode chooses its remote connection automatically. A local daemon using a bootstrap node forwards wallet RPC requests to that remote server while local synchronization is incomplete. The local database continues growing during this period. Bootstrap access therefore does not satisfy a requirement to avoid storing blockchain data on the wallet computer.

Custom bootstrap settings

Advanced mode can also pair a local node with a custom bootstrap endpoint. This differs from selecting Remote node as the wallet's connection type. Bootstrap use can stop when the local node catches up and resume if it falls behind. Removing a bootstrap dependency means using a synchronized local node without a bootstrap endpoint configured.

Connection and synchronization indicators answer different questions

A daemon's synchronized status describes its chain state; the wallet progress indicator describes the scan needed to reconstruct its transaction history.

A successful RPC connection establishes reachability. It does not establish the operator's honesty or mean the wallet has finished scanning. A daemon behind the network can answer requests while lacking recent blocks. The displayed chain height describes the selected daemon's available history, so a responsive endpoint can still leave recent activity absent from the wallet.

Wallet scanning speed depends on the history it must examine, connection performance and the wallet computer's processing and storage resources. Remote access avoids the local node's blockchain download. It does not provide a fixed completion time for the remaining wallet scan, and a change of endpoint cannot eliminate that work.

View full-size image

An existing wallet generally scans blocks it has not yet processed. Restoring a wallet may require examining an older portion of history. A finished daemon progress indicator alongside ongoing wallet progress can therefore describe normal scanning. Treat the unfinished wallet scan separately from an endpoint connection failure.

The operator observes requests outside transaction privacy

Choosing a remote operator determines who receives wallet requests and observes the connection, even though ordinary transactions retain their protections for recipients and amounts.

Connection metadata

The operator of a directly connected remote node can associate your connection IP address with transactions submitted through it. Request patterns can reveal additional information about wallet activity. A malicious daemon can supply misleading responses or use those patterns to investigate transactions. Routing the wallet connection through Tor can reduce exposure of its originating IP address. That transport protection does not certify the server's behavior, and automatic node selection does not remove these concerns.

View full-size image

Trusted daemon behavior

Mark as Trusted Daemon changes wallet behavior without testing the operator. Untrusted mode obfuscates some data requests, while trusted mode relaxes that protection and permits operations requiring trust in the daemon. Control over your own server gives the setting a concrete basis. A public listing, a login requirement or a working connection does not establish the same control.

Node location and node ownership are separate choices

A remote node can belong to you; another machine holds its blockchain, while your control over that machine determines who administers the daemon.

A private server you operate offers remote access without handing daemon administration to an unfamiliar provider. You still need to synchronize that server, keep it available and configure a reachable RPC endpoint. Authentication limits access when configured, while the connection's transport determines how traffic travels. Running the daemon elsewhere moves the storage requirement to that machine.

A local node without bootstrap access supplies data from your own synchronized database and avoids a third-party wallet RPC connection. Pruning can reduce its storage burden while retaining transaction history; it still requires local synchronization and disk space. Compared with a custom remote connection, this choice keeps the daemon on the wallet computer and gives you direct responsibility for its availability and blockchain data.