ALB FAQ-Server Load Balancer(SLB)-阿里云帮助中心

Instances and specifications

ALB instance specifications

You do not need to select instance specifications for ALB. An upgraded ALB instance can achieve 1 million QPS per instance through VIP automatic elasticity. For details about ALB instance performance, see Instance performance metrics.

Note

For ALB instances created before the upgrade, performance limits vary by IP mode (static IP or dynamic IP). These instances have an inelastic VIP and require dynamic scaling of IP addresses to achieve 1 million QPS per instance.

Conversion between IPv4 and dual-stack instances

No.

You can only create a new IPv4 instance or dual-stack instance.

Network and EIPs

Disable ping for an ALB VIP

Upgraded ALB instances let you manage access traffic by using a security group. You can add an inbound rule to the security group of the instance to deny ICMP traffic.
For non-upgraded ALB instances, you can associate the bound Elastic IP Address (EIP) with Cloud Firewall and configure a policy to deny inbound ICMP traffic.

Increase public bandwidth for an ALB instance

If an ALB instance is not added to a shared bandwidth plan, the default maximum public bandwidth for a single ALB instance (deployed in two availability zones) is 400 Mbps.

To obtain higher bandwidth, purchase a shared bandwidth plan and add the EIPs associated with the ALB instance to the plan.

For more information about how to purchase a shared bandwidth plan, see Create and manage bandwidth plans.
For more information about how to add EIPs to a shared bandwidth plan, see Create and manage ALB instances and Adjust the maximum bandwidth of a public instance.

Offset ALB traffic costs with a data plan

When an ALB instance uses an Elastic IP Address (EIP) to provide public-facing services, a data transfer plan can offset the public data transfer costs generated by the EIP.
When an ALB instance uses an Anycast Elastic IP Address (Anycast EIP) to provide public-facing services, a data transfer plan cannot offset the public data transfer costs generated by the Anycast EIP.

EIP types for an ALB instance

ALB instances support only pay-as-you-go EIPs. The following table describes the EIP types that you can associate with an ALB instance.

Billing method	Internet billing method	Line type	Protection type
Pay-as-you-go	Pay-by-traffic	BGP (Multi-ISP)	Default
	Pay-by-traffic	BGP (Multi-ISP)_Pro	Default
	Pay-by-traffic	BGP (Multi-ISP)	DDoS protection (enhanced)

When you associate an EIP with an ALB instance, note the following:

The EIPs associated with all availability zones of an ALB instance must be of the same type.
Before you associate an EIP, ensure that it is not added to a shared bandwidth plan. If you need to use a shared bandwidth plan, you can add the EIP to it from the load balancer console after you associate the EIP with the ALB instance. The line type of the EIP must be the same as the line type of the shared bandwidth plan. Both subscription and pay-as-you-go shared bandwidth resources are supported. For more information, see Adjust the maximum bandwidth of a public instance.
You cannot associate a subscription EIP or a pay-as-you-go EIP billed by bandwidth.
If you select Purchase or Automatically Assign Public IP Address when you assign an EIP to an ALB instance, the system creates a pay-as-you-go (pay-by-traffic) EIP of the BGP (Multi-ISP) line type with default protection.

Associate EIPs with private ALB instances

Yes.

If you need to associate an EIP with a private ALB, you can convert the private ALB to a public ALB by changing the network type of the instance. For detailed steps, see Change the network type of an ALB instance.

When you change the network type from private to public, an EIP is associated with the instance, which incurs public data transfer costs. For more information, see EIP Billing.

Change to a BGP (Multi-ISP)_Pro EIP

You can change the network type of the ALB instance:

Change the network type of the ALB instance from public to private, which disassociates the EIP from the instance.
Change the network type back from private to public and select two BGP (Multi-ISP)_Pro EIPs that you have created.

Uneven traffic distribution across EIPs

This can happen for the following reasons:

