SSD Nodes Learn Hosting plans →
How to do am Matt ConnorBy Matt Connor · Updated 2026-08-29

How to Run Tor Relay for VPS Without Excess Traffic

Set up a Tor guard or middle relay with torrc, bandwidth limits for metered VPS plans, nyx monitoring, and why the consensus ramp dey slow.

Wetin Tor relay for VPS dey do

Tor relay na Tor daemon wey dey run for machine wey get public IP address, and e dey forward encrypted traffic for other people. Directory authorities dey publish am, and Tor clients dey build circuits through am. Guard or middle relay dey only pass traffic go another relay, so e no dey open connection to website on behalf of stranger. Na this fact make e no dey attract abuse mail, and na why e fit ordinary VPS well. Relay dey carry other people traffic and e no dey publish anything of its own. So, if wetin you want na to put your own site for the network instead of moving packets for am, running v3 onion service behind nginx na different work wey use the same tor daemon. Running relay no dey protect the privacy of your own browsing too. That one na separate problem, and the limit dey lower than many people expect: wetin self-hosting SearXNG really dey hide fit show how far moving service go your own VPS fit take you.

The work small: one package, fifteen lines of config, one firewall rule, and one restart. The rest of this guide na where things dey go wrong. E cover bandwidth calculation for metered plan, and why a new relay wey dey work well fit look dead for one week.

Guard, middle, bridge or exit: pick one before you install

One daemon dey run all four roles. Na your config, plus the directory authorities, go decide which one you be.

  • Middle relay. E dey receive traffic from guard and pass am go another relay. E no ever contact destination site. Every new relay dey start from here.
  • Guard relay. Na the same configuration, with one flag on top. Directory authorities dey give relays Guard flag after dem don dey fast and stable for long enough. You no fit choose am. You must earn am, and na the config below go help you earn am.
  • Bridge. Na relay wey dem deliberately keep out of public directory and hand out privately to users for places where Tor dey blocked. Na the smallest commitment among the four: low bandwidth, no public listing, and the correct first step if your plan small. E also need an obfs4 proxy wey dey run alongside the daemon and another set of torrc lines. how to set up an obfs4 bridge on one cheap VPS explain the process, including how dem go give users the bridge line at the end.
  • Exit relay. Na the last hop, wey dey open connection to destination site. Every request user make dey leave from your IP address, so abuse reports and police inquiries go reach whoever own that address.

Exit na the only role wey no belong for general-purpose VPS. Run exit only for provider wey don agree beforehand to receive that mail, with its own IP address and a published abuse contact. Most standard hosting terms dey forbid am, and the usual result if you ignore that na suspended server and lost IP address. If na this work you still want do, what running an exit relay really involves cover how to find exit-friendly host, write exit policy and reverse DNS, and answer the mail when e arrive. Guard or middle relay dey carry the same user traffic without all that exposure.

Everything below dey build guard/middle relay. ExitRelay 0 na the line wey keep am as one.

Wetin VPS need before you start

The Tor Project publish hard requirements for relays. As of August 2026, dem be: one public IPv4 address for the relay, at least 10 Mbit/s bandwidth for each direction with 16 Mbit/s recommended, at least 100 GB outbound traffic every month, and 512 MB RAM below 40 Mbit/s or 1 GB above am. No fixed uptime rule dey, but relay wey dey run less than two hours every day no get much use for the network.

The 10 Mbit/s figure describe the line, no be the setting. You need port wey fit handle am. How much of that line you allow the relay to use na separate decision, based on the monthly transfer allowance. Read your plan before you touch the config. If you still dey choose a box, how much VPS really cost every month explain how dem dey sell transfer allowances, and how to measure the real network throughput of VPS show how to find out wetin the line fit do with iperf3 instead of trusting the sales page.

Harden the machine first. Relay na public service for public address, and scanners fit scan the address within minutes after dem publish am. How to lock SSH down to keys and hardened sshd config fit take ten minutes, and e suppose happen before the relay go live, no be after.

