How to Spot a Fake Onion Mirror Before You Connect in 2026

torverify's tells of a clone mirror

• The first characters match the real address but the rest does not.
• A long mirror list invites you to guess which entry is real.
• Loud urgency: the old link is “dead”, use this one right now.
• A verified badge or a review block, both of which are just images.
• The page turned up first in a search or a forum, not from a record you trust.

Why these five tells work on people who already know better

None of the five tells above requires any technical skill to fake — that's exactly why they work. A cloned page can copy a layout pixel for pixel, run the same CSS, even reuse torverify's own wording if it wants to. What it cannot do is forge a signature over a record it does not control. Every tell on this list is a way of making a visitor stop reading before they reach the one check that actually matters, which is also why torverify's own pages keep repeating that check rather than assuming a reader remembers it from elsewhere.

The tell that matters most: urgency itself

Of the five, manufactured urgency is worth calling out on its own. Every other tell on this list is passive — a badge, a list, a search result — but urgency is active; it is specifically designed to short-circuit the slow, careful comparison a real check requires. Any page telling you to hurry before checking an address is, by that instruction alone, giving you a reason to slow down instead.

torverify's check that never fails

1. Read the whole address. All 56 characters, against torverify's signed source.
2. Distrust the list. Treat every entry as suspect until it matches the source, one at a time.
3. Ignore the dressing. Badges and design are free to copy and prove nothing on their own.
4. Verify the signature. Confirm it on torverify's PGP tool before you trust a single link.

Why order matters here

Reading the address before checking the signature is not arbitrary. A clone with a mismatched address fails at step one, instantly, without needing any cryptography at all — save the signature check for the addresses that actually pass the simpler test first.

Common mistakes torverify sees when hunting for a fake mirror

Spot-checking a mirror sounds simple until it's rushed. torverify sees the same shortcuts fail people again and again — naming them plainly is the fastest way to avoid repeating them.

Mistake 1: eyeballing the address instead of comparing character by character

A 56-character string is long enough that the human eye happily "autocorrects" a swapped character it doesn't expect to see. Copy both addresses into a plain text field and compare them in short chunks of 6-8 characters, not as one long blur read at a glance — the same chunking torverify recommends throughout torverify's own guides.

Mistake 2: trusting a mirror because a forum vouched for it

A forum post, however many upvotes it has, is not a signed source. Forum accounts are cheap, and a coordinated push to vouch for a fresh clone is a known tactic, not a hypothetical one. Cross-check against torverify's signed source regardless of how confident a thread sounds.

Mistake 3: assuming HTTPS or a lock icon means anything on a .onion

A .onion service does not rely on the same certificate-authority trust model a clearnet HTTPS site does, and a clone can present whatever padlock styling it wants in its own markup. The lock icon in your address bar is not a substitute for a signature check on a Tor hidden service.

Worked example: torverify tells a real mirror from a look-alike

Abstract advice is easy to nod along to and easy to skip under time pressure. Here is the process applied to a concrete situation — two addresses in hand, one genuine, one not, and no way to tell which from a screenshot alone.

Step 1 — lay both addresses out in plain text

Strip any surrounding markup, scheme prefix, or trailing slash from each address, and place them one above the other in a plain text editor, not inside a browser tab that might render similar-looking characters identically.

Step 2 — compare in short chunks, not as a whole

Read both strings in matched six-character chunks left to right. A single swapped character anywhere in a 56-character v3 onion address makes it a completely different key, and chunking is what makes a mismatch buried in the middle actually visible.

Step 3 — cross-check the survivor against the signed source

Whichever address passes the character comparison still needs to match an entry in torverify's signed source and carry a valid signature, per the signature guide. Passing the character check narrows the field; it does not finish the job on its own.

What torverify recommends the moment you suspect a clone

The instinct that something looks slightly off is usually right, and it is worth acting on before you type anything into the page, not after. torverify's recommendation is a short, boring sequence rather than a judgment call made under pressure.

Close the tab before you interact with anything on it

Do not log in, do not "just check the address bar first" while still on the suspect page, and do not click through a captcha or warning banner it presents. A clone's own interface cannot be trusted to tell you anything true about itself — step away from it entirely before doing the actual check elsewhere.

Re-find the address through a source you already trust

Go back to a bookmark, a previously verified note, or torverify's own verify index rather than re-searching and risking landing on the same clone or a sibling of it. The goal is to compare against something you already trust, not something you are trusting for the first time in the moment.

Report it if there's a channel to do so

If the project you were trying to reach has an official channel for reporting phishing clones, use it — a clone caught early affects fewer people. torverify itself does not run a phishing-report inbox for third-party projects, but the projects it tracks typically maintain their own.

Practise on a known-good torverify record

Open a verdict on torverify you can check, read the address there, and get used to comparing every character before you ever need to do it under pressure. The habit is the skill. Once reading the full string feels normal, a look-alike jumps out at you within seconds instead of requiring a second look.

Make the habit automatic, not situational

The people who get caught by a clone are rarely careless in general — they simply never built the specific habit of comparing full addresses, so it doesn't fire automatically under time pressure. Running through torverify's own verify pages a few times when there's no urgency at all is what makes the habit available when there is.

Clone patterns torverify's tracked projects have actually seen

The tells described above are not theoretical. torverify's verify pages document specific clone patterns for the projects it tracks, and the patterns repeat closely enough across unrelated projects to be worth summarizing generally here.

The "outage window" clone

