All Products
Search
Document Center

Server Load Balancer:CLB instance FAQ

Last Updated:Jun 09, 2026

This topic answers frequently asked questions (FAQs) about Classic Load Balancer (CLB) instances.

This topic covers the following questions:

Category

Questions

Instance selection

Instance types

Instance configuration

Instance O&M

How to select a pay-as-you-go instance

Starting from 00:00:00 on June 1, 2025 (UTC+8), pay-by-specification CLB instances are no longer available for purchase.

By default, CLB instances use the pay-by-LCU metering method. The performance of an instance scales automatically with usage, which means you do not need to specify an instance type. You are charged an hourly fee based on your actual usage (LCUs). For more information about performance limits, see Instance performance limits. For more information about metering methods, see Instance metering methods.

Why instances may not reach performance limits

This follows the weakest-link principle. A guaranteed-performance instance does not guarantee that all three of its performance metrics, including bandwidth, can reach their upper limits at the same time. Throttling is triggered when any of the metrics reaches its limit.

For example, a user selects a High-performance I (slb.s3.small) instance. If the QPS of the instance has reached 20,000 but the number of concurrent connections has not reached 200,000, the maximum number of connections may never reach the upper limit specified for the instance type. This is because new connection requests are dropped when the QPS reaches its upper limit.

Can I change the instance type?

Yes, you can.

You can modify the configuration of a guaranteed-performance instance in the CLB console. For more information, see Modify the configuration of a pay-as-you-go instance.

Note
  • Starting from 00:00:00 on June 1, 2025 (UTC+8), pay-by-specification CLB instances will no longer be available for purchase. You can no longer change the metering method of a pay-by-LCU instance to pay-by-specification. For more information, see Announcement on the end of sale for pay-by-specification Classic Load Balancer (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-resource instance to a guaranteed-performance instance does not affect your services or change the IP address of the CLB instance.

  • Configuration modifications do not change the IP address of the CLB instance.

    We recommend that you change from a shared-resource instance to a guaranteed-performance instance during off-peak hours. Alternatively, use DNS to implement load balancing among instances before you modify the configuration.

Why are instance type changes not immediate?

If you change the instance type and the metering method (for example, from pay-by-bandwidth to pay-by-data-transfer) at the same time, both changes take effect at 00:00:00 the next day instead of immediately.

Can I change the availability zones?

No.

You cannot change the primary availability zone after a CLB instance is created. The system automatically selects the most appropriate secondary availability zone based on regional conditions, and no manual configuration is required.

We recommend using Application Load Balancer (ALB) or Network Load Balancer (NLB), which support multi-zone deployment. For more information, see Server Load Balancer (SLB) product family, What is Application Load Balancer (ALB)?, and What is Network Load Balancer (NLB)?

Does CLB processing time include data transfer?

Yes, the processing time of a CLB instance includes the time to receive client data and send response data.

  • Time to receive client data: The value of the read_request_time metric. This metric indicates the time the load balancer takes to read 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 required to return response data to the client.

How to get CLB public IP ranges

CLB public IP addresses are dynamically allocated. To avoid access restrictions, we recommend obtaining the CLB IP CIDR blocks in advance and adding them to your firewall's whitelist.

EIPs and the public IP addresses of CLB instances 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.

Note

This API operation supports pagination. The default page size is 100. If more than 100 entries are returned, you must adjust the pagination parameters to obtain the complete list.

How to troubleshoot a stopped CLB instance

A CLB instance enters the Stopped state for one of the following reasons:

  • The instance is manually set to the inactive state by a call to the SetLoadBalancerStatus API operation. After a user or an automated program calls this API operation, the instance immediately stops forwarding traffic.

  • Your account has an overdue payment, causing the system to lock the account and automatically stop the instance.

  • The associated Elastic IP Address (EIP) or shared bandwidth plan is released due to an overdue payment.

You can use ActionTrail to identify why the instance was stopped. Log on to the ActionTrail console. On the event query page, search for the SetLoadBalancerStatus event. View the time and operator of the event to determine whether it was a manual operation.

If the instance was not stopped due to an overdue payment, go to the Instances page in the CLB console, find the instance, and click Start in the Actions column to resume the instance.

Can I disable Ping on a CLB instance?

No. As a workaround, you can add the public IP of an Internet-facing CLB instance or the EIP bound to an internal-facing CLB instance to an Internet firewall and configure an inbound rule to deny ICMP traffic.

The service address of a CLB instance responds to Ping requests only if the instance has at least one listener in the running state.

Why do scans show open UDP ports?

This is a false positive generated by the algorithm of some scanning tools. CLB uses a silent drop policy for UDP ports without configured listeners. It discards incoming packets without sending an ICMP Port Unreachable message. When a scanning tool does not receive this response, its logic may incorrectly report the port as open. In reality, CLB does not process or forward any requests on non-listening ports, so this behavior does not affect the security of your instance.