Host a Tor hidden service alongside a clear domain

Running a clearnet domain and a Tor hidden service together gives you fallback reach and censorship resistance—legitimate users hit the .com, privacy-conscious visitors hit the .onion.

Why pair clearnet and onion addresses

A clearnet domain—.com, .is, .se, whatever—requires DNS resolution and reaches users who aren't running Tor. A .onion address routes three hops through the Tor network and never exits to clearnet, so there's no public IP to DDoS or seize. Together you get broader reach plus a hard-to-censor backup.

Legitimate use cases: whistleblower platforms, privacy-focused services, journalism outlets, free-speech forums, adult content providers, offshore crypto exchanges. All operate legally somewhere; combining clearnet and onion means mainstream users find you via Google while privacy advocates bookmark the .onion.

Tor onion routing: the essentials

Tor routes traffic through three randomly selected relays—guard, middle, exit—to anonymize your IP. For a hidden service (also called an "onion service"), the circuit ends at your server: no exit node, no clearnet IP exposed. The .onion address is the hash of a cryptographic public key, not a domain you register.

When a Tor Browser user visits your .onion, both client and server build three-hop circuits to rendezvous points; the handshake happens entirely inside Tor. The protocol is documented in the Tor Project's "Rendezvous Specification"—no DNS, no certificate authority, no registrar.

Setting up the hidden service

Install Tor

On Debian/Ubuntu:

apt update && apt install tor

On Alpine or other distros, install the tor package from your package manager.

Configure torrc

Edit /etc/tor/torrc (or wherever your distro places it). Add:

HiddenServiceDir /var/lib/tor/hidden_service/
HiddenServicePort 80 127.0.0.1:8080

Replace 8080 with whatever local port your web server listens on. If you run TLS on port 443 locally, map that too:

HiddenServicePort 443 127.0.0.1:8443

The HiddenServiceDir is where Tor will write the private key and the .onion hostname.

Start Tor and retrieve the .onion address

systemctl restart tor
cat /var/lib/tor/hidden_service/hostname

You'll see something like a2s5u3x7o4b6c8d1.onion (v2, deprecated) or a 56-character v3 address qj4fmxyqak…xyz.onion. Use v3; v2 is obsolete and will stop working.

Point your web server at localhost

Configure Nginx, Apache, Caddy, or whatever to listen on 127.0.0.1:8080. Tor forwards incoming .onion traffic to that socket. Same content, same app—just a different listener.

Example Nginx server block:

server {
    listen 127.0.0.1:8080;
    server_name _;
    root /var/www/html;
    index index.html;
}

Restart Nginx. Tor Browser users can now visit your_actual_onion_address.onion and hit your site.

Linking clearnet to onion with Onion-Location

The Onion-Location HTTP header tells Tor Browser "this site has an onion counterpart." When a Tor user visits your clearnet domain, Tor Browser displays a .onion available button in the address bar.

Add to your clearnet Nginx config (the one serving example.com):

add_header Onion-Location http://youroniondomain.onion$request_uri;

Replace youroniondomain.onion with the actual .onion from /var/lib/tor/hidden_service/hostname. Reload Nginx.

Now a visitor on Tor sees the button, clicks it, and switches to the onion—same session, same content, but routed purely through Tor.

TLS and certificates

Clearnet domain

Your clearnet domain should use TLS (HTTPS). Let's Encrypt is fine; bunkerdomains registrar details stay hidden via privacy WHOIS, and LE only validates domain control—no identity check. Install certbot, point it at your webroot or DNS, get the cert.

Onion address

TLS on .onion is optional. Tor already encrypts traffic end-to-end, so an .onion site served over plain HTTP is encrypted in transit. If you do want HTTPS (to avoid mixed-content warnings or because your app hardcodes https://), either:

• Use a self-signed certificate for the .onion address (browsers expect this and won't warn—Tor Browser treats .onion as a secure context).
• Generate a cert via a CA that issues to .onion addresses (rare; DigiCert and Harica did for certain v3 onions under EV requirements, but it's uncommon).

Most operators serve .onion over HTTP and clearnet over HTTPS. No mixed content because the onion never loads external clearnet resources.

DNSSEC considerations

DNSSEC signs DNS records to prevent cache poisoning. If your clearnet domain has DNSSEC enabled (via the bunkerdomains control panel), resolvers verify the cryptographic chain from root → TLD → your nameservers → your A/AAAA record.

The .onion address does not use DNS—it's resolved inside Tor via the distributed hash table of hidden service descriptors. DNSSEC has zero interaction with onion routing. Your clearnet domain can have DNSSEC; your .onion just… exists independently.

Enable DNSSEC if your threat model includes DNS hijacking. Disable it if your nameservers don't support it or you prefer simplicity. The onion doesn't care either way.

Jurisdiction and the registrar

When you register a domain at bunkerdomains—.com, .is, .se, .co—the TLD registry (Verisign for .com, ISNIC for .is, etc.) holds the canonical record. bunkerdomains provides:

• Anonymous signup (no KYC)
• Crypto payment only (Bitcoin, Monero)
• Free privacy WHOIS (registrant fields redacted or anonymized)
• No replies to DMCA complaints sent to us (we're offshore)

But the TLD registry and ICANN still exist. A .com domain can be suspended via registry-level action if a court order lands there. That's why you pair it with a .onion: the hidden service has no registrar, no DNS, no central authority. Tor Project doesn't "own" .onion—it's a special-use top-level name (RFC 7686) that only resolves inside Tor.

If your clearnet domain gets seized, nuked, or DNS-poisoned, the .onion keeps running as long as your server is online and Tor is reachable. Conversely, if Tor network suffers a 0-day or a nation-state blocks entry guards, your clearnet domain still works for mainstream users.

Example setup summary

Your content is identical on both. The clearnet domain hits your server's public IP (or proxy); the .onion hits 127.0.0.1:8080 via Tor.

Operational tips

1. Monitor both endpoints. Set up uptime checks for the clearnet domain and the .onion (use a Tor-enabled monitoring service or run your own Tor relay to test).
2. Keep Tor updated. apt upgrade tor regularly. Security patches matter.
3. Log carefully. If you log requests, the clearnet access logs contain real IPs (unless you proxy via Cloudflare or similar). The onion logs only show 127.0.0.1—Tor never reveals client IPs to you.
4. Backup the private key. Mentioned earlier, but worth repeating: lose /var/lib/tor/hidden_service/hs_ed25519_secret_key and your .onion address is gone forever.
5. Test with Tor Browser. Don't assume your .onion works—actually fire up Tor Browser, paste the address, verify.

Done

You now have a clearnet domain registered anonymously at bunkerdomains and a Tor hidden service serving identical content. Mainstream visitors hit the .com; privacy advocates hit the .onion. Neither relies on the other's infrastructure, so losing one doesn't kill the other. Skip the registrar fragility, skip the DNS single-point-of-failure—run both and let your users choose their own routing.