A real onion service goes down for maintenance or relay churn, and within hours a clone claiming to be the "working mirror" appears in forums and search results, timed specifically to catch people who don't know the outage is routine. torverify's Torzon and Mars entries both document this exact pattern recurring across unrelated outages.

The "buried in a real list" clone

Rather than building a standalone fake page, some clones get slipped into an otherwise-accurate-looking mirror list alongside several genuine addresses, betting a reader who verified the first two entries won't bother checking the rest. This is precisely why torverify's check treats every entry in a list as independently suspect rather than extending trust from one verified row to its neighbors.

The "seized name revival" clone

Covered in more depth on torverify's Hydra and AlphaBay pages: a brand recognizable enough to still generate search traffic gets recycled by an operator with no relationship to the original, betting that residual name recognition outweighs due diligence.

How a phishing ring actually operates, and why the address is the anchor

It is tempting to picture a fake mirror as a crude, slightly-off copy of a real page. The convincing ones are the opposite of crude, and understanding how they are built is what makes the "just check the address" advice on this page feel less like a slogan and more like the one move that actually works.

The clone is often not a copy at all — it is a live relay

The most effective fake mirrors are not static screenshots of a market. They are reverse proxies: a server the attacker controls that sits between you and the genuine service, fetching the real pages in real time and passing them straight to you. Because you are looking at content relayed from the actual site, everything behaves correctly — you can log in, the catalogue is real, your messages go through, the layout is pixel-perfect because it is the real layout. Nothing "looks off" because almost nothing is off. The one thing the attacker changes on the way through is whatever earns them money.

What gets altered in transit

Two things, usually. First, credentials: because every request passes through the attacker's server, your username, password, and even a one-time PGP challenge you decrypt are captured as you type them — the proxy simply forwards them to the real site to keep the session looking normal while keeping a copy. Second, payment details: a deposit address or withdrawal address rendered on the page is rewritten on the fly to one the attacker owns, so funds you believe you are sending to escrow go to them instead. This is why a clone can pass every behavioural test you throw at it and still drain you at the one moment that matters.

Why the onion address is the single thing a relay cannot fake

A reverse-proxy clone can relay the real content, but it cannot relay the real address. To sit in the middle, the attacker's service must live at an onion address they control — a different Ed25519 key, therefore a different 56-character string, no matter how the page looks once it loads. That is the whole reason this guide anchors on the address rather than on anything visible inside the page: the address is the one property that is bound to the key doing the serving, and the one property a man-in-the-middle is structurally unable to borrow. Every other signal — design, behaviour, a working login, a real catalogue — can be relayed. The string in the address bar cannot.

How the address reaches you is the part they invest in

Because the address is the weak link in their scheme, phishing operators spend most of their effort on distribution — getting their string in front of you before the real one does. That means seeding it into search results for the market's name plus words like "official" or "link", posting it from aged forum accounts that look established, dropping it on paste sites and link aggregators, and timing pushes to real outages when people are actively hunting for a "working" address. None of this makes the address genuine; it only makes it visible. The countermeasure is the same regardless of how polished the delivery is: never accept an address from wherever you happened to find it, and compare it, in full, against a source you already trust before you type anything into the page it opens.

Why the "tests" people trust don't catch a relay

Once you know the best clones relay the real site, it becomes clear why the reassurances people reach for prove nothing. Each of these feels like a check and is really just the attacker's proxy passing your request through to the genuine service and handing back the genuine answer.

• "The login worked, so it must be real." It worked because the proxy forwarded your credentials to the real site — and kept a copy on the way through.
• "It made me solve a captcha / a PGP challenge, a fake wouldn't bother." A relay forwards the real captcha or the real challenge and relays your answer straight back. Passing it authenticates you to the attacker, not away from them.
• "The catalogue and my messages are all really there." Of course they are — you are looking at the real site's data, fetched live and passed through the middle.
• "The page loaded fast and looked perfect." Speed and polish are properties of the content being relayed, not of who is relaying it.

The pattern underneath all four is the same: any test that lives inside the page can be satisfied by a proxy that forwards it to the real site. The only check that steps outside that loop is comparing the address, in full, against a source obtained separately — because the address is fixed to the key actually serving you, and a relay is serving you from a key that is not the real one. That is why this guide keeps returning to the string and refuses to treat "it behaves correctly" as evidence of anything.

There is a useful way to internalise this: assume, for a moment, that the page in front of you is a relay of the real site, and ask what would still give it away. The answer is only ever the address, because that is the single thing a relay must own itself and cannot borrow. If your verification would survive that pessimistic assumption, it is a real check; if it rests on anything the page shows or does, it would pass a clone just as happily. Verifying the string against an independent source is the one habit that holds up whether the page is genuine or a perfect relay of a genuine one — which is exactly the situation you cannot tell apart by looking.

Browser settings that reduce risk while you check

None of this replaces the address-and-signature routine above, but a couple of Tor Browser settings reduce what a mistake costs while you're doing the comparison.

The Safest security level, for anything you haven't verified yet

Tor Browser's built-in security slider, set to Safest, disables JavaScript and several other attack surfaces by default. Browsing to an address you haven't finished verifying with the slider at Safest means a malicious page has meaningfully fewer tools available even if you land on it by mistake.

New Identity between checking and connecting

Using Tor Browser's "New Identity" feature between researching a mirror and actually connecting to a verified address closes any tabs and clears state that might otherwise carry context between the two, keeping the verification research and the actual connection cleanly separated.