Purging cached content in Nginx - Step-by-Step Execution

Process Flow - Purging cached content

Client sends PURGE request

↓

Nginx receives PURGE request

↓

Check if PURGE allowed

↓

Remove cached [Return 403 Forbidden

↓

Return 200 OK

↓

Client receives confirmation

The client sends a PURGE request to nginx, which checks permission, deletes cached content if allowed, and confirms the purge.

Execution Sample

Nginx

location / {
    proxy_cache mycache;
}

location ~ ^/purge(/.*) {
    allow 127.0.0.1;
    deny all;
    proxy_cache_purge mycache $1;
}

This config allows purging cached content for requests from localhost only.

Process Table

Step	Action	Request Type	Cache State	Response Code	Notes
1	Client sends PURGE request to /purge/index.html	PURGE	Cache has /index.html	N/A	Start purge process
2	Nginx checks client IP	PURGE	Cache has /index.html	N/A	Client IP 127.0.0.1 allowed
3	Nginx checks if PURGE method allowed	PURGE	Cache has /index.html	N/A	Allowed for /purge/ location
4	Nginx removes /index.html from cache	PURGE	Cache missing /index.html	N/A	Cache entry deleted
5	Nginx returns 200 OK to client	PURGE	Cache missing /index.html	200	Purge successful
6	Client receives 200 OK	PURGE	Cache missing /index.html	200	Client confirms purge
7	Client sends PURGE request from disallowed IP	PURGE	Cache has /index.html	403	Access denied, cache intact
8	Client sends normal GET request for /index.html	GET	Cache missing /index.html	200	Cache miss, content fetched from origin

💡 Purge stops when cache entry is removed or access denied.

Status Tracker

Variable	Start	After Step 4	After Step 7	After Step 8
Cache State	Contains /index.html	Does not contain /index.html	Contains /index.html	Does not contain /index.html

Key Moments - 3 Insights

Why does the PURGE request from a disallowed IP get denied?

Because nginx checks client IP against allowed list (see execution_table step 7) and denies with 403 if not allowed.

What happens to the cache after a successful PURGE?

The cached content is removed (execution_table step 4), so subsequent GET requests will fetch fresh content.

Why does a GET request after PURGE result in a cache miss?

Because the cached content was deleted by PURGE (step 4), so GET must fetch from origin (step 8).

Visual Quiz - 3 Questions

Look at the execution_table, what is the response code returned after a successful PURGE?

A 403

B 200

C 404

D 500

💡 Hint

Check step 5 and 6 in the execution_table where PURGE succeeds.

At which step does nginx remove the cached content?

A Step 2

B Step 7

C Step 4

D Step 8

💡 Hint

Look for the step describing cache deletion in the execution_table.

If the client IP is not allowed, what happens to the cache?

A Cache remains intact

B Cache is deleted

C Cache is refreshed

D Cache is corrupted

💡 Hint

See step 7 where PURGE is denied and cache state is unchanged.

Concept Snapshot

PURGE cached content in nginx:
- Client sends PURGE request to nginx
- Nginx checks client IP and permissions
- If allowed, nginx deletes cached content
- Returns 200 OK on success, 403 if denied
- Subsequent GET requests fetch fresh content if cache purged

Full Transcript

Purging cached content in nginx involves the client sending a PURGE request to nginx. Nginx first checks if the client IP is allowed to perform PURGE. If allowed, nginx deletes the cached content for the requested URI and returns a 200 OK response. If not allowed, nginx returns a 403 Forbidden response and the cache remains unchanged. After a successful purge, subsequent GET requests will miss the cache and fetch fresh content from the origin server.