The domain name for your service is not resolved to the DNS name of the ALB instance. Instead, it is resolved to a single EIP associated with the instance.
A Layer 7 proxy, such as Web Application Firewall (WAF) or Anti-DDoS Pro, is deployed in front of the ALB instance. The origin-pull algorithm of the proxy, such as IP hash, prevents even traffic distribution across the EIPs.
Some clients cache the A records returned by DNS resolution, which causes a large number of requests to be continuously sent to the same EIP.

DNS failover for ALB

Upgraded ALB instances support DNS failover and recovery by default.

Note

For non-upgraded ALB instances, only those in static IP mode support DNS failover and recovery. Instances in dynamic IP mode do not.

After a DNS failover, health checks on the VIP in the corresponding availability zone stop. DNS then removes the VIP or EIP in that availability zone, including both IPv4 and IPv6 addresses, from the resolution of the ALB domain name. You cannot remove only the IPv4 or IPv6 VIP address.

High ECS public traffic when using ALB

Traffic forwarded from an ALB instance to backend ECS instances travels over the VPC internal network and does not consume the public bandwidth of the ECS instances. If your backend ECS instances still have high public traffic, consider the following reasons:

Inbound traffic bypasses the ALB instance: The domain name still resolves to the public IP address of an ECS instance, or clients access the ECS instance directly by using its public IP address. This causes traffic to bypass the ALB instance.
Outbound requests from the ECS instances: Applications on the ECS instances initiate outbound requests to the internet for software updates, log uploads, or external API calls. This generates outbound public traffic.

Troubleshooting:

Verify that the domain name for your service resolves to the address of the ALB instance, not the public IP address of an ECS instance.
Check the inbound rules of the security group for the ECS instances to verify if the service ports are still open to the public.
On the ECS instances, use tools like iftop or nethogs to identify the processes and destination addresses that are consuming public bandwidth.

Listeners and forwarding

Does ALB support traffic mirroring?

Yes. For more information, see Use ALB traffic mirroring to run simulated stress tests.

QPS limit issues in forwarding rules

How it works: The load balancing system uses a cluster of servers to provide services for ALB instances. All incoming requests are evenly distributed among these load balancing servers for forwarding. Therefore, the QPS limit you set in a forwarding rule is divided among multiple servers in the cluster.

Calculate the QPS limit for a single load balancing server as follows: QPS limit per server = Total configured QPS / (N-1), where N is the number of servers in the forwarding group. For example, if you set the QPS limit for a forwarding rule to 1,000 QPS in the console and there are 8 servers, the maximum QPS for a single server is 1000 / (8-1) = 142 QPS.
Cause: With a small number of persistent connections, not all servers in the forwarding group may be assigned a persistent connection. This can prevent the ALB instance from reaching its overall QPS limit.
Recommendation: Set a reasonable QPS limit for your forwarding rules based on your business requirements and the system's traffic distribution to prevent unintentional throttling. For more information about how to set a QPS limit in a forwarding rule, see Add a forwarding rule.

Request length limits and adjustments

ALB supports a maximum URI length of 32 KB and a maximum request header length of 32 KB. These limits cannot be adjusted. For access logs, the default maximum length for custom headers is 1 KB, and this can be increased to 4 KB. To request an increase, contact your account manager.

If a client request exceeds these limits, the ALB instance may return a 400 or 414 status code. For more information, see ALB exception status codes.
For large data transfers, use POST requests. The maximum body size for a POST request is 50 GB.

Scope of ALB processing time

Yes, ALB processing time includes the time to receive data from the client and send a response.

Time to receive client data: This is the read_request_time, which is the total time the load balancer spends reading a client request. It includes the time to receive the HTTP request header (read_header_time) and the request body (read_body_time).
Time to send response data: This includes the time spent sending the response to the client.

Maximum requests per persistent connection

A single persistent connection supports a maximum of 100 consecutive requests. The connection is automatically closed after this limit is exceeded.

