Tor Hosting with DDoS Protection — Keep Your .onion Online

Tor hidden services face unique DDoS challenges that clearnet websites do not. Traditional DDoS mitigation services like Cloudflare cannot protect .onion addresses because they operate at the network layer, while Tor connections are end-to-end encrypted and routed through multiple relays. Attackers exploit this by flooding hidden services with connection requests that overwhelm the Tor process and web server.

Common attack vectors include introduction point flooding, where attackers exhaust the hidden service's introduction points to prevent new connections; rendezvous flooding, where massive numbers of rendezvous circuits consume server resources; and application-layer attacks that send valid-looking HTTP requests designed to consume CPU, memory, or database resources.

Without protection, a moderately resourced attacker can take a standard Tor hidden service offline within minutes. AnubizHost's DDoS protection addresses each attack vector with targeted countermeasures, keeping your .onion site accessible to legitimate users while mitigating malicious traffic at multiple layers.

Tor version 0.4.8+ includes built-in proof-of-work (PoW) defense for hidden services. We enable and optimize this feature on all DDoS-protected plans. When attack traffic is detected, Tor automatically requires connecting clients to solve a computational puzzle before establishing a circuit. Legitimate users solve the puzzle in seconds on modern hardware, while attackers must expend proportionally more resources to maintain their flood.

We configure the PoW difficulty to adapt dynamically based on current load. Under normal conditions, the puzzle is trivial and adds imperceptible delay. Under attack, difficulty scales automatically to match the attack volume, making it economically impractical for attackers to sustain the flood. This adaptive approach ensures legitimate users can always connect, even during large-scale attacks.

Our Tor configuration also uses multiple introduction points distributed across diverse Tor relays, making introduction point flooding less effective. If some introduction points are overwhelmed, others continue functioning. We monitor introduction point health and rotate to fresh relays if sustained targeting is detected.

Application-layer DDoS attacks bypass Tor-level defenses by establishing valid Tor circuits and then sending resource-intensive HTTP requests. Our Nginx configuration includes rate limiting per circuit, connection limits, request size limits, and slow-request timeouts that mitigate these attacks without affecting normal users.

We deploy a Web Application Firewall (WAF) that inspects HTTP traffic for attack patterns: slowloris connections, repeated requests to expensive endpoints, oversized POST payloads, and malformed requests designed to trigger error handling overhead. The WAF operates locally with no external dependencies and adds minimal latency to legitimate requests.

For sophisticated attacks that mimic legitimate traffic patterns, we implement challenge-response mechanisms at the application layer. Under attack conditions, new visitors receive a lightweight JavaScript challenge page that verifies they are using a real browser before granting access to the application. This stops bot-driven attacks while allowing Tor Browser users through with a brief delay.

The most effective DDoS protection for hidden services combines mitigation with redundancy. Our DDoS-protected plans include OnionBalance configuration with multiple backend servers sharing your .onion address. If one backend is overwhelmed by an attack, OnionBalance distributes new connections to healthy backends, maintaining availability even under sustained pressure.

Backend servers are distributed across multiple physical locations, ensuring that a DDoS attack targeting one data center does not affect backends in other locations. Geographic distribution also improves normal-operation performance by reducing circuit length to the nearest healthy backend.

Automatic health checking monitors each backend every 30 seconds and removes unresponsive backends from the OnionBalance rotation within one minute. When a backend recovers, it is automatically re-added. Manual override is available through the control panel for planned maintenance. This self-healing architecture means your .onion service adapts to attacks automatically without requiring human intervention in most scenarios.