Hey there! Since you're new to Nginx, let's break down exactly how to handle those URL query parameters (the bits after the ?) using your example requests as a guide. It's simpler than you might think once you know the right variables and directives to use.

Nginx automatically parses query parameters and makes them available via special variables: $arg_<parameter-name>. For your examples:

• $arg_id will hold the value of the id parameter (like 123 or 456)
• $arg_name will hold the value of name (like yuva1 or jam5)
• Same logic applies to $arg_place and $arg_marks

You can test this easily with a simple return directive to see the values:

server {
    listen 80;
    server_name example.com;

    location /api/student {
        return 200 "Received parameters: ID=$arg_id, Name=$arg_name, Place=$arg_place, Marks=$arg_marks";
    }
}

If you have the echo module installed (common in many Nginx setups), you can use echo instead for cleaner output.

If you need to handle requests differently depending on which parameter is present (e.g., route to different backend services), you have two solid options:

Option 1: Basic Conditional Logic with if #

For simple scenarios, the if directive works well. Just note that Nginx's if isn't a full programming conditional—use it for straightforward checks:

location /api/student {
    # Route requests with an `id` parameter to your ID service
    if ($arg_id) {
        proxy_pass http://your-id-processing-service;
        break; # Stop processing further directives
    }

    # Route requests with a `name` parameter to your name service
    if ($arg_name) {
        proxy_pass http://your-name-lookup-service;
        break;
    }

    # Handle place/marks parameters similarly
    if ($arg_place) {
        proxy_pass http://your-place-service;
        break;
    }

    if ($arg_marks) {
        proxy_pass http://your-marks-service;
        break;
    }

    # Default response if no valid parameter is found
    return 400 "Please provide one of: id, name, place, marks";
}

Option 2: Scalable Routing with map #

For more complex setups (or if you have lots of parameters to handle), the map directive is more efficient. Define it in the http block (outside your server block):

http {
    # Map request URIs to backend services based on which parameter is present
    map $request_uri $target_backend {
        ~*\?id=      http://your-id-processing-service;
        ~*\?name=    http://your-name-lookup-service;
        ~*\?place=   http://your-place-service;
        ~*\?marks=   http://your-marks-service;
        default      http://default-fallback-service;
    }

    server {
        listen 80;
        server_name example.com;

        location /api/student {
            proxy_pass $target_backend;
        }
    }
}

The ~* makes the regex match case-insensitive, and the pattern checks for the presence of each parameter in the request URI.

If you need to enforce rules on parameter values (e.g., id must be a number) or modify them before passing to a backend, use regex checks with if:

Validate Parameter Format #

location /api/student {
    # Ensure `id` is only numbers
    if ($arg_id !~ ^[0-9]+$) {
        return 400 "ID must be a numeric value";
    }

    # Ensure `name` is only letters/numbers
    if ($arg_name !~ ^[a-zA-Z0-9]+$) {
        return 400 "Name can only contain letters and numbers";
    }

    proxy_pass http://your-service;
}

Modify Parameter Values #

To rewrite a parameter value (e.g., add a prefix to id):

location /api/student {
    if ($arg_id) {
        rewrite ^(.*)\?id=(.*)$ $1?id=prefix-$2? break;
        proxy_pass http://your-service;
    }
}

The trailing ? in the rewrite rule ensures any extra & or empty parameters get cleaned up.

• Always validate your config with nginx -t before reloading to catch syntax errors
• Reload Nginx with nginx -s reload after making changes
• Use tools like curl to test requests: curl "http://example.com/api/student?id=789"

内容的提问来源于stack exchange，提问作者Gowthaman Javi