Double-Anonymization VPS Hosting

A single anonymity layer is sufficient for most threat models. Where double-anonymization adds value is for operators who face a sophisticated adversary capable of compromising one layer through legal process, traffic analysis or operational mistakes. By composing two independent layers the operator forces the adversary to compromise both, which is meaningfully harder than compromising either one in isolation.

The most common double-anonymization architecture is "Tor over VPN over offshore VPS." The application runs on an offshore VPS and is reachable only as a Tor v3 onion service. Management access to the VPS is restricted to traffic that arrives over a VPN tunnel terminated on a separate no-log VPS, and the operator's local machine connects to that VPN exclusively over Tor. This stacks Tor's circuit-based anonymity with a VPN's network-level isolation and produces two independent layers that share no operational state.

The inverse architecture, "VPN over Tor," is appropriate for use cases where the operator wants a stable exit IP that is not on a public Tor exit list, but is willing to accept the lower-bandwidth profile that comes from tunneling a VPN inside a Tor circuit. This is rarer and is typically used by operators of specific services that require allowlisted IPs at upstream providers. AnubizHost supports both architectures because both are built from the same set of underlying VPS plans.

The strongest version of the architecture uses two completely independent VPS accounts. The "application VPS" hosts the onion service and is paid for from one crypto wallet, registered with one email, and accessed only through Tor. The "exit VPS" hosts the VPN endpoint and is paid for from a different crypto wallet, registered with a different email, and accessed only through a different Tor circuit. The two VPS instances should be in different jurisdictions, ideally different legal frameworks (Iceland and Romania, for example), so that a legal request in one jurisdiction cannot reach the other.

Avoid colocating the two layers on the same VPS, the same account or the same payment wallet. Operators occasionally try to economize by running the VPN on the same VPS as the application, and this defeats the entire point of the double-anonymization architecture because compromising the VPS compromises both layers simultaneously. The cost of running two separate VPS accounts is small relative to the operational benefit of clean isolation.

Configure the application VPS to drop all inbound traffic that does not arrive through the tor daemon's local loopback. Configure the exit VPS to drop all inbound traffic except management connections from a fixed set of source addresses that the operator controls. Cross-check the firewall rules with a third-party port scan from a Tor exit relay to confirm that neither VPS exposes unexpected services to clearnet scanners.

The architecture only works if the operator maintains strict isolation between the layers. The most common failure mode is reusing an SSH key, a wallet address or an email across both VPS accounts, which creates a correlation that the adversary can recover from public chain analysis or from any single host's logs. Generate fresh keys for each VPS, use a fresh wallet for each, and use distinct email addresses for each. Tools such as KeePassXC make this overhead manageable for operators who maintain multiple isolated identities.

The second most common failure mode is leaking the application's clearnet IP through a misconfigured outbound connection. If the application on the inner VPS ever connects to a clearnet CDN, analytics endpoint or upstream API, the destination's logs now contain a clearnet IP that can be correlated with the onion service. Block all outbound traffic on the inner VPS at the firewall level except to 127.0.0.1, the tor SocksPort and the Tor directory authorities. Any application that needs outbound HTTP must route exclusively through Tor.

The third failure mode is operator-side traffic correlation. If the operator's local machine ever connects directly to the exit VPS's clearnet IP outside the Tor-and-VPN stack, the relationship between the operator and the exit VPS is now in some third party's logs. Use a strict torrc-based transparent proxy on the operator's local machine to enforce that all traffic to the exit VPS goes through Tor, with no exceptions for testing, monitoring or convenience.