All Products
Search

This Product

    Server Load Balancer:Forwarding rules and domain/path matching

    Document Center

    Server Load Balancer:Forwarding rules and domain/path matching

    Last Updated:May 13, 2026

    This topic describes common configurations for ALB forwarding rules, the matching rules for domain names and URL paths, and advanced rules for URL path rewrites and redirects.

    Common scenario examples

    Scenario 1: Redirect HTTP to HTTPS

    Automatically redirect HTTP requests to HTTPS to encrypt data in transit. This requires adding a forwarding rule to the HTTP listener on port 80.

    Parameter

    Description

    Add Condition

    Select Path, select Exact Match and Wildcard, and enter /*.

    Action

    Select Redirect.

    • Protocol: Select HTTPS.

    • Domain Name: ${host}

    • Port: Enter the port of the existing HTTPS listener, for example, 443.

    • Path: ${path}

    • Search: ${query}

    • Status Code: Select 301

    Effect: When a user visits http://www.example.com/page, the browser automatically redirects to https://www.example.com/page.

    Configure this rule on the HTTP listener (port 80). Ensure that an HTTPS listener (port 443) is created and associated with a valid SSL certificate. For complete prerequisites and instructions, see Redirect HTTP requests to HTTPS by using ALB.

    Scenario 2: Route requests based on path

    For a single domain name, you can route requests for different paths to different server groups. For example, you can forward API requests and static resource requests to separate backends.

    Rule 1: Forward requests for /api/* to the API server group.

    Parameter

    Description

    Add Condition

    Select Path: Exact Match and Wildcard and enter /api/*.

    Action

    Select Forward, and then select the API server group.

    Rule 2: Forward requests for /static/* to the static resource server group.

    Parameter

    Description

    Add Condition

    Select Path: Exact Match and Wildcard and enter /static/*.

    Action

    Select Forward, and then select the static resource server group.

    ALB matches forwarding rules sequentially in numerical order. Place more specific path rules first (with smaller numbers) to prevent wildcard rules from being matched first. For example, /api/v2/* should be placed before /api/*.

    Scenario 3: Route multiple domains to backends

    Host multiple domain names on a single ALB instance and forward requests for each domain name to its corresponding server group.

    Rule 1: Forward requests for www.example.com to the Web server group.

    Parameter

    Description

    Add Condition

    For Domain Name, select Exact Match and Wildcard and enter www.example.com.

    Action

    Select Forward, and then select a web server group.

    Rule 2: Forward requests for api.example.com to the API server group.

    Parameter

    Description

    Add Condition

    Select Domain Name: Exact Match and Wildcard and enter api.example.com.

    Action

    Select Forward, and then select the API server group.

    Scenario 4: Forward requests after stripping a path prefix

    Strips a specific prefix from the request path and forwards the request to the backend, while also supporting matching for multi-level paths that follow the prefix. For example, when an ALB forwards a request for www.example.com/api/aaa/bbb/..., the /api part is removed from the path, and the feature supports matching the remaining multi-level path that follows /api.

    A rewrite replaces the path internally on the ALB; the URL in the client's browser does not change. A redirection returns a new URL to the client, which then updates its address bar. Use Rewrite if you only need the backend to receive the path without the prefix. Use Redirection if you want the client to be aware of the URL change.

    Rewrite

    Parameter

    Description

    Add Condition

    Domain Name

    Select Exact Match and Wildcard and enter www.example.com.

    Path

    Select Regular Expression Match | Case Insensitive and enter ^/api/(.*).

    Action

    Rewrite

    • Domain Name: ${host}

    • Path: /${1}

    • Search: ${query}

    Forward

    Select the target server group.

    Redirection

    Parameter

    Description

    Add Condition

    Domain Name

    Exact Match and Wildcard and enter www.example.com.

    Path

    Select Regular Expression Match | Case Insensitive and enter ^/api/(.*).

    Action

    Redirect

    • Protocol: ${protocol}

    • Domain Name: ${host}

    • Port: ${port}

    • Path: /${1}

    • Search: ${query}

    • Status Code: Select 301.

    Effect: When a user accesses www.example.com/api/aaa/bbb/..., the backend server receives a request with the path /aaa/bbb/....

    Scenario 5: Redirect bare domain to www

    Redirect traffic from a bare domain such as example.com to www.example.com to unify the entry point and simplify SEO and management.

    Parameter

    Description

    Add Condition

    Select Domain Name, Exact Match and Wildcard, and enter example.com.

    Action

    Select Redirect.

    • Protocol: ${protocol}

    • Domain Name: Enter www.example.com.

    • Port: ${port}

    • Path: ${path}

    • Search: ${query}

    • Status Code: Select 301.

    Effect: When a user visits example.com, the browser automatically redirects to www.example.com. The protocol and port remain unchanged.

    To also redirect HTTP requests to HTTPS, combine this configuration with the one described in Scenario 1.

    Scenario 6: Wildcard domain matching

    Use a wildcard domain to match all subdomains and forward their requests to the same server group.

    Parameter

    Description

    Add Condition

    Select Domain Name: Exact Match and Wildcard and enter *.example.com.

    Action

    Select Forward, and then select the target server group.

    Effect: Requests for all subdomains such as a.example.com, b.example.com, and tenant1.example.com are forwarded to the same server group.

    Assign the rule for the specific domain name a lower priority number than the rule for the wildcard domain. This is because ALB evaluates rules by priority number, not domain name specificity.

    Scenario 7: Canary release based on an HTTP header

    Use an HTTP header to implement a canary release. Forward requests with a specific header to the new-version server group, and route all other requests to the old-version server group.

    Rule 1 (Canary rule, high priority): Forwards requests with the X-Canary: true header to the new version server group.

    Parameter

    Description

    Add Condition

    Select HTTP Header, set the key to X-Canary, and set the value to true.

    Action

    Select Forward and then select the new version server group.

    Rule 2 (Default rule, higher priority): Use the listener's default forwarding rule to direct requests without the canary header to the old-version server group.

    Effect: Client requests that carry the X-Canary: true header are forwarded to the new version server group. Requests without this header continue to be forwarded to the old version server group.

    Assign the canary rule a lower priority number than the default rule to ensure that it is matched first. For information about canary releases based on cookies and server group weights, see Use ALB to implement canary release.

    Domain name match rules

    ALB evaluates forwarding rules sequentially based on their priority number and stops at the first match. It does not automatically sort rules by domain name specificity. This differs from CLB, which automatically sorts rules by specificity, prioritizing an exact match over a wildcard match.

    For example, consider a listener with the following two rules:

    Priority number

    Match condition

    Rule 1 (Priority: 1)

    domain name = *.example.com → forward to server group A

    Rule 2 (Priority: 2)

    domain name = www.example.com → forward to server group B

    In this case, a request to www.example.com matches Rule 1 (the wildcard rule), not Rule 2 (the exact match rule), because Rule 1 has a lower priority number and is evaluated first.

    Best practice: To ensure an exact match rule is evaluated before a wildcard rule, assign the exact match rule a lower priority number. For this example, you would configure Rule 1 to match www.example.com and Rule 2 to match *.example.com.

    Match type

    Description

    Exact match and wildcard match

    • Match logic

      • Exact match: The requested domain name must be identical to the specified domain name.

      • Wildcard match: The requested domain name must match the specified wildcard pattern.

    • Requirements

      A domain name must be 3 to 128 characters in length. It can contain only letters, digits, and the following special characters: .-?=~_-+\^*!$&|()[]. Asterisks (*) and question marks (?) are supported as wildcards.

    • Example

      Requested domain name: www.example.com

      • Exact match: The request matches if the forwarding rule is configured with www.example.com.

      • Wildcard match: The request matches if the forwarding rule is configured with *.example.com or www.example.*.

    Regular expression match

    • Match logic

      The requested domain name is matched against the specified regular expression.

    • Requirements

      A domain name must be 3 to 128 characters in length. It can contain only letters, digits, and the following special characters: .-?=~_-+\^*!$&|()[].

    • Example

      Requested domain name: www.example.com

      The request matches a forwarding rule configured with the regular expression ^www.example.com$. This match is case-insensitive.

    Path configuration for forwarding rules

    The path matching rules of ALB are different from those of Nginx because ALB does not support longest prefix match. For example, the common Nginx configuration location /api uses longest prefix match. To achieve a similar result in ALB, you must use a wildcard. You can configure the path as /api/* (exact match and wildcard) to achieve this.

    If a listener has forwarding rules for both /api/* and /api/v2/*, you must assign the /api/v2/* rule a smaller rule number than the /api/* rule. Otherwise, the /api/* rule will match all requests first.

    Match type

    Description

    Exact match and wildcard match

    • Match description

      • Exact match: The request path must be identical to the specified path.

      • Wildcard match: The request path must match the specified wildcard pattern.

    • Input conditions

      The path must start with a forward slash (/). It can contain only uppercase and lowercase letters, digits, and the following special characters: $-_.+/&~@:. Asterisks (*) and question marks (?) function as wildcards.

    • Example

      Request path: /example/text

      • Exact match: Matches the path /example/text.

      • Wildcard match: Matches the pattern /example/*.

    Regular expression match

    • Match description

      Matches the request path against the specified regular expression.

    • Input conditions

      The regular expression can contain only uppercase and lowercase letters, digits, and the following special characters: .-_/=?~^*$:()[]+|.

    • Example

      Request path: /api/v2/Users

      • Case-sensitive match: Matches the regular expression ^/api/(.*)/Users$.

      • Case-insensitive match: Matches the regular expression ^/api/(.*)/[Uu]sers$.

    Advanced path configuration for rewrites and redirects

    When you use a regular expression for the path in a forwarding condition, you can use variables from that expression to construct a new path for rewrite and redirect actions.

    • Usage notes

      • The number of capture groups, defined by parentheses( ), in your regular expression must match the number of variables used in the path for the rewrite or redirect action.

      • The path for the rewrite or redirect action must include one or more of the variables: ${1}, ${2}, or ${3}. These variables cannot be replaced by other characters.

    • How it works

      1. When a client sends a request, ALB matches it against the regular expression in a forwarding rule.

      2. Using standard regular expression rules, the system captures content from the first three capture groups( ) and stores it in the variables ${1}, ${2}, and ${3}, respectively. You can then use these variables in the path for the rewrite or redirect action.

      3. ALB replaces the variables ${1}, ${2}, and ${3} in the configured path with their captured values to construct the final path for the rewrite or redirect.

      No.

      Step

      Example

      1

      Configure the forwarding condition and forwarding action in a forwarding rule.

      • Forwarding condition path: /app/(.*)/(.*)/settings

      • Rewrite or redirect path: /${1}/${2}

      2

      A client sends a request that matches the path.

      • Request path from the client: /app/users/profile/settings

      • Matched forwarding condition path: /app/(.*)/(.*)/settings

      3

      Extract and substitute

      The two (.*) capture groups in the condition path extract users and profile. The system then assigns these values to the ${1} and ${2} variables in the path of the forwarding action.

      • ${1} is replaced with users.

      • ${2} is replaced with profile.

      4

      Concatenate the path

      Path received by the backend server: /users/profile

    • Configuration examples

      You can add forwarding rules in the console by following the usage notes and principles in this topic.

      Example 1: ActionRewrite to Forward

      The following example shows how to rewrite the path /app/users/profile/settings to /users/profile and then forward the request to a backend server. The regular expression /app/(.*)/(.*)/settings uses two capture groups to extract users and profile. The rewritten path then uses /${1}/${2} to construct the final path.

      Parameter

      Description

      Add Condition

      Path

      Select Regular Expression Match | Case Insensitive and enter the regular expression /app/(.*)/(.*)/settings.

      For example, a client request for /app/users/profile/settings matches this rule. The capture groups extract users and profile and assign the values to ${1} and ${2}, respectively.

      Action

      Rewrite

      • Domain Name: ${host}

      • Path: /${1}/${2}

      • Search: ${query}

      The Search parameter refers to the query string, which is the part of a URL after the question mark (?). For example, in the URL www.example.com/test/test1?x=1, the Search value is x=1.

      Forward

      Select the target server group from the list.

      Example 2: Set the forwarding action to redirect

      The following example shows how to redirect the path /app/users/profile/settings to /users/profile. Unlike Example 1, a redirect returns a 301 status code and the URL in the browser's address bar changes.

      Parameter

      Description

      Add Condition

      Path

      Select Regular Expression Match | Case Insensitive and enter the regular expression /app/(.*)/(.*)/settings.

      For example, a client request for /app/users/profile/settings matches this rule. The capture groups extract users and profile and assign the values to ${1} and ${2}, respectively.

      Action

      Redirect

      • Protocol: ${protocol}

      • Domain Name: ${host}

      • Port: ${port}

      • Path: /${1}/${2}

      • Search: ${query}

      • Status Code: 301

    FAQ

    Rewriting a domain without modifying the path

    To rewrite a requested domain to another without changing the path and query string, configure the forwarding rule as follows:

    • Add Condition: Set the domain to the original domain, such as old.example.com.

    • Action: Select Rewrite. Set the domain to the new domain (such as new.example.com), the path to ${path} to preserve the original path, and the query to ${query} to preserve the original query string. Also, configure Forward a target server group.

    Adding a prefix to a path

    To add a prefix, such as a version number, to the original path (for example, rewriting /users/list to /v2/users/list), configure the forwarding rule as follows:

    • Add Condition: Set the path regular expression match to ^/(.*).

    • Action: Select Rewrite and set the path to /v2/${1}. Also, configure Forward a target server group.

    This rule rewrites requests for /users/list to /v2/users/list and forwards them to the backend server.

    Removing a prefix from a path

    For instructions, see Use case 4: Forward requests after stripping a path prefix in this topic. It provides a complete example of how to remove a prefix like /api/* by using a regular expression match with a rewrite or redirect action.

    Troubleshooting forwarding rule issues

    If forwarding rules do not route requests as expected, follow these steps to troubleshoot:

    1. Check the rule priority: ALB evaluates rules in ascending order of priority and stops at the first match. If a more general rule has a lower priority number, a more specific rule that follows it will never be evaluated.

    2. Check the match type: Use the correct match type (exact match, wildcard, or regular expression match). For example, an exact match for /api does not match /api/users. To match both, you must use a wildcard match, such as /api/*.

    3. Check for multiple conditions: When a forwarding rule has multiple conditions, conditions of different types are combined with a logical AND, while multiple values for the same condition type are combined with a logical OR. For more information, see Configure listener forwarding rules.

    4. Check the access log: Review the host and request_uri fields in the ALB access log to verify that ALB received the expected request.

    Rewrite vs. redirect

    Aspect

    Rewrite

    Redirect

    Browser address bar

    Unchanged (transparent to the user)

    Changes to the new URL

    Process

    ALB modifies the request and forwards it to the backend server, completing the process in a single round trip.

    ALB returns a 3xx status code, instructing the browser to send a new request to the target URL. This involves two request-response cycles.

    Use cases

    Internal path adjustments, such as stripping a path prefix or adding a version prefix.

    Redirecting from HTTP to HTTPS, from a root domain to a www subdomain, or migrating legacy URLs.

    Requires a Forward to action

    Yes. A rewrite action must be paired with a Forward to action that specifies a target server group.

    No. A redirect action is self-contained and does not require a Forward to action.

    Related topics

    To configure other listener forwarding rules for an ALB, see Configure listener forwarding rules.