Does CLB support port forwarding?

Yes, CLB supports port forwarding.

For more information, see Redirect HTTP requests to HTTPS.

Will my service be interrupted after I disable a public network interface controller (NIC)?

If an Elastic Compute Service (ECS) instance is assigned a public IP address, your service will be interrupted after you disable the public NIC.

By default, if an ECS instance is assigned a public IP address, the ECS instance uses the public IP address to communicate with the Internet. In this case, network traffic is transferred through the public NIC of the ECS instance. If you disable the public NIC, the ECS instance cannot send responses to the Internet. We recommend that you keep the public NIC enabled. If you want to disable the public NIC, you must change the destination of the default route to a private IP address. Before you modify the default route, make sure that the ECS instance does not need to access resources such as ApsaraDB RDS over the Internet.

Why do connections fail to reach the bandwidth limit?

CLB provides load balancing services by evenly distributing network traffic across groups of backend servers. Therefore, bandwidth is evenly allocated to each connection.

The bandwidth limit of each connection is calculated based on the following formula: Bandwidth limit per connection = Bandwidth limit of the CLB instance/(N - 1). N represents the number of server groups. In this example, N is 4. For example, if you set the bandwidth limit of a CLB instance to 10 Mbit/s, the bandwidth limit of each connection = 10/(4 - 1) = 3.33 Mbit/s.

To prevent service interruptions, we recommend that you set the bandwidth limit of each listener to a proper value.

How long is the connection timeout period for each listener?

  • TCP listener: 900 seconds
  • UDP listener: 90 seconds
  • HTTP listener: 60 seconds
  • HTTPS listener: 60 seconds

Why does a CLB connection time out?

Possible causes:

  • The IP address of CLB is blocked for security reasons.

    The IP address of CLB may be blocked due to traffic blackholing and scrubbing or Web Application Firewall (WAF) protection. WAF offers protection by sending Reset (RST) packets to the client and the backend server after a connection is established.

  • Client port exhaustion.

    Client port exhaustion can cause connection errors, especially in stress tests. By default, CLB removes the timestamps of TCP connections. As a result, the tw_reuse setting does not take effect and connections in the time_wait state cannot be reused. These accumulated connections exhaust all ports.

    Solution: Use long-lived TCP connections instead of short-lived TCP connections. Set the SO_LINGER socket option to close connections by sending RST packets instead of FIN packets.

  • The accept queue of a backend server is full.

    If the accept queue of a backend server is full, SYN packets sent from the client are dropped and no SYN-ACK packet is returned from the backend server. As a result, the client times out.

    Solution: The default value of the net.core.somaxconn parameter is 128. Run sysctl -w net.core.somaxconn=1024 to change the value of this parameter to 1024 and then restart the application on the backend server.

  • Layer 4 CLB is accessed from backend servers.

    If you access Layer 4 CLB from a backend server, the connection fails. For example, a request that reaches a backend server is redirected to the application on another backend server.

  • RST packets are not correctly responded.

    If no data is transmitted within 900 seconds after a TCP connection is established on CLB, CLB sends RST packets to the client and the backend server to close the connection. If the application on the backend server does not correctly respond to the RST packet, it may send data packets after the connection is closed. As a result, a CLB connection timeout occurs.

Why does session persistence fail?

  • Make sure that session persistence is enabled for the listener.
  • HTTP and HTTPS listeners cannot persist sessions by inserting cookies into responses that carry 4xx status codes.

    Solution: Use TCP listeners instead of HTTP or HTTPS listeners. TCP listeners persist sessions based on client IP addresses. Backend servers can also insert or even validate cookies to ensure that sessions are persisted.

  • HTTP 302 redirection changes the SERVERID string for persisting a session.

    When CLB inserts a cookie into a response that carries the HTTP status code 302, the SERVERID string is changed. As a result, the session cannot be persisted.

    To verify the cause, check the requests and responses by using your browser or packet capture software. Then, check whether a 302 status code is included in the packets and whether the SERVERID string in the cookie is changed.

    Solution: Use TCP listeners instead of HTTP or HTTPS listeners. TCP listeners persist sessions based on client IP addresses. Backend servers can also insert or even validate cookies to ensure that sessions are persisted.

  • The timeout period is set to a small value. You can set the timeout period to a greater value.

How do I view a cookie?

Open the browser and press F12 to check whether SERVERID or a user-defined cookie is inserted in the response. You can also run the curl www.example.com -c /tmp/cookie123 command to save a cookie and then run the curl www.example.com -b /tmp/cookie123 command to view the cookie.

How do I verify session persistence by using the Linux curl command?

  1. Create a test page.

    Create a test page on each backend server. You can view the private IP address of the backend server on the test page. The following figure shows an example of a test page. The private IP address indicates the backend server to which requests are distributed. The private IP address is used to check whether CLB can persist sessions.

  2. Run the curl command in Linux.

    The IP address of the CLB instance in this example is 10.170.XX.XX. The URL of the test page is http://10.170.XX.XX/check.jsp.

    1. Log on to a server that runs Linux.
    2. Run the following command to query the cookie inserted by the backend server:
      curl -c test.cookie http://10.170.XX.XX/check.jsp
      Note By default, CLB persists sessions by inserting cookies. However, curl does not send or save cookies. Therefore, you must save a cookie before you perform the test. Otherwise, the curl test result may show that session persistence is invalid.
    3. After you save the cookie, run the following command:
      for ((a=1;a<=30;a++)); 2="" do="" curl="" -b="" 1.cookie=""
                  check.jsp="">/dev/null | grep '10.170.*';sleep 1; done`
      Note a<=30 indicates the number of tests to be performed. You can set this value based on your business requirements. grep '10.170.*' indicates the IP address. You can set this value based on the private IP address of the ECS instance.
    4. Check the IP addresses returned in the preceding tests. If the same IP address is returned, it indicates that CLB can persist sessions.

If a connection is closed on the client side before the client receives a response, does CLB close the connection on the server side?

No, CLB does not close the connection on the server side in this case.

If a request already carries a TCP Option Address (TOA) header before the request is sent to CLB, can CLB preserve the client IP address in the header?

No, CLB cannot preserve the client IP address in this case. By default, if the TOA module is installed, CLB automatically adds TOA headers to preserve client IP addresses. When CLB receives a request that carries a TOA header, CLB cannot preserve the client IP address in the header.