If you use an HTTPS listener and enable HTTP/2.0, the limit increases to 1,000 requests per persistent connection.

QUIC listener Client Hello packet length limit

When you use a QUIC listener, ALB enforces a minimum length of 1,024 bytes for the client's Client Hello packet. If the packet is smaller than this, ALB returns a "client hello too small" error and closes the connection. To pass this check, pad the Client Hello packet with null characters to reach the 1,024-byte minimum.

Notes on using ALB Ingress

As a best practice, do not manually modify an ALB instance in the console if it was created by ALB Ingress. Use AlbConfig as the source of truth for the ALB configuration and synchronize changes through the AlbConfig resource. For more information about ALB Ingress, see Manage ALB Ingresses and ALB Ingress feature guide.

If you make manual changes in the console, the next AlbConfig synchronization will overwrite them. This can lead to issues such as access logs being disabled or routing rules being deleted.
If you find that a feature available in the ALB console is not supported in AlbConfig, please contact us.

Cross-origin support FAQ

Preflight request errors in cross-origin configuration

If the "Allowed Request Headers" field is not set to "*" but instead lists specific header names, try changing the setting to "*" for testing purposes. If this resolves the issue, it indicates that the Access-Control-Request-Headers field of the preflight request contains a header name that is not on your allowed list, causing the preflight request to fail.

Different routing for preflight and actual requests

ALB supports multiple methods for matching forwarding rules. A cross-origin preflight request is unique because its headers and method differ from the actual request. To avoid issues where the preflight and actual requests are routed to different forwarding rules, some of which may not have cross-origin rules configured, we recommend using domain-based forwarding rules when implementing cross-origin resource sharing (CORS).

Generating the Access-Control-Allow-Headers header

Preflight request

When a browser initiates a cross-origin request that meets the following conditions, it first sends a preflight request that uses the OPTIONS method:
- The request method is OPTIONS.
- The request contains the Access-Control-Request-Method header.
In this case, ALB returns the Access-Control-Allow-Headers response header based on the cross-origin forwarding rule you configured in the console. The value of this header is a list of allowed request header fields from the rule, for example:
```
DNT,X-CustomHeader,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Authorization
```
Standard cross-origin request

For non-OPTIONS requests or simple requests that do not meet the preflight conditions, ALB does not return the Access-Control-Allow-Headers response header.

Referencing original header values in forwarding rules

For Key, enter the name of the header you want to insert. For Value, select a referencing method and enter the name of the original header whose value you want to reference. In the following example, a new header named abc-abc is inserted, and its value is referenced from the original header abc. The forwarding rule extracts the value from the original abc header and assigns it to the new abc-abc header.

The condition for this forwarding rule is an exact path match for /. In addition to inserting a header, the action is configured to Forward to a specific server group with a weight of 100.

Client

The client uses curl's -H parameter to include the custom request header abc:123456. The server returns 200 OK. The following command and output show an example:

curl http://xxx.xxx.174 -v -k -H abc:123456
*   Trying xxx.xxx.174:80...
* Connected to xxx.xxx.174 (xxx.xxx.174) port 80
> GET / HTTP/1.1
> Host: xxx.xxx 174
> User-Agent: curl/8.4.0
> Accept: */*
> abc:123456
>
< HTTP/1.1 200 OK
< Date: Sat, 13 Sep 2025 16:18:38 GMT
< Content-Type: text/html
< Content-Length: 4833
< Connection: keep-alive
< Vary: Accept-Encoding
< Set-Cookie: acw_tc=0a2a24fb17577803180911860e42646551283f5ec94793498a70af97834171;path=/;HttpOnly;Max-Age=1800
< Last-Modified: Fri, 16 May 2014 15:12:48 GMT
< ETag: "53762af0-12e1"
< Accept-Ranges: bytes

Server

GET / HTTP/1.1
RemoteIp: xxx.xxx.xxx.103
Host: xxx.xxx.xxx.174
X-Forwarded-For: xxx.xxx.xxx.103
User-Agent: curl/8.4.0
Accept: */*
abc: 123456
X-Sinfo: on
abc-abc: 123456
HTTP/1.1 200 OK
Server: nginx/1.20.1
Date: Sat, 13 Sep 2025 16:18:38 GMT
Content-Type: text/html
Content-Length: 4833

