Onion Mirror

Three things, in order of importance:

1. Source protection. Tor users reaching your site via .onion don't expose themselves to exit-node observation. The full path from user to your service stays inside Tor. Their ISP doesn't see they visited you. Your hosting provider doesn't see their public IP.
2. Censorship circumvention. If your public domain is blocked at the network level (national firewall, corporate filter, ISP-level block), the .onion mirror still works as long as the user can reach Tor at all.
3. Authenticity. An .onion address is cryptographically tied to a specific service. Users can't be MITM-attacked the way they can be against a public domain. The address itself is the key fingerprint.

Not everyone needs all three. But for journalists, activists, security researchers, sources, dissidents, and anyone in a hostile network environment, having an .onion option matters.

The audience for .onion access is smaller than the audience for the public web, but it's a high-value subset:

• Journalists' sources. Whistleblowers contacting investigative outlets. The whole reason organisations like ProPublica, BBC, NYT run onion mirrors.
• Security researchers. People investigating threats who don't want their research traffic visible to potential adversaries.
• Privacy-conscious general users. Tor Browser is more popular than people realise. Millions of users globally. Many use it as their default browser for sensitive activity (banking, medical, political).
• Users in censored jurisdictions. China, Iran, Russia, parts of Central Asia, parts of the Middle East. The public web is partially or fully blocked. Tor remains accessible.
• Activists and dissidents. Coordinating without state observation.

Notice what's NOT on this list: criminals using your onion mirror are not really a thing. Criminals do not need your particular onion mirror; they have their own infrastructure. The "onion = crime" assumption confuses Tor with darknet markets, which are a tiny subset of Tor usage and have nothing to do with running a mirror of a normal website.

From the operator perspective:

• Signal of credibility for privacy-focused operators. If your service exists in part to protect user privacy, running an onion mirror is consistent with that mission. Not running one signals the opposite.
• Operational cost is low. Once configured (EOTK or manual setup), maintenance is minimal. Updates flow through with the public site. No separate codebase.
• Regulatory compliance in some jurisdictions. Some EU privacy regulations look favourably on operators that provide privacy-respecting access options. Not required, but it helps the regulatory positioning.
• Resilience against censorship. If your public domain gets blocked in some jurisdiction (state-level or commercial), the onion mirror remains accessible. Censorship-resistant by construction.
• Source pipeline. News organisations and platforms that depend on tip-line submissions need the onion mirror to make whistleblowers feel safe contacting them.

Honest counterargument: not every site needs an onion mirror.

• If your audience is mainstream consumers buying widgets, the onion mirror is barely used. Operational complexity without commensurate benefit.
• If your application has heavy interactive features that don't work well over Tor latency, the onion mirror experience is poor. Better not to offer it than to offer a broken version.
• If you're heavily dependent on third-party services (CDNs, payment processors, analytics) that don't mirror, the onion experience will be incomplete and confusing. Often the right call is to skip the mirror until you can offer the full experience.
• If your TOS or content category attracts active law-enforcement scrutiny, running an onion mirror may make your operation look more sketchy to receivers and reputation systems, even though there's nothing actually sketchy about it. Sometimes the perception matters operationally.

Once your mirror works, users need to find it.

• Onion-Location header. Set on every response from your public domain. Tor Browser automatically detects it and offers users the .onion option. The single most important publication mechanism.
• Footer link or "About" mention. Public-facing notice that an onion mirror exists. Even users not on Tor see it, which itself is a signal.
• Documentation and explainers. A page explaining what the .onion is, why you run it, and how to access it (Tor Browser download link, basic usage tips). Removes friction for users who want to use it but don't know how.
• Vanity address if affordable. An onion address starting with a recognisable prefix is more trustworthy to users than a random string. mkp224o generates them; this costs CPU time, not money. A 6-character vanity prefix takes a few hours on modern hardware. 8 characters takes weeks.

An onion mirror is a Tor hidden service that exposes the same content as a clearnet site but accessible only through the Tor network. The mirror typically reverse-proxies to the clearnet origin or serves a separate copy of the same content; both architectures have operational tradeoffs.

The reverse-proxy architecture runs a Tor hidden service that forwards requests to the clearnet origin server. This is operationally simple because the content stays in one place and updates propagate automatically. The privacy posture is degraded somewhat because the origin server sees the request after Tor exits the network, which means the operator could in principle log the request if they chose to do so. For onion mirrors of clearnet sites that are themselves not privacy-positioned, the reverse-proxy architecture is acceptable; for onion mirrors of privacy-positioned services, the architecture undermines the value proposition.

The separate-copy architecture runs a Tor hidden service that serves an independent copy of the content from infrastructure that has no clearnet exposure. This is operationally more complex because content updates need to flow to both copies, but the privacy posture is substantially better because the request never exits the Tor network. The infrastructure can be configured to retain no logs whatsoever; even if it were compromised, there would be nothing useful to discover.

The choice between the two architectures depends on the specific privacy requirement. For news organizations, journalism platforms, and privacy-focused services, separate-copy is the operationally correct choice despite the additional complexity. For commercial sites adding a Tor mirror as a convenience for Tor-using customers without specific privacy requirements, reverse-proxy is acceptable.

Tor hidden service addresses (onion addresses) are derived from public keys, which makes them cryptographically meaningful identifiers. The current version (v3 onion services) uses ed25519 public keys, producing 56-character addresses ending in .onion. The previous v2 onion services (16-character addresses) have been deprecated since Tor 0.4.6 and are no longer supported; any v2 references in existing documentation are obsolete.

Random onion addresses generate within seconds and require no computational effort. Vanity onion addresses with specific prefixes require brute-force computation that increases exponentially with prefix length. A 7-character prefix typically generates within hours on a single GPU; an 8-character prefix takes days; addresses with 10+ character prefixes have been generated but require substantial computing resources. Tools like mkp224o handle the generation; the operational pattern is to run generation on a dedicated GPU machine and copy the resulting keypair to the production Tor hidden service infrastructure.

Key management for onion services is critical because compromise of the private key means complete loss of control over the address. The address cannot be recovered if the key is lost (no central authority to appeal to), and the address can be impersonated if the key is leaked (anyone with the key can serve content at that address). Production deployments should treat the onion service private key like a code-signing key: stored offline when not in use, backed up to multiple physical locations, accessed only through controlled processes.

Address rotation is sometimes appropriate when the operational context changes (operator changes, infrastructure migration to incompatible setup, suspected key compromise). The previous address can be redirected to the new one through HTTP redirects served by the old hidden service before its shutdown, allowing existing users to discover the new address through normal browsing. The transition window should be long enough for major directories and references to update, typically 30-90 days.

Tor performance has improved substantially through 2022-2026 due to network upgrades, the rollout of arti (the Rust-based Tor implementation), and increased capacity at major Tor nodes. Onion service performance specifically has improved more than clearnet-via-Tor performance because the network architecture for hidden services has become more efficient.

Typical performance numbers as of 2026: page load times for well-optimized onion services run 2-5 seconds for initial connection (including circuit establishment) and 0.5-2 seconds for subsequent requests on the same circuit. Throughput peaks at 5-15 Mbps per circuit for users on good Tor exits or hidden service paths. The latency penalty compared to clearnet remains substantial (5-20x typical) but the absolute numbers are now acceptable for content-heavy sites that would have been unusable through Tor in 2018-2020.

The performance bottlenecks shifted through 2024-2026 from Tor network capacity (which scaled substantially) to client-side resource constraints. Tor Browser on older hardware struggles with modern web sites that depend on heavy JavaScript and large CSS payloads. The implication for onion mirror operators: optimize aggressively for low-resource clients, minimize JavaScript dependencies, lean on server-side rendering, ship lean CSS. The discipline that produces good onion-mirror experience also produces good clearnet experience for users on constrained connections; the optimization investment pays back across multiple user segments.