Install Tor from Tor Project repository

Use Tor Project own apt repository instead of the distribution package. Relay code dey move faster than stable release, so fixes dey reach this repository first, while distribution package dey lag between releases.

sudo apt update
sudo apt install -y apt-transport-https gnupg wget

Add the signing key first, then add the repository. The machine go read the codename, so this same block go work for Ubuntu 24.04 (noble) and Debian 13 (trixie).

wget -qO- https://deb.torproject.org/torproject.org/A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89.asc \
  | gpg --dearmor \
  | sudo tee /usr/share/keyrings/deb.torproject.org-keyring.gpg >/dev/null

CODENAME=$(. /etc/os-release && echo "$VERSION_CODENAME")
echo "$CODENAME"

sudo tee /etc/apt/sources.list.d/tor.sources >/dev/null <<EOF
Types: deb deb-src
URIs: https://deb.torproject.org/torproject.org/
Suites: $CODENAME
Components: main
Signed-By: /usr/share/keyrings/deb.torproject.org-keyring.gpg
EOF

sudo apt update
sudo apt install -y tor deb.torproject.org-keyring
tor --version

tor --version go print the version wey you just install. If apt update print NO_PUBKEY error instead, the dearmored key no dey for the path wey Signed-By: line name, so apt no get key to use check the release file. deb.torproject.org-keyring package important later: e ship the signing key as normal package, so apt go continue to work when dem rotate the key.

Turn on automatic upgrades, then tell dem about the new origin.

sudo apt install -y unattended-upgrades apt-listchanges

For Ubuntu, add Tor origin to the Allowed-Origins block inside /etc/apt/apt.conf.d/50unattended-upgrades:

Unattended-Upgrade::Allowed-Origins {
        "${distro_id}:${distro_codename}-security";
        "TorProject:${distro_codename}";
};

For Debian, the same file dey use Origins-Pattern, and the line to add na "origin=TorProject";. Check the result with sudo unattended-upgrade --debug --dry-run. E go print the origins wey e go act on, and e no go write anything.

The torrc wey matter

The package go install one long, heavily commented /etc/tor/torrc. Na only few lines matter for relay. Add dem for the end of the file.

Nickname mynicerelay
ContactInfo relay-ops[at]example.com
ORPort 9001
ExitRelay 0
SocksPort 0

Nickname na 1 to 19 characters, and na letters and digits only. E no unique across the network, and e no be your identity; the fingerprint na your identity. Na this name you go use find your own relay for search box, so choose one wey you fit spell for phone.

ContactInfo dey published inside relay descriptor. Relay descriptor na public document wey anybody fit download, so people go scrape the address. Use address wey you go still read after two years, and obfuscate am if you like. Na this one be the only channel wey Tor Project get to warn you about problem with your relay.

ORPort 9001 na the port wey other relays and clients go connect to. 9001 na the usual choice. Port 443 na another common choice, because some restrictive networks dey allow only outbound 443. So relay wey dey listen there fit reach more clients. Choose 443 only if nothing else for the box need am.

SocksPort 0 dey switch off local SOCKS proxy. Relay no dey use am, and this one remove one listening socket from the machine. ExitRelay 0 dey write the intention inside the file: this relay no go ever connect to destination on behalf of user, and anybody wey read the config later no need guess this from the default setting.

If the VPS get IPv6 address, add another ORPort line. Tor no fit bind to "any" IPv6 address the same way e dey do for IPv4, so write the address inside square brackets.

ORPort 9001
ORPort [2001:db8::1]:9001

For 1 GB VPS, add MaxMemInQueues 512 MB. Tor dey decide queue limit from the memory wey e see for the machine. For small shared box, this memory fit pass wetin you want Tor to use. If you set the limit yourself, tor go discard queued cells when pressure dey. Relay go survive this, instead of queue growing until kernel kill the process.

Open the ORPort for firewall

