I am having problems configuring my Load Balancer

Reviewed on September 22, 2025

If your problem concerns any of the following, see our specific documentation pages:

Troubleshooting certificate configuration
Setting up SSL bridging, offloading or passthrough
Troubleshooting connection and HTTP errors
General advice and help for configuring frontends, backends and health checks
Creating and configuring a Kubernetes Load Balancer

When adding a backend server to my Load Balancer, I get the message: IP is not owned by Scaleway

You may be trying to add a backend server to your Load Balancer's backend, and experience the following error:

HTTP 404: IP not owned by Scaleway

Cause

You are trying to add the IP address of a backend server that is not owned by Scaleway (i.e. is not a Scaleway resource such as an Instance, Elastic Metal server or Managed Database).

Solution

Only certain Load Balancer types (L and XL) allow you to add non-Scaleway resources as backend servers. This is indicated as "Multi-cloud provider" compatibility in the Load Balancer creation form.

Either:

Resize your Load Balancer to a type that is compatible with multi-cloud backend servers, or
Use only Scaleway resources as backend servers for your Load Balancer

My Load Balancer shows backends attached over a Private Network as `DOWN` even though they are healthy

You may encounter a situation where your Scaleway Load Balancer continuously reports backend servers as DOWN in health checks, with error messages such as Connection refused.

This issue can occur due to a transient network or configuration state within the Load Balancer's attachment to the Private Network, particularly when using static Private Network configurations. Even if your backend services are correctly listening on the expected port and returning 200 status codes, the Load Balancer may lose its ability to initiate Layer 4 connections to the backend. This is often caused by an internal inconsistency in the Load Balancer’s networking state, which prevents it from reaching any backends despite correct IP and port settings.

Solutions

In some cases, support investigations have confirmed that the Load Balancer itself is at fault rather than the backend. Restarting or reprovisioning the backend does not resolve the issue, but detaching and reattaching the Load Balancer to the Private Network often restores connectivity immediately:

Detach and reattach the Load Balancer from the Private Network. This forces a networking state refresh and often resolves the connectivity issue.
Verify backend configuration: Ensure your service (e.g., Nginx) is bound to the correct interface and port, and not blocking traffic based on headers or source IPs. While the issue may not be on the backend, it's good practice to confirm this.

My Load Balancer's Elastic Metal backend servers added via private IPs are all down

You may add Elastic Metal backend servers to your Load Balancer using their private IP address, and find they are marked as DOWN as soon as you add them. You are unable to work out why they are failing their health checks.

Cause

The Load Balancer is unable to successfully communicate with the Elastic Metal backend servers over the Private Network, resulting in failed health checks.

Solution

Check that your health checks and backend servers are correctly configured to work together.
Check that you have entered the correct private IP address for your Elastic Metal server, and that it is attached to a Private Network within the same VPC as the Load Balancer.
Elastic Metal servers require additional manual configuration of their network interface, unlike Instances and other resource types. Ensure you have followed the necessary configuration steps.

My Load Balancer's IP address is appearing in the backend application's logs, instead of the real client IP address.

You may find that as requests are passed from the client, through the Load Balancer, to your backend servers, that the client's original IP address is replaced with the Load Balancer's IP address in your backend application's logs. This is problematic if you need the original IP address for localization, security or other purposes.

Cause

Proxy Protocol has not been activated on your Load Balancer, meaning that information about the original client's connection is not being passed through to the backend servers.

Solution

Activate Proxy Protocol on your Load Balancer, and ensure that your backend server is correctly configured to handle this protocol.

Security rules are not being applied as expected, and I am having difficulties in filtering incoming traffic through my Load Balancer

You may find that traffic is not being filtered as expected via your Load Balancer, and that Instances in your backend are not dropping unauthorized traffic as expected.

Cause

Instance security groups and/or Load Balancer ACLs are incorrectly configured.

Solution

Instance security groups should still filter public traffic arriving on your backend server Instances, as long as that traffic is arriving over the public interface. This means the Instance in question must be attached to the Load Balancer via its public IP and not any private IP.

Ensure that your Instance is attached via its public IP address. If your Instance behind a Load Balancer is attached via a private IP address, the security group rules will not be applied.
Double check your security group rules, to verify that they correspond to the required ports, protocols, and IP addresses configured for your Load Balancer
To filter incoming traffic to your backend servers as it passes through the Load Balancer, use Load Balancer ACLs.

Create a support ticket