All Products
Search

This Product

    Server Load Balancer:FAQ about ALB

    Document Center

    Server Load Balancer:FAQ about ALB

    Last Updated:Mar 15, 2024

    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. The performance of an ALB instance varies based on the type of IP address used by the ALB instance.

    • Static IP: The ALB instance is assigned only one static IP address in each zone. In this mode, a single ALB instance supports up to 100,000 queries per second (QPS).

    • Dynamic IP: The ALB instance is assigned one or more IP addresses in each zone. The number of IP addresses that an ALB instance uses automatically increases along with your workloads. In this mode, a single ALB instance supports up to 1,000,000 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 is deployed in two zones and is not associated with an Internet Shared Bandwidth instance, the default maximum Internet bandwidth of the ALB instance is 400 Mbit/s.

    If you require more bandwidth, 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 Troubleshoot and resolve high load issues 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.

      Note

      By default, the feature of associating Anycast EIPs with ALB instances is disabled in the ALB console. To use this feature, log on to the Quota Center console. On the Privileges page, enter slb_user_visible_gray_label/anycast_eip in the Quota ID field to find the privilege and click Apply in the Actions column. For more information, see Manage ALB quotas.

    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 upgrade your basic ALB instance before you can configure mutual authentication. For more information, see Modify the configurations of ALB instances and Add an HTTPS listener.

    To configure mutual authentication, select a certificate authority (CA) 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

    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?

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

    If you need to associate an EIP with an internal-facing ALB instance, you can 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.

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

    How do I connect WAF to ALB?

    ALB is interfaced with WAF 3.0. If you want your ALB instances to be protected by WAF, purchase a WAF-enabled ALB instance. When you purchase WAF-enabled ALB instances, take note of the following information:

    • If your Alibaba Cloud account does not have a WAF 2.0 instance or has not activated WAF: You can enable WAF 3.0 for Internet-facing and internal-facing ALB instances by purchasing WAF-enabled ALB instances. This way, ALB is interfaced with WAF on the service level. For more information, see Activate and manage WAF-enabled ALB instances.

      Regions that support WAF-enabled ALB instances (Regions in which ALB is interfaced with WAF 3.0)

      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), Australia (Sydney), Singapore, and India (Mumbai)

      Europe & Americas

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

      Middle East

      SAU (Riyadh)

    • If your Alibaba Cloud account already has a WAF 2.0 instance: You can enable WAF 2.0 for Basic Edition Internet-facing ALB instance and Standard Edition Internet-facing ALB instances in transparent proxy mode. Internal-facing ALB instances do not support WAF 2.0.

      Only ALB instances in the following regions can be interfaced with WAF 2.0 in transparent proxy mode: China (Hangzhou), China (Shanghai), China (Shenzhen), China (Chengdu), China (Beijing), and China (Zhangjiakou).

      Note

      If you want to enable WAF 3.0 for your ALB instance, release the WAF 2.0 instance first or migrate to WAF 3.0.

      • After you release the WAF 2.0 instance, service errors may arise because the X-Forwarded-Proto header is disabled for ALB by default. You must enable the X-Forwarded-Proto header for the listeners of the ALB instance to prevent errors. For more information, see Manage listeners.

      • For more information about how to release a WAF 2.0 instance, see Terminate the WAF service.

      • For more information about how to migrate to WAF 3.0, see Migrate a WAF 2.0 instance to WAF 3.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.

    For more information about how to connect WAF 2.0 to CLB in transparent proxy mode, see the following topics:

    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 Activate and manage WAF-enabled ALB instances.

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

    After you connect WAF 2.0 to 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.

    If certificates are not updated or if the changes of the timeout period do not take effect, join DingTalk group 21715946 for consultation.

    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 maximum size of custom headers that can be recorded in an access log is 1 KB. If the size of custom headers exceeds the limit, the excess part is truncated. You cannot increase the allowed maximum size.

    • 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.

    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.

    Why are the HTTP 500, 502, 503, and 504 status codes returned?

    500 (Internal Server Error)

    An internal error occurred on the backend server. The request cannot be processed by the backend server.

    Possible causes:

    • A backend server returns the HTTP 500 status code, and ALB passes the backend status code to the client. Check why the backend server returns the HTTP 500 status code.

    • The backend server closes the connection before sending the response. We recommend that you capture packets on the backend server to determine the cause and troubleshoot.

    502 (Bad Gateway)

    The HTTP or HTTPS listener of ALB failed to send the request to the backend server or no response was returned from the backend server. As a result, the HTTP 502 status code was returned to the client.

    Possible causes:

    • The backend server returns the HTTP 502 status code, and ALB passes the backend status code to the client. Check why the backend server returns the HTTP 502 status code.

    • The ALB backend server returns another HTTP status code (such as 504 and 444), but ALB returns the HTTP 502 status code. We recommend that you check the upstream_status and status fields in the access log or capture packets to check whether the backend server has errors.

    • The communication between ALB and the backend server over TCP contains errors. Check whether the backend server is healthy, whether the service port is listened by listeners, or whether TCP handshakes succeed.

    • The backend server backlog is full, which causes packets to be dropped. We recommend that you use netstat to check whether the network statistics of the backend server show the number of dropped packets. For example, you can run the netstat -s | grep -i listen command.

    • The length of the packets sent by the client exceeds the maximum transmission unit (MTU) of the backend server. In this case, the health check is successful, or shorter packets are sent as expected. However, longer packets are not sent as expected. We recommend that you capture packets on the backend server to analyze whether the packet length meets the requirements.

    • The packets returned by the backend server are in an invalid format or contain invalid HTTP headers. We recommend that you capture packets on the backend server to check whether the format of HTTP responses is invalid.

    • A backend server of ALB has not completed the processing of the request. Check the log data of the backend server. In addition, check the CPU and memory usage.

    503 (Service Temporarily Unavailable)

    The service is unavailable. This is because the traffic exceeds the limit or the backend server is unavailable.

    Possible causes:

    • A backend server returns the HTTP 503 status code, and ALB passes the backend status code to the client. Check why the backend server returns the HTTP 503 status code.

    • The network traffic from clients triggers ALB throttling. You can use one of the following methods to troubleshoot the issue:

      • View the number of requests per second in the CloudMonitor console. For more information, see ALB monitoring metrics and View the monitoring information about an ALB instance.

      • CloudMonitor displays monitoring data at the minute level. You can view the number of requests per second by using the access log. View the upstream_status field of the access log. If the content is "-", the request is not sent to the backend server.

      • Check whether the response header contains the ALB-QPS-Limited:Limited field. If so, it indicates that the request has triggered ALB throttling.

    • The client accesses the IP address of the ALB instance instead of using the domain name when the client accesses ALB, or does not update the DNS resolution results when the client uses the domain name to access ALB. As a result, requests cannot be distributed among multiple ALB IP addresses and the HTTP 503 error code is returned. We recommend that clients access the domain name of ALB instead of the IP address. In addition, make sure that clients use different IP addresses returned by DNS to access ALB.

    • No backend server is associated with the ALB listener or the weight of the backend server is set to 0.

    504 (Gateway Time-out)

    The response of the backend server timed out.

    Possible causes:

    • If the 504 status code is returned by the backend server, check whether the backend server is overloaded.

    • The connection from ALB to the backend server timed out. The timeout period is set to 5 seconds by default. You can check whether the upstream_connect_time field in the access log is set to 5 seconds or approximately 5 seconds. We recommend that you capture packets to determine the cause of the response timeout.

    • The workload on the backend server is heavy and the time that is required to return a response is longer than the specified timeout period. For example, the request timeout period is set to 60 seconds. If the response time is 60.001 seconds, ALB returns the HTTP 504 status code. You can view the network latency during the period in which issues occur in the CloudMonitor console or in the access log. To view the network latency, check the upstream_rt field in CloudMonitor, or the upstream_response_time field in the access log.

    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 overview 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 CORS supported by 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.