Preventing`X-Forwarded-For` field spoofing

Specify a dedicated header field to record the client's real IP:

For example, in a client > CDN > WAF > load balancer > ECS architecture, the CDN forwards the Ali-Cdn-Real-Ip field in the HTTP header. In WAF, configure client IP identification to use the Ali-Cdn-Real-Ip header field. On the backend NGINX server, set the log variable for the client's real IP to $http_Ali_Cdn_Real_Ip.
Use a Layer 4 listener (NLB or CLB) instead. This lets backend servers automatically obtain the client's real IP. For more information, see Obtain the client's real IP through a CLB Layer 4 listener.

HTTP version for backend connections

If a client request uses HTTP/1.1 or HTTP/2, the layer-7 listener connects to the backend server using HTTP/1.1.
If a client request uses a protocol other than HTTP/1.1 or HTTP/2, the layer-7 listener connects to the backend server using HTTP/1.0.

Why ALB removes response headers

To enable session persistence, ALB removes the Date, Server, X-Pad, and X-Accel-Redirect headers from the backend server's response.

Workaround: Add a prefix to your custom headers to avoid this behavior. For example, change Server to xl-server and Date to xl-date. Alternatively, use a forwarding rule to add a new response header.

Certificates and HTTPS

Does ALB support mutual CA authentication?

Basic ALB instances do not support mutual CA authentication. Standard and WAF-enabled ALB instances support mutual CA authentication when you add an HTTPS listener. To use mutual CA authentication on a Basic ALB instance, upgrade the instance edition.

When you configure mutual CA authentication, you can use a CA certificate issued by Alibaba Cloud or a third party.

If you use a CA certificate issued by Alibaba Cloud, you must select or purchase a private CA certificate.
If you use a CA certificate from a third party, you must select or upload a CA certificate. To upload a certificate, click Upload Self-signed CA Certificate in the Default CA Certificate drop-down list. On the Certificate Application Repository page, create a repository, set its data source to Uploaded CA Certificates, and then use the repository to upload your self-signed root CA or intermediate CA certificate.

Wildcard certificate rules

If you select a wildcard certificate when you add an HTTPS listener to an ALB instance, note the following rules:

When you select a wildcard certificate, ALB can only recognize wildcard certificates that contain a single wildcard character * and the wildcard character * is at the leftmost position. For example, ALB can recognize *.example.com and *test.example.com, but cannot recognize test*.example.com.
Wildcard domain name matching rules:
- Matching level: A wildcard domain name matches only single-level subdomains. For example, *.example.com matches test.example.com but not test.test.example.com.
- IDNA support:
  - If the wildcard character is the only character in the leftmost label of the wildcard certificate, an IDNA label can match the wildcard. For example, xn--fsqu00a.example.com can match *.example.com.
  - If the wildcard character is not the only character in the leftmost label of the wildcard certificate, an IDNA label cannot match that partial wildcard. For example, xn--fsqu00atest.example.com cannot match *test.example.com.
- Character support: The wildcard character (*) in a wildcard certificate can match only digits (0-9), uppercase and lowercase letters, and hyphens (-). For example, *.example.com can match test.example.com, but it cannot match test_test.example.com.

Can I upload a certificate directly to ALB?

No.

ALB uses certificates directly from Alibaba Cloud SSL Certificates Service. You must upload your certificate to the SSL Certificates Service console. Therefore, you cannot upload certificates directly in the ALB console. For more information, see Upload an SSL certificate.

