Troubleshooting Load Balancer

View as Markdown

For a problem with a load balancer, look first at its Status in the Load Balancers list. Then check the health of its servers on the Backend Mapping tab; see Monitor a load balancer. For questions about plans, regions, and billing, see Load Balancer FAQ.

The load balancer stays on Creating, Deploying, or Upgrading

Creating follows Launch Load Balancer. A load balancer with Frontend Protocol set to HTTP, or a Network Load Balancer, reads Running about four to seven minutes after you launch it.

Deploying follows every saved change. A timeout change, for example, is back to Running in about 35 seconds. MyAccount estimates two to three minutes for Deploying in the list, and five to 10 minutes in the message after you save.

Upgrading follows a plan upgrade and lasts a few minutes.

Actions, the Info edits, and Delete become available again once the load balancer leaves these statuses.

A short Deploying is expected when a scale group behind the load balancer grows. The load balancer reads Deploying while the new node joins it. The node gets its first requests about 35 seconds after it reads Running. Requests to the load balancer keep succeeding while the scale group grows.

A load balancer that stays in Creating keeps being charged until support clears it. If any of these statuses lasts far longer than those estimates, contact support, and include:

The load balancer’s name and its region.
The status it shows, and when it began.
What you did right before: the launch, the plan upgrade, or the change you saved, such as a certificate, a backend group, or an ACL rule.
Any message MyAccount showed, such as Unable to fire Load Balancer vm instance.

The load balancer shows Backend Connection Failure

Backend Connection Failure shows when at least one server fails its checks. The status covers the whole load balancer, so one failing server, even a node in a scale group, turns it to Backend Connection Failure while the other servers keep serving traffic. Running means every backend server passes its checks.

The status can also show while every server passes, when MyAccount receives no health data for the load balancer. When no server on Backend Mapping is marked DOWN, send a request to the load balancer’s address to see whether it serves traffic.

The load balancer checks every server every two seconds. A server that starts failing stops getting traffic after about six seconds, and gets traffic again about four seconds after it answers its check again.

Check these, in order:

Open the Backend Mapping tab, and find the server the load balancer reports DOWN.
Check that Server IP is the server’s private IP, or its address in the VPC once the load balancer is in a VPC. Check that Server Port is the port your application listens on. Once the first VPC is attached, the load balancer reaches your servers from its VPC address, so update the server IPs when you attach it. See Attach a VPC.
On the server, run this, where <server-port> is the Server Port:
```
ss -ltn | grep ':<server-port> '
```
When the application accepts connections from the network, the output shows the port on 0.0.0.0, *, [::], or the server’s address. A line that shows it only on 127.0.0.1 or [::1] means the application accepts connections from the server alone, so the load balancer cannot reach it. An empty output means nothing listens on that port.
To test the application from another machine in the same network, run this, where <server-ip> is the Server IP:
```
curl -I -H "Host: localhost" http://<server-ip>:<server-port>/
```
With Backend Protocol set to HTTPS, use https:// in place of http://, and add -k, since the server’s certificate does not name its IP. A status in the 200s or 300s means the application will pass the health check. A refused or timed-out connection means the Server IP or Server Port is wrong, the server’s security group or its own firewall blocks the port, or the application listens on the server alone, as in step 3.
Check that the server’s security group allows the Server Port from the load balancer: from its private IP, or from its VPC address once it is in a VPC. A firewall inside the server’s operating system must allow that port too. On a server that uses ufw, run:
```
sudo ufw status
```
The output lists each allowed port. Check that <server-port> is in the list. A status line that reads inactive means the firewall is off, so it blocks nothing.

On a server that uses firewalld, run this instead:
```
sudo firewall-cmd --list-all
```
Look for <server-port> under ports:, or for its service under services:, such as http for port 80 or https for 443. When neither lists it, the server’s own firewall blocks the check even when the security group allows it. If the command says the firewall is not running, it blocks nothing. See Allow traffic from the load balancer to your servers.
If Health Check is ticked, check that the application answers HEAD / with a status in the 200s or 300s. The check asks for the path / with the host name localhost, so a server that hosts several sites answers from its default site. An application served only under a sub-path, with nothing at /, fails the check.
Check that Backend Protocol matches the server: HTTPS for an application that serves HTTPS on that port, HTTP otherwise.

