Configuration-related questions
TCP Timeout Configuration?
Set the TCP connection timeout duration. The input range is an integer between 10 and 4000, with a default value of 900 seconds. If the timeout is set too short, long-idle connections may close prematurely; if set too long, unnecessary connections may be kept open by the real server. It is recommended to adjust the timeout value according to your backend service's specific needs.
Can real servers send requests to associated load balancer instances?
The load balancer allows a single BCC to act as both a client and a server. In such cases, the Client IP and Server IP seen by BLB are identical. Keep in mind that source IP forwarding rules do not prevent loopback. To avoid loopbacks, you can choose weighted round-robin or weighted least-connections forwarding rules.
Are there relatively reasonable recommended values for health check configurations?
For the configuration of health check parameters, consider the following recommendations:
- Health Check Port: By default, health checks use the backend service port. If necessary, you can specify a custom port for your workload.
- Response timeout: 3 seconds
- Health check interval: 3 seconds
- Unhealthy threshold: 3
- Health threshold: 3
Can a group of cloud server instances host multiple websites to perform load balancing simultaneously?
Yes.
- A single BLB instance supports up to 20 listener configurations. Each listener can link to an application running on a backend cloud server, with the BLB’s frontend port mapping to the corresponding backend BCC service port.
- You can host multiple applications on backend BCC instances to support multiple websites and enable Load Balancer functionality across them.
Can the load balancer directly get the client IP address?
Layer 7 IPv4 and IPv6 Load Balancer listeners provide the real client IP through the X-Forwarded-For header. This feature is enabled by default on the load balancer, and the backend service must be configured to retrieve the client IP.
Note: If the client request to the BLB already contains the X-Forwarded-For HTTP header, the BLB appends the real client IP to the existing value, separated by a comma. For example: original value, client’s real IP.
In Layer 4 IPv4 and IPv6 Load Balancer (TCP/UDP listeners), backend servers can include BCC, BBC, physical machines, container custom Pod IPs, or servers connected via dedicated lines. Due to variations in network architecture, different backend types may require unique data forwarding configurations to retrieve the client IP. For standard BCC virtual machines or second-generation BBC instances, the real client IP can be directly obtained on the server without additional configuration. In certain special cases, specific configurations are required to retrieve the real client IP.
- IPv6 NAT64 load balancer does not support to directly get the Client IP. You can enable the ProxyProtocol protocol to obtain the client's source IP, source Port, access destination IP, destination Port and access protocol. Before enabling, be sure to configure the real server to support the ProxyProtocol protocol.
- In Layer 4 Load Balancer scenarios where first-generation BBC instances, physical machines, container custom Pod IPs, servers on the opposite end of dedicated connections, or IP groups are used as real servers, the classic FullNAT forwarding mode is applied. In this mode, the load balancer replaces the source IP in the packet with an IP from its own subnet (currently 100.64.0.0/10) via SNAT, and inserts the original client IP into a custom TCP option or IP option field. As a result, the real server cannot directly obtain the real client IP. To retrieve it, you need to either install the open-source TTM module or enable the ProxyProtocol. For details, you can submit a ticket to contact technical support.
Can the same BLB configure two HTTPS certificates to listen ports 443 and 442 respectively?
You can configure multiple HTTPS certificates. Upon adding a listener in the settings, each HTTPS listener can be assigned a specific server certificate.
Can a server be configured on two different BLBs?
A single server can be added as a real server to two BLB instances simultaneously.
In BLB listener settings, what is the difference between TCP listener and HTTP listener?
Layer 4 (TCP protocol) listeners offer three forwarding strategies: weighted round robin, least connections, and source IP. Layer 7 (HTTP and HTTPS protocols) listeners support weighted round robin and least connections. TCP operates at the transport layer, whereas HTTP functions at the application layer.
Among the multiple IPs obtained by the load balancer, which one is the real IP of the end user?
For Layer 7 (HTTP and HTTPS) listeners, enabling the “Retrieve Real Client IP” feature during BLB listener setup allows the client IP to be accessed via the HTTP header: X-Forwarded-For. For Layer 4 (TCP protocol) listeners, the real client IP of external clients is directly accessible without extra configuration. However, if the client is an internal BCC instance, retrieving the real IP isn’t currently supported. If the client's request to the BLB already contains the X-Forwarded-For HTTP header, the BLB appends an additional X-Forwarded-For header, resulting in two such headers in the request, with the latter added by the BLB.
How to configure session persistence for BLB?
For BLB session persistence configuration, refer to the [document](BLB/Operation guide/General-purpose BLB instance/Creating BLB Ordinary Instance.md#Configure listener) below.
How to perform regular comprehensive checks on the status of BLB resources?
You can activate the "Cloud Advisor" service to regularly receive inspection reports on the security, availability, performance and cost of cloud resources. The report includes several BLB-related inspection items, such as BLB Listener Security, BLB Without real servers, and BLB Load Balancer. Please visit Cloud Advisor Homepage to learn about or activate the Cloud Advisor service
Why does the health check fail when an application BLB mounts an IDC server via an IP group?
After connecting the IDC to the VPC via a dedicated line, application-type BLB health checks can fail when connecting IDC servers through IP groups. Two solutions are commonly used: (1) Configure health check routes for the 100.64.0.0/10 subnet; (2) Set a low-priority default route, such as 0.0.0.0/0, to the dedicated line gateway. If there are no conflicts, the second option is often preferred, as managing specific routes for the 100.64.0.0/10 subnet isn’t necessary.
Explanation on intranet loopback issues
To prevent a server from acting as both client and real server, which would cause the client IP and server IP to be the same and result in connectivity issues, BLB includes a loopback prevention switch in its scheduling logic, which is enabled by default. Therefore, when a Client acts as a real server, please bind at least two real servers; otherwise, access will fail. When a client accesses the load balancer, the load balancer automatically routes the request to a real server other than the client’s own server (Client A). Currently, WRR (Weighted Round Robin) and WLC (Weighted Least Connections) can be configured for loop avoidance on the console interface.
The difference between setting the backend RS weight to 0 and deleting the RS in Layer 4 Load Balancer
Setting the backend weight to 0: New connections will no longer be forwarded to this real server, but existing connections will continue to be served until they time out due to inactivity or are closed by the client or server; Deleting RS: New connections will no longer be forwarded to this real server, existing UDP connections will stop forwarding, while existing TCP connections will continue forwarding but with accelerated aging time; Note that WRR (Weighted Round Robin) and WLC (Weighted Least Connections) are weighted scheduling algorithms, while RR (Round Robin) is a non-weighted scheduling algorithm. Adjusting the backend weight to 0 has no effect when using the RR scheduling policy.
The difference between setting the real server weight to 0 and deleting the RS in Layer 7 Load Balancer
For HTTPS/HTTP/SSL_TCP listeners, setting the backend weight to 0 and removing the RS effectively produce the same outcome: new connections stop being forwarded to the real server, but existing connections remain active until they either timeout due to inactivity or are closed by the client or server.
When there is few connections on the listener, why do the connections of each real server with the same weight under WRR or RR scheduling strategies differ?
In Layer 4 Load Balancer, a node runs multiple worker threads. The implemented WRR and RR scheduling algorithms operate on a per-worker basis, meaning each worker performs scheduling independently. When the number of connections on a listener is low, the network interface card RSS distributes the first packets of data flows unevenly across workers—some workers may receive traffic while others may not. This causes variations in WRR and RR scheduling results among different worker threads, leading to differences in the number of connections to real server with the same weight under WRR or RR scheduling policies when connection counts are low; When there are many connections on a listener, the network interface card RSS distributes the first packets of data flows relatively evenly across workers. Consequently, WRR and RR scheduling among workers is also relatively balanced, resulting in a more uniform distribution of connections to real server;
Why can the Layer 4 Load Balancer's source IP still receive and process traffic after the real server weight is set to 0 by hash scheduling algorithm?
The source IP hash scheduling algorithm is a Load Balancer method that disregards server weights. With this strategy, setting the real server's weight to 0 has no impact—new or existing connection messages may still be forwarded to the real server.
How to handle existing connections on a real server deleted from a Layer 4 Load Balancer?
- If all real servers are deleted from a TCP or UDP listener, the Load Balancer will no longer forward existing client connections. Forwarding ceases entirely until the connections timeout or are shut down, and the real server stops receiving packets.
- For a TCP listener with multiple real servers, removing one RS will, by default, allow active connections to that RS to keep receiving forwarded messages until the connections timeout or are closed. It is recommended to proactively terminate server connections before deleting the real server in such scenarios.
- For a UDP listener with multiple RSs, deleting a specific RS will stop forwarding messages to the active connections on that RS. Any subsequent messages will initiate new connections and reassign them to an available RS.
How to enable WebSocket support?
No extra configuration is required. If an HTTP listener is chosen, the unencrypted WebSocket (WS) protocol is enabled by default; if an HTTPS listener is chosen, the encrypted WebSocket (WSS) protocol is enabled by default.
Is it possible to upgrade a shared load balancer to a specification load balancer without service interruption?
Supported. Simply click the "Performance Adjustment" button on the list page for changes.
Does LB support uploading certificate?
Not supported. The load balancer directly uses certificates from the IAM Certificate Service, so you need to upload the certificates through the Certificate Management Console. Uploading certificates directly in the load balancer is not supported. The Certificate Management Console is located under Security Certification in the upper-right corner, or accessible by clicking Certificate Management on the left sidebar of the Load Balancer console.
How many HTTPS certificates can be bound to a single listener?
If one-way HTTPS authentication is configured, each listener can only be bound to one server certificate. For two-way HTTPS authentication, each listener must be bound to one server certificate and one CA certificate.
Are certificates region-specific?
No regional limitation. Once a certificate is purchased and issued, it can be installed and deployed without any regional restrictions.
Does the certificate need to be uploaded to the real server?
No, it isn't required. The HTTPS Load Balancer includes a certificate management system to handle and store user certificates. There is no need to upload certificates to real servers, as all private keys uploaded to the system are stored securely in an encrypted format.
HTTP and HTTPS use the same real server to provide services, the user can access HTTP listener normally, but access HTTPS abnormally with typesetting error. How to solve this problem?
Since BLB does not modify the transmission of JS files by default, it is recommended that you investigate the issue from the following aspects.
- Browser compatibility with certificate security levels
- Verify that the certificate is properly issued, ensuring it is a valid third-party certificate.
- Examine the code on the real server to check if there are any instances where HTTPS pages are loading HTTP resources.
Does traffic continue to be forwarded after a listener is released in BLB?
After being released, traffic associated with the corresponding listener will stop being forwarded to the real server.
Can the load balancer directly get the client IP address?
Layer 7 IPv4 and IPv6 Load Balancer listeners provide the real client IP through the X-Forwarded-For header. This feature is enabled by default on the load balancer side, and the backend service must be configured accordingly to retrieve the client IP. Note: If the request header sent by the client to the BLB already contains the HTTP header: X-Forwarded-For, the BLB will overwrite the X-Forwarded-For header by appending the client's real IP address to the existing value, separated by a comma. For example: original value, client's real IP. For Layer 4 IPv4 and IPv6 Load Balancer (TCP/UDP listeners), the backend can include various types of servers, such as BCC, BBC, physical machines, container custom Pod IPs, or servers connected via dedicated lines. Due to differences in network architecture, each type of real servers may require a different data forwarding method to obtain the client IP. When using standard BCC virtual machines or second-generation BBC instances as real servers attached to the load balancer, the real client IP can be obtained directly on the server side without additional configuration. In certain special scenarios, the real client IP cannot be obtained directly from the server side and requires specific configuration.
- IPv6 NAT64 load balancer does not support to directly get the Client IP. You can enable the ProxyProtocol protocol to obtain the client's source IP, source Port, access destination IP, destination Port and access protocol. Before enabling, be sure to configure the real server to support the ProxyProtocol protocol.
- In Layer 4 load balancing scenarios where first-generation BBC instances, physical machines, container custom Pod IPs, servers behind dedicated connections, or IP groups act as real servers, the classic FullNAT forwarding mode is utilized. In this mode, the load balancer replaces the source IP within the message with an IP from its own subnet (currently 100.64.0.0/10) via SNAT, inserting the original client IP into a custom TCP message or IP option field. Consequently, the real server cannot directly access the client’s actual IP. To retrieve it, you either need to install the open-source TTM module or enable ProxyProtocol. For detailed guidance, contact technical support or submit a Ticket.
The user still doesn't get real client IP although X-Forwarded-For is enabled. How to solve this problem?
If X-Forwarded-For is enabled to obtain the client IP but the real client IP is still not received, the following reasons may apply. It is recommended to investigate accordingly.
- It is recommended to check the BLB Configuration to ensure X-Forwarded-For is correctly configured.
- It is suggested to verify the protocol, as some protocols (e.g., WebSocket) do not support the X-Forwarded-For header field.
- It is suggested to check whether additional link modules are introduced post-BLB and assess their status. For instance, if a proxy server is employed to forward requests, misconfigurations on the proxy server could impact further forwarding operations.
- It is advised to inspect the client to determine if there is a chance of the client deleting or altering the X-Forwarded-For header field.
- It is recommended to verify the resolution on the backend service and confirm whether the X-Forwarded-For header field is accurately interpreted.
Can the count of real severs be adjusted while the load balancer is running?
The Load Balancer allows for adjustments to the number of real servers at any time, including various server switching operations. However, to maintain the stability of your external services, please monitor the real servers' health check status during these operations, ensuring that at least one functional server remains available in the Load Balancer's backend.
Does IPv6-BLB fail to mount BBC/BCC?
Start by verifying whether the BCC/BBC has been assigned an IPv6 address.
Does Baidu BLB support ECC p256 server certificates and CA certificates?
Support
How does BLB associate with a Security Group?
Method I: 1. Log in to the VPC console, under the Security Group Access Control, create the corresponding Security Group.
- Log in to the Load Balancer console, select Load Balancer Instances in the left navigation bar, locate the specific Instance, and click the Instance to enter the Details page.
- On the Instance details page, select the Security Group tab, click Associate Security Group, and bind the Security Group. Method II: 1. Log in to the VPC console, under the Security Group Access Control, create the corresponding Security Group.
- On the Security Group Details page, select Associate Load Balancer to link the corresponding Security Group to the Load Balancer.
How to modify the health check configuration of a listener?
- Log into the Load Balancer console, go to the Application Load Balancer Instances section in the left navigation bar, find the specific instance, and click on it to access the Details page.
- In the Instance Details page, navigate to Target Group > Server Group/IP Group, locate the desired server/IP group, and click Edit in the port protocol column.
- Adjust the health check configurations in the health check settings dialog as necessary, and then click OK.
Is the source IP network segment for load balancer health check probe 100.64.0.0/10?
The Load Balancer uses IP addresses from the 100.64.0.0/10 range as health probe source IPs. No additional Security Group allow rules for this subnet are required for backend Baidu Cloud Compute servers. Additionally, if iptables or other security policies are configured on the real server, ensure this subnet is allowed, or health probes will fail.
How to handle health check alerts?
When health checks indicate an exception, follow these troubleshooting steps: Verify that the real server has the corresponding Service port enabled. Check whether there are protective software like Firewalls inside the real server that might intercept health check messages. Check that no iptables rules are restricting the real server. Check whether the client can directly access the real server's application Service successfully. Verify whether the Load Balancer's health check parameters are correctly configured. For Layer 7 Load Balancers, it is recommended to use static pages for health checks. Check if the real server is under high load, causing slow external responses.
The health check indicates normal status, but the service remains inaccessible. How to solve this problem?
Check whether access control lists, Security Groups, or other access policies on the Load Balancer listener restrict Client access, and ensure the Client is allowed. If the scheduling algorithm is WLC, WRR, or others with weight attributes, check whether the configured weight on the RS is 0. If it is 0, modify the weight to a value greater than 0; Check whether the current bandwidth usage of the Load Balancer exceeds the purchased bandwidth; For UDP listeners configured with ICMP health checks, check whether the real server service ports are active;
Is the health check frequency of BLB too high?
BLB determines the availability of backend services by probing the health check status of real servers. The server must pass n consecutive probes with all results being healthy for the backend service to be considered operational. Where, n is the health check threshold. To avoid network jitter, multiple health checks are necessary. If the user perceives it as too frequent, they can adjust the health check configuration by themselves.
How long does it take for the health check status of real servers on the BLB console to change?
The time taken for this status update depends on the count of Instances in the Region. The higher the Instance count, the longer the update time. The health check status update time for Layer-4 protocol real servers is ≤150s The health check status update time for Layer 7 protocol real servers is <= 240 s Currently, the console RS status display logic operates independently, affecting only console visibility without impacting actual operations.
Why are IPs from the 100 network segment accessing real servers?
An IP address beginning with 100 belongs to the network segment 100.64.0.0/10. The Load Balancer Instance uses IP addresses from this subnet as source addresses for health check probes to real servers and for forwarding frontend service traffic in special forwarding modes. Therefore, to ensure your configured Load Balancer Instance functions properly, verify that the real server’s iptables security policy allows the 100.64.0.0/10 subnet.
With CIP pass-through enabled on the LB instance, why can the Server still receive connection requests from addresses in the 100.64.0.0/10 network segment?
The Load Balancer utilizes addresses within the 100.64.0.0/10 network segment as the source IPs for health checks. Typically, it leverages IPs ending in .3 and .4 to send health check messages to the Server. This process will not impact business operations and is considered normal behavior.
Why does the Server still receive a large number of connection requests from source IPs ending with .3 and .4 within the 100.64.0.0/10 network segment?
A BLB Cluster is composed of multiple physical machines, each using IPs ending in .3 and .4 to perform health checks on Servers. As a result, the same Server may observe connection attempts from various source IPs within the 100.64.0.0/10 subnet, all ending in .3 or .4.
How to check the status of the real servers of a load balancer instance?
There are two methods to view real server status on the Load Balancer:
- Log in to the Baidu AI Cloud console, navigate to Load Balancer BLB in the left sidebar, select the target Instance, then choose real servers on the Details page to view real-time health check statuses.
- Log in to the Baidu AI Cloud console, navigate to Load Balancer BLB in the left sidebar -> select the target Instance -> choose Monitor on the Details page. Port monitoring displays the count of normal/abnormal real servers.
How long does it take for a real server that is added with a load balancer instance to start handling traffic?
When a Load Balancer Instance mounts a new real server, the real server defaults to an unavailable state. After passing health checks, its status changes to Available. At this point, the real server will begin handling traffic. Thus, the activation time for newly added real servers depends on the health check's effective duration. When the backend Service is normal, Maximum effective time for a health check = health check timeout × number of health checks + health check interval × (number of health checks - 1) With the default health check configuration, the maximum effective time for a health check = 3 s × 3 + 3 s × 2 = 15 s. After users add real servers through the console, it takes some time for the configuration to be deployed to gateway devices. This factor should be accounted for in practical scenarios. This aspect is somewhat related to the cluster configuration scale and can generally be assumed to be within 30 seconds. Thus, after a user mounts a healthy real server via the console, it will begin handling Traffic within 45 seconds under default health check Configuration.
I find many health check requests on real servers sent from 100-segment IPs. Will the count of requests decrease later?
The Load Balancer instance uses 100.x.x.x segment IPs for real server health checks. Before cluster partitioning, the real servers undergo health checks by all machines in the cluster, which may result in the aforementioned phenomenon. The current Load Balancer instance has adopted a cluster-splitting architecture. Each user’s real server is only checked for health by the sub-cluster it belongs to, resulting in a relative reduction in such health check requests.