Certificate update not reflected

This issue typically occurs when ALB is integrated with WAF 2.0 in transparent proxy mode and WAF has not yet synchronized the updated certificate. WAF periodically synchronizes certificates from ALB. To trigger an immediate synchronization, you can disable and then re-enable traffic redirection in the WAF console. This action forces a refresh of the certificate. Note: This action causes a brief service interruption of 1 to 2 seconds.

Health checks

Modify health check configuration

Log in to the Application Load Balancer (ALB) console.
In the left-side navigation pane, choose ALB > Server Groups.
On the Server Groups page, find the target server group and click its ID.
On the Details page, in the Health Check section, click Modify Health Check.
In the Modify Health Check dialog box, click Edit to the right of Health Check Settings, adjust the settings, and then click Save.

For more information, see ALB health checks.

502 errors with successful health checks

This is usually because the load on the backend servers of an Application Load Balancer (ALB) instance is too high. When the load on the backend servers of the ALB instance is too high, inconsistencies between health check results and access request results may occur. To learn how to check the load status of the backend servers, see Troubleshoot and handle high load issues on Linux instances.

Request forwarding when health checks fail

In this scenario, the ALB instance continues to forward requests to the servers based on the configured scheduling algorithm. This "fail-open" behavior is designed to minimize service disruption. If requests are not handled as expected, check the logs for issues with your backend servers or review your health check configuration. For more information, see Troubleshoot ALB health check failures.

Troubleshooting

Service inaccessible through ALB

Follow these steps to troubleshoot the issue:

Verify domain name resolution (CNAME): You cannot directly access a new ALB instance by using its DNS name. You must map your custom domain name to the DNS name of the ALB instance by using a CNAME record. You can use the nslookup or dig command to verify the resolution. For more information, see DNS name of an ALB instance.
Verify the instance network type: An ALB instance on a private network is accessible only from within its VPC, not over the public network. To grant public access, change the instance's network type to public and associate an EIP with it. For more information, see Change the network type of an ALB instance.
Verify the listener and forwarding rules: In the ALB console, verify that a listener exists, its port and protocol are correct, and its forwarding rule matches the requested domain name and path.
Check the health check status: In the ALB console, check the health check status of the backend servers. If a backend server fails health checks, ALB will not forward requests to it.
Verify that the backend service is running correctly: Log on to a backend server and run the command curl -I http://<backend_server_private_ip>:<port> to confirm that the backend service responds as expected.
Check access control and firewall settings: Verify that the access control or security group settings for the ALB instance do not block requests from the client's CIDR block. Also, ensure that iptables or third-party security software on the backend ECS instances does not block traffic from ALB's local IP CIDR block.

High latency through ALB

ALB operates at the application layer. Forwarding requests through ALB adds a small amount of latency compared to directly accessing the backend servers. This is normal.

If the latency is significantly higher than expected, follow these steps to troubleshoot:

Enable access logs and analyze latency fields: Enable ALB access logs and focus on the following fields:
- request_time: The time, in seconds, from when the load balancer receives the first request packet until it finishes sending the response.
- upstream_response_time: The time, in seconds, from when the load balancer establishes a connection with a backend server to when it finishes receiving data and closes the connection.
Identify the source of the latency:
- A high upstream_response_time indicates that the latency originates from the backend servers. Investigate your application's performance, database query efficiency, and resource utilization such as CPU and memory. Consider adding more backend servers to distribute the load.
- If request_time is significantly higher than upstream_response_time, the latency is likely on the network path between the client and ALB. Run continuous ping tests or MTR route traces from the client to the ALB service address to diagnose network link issues.
Cross-region access scenarios: If the client and the ALB instance are in different regions, network latency caused by the physical distance is unavoidable. Use Global Accelerator (GA) to optimize the cross-region access experience.

Unable to access ALB by domain name

