{ "version": "v1", "slug": "host-a-tor-hidden-service", "title": "How to host a service as a Tor hidden service", "description": "Set up a .onion address for your website, wiki, or app — torrc config, hostname rotation, vanity addresses, and the operational pitfalls (clock skew, leaking real-IP via headers, descriptor uptime) that quietly de-anonymize hidden services.", "intro": "Running a Tor hidden service is operationally close to running a normal web service, with one critical difference: every leak is permanent. Below: the minimum-viable setup, the v3-onion-only world we live in, and the failure modes that ruin the anonymity you're paying for.", "body_plain": "Why host on Tor Hide the server's location. No DNS, no public IP, no AS-level attribution from a casual observer. End-to-end encryption by default — the .onion handshake replaces TLS-via-CA. (You can still layer TLS on top for compatibility, but it's not required.) Censorship resistance. Hidden services are reachable from anywhere the Tor network is reachable; no domain to seize, no IP to block at the country level. Caveat: hiding the server's location does not hide what the service does. Logs you keep, accounts you accept, payment processors you forward to — all unchanged. v3 onion only, in 2026 v2 onions (short 16-char) were deprecated in 2021. Use only v3 (56-char) hidden services. They use better crypto, support client auth, and have no known mass-deanon attacks. If a tutorial references v2 it's out of date. Minimum-viable setup Install Tor on the same host as the service. apt install tor on Debian/Ubuntu, equivalent elsewhere. Edit /etc/tor/torrc : HiddenServiceDir /var/lib/tor/my-service/ HiddenServicePort 80 127.0.0.1:8080 HiddenServiceVersion 3 (Port 80 inside the hidden service maps to whatever your local app is listening on.) Restart Tor. systemctl restart tor . Read the hostname. cat /var/lib/tor/my-service/hostname — that's your .onion address. Test. Open Tor Browser → paste the .onion. Page loads = working. Page doesn't load = check Tor logs ( /var/log/tor/log ). Operational pitfalls (the ones that bite) Clock skew. If your server's clock drifts by more than a few minutes, your descriptor won't post and the .onion goes dark. Run chrony or systemd-timesyncd . Leaking real-IP via headers. Default nginx config logs the request and includes X-Forwarded-For or X-Real-IP based on the proxy. If anything in your stack writes the request's real IP into the page (an error message, a debug header, a chat that echoes back), you've defeated the .onion's purpose. Audit every layer. Public referer leak. Outbound links from the hidden service that go to clearnet send the .onion as Referer by default. Mitigation: Referrer-Policy: no-referrer header. Server-side tooling. Hidden service operator wallets / databases / cron jobs that phone home outside Tor reveal the real IP. Run all egress through Tor or block egress entirely on the firewall. SSH backdoor on the real-IP interface. Convenient for admin, terrible for anonymity. Either run SSH on a separate hidden service too, or disable password auth + key-only + non-default port + fail2ban + accept the residual leak. Descriptor downtime. If the Tor daemon goes down for hours, the hidden service descriptor expires + you have to wait for re-propagation. Keep systemd auto-restart on the Tor unit. Vanity onion addresses If you want your .onion to start with specific characters (e.g. \"xmrclub...\"), use mkp224o . Eight-character prefix takes hours on a laptop; longer prefixes are exponentially harder. Keep the generation host offline / isolated — anyone who sees the resulting private key ( hs_ed25519_secret_key ) controls the address. Onion-Location header (advertise to clearnet visitors) If you also serve a clearnet version, add the Onion-Location response header so Tor Browser shows a \".onion available\" banner. Modern Tor Browser auto-redirects to it on first visit: Onion-Location: http://.onion$request_uri The xmr.club onion audit daily-probes every operator-published Onion-Location header against the .onion we list, so an inconsistency between the header and the address you publish elsewhere shows up immediately. Client authorization (advanced) If you don't want the hidden service to be publicly browsable, use v3 client-auth. The server requires a per-client public key in its config; clients without the matching key get a \"permission denied\" from Tor itself, not your app. Useful for private-team services, customer-only support portals, etc. Hosting that already handles Tor for you If you don't want to run Tor on your VPS yourself — picks below run no-KYC providers that either pre-configure Tor on a managed instance or accept your manually-installed setup. Pay in XMR; treat the host as a soft adversary anyway.", "body_html": "\n
\n

Why host on Tor

\n \n
\n\n
\n

v3 onion only, in 2026

\n

v2 onions (short 16-char) were deprecated in 2021. Use only v3 (56-char) hidden services. They use better crypto, support client auth, and have no known mass-deanon attacks. If a tutorial references v2 it's out of date.

\n
\n\n
\n

Minimum-viable setup

\n
    \n
  1. Install Tor on the same host as the service. apt install tor on Debian/Ubuntu, equivalent elsewhere.
    2. \n
  2. Edit /etc/tor/torrc:\n 
    HiddenServiceDir /var/lib/tor/my-service/\nHiddenServicePort 80 127.0.0.1:8080\nHiddenServiceVersion 3
    \n (Port 80 inside the hidden service maps to whatever your local app is listening on.)
    3. \n
  3. Restart Tor. systemctl restart tor.
    4. \n
  4. Read the hostname. cat /var/lib/tor/my-service/hostname — that's your .onion address.
    5. \n
  5. Test. Open Tor Browser → paste the .onion. Page loads = working. Page doesn't load = check Tor logs (/var/log/tor/log).
    6. \n
\n
\n\n
\n

Operational pitfalls (the ones that bite)

\n
    \n
  1. Clock skew. If your server's clock drifts by more than a few minutes, your descriptor won't post and the .onion goes dark. Run chrony or systemd-timesyncd.
    2. \n
  2. Leaking real-IP via headers. Default nginx config logs the request and includes X-Forwarded-For or X-Real-IP based on the proxy. If anything in your stack writes the request's real IP into the page (an error message, a debug header, a chat that echoes back), you've defeated the .onion's purpose. Audit every layer.
    3. \n
  3. Public referer leak. Outbound links from the hidden service that go to clearnet send the .onion as Referer by default. Mitigation: Referrer-Policy: no-referrer header.
    4. \n
  4. Server-side tooling. Hidden service operator wallets / databases / cron jobs that phone home outside Tor reveal the real IP. Run all egress through Tor or block egress entirely on the firewall.
    5. \n
  5. SSH backdoor on the real-IP interface. Convenient for admin, terrible for anonymity. Either run SSH on a separate hidden service too, or disable password auth + key-only + non-default port + fail2ban + accept the residual leak.
    6. \n
  6. Descriptor downtime. If the Tor daemon goes down for hours, the hidden service descriptor expires + you have to wait for re-propagation. Keep systemd auto-restart on the Tor unit.
    7. \n
\n
\n\n
\n

Vanity onion addresses

\n

If you want your .onion to start with specific characters (e.g. \"xmrclub...\"), use mkp224o. Eight-character prefix takes hours on a laptop; longer prefixes are exponentially harder. Keep the generation host offline / isolated — anyone who sees the resulting private key (hs_ed25519_secret_key) controls the address.

\n
\n\n
\n

Onion-Location header (advertise to clearnet visitors)

\n

If you also serve a clearnet version, add the Onion-Location response header so Tor Browser shows a \".onion available\" banner. Modern Tor Browser auto-redirects to it on first visit:

\n 
Onion-Location: http://<your-56-char-v3-onion>.onion$request_uri
\n

The xmr.club onion audit daily-probes every operator-published Onion-Location header against the .onion we list, so an inconsistency between the header and the address you publish elsewhere shows up immediately.

\n
\n\n
\n

Client authorization (advanced)

\n

If you don't want the hidden service to be publicly browsable, use v3 client-auth. The server requires a per-client public key in its config; clients without the matching key get a \"permission denied\" from Tor itself, not your app. Useful for private-team services, customer-only support portals, etc.

\n
\n\n
\n

Hosting that already handles Tor for you

\n

If you don't want to run Tor on your VPS yourself — picks below run no-KYC providers that either pre-configure Tor on a managed instance or accept your manually-installed setup. Pay in XMR; treat the host as a soft adversary anyway.

\n
\n ", "picks": [ { "category": "hosting", "id": "njalla-vps", "name": "Njalla VPS", "url": "https://www.xmr.club/hosting/njalla-vps", "markdown_twin": "https://www.xmr.club/llm/hosting/njalla-vps.txt", "why": "Privacy-respecting VPS, XMR payment, anonymous-friendly support — install Tor yourself, no questions asked." }, { "category": "hosting", "id": "1984-hosting", "name": "1984 Hosting", "url": "https://www.xmr.club/hosting/1984-hosting", "markdown_twin": "https://www.xmr.club/llm/hosting/1984-hosting.txt", "why": "Iceland-based, free-speech focused. Accepts crypto. Hands-off on what you host." }, { "category": "hosting", "id": "incognet", "name": "Incognet", "url": "https://www.xmr.club/hosting/incognet", "markdown_twin": "https://www.xmr.club/llm/hosting/incognet.txt", "why": "No-KYC hosting + email signup. Tor mirror." }, { "category": "tools", "id": "tor-browser", "name": "Tor Browser", "url": "https://www.xmr.club/tools/tor-browser", "markdown_twin": "https://www.xmr.club/llm/tools/tor-browser.txt", "why": "Test your hidden service from the same UA your users will. Mandatory." } ], "url": "https://www.xmr.club/guides/host-a-tor-hidden-service", "markdown_twin": "https://www.xmr.club/llm/guides/host-a-tor-hidden-service.txt" }