Layer 4 load balancing is the distribution of network connections across a pool of servers based on transport-layer information: source and destination IP addresses, TCP or UDP ports and the protocol. In networking, it operates at the transport layer of the OSI model, so the load balancer forwards whole connections or flows without reading the HTTP requests, database queries or other application data they carry.
A device or service that performs this function is commonly called a network load balancer (NLB). Because it makes simple decisions per connection instead of parsing every request, Layer 4 load balancing offers very high throughput, low added latency and protocol independence, at the price of less intelligent routing than Layer 7 load balancing.
How a Layer 4 load balancer forwards traffic
Clients connect to a virtual IP address (VIP) and port that the load balancer advertises. When the first packet of a new flow arrives, the balancer selects a backend server with its load balancing algorithm and records the decision in a connection table keyed by the flow’s five-tuple: source IP, source port, destination IP, destination port and protocol. Every later packet of that flow goes to the same backend.
Implementations differ in how they deliver packets to the chosen server and how return traffic flows. The forwarding mode has a large effect on performance, on whether servers see the real client address and on network design.
| Mode | How it works | Return path | Main consideration |
|---|---|---|---|
| NAT (full proxy of addresses) | Rewrites destination, often source too | Through the balancer | Simple routing, balancer carries all traffic |
| Direct server return | Rewrites only the MAC address or tunnels the packet | Directly from server to client | Very high throughput, servers need VIP configuration |
| IP tunneling | Encapsulates packets, for example in IP-in-IP or GUE | Directly from server | Works across routed networks |
| TCP proxy | Terminates client TCP, opens new connection to backend | Through the balancer | Two separate TCP sessions |
Strictly, a TCP proxy that terminates connections blurs the line toward higher layers, but it is still considered Layer 4 when it routes by addresses and ports only. Packet-forwarding designs such as Linux IPVS or kernel bypass systems based on XDP can handle millions of packets per second on commodity servers.
Algorithms and session persistence
A Layer 4 balancer chooses servers using only information available at connection setup. The most common algorithms are listed below; they reappear at Layer 7, but at Layer 4 they operate per connection rather than per request.
| Algorithm | Selection rule | Best fit |
|---|---|---|
| Round robin | Next server in rotation | Identical servers, similar connection lengths |
| Weighted round robin | Rotation proportional to capacity | Servers of different size |
| Least connections | Server with fewest active connections | Long or uneven connections |
| IP hash or five-tuple hash | Hash of addresses and ports | Stateless forwarding, natural affinity |
| Consistent hashing (for example Maglev) | Hash ring with minimal remapping | Large fleets that change often |
Session persistence at Layer 4 is address-based. A balancer can keep a client on one server by hashing its source IP, but it cannot read cookies. This affinity breaks when many users share one address behind carrier-grade NAT, which then concentrates them on a single backend, or when a mobile client changes networks and receives a new address.
Layer 4 compared with Layer 7 load balancing
The choice between Layer 4 and Layer 7 is a trade between speed and generality on one side and application awareness on the other. Many architectures use both: a Layer 4 tier spreads traffic across a fleet of Layer 7 proxies, which then route individual requests.
| Aspect | Layer 4 | Layer 7 |
|---|---|---|
| Decision basis | IP addresses, ports, protocol | URLs, headers, cookies, methods |
| Protocols | Any TCP or UDP traffic | Mainly HTTP, HTTP/2, gRPC |
| TLS handling | Usually passes encrypted traffic through | Commonly performs TLS termination |
| Per-request routing | Not possible | Path and host based routing |
| Added latency and cost | Very low | Higher, due to parsing and proxying |
| Visibility | Connection counts and bytes | Status codes, request timing, content |
Since Layer 4 balancers do not decrypt traffic, end-to-end encryption stays intact and certificates live only on the servers, which suits compliance requirements and non-HTTP protocols alike.
Health checks and connection handling
A balancer must remove failed servers quickly. Layer 4 health checks typically test whether a TCP handshake completes or whether a UDP service answers, at intervals of a few seconds, and mark a server down after two to five consecutive failures. Such checks confirm that a port is open but cannot detect application errors, so many deployments add HTTP checks even when traffic is balanced at Layer 4.
Because state is kept per connection, operational events must respect existing flows. Connection draining stops new connections to a server while allowing established ones to finish within a timeout, often 30 to 300 seconds. Idle timeouts remove inactive flows from the connection table; a timeout shorter than the application’s keepalive interval silently breaks long-lived connections.
Typical uses and common mistakes
Layer 4 load balancing is the natural choice for protocols other than HTTP and for traffic where raw throughput matters most. The table below matches typical situations with recommendations.
| Situation | Recommendation | Reason |
|---|---|---|
| Database or message broker clusters | Layer 4 | Non-HTTP protocols, long connections |
| Game servers and VoIP over UDP | Layer 4 with flow hashing | Low latency, UDP support |
| Front tier for many HTTP proxies | Layer 4 | Scales the Layer 7 tier horizontally |
| Path-based routing to microservices | Layer 7 | Needs request inspection |
| Strict end-to-end TLS | Layer 4 passthrough | No decryption on the balancer |
- Losing the client IP address in NAT mode breaks logging and access control unless the PROXY protocol or direct server return preserves it.
- Uneven load from long connections appears when round robin is used for connections that last hours.
- Asymmetric routing in direct server return fails if firewalls expect to see both directions of traffic.
Stripped to the essentials
Imagine a busy post office with several counters and a person at the entrance who sends each arriving customer to a free counter. That person looks only at who is arriving and which door they used, not at what is inside their envelopes.
Layer 4 load balancing works the same way for network traffic. It is fast and works for almost any kind of connection, but it cannot make decisions based on what a customer actually wants, which is the job of more detailed Layer 7 balancing.
Where it is applied
An online game studio runs 40 match servers that communicate with players over UDP. A single public address must accept traffic from tens of thousands of players, and every added millisecond of delay is noticeable during play.
The studio places a Layer 4 network load balancer in front of the servers, using five-tuple hashing so that all packets from one player session reach the same match server. A UDP health check removes a crashed server within about ten seconds. Because the balancer never parses game packets, it adds negligible latency, and the studio scales capacity simply by adding servers to the pool during evening peaks.