Cache validity rules in Nginx - Step-by-Step Execution

Process Flow - Cache validity rules

Request Received

↓

Check Cache

↓

Is Cached Content Present?

No→Fetch from Origin

Yes↓

Check Cache Validity Rules

↓

Expires?

↓

Is Cache Valid?

No→Fetch from Origin

Yes↓

Serve Cached Content

↓

End

The flow shows how nginx checks if cached content is present and valid using cache validity rules before serving or fetching fresh content.

Execution Sample

Nginx

proxy_cache_path /data/nginx/cache keys_zone=mycache:10m;
proxy_cache_key "$scheme$request_method$host$request_uri";
proxy_cache_valid 200 302 10m;
proxy_cache_valid 404 1m;

This config sets cache storage, cache key, and cache validity times for HTTP status codes 200, 302, and 404.

Process Table

Step	Cache Status	HTTP Status	Cache Validity Rule	Cache Valid?	Action
1	No cache entry	-	-	N/A	Fetch from origin
2	Cache entry present	200	proxy_cache_valid 200 302 10m	Yes (within 10m)	Serve cached content
3	Cache entry present	200	proxy_cache_valid 200 302 10m	No (expired)	Fetch from origin
4	Cache entry present	404	proxy_cache_valid 404 1m	Yes (within 1m)	Serve cached content
5	Cache entry present	404	proxy_cache_valid 404 1m	No (expired)	Fetch from origin
6	Cache entry present	500	No cache validity rule	No	Fetch from origin

💡 Execution stops when content is served from cache or fetched fresh due to cache miss or expiry.

Status Tracker

Variable	Start	After Step 2	After Step 3	After Step 4	After Step 5	After Step 6
Cache Entry Present	No	Yes	Yes	Yes	Yes	Yes
HTTP Status	-	200	200	404	404	500
Cache Validity	-	Valid (within 10m)	Expired	Valid (within 1m)	Expired	No rule
Action Taken	-	Serve cache	Fetch origin	Serve cache	Fetch origin	Fetch origin

Key Moments - 3 Insights

Why does nginx fetch from origin when HTTP status is 500 even if cache entry exists?

Because there is no cache validity rule defined for status 500, nginx treats the cache as invalid and fetches fresh content (see execution_table step 6).

What happens if cached content for status 200 is older than 10 minutes?

Nginx considers the cache expired and fetches fresh content from origin (see execution_table step 3).

How does nginx decide cache validity for different HTTP statuses?

It uses proxy_cache_valid directives specifying time durations per status code (see execution_sample and execution_table steps 2,4).

Visual Quiz - 3 Questions

Look at the execution_table, what action does nginx take at step 4 when HTTP status is 404 and cache is valid?

A Serve cached content

B Fetch from origin

C Ignore cache and serve error

D Delete cache entry

💡 Hint

Check the 'Action' column in execution_table row for step 4.

At which step does the cache expire for HTTP status 200?

A Step 2

B Step 5

C Step 3

D Step 6

💡 Hint

Look at 'Cache Valid?' column for HTTP status 200 in execution_table.

If you add 'proxy_cache_valid 500 5m;' how would step 6 change?

A Cache would be deleted immediately

B Cache would be considered valid for 5 minutes

C Cache would still be invalid

D No change in behavior

💡 Hint

Refer to how proxy_cache_valid rules affect cache validity in execution_table.

Concept Snapshot

nginx cache validity rules:
- Use proxy_cache_valid to set cache time per HTTP status
- Cached content served only if valid
- Expired or missing cache triggers origin fetch
- No rule means no caching for that status
- Helps control freshness of cached responses

Full Transcript

This visual execution shows how nginx handles cache validity rules. When a request arrives, nginx checks if cached content exists. If no cache is present, it fetches fresh content from the origin server. If cache exists, nginx checks validity based on HTTP status and proxy_cache_valid rules. For example, status 200 and 302 are cached for 10 minutes, 404 for 1 minute. If cached content is valid, nginx serves it directly. If expired or no rule applies, nginx fetches fresh content. This process ensures users get fresh content while benefiting from caching when possible.