Route incoming traffic to your SAE applications using a cloud-native API Gateway. This guide walks you through creating a gateway route in the SAE console and explains the key configuration options.
Background
A cloud-native API Gateway is a unified solution that combines traffic gateways, microservice gateways, security gateways, and AI gateways into a single platform. It handles service discovery, load balancing, and cross-service communication, replacing the fragmented setup that traditional distributed gateways require. For more information, see What is a cloud-native API gateway?.
Prerequisites
Before you begin, ensure that you have:
MSE: A cloud-native API Gateway instance. See Create a cloud-native API Gateway instance.
SAE: A namespace in the same region as the gateway, bound to the same Virtual Private Cloud (VPC). See Create a namespace.
SAE: A deployed application in that namespace.
Create a gateway route
Go to the SAE Gateway Routing page, select a region and namespace, and then click Create Gateway Route.
On the Create Route page, configure the following parameters and click Save.
Basic settings
| Parameter | Description | Example |
|---|---|---|
| Route name | A custom name for the routing rule. | demo |
| Network type | The network through which requests are forwarded. Internet: traffic from the public internet, charged based on actual forwarded traffic. Private: traffic within the current VPC only, not charged. | Internet |
| Gateway type | Select Cloud-native API Gateway. | Cloud-native API Gateway |
| Gateway instance | Required when Gateway type is Cloud-native API Gateway. Select an instance in the same region and VPC as the namespace. To create a new instance, click Create Cloud-native API Gateway. See Create a cloud-native API Gateway instance. | demo |
| Domain name | One or more domain names to match. To add a new domain, click Create Domain Name. See Create a domain name. | www.demo.com |
Matching conditions
Configure how the gateway identifies which requests this route handles.
Path matching
Set the path pattern to match in HTTP requests.
| Match type | Behavior | Example |
|---|---|---|
| Equals | Exact match only. | /user matches /user only. |
| Prefix | Matches any path starting with the value. | /user matches /user, /user/profile, and /user/settings. |
| Regular expression | Matches paths against a regex pattern. | user (character class) matches paths containing that pattern. |
When multiple rules share the same match type, the rule with the longer path takes priority. Across match types, priority runs: Equals > Prefix > Regular expression.
Priority example
The table below shows which route SAE selects for sample requests:
| Request path | Selected route | Reason |
|---|---|---|
/user | Equals: /user | Exact match takes highest priority. |
/user/profile | Prefix: /user | No exact match; prefix catches it. |
/account | Regex: user | No exact or prefix match; regex applies. |
Other matching conditions
| Parameter | Description | Example |
|---|---|---|
| Method | HTTP methods to match. Leave blank to match all methods. | GET |
| Request header | Header name, match type, and value. When multiple rules share the same conditions, the rule with more header parameters wins. | Name: demo, Condition: Prefix, Value: value |
| Request parameter (Query) | Query string key, match type, and value. When multiple rules share the same conditions, the rule with more query parameters wins. | Key: key, Condition: Prefix, Value: value |
Service source and backend
Service source
Select the service registry that matches how your application registers itself.
| Option | When to use |
|---|---|
| MSE Nacos | Application uses MSE Nacos for service registration and discovery. Requires selecting an MSE Nacos instance and MSE Nacos namespace. |
| K8s Service | Application uses Kubernetes ServiceNames. Supports multi-language service registration and discovery, and assigns fixed domain names to avoid IP address changes after deployment. |
The service source must match the service registration and discovery method used by your application.
Scenarios and backend service
| Parameter | Description | Example |
|---|---|---|
| Scenarios | Single service: routes all matching requests to one backend. Multiple services (canary release): splits traffic across multiple backends by weight. See Overview of routing methods. | Single service |
| Backend service | The target application, service name, protocol, and port. When using multiple services, all traffic weight percentages must add up to 100%. | Application: demo, Service: demo, Protocol: Auto Read, Port: 80 |
Canary release example
In a canary release (multiple services scenario), you can split traffic by percentage to validate a new version before full rollout:
Stable version (
demo-v1): 90% of trafficCanary version (
demo-v2): 10% of traffic
Once the canary version is stable, gradually shift the percentage until it handles 100% of traffic.
Advanced configuration
| Parameter | Description | Default | Example |
|---|---|---|---|
| Fallback | Enable to specify a fallback service. When no healthy node is available for the primary backend, the gateway forwards requests to the fallback service instead. Currently supported only between HTTP services. | Off | Enabled |
| Timeout (s) | Maximum time in seconds the gateway waits for a backend response. Set to 0 for no timeout. | 60 | 60 |
| Retries | Number of retry attempts after a failed request. Set to 0 to disable retries. | — | 2 |
| Retry conditions | Events that trigger a retry attempt. See Configure a retry policy. | — | connect-failure, cancelled |
| Retry status codes | HTTP status codes that trigger a retry. | — | 502 |
Manage routing rules
After creating a route, go to the Gateway Routing page to view, edit, or delete gateway routes.
Next steps
Overview of routing methods — learn how single-service and multiple-service routing work.
Configure a retry policy — fine-tune retry behavior for your routes.