Layer 4 vs Layer 7 Load Balancer: A Practical Guide

If your site or app is growing, one server eventually runs out of room. A load balancer spreads traffic across several servers so users stay happy and nothing falls over, and it’s also how you keep services highly available when a single server fails. There are two flavors to know: the network load balancer (Layer 4) and the application load balancer (Layer 7). An L4 load balancer cares about IP and port. An L7 load balancer cares about what is inside the request. The two are not always distinct products. Some load balancers, including the upcoming Contabo Load Balancer, can handle both L4 and L7 in the same service. Let’s have a look into the differences so you can pick the right mode for your workload.

OSI Model Quick Refresher: What Layer 4 and Layer 7 Mean

The OSI model splits networking into seven layers. Two matter here. Layer 4 is the transport layer, where TCP and UDP live. A packet at this layer has a source IP, destination IP, source port, destination port, and a payload the load balancer never opens. Layer 7 is the application layer, where HTTP, HTTPS, gRPC, and WebSocket live. The proxy reads the request, including URL path, host header, cookies, and method. The OSI layer you pick determines how much the proxy is allowed to see, and that single difference drives every other tradeoff below.

What Is a Layer 4 Load Balancer?

A Layer 4 load balancer, also called a network load balancer or TCP load balancer, distributes traffic based on the IP address and port of each connection. It does not inspect the payload. When a client opens a TCP connection, the L4 proxy picks a backend using a balancing algorithm such as round-robin or least-connections, then forwards packets between the endpoints. Sticky sessions, where the same client always lands on the same backend, are a separate concern and are commonly implemented by hashing the source IP, though other methods exist. A UDP load balancer works the same way for connectionless traffic like DNS, QUIC, or game protocols. Because the L4 load balancer never parses payload, it handles very high packet rates with low CPU and predictable latency. It’s a high-speed traffic director that knows where to send a connection, not what is being said over it.

Layer 4 Load Balancer: Pros and Cons

Pros of an L4 load balancer:

• Very high throughput and low latency, because no payload parsing happens.
• Works for any service running over the protocols the load balancer supports, typically TCP and UDP. Not limited to HTTP.
• Simpler configuration and fewer moving parts.

Cons of an L4 load balancer:

• No content-aware routing. It cannot send /api to one pool and /static to another.
• No TLS termination at the proxy in most setups. Certificates live on backends.
• No application-level health checks. The proxy can tell if a TCP port is open, but not if the app behind it is actually healthy.
• Limited observability. You see connections, not requests.

What Is a Layer 7 Load Balancer?

A Layer 7 load balancer, also called an application load balancer or HTTP load balancer, makes routing decisions using the contents of HTTP requests. It terminates the client connection, inspects the request line and headers, applies rules, and opens a new connection to the chosen backend. That single capability enables path-based routing, host-based routing, header and cookie rules, request rewriting, response compression, and TLS termination at a central point. It’s good for routing logic that depends on what the user is asking for, not only where the packets are going.

Layer 7 Load Balancer: Pros and Cons

Pros of an L7 load balancer:

• Path-based and host-based routing for microservices and multi-tenant apps.
• TLS termination at the proxy, with central certificate management.
• Native support for HTTP/2, HTTP/3, WebSocket, and gRPC.
• Sticky sessions through cookies, so the same user lands on the same backend without depending on source IP.
• WAF integration for filtering malicious requests before they reach your app.
• Detailed per-request observability and access logs.

Cons of an L7 load balancer:

• Higher CPU cost per request, because payload is parsed.
• More configuration surface and more ways to misconfigure.
• Application-aware features only help for protocols the proxy understands.

Layer 4 vs Layer 7 Load Balancer: Side-by-Side Comparison

Here is the L4 vs L7 load balancer comparison in one view. The same dimensions show up in nearly every L7 vs L4 load balancer conversation, so this layer 4 vs layer 7 load balancing table anchors the rest of the article.

In the application load balancer vs network load balancer naming used by major cloud providers, ALB is L7 and NLB is L4. The network load balancer vs application load balancer distinction comes down to the same payload-inspection axis.

Performance: How Much Faster Is Layer 4?

L4 is generally faster than L7, and the reason is mechanical. An L4 proxy moves packets without parsing them, so per-connection CPU is low and packet throughput scales close to network line rate. L4 datapaths built on eBPF, like Cilium and Katran, push this further by forwarding in the Linux kernel rather than user space. The gap is smaller than the marketing suggests, though. A high performance load balancer at Layer 7, like NGINX or Envoy, handles tens of thousands of HTTPS requests per second on modest hardware. For most web workloads the bottleneck moves to the backend first. Use L4 when raw connections per second matter. Use L7 when request features matter.

When to Use a Layer 4 Load Balancer

When to use a load balancer at Layer 4 comes down to four signals. Reach for an L4 proxy if any of these apply:

• The traffic is not HTTP. A TCP load balancer is the only option for databases, SMTP, IMAP, and most game backends. A UDP load balancer is required for DNS, QUIC, and real-time media.
• You need maximum throughput per CPU core, and the workload is connection-heavy rather than request-heavy.
• You want TLS termination on the backends, often for compliance or per-tenant certificates.
• You want minimal proxy surface area, because every feature is also a potential misconfiguration.

A common L4 deployment is a public network load balancer in front of an inner L7 tier.

When to Use a Layer 7 Load Balancer

The signals for L7 are about what you want to do with the request, not how many packets you can push. Reach for an HTTP load balancer if any of these apply:

• You serve a web app or API and need path-based or host-based routing. A load balancer for microservices is almost always L7.
• You terminate TLS centrally, manage certificates in one place, or run a WAF in front of HTTP traffic.
• You need a WebSocket load balancer, sticky sessions tied to cookies, or HTTP/2 and gRPC multiplexing.
• You want per-request logs for debugging or SLO tracking.

