Tor-Friendly Bulletproof Hosting in Romania

We explicitly permit the following Tor network roles on all Romania VPS plans:

• Tor relays (middle nodes): Forward encrypted traffic between Tor nodes. No exit traffic reaches the open internet from a relay. Lowest abuse-complaint risk; we receive effectively zero complaints for middle nodes. Recommended starting point for new operators.
• Tor bridges: Unlisted relays that help censored users access the Tor network. Bridge operators receive even fewer abuse complaints than middle nodes because they are not listed in the public consensus.
• Tor exit nodes: Forward traffic from the Tor network to the open internet on behalf of users. Generates abuse complaints from IPs scanning, probing, or accessing reported content. We handle exit node abuse complaints manually and under our jurisdiction policy - not with auto-termination. We recommend exit node operators publish an exit policy that excludes the highest-risk ports (25 SMTP, 6660-6670 IRC) to reduce volume.
• .onion service hosting: Hidden services accessible only through the Tor network. These generate no external traffic and therefore no external complaints. Ideal for privacy-sensitive services.

Mainstream providers reject Tor exit nodes for a simple operational reason: they use automated abuse pipelines. An automated system that receives a complaint about an IP triggers an automated suspend. This is efficient for scale but completely wrong for exit nodes, where the IP is shared by thousands of users who had nothing to do with the reported traffic.

We don't use automated abuse pipelines for Tor IPs. When we receive a complaint about a Tor exit node IP:

1. We check whether the IP is listed in the Tor consensus as an exit node.
2. If yes, we respond to the complainant with our Tor operator standard response explaining the network architecture.
3. We forward the complaint to the exit node operator as an FYI (not as an action demand).
4. We take action only if the specific exit policy permits the traffic type AND there's a valid Romanian court order - which essentially never happens for standard copyright complaints.

This is the same approach that responsible Tor-friendly providers in Europe have used for years. It requires more human time per complaint than an automated system, but it's the only operationally correct approach.

Romania doesn't honor extraterritorial DMCA requests. Takedowns require Romanian court orders following EU due process - not a one-line email from a copyright holder. This keeps content online unless there's actual legal cause.

Romania adds specific privacy benefits for Tor operators beyond DMCA resistance:

• No mandatory data retention for small operators: Romania's implementation of EU data retention policy focuses on telecoms and large ISPs, not VPS hosting customers. We are not required to log your Tor traffic or retain connection metadata beyond standard server operation logs.
• No Roskomnadzor cooperation: Russia's internet regulator has demanded Tor node IP removal from the consensus (effectively censoring Tor). Romania does not cooperate with Roskomnadzor censorship requests.
• EU human rights protections apply: Operating Tor infrastructure is protected expression under the EU Charter of Fundamental Rights (Article 11, freedom of expression, and Article 8, right to privacy). Romanian courts have upheld this in domestic cases.

Technical configuration recommendations based on experience with Tor operators on our infrastructure:

• Bandwidth allocation: Tor relay performance scales with available bandwidth. Set RelayBandwidthRate to 80% of your tier's sustained capacity. For VPS I with 5 TB/month allocation: approximately 15 Mbps sustained average corresponds to ~5 TB/month. Exit nodes typically run at 30-50% of advertised bandwidth.
• CPU sizing: Tor's crypto operations (ChaCha20-Poly1305, curve25519) are CPU-bound. A single-core relay handles ~100 Mbps before CPU becomes the bottleneck. VPS I (2 vCPU) handles a healthy middle relay at 200+ Mbps. Exit nodes with higher circuit counts benefit from VPS II (4 vCPU).
• Exit policy recommendation: Start with a reduced exit policy to minimize abuse volume: allow ports 80, 443 (web), 22 (SSH), 21 (FTP), 143/993 (IMAP), 110/995 (POP3). Block ports 25 (SMTP), 6660-6670 (IRC), 1194 (OpenVPN - frequently flagged as DDoS reflector).
• Monitoring: Use nyx (Tor arm replacement) for bandwidth and circuit monitoring. Set up systemd with automatic restart on failure. Our panel provides VNC access for recovery if Tor misconfiguration blocks SSH.

Some operators run both Tor relay/exit infrastructure and conventional bulletproof services on the same VPS. This is allowed but requires some thought:

• Separate IPs for Tor and your services: We provide 1 IPv4 per plan by default. For exit nodes, you'll want Tor to use the dedicated IP and your other services to use a separate IP (available for a small fee, open a ticket). This prevents Tor-generated abuse complaints from affecting your service's IP reputation.
• Bandwidth partitioning: Set Tor bandwidth limits so relay traffic doesn't consume all of your 5 TB/month allocation. Exit node operators running at 30 Mbps sustained use approximately 9.5 TB/month - larger than the included allocation. Consider running middle relay (not exit) if you want to share a VPS with other services.
• .onion-only services: If you want to run a Tor hidden service (.onion) with no clearnet exposure, there is no Tor exit node involved and no additional abuse surface. A .onion service on VPS I is completely invisible from the public internet and generates no external complaints.