979.

Aggressive caching for a Mastodon reverse proxy: what to cache, what to never cache, and why content negotiation will eventually betray you

it-notes.dragas.net/2026/06/05/aggressive_caching_for_a_mastodon_reverse_proxy

This post discusses configuring an nginx reverse proxy for a Mastodon instance, emphasizing the need to handle Mastodon’s unique characteristics, such as serving multiple representations on the same URLs. The configuration prioritizes caching static assets and dynamic pages while bypassing caching for private, authenticated, or actor-dependent content. The use of a variant map in the cache key ensures correct content delivery based on the Accept header, preventing issues like browsers receiving JSON and federated instances receiving HTML.

Mastodon caching is configured to optimize performance while ensuring security and privacy. GET and HEAD requests are cacheable, while others, including API calls and logged-in traffic, bypass the cache. Specific request profiles are defined for different types of content, with varying cache validations and locking mechanisms to manage backend load and data consistency.

The Nginx configuration optimizes caching for a Mastodon instance. It uses a 10-second TTL for dynamic content, a failover mechanism for upstream servers, and a custom log format for performance monitoring. The configuration also includes considerations for caching signed GETs, handling cookies, and managing variant-specific content.

Mastodon benefits from a reverse proxy that caches requests, as it can handle the varying interpretations of URLs for different clients, reducing load without impacting user experience.