Inbound, ORPort must dey reachable from anywhere for internet. Outbound, leave the relay without restriction: e dey open connections to thousands of other relays for plenty different ports, and outbound allowlist go quietly cripple am.

sudo ufw allow 9001/tcp comment 'tor ORPort'
sudo ufw status verbose

Then check the provider own network firewall. Plenty control panels dey run packet filter in front of the virtual machine, and rule wey you add with ufw no get effect there. Because of this, the port fit show as open for the machine but closed from outside. If ufw new to you, the ufw rules wey belong for every VPS go explain the default policy and the order wey rules dey match.

Set bandwidth to match your plan

The manual describe RelayBandwidthRate as separate token bucket wey dey limit “the average incoming bandwidth usage for relayed traffic on this node to the specified number of bytes per second, and the average outgoing bandwidth usage to that same value”. Read am twice. The limit apply to each direction separately. Relay wey set to 1 Mbit/s fit move 1 Mbit/s in and 1 Mbit/s out at the same time, and provider wey dey meter both directions go bill the total.

ChartMonthly traffic at a sustained relay rate, both directions, 30 days
The data behind this chart
[
  {
    "label": "1 Mbit/s",
    "torrc_rate": "125 KBytes",
    "gb_per_day": 21.6,
    "gb_per_month": "648"
  },
  {
    "label": "2 Mbit/s",
    "torrc_rate": "250 KBytes",
    "gb_per_day": 43.2,
    "gb_per_month": "1,296"
  },
  {
    "label": "5 Mbit/s",
    "torrc_rate": "625 KBytes",
    "gb_per_day": 108,
    "gb_per_month": "3,240"
  },
  {
    "label": "10 Mbit/s",
    "torrc_rate": "1250 KBytes",
    "gb_per_day": 216,
    "gb_per_month": "6,480"
  },
  {
    "label": "20 Mbit/s",
    "torrc_rate": "2500 KBytes",
    "gb_per_day": 432,
    "gb_per_month": "12,960"
  }
]

Those 5 rows na arithmetic, no be measurement: dem show wetin rate go cost if relay maintain am for full 30 days for both directions. Real relay dey below its cap most times, especially for the first weeks. Use the table to remove settings wey no fit enter your budget, no be to predict invoice down to the gigabyte.

For 1 Mbit/s each way, relay dey move about 21.6 GB every day, so 30 day month go cost roughly 648 GB of metered traffic. E fit inside 1 TB allowance, with space remain for updates and backups. If you increase am to 2 Mbit/s, the month go cost 1,296 GB, wey don already pass 1 TB plan. The last row, 20 Mbit/s, need 12,960 GB every month and e suppose dey on unmetered port. If your provider dey bill outbound traffic only, divide every figure by two. Find out which one apply to you before you set the rate, because the two answers differ by factor of two.

Now the config. Set rate limit first, quota second.

RelayBandwidthRate 125 KBytes
RelayBandwidthBurst 250 KBytes
AccountingMax 400 GBytes
AccountingRule sum
AccountingStart month 1 00:00

RelayBandwidthBurst na the size of token bucket, so e allow short spikes above the rate while the average still hold. About twice the rate na reasonable value.

AccountingRule na the line wey many operators dey miss. The default na max, wey dey measure the larger direction against the quota. With the default, AccountingMax 400 GBytes allow 400 GB in and 400 GB out, wey be 800 GB for meter wey dey count both directions. AccountingRule sum count read plus write against the one quota, and na this transfer allowance really dey measure.

Write AccountingStart too; never write AccountingMax alone. The quota na the number, while the start line na the period wey e dey reset on. Quota wey no get period go leave the relay hibernating, with nothing to wake am up.

Hibernation na blunt tool. When quota finish, tor go log am and stop to accept work:

Bandwidth soft limit reached; commencing hibernation. No new connections will be accepted

