How long does it take to earn the HSDir flag after starting a relay?

After starting a relay, it becomes reachable, passes bandwidth measurement, and earns basic relay flags within hours. The HSDir flag specifically requires 96 hours of continuous uptime after the relay first achieves reachability. In practice, new relays typically see HSDir in their consensus flags after 5-7 days when accounting for the time to achieve initial reachability plus the 96-hour uptime requirement.

Does serving as an HSDir increase abuse risk for the operator?

No. HSDir relays store and serve encrypted descriptors - they cannot read the content of .onion services or identify what the services provide. HSDirs are not associated with the traffic or content of the .onion services they index. Abuse risk for HSDir relays is the same as for middle relays - low, because neither handles exit traffic.

How many .onion service descriptors does a typical HSDir store?

A busy HSDir may store thousands of active .onion service descriptors at any time - there are hundreds of thousands of active .onion addresses on the Tor network. Each descriptor is a few kilobytes, so thousands of descriptors requires tens of megabytes of memory. This is well within the capacity of any modern server.

Can I disable HSDir on my relay if I want?

You cannot directly configure a relay to not have the HSDir flag - the flag is assigned by directory authorities based on uptime criteria, not operator configuration. If you want to avoid HSDir status, you can configure your relay with a maximum uptime of less than 96 hours (by restarting it periodically), but this is counterproductive for relay utility. The HSDir flag has minimal operational impact and should be accepted as a normal part of running a stable relay.

Does HSDir role affect my relay's bandwidth measurement?

No. HSDir operations (storing and serving descriptors) consume minimal bandwidth compared to relay data forwarding. The bandwidth measurement (measured by bwauths - bandwidth authority relays) reflects the relay's data forwarding capacity, not descriptor-serving overhead. Earning the HSDir flag does not change your relay's measured bandwidth or its position in circuit selection.

HSDir Relay Configuration: Serving as a Tor Hidden Service Directory

HSDir (Hidden Service Directory) is a special flag assigned to Tor relays that store and serve hidden service descriptors to clients looking up .onion addresses. Running an HSDir relay contributes to the hidden services layer of the Tor network - without a sufficient number of reliable HSDirs, .onion service discovery becomes unreliable. This guide covers the requirements for earning the HSDir flag, the technical configuration, the performance and storage impact of serving descriptor requests, and monitoring your relay's HSDir activity.

Need this done for your project?

We implement, you ship. Async, documented, done in days.

Start a Brief

HSDir Flag Requirements

To earn the HSDir flag from the Tor directory authorities, a relay must meet: (1) minimum uptime of 96 hours continuously (the relay must have been online for at least 4 days without interruption), (2) descriptor storage capability - no specific storage requirement, but the relay must not have the Hibernation flag active, (3) standard relay requirements: valid ContactInfo, reachable ORPort, passing bandwidth measurement. The HSDir flag is assigned automatically by the directory authorities when these criteria are met - operators do not need to apply or configure anything specifically for HSDir beyond maintaining a stable, long-running relay. New relays typically earn the HSDir flag after 5-7 days of continuous operation.

What HSDir Relays Store and Serve

HSDir relays store v3 hidden service descriptors: encrypted blobs that contain the introduction points for .onion services. Each .onion service's descriptor is stored on 6 HSDirs at any given time (3 for the current time period, 3 for the next). When a Tor client wants to reach a .onion service, it queries the appropriate HSDirs for the service's descriptor. The descriptor is small (a few kilobytes) and stored in memory rather than on disk. HSDir operations add modest storage and CPU overhead: storing and serving descriptors requires memory proportional to the number of active .onion services, and serving descriptor requests requires Tor circuit operations. For a busy relay, HSDir operations represent a small fraction of total workload - typically 1-5% of CPU time and a few megabytes of memory for descriptor storage.

Monitoring HSDir Activity

Monitor your relay's HSDir operations via Tor logs: with Log notice level, descriptor upload successes and failures are logged. For more detail: Log info or Log debug shows individual fetch and store operations. Count descriptor operations: grep 'HS descriptor' /var/log/tor/notices.log | wc -l gives daily descriptor operation count. Tor Metrics (metrics.torproject.org) shows whether your relay has the HSDir flag in the consensus. After earning HSDir, check the consensus entry: download the latest consensus from Tor directory authorities and search for your relay fingerprint - the flags line should include HSDir.

HSDir and Privacy Considerations for Operators

HSDir relays receive descriptor requests from clients looking up .onion addresses. A descriptor request reveals to the HSDir: the blinded public key of the .onion service being looked up (not the .onion address directly) and the requesting Tor circuit (not the client IP). An adversary who operates many HSDirs could potentially: determine which .onion services are being queried (by observing descriptor request frequency), and attempt to correlate blinded keys across time periods to track specific services. These are known theoretical concerns about the HSDir design. For relay operators: running an HSDir is a positive contribution to the network. The theoretical adversarial concerns apply to large-scale HSDir operators trying to attack the system, not to individual honest relay operators.

Stable Uptime Strategies for HSDir Eligibility

Maintaining 96+ hours uptime for HSDir eligibility requires: (1) reliable VPS or dedicated hosting that does not experience frequent unplanned reboots, (2) automated OS updates that do not reboot without warning (configure unattended-upgrades with Automatic-Reboot-Time '02:00' to schedule any needed reboots at off-peak hours), (3) systemd unit for Tor with Restart=on-failure and RestartSec=30 to recover from crashes without extended downtime, (4) monitoring that alerts on Tor process failure: monit, systemd service watch, or simple cron-based check. For relays that need planned maintenance (OS upgrades, hardware work), schedule during Tor low-activity periods and keep maintenance windows under 4 hours to avoid losing the 96-hour continuous uptime clock. After a planned reboot, the relay loses the HSDir flag temporarily and must re-earn it after 96 hours of continuous uptime.

Related Services

Offshore VPS from $17.90/mo Dedicated Servers DevOps Services

Why Anubiz Host

100% async — no calls, no meetings

Delivered in days, not weeks

Full documentation included

Production-grade from day one

Security-first approach

Post-delivery support included

Bulletproof Hosting Providers

DMCA-Ignored Servers

Offshore VPS Hosting

Anonymous Hosting Solutions

Ready to get started?

Skip the research. Tell us what you need, and we'll scope it, implement it, and hand it back — fully documented and production-ready.

Start a Brief Iceland VPS I