HTTP redirection to HTTPS
When your service needs to enforce HTTPS, ALB lets you redirect HTTP traffic at the load balancer level — backend servers never handle unencrypted requests, and users get seamless HTTPS access without client-side changes.
How it works
ALB provides HTTP to HTTPS redirection by configuring forwarding rules on the HTTP listener. Two redirect strategies are available:
Strategy | Condition | Best for |
Redirect all HTTP traffic | Path | Enforcing HTTPS site-wide, full HTTPS migration |
Redirect based on HTTP headers | Specific header key/value (e.g., | Selective redirects, language-based routing, device-type routing |
Key benefits:
Flexible configuration: Supports custom redirection rules based on path, HTTP headers, and other parameters to meet the requirements of complex use cases.
Status code settings: Supports different HTTP status codes for redirection, such as 301 (permanent redirect) or 302 (temporary redirect).
Performance optimization: Offloads redirection to the load balancer, allowing backend servers to focus on core business processing.
Prerequisites
Before you begin, make sure you have:
An Internet-facing ALB instance (Basic, Standard, or WAF-Enhanced edition)
A server group with HTTP as the backend protocol, containing ECS01 and ECS02 with your application deployed
An HTTP listener on port 80
A custom domain name with ICP filing completed and a CNAME record pointing to the ALB instance
A server certificate uploaded to Certificate Management Service and associated with your custom domain name
To set up test backend servers, run the following commands on each ECS instance (this example uses Alibaba Cloud Linux 3 with NGINX):
yum install -y nginx
systemctl start nginx.service
cd /usr/share/nginx/html/
echo "Hello World ! This is ECS01." > index.htmlRedirect all HTTP requests to HTTPS
This method unconditionally redirects every HTTP request to the HTTPS listener. Use it when the entire site must use HTTPS.
Step 1: Create an HTTPS listener
Log in to the ALB console and select the region where your ALB instance is deployed.
On the Instances page, click the ID of the target instance.
On the Listener tab, click Create Listener.
On the Configure Server Load Balancer page, complete the following steps. For parameters not listed here, keep the defaults or adjust as needed. For the full parameter reference, see Add an HTTPS listener.
In the Configure Listener step, set Listener Protocol to HTTPS and Listener Port to 443. Click Next.
In the Configure SSL Certificate step, select your server certificate and a TLS security policy. Click Next.
In the Select Server Group step, select your server group and review the backend server list. Click Next.
In the Configuration Review step, confirm the settings and click Submit.
Step 2: Add a forwarding rule to the HTTP listener
On the Listener tab, find the HTTP listener and click View/Modify Forwarding Rule in the Actions column.
On the Forwarding Rules tab, click Add New Rule.
In the Add Forwarding Rule section, configure the following parameters and click OK. For other parameters, see Configure listener forwarding rules.
Parameter
Value
Add Condition
Select Path and enter
/*Action
Select Redirect To
Protocol
HTTPS
Port
443Status Code
301(default)
Step 3: Verify the redirect
From any machine with internet access, run:
curl -v -L http://<custom_domain_name>A status code 301 in the response confirms that ALB redirected the request to HTTPS. The response body comes from one of the backend servers (ECS01 or ECS02 — ALB load-balances between them).
Run the command again — the responding server changes to ECS02, confirming load balancing is working.
Redirect requests based on HTTP headers
This method redirects only requests whose headers match a specified condition. The following example redirects requests with Accept-Language: zh-CN,zh to HTTPS — all other requests are forwarded normally.
Step 1: Create an HTTPS listener
Follow the same steps as Step 1 in "Redirect all HTTP requests to HTTPS" to create an HTTPS listener on port 443.
Step 2: Add a forwarding rule to the HTTP listener
On the Listener tab, find the HTTP listener and click View/Modify Forwarding Rule in the Actions column.
On the Forwarding Rules tab, click Add New Rule.
In the Add Forwarding Rule section, configure the following parameters and click OK. For other parameters, see Configure listener forwarding rules.
Parameter
Value
Add Condition
Select HTTP Header
Key
Accept-LanguageValue
zh-CN,zhAction
Select Redirect To
Protocol
HTTPS
Domain Name
Your custom domain name
Port
443Status Code
302
Step 3: Verify the redirect
From any machine with internet access, run:
curl -v -L -H "Accept-Language: zh-CN,zh" http://<custom_domain_name>A status code 302 confirms that ALB matched the header condition and redirected the request to HTTPS. The response body comes from ECS01 or ECS02.
Run the command again — the responding server changes to ECS02.
HTTP redirect status codes
The default status code for ALB redirects is 301. Select a different code based on your redirect semantics.
Status code | Type | Behavior |
| Permanent redirect | Clients update bookmarks and always use the new URL |
| Temporary redirect | Clients continue using the original URL for future requests |
| Temporary redirect | Regardless of the original method, clients use GET for the redirected request |
| Temporary redirect | Clients must repeat the request with the same method (POST stays POST) |
| Permanent redirect | Clients must use the same method for all future requests (POST stays POST) |
For the full specification, see HTTP/1.1 Standard (RFC 7231).
What's next
Stronger encryption: End-to-end HTTPS encryption encrypts traffic between clients and ALB, and between ALB and backend servers.
Client authentication: Mutual authentication on an HTTPS listener requires both sides to verify identity before establishing a connection, blocking unauthorized clients.
Advanced forwarding rules: Learn the full set of forwarding conditions and actions in Listener forwarding rules.
Traffic mirroring: Mirror production traffic to a staging environment lets you test new configurations without affecting live traffic.
Canary releases: Use ALB to implement a canary release gradually routes traffic to new application versions using condition-based or weight-based forwarding rules.