Help Center/ Elastic Load Balance/ User Guide (Paris Region) / FAQ/ What Can I Do If ELB Can't Be Accessed or Traffic Routing is Interrupted?
Updated on 2024-04-19 GMT+08:00
View PDF
Share

What Can I Do If ELB Can't Be Accessed or Traffic Routing is Interrupted?

  1. Check the health of backend servers. If a backend server is unhealthy, traffic will be routed to other healthy servers. Rectify the health check fault and access ELB again.
  2. Check whether the security group rules allow access from the corresponding IP address range.
    • Dedicated load balancers: Check whether the security group containing the backend server has inbound rules to allow traffic from the backend subnet where the load balancer is deployed.
    • Shared load balancers: Check whether the security group containing the backend server has inbound rules to allow traffic from the 100.125.0.0/16 and 100.125.0.0/16.
    • Shared load balancers: If Transfer Client IP Address is enabled for a TCP or UDP listener, there is no need to configure security group rules and Network ACL rules to allow traffic from 100.125.0.0/16, 100.126.0.0/16, and client IP addresses to backend servers.
    • Dedicated load balancers: If IP as a Backend is not enabled for a load balancer that has a TCP or UDP listener, there is no need to configure security group rules and Network ACL rules to allow traffic from the backend subnet where the load balancer is deployed to the backend servers.
  3. Check whether a TCP connection is established between the load balancer and the client. The timeout duration for a TCP connection is 300s and cannot be changed. If the duration exceeds 300s, the load balancer sends an RST message to the client and the backend server to disconnect the connection.
  4. Check whether sticky sessions are enabled and the sticky session type is set to source IP address. If yes, check whether the request IP address changes before the request reaches the load balancer.

    For example, if ELB is combined with Content Delivery Network (CDN) or Web Application Firewall (WAF), the IP address of the request changes when it passes through CDN or WAF. The IP address change causes session stickiness to fail. If you want to use CDN or WAF, it is recommended that you add an HTTP or HTTPS listener and configure cookie-based sticky sessions.

  5. Check whether the listener is an HTTP or HTTPS listener and sticky sessions are enabled. If yes, check whether the request contains a cookie. Sticky sessions at Layer 7 are based on cookies. If the request contains a cookie, check whether the cookie value changes.
  6. Check the stickiness duration configured for the backend server group. If sticky sessions are enabled, the default stickiness duration of the backend server group at Layer 4 and Layer 7 is 20 minutes. After the stickiness duration times out, the connection will be disconnected.
  7. Check whether the servers you access are associated with a load balancer.

    If Transfer Client IP Address is enabled for TCP or UDP listeners, a cloud server cannot be used as both a backend server and a client.

  8. Check whether you have added a backend server in a VPC that is different from the one where the load balancer is running, by using the server's IP address. If yes, check whether a VPC peering connection has been established between the two VPCs.
Parent topic: FAQ