Share configuration between Nginx locations

Use inheritance, include files, or a shared regex location while preserving correct root, alias, and header behavior.

Best practices
Illustration of server operations and request logs

Use configuration inheritance for settings shared by every location, or an include file for selected locations. A regex location can combine equivalent URL patterns, but it also changes matching behavior and filesystem mapping.

Put genuinely shared settings in the parent

server {
    listen 80;
    root /var/www;
    gzip on;
    add_header Cache-Control "public, max-age=3600";

    location /location1/ { }
    location /location2/ { }
}

Here both locations inherit the root, so /location1/a.css maps to /var/www/location1/a.css. Use this cache header only for content that is safe to share publicly.

Inheritance is directive-specific. Under the default add_header behavior, defining any add_header at a child level replaces the inherited set rather than adding to it. Newer Nginx versions offer additional inheritance controls, so check the documentation for the installed version before relying on one.

Include a shared fragment in selected locations

For static locations, a fragment can contain common policy without fixing their directories:

# /etc/nginx/snippets/shared-static.conf
expires 1h;
access_log /var/log/nginx/static-access.log combined;
location /location1/ {
    alias /var/www/app1/;
    include /etc/nginx/snippets/shared-static.conf;
}
location /location2/ {
    alias /var/www/app2/;
    include /etc/nginx/snippets/shared-static.conf;
}

For PHP, include FastCGI directives inside each actual PHP-handling location. A typical shared fragment includes fastcgi_params, the appropriate fastcgi_pass, and fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;. That filename expression assumes a root-based mapping; do not copy it unchanged into an alias-based application. Restrict PHP execution to existing intended scripts, and never expose uploaded files as executable PHP.

An include behaves as configuration inserted at that position. It does not make a directive legal in a context where the directive is unsupported.

Match equivalent prefixes with one regex

A regex alias must use captures to map the complete requested file:

location ~ ^/(?:location1|location2)/(.+\.(?:css|js|png))$ {
    alias /var/www/shared/$1;
    expires 1h;
}

This example deliberately matches selected static asset extensions rather than every request. Prefix matching may be easier to reason about when applications have different roots or policies.

Choose and verify

Requirement Approach
Same policy for all locations Parent context, if the directive supports it
Same policy for only some locations Shared include
Same mapping for a precise set of URL patterns One regex location

Test the configuration, reload, and request both routes. Compare headers, status codes, and the served content; testing one route does not validate the other.

FAQ

Can I put proxy_pass or root in server?

root is valid in http, server, and location and can be inherited. proxy_pass is not valid directly in server; alias belongs in location. They do not share the same context rules.

Can an include define root?

Yes, where root is valid. If each location needs a different directory, keep that setting outside the shared fragment to avoid duplicate or unintended declarations.

Why did my parent's headers disappear?

Check for add_header in the child. With default inheritance, repeat the full required set there or move common headers into a shared fragment used at that level.

References: core directives, header inheritance.

Get a tailored plan

Contact us

Join the community

Scan with WeChat
to join the community

Try Guance

Start online and pay only for what you use.

Get started

Choose a Guance plan

Code hosting