A reverse proxy can run at layer 4 (connection level) or layer 7 (request level). What can each one inspect and route on, and what does each one hand to the backend?
answer
- bytes versus requests
- what the proxy is allowed to read
- one hostname escapes the handshake
- parsing means terminating
- one decision per connection
basics
~20 sA layer 4 proxy sees only connection data — source and destination IP and port, and for TLS the cleartext SNI hostname — and copies bytes through untouched. A layer 7 proxy parses each request, so it can route on path, method, headers or cookies.
solid answer
~50 sA layer 4 proxy works at the transport level: it accepts a TCP (or UDP) connection, picks a backend, opens a connection to it and shuttles bytes in both directions without interpreting them. All it can match on is the connection's addresses and ports, plus — for TLS — the SNI hostname and ALPN list, which travel in cleartext in the ClientHello before any key exchange. It cannot see a URL path, a method, a header or a status code. A layer 7 proxy terminates the client connection, decrypts if TLS is in play, and parses each HTTP request, so it can route on host, path, method, header or cookie, rewrite the request, and generate its own responses. The backend then talks to the proxy, not to the client's original stream. The rule of thumb: layer 4 forwards a byte stream, layer 7 forwards requests it has understood.
go deeper
Be ready to say plainly that layer 4 sees addresses, ports and the TLS SNI hostname while layer 7 sees the path, method, headers and cookies, and to give one routing example that only layer 7 can do.
Explain the mechanics: SNI is cleartext in the ClientHello, parsing HTTP requires terminating the connection, and a layer 4 proxy picks a backend once per connection while a layer 7 proxy picks once per request.
Show you know what changes for the backend — it now sees the proxy's connections and pooled keep-alives rather than the client's stream — and what per-request telemetry and control you gain or lose by choosing an altitude.
Own the framing that the altitude is a commitment about what the traffic layer is allowed to understand, and that any capability requiring request visibility drags a termination point and a key-holding tier along with it.
## Two altitudes, one job A proxy sits between a client and a backend and passes traffic along. The only question this leaf is about is **how much of that traffic the proxy is allowed to understand**. "Layer 4" and "layer 7" are OSI shorthand: layer 4 is the transport (TCP, UDP), layer 7 is the application protocol carried inside it (HTTP most often, but also SMTP, MQTT, a database wire protocol, anything). A layer 4 proxy is sometimes called a TCP proxy, connection proxy, or in load-balancer marketing a "network" load balancer; a layer 7 proxy is an HTTP proxy or "application" load balancer. ## What a connection-level proxy can act on When a client connects, the proxy learns: - the source IP and port, and the destination IP and port it was reached on; - how long the connection lives and how many bytes flow each way; - if the first bytes are a TLS ClientHello, the fields that are **not** encrypted: the SNI hostname the client asked for and the ALPN protocol list (`h2`, `http/1.1`). SNI is the interesting one, because it is what lets a connection-level proxy put `api.example.com` and `www.example.com` on different backends even though both arrive on port 443 — without ever holding a private key or decrypting anything. It reads the hostname out of the handshake and then forwards the whole stream, handshake included, to the chosen backend. What it cannot do is anything that requires framing the stream into requests. It does not know where one request ends and the next begins. It has no path, no method, no `Cookie` header, no response status code. It cannot add a header, cannot rewrite a URL, cannot log "GET /orders → 500 in 40 ms", and cannot cache. ## What a request-level proxy can act on A layer 7 proxy is a participant in the application protocol. It terminates the client's connection (and, for HTTPS, the TLS session), reads the request, and understands it: ```http GET /api/orders?page=2 HTTP/1.1 Host: shop.example.com Cookie: sid=9f2c Accept: application/json ``` Every part of that is now a routing input: send `/api/*` to the API pool and everything else to the static pool; send requests carrying a beta cookie to the canary pool; treat `POST` differently from `GET`. Beyond routing it can rewrite the path, add or strip headers, enforce size limits, compress, cache, retry an attempt on another backend, and produce its own error response when the upstream misbehaves. It also gets real per-request telemetry: path, status, upstream latency, response size. The backend, meanwhile, is no longer talking to the client. It is talking to the proxy, usually over a pooled keep-alive connection that carries requests from many different clients. ## The price of parsing Understanding requires terminating. To read HTTP inside TLS, the proxy must complete the TLS handshake itself, which means it holds a certificate and key for that name — the topology and key-placement question is its own subject, but the dependency is the point here: **no termination, no layer 7 routing.** That is why "route on the URL path but keep the session encrypted end to end" is not a thing; if the proxy could read the path, the session was not end to end. Parsing also costs CPU per request rather than per connection, adds latency, and gives the request one more place to fail. ## One decision per connection, or one per request This is the consequence candidates most often miss. A layer 4 proxy chooses a backend **once, at connection setup**. If a client sends two hundred HTTP requests over one keep-alive connection, all two hundred land on the same backend, because the proxy never saw two hundred of anything — it saw one connection. A layer 7 proxy chooses **per request**, so the same two hundred requests can be spread across the whole pool. That difference is invisible on short-lived HTTP/1.1 connections from browsers and enormous on long-lived multiplexed ones. ## Where each belongs Layer 4 is the right altitude when the payload is not HTTP (a database connection, a mail or message-broker protocol, an opaque binary RPC), when nobody may hold the key at the proxy tier, or when you want maximum throughput with minimum interference. Layer 7 is the right altitude when the decisions you need to make — routing, rewriting, per-request retries, quotas, per-request observability — only exist once you can read the request.
- If a layer 4 proxy cannot read HTTP, how can it send two different hostnames on port 443 to different backends?By reading SNI. The TLS ClientHello carries the requested hostname in cleartext before any keys are agreed, so the proxy peeks at it, picks a backend, and forwards the untouched handshake and stream on. It gets the hostname and the ALPN list and nothing else — no path, no headers — and the mechanism disappears if the client uses Encrypted Client Hello.
- Could a layer 4 proxy route on the URL path if the traffic were plain HTTP rather than HTTPS?The bytes would be readable, but the moment it parses a request line it is doing layer 7 work — that is what the label means. Connection-level forwarding does not frame the stream into requests at all; a request may straddle segments, and the proxy has already committed to one backend for the whole connection.
- Does layer 4 mean TCP only?No — UDP proxying is layer 4 too, and it matters for DNS, syslog, game and QUIC traffic. A UDP proxy usually pins flows by hashing the address/port tuple, which is why QUIC connection migration between networks needs connection-ID-aware forwarding rather than plain tuple hashing.
saying these in an interview costs you the question
- Claiming a layer 4 proxy can route on the URL path
- Saying SNI exposes the path, not just the hostname
- Believing the proxy decrypts TLS to read SNI
- Thinking layer 7 routing works with end-to-end encryption intact
- Treating the difference as purely about speed