Load Balancers: Layer 4 vs Layer 7

What every load balancer does

Whatever layer it works at, a load balancer has three jobs. It publishes a stable front door, the VIP, that clients connect to. It keeps a pool of backends and runs health checks against them, removing any that stop responding. And it chooses a backend for each new connection or request using an algorithm such as round robin, least connections, weighted distribution, or a hash of some client property so the same client tends to land on the same server.

Health checking is the part people underestimate. A balancer that only checks whether a TCP port accepts connections will keep sending traffic to an application that accepts connections and then returns errors. Layer 7 balancers can check a real request, such as an HTTP GET for a status page, and expect a specific response code.

How Layer 4 load balancing works

A Layer 4 balancer makes one decision per connection, or per flow for UDP, based on the source and destination addresses and ports. After that, it simply moves packets. It never parses the payload, so it works the same for HTTPS, SMTP, database protocols, game traffic, or DNS. There are a few common forwarding modes:

Large-scale Layer 4 balancers are often built as a set of identical machines that all announce the same VIP with BGP, so routers spread traffic across them with equal-cost multipath. Each machine then uses consistent hashing on the flow so that any of them would pick the same backend for a given connection. That way, when a balancer machine fails, its connections can usually continue through a neighbor.

Because Layer 4 balancers do not decrypt TLS, they never hold your certificates' private keys. That is a security advantage, and it keeps them cheap and fast. The cost is that they cannot see anything inside the encrypted stream.

How Layer 7 load balancing works

A Layer 7 balancer is a reverse proxy. It completes the TCP handshake and usually the TLS handshake with the client, reads the full request, and then opens or reuses a separate connection to the chosen backend. Because it understands the protocol, it can do things a Layer 4 balancer cannot:

• Route api.example.com and www.example.com, or /images/ and /checkout/, to different pools on the same address.
• Retry a failed request on another backend before the client notices.
• Keep a user on one backend with a cookie, rather than relying on their IP address.
• Add the client's address to a header, such as the standard Forwarded header from RFC 7239 or the common X-Forwarded-For.
• Terminate HTTP/2 or HTTP/3 from clients while talking HTTP/1.1 to older backends.
• Apply rate limits, authentication, or web application firewall rules per request.

The price is work. Every request is decrypted, parsed, and re-sent, which costs CPU and adds a little latency. The balancer holds TLS private keys, so it becomes a high-value target. And it only helps for protocols it understands; a Layer 7 HTTP proxy cannot balance an SMTP session by message content.

Side-by-side comparison

Balancing DNS servers themselves

DNS is an interesting case because most queries are a single UDP packet each way with no connection. A Layer 4 balancer in front of resolvers or authoritative servers can treat every query independently, which spreads load evenly. The main pitfall is source address translation: if the balancer rewrites the client's address, the DNS server sees every query as coming from the balancer, which breaks per-client access lists, rate limiting, and logging. Direct server return, or an anycast design where each server announces the service address itself, avoids that. TCP vs UDP and Why DNS Uses Both explains why the TCP side still needs connection tracking.

There are also DNS-aware proxies that act at Layer 7 for DNS: they parse each query and can route by query name or type, cache answers, or drop abusive patterns before they reach the servers behind them.

How DNS points users at a load balancer

Users reach a load balancer through DNS. If you run your own balancer, you publish its VIP as an A or AAAA record. Managed cloud balancers usually give you a hostname instead, because the addresses behind it change as the provider scales the service. You point your name at it with a CNAME:

$ dig +noall +answer www.example.com A
www.example.com.        300   IN  CNAME  lb-prod-1.example.net.
lb-prod-1.example.net.  60    IN  A      198.51.100.20
lb-prod-1.example.net.  60    IN  A      198.51.100.21

Two details matter here. First, the provider's own records often have short TTLs so it can move addresses quickly; do not copy those addresses into your zone as A records, or your site will break when they change. Second, a CNAME cannot sit at the zone apex alongside SOA and NS records, so pointing example.com itself at a balancer hostname needs a provider feature such as ALIAS or CNAME flattening, covered in CNAME at the Apex: ALIAS and Flattening.

DNS can also choose between whole sites. Global server load balancing uses health checks and DNS answers to send users to the nearest or healthiest region, each of which has its own Layer 4 or Layer 7 balancers. GeoDNS and DNS Load Balancing covers that layer.

How DNS Panopticon helps

Domain Visualizer resolves a domain's public records live, so you can see the CNAME chain and addresses that lead to your balancer. Website Recon matches CNAME suffixes, name servers, and the AS number behind each address against its provider catalog to suggest which hosting or CDN provider is in front of a name. If you have a zone export, Zone Analyzer lets you tick specific A, AAAA, and CNAME rows and open screenshots of them with Verify selected, a quick way to confirm each balanced hostname serves the page you expect.