Named locations (@) in Nginx - Practice Problems & Coding Challenges

Challenge - 5 Problems

💻 Command Output

intermediate

What is the output status code when accessing /test?

Given the following nginx configuration, what HTTP status code will the client receive when requesting /test?

Nginx

server {
    listen 80;
    location /test {
        return 302 @redirect;
    }
    location @redirect {
        return 404;
    }
}

A 404 Not Found

B 200 OK

C 302 Found

D 500 Internal Server Error

💡 Hint

Look at what the named location @redirect returns.

The /test location returns a 302 redirect to the named location @redirect. The @redirect location returns a 404 status, so the client ultimately receives 404 Not Found.

❓ Configuration

intermediate

Which configuration correctly uses a named location to serve a maintenance page?

Select the nginx configuration snippet that correctly uses a named location @maintenance to serve a static maintenance page when /maintenance is requested.

A

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

B

location /maintenance {
    return 302 @maintenance;
}
location @maintenance {
    root /var/www/html;
    try_files /maintenance.html =404;
}

C

location /maintenance {
    rewrite ^ /maintenance.html break;
}
location @maintenance {
    root /var/www/html;
    try_files /maintenance.html =404;
}

D

location /maintenance {
    return 301 /maintenance.html;
}
location @maintenance {
    root /var/www/html;
    try_files /maintenance.html =404;
}

💡 Hint

Named locations are used with return or error_page directives, not proxy_pass.

Option B correctly uses return 302 to redirect to the named location @maintenance, which serves the static file. Proxy_pass cannot target named locations, and rewrite with break does not invoke named locations.

❓ Troubleshoot

advanced

Why does the named location @error not get triggered?

Given this nginx config, why does the named location @error never get used when a 500 error occurs?

server {
    listen 80;
    location / {
        proxy_pass http://backend;
        error_page 500 @error;
    }
    location @error {
        return 503 'Service temporarily unavailable';
    }
}

A The error_page directive must be outside the location block to work with named locations.

B Named locations cannot be used with error_page directives.

C The backend server does not return a 500 error, so @error is never triggered.

D The return directive inside @error is invalid and causes the location to be ignored.

💡 Hint

Check the backend server response and error_page usage.

Named locations can be used with error_page inside location blocks. The return directive is valid. If the backend never returns 500, the named location @error won't be triggered.

🔀 Workflow

advanced

What is the sequence of location processing when using named locations?

Consider this nginx configuration:

location /start {
    return 302 @next;
}
location @next {
    proxy_pass http://backend;
}

What is the correct sequence of processing when a client requests /start?

A Client requests /start → nginx returns 302 redirect to @next → client requests @next → nginx proxies to backend

B Client requests /start → nginx internally redirects to @next → nginx proxies to backend without client redirect

C Client requests /start → nginx returns 200 OK with content from @next location

D Client requests /start → nginx returns 404 because @next is a named location

💡 Hint

Named locations starting with @ are internal and cannot be requested directly by clients.

The return 302 @next sends a redirect response to the client. The client then makes a new request to the URI '@next', which is invalid as a URI, so this is a misconfiguration. However, nginx treats the @next as a named location internally only if used with internal redirects, not with return 302. So the client receives a redirect to '@next' which is invalid. Thus, option A is the closest correct sequence, but in practice this config causes client error.

✅ Best Practice

expert

Which is the best way to use named locations for internal rewrites without client redirects?

You want to internally rewrite requests to /oldpath to a named location @newpath without telling the client to redirect. Which configuration snippet achieves this correctly?

A

location /oldpath {
    proxy_pass @newpath;
}
location @newpath {
    proxy_pass http://backend;
}

B

location /oldpath {
    return 302 @newpath;
}
location @newpath {
    proxy_pass http://backend;
}

C

location /oldpath {
    rewrite ^ /newpath break;
}
location @newpath {
    proxy_pass http://backend;
}

D

location /oldpath {
    error_page 418 = @newpath;
    return 418;
}
location @newpath {
    proxy_pass http://backend;
}

💡 Hint

Use error_page with a custom code to trigger internal named location rewrites.

Option D uses a custom error code 418 to trigger an internal redirect to the named location @newpath without client involvement. Option D sends a client redirect which exposes the named location. Option D rewrites to /newpath which is not a named location. Option D tries to proxy_pass to a named location which is invalid.

Practice

1. What is the main purpose of a named location starting with @ in nginx configuration?

easy

A. To define an internal jump point for request handling

B. To specify a URL accessible by clients

