Middle, guard, exit — and why you want a middle
A Tor circuit has three hops. The guard (entry) is the first relay; it sees the user's real IP but not what they're doing. The middle relay passes encrypted traffic between the other two and sees neither who the user is nor where they're going — it's a blind courier. The exit relay is the last hop; it's the one that connects out to the actual destination website, which means to that website, the traffic appears to come from the exit relay's IP.
That last fact is the entire reason this article recommends a middle relay for almost everyone. When someone uses Tor to do something abusive — spam a forum, attack a server, worse — it comes out of an exit relay's IP. The complaints, the automated abuse reports, and in some jurisdictions the legal attention land on whoever runs that exit. You did nothing but forward packets, but your IP is what the target saw.
A middle relay carries none of that risk. It only ever talks to other Tor relays, never to the open internet on a user's behalf, so no external site ever sees your IP as the source of anything. No abuse complaints, no knock at the door. You still contribute real, needed capacity to the network. New relays even spend their first days as middle relays before Tor's directory authorities trust them enough to promote them to guard duty, which happens automatically.
My flat recommendation: run a middle relay. Run an exit only if you are an organization with legal cover, a dedicated IP range, a provider that explicitly permits it in writing, and a plan for the abuse reports — not something you bolt onto a personal VPS.
Read your provider's AUP first
Before you install anything: many hosts flatly prohibit Tor exit relays, and some prohibit relays of any kind, in their acceptable use policy. A middle or guard relay is uncontroversial at most providers because it generates no abuse traffic, but check. Running a relay against your host's terms is a fast way to lose the server and any balance on it. Providers that are relaxed about what you run — the sort where you sign up with just an email and top up with crypto, like NoctHost — are a natural fit for a middle relay, but the courtesy of reading the AUP still applies.
Install and configure
On Debian or Ubuntu, use the official Tor Project repository rather than the distro package, which lags behind. Once Tor is installed, the whole configuration lives in /etc/tor/torrc. Here's a complete middle-relay config:
Nickname mycozyrelay
ORPort 443
ExitRelay 0
SocksPort 0
ContactInfo [email protected]Line by line, because each one matters:
Nicknameis a label for your relay in the public directory. Pick anything; it's cosmetic.ORPort 443is the port other relays connect to. Using 443 (or 9001) is fine; 443 tends to be reachable from more restrictive networks.ExitRelay 0is the important one. It explicitly refuses to act as an exit. This is what keeps you a blind courier and off the abuse-report list. Do not omit it.SocksPort 0disables the local proxy — a relay doesn't need it, and turning it off avoids accidentally exposing an open proxy.ContactInfolets the Tor Project reach you if there's an issue with your relay. Use an address you'll actually read. It's public, so use a role address, not something you mind being scraped.
Restart Tor and watch the log:
sudo systemctl restart tor
sudo journalctl -u tor -fWithin a few minutes you want to see a line about a self-test succeeding and your ORPort being reachable. If it says the port is unreachable, your firewall is blocking it — open the ORPort:
sudo ufw allow 443/tcpAfter a few hours your relay appears on Tor's public metrics site by its nickname or fingerprint, and traffic starts to flow. It ramps up over days as the network gains confidence in it, not instantly — don't panic when a brand-new relay looks idle at first.
Bandwidth accounting so it doesn't eat your allowance
The one practical thing that trips people up: a relay will happily use every bit of bandwidth you give it, and most VPS plans meter transfer. Cap it in torrc.
To limit the sustained rate, so the relay doesn't saturate your link:
RelayBandwidthRate 10 MBytes
RelayBandwidthBurst 20 MBytesTo cap total monthly transfer, which is what actually protects you from an overage bill, use accounting. This example allows 2 TB per month, spread out rather than blown through on the first day:
AccountingMax 2 TBytes
AccountingStart month 1 0:00When it hits the cap, the relay hibernates until the next period instead of running up your bill. Set AccountingMax comfortably under your plan's transfer limit and you can run a relay confidently on a metered box. A relay that donates 1–2 TB a month is a genuinely useful contribution; you don't need to donate unlimited bandwidth to matter.
AccountingMax to roughly 90% of it and remember Tor counts both directions. Leaving headroom means a busy month never turns into a surprise charge or a suspended server.Keep it healthy
A relay is close to set-and-forget, but not entirely. Keep Tor updated — relays running old versions can be flagged or dropped by the network, and you're patching a service that's exposed by design. Automatic security updates handle this for you. Beyond that, glance at your relay on the public metrics site now and then to confirm it's still listed and carrying traffic, and you're done. It's one of the lowest-effort ways to give back to a piece of privacy infrastructure that a lot of people quietly rely on.