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 maximum bandwidth?

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

The maximum bandwidth of each connection is calculated based on the following formula: Maximum bandwidth per connection = Maximum bandwidth 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 maximum bandwidth of a CLB instance to 10 Mbit/s, the maximum bandwidth of each connection = 10/(4 - 1) = 3.33 Mbit/s.

To prevent service interruptions, we recommend that you set the maximum bandwidth 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: Set clients to establish long-lived connections instead of short-lived 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 on the backend server is full, the backend server can no longer return syn_ack packets. 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?

  • Check whether 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 redirects change 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.

    In this example, the IP address of the CLB instance that runs Linux is 10.170.XX.XX and the URL of the created 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++));
          do curl  -b test.cookie http://10.170.XX.XX/check.jsp  | grep '10.170.XX.XX';
          sleep 1;
      done
      Note a<=30 indicates the number of tests to be performed. You can set this value based on your business requirements. Set the IP address in grep '10.170.XX.XX' to the private IP address of your 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.