{"id":6170,"date":"2026-09-05T09:57:59","date_gmt":"2026-09-05T00:57:59","guid":{"rendered":"https:\/\/eternalsphere.net\/echoes\/?p=6170"},"modified":"2026-09-12T14:03:11","modified_gmt":"2026-09-12T05:03:11","slug":"5o90aaq9uggmc8r","status":"publish","type":"post","link":"https:\/\/blog.eternalsphere.net\/index.php\/2026\/09\/05\/5o90aaq9uggmc8r\/","title":{"rendered":"A New Tor Relay\u2019s First Hours: From Startup to Consensus"},"content":{"rendered":"\n

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.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

1. Starting the Relay<\/h2>\n\n\n\n

Consider a fictional non-exit relay configured with values such as:<\/p>\n\n\n\n

Nickname AtlasRelay\nORPort 9443\nSocksPort 0\nExitRelay 0<\/code><\/pre>\n\n\n\n
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.<\/p>\n\n\n\n
For a public relay, this is only the beginning.<\/p>\n\n\n\n
2. Discovering the Public Address<\/h2>\n\n\n\n
A relay must advertise an address that other Tor nodes can reach.<\/p>\n\n\n\n
In a NAT environment, the internal server might use a private address such as:<\/p>\n\n\n\n
192.0.2.20<\/code><\/pre>\n\n\n\n
while the public router exposes a fictional address such as:<\/p>\n\n\n\n
203.0.113.42<\/code><\/pre>\n\n\n\n
The router forwards the selected TCP ORPort to the relay server.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
3. ORPort Reachability Testing<\/h2>\n\n\n\n
A public relay is useful only if other Tor systems can connect to its ORPort.<\/p>\n\n\n\n
After startup, Tor performs reachability testing. A successful result resembles the conceptual sequence:<\/p>\n\n\n\n
ORPort opened\n    \u2193\nExternal address discovered\n    \u2193\nReachability test initiated\n    \u2193\nExternal connection succeeds\n    \u2193\nORPort declared reachable<\/code><\/pre>\n\n\n\n
Passing this test is one of the most important milestones in a new relay’s lifecycle.<\/p>\n\n\n\n
A locally listening TCP port is not enough. The port must also be reachable across the public Internet through any firewall and NAT layers.<\/p>\n\n\n\n
4. Publishing the Server Descriptor<\/h2>\n\n\n\n
Once the relay has enough information about itself, it creates a signed server descriptor.<\/p>\n\n\n\n
A descriptor contains public relay metadata such as:<\/p>\n\n\n\n
    \n
  • relay identity<\/li>\n\n\n\n
  • public OR address<\/li>\n\n\n\n
  • ORPort<\/li>\n\n\n\n
  • Tor version<\/li>\n\n\n\n
  • supported protocols<\/li>\n\n\n\n
  • exit policy<\/li>\n\n\n\n
  • advertised bandwidth information<\/li>\n\n\n\n
  • optional nickname<\/li>\n\n\n\n
  • optional contact information<\/li>\n<\/ul>\n\n\n\n
    The descriptor is cryptographically signed with the relay’s identity keys.<\/p>\n\n\n\n
    It is then uploaded into the Tor directory infrastructure.<\/p>\n\n\n\n
    No manual registration form or approval button is involved.<\/p>\n\n\n\n
    5. Why the Relay May Still Be Missing from the Consensus<\/h2>\n\n\n\n
    A common early observation is:<\/p>\n\n\n\n
    Consensus: NOT FOUND<\/code><\/pre>\n\n\n\n
    even though:<\/p>\n\n\n\n
    ORPort reachable\nDescriptor published\nTor fully bootstrapped\nPeer connections increasing<\/code><\/pre>\n\n\n\n
    This is normal.<\/p>\n\n\n\n
    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.<\/p>\n\n\n\n
    The result is a temporary state in which the relay exists operationally but has not yet been incorporated into the current consensus.<\/p>\n\n\n\n
    6. Network Connections Can Begin Before Consensus Inclusion<\/h2>\n\n\n\n
    A particularly interesting feature of the startup phase is that relay-to-relay communication can already become substantial.<\/p>\n\n\n\n
    A new relay may establish hundreds of encrypted OR connections while its own identity is still absent from the current consensus.<\/p>\n\n\n\n
    This does not mean normal client path selection is already using it heavily.<\/p>\n\n\n\n
    Instead, several types of directory, measurement, maintenance, and relay-level activity can occur before the relay receives meaningful path-selection weight.<\/p>\n\n\n\n
    This distinction is important:<\/p>\n\n\n\n
    Connected to the Tor network\n\u2260\nFully weighted for normal Tor circuits<\/code><\/pre>\n\n\n\n
    7. First Appearance in the Consensus<\/h2>\n\n\n\n
    Eventually the relay reaches the next major milestone:<\/p>\n\n\n\n
    Consensus: PRESENT<\/code><\/pre>\n\n\n\n
    A typical new relay may initially receive flags such as:<\/p>\n\n\n\n
    Running\nValid\nV2Dir<\/code><\/pre>\n\n\n\n
    These flags indicate that the relay is reachable, accepted as a valid participant, and capable of participating in directory-cache functions.<\/p>\n\n\n\n
    This is effectively the relay’s first formal appearance in the Tor network’s shared directory view.<\/p>\n\n\n\n
    8. First Seen<\/h2>\n\n\n\n
    Public Tor monitoring services record a field commonly called:<\/p>\n\n\n\n
    First Seen<\/code><\/pre>\n\n\n\n
    This is not the exact moment when the operating system started Tor.<\/p>\n\n\n\n
    It represents the first network-status consensus in which the relay identity appeared.<\/p>\n\n\n\n
    For example:<\/p>\n\n\n\n
    Tor started:        23:48\nFirst consensus:    00:00<\/code><\/pre>\n\n\n\n
    A small difference between the two timestamps is completely normal.<\/p>\n\n\n\n
    9. Public Monitoring Arrives Later<\/h2>\n\n\n\n
    Services such as Onionoo and Relay Search do not display the relay’s local state second by second.<\/p>\n\n\n\n
    The information passes through several layers:<\/p>\n\n\n\n
    Relay\n  \u2193\nDirectory infrastructure\n  \u2193\nConsensus\n  \u2193\nOnionoo processing\n  \u2193\nRelay Search<\/code><\/pre>\n\n\n\n
    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.<\/p>\n\n\n\n
    10. The First Few Hours Should Be Boring<\/h2>\n\n\n\n
    A healthy new relay usually requires very little intervention.<\/p>\n\n\n\n
    The most useful early indicators are:<\/p>\n\n\n\n
    ORPort reachable\nDescriptor successfully published\nConsensus eventually present\nNo repeated warnings or errors\nCPU and memory stable\nFile descriptors far below limits\nConnections increasing normally<\/code><\/pre>\n\n\n\n
    Repeatedly restarting the relay in an attempt to accelerate directory propagation is counterproductive. It does not force faster inclusion and unnecessarily interrupts established connections.<\/p>\n\n\n\n
    Conclusion<\/h2>\n\n\n\n
    A new Tor relay joins the network through a gradual, fully automated process:<\/p>\n\n\n\n
    Start Tor\n   \u2193\nBootstrap\n   \u2193\nDiscover public address\n   \u2193\nVerify ORPort reachability\n   \u2193\nPublish descriptor\n   \u2193\nDirectory Authorities observe it\n   \u2193\nEnter consensus\n   \u2193\nBegin accumulating measurements and history<\/code><\/pre>\n\n\n\n
    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.<\/p>\n","protected":false},"excerpt":{"rendered":"
    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 …<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[120],"tags":[245],"class_list":["post-6170","post","type-post","status-publish","format-standard","hentry","category-1s3b6h7r2zay02x","tag-tor"],"_links":{"self":[{"href":"https:\/\/blog.eternalsphere.net\/index.php\/wp-json\/wp\/v2\/posts\/6170","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.eternalsphere.net\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.eternalsphere.net\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.eternalsphere.net\/index.php\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.eternalsphere.net\/index.php\/wp-json\/wp\/v2\/comments?post=6170"}],"version-history":[{"count":1,"href":"https:\/\/blog.eternalsphere.net\/index.php\/wp-json\/wp\/v2\/posts\/6170\/revisions"}],"predecessor-version":[{"id":6171,"href":"https:\/\/blog.eternalsphere.net\/index.php\/wp-json\/wp\/v2\/posts\/6170\/revisions\/6171"}],"wp:attachment":[{"href":"https:\/\/blog.eternalsphere.net\/index.php\/wp-json\/wp\/v2\/media?parent=6170"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.eternalsphere.net\/index.php\/wp-json\/wp\/v2\/categories?post=6170"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.eternalsphere.net\/index.php\/wp-json\/wp\/v2\/tags?post=6170"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}