--- title: "Troubleshooting Load Balancer" description: "Fix E2E load balancers that show Backend Connection Failure, Error, or 503, are stuck on Creating, Deploying, or Upgrading, or refuse a change." content_type: "troubleshooting" product: "load-balancer" platform: "MyAccount" url: "/myaccount/load-balancer/troubleshooting/load-balancer/" relationships: {"troubleshooting-for":["/myaccount/load-balancer/how-to/create-an-application-load-balancer/","/myaccount/load-balancer/how-to/create-a-network-load-balancer/","/myaccount/load-balancer/how-to/manage-backend-groups/","/myaccount/load-balancer/how-to/route-requests-with-acl-rules/","/myaccount/load-balancer/how-to/add-an-ssl-certificate/","/myaccount/load-balancer/how-to/view-and-edit-details/","/myaccount/load-balancer/how-to/manage-network-and-security-groups/","/myaccount/load-balancer/how-to/monitor-a-load-balancer/","/myaccount/load-balancer/how-to/save-access-logs-to-a-bucket/","/myaccount/load-balancer/how-to/power-off-start-or-upgrade/","/myaccount/load-balancer/how-to/use-committed-billing/","/myaccount/load-balancer/how-to/delete-a-load-balancer/"]} --- # Troubleshooting Load Balancer 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](/myaccount/load-balancer/how-to/monitor-a-load-balancer/). For questions about plans, regions, and billing, see [Load Balancer FAQ](/myaccount/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](#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: 1. Open the **Backend Mapping** tab, and find the server the load balancer reports **DOWN**. 2. 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](/myaccount/load-balancer/how-to/manage-network-and-security-groups/#attach-a-vpc). 3. On the server, run this, where `` is the **Server Port**: ```bash ss -ltn | grep ': ' ``` 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. 4. To test the application from another machine in the same network, run this, where `` is the **Server IP**: ```bash curl -I -H "Host: localhost" http://:/ ``` 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. 5. 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: ```bash sudo ufw status ``` The output lists each allowed port. Check that `` 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: ```bash sudo firewall-cmd --list-all ``` Look for `` 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](/myaccount/load-balancer/how-to/manage-network-and-security-groups/#allow-traffic-from-the-load-balancer-to-your-servers). 6. 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. 7. 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](/myaccount/load-balancer/how-to/manage-backend-groups/#choose-the-health-check). If the status still reads **Backend Connection Failure** after those checks, send a request to the load balancer's address. `` is its **Public IP**, or its VPC address when you test from a machine in the same VPC: ```bash curl -I http:/// ``` 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](/myaccount/load-balancer/how-to/manage-network-and-security-groups/#allow-traffic-to-the-load-balancer). If these tests pass and the status still reads **Backend Connection Failure**, [contact support](#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. 1. On the **Action Logs** tab, find the change you made last. 2. 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](/myaccount/load-balancer/how-to/add-an-ssl-certificate/#import-the-certificate). 3. Save the change, and wait until the load balancer reads **Running**. If **Error** stays after you save again, [contact support](#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](/myaccount/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](/myaccount/load-balancer/how-to/use-committed-billing/#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](#contact-support). Include its name and when you deleted it. See [Delete a load balancer](/myaccount/load-balancer/how-to/delete-a-load-balancer/). ## My domain does not reach the load balancer 1. In the list, check that **LB Type** reads **External**. An internal load balancer has no public IP. A public domain needs an external one. 2. 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 `` is your domain name: ```bash dig +short ``` Once the record is live, the last line of the answer is the load balancer's **Public IP**. 3. 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](/myaccount/load-balancer/how-to/manage-network-and-security-groups/#allow-traffic-to-the-load-balancer). 4. 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](#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 `` is the **Public IP**: ```bash curl -I http:/// ``` On a load balancer that serves **HTTPS** only or has **HTTP Redirect** on, run `curl -I https:///` instead, where `` 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](#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](#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: ```text Bad Request This combination of host and port requires TLS. ``` For a scale group as the backend, see [503 Service Unavailable on Auto Scaling](/myaccount/auto-scaling/troubleshooting/auto-scaling/#503-service-unavailable-no-server-is-available-to-handle-this-request). If every server shows as up and the load balancer still answers 503, [contact support](#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: 1. 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. 2. Click **Submit**, then **Save and Deploy**. 3. Allow the new port from your clients in the load balancer's security group. 4. Point your clients at the new port. Once the load balancer reads **Running** again, test the new port with `nc -zv -w 5 `, where `` is the **Public IP** and `` the new port. See [Set up a backend group for each port](/myaccount/load-balancer/how-to/create-a-network-load-balancer/#set-up-a-backend-group-for-each-port). ## Clients cannot connect to a Network Load Balancer port 1. 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. 2. Connect to the listening port, where `` is the **Public IP** and `` the group's port. A browser or `curl` given no port connects to port 80. ```bash nc -zv -w 5 ``` 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. 3. 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. 4. 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](#the-load-balancer-shows-backend-connection-failure) for the servers that show **DOWN**. 5. 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](#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](/myaccount/load-balancer/how-to/create-a-network-load-balancer/#set-up-a-backend-group-for-each-port). ## An ACL rule will not save 1. 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**. 2. 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**. 3. 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](#the-load-balancer-shows-error). If a valid rule still fails, [contact support](#contact-support) with the rule's name, type, and value. See [Add a rule](/myaccount/load-balancer/how-to/route-requests-with-acl-rules/#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 `` and `` are the rule's values. A path starts with `/`: ```bash curl -I -H "Host: " http:// ``` On a load balancer that serves **HTTPS** only or has **HTTP Redirect** on, send the request over HTTPS: ```bash curl -I --resolve :443: https:// ``` 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](/myaccount/load-balancer/how-to/manage-backend-groups/#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](/myaccount/load-balancer/how-to/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](/myaccount/load-balancer/how-to/manage-backend-groups/#choose-a-routing-policy). ## HTTP is not redirected to HTTPS 1. On the **Info** tab, check that **Frontend Protocol** reads **Both (HTTP and HTTPS)**. 2. Check that **HTTP Redirect** under **Peak Performance Features** reads **True**. 3. 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. 4. Check that the load balancer's security group allows port 80 from your users. 5. Request your domain over plain HTTP, where `` is your domain name: ```bash curl -sI http:/// | 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](/myaccount/load-balancer/how-to/add-an-ssl-certificate/#redirect-http-to-https). If **HTTP Redirect** reads **True** and your domain is still not redirected, [contact support](#contact-support). Include the output of the command in step 5. ## My certificate is missing from the SSL list 1. Check **Frontend Protocol**. **SSL** appears when it is **HTTPS** or **Both (HTTP and HTTPS)**. 2. 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. 3. Back on the load balancer's form, reload the **SSL** list. If an imported certificate in the same project is still missing, [contact support](#contact-support) with a screenshot of **SSL Certificates**. See [Import the certificate](/myaccount/load-balancer/how-to/add-an-ssl-certificate/#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. 1. Import the renewed certificate in **SSL Certificates**, with its private key and chain. 2. On the **Info** tab, click **Edit** beside **SSL**, choose the renewed certificate, and click **Submit**. 3. Wait for the load balancer to read **Running** again. 4. Check which certificate is served, where `` is your domain name: ```bash echo | openssl s_client -connect :443 -servername 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](#contact-support) with that command's output. See [Renew or replace the certificate](/myaccount/load-balancer/how-to/add-an-ssl-certificate/#renew-or-replace-the-certificate). ## Access logs do not arrive in the bucket 1. 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**. 2. 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](/myaccount/object-storage/how-to/generate-an-access-key/#attach-the-access-key-to-a-bucket). 3. 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](#contact-support). Include the message, the bucket's region, and when you turned access logs on. See [Save access logs to a bucket](/myaccount/load-balancer/how-to/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 `` is the **Public IP**. On an Application Load Balancer, run: ```bash curl -I http:/// ``` On one that serves **HTTPS** only, run `curl -I https:///`, where `` is a domain pointed at it. On a Network Load Balancer, run this, where `` is the group's port: ```bash nc -zv -w 5 ``` 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](#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](#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](/myaccount/load-balancer/how-to/manage-backend-groups/#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](/myaccount/load-balancer/how-to/power-off-start-or-upgrade/#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: ```text 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](/myaccount/load-balancer/how-to/manage-backend-groups/#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](/myaccount/load-balancer/how-to/power-off-start-or-upgrade/#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](/myaccount/load-balancer/how-to/manage-network-and-security-groups/#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 `` is the port you opened: ```bash nc -zv -w 5 ``` 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](/myaccount/load-balancer/how-to/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](/myaccount/load-balancer/how-to/add-an-ssl-certificate/#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](/myaccount/load-balancer/how-to/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.