This topic provides answers to some frequently asked questions about Network Load Balancer (NLB).
Does NLB provide specific instance types?
No. NLB does not provide specific instance types. When you create instances, you do not need to specify an instance type.
NLB supports automatic scaling. Each NLB instance supports up to 100 million concurrent connections and 100 Gbit/s of bandwidth. NLB supports higher Layer 4 load balancing performance than Classic Load Balancer (CLB). We recommend that you use NLB. For more information about the differences between NLB and CLB, see Functions and features.
Why does the inbound rule configured for the security group of my NLB instance not take effect?
If an NLB instance is added to a security group that does not contain a Deny rule, the listener port of the NLB instance allows all requests. To allow requests only from specific IP addresses to your NLB instance, add a Deny rule to the security group of your NLB instance. Make sure that the Deny rule has a lower priority than the Allow rules.
For more information about how to manage security groups, see the following topics:
For more information about how to block or allow requests from specific IP addresses, see Use security groups as blacklists or whitelists.
For more information about how to enable access control for NLB instances based on protocols and ports, see Configure security groups for NLB instances
Why does the virtual IP address (VIP) of my NLB instance fail to forward requests?
Perform the following operations to troubleshoot errors:
Check whether Cross-Zone Distribution is disabled. After you enable Cross-Zone Distribution, requests that are destined for the NLB instance can be forwarded to backend servers in other zones. If you disable Cross-Zone Distribution and no backend servers are deployed in the zone of the NLB instance, the VIP of the zone cannot be used to forward requests destined for the NLB instance.
Check whether the zone is removed from the DNS record. If the zone is removed from the DNS record, the VIP of the zone is removed from the A record of the NLB instance. The VIP is no longer resolved to the domain name of the NLB instance. As a result, the VIP of the zone cannot be used to forward requests destined for the domain name of the NLB instance.
Check whether a network access control list (ACL) is enabled for the NLB instance and the 100.64.0.0/10 CIDR block is not on the whitelist. If you configure an ACL for the vSwitch of the VIP and do not add the 100.64.0.0/10 CIDR block to the whitelist, the VIP fails health checks because 100.64.0.0/10 is used for zone health checks. As a result, the VIP of the zone is removed from the A record of the NLB instance and cannot be used to forward requests destined for the domain name of the NLB instance.
How do I configure my NLB instance to allow an ECS instance in the server group to work as both a backend server and a client?
Disable Client IP Preservation for the server group associated with your NLB instance. Then, an Elastic Compute Service (ECS) instance in the server group can work as both a backend server processing requests, and a client accessing your NLB instance. If you still want to retrieve client IP addresses in this case, enable Proxy Protocol for the associated listener. For detailed information, see the following references:
For information about disabling client IP preservation, see Edit basic information.
For information about enabling Proxy Protocol for a TCP listener, see Add a TCP listener.
For information about enabling Proxy Protocol for a UDP listener, see Add a UDP listener.
Can a subscription EIP be associated with an NLB instance?
No, it cannot.
Elastic IP addresses (EIPs) that can be associated with NLB instances must meet the following requirements:
Billing method: pay-as-you-go
Internet metering method: pay-by-data-transfer
Whether associated with Internet Shared Bandwidth instances: no
Why can't I add a host route for the Local IP of an NLB instance?
NLB assigns a Local IP from the CIDR block of the corresponding vSwitch in each zone. For example, in zone H, the Local IP 10.0.0.86 belongs to the 10.0.0.0/24 vSwitch CIDR block, and in zone I, the Local IP 10.0.1.16 belongs to the 10.0.1.0/24 vSwitch CIDR block. The VPC route table automatically includes system local routes that cover each vSwitch CIDR block (for example, 10.0.0.0/24→local and 10.0.1.0/24→local). These system routes already ensure that NLB Local IPs are reachable.
If you attempt to add a /32 host route for a Local IP (for example, 10.0.0.86/32) by calling CreateRouteEntry, the system returns an InvalidCidrBlock error. This is a VPC design restriction that prevents you from adding routes for IP addresses that already fall within an existing local route CIDR block.
You do not need to manually configure routes for NLB Local IPs. The system local routes in the VPC route table already guarantee traffic reachability for NLB instances in each zone.
Can the service IP address of an NLB instance change?
When an NLB instance is created, the system assigns it a private IP address or an EIP to serve traffic. This service IP address does not change on its own after creation. However, the service IP address can change in the following scenarios:
Zone changes: When you update the zones for an instance, IP addresses may be added or removed. For Internet-facing instances, EIPs will be added or removed. For internal instances, private IP addresses will be added or removed.
Network type changes: Changing from internal to Internet-facing: A new EIP or Anycast EIP will be assigned to the instance. Changing from Internet-facing to internal: All public IP addresses will be disassociated from the instance.
Can I disable Ping for the VIP of an NLB instance?
Yes. NLB allows you to manage inbound traffic using security groups. To disable Ping, add an inbound rule to the instance's associated security group that denies all ICMP traffic.
Why can't I directly access the default domain name of an NLB instance?
The DNS domain name assigned to an NLB instance (for example, nlb-xxx.cn-shanghai.nlb.aliyuncsslb.com) is not ICP-licensed and cannot be accessed directly in a browser. To access your NLB instance, use your own domain name that has completed ICP licensing, and add a CNAME record that points to the DNS domain name of the NLB instance.
How do I query the IP addresses bound to an NLB instance?
Log on to the NLB console. In the left-side navigation pane, click Instances.
On the Instances page, click the ID of the target NLB instance.
On the instance details page, in the Zones section, you can view the virtual IP address (VIP) of each zone.
If your NLB instance is an Internet-facing instance, you can also view the elastic IP address (EIP) bound to the instance.
For an internal NLB instance, only VIPs are displayed. For an Internet-facing NLB instance, both EIPs and VIPs are displayed.
Private Network Connection and Disaster Recovery
How can ECS instances in the same VPC connect to backend services through NLB?
ECS instances in the same VPC can directly use the NLB virtual IP address (VIP) to connect to backend services. For example, ECS instances can connect to an MQTT broker on port 1883 by targeting the NLB VIP. The VIP is a static private IP address that is assigned when the NLB instance is created and does not change afterward.
NLB supports TCP and UDP protocol listeners on any port number, including port 1883 for MQTT. You can configure a listener for the required protocol and port when setting up the NLB instance.
What is the difference between VIP direct connection and CNAME domain name connection?
NLB provides two ways to connect to backend services from within a VPC: using the static VIP directly, or using the NLB CNAME domain name. The following table compares the two options:
Comparison item | VIP direct connection | CNAME domain name |
IP type | Static private IP address | DNS-resolved private IP address |
AZ failover on zone failure | Not supported — traffic remains pinned to the zone VIP | Supported — unhealthy zones are automatically removed from DNS |
Recommended use case | Temporary testing or single-AZ deployments | Production environments or high-availability scenarios |
We recommend that you use the private CNAME domain name of your NLB instance to connect to backend services. This enables AZ-level disaster recovery. You can use the NLB CNAME directly, or configure PrivateZone to resolve a custom private domain name to the NLB CNAME.
How do I configure PrivateZone to resolve a private domain name to an NLB CNAME?
You can use Alibaba Cloud PrivateZone to configure a custom private domain name that resolves to the CNAME of your NLB instance. This allows applications in the VPC to reach NLB through a human-readable internal domain name.
Log on to the PrivateZone console and create a private zone bound to the target VPC.
In the private zone, add a CNAME record that maps your custom domain name to the NLB CNAME domain name (for example,
nlb-xxx.cn-hangzhou.nlb.aliyuncsslb.com).After the CNAME record takes effect, applications in the VPC can use the custom private domain name to access the NLB instance with AZ-level failover support.
Can I use the CNAME of a public-facing NLB instance for internal VPC access?
No. The CNAME of a public-facing NLB instance resolves to elastic IP addresses (EIPs). When internal VPC traffic targets an EIP, it exits the VPC and is routed through the Alibaba Cloud Internet boundary, where it is blocked.
For internal VPC access, use the CNAME of an internal (private network) NLB instance, or configure PrivateZone with the CNAME of a private NLB instance.
How do I configure multi-AZ disaster recovery for NLB?
The following end-to-end configuration enables AZ-level automatic failover:
Create or confirm the NLB instance spans at least two availability zones. Each zone is assigned a dedicated static VIP (for example, Zone H: 10.0.0.86, Zone I: 10.0.1.16).
Enable cross-zone forwarding. On the NLB instance details page, in the Zones section, confirm that Cross-Zone Forwarding is enabled. With this feature, NLB forwards traffic to backend servers in other zones when a zone becomes unavailable.
Add backend servers from multiple zones. Add ECS instances from each availability zone to the server group to ensure backend redundancy.
Use the NLB CNAME domain name — not a VIP — to connect to the NLB instance. When a zone fails, NLB automatically removes the VIP of that zone from its DNS records (DNS removal). Traffic is automatically routed to the healthy zones.
With Cross-Zone Forwarding enabled and the CNAME domain name in use, NLB provides automatic AZ-level failover and supports zone-level disaster recovery.