The relay no go wake exactly when the next period start either. Tor dey track how fast e used the last quota and pick random time inside the new interval, so thousands of relays no go return to the network for the same second. Relay wey dey disappear for the last week of every month go continue to lose the stability wey directory authorities dey measure. Set RelayBandwidthRate so the cap never reach, and keep AccountingMax as the backstop wey dey protect the invoice.

Start and confirm say the relay dey reachable

sudo systemctl restart tor@default
sudo systemctl status tor@default
sudo journalctl -u tor@default -n 50

Within few minutes, the log suppose get this line:

Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor.

This sentence mean say other relays connect back to your ORPort and build circuit through am. Until e show, your relay no dey inside the directory and e no carry any traffic. The error message go look like this:

Your server has not managed to confirm reachability for its ORPort(s) at 203.0.113.10:9001. Relays do not publish descriptors until their ORPort and DirPort are reachable. Please check your firewalls, ports, address, /etc/hosts file, etc.

Check each one in order. ORPort dey open for ufw? E dey open too for the provider separate network firewall? The address for that message na the address wey internet actually route go you, or na private address from NAT setup? Test the port from another machine with nc -vz 203.0.113.10 9001. Tor dey repeat the self test by itself, so once you fix the firewall, e go notice am without your help. Restart go make the test happen immediately.

Your relay permanent identity na the fingerprint:

sudo cat /var/lib/tor/fingerprint

About three hours after dem publish the descriptor, the relay go show for Relay Search. Search the nickname or paste the fingerprint. That page show wetin the network think about your relay: the flags wey e get, the weight wey the authorities give am, and the version wey e dey publish.

Why new Tor relay dey carry almost no traffic?

Because the network never measure am yet, and measurement fit take weeks. Tor Project describe this ramp-up for four phases. Operator wey never read am fit conclude say relay spoil and start dey change things.

For the first three days, dem never measure the relay. E report the result of im own self test, and directory authorities still limit the published weight to 20 KB, so clients almost never pick am. From around day three reach day eight, bandwidth authorities measure am properly and the weight dey rise. But dem use am only as middle hop, because no client ready make brand new relay im first hop.

Around day eight, the relay become eligible for the Guard flag. Getting the flag make traffic drop, and this one dey surprise everybody. Clients skip guards when dem dey choose middle hops, because dem assume say guard already dey busy. So the relay lose middle traffic before e gain guard traffic. E go refill only as clients rotate their guard sets, and this fit take weeks. By around day 68, e reach steady state, where clients wey dey remove am balance clients wey dey add am.

So the honest expectation be say nothing go happen for three days, something go happen after one week, and real load go come after two months. Change one setting, then wait one week to see wetin e do. Self-hosted Uptime Kuma status page with a TCP check against port 9001 na better way to use that nervous energy. E answer the question wey you fit actually control: whether the port still dey answer.

Monitor the relay with nyx

nyx na terminal monitor for relay wey dey run. E dey talk to tor control port, so first enable am for torrc:

ControlPort 9051
CookieAuthentication 1
CookieAuthFileGroupReadable 1

ControlPort dey listen only for 127.0.0.1, and cookie authentication mean say program must read secret file before e fit issue commands. Tor dey write that cookie go /run/tor/control.authcookie as user debian-tor, with mode 600, so nobody else fit read am. CookieAuthFileGroupReadable 1 open am to the group, na wetin allow your own account run nyx without sudo.

sudo apt install -y nyx
sudo adduser "$USER" debian-tor
sudo systemctl restart tor@default

Log out and log in again, then run nyx. New group membership must take effect when you log in, so if you run nyx for the same shell session, e go show permission error for cookie file even though config correct. nyx dey show live bandwidth, uptime, log stream, and connection list. For the first weeks, na bandwidth graph wey stay below your RelayBandwidthRate you suppose monitor.

Run more than one relay: MyFamily and family keys

If na only one relay you get, skip this section. If the same operator dey run two or more relays, dem must declare each other. This stop clients from building a circuit wey enter and comot through your machines. Otherwise, one operator fit see both ends of the circuit.

