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.
Does the default domain name of an NLB instance support direct access?
The DNS name assigned to an NLB instance cannot be directly accessed. You must point your custom domain name to the DNS name of the NLB instance by adding a CNAME record at your DNS provider, and then use the custom domain name to access 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, choose Instances.
On the Instances page, click the ID of the target NLB instance.
On the instance details page, in the Zone section, you can view the VIP (private service IP address). If the NLB instance is Internet-facing, you can also view the EIP.
Why do I get a connection refused error when I access a service through an NLB instance?
When you access a service through an NLB instance, if curl returns a Connection refused error, this is usually because the backend port configured for the server group is different from the port on which the backend service actually listens. As a result, NLB cannot forward traffic to the backend.
To troubleshoot this issue, perform the following checks:
Check that the ports are consistent: In the NLB console, check the backend port configured for the server group. Log on to the backend server and run
ss -tlnpto check the port on which the backend service actually listens. The two ports must be consistent.Check the security groups: Make sure that both the security group of the NLB instance and the security group of the backend ECS instance allow inbound traffic on the listener port.
Check the health status: In the NLB console, check the health status of the listener to confirm that the backend server is healthy.
What are the differences between using a VIP and using a CNAME to connect to an internal NLB instance?
Connection method | VIP direct connection | CNAME domain name (resolves to the DNS name of the NLB instance) |
IP type | Private IP address (assigned independently in each zone) | DNS resolves to private IP addresses |
Zone failover | Automatic failover is not supported | Unhealthy zones are automatically removed |
Recommended scenario | Temporary debugging or single-zone deployments | Production environments or high-availability scenarios |
In private network access scenarios, such as when an Elastic Compute Service (ECS) instance in the same virtual private cloud (VPC) accesses the NLB instance, we recommend that you use PrivateZone to resolve a custom private domain name to the DNS name of the NLB instance. This way, resources in the VPC can access the NLB instance by using the custom domain name.
Can the DNS name of an Internet-facing NLB instance be used for internal access?
No, it cannot. The DNS name of an Internet-facing NLB instance resolves to the elastic IP address (EIP) of the instance and cannot be used for access over private networks. We recommend that you use an internal NLB instance and access it by using its VIP, or resolve a custom private domain name to the DNS name of the instance.