To find out whether the HTTP check itself is the problem, edit the group on Backend Mapping, untick Health Check, click Submit, and then click Save and Deploy. The load balancer then checks only that it can connect to the port. If the status turns to Running, fix what the application answers at /, and tick Health Check again. See Choose the health check.

If the status still reads Backend Connection Failure after those checks, send a request to the load balancer’s address. <load-balancer-ip> is its Public IP, or its VPC address when you test from a machine in the same VPC:

curl -I http://<load-balancer-ip>/

The first line shows the status the request received. If your application answers, traffic is flowing through the load balancer.

For a load balancer that serves HTTPS only or has HTTP Redirect on, or a Network Load Balancer, use the matching test in Allow traffic to the load balancer.

If these tests pass and the status still reads Backend Connection Failure, contact support with the load balancer’s name and its region. Include each server’s Server Port and Backend Protocol, and the output of these tests.

The load balancer shows Error

Error means the load balancer’s settings could not be applied. In Error, you can still change the settings, and saving applies them again.

On the Action Logs tab, find the change you made last.
Check that change, such as a backend group or an ACL rule, on its tab, and correct it. If your last change was a certificate, check that the private key belongs to it, as in Import the certificate.
Save the change, and wait until the load balancer reads Running.

If Error stays after you save again, contact support. Include the load balancer’s name, the change you made last, and its entry on the Action Logs tab.

A deleted load balancer is still listed or still billed

After Delete, the load balancer reads Deleting until it is gone. Then it leaves the list, and its hourly charges stop.

If Error in deleting Load Balancer, please try again shows, refresh the list and click Delete again.
A powered-off load balancer is billed until you delete it.
A public IP you reserved when you deleted the load balancer is billed until you release it on Reserved IP. See Reserved IP.
A committed load balancer is charged for its whole period when you commit. That charge stays in full when you delete it before the period ends. To choose whether it renews, moves to hourly billing, or is deleted when the period ends, see Use committed billing for a load balancer: Choose what happens when the period ends.
To see what the load balancer was charged, open its Billing Logs tab while it is still listed.

If a second Delete fails, Deleting lasts far longer than usual, or charges continue after the load balancer is gone, contact support. Include its name and when you deleted it. See Delete a load balancer.

My domain does not reach the load balancer

In the list, check that LB Type reads External. An internal load balancer has no public IP. A public domain needs an external one.
Check that your domain’s A record points at the load balancer’s Public IP, from the list or the Info tab. Look the record up, where <your-domain> is your domain name:
```
dig +short <your-domain>
```
Once the record is live, the last line of the answer is the load balancer’s Public IP.
Check that the load balancer’s security group allows the listening ports from your users: 80 and 443 on an Application Load Balancer, or each LB Listening Port on a Network Load Balancer. The load balancer accepts connections only on its listening ports, whatever the security group allows. See Allow traffic to the load balancer.
For HTTPS, check that the certificate covers the domain. An Application Load Balancer holds one certificate. For several names, use a wildcard or multi-domain certificate.

Contact support if the Public IP of an external load balancer reads Not Assigned, or if its IP answers on no allowed port from anywhere. Include the output of dig and of curl -v against the IP.

503 Service Unavailable: No server is available to handle this request

An Application Load Balancer answers 503 Service Unavailable with No server is available to handle this request. when no server in the backend group passes its checks. The 503 starts about six seconds after the last passing server begins to fail. It stops about four seconds after a server answers its check again. To see the answer for yourself, run this, where <load-balancer-ip> is the Public IP:

curl -I http://<load-balancer-ip>/

On a load balancer that serves HTTPS only or has HTTP Redirect on, run curl -I https://<your-domain>/ instead, where <your-domain> is a domain pointed at it.