For most modern web stacks, the L7 proxy is the default.

Can You Use Both? Layered Load Balancing Architectures

Most large deployments do not choose. They layer. A typical load balancer architecture puts an L4 proxy at the edge for raw scale, then an L7 proxy inside for routing. The L4 tier handles connection volume, DDoS absorption, and protocol passthrough. The L7 tier reads requests and routes them. For a load balancer in microservices, the L7 tier often doubles as the ingress controller, with an L4 proxy or anycast IP in front. The result is L4 throughput with L7 request awareness.

Layer 3 Load Balancing: A Quick Mention

You will sometimes see L3 load balancer references, especially in hyperscaler edge networking. A Layer 3 load balancer routes at the IP level, often using ECMP or anycast with BGP, and sits in front of the L4 tier at the edge. It is a real category, but rarely a buying decision. Most operators consume L3 load balancing as a property of the cloud provider’s edge.

Examples of Layer 4 and Layer 7 Load Balancers

Common load balancer products and software load balancer options:

• HAProxy. Operates at both layers. TCP mode is L4, HTTP mode is L7.
• NGINX. L7 by default through http blocks. Adds L4 support through the stream module for TCP and UDP.
• Envoy. L7-first proxy used in service meshes like Istio and as a standalone application gateway. Also supports L4.
• Traefik. L7 proxy popular with container platforms, with native L4 TCP and UDP routers.
• Cilium and Katran. L4 datapaths built on eBPF, used for high-scale TCP and UDP forwarding.
• AWS NLB and ALB. NLB is L4, ALB is L7.
• Google Cloud Load Balancing. Offers an Application Load Balancer for L7 and a Network Load Balancer for L4, in passthrough and proxy variants.
• Azure. Splits the two layers across separate products: Azure Load Balancer for L4 (TCP and UDP), Azure Application Gateway for L7 (HTTP and HTTPS, with WAF).

These load balancer examples cover most production stacks. The software load balancer choice comes down to operational familiarity.

How to Choose Between Layer 4 and Layer 7

Use this as a quick decision checklist. Common load balancer methods like round-robin, least-connections, and IP-hash exist at both layers, so the layer choice comes before the algorithm.

• Protocols: anything outside HTTP, HTTPS, gRPC, or WebSocket points to L4.
• TLS: central termination means L7. Pass-through means L4.
• Routing rules: path, host, header, or cookie-based routing is L7-only.
• Throughput: if one proxy needs more than your L7 can push per core, add an L4 tier in front.
• Observability: per-request logs mean L7. Connection counts mean L4 is enough.
• Long term: L4 in front of L7 is the most common architecture at scale.

L4 / L7 Load Balancing on Contabo VPS

Contabo VPS plans can run any standard software load balancer, so you can deploy either layer without a managed product. A typical pattern is HAProxy or NGINX on a small VPS in front of two or more application servers on larger plans. NGINX covers L7 through its http block and L4 through the stream module, so a single binary can run both layers. HAProxy works the same way, with mode tcp for L4 and mode http for L7. For a step-by-step setup, see the load balancer setup guide on the Contabo blog. It covers VPS sizing, installing the proxy, and the config blocks for both layers.

Conclusion

The Layer 4 vs Layer 7 load balancer decision is mostly a question of what the proxy needs to see. L4 is the right answer for raw throughput, non-HTTP protocols, or pass-through TLS. L7 is the right answer for path-based routing, central TLS, and per-request visibility. Most production stacks end up running both.

Layer 4 vs Layer 7 Load Balancer FAQ

Is Layer 7 better than Layer 4?

Neither is universally better, it’s use-case dependent. Layer 7 is more feature-rich because it reads HTTP requests, so it wins for web apps and microservices. Layer 4 is faster and protocol-agnostic for the transport protocols it supports, so it wins for non-HTTP traffic, raw throughput, and edge-scale deployments. The L7 vs L4 load balancer choice depends on the protocols you balance and the routing rules you need.

Is NGINX a Layer 4 or Layer 7 load balancer?

Both. NGINX as a load balancer runs at Layer 7 by default through its http configuration block, where it handles HTTP, HTTPS, HTTP/2, and WebSocket routing. NGINX also supports Layer 4 through the stream module, which adds TCP and UDP load balancing. The same NGINX binary covers both layers, which is one reason it remains a default choice for mixed workloads.

Does a Layer 4 load balancer terminate SSL?

Usually no. SSL termination at the load balancer is a Layer 7 feature, because the proxy has to read the request to make routing decisions on cleartext data. A Layer 4 load balancer typically passes encrypted traffic straight through to the backends, which then handle TLS themselves. Some L4 proxies offer TLS pass-through with SNI-based routing, but that is the exception, not the rule.

Can a Layer 7 load balancer handle non-HTTP traffic?

A Layer 7 load balancer is designed for application protocols it can parse, mainly HTTP, HTTPS, gRPC, and WebSocket. For arbitrary TCP or UDP traffic, an L7 proxy either falls back to L4 mode, like NGINX stream or HAProxy mode tcp, or hands the traffic to a separate L4 tier. Pure non-HTTP workloads belong on L4, not L7.

What’s the difference between an Application Load Balancer and a Network Load Balancer?

In most cloud-vendor naming, an Application Load Balancer is Layer 7 and a Network Load Balancer is Layer 4. The difference between Application Load Balancer and Network Load Balancer is the same as L7 vs L4. The ALB reads HTTP requests and routes on URL, host, and headers. The NLB forwards TCP and UDP based on IP and port. ALB vs NLB is the cloud version of L4 vs L7.