Configure rules to forward requests destined for the same domain name but different URLs to implement precise traffic forwarding - Server Load Balancer

Classic Load Balancer (CLB) is defaulted to direct all requests a listener checks to the backend server group associated with the listener. This may result in uneven resource allocation, performance degradation, and complex operations and maintenance. This default configuration especially cannot meet increasingly diverse business needs. You can configure forwarding rules for CLB listeners to direct traffic to different backend server groups. This enables granular traffic management and service isolation, improves resource utilization, ensures service stability, and optimizes user experience.

Feature overview

The forwarding policies of CLB listeners allow you to precisely distribute incoming client requests to different backend servers based on domain names and URL paths, achieving efficient and rational traffic distribution.

CLB supports configuring domain name-based and URL-based forwarding rules for listeners. You can configure forwarding rules to precisely forward client requests to different backend server groups. This allows you to optimize load balancing among your server resources.

Key features

Domain name-based forwarding rules

Matching modes: CLB supports exact matching and wildcard pattern matching (including a single wildcard and multiple wildcards). For example, www.aliyun.com is an exact match, while *.aliyun.com and *.market.aliyun.com are wildcard pattern matches.

This matching priority principle is followed: Exact matching prevails over wildcard pattern matching. If a request matches multiple wildcard domain names, a higher-level wildcard domain name prevails over a lower-level wildcard domain name. This ensures that the most precise rule is always executed.

The following table shows an example of matching priorities. "✓" indicates that the domain name of the request matches the domain name specified in the forwarding rule. "×" indicates that the domain name of the request does not match the domain name specified in the forwarding rule.

Mode	Request URL	Domain name-based forwarding rule
Mode	Request URL	www.aliyun.com	*.aliyun.com	*.market.aliyun.com
Exact matching	www.aliyun.com	✓	×	×
Wildcard pattern matching	market.aliyun.com	×	✓	×
Wildcard pattern matching	info.market.aliyun.com	×	×	✓

URL-based forwarding rules
- Matching logic: If a request matches multiple wildcard domain names, the match with the longest prefix prevails over all the other matches. For example, if rules to forward requests destined for both /abc and /abcd are configured, a request destined for /abcde applies to the /abcd rule.
- Rule combination: You can configure multiple policies for a listener to forward requests destined for the same domain name but different URLs to different backend server groups. This helps achieve complex traffic distribution. For example, you can direct read requests and write requests to different server groups.

How it works

You can configure multiple forwarding rules for a listener, each of which associates a different vServer group with the listener. The following figure shows the matching priority. When no forwarding rule is configured, CLB forwards requests to the default server group associated with the listener. When certain forwarding rules are available, CLB first checks the domain name-based and URL-based rules among all rules. If a match is found, the request is forwarded to the server group associated with the listener specified in the rule. If no match is found, the request is forwarded to the default server group associated with the listener.

Use scenarios

Microservices model: In a microservices architecture, an application is composed of multiple independent microservices, each deployed on different instances or containers. These microservices work together to provide the complete application functionality. By using an intelligent URL-based routing mechanism, client requests are accurately distributed to the microservice instances that handle the required business logic. For example, on an e-commerce platform, user authentication requests, order processing requests, and payment requests are intelligently routed to the specified instances providing the authentication service, order service, and payment service based on the URL contained in the HTTP request.
Read and write request isolation: For services with high concurrency and strict data consistency requirements, such as order processing services, a read and write isolation strategy can be used to optimize service performance and data security. Read operations and write operations are handled by different database instances or clusters. Read operations are routed to the read database, while write operations are directed to the write database.
Multitenancy: For a multitenant application, to achieve service isolation and personalization for different tenants, independent environments need to be provided for the tenants. For example, create tenant-specific subdomain names to differentiate the service endpoints for different tenants. What's more, different URLs can be used to distinguish endpoints for different service functionalities. This not only ensures the data security and privacy for each tenant but also enables each tenant to enjoy a customized user experience and interface.

Limits

Only Layer 7 HTTP or HTTPS listeners support forwarding rules.
Backend server groups specified in forwarding rules must be vServer groups.
The number of domain name-based and URL-based forwarding rules that can be configured for an HTTP or HTTPS listener cannot exceed 40. For more information, see Limits.

Example scenario

An education platform wants to provide diverse online learning services, including video courses and online question libraries, through a single domain name. Video services require high bandwidth and media processing capabilities, while question library services require intensive computing and short response time. Initially, all services were deployed on a single server group, resulting in uneven resource allocation and affecting the access speed of the question libraries during peak video coursing periods, damaging user experience. Especially when user traffic surges, the server load is too high to ensure stable service operation.

In this scenario, the platform uses Alibaba Cloud CLB and configures traffic forwarding rules for requests destined for the same domain name but different URLs. As shown in the following figure, requests for the /video/ URL are forwarded to the video server group RS1, ensuring that video services are equipped with sufficient bandwidth and processing capabilities. Requests for the /exam/ URL are forwarded to the question library server group RS2, optimizing computing resources for short response time to queries and submissions. Using this solution, the plarform achieves precise routing and ensures that each service runs efficiently and independently.

Prerequisites

