Bird
Raised Fist0
Nginxdevops~5 mins

Why location matching controls request routing in Nginx - Why It Works

Choose your learning style10 modes available

Start learning this pattern below

Jump into concepts and practice - no test required

or
Recommended
Test this pattern10 questions across easy, medium, and hard to know if this pattern is strong
Introduction
When a web server receives a request, it needs to decide which part of the website or application should handle it. Nginx uses location matching rules to control this routing, directing requests to the right content or service based on the URL path.
When you want to serve different content for different URL paths on the same server
When you need to route requests to different backend services depending on the URL
When you want to apply specific settings like caching or authentication to certain URL patterns
When you want to block or allow access to certain parts of your website
When you want to rewrite URLs or redirect users based on the request path
Config File - nginx.conf
nginx.conf
events {}
http {
    server {
        listen 80;
        server_name example.com;

        location / {
            root /var/www/html;
            index index.html;
        }

        location /images/ {
            root /var/www/assets;
        }

        location /api/ {
            proxy_pass http://localhost:3000;
        }
    }
}

This configuration defines a server listening on port 80 for example.com.

The location / block serves files from /var/www/html for the root URL.

The location /images/ block serves image files from /var/www/assets when the URL starts with /images/.

The location /api/ block proxies requests starting with /api/ to a backend service running on localhost port 3000.

Commands
This command tests the nginx configuration file for syntax errors before applying it.
Terminal
sudo nginx -t
Expected OutputExpected
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok nginx: configuration file /etc/nginx/nginx.conf test is successful
This command reloads nginx to apply the new configuration without stopping the server.
Terminal
sudo systemctl reload nginx
Expected OutputExpected
No output (command runs silently)
This command requests the root URL, which nginx serves from /var/www/html as defined in the location / block.
Terminal
curl http://example.com/
Expected OutputExpected
<!DOCTYPE html> <html> <head><title>Home</title></head> <body>Welcome to the homepage!</body> </html>
This command requests an image file. Nginx routes it to the /images/ location, serving the file from /var/www/assets.
Terminal
curl http://example.com/images/logo.png --output logo.png
Expected OutputExpected
No output (command runs silently)
This command requests the /api/users endpoint, which nginx proxies to the backend service at localhost:3000.
Terminal
curl http://example.com/api/users
Expected OutputExpected
{"users":[{"id":1,"name":"Alice"},{"id":2,"name":"Bob"}]}
Key Concept

Nginx uses location blocks to match parts of the URL and route requests to the correct content or backend service.

Common Mistakes
Using overlapping location blocks without understanding their matching order
Nginx chooses the most specific match first, so a general location block may never be used if a more specific one matches first.
Order location blocks carefully and use prefixes or exact matches to control routing precisely.
Forgetting to reload nginx after changing the configuration
Changes won't take effect until nginx reloads, so requests will still be routed using the old rules.
Always run 'sudo nginx -t' to test and then 'sudo systemctl reload nginx' to apply changes.
Not using trailing slashes consistently in location paths
Trailing slashes affect how nginx matches URLs and serves files, causing unexpected routing or 404 errors.
Be consistent with trailing slashes in location definitions and URLs.
Summary
Nginx uses location blocks to decide how to route incoming requests based on URL paths.
Each location block can serve files, proxy requests, or apply special rules for matching URLs.
Testing and reloading nginx after configuration changes ensures routing rules are applied correctly.

Practice

(1/5)
1. What does the location directive in nginx control?
easy
A. How nginx routes incoming requests based on URL patterns
B. The server's IP address configuration
C. The database connection settings
D. The logging format for errors

Solution

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

    The location directive defines how nginx matches URLs to decide where to send requests.
  2. Step 2: Identify what location controls

    It controls routing of requests, not server IP, database, or logging.
  3. Final Answer:

    How nginx routes incoming requests based on URL patterns -> Option A
  4. Quick Check:

    Location controls routing = B [OK]
Hint: Location matches URLs to route requests [OK]
Common Mistakes:
  • Confusing location with server IP settings
  • Thinking location controls database connections
  • Assuming location affects logging formats