The old method na to put MyFamily inside every relay's torrc. The setting must list the fingerprints of all the other relays:

MyFamily AAAAAAAAAA,BBBBBBBB

Every relay lists every other relay. So, if you add a fourth relay, you must edit four files. Tor 0.4.9 replace this method with a family key. Generate one key, then share am:

tor --keygen-family myfamily

This command writes myfamily.secret_family_key and prints one FamilyId line. Copy the key file to every relay, inside the keys subdirectory of the DataDirectory (/var/lib/tor/keys for Debian and Ubuntu). Keep the .secret_family_key suffix. Add the printed FamilyId line to each torrc, then reload with sudo systemctl reload tor@default. For now, keep the MyFamily list too. Clients wey no understand family certificates yet still read the old list. Tor Project go announce when you fit remove am.

Wetin dey spoil after e don dey run

The version dey stale. Unattended upgrades go replace the package, but the process wey dey run go continue use the binary wey e start with until something restart am. Compare tor --version for the box with the version wey dey show for the relay's Relay Search page. If dem no match, network still dey see the old one, so restart the service.

The clock dey drift. Consensus documents and certificates all get time limit, so machine wey clock don far out go reject the consensus and stop publishing. timedatectl suppose report say system clock don synchronize. If e no do so, enable systemd-timesyncd or install chrony.

The IP address dey change. Descriptor carry the address, and clients no fit reach address wey don move. After any provider migration or address change, restart tor and monitor for the self-test line again.

The relay slow pass wetin the plan allow. Tor relay crypto efficient for modern processors, and Tor Project estimate say CPU wey support AES-NI fit reach about 400 to 450 Mbit/s for each direction. Long before you reach that limit, port speed and transfer allowance go limit you. Na why the accounting section above matter pass the hardware.

FAQ

How much bandwidth Tor relay dey use?

Na as much as you allow am, and nothing pass that. RelayBandwidthRate dey cap relayed traffic for each direction separately, so relay wey you set to 1 Mbit/s fit carry 1 Mbit/s enter and 1 Mbit/s comot at the same time. This na about 21.6 GB every day, or 648 GB for 30 day month, when you count both directions. Add AccountingMax with AccountingRule sum as hard monthly quota under that rate.

Running Tor relay go bring abuse complaints for me?

Guard or middle relay dey pass traffic only go other Tor relays, and e never connect to website for user. So complaints about wetin person do through Tor go reach exit operator, no be you. Wetin you fit see na scanning and sometimes IP reputation listing, because dem list the address publicly as relay. Na exit relays dey receive abuse mail and legal notices, and dem need provider wey agree ahead of time to handle am. Read your provider's terms before you start either type.

Why my new Tor relay no dey receive traffic?

Because new relays get throttling by design until dem measure dem. For the first three days, directory authorities dey cap the published weight at 20 KB, so clients almost never choose the relay. Bandwidth authorities dey measure am from about day three. E become eligible for Guard flag around day eight. Traffic go reduce again at that time because clients dey avoid guards when dem dey choose middle hops. Full load go arrive around day 68. Confirm say the log show "Self-testing indicates your ORPort is reachable from the outside", then leave am alone.

I fit run Tor relay for VPS with 1 TB transfer allowance?

Yes, at about 1 Mbit/s for each direction, and this na RelayBandwidthRate 125 KBytes. That one na roughly 648 GB every month if your provider dey measure both directions, with extra capacity for updates and backups. Add AccountingMax 400 GBytes with AccountingRule sum and AccountingStart month 1 00:00 so the relay go hibernate instead of passing the plan limit. If provider dey bill outbound traffic only, you fit double the rate.

I need set MyFamily if I run only one relay?

No. Family declarations dey help clients avoid building circuit through two relays wey the same operator own, and this no get meaning with one relay. Set am as soon as you add second relay: list every relay's fingerprint inside every relay's MyFamily line, or use the family key wey Tor 0.4.9 introduce, wey dey distribute one FamilyId instead of list wey dey grow forever.