Nginx Static-Dynamic Separation: Principles, Architecture & Practical Configuration

What Is Static-Dynamic Separation

Static-dynamic separation divides service responsibilities by request content and processing method:

Static resources : Do not require real-time generation per user or business state — examples include images, CSS, JavaScript, font files, and videos.

Dynamic requests : Require business logic execution or data queries — examples include user authentication, order processing, search, and personalized pages.

Nginx Static-Dynamic Separation Principle

Client requests reach Nginx first. Nginx selects a handling path based on domain, URI, file type, request method, and other rules.

The core routing logic:

Request enters Nginx
|
v
Match location
|
├── Static path → Find file → Return content
|
└── API path → Proxy to backend → Forward backend response

For static requests, Nginx uses root or alias directives to locate files and returns them directly. Because Nginx excels at handling massive concurrent connections and file transfers, this offloads static content processing from application servers.

For dynamic requests, Nginx typically uses proxy_pass to forward requests to backend services, optionally passing client address, original protocol, and other request metadata.

Request Chains

Static Request Chain

Client → Nginx → Static resource server or file directory. In enterprise architectures, a CDN is inserted:

User
|
v
CDN
|
v
Nginx Cluster
|
+-----------------+-----------------+
v                 v
Static Resources  Backend Service Cluster
OSS               Spring Boot / Dubbo / Redis / MySQL
Images/Video
JS/CSS

Users fetch files from the nearest CDN edge node.

Dynamic Request Chain

Client → Nginx → Application Server → Database or other business services.

Practical Nginx Configuration

The following server block demonstrates a complete static-dynamic separation setup:

server {
    listen 80;
    server_name example.com;

    # Static resource directory: /var/www/site/
    location ~* \.(css|js|png|jpg|jpeg|gif|svg|ico|woff2)?$ {
        root /var/www/site;
        expires 7d;
        add_header Cache-Control "public";
        try_files $uri =404;
    }

    # Dynamic API requests forwarded to backend application
    location /api/ {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }

    # Other page requests handled by application
    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

Key directives explained: location ~* \.(css|js|png|...)$ — case-insensitive regex matching common static file extensions. root /var/www/site — maps the URI to the filesystem path. expires 7d — sets Expires and Cache-Control: max-age headers for browser caching. add_header Cache-Control "public" — allows caching by shared caches (CDN, proxies). try_files $uri =404 — serves the file if it exists; otherwise returns 404 without falling back to backend. proxy_pass http://127.0.0.1:8080 — forwards dynamic requests to the upstream application. proxy_set_header directives — preserve original client information (Host, real IP, forwarded chain, protocol) for backend use.

Effectiveness

Static-dynamic separation suits most websites and web applications, especially those with high volumes of image, script, and style requests while needing independent scaling of business processing. With well-designed location rules combined with expires and proxy_cache, backend pressure can be reduced by more than 70%.