The first line shows 503 Service Unavailable while no server passes. When it shows a status in the 200s or 300s instead, a server is passing and traffic is flowing again. Open Backend Mapping, and work through The load balancer shows Backend Connection Failure for the servers marked DOWN.

On a Network Load Balancer, a 503 on port 80 has its own fix; see A Network Load Balancer answers 503 on port 80.

If your server answers that the port needs TLS, the load balancer is sending plain HTTP to an HTTPS port. Set Backend Protocol to HTTPS, or change Server Port to the application’s plain HTTP port. Tomcat, for example, answers:

Bad Request
This combination of host and port requires TLS.

For a scale group as the backend, see 503 Service Unavailable on Auto Scaling. If every server shows as up and the load balancer still answers 503, contact support. Include the output of curl -I against the load balancer, the group’s Backend Type, and whether HTTP and HTTPS behave differently.

A Network Load Balancer answers 503 on port 80

About half of the connections to a Network Load Balancer’s port 80 get 503 Service Unavailable with No server is available to handle this request. Move the group to another port:

On Backend Mapping, edit the group, and change LB Listening Port to 443 or a port from 1024 to 65535, other than 8080, 10050, and 9101.
Click Submit, then Save and Deploy.
Allow the new port from your clients in the load balancer’s security group.
Point your clients at the new port.

Once the load balancer reads Running again, test the new port with nc -zv -w 5 <load-balancer-ip> <listening-port>, where <load-balancer-ip> is the Public IP and <listening-port> the new port. See Set up a backend group for each port.

Clients cannot connect to a Network Load Balancer port

On Backend Mapping, read the group’s LB Listening Port. Clients connect to that port on the load balancer, and Server Port is the port your service listens on in each server. The two can differ.
Connect to the listening port, where <load-balancer-ip> is the Public IP and <listening-port> the group’s port. A browser or curl given no port connects to port 80.
```
nc -zv -w 5 <load-balancer-ip> <listening-port>
```
A line that says succeeded, open, or Connected means the port answers. A refused or timed-out connection points to the security group in the next step.
Check that the load balancer’s security group allows each LB Listening Port from your clients. Each server’s security group must allow the Server Port from the load balancer.
When no server in the group passes its check, the Network Load Balancer closes each connection without sending any data. Open Backend Mapping, and work through The load balancer shows Backend Connection Failure for the servers that show DOWN.
To offer several ports, add a backend group for each, with Add Backend Group. Each group needs its own listening port and at least one server.

If every port is allowed and the server answers on its Server Port from inside the network, but the listening port still refuses connections, contact support. Include the nc -zv output.

The port number is restricted

LB Listening Port takes 443, or a port from 1024 to 65535, other than 8080, 10050, and 9101. Port 80 is also accepted, but keep Network Load Balancer groups off it: about half of the connections to a group there get 503 Service Unavailable. Your servers can keep listening on the port they use now, since Server Port is separate. See Set up a backend group for each port.

An ACL rule will not save

Check the rule’s Name: up to 32 characters, using letters, digits, underscores, and hyphens, with no dot or space. Each rule needs its own name, and a second rule with the same name is refused with Same acl name is not allowed.
Check the load balancer’s status. To change ACL rules, the load balancer must be powered on and must have left Creating, Deploying, or Deleting.
Click Save and Deploy, and confirm. The change takes about five to 10 minutes.

If the status turns to Error after you add a rule, see The load balancer shows Error. If a valid rule still fails, contact support with the rule’s name, type, and value. See Add a rule.

All traffic goes to one group or one server

On an Application Load Balancer, requests go to the first backend group unless an ACL rule sends them to another. The rules are checked from the top down. To see where a request goes, send it with the host and path your rule matches, where <host> and <path> are the rule’s values. A path starts with /:

curl -I -H "Host: <host>" http://<load-balancer-ip><path>

On a load balancer that serves HTTPS only or has HTTP Redirect on, send the request over HTTPS:

curl -I --resolve <host>:443:<load-balancer-ip> https://<host><path>

Run it for each host or path, and compare the answers with what each group’s servers return. Two ways to fix it:

To spread traffic across all your servers, put them in one backend group. See Add or change servers.
To send some requests to another group, add an ACL rule that matches them, above any broader rule. See Route requests with ACL rules.

Within one group, Source IP Hash keeps each client on one server. Clients behind one shared address, such as an office network, all reach the same server. To share clients across the servers, choose Round Robin or Least Connection.

When a server goes down, its clients move to the other servers under every policy. Under Source IP Hash, a change in the number of healthy servers can move many clients at once. A session kept only on the old server is then lost. See Choose a routing policy.

HTTP is not redirected to HTTPS

On the Info tab, check that Frontend Protocol reads Both (HTTP and HTTPS).
Check that HTTP Redirect under Peak Performance Features reads True.
To change either, click Edit beside Frontend Protocol, choose Both (HTTP and HTTPS), tick HTTP Redirect, and click Submit. Wait until the load balancer reads Running again.
Check that the load balancer’s security group allows port 80 from your users.
Request your domain over plain HTTP, where <your-domain> is your domain name:
```
curl -sI http://<your-domain>/ | grep -i -E '^HTTP|^location'
```
A redirect shows a status in the 300s and a location line that starts with https://. A status in the 200s means the page was served over HTTP without a redirect.

The redirect covers every path on port 80; no path can be left out.

See Add an SSL certificate: Redirect HTTP to HTTPS.

If HTTP Redirect reads True and your domain is still not redirected, contact support. Include the output of the command in step 5.

My certificate is missing from the SSL list

Check Frontend Protocol. SSL appears when it is HTTPS or Both (HTTP and HTTPS).
Import the certificate in SSL Certificates, in the same project as the load balancer, with its private key and the certificate chain. All three are required. A certificate you bought from E2E appears once you import it with its private key.
Back on the load balancer’s form, reload the SSL list.

If an imported certificate in the same project is still missing, contact support with a screenshot of SSL Certificates. See Import the certificate.

The old certificate is still served after a renewal

A renewed certificate takes effect once you choose it on the load balancer.

Import the renewed certificate in SSL Certificates, with its private key and chain.
On the Info tab, click Edit beside SSL, choose the renewed certificate, and click Submit.
Wait for the load balancer to read Running again.
Check which certificate is served, where <your-domain> is your domain name:
```
echo | openssl s_client -connect <your-domain>:443 -servername <your-domain> 2>/dev/null | openssl x509 -noout -subject -dates
```
The last line of the output shows the served certificate’s end date. It matches the renewed certificate once the load balancer serves it.

If the load balancer reads Running and the old certificate is still served, contact support with that command’s output. See Renew or replace the certificate.

Access logs do not arrive in the bucket

On the Info tab, check that Access Details reads Enabled. If it reads Disabled, click Activate, which is available while the load balancer reads Running or Backend Connection Failure.
Check the bucket name and keys you gave in Enable Access Logs: the EOS Bucket, the Access Key, and the Secret Key. The access key needs access to that bucket; see Attach the access key to a bucket.
If the bucket or its keys changed, click Deactivate, then Activate again with the current details.

When you turn access logs on, the load balancer copies its current request log to the bucket at once, unless that log is empty. Later, it copies the log on a regular schedule, and only once the log has reached 10 KB, so requests arrive in batches rather than as they happen. A load balancer with little traffic therefore copies less often. Each copy is a gzip file at the top level of the bucket.

The request logs go only to your bucket. The Action Logs tab lists actions taken on the load balancer rather than requests. If Enable fails with a message, or the bucket stays empty while Access Details reads Enabled and the load balancer serves traffic, contact support. Include the message, the bucket’s region, and when you turned access logs on. See Save access logs to a bucket.

The load balancer does not answer ping

