Server Load Balancer:ALB FAQ

ALB instance specifications

ALB does not require you to select an instance specification. After you upgrade an ALB instance, ALB uses the VIP automatic scaling feature to achieve 1 million QPS for a single instance. For details about instance performance, see Instance metrics.

Converting IPv4 and dual-stack instances

No.

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

Disable pings to the ALB VIP

• For upgraded ALB instances, you can manage access traffic by using a security group. You can configure an inbound rule in the instance's security group to deny ICMP requests.

• For ALB instances that are not upgraded, you can add the EIPs associated with the instance to Cloud Firewall and configure an inbound policy to deny ICMP requests.

Increase ALB public bandwidth

If not added to a Shared Bandwidth instance, a single ALB instance deployed across two availability zones has a default peak public bandwidth of 400 Mbps.

Use a Data Transfer Plan with ALB

• If an ALB instance provides public services through an Elastic IP Address (EIP), you can use a Data Transfer Plan to offset the public data transfer costs generated by the EIP.

• If an ALB instance provides public services through an Anycast Elastic IP Address (Anycast EIP), you cannot use a Data Transfer Plan to offset the public data transfer costs generated by the Anycast EIP.

Supported EIP types

EIPs for private ALB instances

Yes.

If you need to associate an Elastic IP Address (EIP) with a private-facing ALB, you can convert the private-facing ALB to a public-facing ALB by changing the network type of the instance. For more information, see Change the network type of an ALB instance.

Changing the network type from private to public associates an EIP with the instance and incurs charges for the resulting Internet data transfer. For more information, see EIP billing.

Replacing an EIP with a BGP (Multi-ISP) Pro EIP

Replace the EIP by changing the network type of the ALB instance:

1. Change the network type of the ALB instance from public to private to disassociate the EIP.

2. Change the network type of the ALB instance back from private to public. During this process, select two BGP (Multi-ISP) Pro EIPs that you have already created.

Uneven traffic distribution among EIPs

This issue may have the following causes:

• The service domain name is incorrectly resolved to a single EIP associated with the instance instead of the ALB instance's DNS name.

• A Layer 7 proxy, such as Web Application Firewall (WAF) or Anti-DDoS, is deployed in front of the ALB instance. The proxy's back-to-origin algorithm, such as IP hash, prevents traffic from being evenly distributed among the EIPs.

• Some clients cache the A records from DNS resolution, causing a large number of requests to be consistently sent to the same EIP.

DNS removal for ALB

Upgraded ALB instances support DNS removal and recovery operations by default.

After DNS removal is complete, health checks for the VIP in that availability zone stop. The VIP or EIP (including both IPv4 and IPv6 addresses) in that availability zone is also removed from the ALB domain name resolution. You cannot remove only the IPv4 or IPv6 VIP address.

High public traffic on backend ECS instances

Traffic forwarded by an ALB instance to backend Elastic Compute Service (ECS) instances travels over a Virtual Private Cloud (VPC) internal network and does not consume the public bandwidth of the ECS instances. If the public traffic of your ECS instances remains high, it is usually for one of the following reasons:

• Inbound traffic bypasses the ALB instance: The domain name is still resolved to an ECS public IP, or clients access the ECS instance directly through its public IP. As a result, the ALB instance does not forward the traffic.

• Outbound requests from the ECS instances: Applications running on the ECS instances initiate external requests, such as software updates, log uploads, or external API calls, which generate outbound public traffic.

Troubleshooting steps:

1. Verify that your service domain name resolves to the ALB address, not an ECS public IP address.

2. Check the inbound security group rules for the ECS instances to ensure that service ports are not exposed to the public.

3. On the ECS instances, use iftop or nethogs to identify the processes and destination addresses that are consuming public bandwidth.

Does ALB support traffic mirroring?

Yes. For more information, see Use ALB Traffic Mirroring for Stress Testing.

Failure to reach the listener QPS limit

• How it works: The load balancing system uses a server cluster to serve each ALB instance. This cluster evenly distributes inbound requests among its servers for forwarding. Therefore, the QPS limit you set in a forwarding rule is also spread across these system servers.

  The QPS limit for a single system server is calculated by using the following formula: QPS limit per system server = Total QPS set / (N-1). N is the number of system 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 system servers, the maximum QPS for a single system server is 1000/(8-1) = 142 QPS.

