A New Tor Relay’s First Hours: From Startup to Consensus

Running a public Tor relay is not an instantaneous registration process. A relay can be online, reachable, and already communicating with other Tor nodes before it appears in the network consensus.

Understanding these first few hours helps explain why a newly deployed relay may appear active locally while public monitoring services still show little or no information.

1. Starting the Relay

Consider a fictional non-exit relay configured with values such as:

Nickname AtlasRelay
ORPort 9443
SocksPort 0
ExitRelay 0

Once Tor starts successfully, the daemon first bootstraps into the Tor network. It downloads directory information, learns about other relays, establishes encrypted connections, and determines whether it has enough information to participate normally.

For a public relay, this is only the beginning.

2. Discovering the Public Address

A relay must advertise an address that other Tor nodes can reach.

In a NAT environment, the internal server might use a private address such as:

192.0.2.20

while the public router exposes a fictional address such as:

203.0.113.42

The router forwards the selected TCP ORPort to the relay server.

Tor can often learn the external address through the directory system without requiring a manually configured public IP. This is useful on residential connections where the IPv4 address may occasionally change.

3. ORPort Reachability Testing

A public relay is useful only if other Tor systems can connect to its ORPort.

After startup, Tor performs reachability testing. A successful result resembles the conceptual sequence:

ORPort opened
    ↓
External address discovered
    ↓
Reachability test initiated
    ↓
External connection succeeds
    ↓
ORPort declared reachable

Passing this test is one of the most important milestones in a new relay’s lifecycle.

A locally listening TCP port is not enough. The port must also be reachable across the public Internet through any firewall and NAT layers.

4. Publishing the Server Descriptor

Once the relay has enough information about itself, it creates a signed server descriptor.

A descriptor contains public relay metadata such as:

• relay identity
• public OR address
• ORPort
• Tor version
• supported protocols
• exit policy
• advertised bandwidth information
• optional nickname
• optional contact information

The descriptor is cryptographically signed with the relay’s identity keys.

It is then uploaded into the Tor directory infrastructure.

No manual registration form or approval button is involved.

5. Why the Relay May Still Be Missing from the Consensus

A common early observation is:

Consensus: NOT FOUND

even though:

ORPort reachable
Descriptor published
Tor fully bootstrapped
Peer connections increasing

This is normal.

Tor’s network consensus is produced periodically by the Directory Authorities. A newly published descriptor must first propagate through the directory system and become part of the authorities’ voting process.

The result is a temporary state in which the relay exists operationally but has not yet been incorporated into the current consensus.

6. Network Connections Can Begin Before Consensus Inclusion

A particularly interesting feature of the startup phase is that relay-to-relay communication can already become substantial.

A new relay may establish hundreds of encrypted OR connections while its own identity is still absent from the current consensus.

This does not mean normal client path selection is already using it heavily.

Instead, several types of directory, measurement, maintenance, and relay-level activity can occur before the relay receives meaningful path-selection weight.

This distinction is important:

Connected to the Tor network
≠
Fully weighted for normal Tor circuits

7. First Appearance in the Consensus

Eventually the relay reaches the next major milestone:

Consensus: PRESENT

A typical new relay may initially receive flags such as:

Running
Valid
V2Dir

These flags indicate that the relay is reachable, accepted as a valid participant, and capable of participating in directory-cache functions.

This is effectively the relay’s first formal appearance in the Tor network’s shared directory view.

8. First Seen

Public Tor monitoring services record a field commonly called:

First Seen

This is not the exact moment when the operating system started Tor.

It represents the first network-status consensus in which the relay identity appeared.

For example:

Tor started:        23:48
First consensus:    00:00

A small difference between the two timestamps is completely normal.

9. Public Monitoring Arrives Later

Services such as Onionoo and Relay Search do not display the relay’s local state second by second.

The information passes through several layers:

Relay
  ↓
Directory infrastructure
  ↓
Consensus
  ↓
Onionoo processing
  ↓
Relay Search

As a result, the local Tor daemon can already know that it is present in the consensus while a public web page still shows older information.

10. The First Few Hours Should Be Boring

A healthy new relay usually requires very little intervention.

The most useful early indicators are:

ORPort reachable
Descriptor successfully published
Consensus eventually present
No repeated warnings or errors
CPU and memory stable
File descriptors far below limits
Connections increasing normally

Repeatedly restarting the relay in an attempt to accelerate directory propagation is counterproductive. It does not force faster inclusion and unnecessarily interrupts established connections.

Conclusion

A new Tor relay joins the network through a gradual, fully automated process:

Start Tor
   ↓
Bootstrap
   ↓
Discover public address
   ↓
Verify ORPort reachability
   ↓
Publish descriptor
   ↓
Directory Authorities observe it
   ↓
Enter consensus
   ↓
Begin accumulating measurements and history

The transition from a functioning server to a fully weighted Tor relay takes time. The first hours are therefore best treated as an observation period rather than a configuration-tuning exercise.