FAQ about CLB listeners

Does Classic Load Balancer (CLB) support port redirection?

This is supported.

CLB supports port redirection. For an example, see Redirect HTTP requests to HTTPS using CLB.

Do Layer 4 listeners of CLB support port ranges?

No, they do not. To configure a TCP or UDP listener for a port range, you can create a Network Load Balancer (NLB) instance and enable the full-port feature for the TCP or UDP listener. For more information, see Use the full-port listening feature of NLB to forward traffic from multiple ports.

What do I need to know when I configure a listening port for a CLB instance?

Some ISPs mark ports such as 25, 135, 139, 444, 445, 5800, and 5900 as vulnerable ports and block them by default. Even if you allow these ports in security group rules, users in the affected regions cannot access them. Therefore, you should use other non-vulnerable ports for your services.

• For more information about the ports used by Windows Server, see the Microsoft documentation Service overview and network port requirements for Windows.

• For more information about common ports, see Common ports.

How do I configure a listener if WebSocket or WebSocket Secure services are deployed on backend servers?

• If WebSocket services are deployed on backend servers, you can configure a TCP or HTTP listener.

• If WebSocket Secure services are deployed on backend servers, you can configure a TCP or HTTPS listener.

How and when do changes to a CLB listener configuration take effect, and what is the impact?

The changes take effect immediately and apply only to new requests. Existing connections are not affected.

Why can't I access a URL that contains special characters after I configure a URL forwarding rule?

