All Products
Search

This Product

    Server Load Balancer:ALB FAQ

    Document Center

    Server Load Balancer:ALB FAQ

    Last Updated:Feb 24, 2026

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

    Instances and specifications

    Does ALB have specific instance specifications?

    ALB instances do not require you to select specific specifications. Upgraded ALB instances use auto-scaling virtual IP addresses (VIPs) to achieve a performance of up to 1 million queries per second (QPS) for a single instance. For more information about ALB instance performance, see Instance performance metrics.

    Note

    Before the upgrade, ALB instance performance varied depending on whether the IP mode was static or dynamic. These instances did not support auto-scaling VIPs. To achieve 1 million QPS, you had to dynamically scale out the number of IP addresses.

    Can I switch an ALB instance between IPv4 and dual-stack?

    This feature is not supported.

    You must create a new IPv4 or dual-stack instance.

    Network and EIPs

    Does the VIP of an ALB instance support disabling ping?

    • For upgraded ALB instances, you can manage access traffic using security groups. Configure an inbound rule in the security group of the instance to deny ICMP traffic.

    • For instances that are not upgraded, you can add their associated Elastic IP Addresses (EIPs) to an Internet firewall and configure an inbound policy to deny ICMP traffic.

    How do I increase the public bandwidth of an ALB instance?

    If an ALB instance deployed across two zones is not added to an Internet Shared Bandwidth, its default peak public bandwidth is 400 Mbps.

    To obtain additional bandwidth, purchase an Internet Shared Bandwidth and add the EIPs associated with the ALB instance to it.

    Can I use a Data Transfer Plan to pay for the public traffic of an ALB instance?

    • If an ALB instance uses an Elastic IP Address (EIP) to provide public services, you can use a general-purpose Data Transfer Plan to pay for the public traffic generated by the EIP.

    • If an ALB instance uses an Anycast EIP to provide public services, you cannot use a general-purpose Data Transfer Plan to pay for the public traffic generated by the Anycast EIP.

    What types of EIPs can be associated with ALB instances?

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

    Billing method

    Public network metering method

    Line type

    Security protection

    Pay-as-you-go

    Pay-by-traffic

    BGP (Multi-ISP)

    Default

    Pay-by-traffic

    BGP (Multi-ISP)_Premium

    Default

    Pay-by-traffic

    BGP (Multi-ISP)

    Anti-DDoS (Enhanced)

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

    • The EIPs bound to all zones of an ALB instance must be of the same type.

    • Before associating an EIP, ensure it is not added to an Internet Shared Bandwidth. After associating the EIP with the ALB instance, you can add it to an Internet Shared Bandwidth in the SLB console. The line type of the EIP must match the line type of the Internet Shared Bandwidth. Both subscription and pay-as-you-go Internet Shared Bandwidth plans are supported. For more information about how to add an EIP to an Internet Shared Bandwidth, see Adjust the peak bandwidth of a public-facing instance.

    • You cannot associate subscription EIPs or pay-as-you-go EIPs that use the pay-by-bandwidth metering method.

    • When assigning an EIP to an ALB instance, if you select Purchase EIP or Automatically assign public IP, a pay-as-you-go (pay-by-traffic) BGP (Multi-ISP) EIP with default security protection is created.

    Can I associate an EIP with a private ALB instance?

    Supported.

    To associate an EIP with an internal-facing ALB, change the network type of the instance to convert the internal-facing ALB to an Internet-facing ALB. For more information, 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, and public network fees are generated. For more information, see EIP billing.

    How do I change the EIP of an ALB instance to a premium EIP?

    You can replace it by changing the network type of an ALB instance:

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

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

    Why is the traffic load unbalanced across the EIPs bound to an ALB instance?

    This may occur for the following reasons:

    • The business domain name resolves to a single EIP bound to the ALB instance instead of the ALB instance’s DNS name.

    • A Layer 7 proxy, such as WAF or Anti-DDoS Proxy, 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 across multiple EIPs.

    • Some clients cache the A records returned from DNS resolution. This causes many requests to be sent to the same EIP.

    Notes on ALB DNS removal

    Upgraded ALB instances support DNS removal and restoration by default.

    Note

    Before the upgrade, only ALB instances in static IP mode supported DNS removal and restoration. Instances in dynamic IP mode did not.

    After DNS removal completes, availability probing for the VIP in the zone stops. The VIP or EIP—including both IPv4 and IPv6 addresses—is removed from the DNS resolution of the ALB domain name. You cannot remove only the IPv4 or IPv6 address.

    Listeners and forwarding

    Does ALB support traffic mirroring?

    Yes. For more information, see Use the traffic mirroring feature of ALB to perform simulated stress testing.

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

    • How it works: The load balancing system provides services for ALB instances through a cluster deployment. All external access requests are evenly distributed to the servers in the load balancing system for forwarding. Therefore, the QPS limit you set in a forwarding rule is evenly distributed across multiple system servers.

      The QPS limit for a single system server is calculated using the following formula: QPS limit per system server = Total QPS configured / (N - 1), where 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: In business scenarios that use a small number of persistent connections, not all system servers in the forwarding group may be allocated persistent connections. As a result, the ALB instance cannot reach the QPS limit.

    • Suggestion: Based on how load balancing is implemented, we recommend that you set a reasonable QPS limit for your forwarding rules as needed. This ensures that your services are not affected. For more information about how to set a QPS limit in a forwarding rule, see Add a forwarding rule.

    What is the length limit for requests forwarded by ALB? Can it be adjusted?

    The maximum length of a request URI is 32 KB. The maximum length of a request header is 32 KB. These limits cannot be changed. The default length of a custom header in an access log is 1 KB. You can contact your account manager to increase the limit to a maximum of 4 KB.

    • If the size of a client request exceeds the limit, a 400 or 414 status code may be returned. For more information, see ALB error codes.

    • If the data volume is large, we recommend that you use the POST method. The body of a POST request can be up to 50 GB.

    Does ALB processing time include the time to receive client data and send data?

    ALB processing time includes the time required to receive client data and send data.

    • Time to receive client data: This is the value of read_request_time, which is the total time that the load balancer spends reading a client request. This 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 to return response data to the client.

    What is the maximum number of requests supported by a single HTTP persistent connection from a client to ALB?

    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, the maximum number of requests for a single persistent connection can be increased to 1,000.

    What is the length limit for a client Hello packet for an ALB QUIC listener?

    When you use a QUIC listener, ALB sets a minimum length for the client Hello packet. The packet must be at least 1,024 bytes. Otherwise, ALB returns a "client hello too small" error and closes the connection. You can pad the client Hello packet with null characters to meet the 1,024-byte requirement.

    What are the precautions for using ALB Ingresses?

    In most cases, do not manually modify an ALB instance that is created using ALB Ingress in the console. The configuration of the ALB instance is synchronized based on the AlbConfig resource. For more information about ALB Ingress, see Manage ALB Ingresses and ALB Ingress features.

    If you make manual changes in the console, the changes will be overwritten because the AlbConfig is not modified. This can cause issues such as disabled access logs or deleted forwarding rules.

    FAQ about cross-origin requests in ALB

    Why does the cross-origin configuration not take effect, and the browser reports a preflight request error?

    If you configure "Allowed Request Headers" with a specific header name instead of "*", try setting it to "*" for testing. If the issue is resolved, verify whether the header_name contained in the Access-Control-Request-Headers field of the preflight request is missing from your configuration, which causes the preflight request to fail.

    Preflight requests and actual requests match different forwarding rules

    ALB supports a variety of matching methods for forwarding rules. However, due to the special nature of preflight requests in cross-origin scenarios, their headers and methods differ from those of actual requests. We recommend that you use domain names to configure forwarding rules when handling cross-origin requests. This ensures that preflight requests and actual requests do not fall into forwarding rules that are not configured for cross-origin requests, which can cause unnecessary issues.

    When CORS is configured, how is the Access-Control-Allow-Headers response header generated and returned?

    1. Preflight request

      When a browser initiates a cross-origin request and the following conditions are met, it first sends a preflight request with 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 that you configured in the console. The value of this response header is a list of allowed request header fields in the rule. Example:

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

    2. Simple 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.

    Certificates and HTTPS

    Does ALB support mutual authentication?

    Basic Edition ALB instances do not support mutual authentication. Standard Edition and WAF-enabled ALB instances support enabling mutual authentication when you add HTTPS listeners. To use mutual authentication on a Basic Edition ALB instance, change the edition of your instance.

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

    • If you select a CA certificate issued by Alibaba Cloud, you need to select or purchase a private CA certificate.

    • If you select a CA certificate issued by a third party, you need to select or upload a CA certificate. To upload a CA certificate, click Upload Self-signed CA Certificate from the Select Default CA Certificate drop-down list. On the Certificate Repository page, create a repository whose data source is Upload CA Certificate. Then, upload a self-signed root CA or a self-signed intermediate CA certificate through the certificate application repository.

    What rules must a wildcard certificate for an ALB listener meet?

    When you add an HTTPS listener to an ALB instance, if the selected certificate is a wildcard certificate, note the following rules.

    • When you select a wildcard certificate, ALB can identify only certificates that contain a single wildcard character (*) and that place the wildcard character (*) at the far left of the domain name. For example, ALB can identify *.example.com and *test.example.com, but cannot identify test*.example.com.

    • Wildcard domain name matching rules:

      • Wildcard level: A wildcard domain name can match only subdomains of the same level. For example, *.example.com can match test.example.com, but cannot match test.test.example.com because the subdomain and the wildcard domain name are at different levels.

      • IDNA support:

        • If the wildcard character in the wildcard certificate is the only character in the leftmost label, an IDNA label can match the wildcard character. For example, xn--fsqu00a.example.com can match *.example.com.

        • If the wildcard character in the wildcard certificate is not the only character in the leftmost label, an IDNA label cannot match that part of the 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 cannot match test_test.example.com.

    Can I upload certificates in the ALB console?

    No.

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

    After I update an ALB certificate, the expiration date of the domain name certificate in the browser does not change.

    This usually happens because ALB is connected to WAF 2.0 through the transparent proxy mode, and the certificate on the WAF side has not been updated. WAF synchronizes certificates from ALB periodically. To synchronize immediately, disable and then re-enable traffic redirection on the WAF side to force a refresh of the certificate status. Note that this operation causes a transient disconnection of 1 to 2 seconds.

    Health checks

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

    1. Log on to the Application Load Balancer console.

    2. In the navigation pane on the left, choose Application Load Balancer > Server Groups.

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

    4. In the Health Check section of the Details tab, click Edit Health Check.

    5. In the Edit Health Check dialog box, click Edit to the right of Health Check Configuration and modify the health check configuration as needed. Then, click Save.

      For more information, see Health checks.

    Why is a 502 status code returned when health checks are normal?

    This is usually because the backend servers of the ALB instance are overloaded. When the backend servers of an ALB instance are overloaded, the health check results may be inconsistent with the access request results. For more information about how to query the load of backend servers, see Troubleshoot and handle high load issues on Linux instances.

    How does ALB forward requests when all backend servers in a server group are unhealthy?

    ALB continues to forward requests based on the scheduling algorithm to minimize business impact. If requests do not meet expectations, check the logs for backend server exceptions or review the health check configuration for abnormalities. For more information, see Troubleshoot ALB health check exceptions.

    Troubleshooting

    How do I troubleshoot when a service cannot be accessed through ALB?

    Follow these steps:

    1. Confirm the domain name resolution (CNAME): You cannot directly access a new ALB instance using its DNS name. You must resolve your custom domain name to the DNS name of the ALB instance using a CNAME record. You can use the nslookup or dig command to verify the resolution result. For more information, see DNS names of ALB instances.

    2. Confirm the instance network type: A private ALB instance can be accessed only from within a VPC. It cannot be accessed from the Internet. For public access, change the instance network type to public and associate an EIP with it. For more information, see Change the network type of an ALB instance.

    3. Confirm the listener and forwarding rules: In the ALB console, check whether a listener is created, confirm that the listener port and protocol are correctly configured, and confirm that the forwarding rules can match the domain name and path of the request.

    4. Confirm the health check status: In the ALB console, view the health check status of the backend servers. When a backend server is unhealthy, ALB may not be able to forward requests normally.

    5. Confirm that the backend service is normal: Log on to the backend server and run the curl -I http://<backend_server_private_IP>:<port> command to confirm that the backend service itself can respond normally.

    6. Confirm the security group rules: Check the security group rules of the backend server and the ALB instance to confirm that the listener port and the request source address range are allowed.

    How do I troubleshoot high latency when accessing through ALB?

    ALB is application-oriented. Requests are forwarded to backend servers through ALB. Compared with direct access to the backend, there is a slight increase in latency, which is normal.

    If the latency is significantly high, follow these steps to troubleshoot:

    1. Enable access logs and analyze the latency fields: Enable ALB access logs and focus on the following fields:

      • request_time: The time interval in seconds from when the load balancer receives the first request packet to when it returns a response.

      • upstream_response_time: The time in seconds from when the load balancer establishes a connection to the backend server to when it finishes receiving data and closes the connection.

    2. Determine the source of the latency:

      • If upstream_response_time is high: The latency is usually caused by slow processing on the backend server. We recommend that you check the backend application performance, database query efficiency, CPU/memory usage, or add more backend servers to share the load.

      • If request_time is much greater than upstream_response_time: The latency may be on the network link from the client to ALB. We recommend that you run a continuous ping test or MTR route trace from the client to the ALB endpoint to troubleshoot network link issues.

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

    What should I do if I cannot access the ALB service through a domain name?

    You cannot directly access a new ALB instance using its DNS name. You must resolve your custom domain name to the DNS name of the ALB instance using a CNAME record. If you have correctly configured the CNAME record but still cannot access the service (returns 403 or the connection is reset), the most common reason is that the domain name has not completed ICP filing.

    Follow these steps to troubleshoot:

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

    2. Confirm the ICP filing status of the domain name: According to relevant regulations, when you use a domain name to access services over the public network in the Chinese mainland, the domain name must have completed ICP filing. Otherwise, access will be blocked. Log on to the Alibaba Cloud ICP Filing system to query the filing status of the domain name. If it is not filed, complete the ICP filing first. For more information, see ICP filing process.

    3. Confirm whether you need to add Alibaba Cloud to the ICP filing information as a service provider: If the domain name has completed ICP filing with another cloud service provider, but you are using it with Alibaba Cloud for the first time, you also need to add Alibaba Cloud to the ICP filing information as a service provider. Failure to do so may also result in blocked access.

    Common error status codes and possible causes

    500 (Internal Server Error)

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

    • Backend directly returns 500: Check the access logs. If upstream_status is 500, ALB likely passed through the upstream status code. Troubleshoot the backend service.

    • Backend server abnormally closed connection: The backend server abnormally closed the connection before sending the complete response. Capture packets on the backend server to troubleshoot the cause of the abnormal connection closure.

    502 (Bad Gateway)

    After the HTTP or HTTPS listener received the client request, ALB could not properly forward the request to the backend server or could not receive a response from the backend server.

    • Backend directly returns 502: Check the access logs. If upstream_status is 502, ALB likely passed through the upstream status code. Troubleshoot the backend service.

    • Backend returns other error status codes: For example, 504 or 444, but ALB uniformly returns 502. Check the status and upstream_status fields in the access logs and troubleshoot based on the upstream status code.

    • TCP communication error between ALB and backend server: Check whether the backend service is running normally, whether the service port is listening properly, or capture packets to check whether the TCP handshake is normal.

    • Backend server backlog is full: This causes new connection requests to be rejected or dropped. Run netstat -s | grep -i listen on the backend server to check whether there is a drop count.

    • Client packet length exceeds backend server MTU: This is characterized by normal short packets such as health checks, but abnormal long packets. Capture packets on the backend server to analyze whether the packet length meets requirements.

    • Backend server response packet format is abnormal or contains illegal HTTP headers: Capture packets on the backend server to analyze whether the response packet format is standard.

    • Backend server did not process the request in time: Check the backend server logs and view CPU and memory utilization.

    503 (Service Temporarily Unavailable)

    The server is temporarily unavailable, usually due to traffic exceeded or backend service unavailable.

    • Backend directly returns 503: Check the access logs. If upstream_status is 503, ALB likely passed through the upstream status code. Troubleshoot the backend service.

    • Client request triggered ALB throttling:

      • Check the Requests per second metric through CloudMonitor.

      • CloudMonitor displays minute-level data and may not reflect second-level exceeded situations. Check the access logs. If the value of 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.

    • Client directly accesses ALB IP or DNS resolution is abnormal when accessing through domain name: This may cause traffic to concentrate on a few IPs and exceed the limit. We recommend that the client access through the ALB domain name (refer to Configure a CNAME record for an ALB instance and ensure that DNS resolution is normal.

    • Listener has no backend servers configured or the configured backend servers have weight 0

    504 (Gateway Time-out)

    The backend server response timed out.

    • Backend directly returns 504: Check the access logs. If upstream_status is 504, ALB likely passed through the upstream status code. Troubleshoot the backend service.

    • Connection establishment between ALB and backend server timed out: The default timeout is 5 seconds and cannot be modified. Capture packets to troubleshoot why the backend server response timed out.

    • Backend server response timed out: The connection request timeout defaults to 60 seconds. You can check the UpstreamResponseTime metric in CloudMonitor and the upstream_response_time field in access logs to determine whether the backend server response timed out.

    WAF integration

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

    image

    The differences between the two are summarized as follows:

    • WAF 2.0 transparent proxy mode: Client requests are first inspected by WAF and then forwarded to ALB or CLB. In transparent proxy mode, requests pass through two gateways. Therefore, you need to maintain configurations such as timeout periods and certificates on both the WAF side and the load balancer side.

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

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

    Instructions for integrating ALB with WAF

    • We recommend that you enable WAF 3.0 protection for your ALB instance using the service integration method. This means using a WAF-enabled 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), and China (Hong Kong)

        Asia Pacific

        Philippines (Manila), Indonesia (Jakarta), Japan (Tokyo), Malaysia (Kuala Lumpur), Singapore, Thailand (Bangkok), and South Korea (Seoul)

        Europe and Americas

        Germany (Frankfurt), US (Virginia), US (Silicon Valley), and Mexico

        Middle East

        SAU (Riyadh - Partner Region)

      • WAF version: You must use WAF 3.0. If you have a WAF 2.0 instance in your account, you must first release the WAF 2.0 instance or migrate it to WAF 3.0.

        By default, ALB does not enable the X-Forwarded-Proto header in requests forwarded to the backend server group. After you terminate a WAF 2.0 instance, accessing the ALB directly may cause service exceptions, such as infinite loop redirection, because the backend service cannot properly identify the protocol (HTTP/HTTPS). To prevent this issue, you must manually enable the X-Forwarded-Proto request header in the ALB listener configuration.

      • Feature availability: WAF for ALB instances does not support the following features: the data leakage prevention module and the automatic Web SDK integration feature for anti-crawler rules for websites in the bot management module.

    • To use an existing WAF 2.0 instance in your account, public-facing Basic and Standard ALB instances support transparent integration with WAF 2.0 protection. Supported 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 protection.

    Do CLB and ALB support transparent integration with WAF 2.0 and service integration with WAF 3.0?

    Product

    Transparent integration with WAF 2.0

    Service integration with WAF 3.0

    CLB

    Supported

    Not supported

    ALB

    • If your Alibaba Cloud account has a WAF 2.0 instance, ALB supports transparent integration with WAF 2.0. For more information, see Redirect traffic from a port of an ALB instance.

    • If your Alibaba Cloud account does not have a WAF 2.0 instance or WAF is not enabled, ALB supports only service integration with WAF 3.0. This means you must purchase a WAF-enabled ALB instance.

    Supported

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

    Why do issues such as unsynchronized timeout periods and certificates occur with WAF 2.0 transparent integration?

    When using WAF 2.0 transparent integration, client requests are first inspected by WAF and then forwarded to ALB or CLB. Client requests pass through two gateways, which requires synchronizing multiple configurations between the WAF side and the load balancer side. This can easily cause synchronization delays, especially when changing timeout periods and certificates.