The load balancer does not reply to a ping, whatever its security group allows. A ping with no reply says nothing about the load balancer’s health. Test a listening port instead, where <load-balancer-ip> is the Public IP. On an Application Load Balancer, run:

curl -I http://<load-balancer-ip>/

On one that serves HTTPS only, run curl -I https://<your-domain>/, where <your-domain> is a domain pointed at it. On a Network Load Balancer, run this, where <listening-port> is the group’s port:

nc -zv -w 5 <load-balancer-ip> <listening-port>

A status line from curl, or succeeded, open, or Connected from nc, means the load balancer answers. If the port does not answer either, see My domain does not reach the load balancer.

Unable to fire Load Balancer vm instance

Creation fails with Unable to fire Load Balancer vm instance. Contact support with the load balancer’s name, the time, and the plan you chose, and wait for their answer before you launch again.

Each TCP backend must have a unique listener port

Each backend group on a Network Load Balancer listens on its own port. Give the group a port that no other group uses. Groups also need different names, and server names within a group must differ. A repeated group name is refused with Same backend name is not allowed, and a repeated server name with Server names within a TCP backend group must be unique.

Same backend name is not allowed

Each backend group on a load balancer needs its own name. The name none is refused with ‘none’ cannot be a Backend Name. Rename the group, using letters, digits, underscores, and hyphens. See Add a backend group.

You can’t edit Load Balancer in ‘Powered off’ state

An edit is refused with a message that names the load balancer’s status. To change backend groups or ACL rules, the load balancer must be powered on. To edit the Info tab, it must be powered on and must have left Creating, Deploying, or Upgrading.

Start the load balancer, or wait for the current change to finish, and try again. See Start the load balancer.

Do not delete the last backend group individually

A load balancer must have at least one backend group. Deleting the last one is refused with this message:

Do not delete the last backend group individually. Please delete the entire load balancer to ensure proper functionality.

To replace the last group, add the new group first, then delete the old one. To remove every group, delete the load balancer. See Remove a backend group.

The plan cannot be upgraded

To upgrade the plan, the load balancer must be Powered off and on hourly billing. The plan list offers only larger plans. MyAccount shows:

Your need to power off your LB to upgrade plan. while the load balancer is running. Power it off first.
Cannot Upgrade Committed Plans on a committed load balancer. Its plan stays for the committed period.

See Upgrade the plan.

vpc_list must have elements when lb_type is ‘internal’

An internal load balancer must have at least one VPC. Detaching its last one is refused with this message. To move it to another VPC, attach the new VPC first, then detach the old one. See Detach a VPC.

A port I opened in the security group stays closed

The load balancer accepts connections only on ports 80 and 443, and on each LB Listening Port of a Network Load Balancer. A security group rule for any other port leaves it closed. To check a port, where <port> is the port you opened:

nc -zv -w 5 <load-balancer-ip> <port>

A refused or timed-out connection on a port that is not a listening port is expected. To serve another TCP port, add it as an LB Listening Port on a Network Load Balancer. See Create a Network Load Balancer.

SSL is currently enabled on the Load Balancer. It cannot be deleted.

You can delete a certificate from SSL Certificates once no load balancer uses it. Choose another certificate on the load balancer first, then delete the old one. See Renew or replace the certificate.

Every plan shows Request in place of Select

In Delhi, every plan shows Request for an account created on or after May 15, 2026, unless E2E has exempted that account. Click Request on the plan you want; We have accepted your request, will contact you shortly. confirms it.

Waiting does not change it; click Request, and E2E contacts you. See Create an Application Load Balancer: Choose the plan.

You have exhausted your available resource quota

On an account with a resource quota, load balancers count against it, and creation is refused at the limit. The message says how many resources you can launch. Click Request on the create page, or write to E2E sales, to ask for more.

Your balance cannot cover the plan

When your balance cannot cover the plan, nothing is created. Add infra credits, or choose a smaller plan, and launch again.

Contact support

Give support the load balancer’s name, its region, the exact error text, the status it shows, and the time it happened.