Layer 7 load balancing is a form of load balancing in which the balancer reads application-layer data, such as HTTP paths, host names, headers and cookies, and uses it to decide which backend server receives each request. In networking, the name refers to the application layer of the OSI model, and a device or service that performs it is often called an application load balancer (ALB) or a reverse proxy.
Unlike a balancer that only sees IP addresses and ports, a Layer 7 balancer terminates the client connection, parses the request and opens its own connection to the chosen backend. This costs more processing per request, but it enables content-based routing, TLS termination, header rewriting, request-level health checks and fine-grained traffic control that a transport-level balancer cannot provide.
How Layer 7 load balancing works
A Layer 7 balancer behaves as a full proxy. It accepts the TCP connection from the client, completes the TLS handshake if traffic is encrypted, and reads the HTTP request. It then evaluates routing rules against the request, selects a backend pool, chooses a server within that pool using a load balancing algorithm, and forwards the request over a separate backend connection.
Because it works per request rather than per connection, a single client connection carrying many HTTP requests can be spread across several servers. This matters for HTTP/2 and HTTP/3, where browsers multiplex many requests over one long-lived connection that a transport-level balancer would pin to a single backend.
The table shows the main steps in handling one request.
| Step | Action | Information used |
|---|---|---|
| Connection accept | Client TCP or QUIC connection is accepted | Destination IP and port |
| TLS termination | Traffic is decrypted with the site certificate | Server name indication |
| Request parsing | Method, path, headers and cookies are read | HTTP request line and headers |
| Rule evaluation | Routing rules select a backend pool | Host, path, header and cookie values |
| Server selection | An algorithm picks one healthy server | Load, weights, session affinity |
| Forwarding | Request is sent, response returned to client | Backend connection pool |
Routing rules and traffic policies
The defining capability of Layer 7 load balancing is routing by request content. One public address can serve many applications, each handled by a different group of servers, and traffic can be shifted gradually between versions of the same service.
| Criterion | Example rule | Typical purpose |
|---|---|---|
| Host name | api.example.com goes to the API pool | Several sites behind one address |
| URL path | Paths under /images go to the media pool | Separating static and dynamic content |
| HTTP header | A version header selects the beta pool | Feature testing and API versions |
| Cookie | A session cookie maps to one server | Sticky sessions |
| Weighted split | 5 percent of requests to the new release | Canary and blue-green deployments |
| Client attributes | Mobile user agents to a dedicated pool | Device-specific back ends |
Layer 7 balancers can also modify traffic: they add headers such as X-Forwarded-For so that backends know the original client address, redirect HTTP to HTTPS, compress responses, enforce rate limits and block malformed requests. Many products integrate a web application firewall at this layer.
Layer 7 compared with Layer 4 load balancing
The choice between Layer 4 and Layer 7 is a trade-off between visibility and efficiency. Layer 4 load balancing forwards packets or connections based on addresses and ports and never inspects the payload, so it is faster and protocol-agnostic. Layer 7 sees the full request and can make smarter decisions, but it consumes more CPU and memory per request and adds a small amount of latency.
| Aspect | Layer 4 load balancing | Layer 7 load balancing |
|---|---|---|
| Decision basis | IP addresses and ports | URLs, headers, cookies, methods |
| Unit of balancing | Connection or flow | Individual request |
| Protocols | Any TCP or UDP traffic | HTTP, gRPC, WebSocket and similar |
| TLS handling | Usually passed through | Usually terminated |
| Performance cost | Very low | Moderate |
| Health checks | Port reachability | Application responses such as status codes |
| Client IP visibility | Often preserved directly | Passed in headers or proxy protocol |
Large deployments commonly combine both: a Layer 4 tier distributes connections across a fleet of Layer 7 proxies, which then apply application rules. Global server load balancing or DNS load balancing may sit in front of both to direct users to the nearest region.
Configuration choices in practice
A reliable Layer 7 setup depends on a few decisions made early. The decision table summarizes common situations.
| Situation | Recommended choice | Reason |
|---|---|---|
| Stateless web application | Least connections or round robin | Even load without affinity |
| Legacy app with server-side sessions | Cookie-based sticky sessions | Keeps users on their session server |
| Microservices behind one domain | Path and host routing | One entry point, many services |
| Frequent releases | Weighted canary routing | Limits impact of faulty versions |
| Compliance requires encryption to servers | TLS re-encryption to backends | End-to-end protection |
| Planned server maintenance | Connection draining | Finishes active requests before removal |
Health checks should test a real application endpoint, ideally one that verifies dependencies such as the database, rather than only a static page. Timeouts deserve equal care: an idle timeout shorter than the application’s longest request cuts off uploads or long-running API calls.
Limitations and common pitfalls
Because the Layer 7 balancer sits in the middle of every request, misconfiguration affects the entire application.
- The balancer can become a bottleneck if TLS termination and rule processing are not sized for peak traffic.
- Backends see the balancer’s address, so logging and access control must read the forwarded client address correctly.
- Trusting forwarded headers from any source allows clients to spoof their IP address.
- Sticky sessions undermine even distribution and complicate scaling; shared session storage is usually better.
- WebSocket and streaming connections need suitable timeouts, or the balancer closes them unexpectedly.
- Terminating TLS moves sensitive data into the balancer, which then requires the same protection as the application.
In simple terms
Picture a large office building with a receptionist at the entrance. A simple doorman would send each visitor to whichever elevator is free. A Layer 7 load balancer is the receptionist who reads each visitor’s appointment card and sends them to the correct department.
On a website, the appointment card is the web request: the address of the page, the type of device and any login information. Reading the request lets the balancer send each one to the right group of servers, which keeps large websites fast and organized.
A practical example
An online retailer runs its storefront, product search, image delivery and checkout as separate services, all reachable under one domain. A Layer 7 load balancer terminates HTTPS for the domain and routes requests by path: search requests go to a pool of eight search servers, image requests to a caching tier, and checkout requests to a separate, more tightly secured pool.
Before a major sales event, the team deploys a new checkout version and uses weighted routing to send 5 percent of checkout traffic to it. Error rates are watched for one hour, then the share is raised step by step to 100 percent. When one search server begins returning errors, the application-level health check removes it from rotation within seconds. Shoppers notice neither the release nor the failure.