This topic answers frequently asked questions about Classic Load Balancer (CLB) instances.
This topic contains the following questions:
Category | FAQ |
Instance selection | |
Instance types | |
Instance configuration | |
Instance O&M |
How do I select a pay-as-you-go instance?
Starting from 00:00:00 (UTC+8) on June 1, 2025, you can no longer purchase pay-by-specification CLB instances.
By default, CLB instances use the pay-by-LCU metering method. The performance of an instance automatically scales with usage, and you do not need to specify an instance type. You are charged hourly based on your actual usage. For more information about performance limits, see Upper limits for instance performance metrics. For more information about metering methods, see Metering methods.
Why does a guaranteed-performance instance sometimes fail to reach the upper limit for its performance metrics?
A guaranteed-performance instance does not guarantee that all performance metrics, including bandwidth, can reach their maximum values at the same time. Throttling is triggered based on the first metric that reaches its peak.
For example, for a large I (slb.s3.small) instance, if the QPS reaches 20,000 but the number of concurrent connections has not reached 200,000, the instance may never reach its maximum connections limit. This is because new connection requests are dropped when the QPS limit is reached.
Can I change the instance type of a guaranteed-performance instance?
Yes, you can.
You can change the instance type of a guaranteed-performance instance in the console. For more information, see Modify the configurations of a pay-as-you-go CLB instance.
Starting from 00:00:00 (UTC+8) on June 1, 2025, you can no longer purchase pay-by-specification CLB instances. You cannot change the metering method of a pay-by-LCU instance to pay-by-specification. For more information, see End-of-sale for pay-by-specification CLB instances.
You can change only shared-resource CLB instances to high-performance ones. You cannot change high-performance CLB instances to shared-resource ones.
Changing a shared-performance instance to a guaranteed-performance instance does not affect your services or the IP address of the SLB instance.
The IP address of the SLB instance is not affected by upgrade or downgrade operations.
We recommend that you change a shared-performance instance to a guaranteed-performance instance during off-peak hours. Alternatively, you can use DNS to load balance traffic across multiple instances before you change the instance type.
After I change the instance type of a guaranteed-performance instance, why does the change not take effect immediately?
If you change the instance type and the metering method from pay-by-bandwidth to pay-by-data-transfer or vice versa at the same time, the changes take effect at 00:00:00 the next day instead of immediately.
Can I change the primary and secondary zones after a CLB instance is created?
No, you cannot.
You cannot change the primary zone after a CLB instance is created. The system automatically selects the most suitable secondary zone based on resource availability in each region. You do not need to configure it manually.
You can use Application Load Balancer (ALB) and Network Load Balancer (NLB), which support multi-zone deployment. For more information, see What is SLB?, What is ALB?, and What is NLB?.
Does the processing time of a CLB instance include the time to receive data from and send data to a client?
Yes, it does. The processing time of a Server Load Balancer (CLB) instance includes the time to receive data from and send data to a client.
Time to receive client data: This is the total time that a CLB instance takes to read a client request. This time is measured by the
read_request_timemetric. It includes the time to receive the HTTP request header (read_header_time) and the request body (read_body_time).Time to send response data: This includes the time to return a response to the client.
How can I get the list of public IP CIDR blocks automatically assigned to CLB?
The public IP addresses of CLB are dynamically allocated. You must obtain the list of CLB IP CIDR blocks in advance. You can then add the CIDR blocks to a firewall whitelist to prevent access restrictions.
Elastic IP addresses (EIPs) and the public IP addresses of CLB are allocated from the same public IP resource pool. You can call the DescribePublicIpAddress operation to obtain the public IP CIDR blocks in a specified region.
This API operation supports paging. The default page size is 100 entries. If the result contains more than 100 entries, adjust the paging parameters to obtain the complete list.
Can I disable Ping for the endpoint of a CLB instance?
No, you cannot. You can associate the public IP address of a public-facing CLB instance or the EIP bound to a private-facing CLB instance with an Internet firewall. Then, you can configure an inbound policy to deny ICMP traffic.
The endpoint of a CLB instance can be pinged only if the instance has at least one listener in the running state.
Why does a scan show all UDP ports are open when the CLB instance listens only on TCP ports?
This is a false positive from the scanning tool's algorithm. CLB silently drops packets for UDP ports that do not have listeners. It does not send "ICMP Port Unreachable" messages back to the client. Some scanning tools misinterpret the lack of this response and report the port as open. In reality, CLB does not process or forward any service requests on non-listening ports. This does not affect the security of the instance.