When working with Nginx configuration files, you might encounter location blocks prefixed with an @ symbol like this:

location @fallback {
    proxy_pass http://backend;
}

This isn't some obscure undocumented feature - it's actually a powerful Nginx construct with specific functionality.

The @ symbol defines a named location block, which differs from regular location blocks in several key ways:

• Cannot be accessed directly by clients (no URI matching)
• Can only be accessed via internal directives (try_files, error_page, etc.)
• Don't participate in normal location selection

Here are three common scenarios where named locations shine:

1. Fallback Handlers

location / {
    try_files $uri $uri/ @php;
}

location @php {
    fastcgi_pass php:9000;
    include fastcgi_params;
}

2. Custom Error Pages

error_page 404 = @notfound;

location @notfound {
    return 301 /404.html;
}

3. Complex Routing Logic

location /api {
    try_files $uri @validate_request;
}

location @validate_request {
    # Auth and validation logic
    if ($invalid) {
        return 403;
    }
    proxy_pass http://backend;
}

• Named locations must be defined in the same context as they're used
• They inherit the configuration from the surrounding context
• You can chain multiple named locations if needed
• No regex or prefix matching applies to named locations

Named locations are processed at configuration time and add virtually no runtime overhead. They're actually more efficient than using rewrite rules for similar functionality.

The Nginx documentation refers to these as "named location" blocks in the official location documentation.

While working with Nginx configurations, you might encounter location blocks prefixed with the at-sign "@" symbol. This isn't a variable declaration, but rather a special syntax for creating named locations - internal request handling points that can't be accessed directly by clients.

The syntax is straightforward:

location @name {
    # your configuration here
}

Key characteristics of named locations:

• Can only be accessed internally via directives like try_files, error_page, or rewrite
• Never match against client requests directly
• Often used as fallback handlers or for specific internal redirections

1. Fallback Handling with try_files

This is the most common application:

location / {
    try_files $uri $uri/ @fallback;
}

location @fallback {
    proxy_pass http://backend;
    # Additional proxy settings...
}

2. Custom Error Pages

Named locations work exceptionally well for error handling:

error_page 404 = @not_found;

location @not_found {
    return 301 /error-page.html;
}

3. Complex Rewrite Logic

For multi-step URL processing:

location /api {
    try_files $uri @api_processing;
}

location @api_processing {
    rewrite ^/api/(.*)$ /process.php?request=$1 last;
}

• Named locations must be defined within the same server block where they're used
• They don't inherit configuration from regular locations
• Can't be used with alias directive
• Performance impact is negligible as they're resolved at configuration load time

Here's a sophisticated implementation for maintenance scenarios:

location / {
    if (-f /var/www/maintenance.on) {
        return 503;
    }
    try_files $uri $uri/ @backend;
}

error_page 503 @maintenance;

location @maintenance {
    root /var/www/maintenance;
    try_files /maintenance.html =503;
}

location @backend {
    proxy_pass http://app_server;
    include proxy_params;
}