All Products
Search
Document Center

Server Load Balancer:access control

Last Updated:May 25, 2026

Classic Load Balancer (CLB) access control filters client requests by using IP whitelists and blacklists on listeners. You can create an access control list (ACL), add IP entries to it, and then associate the ACL with a listener to allow or block traffic from specific sources.

Create an access control list

An access control list (ACL) is a collection of IP entries. After you create an ACL and add IP entries, you can associate it with a listener to implement whitelist or blacklist-based access control.

Console

  1. Go to the Access control page of the CLB console. In the top navigation bar, select the region of the target instance, and then click Create ACL.

  2. In the Create ACL panel, enter an ACL Name, select an IP Version (IPv4 or IPv6), add IP entries, and then click Create.

    IPv4 instances support only IPv4 access control lists (ACLs), and IPv6 instances support only IPv6 ACLs. Select the IP version that matches your CLB instance.

API

Call the CreateAccessControlList operation to create an ACL.

Add IP entries

After you create an ACL, you can add IP entries to it.

Console

Go to the Access control page of the CLB console and click the ID of the target ACL to go to the details page. Add IP entries in one of the following ways:

  • Add a single entry: Click Add Entry. Enter an IP Address/CIDR Block and Remarks, and then click Add.

  • Add entries in batches: Click Add ACL Entries and enter the entries in the following format:

    • Enter one entry per line.

    • Use a vertical bar (|) to separate the IP address or CIDR block from its remarks. Example: 192.168.1.0/24|Remarks.

    • You can add up to 50 entries at a time.

After you add the entries, you can delete or export them from the entry list.

API

Enable or disable access control

After you create an ACL and add IP entries, associate the ACL with a listener to enable access control. If you no longer need access control, you can disable it at any time.

Important
  • If an ACL is empty, access control has no effect and the listener forwards all requests, regardless of whether it is configured as a whitelist or a blacklist. To prevent service disruptions when using a whitelist, ensure the ACL contains the IP addresses that you want to allow.

  • IP entries must be unique across all ACLs associated with a single listener.

Console

  1. Go to the Instances page of the CLB console. In the top navigation bar, select the region where the target instance is deployed, and then click the instance ID.

  2. Click the Listener tab. Find the target listener, and click Enable or Close in the ACL column.

    • Enable: In the dialog box that appears, select an Access Control Mode (Whitelist: Allows Specified IP Addresses to Access the SLB Instance or Blacklist: Forbids Specified IP Addresses to Access the SLB Instance) and select an ACL, and then click Save.

    • Close: In the confirmation dialog box, click OK.

You can also enable or disable access control in the Access Control section of the listener details page.
You can also enable access control when you create a listener.

API

When you call an API operation to create or modify a listener, such as CreateLoadBalancerHTTPSListener or SetLoadBalancerHTTPSListenerAttribute, use the following parameters to configure access control:

  • AclStatus: Specifies whether to enable access control. Valid values: on and off.

  • AclType: The type of the ACL. Valid values: white (for a whitelist) and black (for a blacklist).

  • AclId: The ID of the associated ACL.

FAQ

Whitelist allows access from any IP

Cause: The ACL is not associated with the listener (access control is not enabled), or the ACL contains no IP entries. An empty ACL allows all traffic.

Solution: Go to the Listener tab for the CLB instance. Make sure that Enabled is displayed in the ACL column for the target listener, and verify that the associated ACL contains IP entries.

Blacklisted IPs can still access

Cause: Requests are forwarded to CLB through a proxy, such as a Content Delivery Network (CDN) or Web Application Firewall (WAF). The source IP address that CLB sees is the source IP of the proxy, not the real client IP. Therefore, blacklist rules based on client IPs will not match.

Solution: Configure an IP blacklist on the upstream proxy layer (CDN or WAF). If clients can bypass the proxy and access CLB directly, you can configure a whitelist on CLB to allow access only from the proxy's source IP range.

NGINX allow/deny rules ineffective for Layer-7 listeners

Cause: After a CLB Layer-7 listener proxies a request, the backend server receives an internal source IP address from CLB (from the 100.64.0.0/10 CIDR block). The NGINX allow/deny rules, which are based on source IP addresses, cannot match the real client IP.

Solution:

ECS security groups do not block CLB traffic

Cause: CLB communicates with backend ECS instances over the 100.64.0.0/10 CIDR block. By design, traffic from this CIDR block bypasses the inbound rules of ECS security groups.

Solution: To restrict access based on client IP addresses, configure a whitelist or blacklist on the CLB listener to block requests before they are forwarded.

Client response to blocked requests

Explanation: CLB access control drops blocked requests without sending any response. The client connection times out.

Can a whitelist prevent DDoS attacks?

Explanation: No. CLB access control cannot protect against DDoS attacks. Attack traffic consumes instance bandwidth before it reaches the access control layer, which can trigger blackhole filtering in severe cases.

Recommendation: Use Anti-DDoS.

Access control in multi-layer proxy scenarios

If a Layer-7 proxy is deployed in front of CLB, CLB access control can only see the source IP of the immediate upstream proxy and cannot identify the real client IP. In this case, you must configure access control at the appropriate layer. Take a scenario where WAF is connected via CNAME (Client → CDN → WAF → CLB → ECS) as an example. The following table describes the observed source IP and recommended access control strategy for each layer.

In cloud service integration (transparent integration) mode, the system automatically adjusts the underlying network routing to direct traffic from the CLB listener port to WAF for security inspection. WAF intercepts malicious requests and forwards legitimate traffic back to the source CLB instance. This mode does not use a dedicated WAF source IP range, so no extra configuration is needed for CLB access control.

Layer

Observed source IP

Access control recommendation

WAF

  • If no CDN is used, the observed source IP is the real client IP.

  • If a CDN is used, the observed source IP is the CDN source IP. You must configure how to identify client IP addresses in the WAF settings to obtain the real client IP.

Configure an IP whitelist or blacklist at this layer. After WAF is correctly configured, it can block requests based on the real client IP and supports region-based blocking.

CLB

The WAF source IP.

Configure a whitelist on CLB to allow access only from the WAF source IP range. This prevents attackers from bypassing WAF and accessing the public IP of CLB directly. You can view the WAF source IP range on the Manage page of the WAF console.

Backend ECS

An internal IP address of CLB (from the 100.64.0.0/10 CIDR block).

Make sure that the internal firewalls on your ECS instances (such as iptables or firewalld) do not block traffic from the 100.64.0.0/10 CIDR block. Otherwise, health checks and request forwarding will fail.

Billing

The access control feature is free of charge. For details on CLB instance billing, see CLB billing overview.

Quotas

You can request to increase the following quotas in Quota Center.

Limit

Quota name

Default limit

Request an increase

Number of ACLs per Alibaba Cloud account

slb_quota_acls_num

200

Go to Quota Center

Number of entries per ACL

slb_quota_acl_entries_num

300

Number of listeners per ACL

slb_quota_acl_attached_num

50

The following limits are fixed and cannot be increased.

Limit

Maximum value

Number of ACLs per listener

3

Total IP entries across all ACLs associated with a listener

1000