How to optimize Nginx reverse proxy caching for media streaming apps?

Question

Hi everyone,

I am working on a web project where users stream media content, and I want to improve overall performance by fine-tuning Nginx reverse proxy caching layers.

What are the recommended configuration parameters (like proxy_cache_path, inactive timeouts, and cache bypass rules) to handle high-volume requests smoothly on a Linux VPS without overwhelming server memory?

Any best practices or configuration examples would be greatly appreciated. Thanks!

KFSys · Answer

Heya, The first thing worth clearing up is the memory worry, because it changes how you size everything. Nginx doesn’t hold cached bodies in RAM. The keys_zone is a shared-memory zone that only stores cache metadata (keys and object headers), at roughly 8KB per object, while the actual media sits on disk. So a modest keys_zone plus a disk cap is what keeps you safe, not any per-request memory budget. The thing that actually eats RAM on a streaming box is the OS page cache warming up hot segments, and that’s a good thing, not something to fight. A sane base looks like this: proxy_cache_path /var/cache/nginx/media levels=1:2 keys_zone=media_cache:50m max_size=20g inactive=7d use_temp_path=off; keys_zone=50m covers on the order of a few hundred thousand objects, which is the only part living in memory. max_size=20g is your hard disk ceiling, and nginx evicts least-recently-used once it’s hit. inactive=7d drops anything not requested in a week regardless of freshness. use_temp_path=off writes straight into the cache tree instead of staging in a temp dir and copying, which matters when your objects are large. For streaming specifically, the two things that make or break it are range requests and cache stampede. If you’re serving large progressive files or HLS/DASH segments, turn on slicing so nginx caches byte ranges instead of whole files per seek: location /media/ { proxy_pass http://backend; proxy_cache media_cache; proxy_cache_valid 200 206 1d; slice 1m; proxy_cache_key $scheme$proxy_host$uri$is_args$args$slice_range; proxy_set_header Range $slice_range; proxy_http_version 1.1; proxy_cache_lock on; proxy_cache_use_stale updating error timeout; proxy_cache_background_update on; } Caching 206 alongside 200 is the part people forget, and without it range requests bypass the cache entirely. The slice 1m plus $slice_range in the key plus the forwarded Range header is what gives you seekable, per-chunk caching. proxy_cache_lock on is the one that saves you under load: when a hot segment isn’t cached yet and a thousand clients ask for it at once, only one request goes upstream and the rest wait, instead of a thousand identical fetches hammering your origin. use_stale updating plus background update means clients keep getting served while a stale entry refreshes quietly. Manifests are the exception to all of this. Live HLS/DASH playlists (.m3u8 / .mpd) change constantly, so cache them for a few seconds at most or bypass them outright, otherwise clients get stuck on a stale segment list: location ~ \.(m3u8|mpd)$ { proxy_pass http://backend; proxy_cache media_cache; proxy_cache_valid 200 2s; } Same idea for anything per-user or token-gated: use proxy_cache_bypass/proxy_no_cache keyed on the auth cookie so personalized responses never land in a shared cache. Last thing, on storage placement, since it’s where “without overwhelming the server” really lives. Keep the cache dir on fast local disk, and resist the temptation to point it at tmpfs to make it faster, because that’s exactly how you’d blow up your memory with large media. If the cache outgrows the VPS disk, a DigitalOcean Block Storage volume mounted at the cache path lets you bump max_size without resizing the whole VPS, and NVMe-backed local storage is usually plenty fast for segment serving anyway. Watch du on the cache dir and your disk I/O for the first few days and tune max_size/inactive from what you actually see rather than guessing up front.

alexdo · Answer

Heya, Two additional Nginx directives are worth mentioning since they matter specifically for streaming workloads under heavy load. First, proxy_cache_use_stale with the updating parameter. This allows Nginx to continue serving the existing cached copy of a manifest or media segment while it’s fetching a fresh version from the origin. Instead of every concurrent viewer waiting on the same upstream request, they continue receiving the cached object. Combined with proxy_cache_lock (which KFSys already mentioned), this helps prevent a cache stampede when a popular segment expires. Second, open_file_cache. This is separate from proxy_cache_path—it caches file descriptors along with file metadata (stat results), so Nginx doesn’t have to repeatedly open and stat the same cached files on disk. With HLS or DASH, where you’re serving large numbers of small .m3u8, .ts, or .m4s files, this can noticeably reduce filesystem syscall overhead under high concurrency. Since you’re hosting this on a Droplet, it’s also worth considering whether Nginx needs to be responsible for the entire caching layer. If most of your content is VOD or can tolerate a few seconds of cache latency, using a CDN in front of your origin can dramatically reduce load. For example, DigitalOcean Spaces with the CDN enabled is commonly used for HLS delivery—an RTMP server uploads .m3u8 playlists and segment files directly to a Space, and the CDN handles global distribution. It isn’t ideal for true live-edge streaming because CDN cache TTLs introduce some delay, but for VOD or near-live content, it removes a significant amount of cache management and tuning from your VPS. Hope this helps!

masonreed Reed · Answer

Use disk-based caching with a sensible keys_zone, inactive, and max_size. Cache only static/media content, bypass logged-in or dynamic requests, and monitor cache hit rates before tuning further.

Become a contributor for community

DigitalOcean Documentation

Resources for startups and AI-native businesses

The developer cloud

Start building today

Report this

How to optimize Nginx reverse proxy caching for media streaming apps?

Related questions

How can I improve the speed of an e-commerce website?

How to configure Nginx reverse proxy on Ubuntu

How to fix in nginx security config

How to change existing certbot/nginx to wildcard domain?

How do I get Ruby with Hanami to serve dynamic files via Falcon?

Unable to access the URL after deploying Discourse

AstroJS project hosted on DigitalOcean droplet with Nginx – CSS loading as text/html

Setting up a reverse proxy on DigitalOcean App Platform to route main domain and subdomains

using shiny-server with nginx

Django/Nginx/Gunicorn "unknown errors" in nginx logs

Problem running multiple workers with gunicorn/nginx to deploy python/flask web app

Issue with Droplet connecting to GODaddy Domain name

Report this

How to optimize Nginx reverse proxy caching for media streaming apps?

Related questions

How can I improve the speed of an e-commerce website?

How to configure Nginx reverse proxy on Ubuntu

How to fix in nginx security config

How to change existing certbot/nginx to wildcard domain?

How do I get Ruby with Hanami to serve dynamic files via Falcon?

Unable to access the URL after deploying Discourse

AstroJS project hosted on DigitalOcean droplet with Nginx – CSS loading as text/html

Setting up a reverse proxy on DigitalOcean App Platform to route main domain and subdomains

using shiny-server with nginx

Django/Nginx/Gunicorn "unknown errors" in nginx logs

Problem running multiple workers with gunicorn/nginx to deploy python/flask web app

Issue with Droplet connecting to GODaddy Domain name