TorConfig: HTTP calls (RGS, scoring, LNURL-auth) bypass SOCKS proxy

Problem

When TorConfig is set, only peer connections to .onion addresses are routed through the SOCKS proxy. All HTTP calls made by ldk-node (RGS gossip sync, pathfinding scoring, and LNURL-auth) go direct over clearnet.

This means even a node connecting exclusively to .onion peers still leaks its IP to rapidsync.lightningdevkit.org on every gossip sync cycle.

Proposal

Route HTTP calls through the configured SOCKS5 proxy when TorConfig is set. Three call sites in ldk-node use bitreq for HTTP:

gossip.rs: RGS snapshot fetch
scoring.rs: external pathfinding scores
lnurl_auth.rs: LNURL-auth challenge/response

bitreq's proxy feature currently supports HTTP CONNECT but not SOCKS5. SOCKS5 support (~180 lines, RFC 1928) would need to be added to bitreq, either upstream or via fork.

This could be unconditional (always proxy HTTP when TorConfig is set) or gated behind an opt-in flag. Happy to hear what the maintainers prefer.

Context

I'm building a mobile Lightning node (Android) with embedded Tor (Arti). I have a working implementation of this: SOCKS5 in a bitreq fork + proxy plumbing in ldk-node. Tested on a live node with an open channel. Happy to submit a PR if this direction makes sense.

Yes, this is known and was so far a dedicated design decision, as in this first step we mainly wanted to be able to peer with .onion nodes. Def. feel free to work on improving this though, but we'd then need to make sure that we can really proxy everything over Tor, i.e., all chain sources for example would need to work.

See rust-bitcoin/corepc#472 for the bitreq discussion on adding SOCKS support, btw.

Thanks. I have a working implementation: SOCKS5 in a bitreq fork + route_all_traffic plumbing in ldk-node. Tested on a live node with an open channel over Tor.

Plan is to upstream the bitreq SOCKS5 support first (see rust-bitcoin/corepc#472), then submit the ldk-node PR that wires HTTP calls through the SOCKS proxy when TorConfig is set.

For chain sources: bitcoind RPC is typically local (127.0.0.1) so doesn't need proxying. Esplora would need it, but that's just another bitreq call.

Cool, yeah, then the next step is really to move forward with SOCKS support in bitreq, before we can revisit here.

bitreq: add SOCKS5 proxy support

bitreq 0.4 (0.4.0 on 2026-09-28, 0.4.2 on 2026-10-20) ships the SOCKS5 support from rust-bitcoin/corepc#533, so picking this back up. The outbound paths in ldk-node today and what each needs:

RGS, scoring, LNURL-auth (bitreq calls in gossip.rs, scoring.rs, lnurl_auth.rs): bump bitreq to 0.4 with the proxy feature and set with_proxy(Proxy::new_socks5(..)) on the requests. Payjoin (Add Payjoin Receiver Support (BIP 77) #746) adds a fourth bitreq site that needs the same.
Electrum: electrum-client already has Socks5Config and the proxy feature is on; wire it through ConfigBuilder::socks5.
Esplora: the BDK side (esplora-client 0.12, reqwest with socks) takes a socks5h:// proxy through Builder.proxy as is. The lightning-transaction-sync side (esplora-client 0.13, now on bitreq) only builds Proxy::new_http from Builder.proxy, so it needs a small change upstream to pick new_socks5 for a socks5:// URL, plus the bitreq 0.4 bump.
bitcoind: lightning-block-sync's HttpClient is bitreq too but has no proxy option; a remote bitcoind over Tor needs one (rust-lightning change, with the bitreq bump).
VSS: vss-client-ng posts through bitreq with no proxy option; same shape of change there.

Config: an opt-in route_all_traffic: bool on TorConfig (default false), so existing users who set it for .onion peers keep direct clearnet connections, and when set, clearnet peer connections and every HTTP and Electrum connection above go through the proxy. That is what my fork runs.

I can do the esplora-client and lightning-block-sync changes and then the ldk-node PR; the vss-client one is the same shape. Holding the PRs until this has had a look.

Navigation Menu

Repository navigation

TorConfig: HTTP calls (RGS, scoring, LNURL-auth) bypass SOCKS proxy #834

Problem

Proposal

Context

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

TorConfig: HTTP calls (RGS, scoring, LNURL-auth) bypass SOCKS proxy #834

Description

Problem

Proposal

Context

Activity

tnull commented on Mar 19, 2026

FreeOnlineUser commented on Mar 20, 2026

tnull commented on Mar 20, 2026

FreeOnlineUser commented on Oct 21, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions