All Products
Search

This Product

    Server Load Balancer:FAQ about ALB

    Document Center

    Server Load Balancer:FAQ about ALB

    Last Updated:Dec 18, 2025

    This topic provides answers to some frequently asked questions (FAQ) about Application Load Balancer (ALB).

    Does Alibaba Cloud provide ALB instances of different specifications?

    No, Alibaba Cloud does not provide different specifications for ALB instances. Upgraded ALB instances can auto-scale virtual IP addresses (VIPs), each being able to handle up to 1 million QPS. For ALB performance details, see Performance metrics.

    Note

    Non-upgraded ALB instances differentiate between static IP and dynamic IP modes. In static IP mode, the VIP used by an ALB instance is fixed. In dynamic IP mode, more VIPs can be used as the load escalates, each instance being able to reach 1 million QPS.

    For more information about the performance of ALB instances, see the Performance metrics section of the "What is ALB?" topic.

    How do I increase the maximum Internet bandwidth of an ALB instance?

    If an ALB instance (deployed in two zones) is not associated with any Internet Shared Bandwidth instance, the maximum bandwidth for the ALB instance is 400 Mbps by default.

    If you require a larger maximum bandwidth value, you can purchase an Internet Shared Bandwidth instance and associate the elastic IP addresses (EIPs) of your ALB instance with the Internet Shared Bandwidth instance.

    How do I modify the health check configuration of a listener?

    1. Log on to the ALB console.

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

    3. On the Server Groups page, find the server group that you want to manage and click its ID.

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

    5. In the Modify Health Check dialog box, click Modify to the right of Health Check Settings and modify the settings. Click Save.

      For more information, see Health checks.

    Why is the 502 status code returned when no exceptions are detected during health checks?

    This is because the backend servers of the ALB instance are overloaded. If the backend servers of your ALB instance are overloaded, access requests may fail to be responded even if the results of health checks are normal. For more information, see Troubleshooting high load on Linux instances.

    Can I use a data transfer plan to offset the Internet data transfer fee for ALB?

    • If your ALB instance uses EIPs to provide services over the Internet, you can use a data transfer plan to offset the public bandwidth fees.

    • If your ALB instance uses an Anycast EIP to provide services over the Internet, you cannot use a data transfer plan to offset the Internet data transfer fees.

    Does ALB support mutual authentication?

    Basic ALB instances do not support mutual authentication. You can enable mutual authentication for the HTTPS listeners of standard or Web Application Firewall (WAF)-enabled ALB instances. You must change the edition of your basic ALB instance to standard or WAF-enabled before you can configure mutual authentication.

    Certificate authority (CA) certificates used for mutual authentication can be signed by either Alibaba Cloud or a third party.

    • Select or purchase a private CA certificate signed by Alibaba Cloud.

    • Select or add to ALB a CA certificate signed by a third party. When configuring the certificate, click Upload Self-signed CA Certificate in the Default CA Certificate drop-down list. On the Certificate Application Repository page, create a repository whose Data Source is Upload CA certificates. On the repository details page, upload self-signed root CA certificates or self-signed intermediate CA certificates.

    To configure mutual authentication, select a certificate from Alibaba Cloud Certificate Management Service or purchase a CA certificate. For more information, see Purchase and enable a private CA.

    What requirements does a wildcard listener certificate need to meet?

    When you configure a wildcard certificate for an HTTPS listener, take note of the following limits:

    • When you select a wildcard certificate, ALB can identify certificates that contain only one wildcard (*), which must be on the leftmost side of the domain name. For example, ALB can identify *.example.com and *test.example.com, but cannot identify test*.example.com.

    • Requirements for wildcard certificates:

      • Levels of wildcard domain names: A wildcard domain name can match specific domain names that are of the same level as the wildcard domain name. For example, *.example.com can match test.example.com but cannot match test.test.example.com, which is one level lower than the wildcard domain name.

      • Internationalized domain names (IDNAs):

        • If the wildcard character is the only wildcard character and on the leftmost side of the wildcard domain name, IDNAs can match the wildcard domain name. For example, xn--fsqu00a.example.com can match *.example.com.

        • If the wildcard character is not on the leftmost side of the wildcard domain name, IDNAs cannot match the wildcard domain name. For example, xn--fsqu00atest.example.com cannot math *test.example.com.

      • Match scope: The wildcard character (*) can match digits, letters, and hyphens (-). For example, *.example.com can match test.example.com but cannot match test_test.example.com.

    What types of EIPs can be associated with ALB instances?

    ALB supports only pay-as-you-go EIPs. The following table describes the types of EIPs that can be associated with ALB instances.

    Billing method

    Internet metering method

    Line type

    Security protection

    Pay-as-you-go

    Pay-by-data-transfer

    BGP (Multi-ISP)

    Default

    Pay-by-data-transfer

    BGP (Multi-ISP) Pro

    Default

    Pay-by-data-transfer

    BGP (Multi-ISP)

    Anti-DDoS Pro/Premium

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

    • The EIPs allocated to different zones of the same ALB instance must be of the same type.

    • The EIP that you want to associate with the ALB instance cannot be associated with an EIP bandwidth plan. You can associate an Internet Shared Bandwidth instance with an ALB instance in the ALB console after you associate an EIP with the ALB instance. The Internet Shared Bandwidth instance must use the same line type as the EIP. Subscription Internet Shared Bandwidth instances and pay-as-you-go Internet Shared Bandwidth instances are supported. For more information about how to associate an Internet Shared Bandwidth instance with an ALB instance, see Modify the maximum bandwidth.

    • You cannot associate a subscription EIP or a pay-as-you-go EIP that uses the pay-by-bandwidth metering method with an ALB instance.

    • If you select Purchase EIP or Automatically assign EIP when you assign an EIP to an ALB instance, a pay-as-you-go EIP that uses the pay-by-data-transfer metering method is created. The EIP uses BGP (Multi-ISP) lines and is protected by Anti-DDoS Origin Basic.

    Can I associate an EIP with an internal-facing ALB instance?

    Yes, you can associate an EIP with an internal-facing ALB instance after you switch the network type of the ALB instance to Internet-facing.

    To associate an EIP with an internal-facing ALB instance, change the network type of the instance. You can change an internal-facing ALB instance to an Internet-facing ALB instance. For more information, see Change the network type of an ALB instance.

    After you switch the network type to Internet-facing, the ALB instance uses an EIP to provide services over the Internet. You are charged for the data transfer over the Internet. For more information, see Pay-as-you-go.

    How can I change the EIP for my ALB instance to an EIP of the BGP (Multi-ISP) Pro line type?

    You can accomplish this by changing the ALB instance's network type in a two-step process:

    1. Change the network type of the ALB instance from Internet-facing to internal. This will disassociate the current EIP from the instance.

    2. Change the network type back from internal to Internet-facing. During this conversion, you will be prompted to select new EIPs. At this step, choose two EIPs of the BGP (Multi-ISP) Pro line type that you have created.

    Can I upload certificates in the ALB console?

    No, you cannot upload certificates in the ALB console.

    ALB uses certificates from Alibaba Cloud Certificate Management Service. You must upload your certificates in the Certificate Management Service console instead of the ALB console. For more information, see Upload an SSL certificate.

    Does ALB support traffic mirroring?

    Yes, ALB supports traffic mirroring. For more information, see Mirror production traffic to a staging environment.

    Can I switch an ALB instance from IPv4 to dual-stack or from dual-stack to IPv4?

    No, you cannot switch the IP mode of an ALB instance.

    If you need to use an IPv4 or dual-stack ALB instance, create one.

    What do I need to take note of when I remove DNS records?

    Upgraded ALB instances support the features of removing and restoring DNS records.

    Note

    Before the upgrade, ALB instances in static IP mode supported these features, while ALB instances in dynamic IP mode did not.

    After you remove the DNS record for a zone, probing on the VIPs used in the zone stops. Meanwhile, the EIPs or VIPs used in the zone, including both IPv4 and IPv6 addresses, are removed. Removing only the IPv4 or IPv6 address is not supported.

    What are the differences between the transparent proxy mode of WAF 2.0 and the service integration mode of WAF 3.0?

    image

    The following section describes the differences between the transparent proxy mode of WAF 2.0 and the service integration mode of WAF 3.0:

    • Transparent proxy mode of WAF 2.0: Requests are filtered by WAF before the requests are forwarded to ALB or CLB. In transparent proxy mode, requests pass through two gateways. You must configure the timeout period and the certificates for WAF and Server Load Balancer (SLB).

    • Service integration mode of WAF 3.0: WAF is deployed in bypass mode and requests are directly forwarded to ALB. Before the requests are forwarded to backend servers, ALB extracts and sends the request content to WAF for filtering. In service integration mode, requests pass through one gateway. This eliminates the need to synchronize certificates and settings between gateways, and prevents synchronization issues.

    For more information, see Compare WAF 3.0 and WAF 2.0.

    Do CLB and ALB support WAF 2.0 and WAF 3.0?

    Service

    WAF 2.0 (transparent proxy mode)

    WAF 3.0 (service integration mode)

    CLB

    Supported.

    Not supported.

    ALB

    • If your Alibaba Cloud account has a WAF 2.0 instance, you can connect the WAF 2.0 instance to ALB in transparent proxy mode. For more information, see the Configure a traffic redirection pot for an ALB instance section of the "Configure traffic redirection ports".

    • If your Alibaba Cloud account does not have a WAF 2.0 instance or has not activated WAF, you can connect only WAF 3.0 to ALB. In this case, you must purchase a WAF-enabled ALB instance.

    Supported.

    For more information about the supported regions and related operations, see Enable WAF protection for an ALB instance.

    Why are the timeout period and certificates not synchronized after I integrate WAF 2.0 with ALB or CLB?

    After you integrate WAF 2.0 with ALB or CLB, client requests are filtered by WAF before they are forwarded to ALB or CLB. The requests pass through two gateways, and you must synchronize the settings between WAF and ALB or CLB. If you change the timeout period or certificates, synchronization issues may occur due to latency.

    Why does an ALB instance fail to reach the maximum QPS that is configured in the forwarding rule of a listener?

    • How it works: ALB provides load balancing services by evenly distributing network traffic across groups of backend servers. The maximum QPS that you configure in a forwarding rule is evenly allocated to each backend server.

      The maximum QPS of each backend server is calculated by using the following formula: Maximum QPS of each backend server = Total QPS/(N-1). N specifies the number of backend servers in server groups. For example, you set the maximum QPS to 1,000 in a forwarding rule. If the number of backend servers is 8, the maximum QPS of each backend server is calculated by using the following formula: 1000/(8-1) = 142.

    • Cause: In scenarios in which a small number of persistent connections are used, not all backend servers in server groups are allocated persistent connections. As a result, the ALB instance cannot reach the maximum QPS.

    • Suggestion: To prevent service interruptions, we recommend that you set the maximum QPS in a forwarding rule to a proper value based on your business requirements. For more information about how to set the maximum QPS in a forwarding rule, see the Create a forwarding rule section of the "Manage forwarding rules for a listener" topic.

    What is the maximum size of a request that can be forwarded by an ALB instance? Can I increase the allowed maximum size?

    The maximum size of the URI or HTTP headers of a client request is 32 KB. You cannot increase the allowed maximum size. The default maximum size of custom headers that can be recorded in an access log is 1 KB, which can be increased to 4 KB. To request an increase, contact your account manager.

    • If the size of the URI or HTTP headers of a client request exceeds the maximum size, an HTTP 400 or 414 status code may be returned. For more information, see ALB status codes.

    • If you want to transmit a large amount of data, we recommend that you use the POST method to transmit data. The body of a POST request to ALB can be up to 50 GB in size.

    Does ALB processing time include the time spent receiving client data and sending response data?

    Yes, ALB processing time includes the time taken to both receive the complete client request and send the response back to the client. It consists of the following components:

    • Request Reception Time (read_request_time): This is the total time the load balancer spends reading the client's request. It is the sum of:

      • Header Reception Time (read_header_time): The time to receive the HTTP request headers.

      • Body Reception Time (read_body_time): The time to receive the HTTP request body.

    • Response Transmission Time: This includes the time spent sending the response data back to the client.

    How can an ALB instance forward requests if all the backend servers in the same backend server are unhealthy?

    ALB distributes requests based on the scheduling algorithm to maintain service availability. To address the issue, you can check the logs to determine whether the backend servers encounter errors, or check the health check configurations. For more information, see Troubleshoot ALB health check issues.

    What do I need to take note of when I use ALB Ingresses?

    The ALB Ingress controller uses AlbConfig objects to configure ALB instances. We recommend that you do not manually modify the configurations of an ALB instance that is created by using the ALB Ingress controller in the ALB console. For more information about ALB Ingresses, see ALB Ingress management and ALB Ingress features.

    If you manually modify the configurations of an ALB instance that is created by using the ALB Ingress controller in the ALB console, the manually modified configurations are overwritten by the AlbConfig object. This may cause exceptions, such as disabling of access log feature and deletion of routing rules.

    FAQ about the CORS feature of ALB

    Why does the configuration for cross-origin resource sharing (CORS) not take effect and the browser throw a preflight request error?

    If a specific header name instead of an asterisk (*) is specified for the Allowed Request Headers parameter, you can set Allowed Request Headers to an asterisk (*) for testing. If the problem is resolved, check whether the header_name attribute in Access-Control-Request-Headers is included in the configuration. If not, the absence of the header_name attribute is the cause of failure.

    Why do the preflight request and the actual request adopt different forwarding rules?

    ALB supports multiple matching methods for forwarding rules. However, the headers and methods of the preflight request in CORS are special and different from those of the actual requests. We recommend that you use a domain name to configure forwarding rules when you use CORS. This ensures that the preflight request and the actual request do not match forwarding rules that are not configured with CORS rules.

    How is the Access-Control-Allow-Headers response header is handled?

    1. Preflight requests

      When a browser initiates a cross-origin request that requires a preflight check, it first sends a request using the OPTIONS method. This happens if the actual request is not a simple request (e.g., it uses methods like PUT or DELETE, or includes custom headers).

      This preflight OPTIONS request includes the Access-Control-Request-Method header.

      In response to this preflight request, ALB will return the Access-Control-Allow-Headers header based on the CORS rules you have configured in the console. The value of this header will be a comma-separated list of the request headers allowed by your rule. For example:

      DNT,X-CustomHeader,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Authorization

    2. Simple and actual requests

      The Access-Control-Allow-Headers header is only returned for preflight (OPTIONS) requests.

      For any other request, such as a simple cross-origin request (which does not require a preflight) or the actual request that follows a successful preflight, ALB will not include the Access-Control-Allow-Headers header in its response.