Optimizing Tor Hidden Service Performance for Faster Onion Sites

HTTP/2 multiplexing allows multiple requests to be served over a single Tor circuit, eliminating the per-request circuit setup overhead that makes .onion sites feel slow. nginx supports HTTP/2 natively with simple configuration changes:

server {
    listen 127.0.0.1:8080 http2;
    # ... rest of config
}

HTTP/2 requires TLS in most browsers, but Tor Browser's .onion handling bypasses this requirement through Tor's built-in encryption. Verify HTTP/2 is active by checking nginx error logs for protocol version errors, or use curl -v --proxy socks5h://127.0.0.1:9050 http://YOUR_ONION_ADDRESS/ and look for HTTP/2 in the response headers.

Persistent connection tuning also helps significantly. Configure keepalive settings to maintain circuit connections across multiple requests:

keepalive_timeout 65;
keepalive_requests 100;

Enable gzip compression for all text-based responses. The compression reduces the amount of data transmitted over Tor circuits, directly reducing transfer time for text-heavy pages:

gzip on;
gzip_vary on;
gzip_min_length 1024;
gzip_proxied any;
gzip_comp_level 6;
gzip_types text/plain text/css text/xml application/json application/javascript application/rss+xml application/atom+xml image/svg+xml;

For application servers behind nginx, add aggressive caching headers for static assets. Static files that change infrequently should be cached by Tor Browser for extended periods, eliminating repeat downloads on subsequent visits:

location ~* .(css|js|png|jpg|gif|woff2)$ {
    expires 30d;
    add_header Cache-Control "public, immutable";
}

For dynamic content, implement server-side caching with Redis or memcached. Cache rendered page output for content that changes infrequently. Cache invalidation on publish rather than time-based expiry ensures users always see current content while avoiding repeated computation for every request.

Several torrc settings affect hidden service performance. The NumCPUs directive is the most impactful for high-traffic hidden services, enabling multi-core cryptographic processing:

NumCPUs 4
CircuitBuildTimeout 10
MaxMemInQueues 1024 MB
HiddenServiceMaxStreams 100
HiddenServiceMaxStreamsCloseCircuit 1

HiddenServiceMaxStreams limits the number of simultaneous streams on a single circuit, preventing one heavy client from monopolizing a circuit and degrading response time for other clients. HiddenServiceMaxStreamsCloseCircuit 1 forces circuit closure when the stream limit is reached, ensuring resource cleanup rather than indefinite stream queuing.

For very high traffic hidden services, consider running multiple tor processes with separate HiddenServiceDir instances all serving the same backend, combining with OnionBalance to publish a single combined descriptor. This distributes cryptographic load across multiple processes and potentially multiple CPUs while presenting a single onion address to clients.

Images are typically the largest contributors to page weight on media-rich .onion sites. Serving optimized images reduces bandwidth and load time significantly. Convert images to WebP format where browser support allows, as WebP achieves 25 to 35% smaller file sizes compared to JPEG at equivalent quality:

location ~* .(?:jpg|jpeg|png)$ {
    add_header Vary Accept;
    try_files $uri.webp $uri;
}

Generate WebP variants at build time rather than at request time to avoid runtime conversion overhead. Use imagemagick or cwebp for batch conversion: find /var/www -name "*.jpg" -exec cwebp -q 80 {} -o {}.webp ;

Implement lazy loading for images below the fold. Browser-native lazy loading with the loading="lazy" attribute on img tags delays image requests until the user scrolls to them, reducing initial page load bytes. For .onion sites where users are deliberately patient enough to use Tor, lazy loading significantly improves perceived load time even when total transfer time is similar.

Hidden services with dynamic content typically have a database query on every request. Unoptimized database queries add milliseconds that compound with Tor's inherent latency to produce unacceptably slow page loads. Profile all slow queries with database explain plans and add indexes for columns used in WHERE clauses and JOIN conditions.

Connection pooling prevents the overhead of establishing new database connections on each request. For PostgreSQL, PgBouncer in transaction pooling mode maintains a small pool of persistent database connections that application requests use without the connection setup overhead. For small hidden services, PgBouncer is often the single largest performance improvement available at the application tier.

Implement read replicas for read-heavy applications. A read replica in the same data center as the hidden service handles all SELECT queries while the primary handles writes. This distributes database load and reduces query latency by avoiding write lock contention on read operations. Configure your application to route read queries to the replica and write queries to the primary using application-level database routing or ProxySQL.