Server Load Balancer:Listener forwarding rules

Rule Name

Optional. If you leave this parameter empty, the system automatically generates a name.

Add Condition

Select a condition type to add one or more of the following conditions. You can also click Add Condition to add multiple conditions.

• Domain Name: Add one or more domain names. A domain name must be 3 to 256 characters in length and can contain wildcard characters, including asterisks (*) and question marks (?). An asterisk (*) matches any string of characters, and a question mark (?) matches a single character. Supported match types include exact match, wildcard match, and regular expression match. For more information about domain name configuration rules, see Forwarding rule configuration examples and domain name and path matching rules.

  • Exact match: The request domain name must be an exact match for the specified domain name, for example, www.example.com.

  • Wildcard match: Use an asterisk (*) to match any string of characters, including dots (.), and a question mark (?) to match a single character. For example, *.example.com can match api.example.com and www.example.com.

  • Regular expression match: Use a regular expression for domain name matching. The matching is case-insensitive. For example, ^www\.example\.(com|cn)$ can match domain names that end with .com or .cn.

• Path: Add one or more paths. Both regular expression paths and non-regular expression paths are supported. For more information about path configuration rules, see Forwarding rule configuration examples and domain name and path matching rules.

  • Exact match: For example, /api/v1/users matches only the exact path.

  • Wildcard match: For example, /api/* matches all paths that start with /api/, including subpaths. /* matches all paths. Path matching is case-sensitive.

    When a client accesses a domain name directly without specifying a path, for example, http://example.com, ALB treats it as the path / for matching. Therefore, /* also matches such requests without a path.

  • Regular expression match: For example, ^/api/(.*)/list$ matches paths that start with /api/ and end with /list. You can choose whether the matching for regular expression paths is case-sensitive.

• HTTP Header: Enter the HTTP header name in the Key field and its value in the Value field. You can add multiple header values. The header key must be 1 to 40 characters in length and can contain only letters, digits, underscores (_), and hyphens (-). The matching is case-insensitive. The header value must be 1 to 128 characters in length and can contain printable characters. The value cannot start or end with a space. You can use wildcard characters, including asterisks (*) and question marks (?).

  Example: Key is user-agent, and Value is *Mozilla/4.0*. This configuration matches all requests where the value contains Mozilla/4.0.

• Query String: Add one or more key-value pairs for the query string. The key must be 1 to 100 characters in length and the value must be 1 to 128 characters in length. You can use visible characters such as lowercase letters (although the input accepts only lowercase letters, the matching is case-insensitive), asterisks (*), and question marks (?). Spaces and special characters such as #[]{}\|<>& are not supported.

  Example: If the URL is www.example.com/test/test1?x=1&y=2, you can configure the condition as x:1 or y:2.

• HTTP Request Method: Add one or more HTTP request methods. Valid values are HEAD, GET, POST, OPTIONS, PUT, PATCH, and DELETE.

• Cookie: Add one or more cookies. The key must be 1 to 100 characters in length and the value must be 1 to 128 characters in length. You can use visible characters such as lowercase letters (although the input accepts only lowercase letters, the matching is case-insensitive), asterisks (*), and question marks (?). Spaces and special characters such as []{}<>\#|& are not supported.

  Example: Key is key and Value is value.

• Source IP: Add one or more IP addresses or CIDR blocks. CIDR blocks in the format of 0.0.0.0/x, where x is a digit, are not supported.

  Example: 192.168.1.1/32

• AI Model: Supported only by ALB Extensible Edition instances. ALB extracts the model protocol and model name from the request body for matching, and then proxies the request to the corresponding backend service (an AI service or a self-managed LLM service), without requiring any modification on the business side.

  • Protocol: Defaults to OpenAI compatible, which includes three routes: /v1/completions, /v1/chat/completions, and /v1/embeddings. Business traffic that matches this protocol is forwarded to the backend service.

  • Model Name: Optional. If you specify a model name, requests can be matched and forwarded to the corresponding backend service based on the model name. Model names are matched using Glob syntax. You can add multiple model names, and the OR logic applies between them.

  In a single forwarding rule, the AI Model and Path conditions are mutually exclusive. You can configure only one of them in a rule.

  When forwarding is based on the model name, in the inbound Insert Header and Remove Header actions, you cannot set the header field name to x-alb-model, which is a system-reserved field of ALB.

Action

Select an action type to add one or more of the following actions. You can also click Add Action to add multiple actions.

• Forward to: Select a target server group from the list. Supported server group types are Server, IP Address, and Function Compute. If the instance edition is Extensible, the FQDN, AI Service, MCP Service Type, and IP Address Range server group types are also supported. You can add multiple server groups and set a Weight for each server group to control the traffic distribution ratio. By default, the weight of a single server group ranges from 0 to 100. If you add multiple server groups, you can enable Session Persistence for Server Groups. To use this feature, you must enable session persistence for all added server groups.

  When you add multiple server groups, you can select server groups that use different backend protocols, such as HTTP and HTTPS.

  The maximum weight of a single server group can be increased to 10,000. To request this increase, contact your account manager.

  A server group of the IP Address Range type is a component for implementing dynamic forwarding and is used to limit the range of destination addresses allowed for dynamic forwarding. This type of server group can be used only after it is associated with a service extension that contains the dynamic forwarding component.

  After you select a server group of the MCP service type, the entire forwarding rule is subject to the following restrictions to comply with the MCP protocol specifications: The conditions support only Domain Name and Path. The actions support only Forward to, Insert Header, and Remove Header. You can select only one server group of the MCP service type, and it cannot be used together with server groups of other types. It must be associated with a service extension that contains the MCP proxy component.

• Redirect to: From the Protocol and Status Code drop-down lists, select a protocol and a status code. Then, specify the destination Domain Name, Port, Path, and Search. You must specify a non-default value for at least one of these parameters: Protocol, Domain Name, Port, Path, or Search.

  For more information about advanced configuration rules for the Path parameter in the Redirect to action, see Advanced path configuration for rewrites and redirects.

  The default values of fields, such as ${host}, ${path}, ${port}, ${protocol}, and ${query}, refer to the corresponding values in the request. The path field supports only references to ${host}, ${path}, ${port}, and ${protocol}, and regular expression capture group variables such as ${1}, ${2}, and ${3}. Other $ variables are not supported.

  For more information about status codes, see Standard HTTP status codes.

• Return Fixed Response: Enter a Response Status Code. You can also specify the Response Content Type (Optional) and Response Content (Optional). The response status code must be a numeric string in the 2xx, 4xx, or 5xx format, where x is a digit.

• Rewrite: Modifies the Domain Name, Path, or Search of a request to a specified value before the request is forwarded to a backend server. The URL in the client's browser address bar does not change.

  The Rewrite action takes effect only when it is used with the Forward to action.

  Difference between Rewrite and Redirect to: A rewrite is an internal ALB operation that changes the path received by the backend server. The client URL remains unchanged. A redirect returns a 3xx status code that causes the client's browser to navigate to a new URL.

  Example: To rewrite /app/page to /v2/page, set the path condition to /app/page with the exact match method and set the rewrite path to /v2/page. To match and rewrite all subpaths under /app/, use a regular expression. For more information, see Advanced path configuration for rewrites and redirects.

  In a rewrite path, the $ character can be used only to reference the following variables: ${host}, ${path}, ${port}, ${protocol}, and regular expression capture group variables, such as ${1}, ${2}, and ${3}. Other variables are not supported.

• Insert Header: Enter a header name and value. This action overwrites any existing request header with the same name. The header key must be 1 to 40 characters in length and can contain letters, digits, underscores (_), and hyphens (-). The header value must be 1 to 128 characters in length and can contain letters, digits, and common punctuation marks. The value cannot start or end with a space.

• Remove Header: Enter a header name to remove the corresponding key-value pair from the request header.

  When you use the inbound Insert Header and Remove Header actions, you cannot specify the following header names. The matching is case-insensitive. These headers are reserved by ALB or are critical to the HTTP protocol. Modifying them may cause request forwarding errors or connection interruptions. slb-id, slb-ip, x-forwarded-for, x-forwarded-proto, x-forwarded-eip, x-forwarded-port, x-forwarded-client-srcport, x-forwarded-host, connection, upgrade, content-length, transfer-encoding, keep-alive, te, host, cookie, remoteip, and authority.

• Rate Limit: Configure the following parameters based on your business requirements.

  • QPS (Total): Specify the number of queries per second. Valid values: 1 to 1,000,000.

  • QPS (Per Client IP): Specify the QPS limit for each source IP address. Valid values: 1 to 1,000,000. If you configure both QPS (Total) and QPS (Per Client IP), the value of QPS (per Source IP) must be less than the value of QPS (Total Limit).

  The Rate Limit action must be used with the Forward to action. Requests that are within the QPS limit are forwarded to the target server group. By default, ALB returns a 503 status code for requests that exceed the QPS limit. Alternatively, you can add a Redirect to or Return Fixed Response action to handle these requests.

  If you enable QPS (Per Client IP), ALB retrieves the source IP address from the X-Forwarded-For header. If requests pass through multiple proxies, enable Retrieve Client IP for the listener to ensure that ALB obtains the correct client source IP address. For more information, see Create and manage listeners.

• Mirror traffic to: Select a target server group from the list. You can select Server or IP Address server groups.

• CORS: Configure a Cross-Origin Resource Sharing (CORS) policy. ALB automatically handles OPTIONS preflight requests and returns CORS response headers. As a result, backend servers do not need to process CORS requests. The CORS action is easier to configure than using the Insert Header action to manually configure response headers such as Access-Control-Allow-Origin.

  What is CORS?

  A cross-origin request is a request for a resource from an origin (domain, protocol, or port) different from that of the current page. Requests include simple requests and preflight requests. The CORS action is suitable for scenarios where frontend and backend services are decoupled. For example, if the frontend is deployed at www.example.com and the API service is deployed at api.example.com, cross-origin restrictions are triggered when the frontend calls the API from a browser.

  • Trusted Origins: Specify the origins from which browsers are allowed to access your resources.

  • Trusted Methods: Select the HTTP methods that are allowed for cross-origin requests. Valid values: GET, POST, PUT, DELETE, HEAD, OPTIONS, and PATCH.

  • Trusted Request Headers: Specify the headers that are allowed in cross-origin requests in addition to the basic headers supported by browsers.

  • Trusted Response Headers: Specify the response headers that can be accessed by browsers and JavaScript.

  • Trusted Credentials: Specify whether to allow credentials to be included in cross-origin requests. The default value is Allow.

  • Browser Cache Time: For preflight requests, specify the maximum period of time for which the results of an OPTIONS preflight request can be cached in the browser. Unit: seconds. Valid values: -1 to 172800.

  We recommend that you use a Domain Name condition for a CORS rule. This prevents preflight requests (OPTIONS), whose method and headers differ from the actual request, from matching a different rule and causing the CORS configuration to fail. Distinguish between the two domain names: set Domain Name to the target domain name, for example, api.example.com, and set Trusted Origins to the source domain name, for example, www.example.com. For more information, see CORS FAQ.

• Fallback: Supported only by ALB Extensible Edition instances. When a backend service returns any HTTP 4xx or 5xx error status code (the status codes are preset by the system and cannot be customized), ALB automatically retries the request on backup server groups. You can select one or more backup server groups. If you select multiple groups, ALB tries them in ascending order of their sequence numbers. When falling back to a service that is compatible with the OpenAI protocol, ALB can pass through the model name or rewrite the model name in the request body.

  The Fallback action must be used with the Forward to action and is executed after the Forward to action.

  All server group types except the MCP Service Type type can be used as fallback services.

Service Extension (Optional)

Supported only by ALB Extensible Edition instances. Service extensions provide ALB with personalized traffic processing and flexible extension capabilities through plugins or external service calls. Built-in components include Token Rate Limiting, API Key Authentication, JWT Authentication, MCP Proxy, Dynamic Forwarding, and Load-Aware Routing. An inbound forwarding rule can be associated with one service extension, which takes effect immediately after association. The service extension is executed between the conditions and the actions.

For more information about the components, configuration steps, quotas, and billing of service extensions, see Service Extensions.

Service extensions that contain the Dynamic Forwarding or Load-Aware Routing component cannot be associated with forwarding rules.

Rule Name

Optional. If you leave this parameter empty, the system automatically generates a name.

Inbound Conditions (Optional):

Select one or more inbound conditions. You can also click Add Inbound Condition to add multiple conditions. For information about how to configure each condition, see the Inbound forwarding rules tab.

If you configure a Rewrite action in an inbound forwarding rule, the inbound conditions (such as Domain Name, Path, and Query String) that you add to an outbound forwarding rule must match the rewritten values, not the original values from the client request. For example, if the inbound rule rewrites the path from /app/page to /v2/page, you must set the path condition in the outbound rule to /v2/page.

Outbound Conditions

Select one or more outbound conditions. You can also click Add Outbound Condition to add multiple conditions.

• Response Status Code: The status code in the response to the client. Valid values: 100 to 599. You can specify a range. Separate multiple status codes and ranges with commas (,), for example, 200-233,301.

• Response Header: An HTTP header in the backend response. Enter the HTTP header name in the Key field and its value in the Value field. You can add multiple headers.

Action

Select an outbound action type. You can also click Add Action to add multiple actions.

• Return Fixed Response: Enter a Response Status Code. You can also specify the Response Content Type (Optional) and Response Content (Optional). The response status code must be a numeric string in the 2xx, 4xx, or 5xx format, where x is a digit.

• Insert Header: Enter an outbound header name and value. This action overwrites any existing response header with the same name.

• Remove Header: Enter an outbound header name to remove the corresponding key-value pair from the response.

  When you use the outbound Insert Header and Remove Header actions, you cannot specify the following header names. The matching is case-insensitive. These headers are critical to the HTTP protocol. Modifying them may cause response transmission issues. connection, upgrade, content-length, and transfer-encoding.