Privacy and Exposure When Running a Public Tor Relay

Operating a public Tor relay improves the diversity and capacity of the Tor network, but it also creates a deliberate public presence on the Internet.

The objective of good relay privacy is therefore not to make the relay invisible. That would be incompatible with being a public relay.

The realistic objective is:

Publish everything the Tor network needs, and nothing unnecessary about the operator.

1. Information That Must Be Public

A public relay necessarily exposes several pieces of information.

These include:

public OR address
ORPort
relay fingerprint
relay flags
exit policy
bandwidth-related information
consensus weight
software compatibility information
first-seen and last-seen history

Without these values, Tor clients could not safely discover and select relays.

2. The Public IP Cannot Be Hidden

Other Tor relays must know where to establish OR connections.

Therefore:

Public Relay
     ↓
Public IP
     ↓
Public ORPort

is fundamental to the design.

If hiding the server’s address is a strict requirement, a public relay is the wrong Tor role.

Bridges serve a different purpose and are intentionally less publicly discoverable.

3. Relay Fingerprint

Every relay has a long-term cryptographic identity fingerprint.

A fictional example:

91F84B0D...

This is the true persistent identity of the relay.

Changing:

nickname
IP address
ORPort
contact information

does not create a new relay as long as the identity keys remain unchanged.

This persistence is essential for building stability history and trust.

4. Nicknames Should Be Treated as Public Pseudonyms

Relay nicknames are public and searchable.

A poor configuration would reuse an internal infrastructure hostname:

Nickname production-storage-03

This unnecessarily reveals part of a private naming scheme.

A better approach is to use a dedicated public pseudonym:

Nickname IronHarbor

The pseudonym should not contain:

real name
city
employer
ISP name
personal username
internal hostname
other unique infrastructure identifiers

5. ContactInfo Is Also Public

ContactInfo is useful because it gives the Tor community a way to reach a relay operator.

But it should be considered fully public.

A risky example is:

relay@personal-domain.example

if that domain is also used for personal websites, email, or other infrastructure.

This creates a direct correlation:

Relay fingerprint
      ↓
personal domain
      ↓
other public services
      ↓
operator identity

A cleaner design uses a dedicated address on an unrelated mail provider:

relay-alias@example-mail.invalid

The mailbox should ideally exist only for relay administration.

6. GeoIP Information Is Unavoidable

Public monitoring systems can infer approximate location from the relay’s public IP.

This may expose:

country
region
city approximation
latitude/longitude approximation

These values come from GeoIP databases rather than relay configuration.

They should not be confused with precise GPS location.

7. ASN Information Is Also Publicly Inferable

The public IP belongs to an Autonomous System.

Public data can therefore reveal:

ASN
AS organization name

This may identify:

an ISP
hosting provider
university
company
network operator

This information cannot realistically be hidden while continuing to use that network address as a public relay.

8. Reverse DNS Deserves Attention

A public IP may have a PTR record.

For example:

203.0.113.42
    ↓ PTR
customer-42.isp.example

A generic ISP PTR is usually harmless.

A custom PTR such as:

personal-server.example.org

creates a much stronger identity link.

Relay operators should therefore inspect reverse DNS when performing a privacy audit.

9. Software Information

Public relay information may reveal broad platform data such as:

Tor 0.x.x on Linux

This does not normally reveal:

exact Linux distribution
CPU model
RAM size
hypervisor
local username
storage layout
LAN address
SSH configuration

Attempting to obscure standard Tor compatibility information is generally unnecessary and can make operation less standard.

10. Bandwidth Is Public but Limited in What It Reveals

Relay Search may expose:

bandwidth rate
bandwidth burst
observed bandwidth
advertised bandwidth
consensus weight

This can reveal roughly how much capacity is allocated to Tor.

It does not necessarily reveal the physical connection’s full speed.

A relay capped at:

30 Mbit/s

could be operating behind a much faster Internet connection.

11. Running History Is Public

Tor metrics can record:

First Seen
Last Seen
Last Restarted
historical bandwidth

This allows outside observers to determine roughly when a relay entered the network and when it has been available.

Long-term 24/7 operation generally reveals less behavioral information than a highly regular personal on/off schedule.

12. Relay Family Relationships Are Public by Design

Operators of multiple relays should correctly declare their family relationships.

This tells Tor:

These relays are controlled by the same operator and should not be treated as independent for path diversity.

Hiding such a relationship for privacy reasons would weaken Tor’s security model.

Correct family declaration is therefore more important than concealing the operational link.

13. Cross-Service Correlation Is Often the Largest Remaining Risk

Tor’s own directory metadata may be carefully minimized, while the same public IP exposes unrelated services:

TCP 9443 → Tor
TCP 443  → personal website
TCP 22   → SSH
TCP 8443 → administration panel

An external observer can scan the public IP and correlate:

TLS certificates
domain names
HTTP titles
service banners
reverse DNS
application-specific identifiers

This can reveal much more than the Tor Relay Search page itself.

Separating relay infrastructure from personally identifiable services is therefore one of the strongest privacy improvements available.

14. Public Relay Status Can Affect IP Reputation

A public relay IP appears in openly available Tor relay lists.

Some anti-abuse systems classify such addresses broadly as:

Tor-related

even when the relay is non-exit.

This can occasionally affect:

account registration
CAPTCHA frequency
fraud detection
rate limits
website access

A non-exit relay does not forward Tor users’ ordinary Internet traffic to external websites, so it does not have the same reputation risk as an Exit. Nevertheless, poorly differentiated blocklists can still create side effects.

15. Changing Public Metadata Does Not Erase History

Suppose a relay initially publishes:

Nickname OldName
ContactInfo old-address@example.invalid

and later changes to:

Nickname NewAlias
ContactInfo relay-contact@example.invalid

Current Relay Search data will eventually show the new values.

However, historical descriptors and third-party archives may still contain the earlier metadata.

Therefore:

changing metadata
=
stopping future publication of old information

not:

erasing every historical copy

This is why privacy-sensitive metadata should ideally be chosen correctly before the relay is first published.

16. A Minimal-Exposure Public Relay

A well-designed public relay can reduce unnecessary operator information to approximately:

Required:
public IP
ORPort
fingerprint
Tor metadata
flags
bandwidth information
ASN / GeoIP-derived location

Optional but anonymized:
neutral nickname
dedicated relay-only contact address

Avoided:
internal hostname
personal domain
personal email
real name
private infrastructure names
identifiable PTR record
unrelated public services on the same IP

Conclusion

Perfect anonymity is not compatible with operating a publicly listed Tor relay. The relay itself must be discoverable.

The achievable privacy goal is instead separation:

Public relay identity
       │
       └── intentionally public

Personal / internal identity
       │
       └── deliberately unlinked

Once the nickname, contact information, reverse DNS, and cross-service correlations are properly controlled, the remaining exposure is largely inherent to the role of a public Tor relay rather than unnecessary personal disclosure.