This document is an introduction to nginx caching strategy.
Table of Contents
Nginx Cache Introduction
What is Nginx HTTP Cache
Nginx HTTP cache is a mechanism used to temporarily store static resources requested by clients (such as images, CSS, JavaScript files, etc.) in order to improve the server’s response speed and reduce bandwidth consumption. Caching can significantly enhance user experience by allowing faster resource retrieval while easing the load on the server. Nginx HTTP caching can be classified into two main types:
Browser Cache:
Browser cache means that resources are stored in the client’s browser or local device. When a client requests a resource for the first time, the server sends the resource along with HTTP headers such as Cache-Control and Expires, which instruct the browser how long the resource can be cached. Within this period, the browser retrieves the resource directly from the local cache without contacting the server again.
Server Cache:
Server cache refers to resources being stored on the Nginx server itself. This is usually implemented via the Nginx proxy_cache module. When a client requests a resource and a cached copy already exists on the Nginx server, it directly serves the cached resource instead of fetching it from the origin server. This can greatly reduce server response time and load. Key configuration directives for server cache include:
proxy_cache_path: Sets the storage path and other parameters for cache data.proxy_cache: Specifies the cache zone to use.proxy_cache_key: Defines how to generate the cache key.proxy_cache_valid: Sets the caching duration for different HTTP status codes.
Browser cache configuration is typically controlled in the server response via HTTP headers, for example:
Cache-Control: Specifies caching behavior and maximum expiration time.Expires: Specifies the expiration time of the resource.EtagandLast-Modified: Used to verify the freshness of the cache.
Configuring Negotiated Cache / Strong Cache / No Cache (Frontend Practice)
Nginx Configuration for Negotiated Cache
Frontend negotiated cache (also known as conditional caching) involves using HTTP response headers to instruct the browser how to cache content. The main headers used include Cache-Control, Expires, ETag, and Last-Modified. Below is how you can configure these headers in Nginx:
Cache-Control
The Cache-Control response header is the most commonly used caching control directive. It allows you to specify how the resource is cached and its maximum age.
server {
location / {
root /usr/share/nginx/html;
index index.html index.htm;
# Set Cache-Control header to allow caching for 2 days
add_header Cache-Control "public, max-age=172800";
}
}Expires
The Expires header specifies the exact date/time when the resource will be considered stale. Once expired, browsers will request a fresh version from the server.
server {
location / {
root /usr/share/nginx/html;
index index.html index.htm;
# Set resource expiration time to 1 day later
expires 24h;
}
}ETag
The ETag header provides a specific version identifier for a resource. When the resource is updated, the ETag value changes. Browsers use this to validate whether the cached content is still current.
server {
location / {
root /usr/share/nginx/html;
index index.html index.htm;
# Enable ETag
etag on;
}
}Last-Modified
The Last-Modified header indicates the last time the resource was modified. Similar to ETag, it is used to verify the freshness of the cache.
server {
location / {
root /usr/share/nginx/html;
index index.html index.htm;
# Nginx sets Last-Modified header by default
}
}Combined Configuration Example
You can combine various caching strategies in a single configuration to improve efficiency and ensure content freshness.
server {
location / {
root /usr/share/nginx/html;
index index.html index.htm;
# Caching configuration
add_header Cache-Control "public, max-age=172800";
expires 24h;
etag on;
# When content changes, use different ETag or Last-Modified to notify the browser to update the cache
}
}With such configuration, you can effectively control the browser caching behavior, enhance website access speed, reduce the load on your server, and save bandwidth. In actual deployment, adjust the caching durations and strategies based on your website content and user requirements.
Configuring Strong Cache in Nginx
In Nginx, implementing strong (or “force”) caching for the frontend relies primarily on the Cache-Control and Expires HTTP headers. Strong cache ensures that clients (e.g., browsers) serve content directly from the local cache without contacting the server until the cache expires. This can significantly improve page load speeds and reduce server load. Below is how to configure strong caching in Nginx:
Enable Strong Cache in Nginx
Use the Cache-Control header to specify the maximum age (max-age) and whether the cache is public or private.
server {
location /static/ {
root /usr/share/nginx/html;
index index.html index.htm;
# Strong cache setting: cache resources for 1 year
add_header Cache-Control "public, max-age=31536000";
}
}The above configuration applies strong caching for resources (such as CSS, JavaScript, images, etc.) under /static/, with a cache period of one year.
Using the Expires header provides an explicit HTTP date after which the resource is considered expired. While Cache-Control’s max-age is generally prioritized, both work in tandem.
server {
location /assets/ {
root /usr/share/nginx/html;
index index.html index.htm;
# Set resource expiration to 30 days later
expires 30d;
}
}Configuring No Cache in Nginx
To configure Nginx so that clients (browsers) do not cache content—ensuring each request fetches the latest resource from the server—you can use Cache-Control and Expires headers.
Set Cache-Control
Through the Cache-Control header, you can specify directives such as no-cache, no-store, or must-revalidate to prevent caching.
no-cache: Forces the browser to validate the cached content with the server before using it.no-store: Completely disables caching; every request must fetch new content.must-revalidate: Instructs the browser that once the cache expires, a validation with the server is required.
Configuration example:
server {
location / {
root /usr/share/nginx/html;
index index.html index.htm;
# Completely disable caching
add_header Cache-Control "no-store, no-cache, must-revalidate, max-age=0";
add_header Pragma "no-cache";
add_header Expires "0";
}
}Set Expires
By setting the Expires header to a past date, you can instruct the browser that the content is already expired and should not be cached.
server {
location / {
root /usr/share/nginx/html;
index index.html index.htm;
# Set resource expiration to a past date
expires -1;
}
}Combined Configuration
Typically, using a combination of Cache-Control, Pragma, and Expires headers is the most effective way to ensure that the content is not cached by the browser:
server {
location / {
root /usr/share/nginx/html;
index index.html index.htm;
# Completely disable caching
add_header Cache-Control "no-store, no-cache, must-revalidate, proxy-revalidate, max-age=0";
add_header Pragma "no-cache";
add_header Expires "0";
}
}Notes
- Performance Impact: Disabling caching increases server load because every request must be processed by the server instead of being served from the browser cache.
- Suitable Scenarios: This configuration is typically used in development environments or in applications where content freshness is critical (for example, stock trading platforms).
By applying these configurations, you can control how Nginx manages caching on both the client and server sides, enhancing website performance and ensuring content is delivered as required.