Tor Conflux Multipath: Faster Onion Services on Your VPS

Classic Tor sends every byte of a stream down one circuit: three relays, fixed for the life of the connection. If any one of those relays is slow or congested, the whole transfer crawls. Conflux, specified in Tor Proposal 329 ("Overcoming Tor's Bottlenecks with Traffic Splitting"), attacks that bottleneck by building a second circuit to the same endpoint and dynamically splitting cells across both legs.

The two legs are joined with a small handshake (the RELAY_CONFLUX_LINK / RELAY_CONFLUX_LINKED cells), and a sequence-number scheme plus RELAY_CONFLUX_SWITCH cells let the receiver reassemble the interleaved data in order. Crucially, Conflux is built on top of Tor's congestion-control work: each leg measures its own round-trip time and congestion window, and the scheduler uses that live information to decide which leg to feed next.

• MinRTT scheduler (latency-optimised): always sends on the leg with the lowest current RTT, only switching when that leg's latency rises above the other. Best for interactive use, such as SSH or a chat backend.
• LowRTT scheduler (throughput-optimised): keeps both legs busy, sending on whichever has the lowest RTT and an unblocked local connection, so a large download or stream can use the combined capacity of two paths.

Endpoints can even signal a desired user experience (the DESIRED_UX field exposes options like MIN_LATENCY and HIGH_THROUGHPUT), so a service can hint whether it cares more about snappiness or raw bandwidth.

This is the part most write-ups get wrong, so be precise: Conflux for exit traffic shipped network-wide in the C-Tor 0.4.8 stable series and is enabled by default. Onion-service Conflux is a different, harder case and is not yet live in stable C-Tor.

For a hidden service, there is no exit. The two legs must instead be a pair of rendezvous circuits. In Proposal 329 the client sends two introduce requests to the service's introduction point, the service builds two rendezvous circuits to two separate rendezvous points, and Conflux links those. Path-selection rules require the relay identities across both legs to be distinct so you are not just doubling up on the same congested middle.

That rendezvous-linking machinery is being implemented in Arti, the Rust rewrite of Tor. Through 2025 and into 2026 the Arti releases (1.4.1 laid the groundwork, with multi-legged tunnel work continuing in 1.4.4, 1.4.6 and later) have been steadily building it out, but it has not reached a stable, default-on state for onion services as of mid-2026. The honest takeaway: do not expect a magic 2x today, but the protocol and tooling are arriving, and a service set up correctly now will benefit the moment it lands.

Before counting on multipath, fix the bottlenecks you control right now. An onion service routes through six relays (three from the client, three from the service) plus a rendezvous point, so end-to-end speed is governed by the slowest hop and by your own server's ability to keep circuits fed.

• Single-threaded crypto. The Tor daemon does relay-cell encryption largely on one core. A box with a few fast cores beats a box with many slow ones. Dedicated vCPU, not oversubscribed shared cores, is what keeps a busy onion service responsive.
• Guard and circuit health. Your service's entry guards and its rendezvous circuits set the floor on latency. A VPS with a clean, low-latency uplink to the Tor network reaches better relays and rebuilds circuits faster.
• Bandwidth headroom and steady I/O. Conflux can only fill two legs if your server can produce the data. NVMe storage and unmetered bandwidth stop disk seeks and overage throttling from becoming the real cap.
• Memory for many circuits. Each linked Conflux session doubles the circuit count, and Tor keeps reordering buffers per leg. Dedicated RAM matters once you have real traffic.

This is exactly why the host underneath your hidden service matters. Our offshore VPS plans give you dedicated cores, NVMe, full root access and unmetered bandwidth in privacy-friendly jurisdictions, and for high-traffic services a dedicated offshore server removes hypervisor neighbours from the equation entirely.

You cannot force onion-service Conflux on in stable C-Tor today, but you can run a configuration that is multipath-ready and faster regardless. Start from a current Tor and a minimal torrc:

HiddenServiceDir /var/lib/tor/hs/
HiddenServicePort 80 127.0.0.1:8080

# v3 onion services and congestion control are the foundation Conflux
# builds on - keep Tor up to date so you inherit it automatically.
# Spread load across cores if your service is busy:
NumCPUs 0          # 0 = autodetect; set explicitly on dedicated boxes

Practical steps that pay off now and compound once multipath lands:

• Run a recent Tor (or track Arti). Congestion control and Conflux are version-gated. Update regularly so you get scheduler and circuit-building fixes - several 0.4.8.x point releases specifically fixed Conflux circuit-building regressions.
• Use Onionbalance for real scale. Onionbalance lets one .onion address publish descriptors backed by several independent backend instances, each on its own offshore VPS, distributing client load across servers. It is the proven way to scale a busy hidden service today and composes cleanly with per-instance multipath later.
• Keep the origin local and lean. Bind your web app to 127.0.0.1, terminate TLS at the application if you want defence in depth, and avoid heavy reverse-proxy chains that add latency Conflux cannot recover.
• Right-size, do not over-provision. A 2-4 dedicated-core VPS with NVMe and unmetered transfer serves most onion services comfortably; scale up only when guard saturation or CPU, not the Tor protocol, is the proven bottleneck.