Caching Strategies for High-Traffic Tor Hidden Services

The most efficient cache is the user's own browser. Configure aggressive HTTP caching headers for static assets in your hidden service's web server configuration. Set Cache-Control: public, max-age=31536000 for immutable static assets (versioned JS/CSS/images). Use Cache-Control: public, max-age=86400 for assets that change rarely. For dynamic content, set appropriate ETags and Last-Modified headers to enable conditional requests (304 Not Modified) that save bandwidth even when caches expire. Properly configured browser caching means repeat visitors only download changed assets, with Tor circuits needed only for changed content rather than all assets on each page load.

Between the Tor hidden service listener and the backend application, a reverse proxy cache dramatically reduces load. Nginx's fastcgi_cache or proxy_cache modules cache responses from backend applications. Configure a cache zone in tmpfs: proxy_cache_path /dev/shm/nginx_cache levels=1:2 keys_zone=hidden_cache:10m max_size=2g; Set appropriate cache keys and cache times for different URL patterns. For a WordPress or similar CMS, cache full-page HTML for anonymous visitors (users not logged in) for 1-60 minutes depending on content update frequency. Dynamic user-specific content (logged-in views, shopping carts) must bypass the cache. Varnish provides more sophisticated cache logic through VCL for complex caching requirements.

Database queries are a major source of latency on dynamic hidden services. Redis running as an in-memory cache for expensive database queries eliminates repeated database hits for the same data. Cache frequently accessed but infrequently changing data: forum thread listings, user profiles, site configuration. Set TTL values based on how often data changes - thread listings might be cached 30 seconds, user profiles 5 minutes, site configuration 1 hour. Use Redis's hash structures to cache query result sets. Monitor Redis hit rates through the INFO stats command - a hit rate below 80% indicates cache key design needs improvement. Redis in-process latency is microseconds compared to 1-10ms database queries, providing massive speedup for cached paths.

For content-focused hidden services (news sites, wikis, documentation), static site generation eliminates backend processing entirely for each request. Jekyll, Hugo, or Gatsby generate full HTML files that Nginx serves directly. Combined with a Tor hidden service pointing to Nginx serving a static site, the only latency is Tor circuit traversal plus file read time - no application code, no database queries. Content updates require regenerating the site (typically 1-60 seconds for static site builds), which can be automated via CI/CD pipeline triggered by content changes. The performance improvement over dynamic generation is so significant that many onion sites benefit from converting to static generation even at the cost of some dynamic functionality.

High-traffic hidden services benefit from separating concerns across tiers: Tor hidden service process, reverse proxy/cache, application servers, and database. The hidden service process (tor) handles the onion routing and decryption but passes HTTP to Nginx over a Unix socket or loopback. Nginx handles SSL termination, rate limiting, and caching of responses. Application servers (Node.js, PHP-FPM, Python WSGI) handle dynamic requests that miss cache. Database handles persistent storage. This separation allows each tier to be scaled independently - multiple application server instances behind Nginx load balancing for compute-intensive operations, while the Tor process remains single-threaded. Connection between the Tor process and Nginx uses a Unix socket for minimal overhead.