After mapping your custom domain to the ALB instance's DNS name via a CNAME record, you might still be unable to access the service (for example, you receive a 403 error or the connection is reset). If this happens, the most common reason is an incomplete ICP filing for your domain.

Follow these steps to troubleshoot:

Verify the CNAME resolution configuration: Use the nslookup or dig command to verify that the domain name resolves correctly to the ALB instance's DNS name. For more information, see Configure CNAME resolution.
Check the ICP filing status of the domain name: Regulations in the Chinese mainland require that any domain name used for public network services must have a valid ICP filing; otherwise, access will be blocked. Log on to the Alibaba Cloud ICP Filing system to check the filing status. If the domain name does not have an ICP filing, complete the process first. For more information, see ICP Filing process.
Check whether an ICP filing transfer is required: If your domain name has an ICP filing with another cloud service provider but you are using it with Alibaba Cloud for the first time, you must perform an ICP filing transfer. This process registers your filing information with Alibaba Cloud. Access may be blocked until this transfer is complete.

Common error codes and causes

500 (Internal server error)

The backend server encountered an internal error and could not process the request.

The backend returns 500 directly: Check the access log. If upstream_status is 500, ALB likely passed through the status code from the backend. Investigate the backend service.
The backend server closed the connection unexpectedly: The backend server closed the connection before sending a complete response. Capture packets on the backend server to identify the cause of the unexpected connection closure.

502 (Bad gateway)

This error occurs when an HTTP or HTTPS listener receives a client request, but ALB fails to forward the request to a backend server or receive a response from it.

Troubleshooting approach: First, check the value of the upstream_status field in the access log to determine the next steps.

If upstream_status = 502: ALB passed through the 502 status code from the backend server. The issue lies with the backend service itself. Investigate your backend service. For example, check whether a backend Nginx or gateway layer is attempting to reverse proxy to an unreachable upstream.
If upstream_status is another value (such as 504, 444, or 500): The status that ALB returns to the client differs from upstream_status, which means ALB changed the status code. Investigate why the backend service is returning that specific status code by checking the backend Nginx, gateway, or application logs.
If upstream_status is - or empty: ALB did not receive any response from the backend. This means the request either never reached the backend, or the backend connection was abnormally terminated before a response was sent. Check the following causes in order:
- TCP communication between ALB and the backend server is failing. Verify that the backend service is running, the service port is listening correctly, and no iptables rules or third-party security software on the backend ECS are blocking the CIDR block of the VSwitch where the ALB instance is located. ALB communicates with backend servers by using a Local IP assigned by the VSwitch. You can capture packets to check if the TCP handshake is successful.
- The backend server's backlog is full. This causes the server to drop new connection requests. Run netstat -s | grep -i listen on the backend server and check for a drop counter.
- The backend server failed to process the request in time. Check the backend server's logs and review CPU and memory usage to identify any performance bottlenecks.
- The packet size of the client request exceeds the MTU of the backend server. This can cause short packets (such as health checks) to succeed while long packets fail. Capture packets on the backend server to analyze whether the packet length is within the required limits.
- The backend server's response has an invalid format or contains invalid HTTP headers. Capture packets on the backend server to analyze if the response format is standard-compliant.

503 (Service unavailable)

The server is temporarily unavailable, typically due to traffic exceeding limits or an unavailable backend service.

The backend returns 503 directly: Check the access log. If upstream_status is 503, ALB likely passed through the status code from the backend. Investigate the backend service.
The client request triggers ALB throttling:
- In Cloud Monitor, check the Requests per second metric.
- Cloud Monitor displays minute-level data and may not reflect second-level spikes. Check the access log. If the upstream_status field is -, the request did not reach the backend server.
- Check the response packet header. If it contains the ALB-QPS-Limited:Limited field, the request triggered ALB throttling.
Direct IP access or abnormal DNS resolution: This can concentrate traffic on only a few IP addresses and trigger throttling. Access ALB through its domain name (see Configure a CNAME for an ALB instance) and verify that DNS resolution works as expected.
The listener has no configured backend servers, or the configured backend servers have a weight of 0.