• Cause: With a small number of persistent connections, some system servers in the forwarding group may not receive any connections. This can prevent the ALB instance from reaching the QPS limit.

• Recommendation: Set a reasonable QPS limit for your forwarding rules based on your business requirements. This ensures your services remain available and are not unexpectedly limited. For more information about how to set a QPS limit in a listener forwarding rule, see Add a forwarding rule.

Request length limits

Scope of ALB processing time

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

• Time to receive client data: This is the read_request_time, the total time the load balancer takes to read a client request. It includes the time to read the HTTP request header (read_header_time) and request body (read_body_time).

• Time to send response data: This includes the time to return response data to the client.

Maximum requests per persistent connection

A single persistent connection supports a maximum of 100 consecutive requests. If this limit is exceeded, the connection is automatically closed.

This limit increases to 1,000 if you use an HTTPS listener and enable HTTP/2.

Client Hello length limit for QUIC listeners

When you use a QUIC listener, ALB enforces a minimum length for the client's Client Hello. The packet must be at least 1,024 bytes long. Otherwise, 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 meet the 1,024-byte requirement.

Considerations for ALB Ingress

In most cases, do not manually modify ALB instances created by ALB Ingress in the console. Use AlbConfig as the source of truth for ALB configurations. For more information about ALB Ingress, see Overview of ALB Ingresses and Use an ALB Ingress.

If you make manual changes in the console, your changes are not reflected in the AlbConfig resource. The next AlbConfig synchronization overwrites these manual changes. This can cause issues such as disabled access logs or deleted forwarding rules.

ALB cross-origin FAQ

Referencing original header values

For Key, enter the name of the header that you want to write. For Value, select the reference 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 written, and it references the value of the original header abc. The forwarding rule extracts the value from the original header abc and assigns it to the new header abc-abc.

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

Client

When the client sends a request using curl, it includes the custom request header abc:123456 with the -H parameter. The server returns 200 OK. The following code shows a sample command and its output:

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

CA mutual authentication

Basic Edition ALB instances do not support CA mutual authentication. Standard Edition and WAF-enabled Edition ALB instances support CA mutual authentication when you add an HTTPS listener. If you need to use the CA mutual authentication feature for a Basic Edition ALB instance, please upgrade the instance edition.

Rules for wildcard certificates

Uploading certificates

No.

ALB uses certificates from the Alibaba Cloud SSL Certificates Service. Therefore, you must upload certificates to the SSL Certificate console instead of the ALB console. For more information, see Upload an SSL Certificate.

Unchanged certificate expiration date

This issue typically occurs when your ALB instance is integrated with WAF 2.0 in transparent proxy mode and the certificate in WAF has not been updated. WAF synchronizes certificates from ALB periodically. To trigger an immediate update, you can disable and then re-enable traffic diversion for your domain in the WAF console. This action forces a certificate refresh. Note that this operation causes a brief service interruption of 1 to 2 seconds.

Modify health check configuration

1. Sign in to the Application Load Balancer (ALB) console.

2. In the left-side navigation pane, choose ALB > Server Groups.

3. On the Server Groups page, find the target server group and click its ID.

4. On the Details tab, in the Health Check section, click Modify Health Check.

5. In the Modify Health Check dialog box, click Edit next to Health Check Settings, modify the health check settings, and then click Save.

   For more information, see ALB health check.

502 errors despite successful health checks

This is usually because the load on the backend servers of the ALB instance is too high. When the load on the backend servers of the ALB instance is too high, inconsistencies may occur between health check results and access request results. For information about how to check the backend server load, see Troubleshooting and handling high load issues on Linux instances.

Request forwarding when health checks fail

The ALB instance still forwards requests based on the configured scheduling algorithm to minimize service disruption. If requests are not handled as expected, check your logs for backend server errors or review your health check configuration for issues. For more information, see Troubleshoot ALB health check failures.

Service inaccessible via ALB

Follow these steps to diagnose the issue:

1. 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. Use the nslookup or dig command to verify the resolution. For more information, see ALB Instance DNS Names.

