Tor Relay VPS Hosting: Run a Tor Node on Offshore Infrastructure

The Tor network consists of three types of relays: guards (entry nodes), middle relays, and exit nodes. Each carries different operational considerations. Guard nodes are the first hop in a Tor circuit and see the client's IP address. Middle relays handle encrypted traffic between guards and exits, seeing neither the client's IP nor the destination. Exit nodes are the final hop and make connections to the open internet on behalf of Tor users - exit traffic appears to originate from the exit node's IP address.

For most VPS operators, running a middle relay is the optimal choice. Middle relays carry the privacy benefits of contributing to the Tor network without the legal and operational complexity of exit node operation. Middle relay operators do not see client IPs, do not see destination websites, and do not generate traffic that appears to originate from their IP toward potentially sensitive destinations. The legal risk profile of a middle relay is equivalent to that of any other encrypted traffic passing through a server.

Bridge relays are unlisted Tor entry points used by users in censored regions where the public Tor relay list is blocked. Running a bridge node (with or without obfuscation via obfs4) helps users in China, Iran, Russia, and other censored environments connect to the Tor network when direct connections are blocked. Bridges receive lower traffic volume than middle relays but serve a critical circumvention function. obfs4 bridges are especially valuable because they disguise Tor traffic as random data, defeating the DPI fingerprinting used to block standard Tor connections.

Exit nodes require careful consideration: your VPS's IP will appear in the source field of traffic exiting through your relay. AnubizHost's offshore locations have more tolerant abuse handling than most datacenter jurisdictions, but exit node operation still generates DMCA and abuse complaints that require management. Experienced Tor operators often start with a middle relay, operate it for several months to build relay reputation and flag assignment, and then evaluate whether to add exit capacity.

Install Tor from the official Tor Project repository for your distribution. On Debian/Ubuntu, add the Tor Project's APT repository and install tor and tor-geoipdb: follow the instructions at https://support.torproject.org/apt/. Using the official repository ensures you receive the latest stable release with security patches, rather than the older version in the OS package repositories.

Configure the relay in /etc/tor/torrc. For a middle relay, set: Nickname (a public name for your relay), ContactInfo (a way for Tor operators to reach you - use a privacy-preserving email like a ProtonMail address), ORPort 9001 (the port Tor clients connect to), RelayBandwidthRate and RelayBandwidthBurst (set these to values appropriate for your VPS plan - 100 Mbytes (100 MB/s) is a good starting point for a dedicated relay VPS), and ExitPolicy reject *:* to explicitly declare yourself a non-exit relay.

For a bridge with obfs4 obfuscation, additionally install obfs4proxy (apt install obfs4proxy), add BridgeRelay 1 and ServerTransportPlugin obfs4 exec /usr/bin/obfs4proxy to torrc, and set ServerTransportListenAddr obfs4 0.0.0.0:obfs4port. After starting Tor, retrieve your bridge line with cat /var/lib/tor/pt_state/obfs4_bridgeline.txt and register it with the Tor Bridge Database at bridges.torproject.org if you want Tor Browser users to discover your bridge automatically. Alternatively, distribute your bridge line directly to users who need it.

Monitor your relay's status after 24-48 hours on the Tor Metrics site (metrics.torproject.org) by searching for your relay's fingerprint. A healthy relay will show in the consensus and gradually attract more traffic as the Tor network's bandwidth authority measures its capacity and stability. New relays receive the Stable and Fast flags after approximately one week of consistent operation.

Tor relays are bandwidth-intensive. A middle relay with no artificial limits will use every available megabit of your VPS's uplink - which is typically 1 Gbps unthrottled on AnubizHost plans. This is excellent for the Tor network but will consume your monthly bandwidth allocation rapidly. Plan bandwidth usage carefully: a relay running at 10 Mbps average uses approximately 3.24 TB/month. AnubizHost VPS plans include generous bandwidth allocations, but check the specific plan limits before setting your relay bandwidth caps.

Set RelayBandwidthRate to a value that fits within your plan's monthly allocation. For a plan with 5 TB/month of bandwidth, a safe sustained rate is around 15 Mbps (5 TB / 30 days / 86400 seconds ≈ 15 Mbps). Set RelayBandwidthBurst to 2-3x the rate value to allow short traffic spikes without exceeding the sustained rate. Monitor actual usage via your VPS control panel's bandwidth graphs and adjust the torrc values accordingly.

CPU usage for a middle relay is modest: Tor's cryptographic operations use one CPU core. For a relay processing 50-100 Mbps of traffic, one vCPU is adequate. Higher throughput relays benefit from additional cores as Tor can use multiple worker threads for circuit management, though the bandwidth constraint is usually the bottleneck before CPU becomes limiting.

Memory usage is proportional to the number of active circuits. A relay handling 1,000 simultaneous circuits uses approximately 500 MB of RAM. The base Romania Start plan (512 MB RAM) is suitable for a modest relay; the Romania Basic plan (2 GB RAM) comfortably handles a high-throughput relay. Monitor memory usage with systemctl status tor and adjust MaxMemInQueues in torrc if you see excessive memory consumption.