A virtual private network (VPC) named VPC1 is created in the China (Shanghai) region and vSwitches VSW1 and VSW2 are created in Zone E and Zone G, respectively.
Elastic Compute Service (ECS) instances ECS01 and ECS02 are created in VSW1 and VSW2, respectively, and application services are deployed on ECS01 and ECS02. Requests to the ports used by the application services are allowed by the security groups specified for ECS01 and ECS02.
The following sample code shows how the testing application services are deployed on ECS01 and ECS02 in this example:
Sample code for deploying testing application services on the ECS instances
Sample code for deployment on ECS01
```
yum install -y nginx
systemctl start nginx.service
mkdir /usr/share/nginx/html/video
cd /usr/share/nginx/html/video
echo "Hello World ! This is video service." > index.html
```
Sample code for deployment on ECS02
```
yum install -y nginx
systemctl start nginx.service
mkdir /usr/share/nginx/html/exam
cd /usr/share/nginx/html/exam
echo "Hello World ! This is exam service." > index.html
```
Two vServer groups RS1 and RS2 are created for your CLB instance by creating and managing CLB vServer groups, ECS01 is added to RS1, and ECS02 is added to RS2. The same port configurations are applied to the vServer groups as to the application services. In this example, the default port used by the NGINX service is used, which is port 80.
An HTTP listener or an HTTPS listener is configured for your CLB instance.
A domain name is registered on Alibaba Cloud and an Internet content provider (ICP) number is obtained for the domain name.

Procedure

Step 1: Configure forwarding rules

Log on to the CLB console.
In the top navigation bar, select the region to which your CLB instance belongs.
On the Instances page, click the ID of the CLB instance that you want to manage.
Click the Listener tab, find the listener that you want to manage, then click Set Forwarding Rule in the Actions column.
In the Add Forwarding Policy panel, configure the parameters as shown and described below, and click Add Forwarding Policy.
- Domain Name: Enter the custom domain name that you have registered and obtained an ICP number for.
- URL: Specify the URL from which requests are forwarded.
Note
If the URL of a request contains special characters, you must use URL escape codes to convert the special characters. For example, if the URL of a request contains a number sign (#), the number sign must be converted into the escape code (% 23). This way, the system can match the URL of the request against the URL-based forwarding rule.

Step 2: Configure health checks

Note

By default, when CLB performs HTTP health checks on a backend server, CLB sends HTTP requests to the default homepage configured on the backend server. If you do not want to use the default homepage for health checks, you can specify a URL.

On the Instances page, click the ID of the CLB instance that you want to manage.
On the Listener tab, find the listener that you want to manage and click Set Forwarding Rule in the Actions column.
In the Add Forwarding Policy panel, in the Forwarding Rules area, find the forwarding rule that you want to manage, and click Modify. Repeat steps 3 to 4 for all the forwarding rules that you want to manage.
In the Modify Forwarding Rule panel, enable Advanced Setting and Health Check, then set the Health Check Path parameter. You can set it to a URL configured for the forwarding rule, for example, /video, as shown in the following figure.

Step 3: Create a DNS record

Note

For domains not registered on Alibaba Cloud, you must first add the domain name to Alibaba Cloud DNS before you can create a DNS record.
If your CLB instance is internal-facing, you must first associate an Elastic IP address (EIP) with it, then create an A record to map the domain name to the EIP for Internet access.

In the left-side navigation pane, choose CLB > Instances.
On the Instances page, find the CLB instance that you want to manage and copy the Endpoint of the CLB instance.

Perform the following steps to create an A record:

Log on to the Alibaba Cloud DNS console.
On the Authoritative DNS Resolution page, find the domain name that you want to manage, and click DNS Settings in the Actions column.
On the DNS Settings page, click Add DNS Record.

In the Add DNS Record panel, configure the following parameters, use the default values for all the other parameters or set them based on actual conditions, and click OK.

Parameter	Description
Record Type	Select A from the drop-down list.
Hostname	The prefix of your domain name. In this example, www is entered. Note If you use a root domain name, enter @.
Record Value	Enter the A address corresponding to your domain name. In this example, the IP address of your CLB instance is used.

Step 4: Test the network connectivity

Use a browser to access http://<Domain name>/<URL>/, view the response result, and check whether the request is routed to the specified server group.

Access the video service at http://www.***-example.com/video/ and check whether the request is routed to the vServer group RS1 for providing video services.
Access the question library service at http://www.***-example.com/exam/ and check whether the request is routed to the vServer group RS2 for providing question library services.

Related issues

Does the CLB forwarding rules for requests destined for the same domain name but different URLs support URL redirections?

No, it does not. The CLB forwarding rules focus on traffic forwarding. If you want to configure forwarding rules containing URL redirections, consider Application Load Balancer (ALB). For more information, see Configure listener forwarding rules.

Why is the backend server group declared unhealthy after I configured forwarding rules for different URLs?

CLB performs health checks according to the health check path set for listeners, which is the root path by default, rather than URLs configured for a forwarding policy. If you have configured forwarding rules for requests destined for the same domain name but different URLs, but have not modified the health check path for the listeners, the backend server group may be declared unhealthy unexpectedly. You must modify the health check path based on your needs in the forwarding rules.

Will I be billed for domain name-based forwarding rules?

No, you will not. If your CLB instance is internal-facing and you associate an EIP with your CLB instance to change its network type to Internet-facing, you are charged for Internet data transfer. For specific billing information, see CLB billing.

References

To configure multiple HTTPS domain names for a CLB instance, see Configure a CLB instance to serve multiple domain names over HTTPS.
If your current application system uses the HTTP protocol for communication and you want to smoothly migrate to the HTTPS protocol, see Use CLB to redirect requests from HTTP to HTTPS.
To have a smooth migration from CLB to ALB, see Best practices for migrating Layer 7 listeners from CLB to ALB by using a wizard and Best practices for manually migrating Layer 7 listeners from CLB to ALB.