SAE applications are isolated from the public internet by default. To accept inbound traffic, configure ALB gateway routing to expose your applications through an Application Load Balancer (ALB) listener. Each listener rule you define on the SAE side is an inbound forwarding rule — it matches incoming requests against one or more conditions and then executes one or more actions.
This topic covers key parameter decisions. For step-by-step instructions on creating gateway routes, see Configuring route rules by Application Load Balancer (ALB).
How forwarding rules work
A forwarding rule has two parts: forwarding conditions and forwarding actions. When an incoming request matches all the conditions in a rule, ALB executes the specified actions.
For Standard Edition and WAF-Enabled Edition ALB instances:
Inbound rules — ALB applies these to the request before forwarding it to the backend. Configure inbound rules from the SAE console.
Outbound rules — ALB applies these to the backend response before returning it to the client. Configure outbound rules from the SLB console, not the SAE console.
When creating a rule:
An inbound rule can only contain inbound conditions and inbound actions.
An outbound rule can contain both inbound and outbound conditions, but only outbound actions.
Every rule must include one of these actions: Forward to, Redirect to, or Return fixed response.
Navigate to gateway routing
Log on to the SAE console. In the left-side navigation pane, click Namespaces and select the target region.
On the Namespace page, click the name of the target namespace.
On the Basic Information page, click Gateway Routing in the left-side navigation pane, then click Create Gateway Route.
Forwarding conditions
On the SAE side, you can configure forwarding conditions based on domain name, access port, and path. The sections below explain each condition type and its matching options.
Domain name
ALB supports three matching types for domain names:
Matching type | How it works | Input constraints |
Exact match | The request domain name must exactly equal the configured value | 3–128 characters; uppercase/lowercase letters, digits, and `. - ? = ~ _ + \ ^ * ! $ & ( ) [ ]` |
Wildcard match | The request domain name must match the wildcard pattern; | Same character set as exact match |
Regular expression match | The request domain name must match the regular expression (case-insensitive) | 3–128 characters; uppercase/lowercase letters, digits, and `. - ? = ~ _ - + \ ^ * ! $ & ( ) [ ]` |
Examples for www.example.com:
Matching type | Input | Matches? |
Exact |
| Yes |
Exact |
| No |
Wildcard |
| Yes |
Wildcard |
| Yes |
Wildcard |
| No |
Regex |
| Yes |
Regex |
| No |
Path
ALB supports three matching types for request paths. All path values must start with /.
Matching type | How it works | Input constraints |
Exact match | The request path must exactly equal the configured value | Uppercase/lowercase letters, digits, and |
Wildcard match | The request path must match the wildcard pattern; | Same character set as exact match |
Regular expression match | The request path must match the regular expression |
|
ALB does not support longest-prefix matching (unlike Nginx). To replicatelocation /abcin Nginx, use the wildcard pattern/abc/*in ALB.
Troubleshooting: a new traffic forwarding rule cannot proxy requests to the backend application
If a newly added ALB traffic forwarding rule on the SAE side cannot proxy requests to the backend server, troubleshoot in the following order:
Confirm that the ALB instance and the SAE application are in the same VPC and namespace.
Confirm that the domain name has completed CNAME resolution and that a default traffic forwarding rule is configured on the listener.
In the SAE console, check the Path matching rule.
/is an exact match and matches only the root path request;/*is a wildcard match that matches all path requests, so it evaluates the URI of the request against the pattern. When a rule with path/cannot proxy, change it to/*. Note that/.*is a regular expression match:.and*are special characters, so it must be configured in regular expression mode.In multi-application, multi-domain scenarios, use the SAE console to configure an independent domain name traffic forwarding rule for each SAE application, and set the path to
/*.
ALB traffic forwarding rule configuration changes may take approximately 1–2 minutes to take effect. If the request cannot reach the backend server immediately after a change, wait a moment and retry.
Examples for /sys/aaa/HOST:
Matching type | Input | Matches? |
Exact |
| Yes |
Exact |
| No — trailing slash is not matched |
Exact |
| No — partial path is not matched |
Wildcard |
| Yes |
Wildcard |
| No |
Regex (case-sensitive) |
| Yes |
Regex (case-insensitive) |
| Yes |
Regex (case-sensitive) |
| No |
Forwarding actions
The forwarding action determines what ALB does with a matched request. Before choosing an action type, understand the fundamental difference between redirect and rewrite:
Dimension | Redirect | Rewrite |
URL visible to user | Changes in the browser address bar | No change — the original URL is preserved |
Processing location | Browser-side (client follows the redirect) | Server-side (ALB rewrites transparently) |
HTTP status code | 301, 302, 303, 307, or 308 | No status code change |
Common uses | Domain migration, HTTP-to-HTTPS enforcement, fixing broken links | Clean URLs, hiding internal path structures |
Rewrite policy
A rewrite policy is available when you select Forward to as the action. It modifies the request path or query before forwarding to the backend — the client never sees the rewritten URL.
Path rewrite with regex capture groups
When the forwarding condition uses a regular expression, you can use capture groups in the rewrite path.
How it works: Each pair of parentheses()in the condition regex captures a segment of the matched path. The first three captured groups are stored as${1},${2}, and${3}. Use these variables in the rewrite path to construct the new URL sent to the backend. Rules: - The number of()groups in the condition must equal the number of${}variables in the rewrite path. - Only${1},${2}, and${3}are supported — you cannot substitute other characters.
Example: Strip a path prefix and suffix using two capture groups.
Condition path regex: /sys/(.*)/(.*)/aaa Rewrite path: /${1}/${2}
Client request path |
|
| Backend receives |
|
|
|
|
|
|
|
|
|
|
|
|
Query rewrite
The query string is the portion of the URL after ?. Set the rewrite query to ${query} to forward the original query parameters to the backend unchanged.
Example: For www.example.com/test/test1?x=1, the query content is x=1.
Redirection policy
A redirection policy sends the client to a different URL. Configure six parameters: protocol, domain name, access port, path, query, and status code.
Reserved variables
Use the following variables to retain components from the original request in your redirect target:
Variable | What it retains |
| Original protocol (HTTP or HTTPS) |
| Original domain name |
| Original port |
| Original query parameters |
Protocol
An HTTP listener can redirect to HTTP or HTTPS. An HTTPS listener can only redirect to HTTPS.
Path redirect with regex capture groups
Path redirect follows the same capture-group mechanics as path rewrite. The condition path regex captures segments into ${1}, ${2}, and ${3}, and the redirect path uses these variables to construct the target URL.
Rules (same as rewrite):
The number of
()groups in the condition must equal the number of${}variables in the redirect path.Only
${1},${2}, and${3}are supported.
Example: Strip a path prefix and suffix using two capture groups.
Condition path regex: /sys/(.*)/(.*)/aaa Redirect path: /${1}/${2}
Client request path |
|
| Redirected to |
|
|
|
|
|
|
|
|
Status codes
The default status code is 301. Choose the status code based on whether the redirect is permanent or temporary and whether the HTTP method must be preserved:
Status code | Type | HTTP method preserved? |
301 (default) | Permanent redirect | No |
302 | Temporary redirect | No |
303 | See other location | No |
307 | Temporary redirect | Yes |
308 | Permanent redirect | Yes |
Use 307 or 308 when clients send POST or PUT requests and the redirected endpoint must receive the same method.