Tor Circuit Isolation Settings - Privacy vs Performance Trade-offs

Without circuit isolation, all traffic from a Tor client could share a single circuit. An adversary who controls an exit node would see all traffic from that circuit to clearnet destinations. By correlating which destinations a single circuit accesses, the adversary builds a profile of the user's browsing session. This profile can sometimes reveal identity through the combination of sites accessed, timing patterns, or logged-in account activity.

Circuit isolation prevents this by ensuring traffic to different first-party domains uses different circuits. Even if an adversary controls an exit node that sees traffic from multiple circuits, they cannot link the circuits to each other without performing traffic correlation at the Tor entry point - a much more expensive attack.

Tor Browser enables isolation by default for new identity and per-site isolation for most traffic. This is the right default for high-privacy browsing. Understanding when to reduce isolation for performance enables informed trade-offs for users whose threat model does not require per-site circuit isolation.

Tor's SOCKSPort accepts flags that control isolation behavior. The IsolateSOCKSAuth flag (default) routes traffic from SOCKS connections with different credentials through separate circuits. IsolateClientAddr routes traffic from different client addresses through separate circuits. IsolateDestAddr routes traffic to different destination IPs through separate circuits.

For Tor Browser, the default configuration is IsolateSOCKSAuth on the primary SOCKSPort. This means each website uses its own SOCKS credentials and therefore its own circuit. The performance cost is building a new circuit for each first-party domain that has not been recently visited, typically adding 2 to 5 seconds to the first request to each new site in a session.

For automated Tor usage (scripts, crawlers, API clients that are not Tor Browser), reducing isolation can dramatically improve performance. A script that makes requests to many different domains in sequence will build a new circuit for each domain with default isolation. Removing isolation (SOCKSPort 9050 with no IsolateSOCKSAuth flag) routes all requests through a single circuit pool, reducing circuit overhead at the cost of correlation risk.

Measure isolation overhead by comparing total time for a sequence of requests with and without isolation. In a typical session visiting 20 different sites, per-site isolation requires building approximately 20 circuits over the session. Circuit build time averages 2 to 4 seconds each. The cumulative overhead is 40 to 80 seconds of circuit-building latency spread across the session.

Without isolation (single circuit for all destinations), circuit build time occurs only once at session start. The 40 to 80 seconds of cumulative circuit-building latency is eliminated. This is a dramatic improvement for applications that access many different destinations in sequence, such as security research tools, link checkers, or aggregate content fetchers.

The privacy cost must be weighed against this performance gain. For use cases where traffic correlation is not a concern (e.g., accessing your own hidden service infrastructure from a known, controlled vantage point), removing isolation is reasonable. For user-facing browsers handling sensitive browsing, default isolation is the correct configuration regardless of performance cost.