2. Which of the following is the correct syntax to define a prefix location block in nginx?
easy
A. location ~ /example { }
B. location = /example { }
C. location /example { }
D. location ! /example { }

Solution

  1. Step 1: Review nginx location syntax

    Prefix locations use location /path { } without modifiers.
  2. Step 2: Identify correct prefix syntax

    location /example { } is correct for prefix matching.
  3. Final Answer:

    location /example { } -> Option C
  4. Quick Check:

    Prefix location syntax = A [OK]
Hint: Prefix location has no modifier, just path [OK]
Common Mistakes:
  • Using '=' which means exact match, not prefix
  • Using '~' which means regex match
  • Using '!' which is invalid syntax
3. Given this nginx config snippet:
location /images/ {
  root /data;
}
location /images/thumbnails/ {
  root /thumbs;
}

Which root directory will nginx use for the request /images/thumbnails/pic.jpg?
medium
A. Default root directory
B. /data
C. Both /data and /thumbs
D. /thumbs

Solution

  1. Step 1: Understand location matching order

    nginx chooses the most specific matching location block for the URL.
  2. Step 2: Compare matching locations for /images/thumbnails/pic.jpg

    Both /images/ and /images/thumbnails/ match, but /images/thumbnails/ is more specific.
  3. Final Answer:

    /thumbs -> Option D
  4. Quick Check:

    Most specific location wins = A [OK]
Hint: Longest matching prefix location is chosen [OK]
Common Mistakes:
  • Choosing the first matching location instead of the most specific
  • Assuming both roots apply simultaneously
  • Ignoring location specificity
4. You have these location blocks:
location /app/ {
  proxy_pass http://backend1;
}
location ~ /app/ {
  proxy_pass http://backend2;
}

Requests to /app/test always go to backend1. Why?
medium
A. Requests to /app/test do not match either location
B. Prefix locations have higher priority than regex locations
C. The config has a syntax error
D. Regex locations always override prefix locations

Solution

  1. Step 1: Recall nginx location matching priority

    nginx first matches prefix locations, then regex locations only if no prefix matches.
  2. Step 2: Analyze given config

    Since /app/ prefix matches /app/test, nginx uses that before regex ~ /app/.
  3. Final Answer:

    Prefix locations have higher priority than regex locations -> Option B
  4. Quick Check:

    Prefix beats regex if prefix matches = D [OK]
Hint: Prefix location matches first, regex only if no prefix match [OK]
Common Mistakes:
  • Thinking regex always overrides prefix
  • Assuming syntax error causes this
  • Believing request doesn't match any location
5. You want requests to /api/v1/ to go to backend_v1 and requests to /api/ to go to backend_default. Which config correctly routes requests?
hard
A. location /api/v1/ { proxy_pass http://backend_v1; } location /api/ { proxy_pass http://backend_default; }
B. location ~ /api/ { proxy_pass http://backend_v1; } location /api/ { proxy_pass http://backend_default; }
C. location /api/ { proxy_pass http://backend_default; } location ~ /api/v1/ { proxy_pass http://backend_v1; }
D. location = /api/v1/ { proxy_pass http://backend_v1; } location /api/ { proxy_pass http://backend_default; }

Solution

  1. Step 1: Understand location matching order

    nginx chooses the most specific prefix location for a request.
  2. Step 2: Use more specific prefix /api/v1/

    Since /api/v1/ is longer/more specific than /api/, nginx selects it for matching requests.
  3. Step 3: Check options

    location /api/v1/ { proxy_pass http://backend_v1; } location /api/ { proxy_pass http://backend_default; } uses prefix locations where the longer one wins, correctly routing requests.
  4. Final Answer:

    location /api/v1/ { proxy_pass http://backend_v1; } location /api/ { proxy_pass http://backend_default; } -> Option A
  5. Quick Check:

    Specific location before general = C [OK]
Hint: Place more specific location before general prefix [OK]
Common Mistakes:
  • Placing general location before specific causing wrong routing
  • Using regex unnecessarily for simple prefix matching
  • Using exact match which only matches exact URL