Special characters in a URL must be URL-encoded before they can be accessed. For example, the pound sign (#) must be encoded as %23. The access URL should be http://www.example.com/%23/. For the complete encoding rules, see RFC 3986.

How do I manage backend servers for a CLB forwarding rule?

On the forwarding rule page, click the name of the target server group in the vServer Group column. On the page that appears, you can add, delete, or modify the port or weight of backend servers.

Why is traffic dropped even though the monitoring data shows that the bandwidth does not exceed the specification?

This issue is usually caused by the following reasons:

• The bandwidth monitoring data from Alibaba Cloud is calculated based on a one-minute average. If instantaneous traffic exceeds the bandwidth limit of the instance, traffic is dropped. The monitoring chart may not show this because it displays an average value. As long as the average bandwidth over one minute does not exceed the limit, the chart shows that the bandwidth usage is within the specification.

• The SLB system provides services for CLB instances in a cluster deployment. All external access requests are evenly distributed to these SLB system servers for forwarding. The specified bandwidth cap is distributed among multiple system servers. If the amount of data downloaded by a client connection exceeds the threshold of a single server, traffic is dropped. For more information about how to calculate the maximum traffic for a single connection, see Why can't a connection reach the bandwidth cap in some scenarios?

Why is the listener traffic shown in monitoring data greater than the configured speed limit?

The SLB system provides services for CLB instances in a cluster deployment and uses distributed throttling. The formula is: Bandwidth cap of a single node = Total bandwidth of the SLB instance / (N - 1), where N is the number of child nodes in the cluster. Therefore, the overall speed limit is slightly higher than the configured value.

Why can't a connection reach the bandwidth cap in some scenarios?

• Scenario: When you use a public-facing CLB instance that uses the pay-by-bandwidth billing method, a connection may not reach the bandwidth cap in some scenarios, such as during stress testing from a single client or when you transmit oversized data packets.

• How it works:

  The SLB system provides services for CLB instances in a cluster deployment. All external access requests are evenly distributed to the SLB system servers for forwarding. Therefore, the specified bandwidth cap is distributed among these system servers.

  The formula to calculate the maximum download bandwidth for a single connection is: Maximum download bandwidth for a single connection = Total bandwidth of the SLB instance / (N - 1), where N is the number of child nodes in the cluster. N is 4 for Layer 4 listeners and 8 for Layer 7 listeners. For example, if you set the bandwidth cap to 10 Mbps in the console, the total bandwidth can reach 10 Mbps when multiple clients are used at the same time. The maximum download bandwidth for a single client is 10 / (4 - 1) = 3.33 Mbps.

• Recommended solution:

  • Use the pay-by-data-transfer billing method for the public-facing CLB instance.

  • Use a Network Load Balancer (NLB) or Application Load Balancer (ALB) instance with EIPs and an Internet Shared Bandwidth instance. This solution provides sufficient elasticity for the load balancer instance and does not have this limit.

Why can't a CLB instance reach the QPS cap in some scenarios?

• Scenario: In business scenarios that use a small number of persistent connections, the system servers in the forwarding group may not all be assigned persistent connections. This can cause the CLB instance to fail to reach the queries-per-second (QPS) cap.

• Cause:

  The SLB system provides services for load balancer instances in a cluster deployment. All external access requests are evenly distributed to the SLB system servers for forwarding. Therefore, the QPS cap of the CLB instance is distributed among these system servers.

  The formula to calculate the QPS cap of a single system server is: QPS cap of a single system server = Total QPS of the instance / (N - 1), where N is the number of system servers in the forwarding group. For example, if you purchase a CLB instance of the slb.s1.small instance type, the corresponding QPS is 1,000. When multiple clients are used at the same time, the total QPS can reach 1,000. If the number of system servers is 8, the maximum QPS of a single system server is 1,000 / (8 - 1) = 142.

  Note

  New purchases of pay-by-specification CLB instances will be discontinued at 00:00:00 on June 1, 2025 (UTC+8). For more information, see Discontinuation Notice for Pay-by-Specification Classic Load Balancer (CLB) Instances.

• Solutions:

  • Use short-lived connections from a single client for stress testing.

  • Reduce connection reuse as needed.

  • Upgrade the instance type of the CLB instance. For more information, see Upgrade or downgrade a pay-as-you-go (pay-by-specification) instance.

  • Use an Application Load Balancer (ALB) instance. This solution provides sufficient elasticity for the load balancer instance.

Why can't the rate of new connections reach the cap in some scenarios?

• Scenario: When you use a Classic Load Balancer (CLB) instance that uses the pay-by-specification billing method, the rate of new connections per second (CPS) may not reach the specified level in some scenarios, such as during stress testing from a single client or a single access source.

  Note

  New purchases of pay-by-specification CLB instances will be discontinued at 00:00:00 on June 1, 2025 (UTC+8). For more information, see Discontinuation Notice for Pay-by-Specification Classic Load Balancer (CLB) Instances.

• Cause:

  The SLB system uses a cluster deployment architecture to ensure high availability and extensibility. All connection operations for external access requests are evenly distributed to multiple system servers in the cluster for processing. Therefore, the CPS cap of the CLB instance is distributed among these servers.

  The formula to calculate the CPS cap of a single system server is: CPS cap of a single system server = Total CPS of the instance / (N - 1), where N is the number of system servers in the forwarding group.

  For example, if you purchase a CLB instance of the slb.s1.small instance type, its nominal CPS is 3,000. When multiple clients access the instance at the same time, the overall CPS can reach 3,000. If the number of system servers is 4, the CPS cap of a single server is 3,000 / (4 - 1) = 1,000.

• Solutions:

  • Change the billing method of the CLB instance: Change the billing method of the CLB instance from pay-by-specification to the more flexible pay-as-you-go. Pay-as-you-go CLB instances do not require you to specify an instance type and have higher performance limits than most pay-by-specification instances. This prevents performance issues caused by undersized specifications.

  • Upgrade to Network Load Balancer (NLB): For scenarios with high concurrency and a high demand for new connections, use the NLB service. NLB provides better performance and elasticity than CLB. A single NLB instance supports 100 million concurrent connections, making it suitable for large-scale concurrent connection scenarios. This helps avoid insufficient CPS caused by the limited number of system servers in CLB.

What are the connection timeout ranges for different listeners?

• TCP listener connection timeout: 10 to 900 seconds.

• HTTP listener:

  • Idle connection timeout: 1 to 60 seconds.

  • Request timeout: 1 to 180 seconds.

• HTTPS listener:

  • Idle connection timeout: 1 to 60 seconds.

  • Request timeout: 1 to 180 seconds.

Why do connections to the SLB endpoint time out?

From the server-side perspective, the following issues can cause connections to the endpoint to time out:

• Security protection on the endpoint

  This includes traffic blackholing, traffic scrubbing, and Web Application Firewall (WAF) protection. WAF sends RST packets to both the client and the server cluster after a connection is established.

• Insufficient client ports

  This is especially common during stress testing. Insufficient client ports can cause connection failures. By default, SLB removes the timestamp attribute from TCP connections. This prevents the `tw_reuse` feature of the Linux protocol stack from taking effect to reuse connections in the `time_wait` state. The buildup of connections in the `time_wait` state leads to a shortage of client ports.

  Solution: Use persistent connections instead of short-lived connections on the client. Use RST packets to close connections (set the SO_LINGER attribute for the socket) instead of FIN packets.

• The accept queue of the backend server is full

  If the accept queue of a backend server is full, the backend server does not reply with SYN-ACK packets, which causes the client to time out.

  Solution: The default value of net.core.somaxconn is 128. Evaluate your service volume and adjust this value as needed. Then, run the sysctl -w net.core.somaxconn=<new_value> command to change the parameter and restart the application on the backend server.

• Accessing the endpoint of a Layer 4 SLB instance from one of its backend servers

  For Layer 4 (TCP/UDP) listeners of CLB, a backend server cannot act as both a client and a server. Accessing the endpoint of a CLB instance from one of its backend servers causes connection failures. A common scenario is when a backend application uses URL concatenation to access the CLB endpoint.

  Solutions:

  • Use a different client instead of the backend server of the Layer 4 SLB instance.

  • Migrate to Network Load Balancer (NLB) and disable the Preserve Client IP feature in the server group. After this feature is disabled, the ECS instances in the server group can act as both backend servers and clients that access the NLB instance. To obtain the source IP address of the client, enable Proxy Protocol. For more information, see How can an ECS instance act as both a backend server and a client of an NLB instance?.

• Improper handling of RST packets for connection timeouts

  After SLB establishes a TCP connection, it sends RST packets to both the client and the server to close the connection if there is no activity for 900 seconds. Some applications do not handle RST exceptions properly and may send data over a closed connection, which causes the application to time out.

  Note

  The default value is 900 seconds. You can adjust it as needed.

What are the timeout rules for HTTP and HTTPS connections?

• A maximum of 100 consecutive requests can be sent over an HTTP persistent connection. The connection is closed if this limit is exceeded.

• The timeout period between two HTTP or HTTPS requests over a persistent connection is configurable from 1 to 60 seconds, with a margin of error of 1 to 2 seconds. If the timeout period is exceeded, the TCP connection is closed. To use persistent connections, you must send a heartbeat request at an interval of less than 13 seconds.

• The timeout period for the TCP three-way handshake between SLB and a backend ECS instance is 5 seconds. If a timeout occurs, SLB selects the next ECS instance. You can check the upstream response time in the access log to locate the issue.

• The timeout period for SLB to wait for a response from an ECS instance is configurable from 1 to 180 seconds. If a timeout occurs, SLB usually returns a 504 or 408 status code to the client. You can check the upstream response time in the access log to help locate the issue.

• The timeout period for HTTPS session reuse is 300 seconds. If the timeout period is exceeded, the same client must perform a full SSL handshake again.

If a client actively disconnects before receiving a response from the backend server, does SLB also disconnect from the backend server?

SLB does not disconnect from the backend server during read and write operations.

How do I enable backend persistent connections for a Classic Load Balancer (CLB) instance?

CLB instances do not support enabling backend persistent connections. To implement this feature, you can create an Application Load Balancer (ALB) instance, configure an HTTP or HTTPS listener, and enable backend persistent connections for the corresponding ALB server group. For more information, see Create and manage a server group.

How do I troubleshoot high latency when I access a backend service through CLB?

When you access a backend service through CLB, a small increase in latency compared to direct access is expected. Layer 7 listeners of CLB use a reverse proxy architecture (Tengine). Requests are forwarded by CLB, which adds latency for one network hop and protocol processing. Layer 4 listeners use LVS for forwarding, and the additional latency is typically small.

If the latency is significantly high, troubleshoot the issue as follows:

1. Enable access logs and analyze the latency fields: Enable CLB access logs and focus on the following fields:

   • request_time: The interval between the time when CLB receives the first request packet and the time when it returns a response. Unit: seconds.

   • upstream_response_time: The time from when a connection is established with the backend server to when all data is received and the connection is closed. Unit: seconds.

2. Determine the source of the latency:

   • If upstream_response_time is high: The latency is usually caused by slow processing on the backend server. Check the performance of the backend application, the efficiency of database queries, and the usage of resources such as CPU and memory. You can also add more backend servers to share the load.

   • If request_time is much greater than upstream_response_time: The latency may be on the network link from the client to CLB. Run continuous ping tests or MTR route traces from the client to the CLB endpoint to troubleshoot network link issues.

3. Cross-region access: If the client and the CLB instance are in different regions, network latency due to physical distance is unavoidable. Use Global Accelerator (GA) to optimize the cross-region access experience.

How do I troubleshoot 502, 503, and 504 errors returned by CLB?

When you access a backend service through CLB, 502, 503, and 504 errors usually indicate that the request was not processed correctly by the backend server. The meanings of the three error codes are as follows:

• 502 Bad Gateway: CLB cannot forward the request to the backend server or cannot get a response from the backend server. Common causes include an unreachable backend service or all health checks failing.

• 503 Service Temporarily Unavailable: This is usually caused by traffic exceeding the limit or an unavailable backend server. This error code is returned when the instantaneous traffic of a request exceeds the QPS limit of the CLB instance.

• 504 Gateway Time-out: The backend server timed out. Common causes include long processing time on the backend server or a connection timeout with the backend server.

Step 1: View access logs

First, enable CLB access logs and check the status (the status code that CLB returns to the client) and upstream_status (the status code that the backend server returns to CLB) fields in the logs:

• If the value of status is the same as the value of upstream_status, CLB likely passed through the exception status code from the backend server. In this case, prioritize troubleshooting the cause of the status code returned by the backend server.

• If the value of upstream_status is "-" or different from the value of status, the error code was returned by CLB. You can refer to the following points for troubleshooting.

Troubleshooting 502 errors

• All backend servers fail health checks: When all backend servers associated with a listener fail health checks, CLB cannot forward requests and returns a 502 error. Check the health check status in the console and troubleshoot the cause of the health check failures. Causes can include iptables or third-party security software blocking the 100.64.0.0/10 CIDR block (the system CIDR block of CLB), mismatched health check status code configuration, or a non-existent health check path. For more information, see FAQ about CLB health checks.

• CLB converts an exception status code from the backend into a 502 error: If the backend server returns certain exception status codes (such as 504 or 444), CLB may return a 502 error to the client. Check the upstream_status field in the access log to confirm the actual status code returned by the backend and troubleshoot the cause of the backend server exception.

• Backend service exception: A 502 error can also be caused by high load on the backend server, an abnormal response format, or an abnormally closed connection. Check the backend server logs and the usage of resources such as CPU and memory.

Troubleshooting 503 errors

• Traffic exceeds the instance specification limit: A 503 error is returned when the QPS, bandwidth, or number of new connections for traffic accessing CLB exceeds the current specification limit. You can obtain these metrics from Cloud Monitor.

• Instantaneous traffic exceeds the limit but is not shown in monitoring: Cloud Monitor displays minute-level data and may not show when the limit is exceeded at the second level. Check the number of requests per second in the access log. If the upstream_status field in the log is "-", it means the request was not sent to the backend server.

Troubleshooting 504 errors

• Backend response timeout: CLB returns a 504 error if the backend server does not return a response within the request timeout period configured for the listener. Check the upstream_response_time field in the access log to confirm the actual response time of the backend and adjust the request timeout period of the listener accordingly.

• Backend connection timeout: The timeout period for the TCP three-way handshake between CLB and a backend ECS instance is 5 seconds. If the upstream_response_time in the access log is too long, there may be a connection issue with the backend server. Capture packets to troubleshoot the cause.

• High backend load: High usage of resources such as CPU and memory on the backend server causes the response time to exceed the timeout period. Troubleshoot and optimize the performance of the backend service, or add more backend servers to share the load.

How do I troubleshoot access failures to services through CLB?

If you cannot access a service after you configure CLB, troubleshoot the issue by following these steps:

1. Check the domain name resolution: If you are accessing the service through a domain name, check that the domain name is correctly resolved to the endpoint of the CLB instance. You can use the nslookup or dig command to verify the resolution result. A domain name resolution error is a common cause of access failure.

2. Check the listener configuration: In the CLB console, check whether a listener has been created and confirm that the listening port and protocol are configured correctly. If no listener is added or the listening port is configured incorrectly, requests cannot be forwarded.

3. Check the health check status: In the CLB console, view the health check status of the backend servers. When all backend servers fail health checks, CLB cannot forward requests.

4. Check the firewall settings: Check whether the iptables or third-party security software on the backend servers allows access to the backend service port and the CLB system CIDR block 100.64.0.0/10.

5. Check whether the backend service is running properly: Log on to the backend server and run telnet <private_IP_of_backend_server> <port> (for Layer 4) or curl -I http://<private_IP_of_backend_server> (for Layer 7) to confirm that the backend service can respond normally.

6. Check the network link: Test access to the CLB endpoint from different network environments. If only the on-premises network has an issue, you can run continuous ping tests or MTR route traces for further troubleshooting.

What do I do if I can access a CLB instance using its IP address but not its domain name?

The most common reason is that the domain name has not completed its ICP filing.

According to relevant regulations, if you use a domain name to access a service over the public network in the Chinese mainland, the domain name must have an ICP filing. Access to a domain name without an ICP filing is blocked, which results in a 403 status code or a reset connection.

Troubleshoot and handle the issue as follows:

1. Check the ICP filing status of the domain name: Log on to the Alibaba Cloud ICP Filing system to check whether the domain name has completed its ICP filing. If not, complete the ICP filing first. For more information, see ICP filing procedure.

2. Check to add Alibaba Cloud to the ICP filing information as a service provider: If the domain name has completed its ICP filing with another cloud service provider but is being used with Alibaba Cloud for the first time, you also need to add Alibaba Cloud to the ICP filing information as a service provider. Failure to do so may also result in blocked access.

3. Rule out other causes: If the domain name has completed its ICP filing and you have added Alibaba Cloud to the ICP filing information, check whether the domain name resolution correctly points to the CLB endpoint. You can verify this with the nslookup or dig command. Also, check whether the CLB listener port and protocol configuration match the domain name access method.

Does configuring access control for a private-facing CLB instance that is bound to an EIP affect internal network access?

Yes, it does. Access control is applied at the listener level and affects both internal and public network access. If the whitelist allows only specific public IP addresses, internal network access requests from addresses not on the whitelist are blocked. To avoid affecting internal services, you can add the relevant internal CIDR blocks to the whitelist or use Cloud Firewall to restrict public network access to the EIP.

How do I troubleshoot request timeouts during stress testing on a CLB instance?

If you encounter a 504 status code and request timeouts during stress testing on a Layer 7 CLB instance, and the upstream_response_time in the logs is consistently around 5 seconds, the issue is usually a connection timeout caused by a failed TCP three-way handshake between CLB and the backend server. A common reason is that the connection tracking table (nf_conntrack) on the backend server is full, which causes it to drop new connection packets.

Log on to the backend server and check the /var/log/messages log. If the following error appears, the cause is confirmed:

nf_conntrack: table full, dropping packet

Solution: Adjust the nf_conntrack parameters. The following values are for reference only. Adjust them as needed.

sysctl -w net.netfilter.nf_conntrack_max=1048576
sysctl -w net.netfilter.nf_conntrack_buckets=262144
sysctl -w net.netfilter.nf_conntrack_tcp_timeout_established=3600

Note: The preceding commands take effect only temporarily and will be invalid after the instance is restarted. To make the changes permanent, write the parameters to the /etc/sysctl.conf file.

How do I handle a situation where a backend database failure causes all sites under the same listener to become inaccessible?

Scenario: Multiple sites are mounted under a CLB listener, such as a static website at www.example.com and a dynamic website at app.example.com. When the backend database of the dynamic website fails, the static website also becomes inaccessible and reports an HTTP 502 error.

Cause: The two websites share the same listener. The listener's Health Check Domain Name is configured as the domain name of the dynamic website. When the backend of the dynamic website fails, all backend servers fail health checks. CLB stops forwarding traffic to the backend servers, which ultimately affects access to all sites under the listener.

Solution: Use different CLB instances for the dynamic and static websites to isolate the services. This way, a failure of the dynamic website does not affect access to the static website.

Why does session persistence sometimes fail?

• Session persistence is not enabled: Check whether session persistence is enabled in the listener configuration.

• Issues with HTTP/HTTPS listeners: For HTTP or HTTPS listeners, SLB cannot insert the required cookie for session persistence into response messages that have a 4xx status code.

  Solution: Use a TCP listener. TCP listeners use the source client IP address for session persistence. You can also insert a cookie on the backend ECS instance and add a cookie check for extra assurance.

• 302 redirection issues: A 302 redirection changes the `SERVERID` string in the session persistence cookie.

  When SLB inserts a cookie, if a backend ECS instance replies with a 302 redirection message, the `SERVERID` string in the session persistence cookie is changed, which causes session persistence to fail.

  Troubleshooting: Capture the request and response on the browser or use packet capture software to analyze whether there is a 302 response message. Compare the `SERVERID` strings in the cookies of the messages before and after the redirection to see if they are different.

  Solution: Use a TCP listener. TCP listeners use the source client IP address for session persistence. You can also insert a cookie on the backend ECS instance and add a cookie check for extra assurance.

• The session persistence timeout period is too short: If the session persistence timeout period is set too short, session persistence may fail.

How do I view the session persistence string?

You can press the F12 key in your browser to check whether the response message contains the `SERVERID` string or a user-specified keyword. You can also run curl www.example.com -c /tmp/cookie123 to save the cookie, and then run curl www.example.com -b /tmp/cookie123 to access the site.

How do I use the Linux curl command to test SLB session persistence?

1. Create a test page.

   On all backend ECS instances of the SLB instance, create a test page that displays the private IP address of the local machine. The private IP address is used to determine which physical server a request is assigned to. By observing the consistency of this IP address, you can determine the effectiveness of SLB session persistence.

   

2. Run the curl command in Linux.

   Assume that the IP address of the SLB service is 10.170.X.X and the URL of the test page is http://10.170.X.X/check.jsp.

   1. Log on to the Linux server used for testing.

   2. Run the following command to query the cookie value of the SLB server.

      curl -c test.cookie http://10.170.X.X/check.jsp

      Note

      The default session persistence mode for Alibaba Cloud SLB is cookie injection. The `curl` command does not save or send cookies by default. You must first save the corresponding cookie for the test. Otherwise, the `curl` test results are random, and you may mistakenly conclude that SLB session persistence is not working.

   3. Run the following command to perform continuous tests.

      for ((a=1;a<=30;a++));
          do curl  -b test.cookie http://10.170.XX.XX/check.jsp  | grep '10.170.XX.XX';
          sleep 1;
      done

      Note

      The `a<=30` part specifies the number of repetitions. You can change it as needed. The grep '10.170.X.X' part filters the displayed IP information. Modify it based on the private IP addresses of your backend ECS instances.

   4. Observe the IP addresses returned by the test. If it is the same private IP address of an ECS instance, SLB session persistence is working. Otherwise, there is an issue with SLB session persistence.

How do I configure cookies on a backend server when I use the Rewrite Cookie mode?

If you select the Rewrite Cookie mode for Layer 7 session persistence in CLB, you need to configure a cookie with the corresponding name on the backend server. The cookie name must be the same as the one configured in the CLB console. The following are configuration examples for common web servers:

server {
    listen 8080;
    server_name wqwq.example.com;
    location / {
        add_header Set-Cookie name=xxxx;
        root   html;
        index  index.html index.htm;
    }
}

How do I troubleshoot load imbalance among backend servers?

If the load on one backend server is significantly higher than on others after you mount multiple backend servers to a CLB instance, troubleshoot the issue by following these steps:

1. Check whether session persistence is enabled: HTTP/HTTPS listeners of CLB support session persistence through cookie injection. When session persistence is enabled, all requests from the same client are routed to the same backend server. If a few clients generate many requests, the traffic is concentrated on specific backend servers, which leads to load imbalance.

2. Disable session persistence for even load distribution: If your service does not rely on session state, such as cookies or logon status, you can disable session persistence for the listener. After it is disabled, CLB distributes requests evenly to all backend servers based on the scheduling algorithm, such as weighted round-robin. Perform this operation during off-peak hours and immediately verify service availability. Disabling session persistence affects services that rely on user state, such as shopping carts and logon status persistence. Before you perform this operation, you must assess the dependency of your services on session persistence.

3. Check the application load on backend servers: Even if CLB distributes traffic evenly, differences in CPU, memory, and other resource usage on the backend servers themselves can cause some servers to have a higher load. Log on to each backend server, compare the resource usage of the applications, and check for performance bottlenecks.

Why does a website load normally over an HTTP listener but fail to load styles over an HTTPS listener?

Symptom:

You create an HTTP listener and an HTTPS listener, and both listeners use the same backend servers. When you access the website over HTTP, the website displays normally. However, when you access it over the HTTPS listener, the website layout is garbled.

Cause:

By default, SLB does not block the loading and transmission of JS files. Possible causes are:

• The certificate is not compatible with the security level of the browser.

• The certificate is from an unofficial third-party provider. Contact the certificate publisher to check for issues with the certificate.

Solution:

1. When you open the website, follow the browser prompts to load the scripts.

2. Add the corresponding certificate to the client.

After I configure HTTP-to-HTTPS redirection on a CLB instance, do I still need to configure a certificate on the backend server?

No, you do not. You need to configure the relevant certificate only in the HTTPS listener of the CLB instance. For more information, see Configure an SSL certificate.

After I update a certificate on a CLB instance, why does the browser still show the old expiration date?

This usually happens because the CLB instance is connected to WAF 2.0 in transparent proxy mode, and the certificate on the WAF side has not been updated. WAF synchronizes certificates from CLB periodically. To synchronize immediately, you can disable and then re-enable traffic redirection on the WAF side to force a refresh of the certificate status. Note that this operation causes a transient disconnection of 1 to 2 seconds for your services.

Does CLB support HSTS?

CLB does not support configuring the HSTS response header. To enable HSTS, you can use one of the following methods:

• Add the Strict-Transport-Security response header on the backend server yourself.

• Connect to WAF and enable HSTS through WAF.

What HTTP protocol version does an HTTP or HTTPS listener use to access backend servers?

• If the client request uses HTTP 1.1 or HTTP 2.0, the Layer 7 listener uses HTTP 1.1 to access the backend server.

• If the client request uses a protocol other than HTTP 1.1 and HTTP 2.0, the Layer 7 listener uses HTTP 1.0 to access the backend server.

Can a backend server obtain the protocol version of a client request to an HTTP or HTTPS listener?

Yes, it can.

Does CLB support URL-based speed limiting?

CLB does not support URL-based speed limiting. CLB supports bandwidth throttling only at the listener level.

Application Load Balancer (ALB) supports URL-based speed limiting. You can configure a forwarding rule for a listener to set a QPS limit for a specific path. This requires using the "Forward to" action. See the following figure:

Why does the `Transfer-Encoding: chunked` field appear in the HTTP request header of a Layer 7 CLB instance?

The Transfer-Encoding: chunked field is a standard field in the HTTP protocol that indicates the message body uses chunked transfer encoding. Layer 7 CLB is implemented based on the Tengine reverse proxy and uses chunked transfer when it forwards requests to the backend. Therefore, the backend server sees this field in the request header. This is normal behavior for a reverse proxy and does not affect your services. Layer 4 CLB only forwards traffic and does not add this field.

After a request is forwarded by a Layer 7 CLB instance, why are some parameters in the backend response header deleted?

To implement session persistence, CLB deletes fields such as Date, Server, X-Pad, and X-Accel-Redirect from the response header. To keep these fields, you can add a prefix to your custom response headers, such as xl-server, or use a Layer 4 TCP listener instead.

Are `proxy_buffering` and `proxy_cache` enabled for CLB?

The proxy_buffering and proxy_cache features are not enabled for CLB. CLB does not buffer or cache request or response data. Instead, CLB directly forwards client requests to the backend servers in transparent proxy mode. This is the default configuration of CLB and requires no additional settings.

Instructions for enabling WAF protection for CLB

Does disabling the public NIC affect the SLB service?

If an ECS instance has a public IP address, disabling the public network interface controller (NIC) affects the SLB service.

This is because when a public NIC is present, the default route goes through the public network. Disabling the public NIC prevents response packets from being sent back, which affects the SLB service. Do not disable the public NIC. If you must disable it, you need to change the default route to the private network to avoid affecting the service. However, you must consider whether your services depend on the public network, such as accessing RDS over the public network.

Does SLB support client requests that contain the TOA field?

No, it does not. The TCP Option Address (TOA) field in a client request conflicts with the TOA field that SLB uses for internal communication. This conflict prevents the client's originating IP address from being obtained.