Tor / onion services — verification pass 20 Oct 2026

Legit .onion links — 24 addresses, tested for real

A bookmark page of legal onion services is easy to write and easy to get wrong: most .onion lists on the web are dead, cloned, or rebuilt from memory. So instead of copying a directory, I started a Tor client and fetched every single address, recording HTTP status, byte count and the page title. 13 of 24 served real content; the failures were as informative as the successes.

onion addresses tried
24
confirmed serving
13 /24
clearnet controls
5
markets included
0
addresses I had wrong
1 BBC
biggest page
710 KB (BBC)
The ask, verbatim

“in onion brower, can you find me some links for that, maybe not those dark web ones … maybe like find links but doesnt have to be illegal”

How each address was tested

1

No Tor Browser assumption

Tor Browser is installed at /Applications/Installed Applications/Tor Browser.app, but a GUI proves nothing about an address. The test harness is the tor daemon that ships with it, started headless: tor --SocksPort 9050 --DataDirectory /tmp/tordata.

2

Every request goes through the onion network

curl --socks5-hostname 127.0.0.1:9050 — the hostname flag matters: it hands the .onion name to Tor to resolve, instead of trying (and failing) to DNS-resolve it locally.

3

Three signals per address, not one

HTTP status code, download size, and the page <title> scraped from the body. A 200 alone is not proof — a captive portal or a phishing clone also returns 200. Byte count plus a sane title is what makes “live” mean something.

4

Retry ladder before calling anything dead

Onion circuits on this network are slow and drop mid-handshake. Anything that failed got a second and third attempt with a longer ceiling (45 s → 90 s). Four addresses moved between runs, so a single timeout proves nothing.

5

Cross-check against an independent monitor

dark.fail publishes per-site up/down status. I compared its labels to my own results and only then treated the dead ones as dead — agreement from a second source is the difference between “my network is throttled” and “this service is offline”.

6

Ship a page that works inside Tor Browser

The deliverable is a single dark-theme HTML file with Open / Copy per row. Chrome and Safari cannot resolve .onion, so the page is meant to be dragged into Tor Browser. Every address on it is one of the 13 verified rows below.

Why onion traffic needs no exit node

this Mac
  1. curl → SOCKS 9050
  2. tor picks 3 hops
  3. rendezvous cookie
never sees the service IP
guard + middle
  1. sees encrypted cells only
  2. no exit relay involved
  3. relay never learns the target
“no exit nodes in consensus” is fine here
onion service
  1. intro point + rendezvous
  2. answers over TLS
  3. its IP stays hidden
the last hop is the server itself

The tor log printed “The current consensus has no exit nodes. Tor can only build internal paths, such as paths to onion services.” — a warning that would break a normal website fetch, and completely irrelevant to onion fetches. For an onion service the third hop is the service, reached via a rendezvous point, so no exit relay is needed. The 5 clearnet control fetches (freedom.press, securedrop.org, signal.org, archive.org, wikipedia.org) all returned real pages, which proved circuits had capacity — so a failing .onion was the address, not the network.

Results — all 24 addresses

ServiceResultAddressBytesEvidence
Tor Project● live2gzyxa5ihm7nsggfxnu52r…len53wid25,736Tor Project | Anonymity Online
Tor Blog● livepzhdfe7jraknpj2qgu5cz2…mg7o5pad15,906Tor Blog | The Tor Project
DuckDuckGo● liveduckduckgogg42xjoc72x3…gswzczad237,017DuckDuckGo — Protection. Privacy.
Ahmia● livejuhanurmihxlp77nkq76by…sot4csyd4,747(JS shell, no <title>)
Proton Mail● liveprotonmailrmez3lotccip…vfu7ozyd426,538Proton: Privacy by default
Deutsche Welle● livedwnewsgngmhlplxy6o2twt…62tszfid12,300(JS shell, no <title>)
BBC● livebbcnewsd73hkzno2ini43t…h7745uqd710,312BBC - Home
CIA● liveciadotgov4sjwlzihbbgxn…sxyjstad549,094CIA
Guardian — SecureDrop● livexp44cagis447k3lpb4wwhc…2gjvc2yd6,866Welcome | The Guardian | SecureDrop
NYT — SecureDrop● liveej3kv4ebuugcmuwxctx5ic…55thufqd4,036Welcome | SecureDrop
Washington Post — SecureDrop● livevfnmxpa6fo4jdpyq3yneqh…l75ir5qd4,030Welcome | The Washington Post | SecureDrop
Economist — SecureDrop● livemxmddqsh4jnr4gjan37ayi…jbxdjtad4,036Welcome | SecureDrop
ProPublica — SecureDrop● live33xu4yhum2eiisxm6fntas…ub25cead5,018Welcome | SecureDrop
NYT (main site mirror)○ nonytimesn7cgmftshazwhfg…ljsciiyd—no response, 3 attempts
ProPublica (main site)○ nop53lf57qovyuvwsc6xnrpp…znfu5uqd—no response, 3 attempts
Facebook○ nofacebookwkhpilnemxj7as…7kx5tfyd—HTTP 500
Riseup (v3)◐ unclearvww6ybal4bd7szmgncyruu…copnpyyd15,393responds, no <title> — unverified
Archive.is○ noarchiveiya74codqgiixo3…5bpcbiyd0empty response
Tor Community○ noxmrhfasfg5suueegrnc4gs…b6t2ioyd—no response, 2 attempts
Tor Support○ no4bflp2c4tnynnbes…—no response (stale address)
Debian○ no5ekxf6nwwovjvw2zoxwnjn…7qwv3pqd—no response (I reconstructed this — wrong)
Mullvad○ noxcl62n5bxjqtubanornwjo…wjd2puad—no response (I reconstructed this — wrong)
Riseup (v2)○ no5gdvpfoh6kb2iqhi…—16-char v2 — deprecated network-wide
DW (v2)○ nodwnewsvdyyiamwnp…—16-char v2 — deprecated network-wide

