You need to enable JavaScript to run this app.
优惠活动
大模型
产品
解决方案
定价
更多

将Nginx缓存过期指令加入默认配置是否合理且安全?

Is Moving Cache Expiry Rules to Nginx Default Configuration Safe & Reasonable?

Great question! Let's clear up a common Nginx configuration misconception first, then walk through the right way to solve your duplicate config problem.

First: Why Your Initial Idea Won't Work

Your default sites-available/default is a separate server block marked as default_server—it only handles requests that don't match any other server block's server_name. When a request hits one of your 10 apps (e.g., example.com), Nginx routes it to that app's dedicated server block, and it won't inherit any rules from the default server block. So if you move the cache expiry rule to the default config, your app's static assets won't get the 365-day expiry—because the request never touches the default server block.

The Safe & Reasonable Solutions

To eliminate duplicate cache rules across all apps, you have two solid, production-friendly options:

Option 1: Add the Rule to the Global http Block

This is the simplest approach—any rule defined in the http block applies to all server blocks automatically. Here's how:

  1. Open your main Nginx config file (usually /etc/nginx/nginx.conf)
  2. Add the cache location block inside the http section:
    http {
        # ... existing global config (like log formats, mime types, etc.) ...
    
        # Global static asset caching rule
        location ~* \.(jpg|jpeg|png|gif|ico|css|js|ttf|woff|pdf)$ {
            expires 365d;
        }
    }
    
  3. Test the config with sudo nginx -t and reload Nginx with sudo systemctl reload nginx

Why this works: All your app server blocks inherit this rule, so you can delete the duplicate cache blocks from each sites-available/${domain}.conf. If any app needs a custom cache rule (e.g., shorter expiry for certain assets), just add a matching location block in that app's server block—Nginx will prioritize the server-specific rule over the global one.

Option 2: Create a Reusable Snippet File

If you prefer more control (e.g., some apps might not need the cache rule), create a dedicated snippet and include it in each app's config:

  1. Create a new file: /etc/nginx/snippets/cache-static.conf with your cache rule:
    location ~* \.(jpg|jpeg|png|gif|ico|css|js|ttf|woff|pdf)$ {
        expires 365d;
    }
    
  2. Update each app's server block to include the snippet:
    server {
        root ${drt}/${domain}/;
        server_name ${domain} www.${domain};
        
        # Include the global cache rule
        include snippets/cache-static.conf;
    
        # ... other app-specific config ...
    }
    
  3. Test and reload Nginx as before

Why this works: You keep a single source of truth for the cache rule, and you can easily exclude apps by omitting the include line.

Are These Approaches Safe?

Absolutely! These are standard Nginx best practices:

  • The cache rule only targets static assets (image, CSS, JS, etc.)—it won't interfere with dynamic PHP content (your existing location ~ \.php$ blocks are untouched)
  • Expiring static assets after 365 days is a common optimization that reduces repeat requests to your server, improving performance without risk
  • Both methods make your config easier to maintain—no more editing 10 files just to change a cache expiry time

内容的提问来源于stack exchange,提问作者Arcticooling

相关产品推荐
方舟 Agent Plan

超全模态模型 × Harness 升级,最新支持 Deepseek-V4.1-Flash、GLM-5.3 系列、Doubao-Seedream-5.0-pro、Kimi-K3 (部分), 限时 9.9 元起

最近更新时间:2026.05.19 03:22:25