Tor Technical

Reverse Proxy Setup for Tor Hidden Services

A reverse proxy between Tor and your application provides additional security, caching, load balancing, and protocol handling. Rather than exposing your application directly to the Tor daemon, you place Nginx or HAProxy in between — enabling features like WebSocket proxying, response compression, static file caching, and request filtering that improve both performance and security.

Need this done for your project?

We implement, you ship. Async, documented, done in days.

Start a Brief

Nginx as Reverse Proxy for Tor

Use Nginx as a reverse proxy to forward Tor traffic to your application while adding caching, compression, and security headers:

# /etc/nginx/sites-available/onion-proxy
upstream backend {
    server 127.0.0.1:3000;
    keepalive 32;
}

server {
    listen 127.0.0.1:8080;

    # Compression — reduces data over Tor circuits
    gzip on;
    gzip_types text/plain text/css application/json application/javascript;
    gzip_min_length 256;

    # Proxy headers
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP "";
    proxy_set_header X-Forwarded-For "";
    proxy_set_header X-Forwarded-Proto http;

    # Timeouts tuned for Tor latency
    proxy_connect_timeout 30s;
    proxy_read_timeout 120s;
    proxy_send_timeout 120s;

    # Static file caching
    location ~* \.(css|js|png|jpg|gif|ico|woff2)$ {
        root /var/www/static;
        expires 30d;
        add_header Cache-Control "public, immutable";
    }

    location / {
        proxy_pass http://backend;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
    }

    access_log off;
    error_log /dev/null;
}

Note the empty X-Real-IP and X-Forwarded-For headers — this prevents your application from seeing any IP address information (all Tor connections come from 127.0.0.1, but stripping these headers is a defense-in-depth measure). Gzip compression is especially valuable for Tor services because it reduces the data that must traverse the high-latency Tor circuit.

WebSocket Proxying Over Tor

If your application uses WebSockets (common for chat applications, real-time dashboards, or collaborative tools), configure the reverse proxy to handle the protocol upgrade:

# WebSocket proxy configuration
location /ws {
    proxy_pass http://backend;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";

    # Extended timeouts for persistent connections
    proxy_read_timeout 3600s;
    proxy_send_timeout 3600s;
}

# Alternative: HAProxy for WebSocket
# haproxy.cfg
frontend tor_frontend
    bind 127.0.0.1:8080
    default_backend web_backend

backend web_backend
    option http-server-close
    option forwardfor except 127.0.0.1
    server app1 127.0.0.1:3000 check
    timeout tunnel 3600s

WebSocket connections over Tor tend to have higher latency but work reliably. Set generous read/write timeouts (3600 seconds or more) to prevent the proxy from closing idle WebSocket connections. Tor circuits are long-lived by default, so the underlying transport supports persistent connections well.

Load Balancing Multiple Backends

For high-availability .onion services, configure the reverse proxy to distribute requests across multiple application backends:

# Nginx upstream with health checks
upstream app_backends {
    least_conn;
    server 127.0.0.1:3001 max_fails=3 fail_timeout=30s;
    server 127.0.0.1:3002 max_fails=3 fail_timeout=30s;
    server 127.0.0.1:3003 max_fails=3 fail_timeout=30s;
    keepalive 64;
}

server {
    listen 127.0.0.1:8080;

    location / {
        proxy_pass http://app_backends;
        proxy_next_upstream error timeout http_500 http_502;
        proxy_next_upstream_tries 3;
    }
}

The least_conn algorithm routes new connections to the backend with the fewest active connections, which works well for Tor traffic where connection duration varies widely. Combined with proxy_next_upstream, failed requests are automatically retried on a healthy backend, providing transparent failover.

This approach differs from OnionBalance in that all backends run on the same server. For true distributed load balancing across multiple servers, use OnionBalance with the reverse proxy pattern on each backend node.

AnubizHost — Optimized Tor Reverse Proxy Hosting

AnubizHost servers come with Nginx pre-installed and optimized for reverse proxy use with Tor hidden services. Our configurations include gzip compression, connection pooling, and security hardening tuned specifically for .onion traffic patterns.

Our offshore infrastructure in Iceland, Romania, and Finland provides privacy-friendly jurisdictions with high-performance hardware. Pay with Bitcoin, Monero, or other cryptocurrencies — no KYC, no identity verification. Whether you need simple reverse proxying or advanced load-balanced architectures, AnubizHost provides the performance and privacy your .onion service demands.

Why Anubiz Labs

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.

Support Chat

Online