2. Verify the instance network type: A private network ALB instance can only be accessed from within its Virtual Private Cloud (VPC). To enable public access, change the instance's network type to public and associate an Elastic IP (EIP). For more information, see Change the Network Type of an ALB Instance.

3. Verify the listener and forwarding rules: In the ALB console, check that a listener has been created with the correct port and protocol. Also, confirm that the forwarding rules are configured to match the domain name and path of the incoming requests.

4. Verify the health check status: In the ALB console, check the health check status of your backend servers. An ALB instance will not forward requests to unhealthy backend servers.

5. Confirm the backend service is running correctly: Log on to a backend server and run the curl -I http://<backend_server_private_IP>:<port> command to confirm that the backend service responds correctly.

6. Verify access control and firewall settings: Ensure that the access control settings or security group rules of the ALB instance allow the client's source IP address range. Also, confirm that iptables or third-party security software on the backend Elastic Compute Service (ECS) instances allow the local IP address range of the ALB instance.

Troubleshooting high latency

ALB operates at the application layer, which means requests are forwarded to backend servers. This process introduces minor additional latency compared to accessing backend servers directly. This is expected behavior.

If you experience significantly high latency, follow these steps to troubleshoot:

1. 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 the load balancer sends the response.

   • upstream_response_time: The time in seconds from when the load balancer starts to connect to a backend server until it receives all data and closes the connection.

2. Identify the source of the latency:

   • If upstream_response_time is high, the backend servers are likely the source of the latency. Check the performance of your backend application, the efficiency of your database queries, and the usage of resources like CPU and memory. You can also add more backend servers to distribute the load.

   • If request_time is much higher than upstream_response_time, the latency is likely in the network path between the client and the ALB instance. From the client, run continuous ping tests or an MTR trace to the ALB service address to diagnose network link issues.

3. Consider cross-region access scenarios: If the client and the ALB instance are in different regions, network latency due to physical distance is unavoidable. We recommend using Global Accelerator (GA) to optimize the cross-region access experience.

Service inaccessible via domain name

After mapping your custom domain name to the ALB instance's DNS name with a CNAME record, you might still be unable to access the service. If you receive an HTTP 403 error or a connection reset, the cause is likely an incomplete ICP filing for your domain name.

Follow these steps to diagnose the issue:

1. Verify the CNAME record configuration: Use the nslookup or dig command to verify that your domain name is correctly resolved to the DNS name of the ALB instance. For more information, see Configure a CNAME Record.

2. Check the ICP filing status of your domain name: According to regulations, domain names used for public access in the Chinese mainland 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 of your domain name. If it is not filed, complete the ICP filing process first. For more information, see ICP Filing Process.

3. Determine if an ICP filing transfer is required: If your domain name was filed through another cloud service provider and you are using it with Alibaba Cloud for the first time, you must complete an ICP filing transfer. This process registers your filing information with Alibaba Cloud. Access may be blocked if the transfer is not complete.

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 Temporarily 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 Time-out)

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 2.0 transparent vs. WAF 3.0 service-based integration

For more information, see Comparison between WAF 3.0 and WAF 2.0.

ALB and WAF integration

• We recommend that you enable WAF 3.0 protection for an ALB instance by using WAF 3.0 service-based integration. This means 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 (Heyuan)
    Asia Pacific	Indonesia (Jakarta), Japan (Tokyo), Malaysia (Kuala Lumpur), Philippines (Manila), Singapore, South Korea (Seoul), Thailand (Bangkok)
    Europe & Americas	Germany (Frankfurt), US (Silicon Valley), US (Virginia), Mexico
    Middle East	Saudi Arabia (Riyadh) (Operated by Partner), 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 want to use an existing WAF 2.0 instance, Internet-facing Basic and Standard ALB instances support WAF 2.0 transparent integration in the following regions: China (Hangzhou), China (Shanghai), China (Shenzhen), China (Chengdu), China (Beijing), and China (Zhangjiakou). Internal-facing ALB instances do not support WAF 2.0 transparent integration.

WAF integration support for CLB and ALB

WAF 2.0 transparent integration issues

In a WAF 2.0 transparent integration, client requests pass through WAF for inspection before being sent to an ALB or CLB instance. This two-gateway path requires you to synchronize multiple configurations between WAF and the load balancer. Changes to timeouts and certificates are especially prone to configuration synchronization delays.