Onion services as content delivery infrastructure remain unsuitable for very high traffic volumes or for content that depends on real-time interactivity. Static content and traditional web applications work well. Real-time chat, streaming video, or anything requiring sub-second latency does not. The Tor network architecture has fundamental latency floors that no amount of optimization can eliminate; operators with use cases that need real-time properties should use Tor as one access path among several rather than as the sole access mechanism.

Hosting an onion mirror produces different legal exposure than hosting clearnet content because the legal frameworks applicable to Tor-accessible content vary by jurisdiction and have evolved through 2022-2026. The summary below reflects 2026 operational reality but should not substitute for jurisdiction-specific legal review.

The hosting jurisdictions we operate from (Bulgaria, Romania, Moldova, Ukraine, Panama, Hong Kong, Singapore) all permit operation of Tor hidden services as content infrastructure without special licensing or restrictions. The general legal principle is that the hosting provider is responsible for the content it hosts according to the same framework that applies to clearnet content; Tor accessibility does not create separate obligations.

The legal-process exposure for onion mirror hosts depends on what the operator retains and what the legal process targets. For separate-copy architectures with no-logging configurations, legal process typically returns no actionable data because no data is retained. For reverse-proxy architectures where the origin server logs requests, legal process can target those logs through the standard mechanisms applicable to clearnet hosting.

The reputational exposure for onion mirror hosting has decreased through 2022-2026 as Tor has been increasingly recognized as legitimate infrastructure for privacy, journalism, censorship resistance, and security research. The legacy framing of Tor as inherently associated with illegal activity has been substantially displaced by frameworks that recognize Tor as essential privacy infrastructure with broad legitimate use. The shift makes onion mirror hosting less commercially risky than it was in earlier periods.

Operators considering an onion mirror should think about the use case and target audience. Mirrors of journalistic content, security research, censorship-circumvention services, and privacy-positioned tools have clear legitimate framing. Mirrors of commercial sites without specific privacy requirements may be perceived as performative rather than purposeful. We have hosted multiple onion mirrors for customers in the journalism and privacy categories; mirrors for purely commercial customers have been infrequent because the operational value rarely justifies the additional complexity.

Operators deploying onion mirrors often want to understand traffic patterns and engagement on the Tor side similar to how they understand clearnet analytics. The structural and ethical considerations make this more complex than simply deploying clearnet analytics tooling on the onion mirror.

The structural reality: Tor users typically have strong expectations about privacy that conventional analytics tooling violates. Loading external analytics scripts on the onion mirror leaks information to the analytics provider about Tor users in ways that defeat the purpose of Tor access. Many Tor users block third-party scripts by default and have configurations specifically designed to defeat analytics tracking. The analytics implementation that works on clearnet typically does not work on onion mirrors for these reasons.

The ethical consideration: collecting detailed analytics on Tor users contradicts the privacy positioning that typically justifies running an onion mirror. Operators running onion mirrors for journalism, source protection, or censorship circumvention should not collect data that could identify or fingerprint their Tor users. The analytics question reduces to whether the operator can justify the data collection given the audience.

The practical approach that respects both technical reality and ethical considerations: minimal server-side logging that captures aggregate request patterns (request rates, response codes, popular paths) without individual-user tracking. The aggregate data supports operational decisions (capacity planning, content effectiveness) without compromising the privacy properties the onion mirror provides. Server logs configured for aggregate-only retention and no user identifiers achieve this.

For operators wanting more sophisticated analytics: self-hosted privacy-respecting analytics platforms (Plausible, Umami, GoatCounter all support self-hosted operation) running on the same infrastructure as the onion mirror provide more sophisticated analytics without external data leakage. The configuration should respect Do-Not-Track signals and use no cookies; the implementation produces useful operational visibility without compromising the underlying privacy properties.