All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
How to safely operate a Tor exit relay (it's easier than you think!)
This guide is mostly intended for people who already run Tor non-exit relays, but anyone can get into it. Even if it's your first time running a Tor relay, as long as you pick a provider that allows it, you can run an exit!
Firstly, what is a Tor exit? A Tor exit is the last hop on the Tor anonymity network where traffic exits to the wider internet. They have a reputation for being risky to run due to the possibility of abuse being incorrectly attributed to you. This was more true in the past when Tor was obscure, and is still true when it comes to running exits on your home residential line, but the story is very different in 2026 for running exits on a hosting provider.
Legality of running a Tor exit
The days of law enforcement constantly harassing exit operators because they don't understand or don't believe that the operator has no way to trace the offending traffic have passed. Law enforcement is more educated about Tor than ever and they know that exit operators have nothing to do with their investigation. This isn't a hard rule and may not apply in every country, but as a rule of thumb, operating an exit from an exit-friendly provider has transitioned from "dangerous and for well-informed risk-takers only" to "largely safe in most democratic countries assuming a few basic precautions are taken".
Assuming you're in the US or EU, it's always legal to run a Tor exit, but the bigger question is whether or not you are legally liable for the traffic that is passed through the exit. In the US, 17 U.S.C. § 512(a) protects the operator from copyright complaints so long as the service merely routes traffic without selecting or modifying the content, and 47 U.S.C. § 230, famously known as Section 230, provides legal immunity for entities merely hosting or transmitting others' speech. It protects ISPs and it protects you too.
In the EU, Article 4 of the DSA provides protection for any service operating as a "mere conduit" which, as with the US DMCA safe harbor laws, provides protection for services which do not select or modify the content that is passing through it. There have been seizures in the EU in the past, but this was when Tor was quite unknown to law enforcement and almost always involved extra circumstances.
It's legal in many other countries as well, but the safety has only been tested heavily in the US and EU. As usual, there are exceptions, and if you boast online about trying to facilitate illegal activity (even though your exit is primarily facilitating lawful anonymous activity), that could be used against you. If you're a blackhat hacker, running an exit may give law enforcement pretext to raid you. But if you're not being stupid and you're not hosting on your home residential network, you'd be very unlikely to have any issues. If you did, it would be newsworthy.
Handling abuse complaints
This matters more often when you're hosting a large number of high-capacity relays under your own ASN. For people who instead host with Tor exit-friendly providers on LET, abuse complaints are almost always handled by the provider. In some cases they may open a ticket, in which case all you have to do is reply that you're running a Tor exit with permission. In the rare case that the abuse complaint is addressed directly to you or is directly forwarded to you, Tor Project provides useful response templates that you can reply with.
I currently run around 10 exit relays and over 40 non-exit relays, and I can recall only three complaints I had to act on, two of which were in the form of a ticket opened by the provider essentially asking me to block a particular IP and one was a temporary suspension that was cleared up by pointing out that I'm running an exit, after which the service was promptly re-enabled and the staff thanked me for supporting the Tor network. In fact, for transparency, here are the only notices I've ever gotten for running exits: https://postimg.cc/gallery/0Q6qndS
You can also reduce the rate of complaints by setting your rDNS to a name that makes it clear that you're running an exit, and by creating a simple page on that rDNS that explains what an exit is (see the template), you can make your life a little easier. This isn't as important as it used to be, now that Tor is more popular and many IP databases will explicitly flag an IP as running an exit. AbuseIPDB, for example, says "This address is a Tor exit node. Neither the owner nor the provider are directly behind the offending action.".
Finding an exit-friendly provider
There are a number of providers on LET which allow Tor exit relays. Some allow them on all of their services, others only allow them on specific services. Some ask that you open a ticket with them to tell them that you'll be running an exit, others just let you do it without telling them. In some cases, they'll make exceptions for you.
If you aren't sure if a provider allows exits, you can ask them. But be aware that the support staff might not fully understand and will blindly give approval as soon as you mention that it's legal. So make sure you tell any prospective provider that allowing you to run a Tor exit will:
- Operate similarly to a public VPN or open proxy
- Reduce IP reputation, putting the IP of the VPS on blacklists very quickly
- Bring in abuse complaints and copyright notices
- Use substantial bandwidth and engage in activity that is often falsely-flagged as port-scanning
It may also be helpful to give them an example exit IP on AbuseIPDB. If they still say it's permitted after seeing the 100% risk score, you're good to go! Just make sure they know what they're getting into.
You'll generally want to avoid locations that are already over-represented on the Tor network. Because of this, it's a good idea not to set up an exit in the Netherlands or Germany.
Here are a few providers that I use for exits, all of which accept cryptocurrency payments:
- iHostArt (https://ihostart.com) - Romanian host. A bit pricey and uptime isn't ideal, but very lenient. Accepts payments in the form of Bitcoin, fruits, and vegetables.
- Maxko Hosting by @MAXKO_Hosting (https://maxko-hosting.com) - A host with locations in some obscure locations including Serbia and South Africa. Allows exits on all their locations and is actively pro-privacy. Use promo code "TOR10" for 10% off any service intended as a relay (exit or non-exit). You have to ask them to enable host CPU passthrough in a ticket, otherwise you won't have AES-NI and performance will suffer.
- Aluy by @aluy (https://aluy.net) - Pro-privacy host with a few nice locations including Bulgaria, Finland, and even Hong Kong. The owner is very friendly and active on LET.
- Advin Servers by @advinservers (https://advinservers.com): American. A bit pricey, but they're premium. Very fast CPUs. Requires written approval for exits.
- Trabia by @trabia (https://www.trabia.com) - Moldovan host. Exits are allowed but mail-related ports should be blocked. They'll notify you if they are getting too many complaints and may request that you change your exit policy. If I recall, they want you to use a reduced exit policy (described later).
- Pfcloud UG (https://pfcloud.io) - Slovenian host. Occasionally suspends for abuse, but all you have to do is tell them that you're running an exit relay and they'll unsuspend you.
- IncogNET by @MannDude (https://incognet.io) - Radically pro-privacy host with servers in Sweden. Exits are allowed, but you have to follow their specific exit policy to reduce abuse complaints.
- No Ack Hosting (https://noackhosting.se) - Has a dedicated subnet for exits in Sweden. Does not enable host CPU passthrough (boo!). You have to ask them explicitly to run an exit so they assign you to the right subnet on the right node. It's pricey but reliable. They run their own DNS resolver.
With the exception of the first three (who really don't care), you should ask them for confirmation before running an exit so they know you are not some spammer or abuser, and you should ask them if there is any special configuration they require. It's also a good idea to name your server in the control panel something like "Tor exit relay", because that's the name that they'll see attached to any abuse reports they receive.
As always, read the Terms of Service and Acceptable Use Policy and remember that rules can change.
Configuring the relay
A typical minimal Tor configuration file, /etc/tor/torrc, looks like this for an exit:
SocksPort 0
ORPort 9001
ExitRelay 1
#IPv6Exit 1 # uncomment if the VPS has IPv6
Nickname MyCoolNewRelay # use whatever nickname you want
ContactInfo [email protected] # use a valid email
Sandbox 1
NoExec 1
The email contact is important. If something is broken and your relay is failing DNS (for example) or is unable to reach many sites, Tor Project developers will reach out to this email to tell you that something is wrong. If they can't reach you, their only option is to assign the "BadExit" flag to your relay which prevents it from operating as an exit. This most often happens due to DNS-related censorship or misconfiguration.
You may want to use a reduced exit policy. This creates a whitelist of allowed ports that Tor can exit from which is far more strict than the default exit policy. Using a reduced exit policy is as simple as including ReducedExitPolicy 1 in the Tor configuration file. Note that the reduce exit policy still allows SSH (which accounts for a majority of abuse), so you may also want to add ExitPolicy reject *:22. If even that isn't enough, you can whitelist the bare minimum ports that are needed by adding:
ExitPolicy accept *:80
ExitPolicy accept *:443
ExitPolicy reject *:*
Make sure the VPS has at least 1 vCPU with AES-NI (Tor is largely single-threaded) and at least 2 GB RAM, ideally more. You don't need much storage. A minimal Debian server with Tor comfortably fits on a 5 GB drive.
Configuring DNS
Unlike middle relays, exit relays make extensive use of DNS. While you could just use the default, it's a bad idea to send unencrypted, unauthenticated DNS queries to a centralized service like Google or Cloudflare. It's far better to use DNS-over-TLS, DNS-over-HTTPS, or DNSCrypt with a reputable provider. For DoT and DoH, you can use systemd-resolved. Be sure to set DNSSEC=yes if supported by your nameserver of choice.
The ideal solution is to run your own local, caching DNS resolver, such as Unbound, which is available in most distro's repos. The catch is that you need a second IPv4. You can't re-use the same one that's being used for Tor as some upstream nameservers block Tor. If you're willing to buy a second IPv4, then this is ideal. All you need to do is put nameserver 127.0.0.1 in /etc/resolv.conf and create /etc/unbound/unbound.conf with the following contents (note that the paths are correct on Debian, your distro may be different):
server:
outgoing-interface: 198.51.100.57
do-ip6: no
rrset-cache-size: 256m
msg-cache-size: 128m
neg-cache-size: 32m
cache-min-ttl: 300
prefetch: yes
prefetch-key: yes
auto-trust-anchor-file: "/var/lib/unbound/root.key"
auth-zone:
name: "."
master: f.root-servers.net
master: k.root-servers.net
master: l.root-servers.net
master: j.root-servers.net
fallback-enabled: yes
for-downstream: no
for-upstream: yes
zonefile: "/var/lib/unbound/root.zone"
In this particular example, 198.51.100.57 is your secondary IPv4 to be used for DNS. If 198.51.100.56 is the primary one used with Tor that you won't be using for DNS, you'll want to tell Tor this explicitly so it only uses it. This can be done by adding OutboundBindAddress 198.51.100.56 to the Tor configuration file. Now Tor will use 198.51.100.56 for general exit traffic and Unbound will use 198.51.100.57 for DNS.
If you don't want to buy a secondary IPv4, that's fine. Just make sure you're using some form of encrypted and authenticated DNS, ideally outside of the big providers (Google, Cloudflare, Quad9, etc.). If you absolutely have to use unencrypted, unauthenticated DNS, try to use one that's hosted by one of your servers' upstreams or peers to minimize the number of ASes that each DNS request has to pass through.
If your provider provides its own local resolver, you can use that instead. And if you trust me and happen to get an exit on the same provider network as one of mine, I'd be happy to whitelist your server's IP so it can use my resolver so you don't have to buy a second IPv4!
To everyone running a relay, exit or not, thank you for supporting online privacy!
Comments
I've ran/been running a few tor nodes now for awhile.
As a provider that allows tor services on our network.
Disabling SSH through tor stops majority of abuse notices.
Just what I've noticed
Good point! I'll add that detail to my post. It's actually surprising that the "reduced exit policy" still allows SSH.
When I run exits the most I get is emails from Indian police asking for info about someone using my tor exit for swatting emails.
ihostart Rip @Calin
What do you run an exit on? Most exit-friendly hosts handle the complaints for you.
But getting those kinds of emails is a great way to educate people!
I have been running two Tor exit nodes since February and I haven't gotten a single abuse report email, I just allow web ports tho. Tor is better suited to be used inside the own Tor network anyways.
They get forwarded as its legal request from Law enforcement.
I did receive one from Croatian police too before
Interesting! The providers I use don't seem to forward even when I ask them to.
But yes, in cases like that, a reply that is based on one of Tor Project's abuse reply templates is usually enough to get them to go away, hopefully more educated than they were before.
Most of the time it gets forwarded or they send to your tor contact email. I pretty much don’t respond. Even if I do, I hear nothing back.
Nice one @forest
Cool guide as always. I running a few middle relays, once I get comfortable with orchestrating them and they are stable enough - will try to run an exit.
Another clear and well-written guide. Nice work!