Map directive for variable mapping in Nginx - Mini Project: Build & Apply

Map Directive for Variable Mapping in Nginx

📖 Scenario: You are configuring an Nginx web server to serve different content based on the client's IP address range. You want to use the map directive to create a variable that changes its value depending on the client's IP.

🎯 Goal: Build an Nginx configuration that uses the map directive to set a variable called $client_type to internal for IPs in the 192.168.1.0/24 range and external for all other IPs.

📋 What You'll Learn

Create a map block named client_type that maps $remote_addr to internal or external

Define the IP range 192.168.1.0/24 as internal

Set the default value to external

Use the $client_type variable inside the server block

Print the value of $client_type in the response header

💡 Why This Matters

🌍 Real World

In real web servers, the <code>map</code> directive helps customize responses based on client IPs, user agents, or other variables without changing the main server logic.

💼 Career

Knowing how to use <code>map</code> in Nginx is valuable for DevOps engineers and system administrators to implement flexible, efficient server configurations.

1

Create the basic Nginx server block

Write an Nginx configuration with a server block listening on port 8080 and a location / that returns a simple text response.

Nginx

server {
    listen 8080;
    location / {
        return 200 'Hello from Nginx';
    }
}

# Your code here

Hint

Start with a simple server block that listens on port 8080 and returns a text response.

2

Add a map directive to define $client_type

Add a map directive outside the server block that maps $remote_addr to internal for IP range 192.168.1.0/24 and sets the default to external. The variable name must be client_type.

Nginx

map $remote_addr $client_type {
    # Define IP range mapping here
}

server {
    listen 8080;
    location / {
        return 200 'Hello from Nginx';
    }
}

# Your code here

Hint

The map directive must be placed outside the server block. Use the IP range 192.168.1.0/24 as the key and internal as the value.

3

Use the $client_type variable in the server block

Modify the location / block inside the server block to add a response header named X-Client-Type with the value of the $client_type variable.

Nginx

map $remote_addr $client_type {
    192.168.1.0/24 internal;
    default external;
}

server {
    listen 8080;
    location / {
        add_header X-Client-Type $client_type;
        return 200 'Hello from Nginx';
    }
}

# Your code here

Hint

Use the add_header directive inside the location / block to add the header.

4

Test the configuration output

Run the Nginx server with this configuration and simulate a request from IP 192.168.1.5. Print the response header X-Client-Type to confirm it shows internal.

Nginx

# Simulate a request from 192.168.1.5 and print the X-Client-Type header
# Your code here

Hint

Since this is a configuration file, simulate the output by printing the expected header line.

Practice

1. What is the primary purpose of the map directive in nginx configuration?

easy

A. To create new variables based on existing variables

B. To define server blocks for different domains

C. To set up SSL certificates

D. To configure load balancing between servers

Solution

1. Step 1: Understand the role of map in nginx

   The map directive is used to create new variables by mapping values from existing variables.

2. Step 2: Compare with other nginx directives

   Other options like server blocks, SSL, and load balancing serve different purposes unrelated to variable mapping.

3. Final Answer:

   To create new variables based on existing variables -> Option A

4. Quick Check:

   map creates variables [OK]

Hint: Map creates variables from existing ones [OK]

Common Mistakes:

• Confusing map with server block configuration
• Thinking map sets SSL or load balancing
• Assuming map modifies request headers directly

2. Which of the following is the correct syntax to start a map block in nginx?

easy

A. map ($variable, $new_variable) {

B. map $new_variable $variable {

C. map { $variable $new_variable }

D. map $variable $new_variable {

Solution

1. Step 1: Recall the syntax of the map directive

   The correct syntax is map $variable $new_variable { where the first variable is the source and the second is the target.

2. Step 2: Eliminate incorrect syntax

   The incorrect options use wrong order or invalid punctuation for nginx configuration.

3. Final Answer:

   map $variable $new_variable { -> Option D

4. Quick Check:

   map syntax = map $source $target { [OK]

Hint: Map syntax: map $source $target { [OK]

Common Mistakes:

• Swapping source and target variables
• Using parentheses or braces incorrectly
• Missing the $ sign before variables

3. Given this nginx map configuration:

map $http_user_agent $is_mobile {
    default 0;
    ~*Mobile 1;
}

What will be the value of $is_mobile if the user agent is Mozilla/5.0 (Linux; Mobile)?

medium

A. Mobile

B. 0

C. 1

D. default

Solution

1. Step 1: Understand the map pattern matching

   The map uses a case-insensitive regex ~*Mobile to match user agents containing 'Mobile'.

2. Step 2: Check the user agent string

   The user agent contains 'Mobile', so the regex matches and sets $is_mobile to 1.

3. Final Answer:

   1 -> Option C

4. Quick Check:

   Regex match 'Mobile' sets value to 1 [OK]

Hint: Regex ~*Mobile matches user agent containing 'Mobile' [OK]

Common Mistakes:

• Ignoring case-insensitive regex (~*)
• Assuming default value applies despite match
• Confusing variable names

4. Identify the error in this nginx map configuration:

map $request_method $allow_method {
    GET yes;
    POST yes;
    DELETE no
}

medium

A. Missing semicolon after DELETE no

B. Incorrect variable names

C. map directive cannot map request methods

D. Using yes/no instead of 1/0 is invalid

Solution

1. Step 1: Check syntax for each mapping line

   Each line inside map must end with a semicolon. The line DELETE no is missing a semicolon.

2. Step 2: Validate other options

   Variable names are valid, mapping request methods is allowed, and yes/no strings are acceptable values.

3. Final Answer:

   Missing semicolon after DELETE no -> Option A

4. Quick Check:

   Each map line ends with ; [OK]

Hint: Every map entry line ends with a semicolon [OK]

Common Mistakes:

• Omitting semicolons at line ends
• Thinking yes/no are invalid values
• Assuming map can't use request methods

5. You want to create a variable $cache_key that is mobile if the user agent contains 'Mobile', otherwise desktop. Which map configuration correctly achieves this?

hard

A. map $cache_key $http_user_agent {
mobile ~*Mobile;
desktop default;
}

B. map $http_user_agent $cache_key {
~*Mobile mobile;
default desktop;
}

C. map $http_user_agent $cache_key {
default desktop
~*Mobile mobile
}

D. map $http_user_agent $cache_key {
Mobile mobile;
default desktop;
}

Solution

1. Step 1: Confirm correct map syntax and order

   The map directive must have source variable first, target variable second, and each line ends with semicolon.

2. Step 2: Check pattern matching and default

   map $http_user_agent $cache_key { ~*Mobile mobile; default desktop; } uses case-insensitive regex ~*Mobile to match user agents containing 'Mobile' and sets mobile, else desktop.

3. Step 3: Eliminate incorrect options

   map $cache_key $http_user_agent { mobile ~*Mobile; desktop default; } reverses variables, one misses semicolons, another uses exact 'Mobile' without regex and may miss case-insensitive matches.

4. Final Answer:

   map $http_user_agent $cache_key { ~*Mobile mobile; default desktop; } -> Option B

5. Quick Check:

   Correct map syntax with regex and default [OK]

Hint: Use map $source $target with regex and default [OK]

Common Mistakes:

• Swapping source and target variables
• Missing semicolons after lines
• Not using case-insensitive regex for matching