C. To set environment variables for nginx

D. To configure SSL certificates

Solution

1. Step 1: Understand named locations in nginx

   Named locations start with @ and are used internally by nginx to jump to specific blocks of configuration during request processing.

2. Step 2: Differentiate from client-accessible URLs

   Named locations are not accessible directly by clients; they serve as internal routing points.

3. Final Answer:

   To define an internal jump point for request handling -> Option A

4. Quick Check:

   Named location = internal jump point [OK]

Hint: Named locations start with @ and are internal only [OK]

Common Mistakes:

• Thinking named locations are public URLs
• Confusing named locations with environment variables
• Assuming named locations configure SSL

2. Which of the following is the correct syntax to define a named location in nginx?

easy

A. location @named { ... }

B. location /named { ... }

C. named_location @named { ... }

D. location #named { ... }

Solution

1. Step 1: Recall nginx named location syntax

   Named locations are defined using location @name { ... } where @ prefixes the name.

2. Step 2: Check options for correct syntax

   location @named { ... } uses location @named { ... }, which is the correct syntax. Other options use invalid prefixes or keywords.

3. Final Answer:

   location @named { ... } -> Option A

4. Quick Check:

   Named location syntax = location @name [OK]

Hint: Named locations always start with @ in location block [OK]

Common Mistakes:

• Omitting the @ symbol
• Using # or other symbols instead of @
• Using invalid keywords like named_location

3. Given this nginx config snippet:

location / {
  error_page 404 = @fallback;
}

location @fallback {
  return 200 'Fallback reached';
}

What will be the response body if a client requests a non-existing page?

medium

A. 404 Not Found error page

B. Empty response with status 200

C. Fallback reached

D. 500 Internal Server Error

Solution

1. Step 1: Understand error_page directive with named location

   The error_page 404 = @fallback; tells nginx to internally redirect 404 errors to the named location @fallback.

2. Step 2: Analyze the named location response

   The @fallback location returns status 200 with body 'Fallback reached'. So a missing page triggers this response.

3. Final Answer:

   Fallback reached -> Option C

4. Quick Check:

   404 triggers @fallback = 'Fallback reached' [OK]

Hint: error_page 404 = @name redirects internally [OK]

Common Mistakes:

• Expecting default 404 page instead of fallback
• Confusing status codes returned
• Thinking named locations are client URLs

4. Identify the error in this nginx config snippet:

location / {
  error_page 404 = @notfound;
}

location notfound {
  return 404 'Not Found';
}

medium

A. location / block cannot have error_page

B. Named location missing @ prefix

C. return directive cannot use status 404

D. error_page directive syntax is wrong

Solution

1. Step 1: Check named location definition

   The named location referenced is @notfound, but the location block is defined as location notfound without the @.

2. Step 2: Confirm correct named location syntax

   Named locations must start with @, so it should be location @notfound.

3. Final Answer:

   Named location missing @ prefix -> Option B

4. Quick Check:

   Named location must start with @ [OK]

Hint: Named location blocks must start with @ [OK]

Common Mistakes:

• Defining named location without @
• Misusing error_page syntax
• Thinking return 404 is invalid

5. You want to reuse a block of configuration for multiple error codes (404 and 403) using a named location @error_handler. Which configuration correctly achieves this?

hard

A. error_page 404 403 @error_handler {
return 403 'Access denied';
}

B. error_page 404, 403 = @error_handler;

location @error_handler {
return 403 'Access denied';
}

C. error_page 404 403 @error_handler;

location @error_handler {
return 403 'Access denied';
}

D. error_page 404 = @error_handler;
error_page 403 = @error_handler;

location @error_handler {
return 403 'Access denied';
}

Solution

1. Step 1: Understand error_page syntax for multiple codes

   To assign multiple error codes to the same named location, you can use separate error_page directives for each code pointing to the same named location.

2. Step 2: Validate options

   error_page 404 = @error_handler;
   error_page 403 = @error_handler;
   
   location @error_handler {
     return 403 'Access denied';
   }

   correctly uses two error_page lines for 404 and 403, both redirecting to @error_handler. The named location block is defined properly.

3. Final Answer:

   Separate error_page directives for each code pointing to @error_handler -> Option D

4. Quick Check:

   Use separate error_page lines for multiple codes [OK]

Hint: Use separate error_page lines for multiple codes [OK]

Common Mistakes:

• Trying to list multiple codes with = @location in one line
• Incorrect error_page syntax without =
• Defining location block inside error_page