NGINX将带参数的/api路径请求全部重定向至子域名

Let's break down what's wrong with your current configuration and get this redirect working exactly as you need it.

The Problem with Your Existing Setup #

Your current rule:

location ~ /api(.*)$ { return 301 https://api.example.com/api/$request_uri$is_args$args; }

has two key issues causing broken redirects:

• $request_uri already includes the full original path (including /api and everything after it) plus any query parameters. Adding /api/ before it creates duplicate path segments, which is why you're seeing mangled URLs like https://api.example.com//some_action.
• You're combining $request_uri (which already contains parameters) with $is_args$args, leading to redundant parameter strings that get dropped or mangled by Nginx.

Correct Configurations to Use #

Option 1: Prefix Match (Recommended for Performance)

This is the simplest and most efficient way to handle all /api-prefixed requests:

server {
    listen 443 ssl;
    server_name example.com;

    # Redirect all /api requests to api subdomain, preserving full path and params
    location ^~ /api {
        return 301 https://api.example.com$request_uri;
    }

    # Your other main domain configurations (static files, other locations, etc.)
}

• ^~ /api tells Nginx to use this prefix match before any regular expression locations, ensuring /api requests are prioritized.
• $request_uri carries the entire original request path (e.g., /api/some_action) and query parameters (e.g., ?params1=somevalue&params2=value2), so appending it directly to https://api.example.com gives you the exact URL structure you want.

Option 2: Regular Expression Match

If you prefer regex for more granular control, this works reliably too:

server {
    listen 443 ssl;
    server_name example.com;

    location ~ ^/api(.*)$ {
        return 301 https://api.example.com/api$1$is_args$args;
    }

    # Other main domain configs
}

• The regex ^/api(.*)$ captures everything after /api into the $1 variable (e.g., /some_action for /api/some_action).
• We append /api$1 to reconstruct the original path, then add $is_args$args to include any query parameters (safe here because $1 doesn't include params).

Testing Tip #

While debugging, use 302 Temporary Redirect instead of 301 Permanent Redirect—browsers cache 301s aggressively, which can make testing new configs frustrating. Once you confirm everything works as expected, switch back to 301.

Example Results #

With either correct config, your test cases will behave exactly as needed:

• https://example.com/api → https://api.example.com/api
• https://example.com/api/some_action → https://api.example.com/api/some_action
• https://example.com/api/some_action?params1=somevalue&params2=value2 → https://api.example.com/api/some_action?params1=somevalue&params2=value2

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