504 (Gateway timeout)

ALB timed out while waiting for a response from the backend server.

The backend returns 504 directly: Check the access log. If upstream_status is 504, ALB likely passed through the status code from the backend. Investigate the backend service.
The connection attempt from ALB to the backend server times out: This timeout is 5 seconds by default and cannot be changed. Capture packets to identify why the backend server is not responding in time.
Backend response timeout: The connection request timeout is 60 seconds by default. You can check the UpstreamResponseTime metric in Cloud Monitor and the upstream_response_time field in the access log to determine if the backend server's response timed out.

WAF integration

WAF 2.0 vs. WAF 3.0 integration

The following summarizes the differences:

WAF 2.0 transparent integration: Client requests first pass through WAF for inspection before WAF forwards them to an ALB or CLB instance. In this model, requests traverse two gateways, requiring you to maintain configurations such as timeouts and certificates on both WAF and the load balancer.
WAF 3.0 service-based integration: WAF is integrated as a bypass service. Client requests go directly to the ALB instance. Before forwarding a request to a backend server, the ALB instance extracts the request content and sends it to WAF for inspection. In this model, requests traverse only one gateway, eliminating the need to synchronize certificates and configurations between gateways and preventing synchronization issues.

For more information, see WAF 3.0 vs. WAF 2.0.

ALB and WAF integration

We recommend using service-based integration to enable WAF 3.0 protection for an ALB instance. This involves using a WAF-enhanced ALB instance.

Supported regions:

Area	Region
China	China (Chengdu), China (Qingdao), China (Beijing), China (Guangzhou), China (Hangzhou), China (Ulanqab), China (Shanghai), China (Shenzhen), China (Zhangjiakou), China (Hong Kong), China (Fuzhou), China (Heyuan)
Asia Pacific	Philippines (Manila), Indonesia (Jakarta), Japan (Tokyo), Malaysia (Kuala Lumpur), Singapore, Thailand (Bangkok), South Korea (Seoul)
Europe & Americas	Germany (Frankfurt), US (Silicon Valley), US (Virginia), Mexico (Mexico City)
Middle East	UAE (Dubai)

WAF-enabled ALB instances use the WAF 3.0 SDK integration model. If your account has a WAF 2.0 instance, you must first release the WAF 2.0 instance or migrate to WAF 3.0.
By default, ALB does not add the X-Forwarded-Proto request header. After you release a WAF 2.0 instance, direct access to the ALB instance may cause service exceptions, such as infinite redirects, because backend servers cannot identify the original request protocol (HTTP or HTTPS). To prevent this issue, you must manually enable the X-Forwarded-Proto request header in the ALB listener settings.
Unsupported features: After you enable WAF protection, the following WAF features are not supported: data leakage prevention and automatic Web SDK integration for website crawler protection in Bot Management.

If you need to use an existing WAF 2.0 instance, public-facing Basic and Standard ALB instances support transparent integration with WAF 2.0 in the following regions: China (Hangzhou), China (Shanghai), China (Shenzhen), China (Chengdu), China (Beijing), and China (Zhangjiakou). Private ALB instances do not support integration with WAF 2.0.

WAF integration support: CLB and ALB

Product

Transparent integration

Service-based integration

CLB

Supported

For guidance on transparently integrating CLB with WAF 2.0, see the following topics:

Not supported

ALB

If your Alibaba Cloud account has an existing WAF 2.0 instance, ALB supports transparent integration with WAF 2.0. For more information, see ALB instance port redirection.
If your Alibaba Cloud account does not have a WAF 2.0 instance or WAF is not enabled, ALB only supports service-based integration with WAF 3.0. You must purchase a WAF-enhanced ALB instance.