Mahdi.Kh
September 21, 2026
Caching means certain requests no longer need to be processed again. In that case, the response stored in the cache is served directly to the user.
Caching means keeping the results of requests (such as HTML files, JSON data, images) for a specific period of time, so that if the same request happens again in the future, it doesn't need to be processed again.
To cache requests, we first use the proxy_cache_path directive to specify a path for storing caches on disk. In this directive, the first parameter specifies the path where caches are stored. The levels parameter is set to 1:2, meaning that, at /var/cache/nginx/, to store each cache file, it first creates a folder with a one-character name, then creates another folder with a two-character name inside it, and finally stores the cache file there.
The keys_zone=my_cache:50m part names the cache zone my_cache and allocates 50 megabytes for storing the cache's metadata. The cache metadata includes information such as cache keys, file paths, and whether something is cached or not.
The max_size=2g part specifies that the maximum cache size on disk is two gigabytes.
The inactive=60m part specifies that if no request to use that cache comes in for up to 60 minutes, that cache is cleared.
By default, when NGINX receives a response from a service called via proxy_pass, it first writes it to a temporary path (usually /var/lib/nginx/tmp) and then moves it to the cache path. Here, use_temp_path=off specifies that this option is turned off, or disabled, which causes it to be written directly to the cache path. This reduces the number of requests on disk and improves performance.
Caches are stored as key-value pairs. Using proxy_cache_key, we specify how cache keys are constructed, and finally, using proxy_cache, we start caching at the path we specified. The proxy_cache_valid directive also specifies the cache's lifetime.
In nginx, whenever a request is received, the key associated with that request is first built according to what we defined in proxy_cache_key, and then it's checked whether a cache exists for it or not. If no cache exists, the request is sent to the backend service, and the result is then cached for use in later requests. But if a cache exists, it's given to the user as the response, and no new request is sent to the backend service.
On the client side, we can use the X-Cache-Status header to tell whether the response we received came from the cache or not. If its value is hit, it means the response came from the cache.
Sometimes there are situations where we don't want requests to be cached. In these cases, we can use the proxy_no_cache and proxy_cache_bypass directives as follows:
In the example above, using the set directive, we created a variable named $skip_cache. (Variable names in nginx start with a dollar sign, $.) We set this variable's initial value to 0. Then we wrote an if directive that checks whether a part named /dashboard is found in the request, and if so, sets the variable's value to 1.
The proxy_cache_bypass directive specifies when a response to a request should not be read from the cache. If we pass this directive a value that isn't 0 or an empty string (a zero-length string), this directive is triggered, and the response to the request isn't read from the cache.
The proxy_no_cache directive specifies when a response to a request should not be stored in the cache. If we pass this directive a value that isn't 0 or an empty string (a zero-length string), this directive is triggered, and the response to the request isn't stored in the cache.
Previous part: Traffic Management | Nginx from Scratch
Next part: Redirect and Rewrite | Nginx from Scratch