Cross-validation against dark.fail

dark.fail saysMy curl through TorAgree
BBC — online710,312 B, title “BBC - Home”yes
NYT — offlineno response, 3 attemptsyes
ProPublica — offlineno response, 3 attemptsyes
Proton Mail — online426,538 B, “Proton: Privacy by default”yes
Riseup — online15,393 B but no titlepartial

My first BBC address — bbcixlktsukpsyh6nnj7n4h6qm4sqsfmwxxqtxv24vmxbxczjqxqyad — never answered. The one that works is the address dark.fail lists: bbcnewsd73hkzno2ini43t4gblxvycyac5aw4gnv7t2rccijh7745uqd, 710 KB, title “BBC - Home”. I had reconstructed the wrong one from memory. That is the whole argument for testing instead of trusting recall — and it is exactly the failure mode that gets people phished.

What actually makes an onion link trustworthy

1 · The operator's own site

Visit bbc.com in Tor Browser and a purple “.onion available” chip appears. That is the Onion-Location header, served by the organisation itself. It is the only source that cannot be poisoned by a third party.

2 · PGP-signed lists

A published address is a claim; a signed address is a verifiable claim. dark.fail signs its list and publishes a mirror file precisely because clones outrank originals.

3 · v3 addresses are self-authenticating

The 56-char address is derived from the service's public key. You cannot typo your way onto an attacker's server — a wrong address simply goes nowhere. That is why the dead rows above fail silently instead of landing on fakes.

4 · The threat is the list, not the network

Phishing works by handing you a live clone at a similar-looking address. Ahmia itself prints “right onion address starts with juhanurmihxlp77 and ends with 4csyd.onion” for exactly this reason.

Honest limitations. Statuses are a snapshot of 20 Oct 2026 on a throttled school connection — mirrors go up and down, and “no response” here means “not proven either way”, not “dead forever”. Five of my failures (Tor Support, Debian, Mullvad, Riseup v2, DW v2) were addresses I reconstructed or that belong to the retired 16-character v2 network — my bad guesses, not broken services. The set is also deliberately narrow: news, search, email and whistleblower boxes only. No markets, no “hidden wiki”, nothing that needed a legal judgement call. And no security tool can tell you that a live onion is the right onion — that check only comes from the operator's signature or its own clearnet site.

Evidence

ArtifactValue
link boarddemos/onion-links-mirror/index.html
board size12,204 bytes
sha-256 (source = mirror)6b2109896039b068f9604fe9cf7d4534c9b2cc7ea7b3df65144f69829511f064
verification methodtor 0.4.x daemon + curl --socks5-hostname
retry policyup to 3 attempts, 45 s → 100 s ceiling
indices usedsecuredrop.org JSON directory, onion.torproject.org, dark.fail
Open the link board → Portfolio home

Served copy: the file in the repo and its mirror are byte-identical (hash above). The served copy is a few hundred bytes larger because deploys inject the site skin engine and the Cloudflare beacon — that delta is the deploy, not the artifact.

What's next

Candidate V2 — a local checker

check-onion.sh <address> … that boots Tor, walks a list, and prints live/dead + title + bytes as a table. The harness already exists in this session (worker.sh + a parallel driver); what is missing is packaging it so it runs on demand instead of inside one chat.