en
Tor Exit Relay Policy Configuration: Balancing Utility and Abuse Reduction
Exit relays are the most valuable and highest-impact contribution to the Tor network - they connect Tor circuits to the public internet, allowing Tor users to access websites, APIs, and services. However, exit relays are also the most operationally complex relay type because they are the apparent source of Tor traffic to destination servers, resulting in DMCA notices, abuse reports, and occasional law enforcement contact. Configuring a thoughtful exit policy reduces abuse volume while maintaining the exit relay's contribution to the Tor network. This guide covers exit policy syntax, the reduced exit policy commonly used to minimize abuse while maintaining utility, port-specific considerations, and how to respond to abuse reports received as an exit operator.
Need this done for your project?
We implement, you ship. Async, documented, done in days.
Exit Policy Syntax and Structure
Tor's exit policy in torrc uses accept/reject rules evaluated in order, similar to a firewall ACL. Format: ExitPolicy accept/reject *|IP|CIDR:port|port-range. The default if no ExitPolicy is configured: reject *:* (not an exit relay at all). To become an exit relay, configure an ExitPolicy accepting outbound connections. Example full exit policy: ExitPolicy accept *:80, ExitPolicy accept *:443, ExitPolicy reject *:*. This allows HTTP and HTTPS to any destination. The final ExitPolicy reject *:* is an implicit default - any traffic not matched by earlier accept rules is rejected. Rules are evaluated in order, first match wins. You can accept specific destination CIDRs: ExitPolicy accept 10.0.0.0/8:80 accepts HTTP only to RFC-1918 private ranges (useful for testing, not production).
The Reduced Exit Policy
The Tor Project publishes a recommended reduced exit policy for operators who want to run an exit relay while minimizing abuse exposure. The reduced exit policy accepts only essential internet services: HTTP (80), HTTPS (443), IMAP/POP3/SMTP for email (143, 587, 465, 993, 995), XMPP for chat (5222, 5269), and a few others while blocking high-abuse ports (25 for SMTP spam, 137-139 for SMB/Windows file sharing, 1194 for VPN, 6881-6999 for BitTorrent). The reduced exit policy is documented at the Tor Project wiki. It represents a balance between contributing significant value (HTTPS/HTTP exit traffic is the majority of Tor usage) and avoiding the high-abuse port ranges that generate the most complaints. Implement by copying the reduced exit policy lines from the Tor Project wiki into torrc.
High-Risk Port Considerations
Certain ports generate disproportionate abuse relative to their legitimate use on Tor. Port 25 (SMTP): almost all Port 25 exit traffic is spam. Reject it: ExitPolicy reject *:25. Port 6881-6999 (BitTorrent): high bandwidth usage and significant DMCA exposure. Reject: ExitPolicy reject *:6881-6999. Port 139, 445 (SMB): exploit activity, Samba attacks. Reject: ExitPolicy reject *:139, ExitPolicy reject *:445. Port 23 (Telnet): brute force attempts against legacy systems. Port 3389 (RDP): brute force against Windows servers. Port 1194 (OpenVPN), 1723 (PPTP): VPN establishment over Tor is unusual and can be abused. For most exit operators, accepting ports 80, 443, 6667 (IRC), 22 (SSH with caveats about brute force), and the email ports provides significant value while avoiding the highest-abuse categories.
Responding to Abuse Reports
Exit relay operators receive abuse reports when Tor traffic through their relay triggers destination server complaint systems. Common abuse types: port scanning (automated complaint systems), DMCA notices (BitTorrent, copyright material downloads), SSH brute force attempts (automated scanners). Response procedure: for automated complaints about your exit relay's IP being used for port scanning or malicious activity: respond with a factual explanation that the IP is a Tor exit relay and include a link to torproject.org/relay. Many security teams and ISPs have developed standard procedures for Tor exit relay complaints and resolve them quickly with this explanation. For DMCA notices regarding BitTorrent: if you do not allow BitTorrent ports, explain this in your response. If you do allow BitTorrent ports, consider adding them to your reject policy. The Tor Project provides a DMCA response template and FAQ for exit relay operators.
Hosting Provider Selection for Exit Relays
Not all VPS providers allow exit relay operation. The Tor relay operator wiki maintains the good-bad-isps.md list documenting which providers explicitly permit or prohibit exit relays. Providers with documented exit relay support: OVHcloud (certain plans), Leaseweb (Netherlands), Frantech Solutions (BuyVM), some Iceland-based providers. Providers that have historically terminated relay accounts: major cloud providers (AWS, Google Cloud, Azure) prohibit exit relay operation in their terms of service. Before deploying an exit relay: review the provider's TOS for language about 'proxy services', 'TOR', or 'anonymization services'. Some providers explicitly permit relays; others prohibit the activity even without mentioning Tor specifically. Contact the provider's support team if unclear.
Related Services
Why Anubiz Host
100% async — no calls, no meetings
Delivered in days, not weeks
Full documentation included
Production-grade from day one
Security-first approach
Post-delivery support included
Ready to get started?
Skip the research. Tell us what you need, and we'll scope it, implement it, and hand it back — fully documented and production-ready.