# Backend Servers Backend servers are the VMs that actually serve the traffic behind a listener. The load balancer picks one of them for each new flow, forwards the packet through, and keeps the flow tracked so return traffic finds its way back. Every backend belongs to exactly one listener's pool. If the same VM should serve multiple listeners (for instance, an HTTPS listener on 443 and an HTTP-redirect listener on 80), register it in each pool separately — each registration has its own weight and health state. ## What a Backend Defines | Field | Description | | ----------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- | | **VM ID** | The VM the backend refers to. | | **Private IP** | Private IP inside the attached global VPC that traffic is forwarded to. | | **Port** | The port on the backend the listener forwards to. `0` means "same as the listener port" — typical when the backend listens on the same port as the VIP. | | **Weight** | Relative share of traffic compared to other backends in the same pool. Used by weighted scheduling algorithms. | | **Health status** | `healthy` or `unhealthy`. Unhealthy backends are excluded from scheduling. Updated by the health checker. | ## Backend Pool Rules * All backends must reside in the **same global VPC and the same region** as the load balancer instance. Cross-region backends are not supported today. * Backends can span multiple subnets within the load balancer's region. * The same VM can appear in multiple listeners' pools; each appearance is independent. ## Weights Each backend has a weight — an integer that expresses its share of traffic relative to other backends in the pool. Weights matter for the weighted algorithms (`wIc`) and are ignored by the unweighted ones (`wrr`, `lc`, `mh`). | Weight ratio | Effect with `wIc` | | ------------ | ---------------------------------------------------------- | | 1 : 1 : 1 | Even distribution across three backends | | 3 : 2 : 1 | First gets \~3× the second's load; second \~2× the third's | | 1 : 1 : 0 | Third backend drained — schedulers skip it for new flows | **Setting weight to 0 to drain.** Setting a backend's weight to 0 stops new connections from being scheduled to it while existing connections finish. Once the backend has no active flows, you can safely remove it or take the VM offline. This is the standard pattern for rolling maintenance — drain, replace, re-add. ## Port Configuration * **Listener port = backend port.** The most common pattern. Set the backend port to `0` (meaning "same as listener port") and each connection reaches the same port on the chosen backend. * **Listener port ≠ backend port.** Useful when backends run the service on a non-standard port internally. For example, a listener on `tcp/443` can forward to backends listening on `tcp/8443`. ## Client IP Visibility The load balancer is passthrough. Backends see the **real client IP as the source address** on both TCP and UDP listeners — no configuration, kernel module, or application-layer header is needed. Standard socket APIs (`getpeername`, access logs, `REMOTE_ADDR`, etc.) return the original client address. This makes source-based access control, geo-aware logging, and rate-limiting-by-client-IP work natively on the backend, as if clients were connecting directly. ## Health and Traffic Eligibility A backend's current health determines whether schedulers consider it for new flows: * **Healthy** — included in scheduling. New flows can land on it. * **Unhealthy** — excluded from scheduling. Existing connections continue until they close or are reaped, but no new flows are sent. See [Health Check](/welcome/elastic-compute/load-balancing/05-health-check.md) for probe types, thresholds, and the all-failed fallback behavior. ## Adding and Removing Backends * **Adding a backend** — the new backend enters the pool but, if health checks are on, it only starts receiving traffic after its first successful probe. This avoids a brief window where a backend is registered but not yet ready. * **Removing a backend** — new flows stop being scheduled to it immediately. Existing connections continue until they close naturally or the idle timeout reaps them. To avoid mid-flow drops on long-lived connections, drain by setting weight to 0 first, then remove once active counts reach zero. * **Changing weight** — takes effect on the next scheduling decision. Flows already in progress keep running on their current backend. * **Changing port** — breaks existing connections to that backend (they're talking to the old port). Use a drain-then-change pattern for production changes. ## Limits and Considerations * **Same VPC, same region.** Backends must be in the load balancer's VPC and region. Cross-region is not supported today. * **No session termination at the load balancer.** Because forwarding is passthrough, the load balancer does not act as an HTTP proxy — it won't retry failed requests, close half-open connections cleanly, or inject application headers. All of that is the backend's responsibility. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.console.zenlayer.com/welcome/elastic-compute/load-balancing/04-backend.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.