etag on;
add_header Cache-Control "public, max-age=2592000, must-revalidate";
expires 30d;
This setting is great for assets like JavaScript, CSS, and images that don't change often but might still require updates occasionally.
The max-age directive sets a 30-day cache duration, ensuring these resources can be cached by browsers and intermediate caches (e.g., CDNs).
However, the must-revalidate directive ensures the client checks with the server for a fresh version once the cache expires, preventing
stale data from lingering unnecessarily.
When to use? For files that might need updates but don't need constant revalidation during their validity period.
etag on;
add_header Cache-Control "public, max-age=7776000, stale-while-revalidate=432000, stale-if-error=432000, immutable";
expires 90d;
This setting is tailored for static files that almost never change, like versioned assets (style.v1.css, script.v2.js). The immutable
directive tells browsers the file won't change, allowing them to skip revalidation entirely. The stale-while-revalidate and stale-if-error
directives provide an extra safety net: users can keep serving the cached version for up to 5 days while a revalidation is happening
or if the server is temporarily unavailable.
When to use? For versioned or rarely updated files, providing a more aggressive and efficient caching strategy.
etag off;
add_header Cache-Control 'no-cache, no-store, must-revalidate';
expires off;
This configuration disables caching entirely, forcing the browser to fetch a fresh version of the resource every time. This is ideal for dynamic content or sensitive data, ensuring no stale copies remain in caches.
When to use? For pages or APIs with frequently changing data or sensitive user information (e.g., dashboards, login forms).
gzip on;
gzip_disable "msie6";
gzip_vary on;
gzip_proxied any;
gzip_comp_level 6;
gzip_buffers 16 8k;
gzip_http_version 1.1;
gzip_min_length 256;
gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript application/x-font-ttf font/opentype;
This gzip configuration enables efficient compression for text-based and web-critical file types, improving page load times while balancing
server performance. Compression is turned on with a moderate level (gzip_comp_level 6) to reduce file sizes without excessive CPU usage. It
ensures compatibility with modern browsers by targeting HTTP/1.1 and disabling gzip for outdated clients like IE6. The gzip_vary directive
allows proxies to differentiate between compressed and uncompressed responses, while gzip_proxied ensures compression is applied even for
proxied requests. To avoid compressing files that are too small to benefit, a minimum size of 256 bytes is set. Common text and font MIME
types are explicitly included, ensuring effective compression for critical resources like stylesheets, scripts, and JSON responses.
brotli on;
brotli_comp_level 5;
brotli_buffers 16 8k;
brotli_min_length 256;
brotli_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript application/x-font-ttf font/opentype;
This setup enables Brotli compression, which often achieves better compression ratios than gzip for text-based assets. The compression level is set to 5, balancing performance and resource usage. It targets the same file types as the gzip example, ensuring stylesheets, scripts, and JSON are compressed efficiently. Brotli is ideal for modern browsers, as it provides better results but is not universally supported like gzip.
ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers on;
ssl_ciphers "TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256";
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 1d;
ssl_session_tickets off;
ssl_stapling on;
ssl_stapling_verify on;
resolver 8.8.8.8 1.1.1.1;
This configuration enforces modern protocols (TLSv1.2 and TLSv1.3) and uses strong ciphers that prioritize security and performance.
ssl_stapling and ssl_stapling_verify are enabled to speed up certificate verification. Session tickets are disabled for better forward
secrecy, and a shared session cache improves performance for repeat connections. The trusted resolver is included to ensure proper validation of OCSP responses.
When to use? For modern applications targeting up-to-date browsers and clients, prioritizing security and performance over backward compatibility.
ssl_protocols TLSv1.3;
ssl_prefer_server_ciphers off;
ssl_ciphers "TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256";
ssl_session_cache shared:SSL:1m;
ssl_session_timeout 1h;
ssl_session_tickets off;
ssl_stapling on;
ssl_stapling_verify on;
resolver 8.8.8.8 1.1.1.1;
This configuration exclusively uses TLSv1.3 for the highest security, eliminating support for older protocols. It disables session tickets and
uses a short session timeout for maximum forward secrecy.
When to use? For high-security applications like banking or government websites that only target modern clients.
ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers on;
ssl_ciphers "ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256";
ssl_session_cache shared:SSL:5m;
ssl_session_timeout 1h;
ssl_session_tickets on;
ssl_stapling off;
This configuration is optimized for API endpoints where performance is key, and the client is typically a modern machine. It enables efficient ciphers and session tickets for faster connections while keeping things secure. OCSP stapling is turned off to reduce latency since APIs rarely benefit from it.
When to use? For public-facing or internal APIs that prioritize performance with modern clients.
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
add_header Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline' https:; style-src 'self' 'unsafe-inline' https:; img-src 'self' data: https:; font-src 'self' https:; object-src 'none'; base-uri 'self'; frame-ancestors 'none';";
add_header X-Frame-Options "DENY";
add_header X-Content-Type-Options "nosniff";
add_header Referrer-Policy "strict-origin-when-cross-origin";
add_header Permissions-Policy "geolocation=(), microphone=(), camera=()";
This setup enforces strict HTTPS requirements with HSTS (Strict-Transport-Security), ensures that content can only be loaded from trusted
sources via Content-Security-Policy, and prevents content embedding using X-Frame-Options. The X-Content-Type-Options header mitigates
MIME-type sniffing vulnerabilities, while Referrer-Policy limits the exposure of referrer information. The Permissions-Policy restrict
unnecessary browser features like geolocation, microphone, and camera access. Together, these headers provide a strong security baseline
for modern web applications, reducing common attack vectors.
When to use? For production web applications that require strong security, especially those handling sensitive data or user input.
add_header Strict-Transport-Security "max-age=31536000" always;
add_header X-Frame-Options "SAMEORIGIN";
add_header X-Content-Type-Options "nosniff";
add_header Referrer-Policy "no-referrer-when-downgrade";
This configuration is optimized for older or legacy applications that cannot fully adopt modern security measures like Content-Security-Policy.
It enforces HTTPS with HSTS, prevents framing except on the same origin using X-Frame-Options, and disables MIME-type sniffing with
X-Content-Type-Options. The referrer policy is slightly relaxed (no-referrer-when-downgrade) for broader compatibility. It's designed to
provide reasonable security without breaking older apps.
When to use? For legacy applications or sites where compatibility constraints limit the use of modern security features.
add_header Strict-Transport-Security "max-age=31536000" always;
add_header X-Content-Type-Options "nosniff";
add_header Referrer-Policy "no-referrer";
add_header Access-Control-Allow-Origin "*";
add_header Access-Control-Allow-Methods "GET, POST, PUT, DELETE, OPTIONS";
add_header Access-Control-Allow-Headers "Content-Type, Authorization";
This configuration is designed for APIs exposed to the public. It enforces HTTPS with HSTS and protects against MIME-type sniffing using
X-Content-Type-Options. The Referrer-Policy ensures that no referrer information is sent with requests, safeguarding client privacy.
Additionally, it includes permissive CORS headers (Access-Control-Allow-*) to allow cross-origin requests from any domain, making it
suitable for APIs accessed by web applications from various origins.
When to use? For public APIs that require cross-origin access, especially in scenarios where privacy and compatibility are concerns.