Proxies: forward proxy, reverse proxy and API gateway

01Proxy definition: forward versus reverse

A proxy is an intermediary that receives communication and forwards it on behalf of another party. A hop is one connection segment along that path. The same request can travel client → proxy → application, with a separate response returning through those components. The proxy can apply access or routing rules, cache a permitted response, or change how the next connection is made. A proxy adds a hop; it does not erase the need to understand the caller and the destination.

A forward proxy represents clients accessing remote services; an organizational gateway may filter destinations and record permitted outbound traffic. A reverse proxy fronts origin servers and routes incoming traffic to them. For example, shop.example can accept a public /orders/17 request and forward it to an internal order API.

The origin is the service responsible for producing the resource. A proxy may return a cached origin response when the policy allows. “Forward” and “reverse” describe whose side the intermediary serves, not whether packets travel only in one direction.

One deployed component can perform several of these jobs. Explain the responsibilities separately so a product name does not hide an authorization or failure assumption.

02Worked example: an HTTPS request through a reverse proxy

For an HTTPS request to https://shop.example/orders/17, several protocols have separate responsibilities. DNS maps a service name to a network address. HTTP carries the request and response. TLS encrypts a connection and authenticates its endpoint using certificates; HTTPS is HTTP over a protected connection. TLS termination is where that protected connection ends and the receiver can inspect its HTTP content. The following steps use those terms; protocol details are in the request-lifecycle chapter.

1. DNS resolves the public shop name to a reachable edge address.
2. The browser establishes an encrypted connection to the shop's reverse proxy and verifies its certificate for that name.
3. The proxy receives GET /orders/17, plus the session credential. That credential is evidence used to authenticate the signed-in account; the URL itself proves no identity. The proxy routes the request to the order service.
4. It opens or reuses a backend connection. If this crosses an untrusted network segment, encrypt and authenticate that hop too.
5. The order service derives the caller’s identity from a validated credential and checks permission to read order 17.
6. The response travels back through the proxy to the browser. Private order data is not placed in a broadly shared cache.

An API gateway is often a reverse proxy with additional API policy: authentication checks, quotas, routing, or request validation. A load balancer chooses among eligible backends. One product can perform both roles, but the responsibilities remain separate.

03Forwarding headers and trusted client identity

The backend connection originates at the proxy, so the backend's immediate peer address may be the proxy's address. Forwarding headers can carry earlier connection information. They must be trusted only from known proxy hops, because a public caller can forge ordinary request headers.

Suppose an attacker sends X-Forwarded-For: 127.0.0.1. A backend that treats that value as proof of an internal caller may grant unintended access. The edge should normalize forwarding metadata, and the backend should know which upstreams are authorized to supply it. Rewriting a header is a security-sensitive operation when policy depends on that field.

04Open, anonymous and transparent proxies

Forward and reverse describe whom a proxy represents. Open, anonymous and transparent describe other properties: who may use it, what identity information it reveals, or how traffic reaches it. These labels can overlap; choosing one does not answer the questions covered by the others.

An open proxy accepts use from a broad or unrestricted set of clients. A closed organizational proxy limits who may use it. Openness is an access-control property. It says nothing by itself about whether the proxy hides the client identity or inspects content.

An anonymous proxy attempts not to reveal some client-identifying information to the destination. That is not a promise of universal anonymity: accounts, cookies, behavior, or other headers can still identify a user. Explain the exact information hidden rather than using anonymity as a security guarantee.

“Transparent proxy” is overloaded. In common network terminology, a transparent or interception proxy handles traffic without explicit proxy configuration in the client. Older HTTP specifications also used transparent to mean that the proxy does not transform requests or responses beyond changes needed for proxy authentication and identification. These are different properties; name the intended meaning. Intercepting encrypted content requires an applicable trust and certificate arrangement; a device that only forwards encrypted bytes cannot arbitrarily inspect their HTTP content.

The useful interview distinction is role plus policy: who can use the proxy, which destination it represents, what it can see, and what information it forwards.

05Reverse-proxy caching and API gateway policies

A reverse proxy can cache public versioned images, compress permitted responses, terminate TLS, filter malformed requests, and route to service pools. For each feature, state which requests it applies to, what it may change, and its resource or security cost. Compression uses CPU; logging can expose sensitive data; transformation can invalidate signatures or cached representations if done incorrectly.

For the private order page, choose authorization-aware forwarding and an explicit cache policy. HTTP private prevents shared caches from storing the response but can permit a browser cache; no-store tells caches not to store it. Choose the policy required by the product instead of treating those directives as synonyms. For /images/P7/v9.jpg, a shared edge cache can reuse the same immutable public bytes. The first request misses and fetches the static origin; the next permitted request hits nearby storage. Different paths can therefore have different cache and authentication policies.

An API gateway may reject excess traffic before it reaches expensive application work, but it must identify users and quota dimensions correctly. Sending all traffic through a single unreplicated gateway creates a new failure point even if the applications behind it are redundant.

06Proxy timeouts, retries and redirect rewriting

A proxy can rewrite the path it forwards so a public URL maps to a different internal path. A redirect instead asks the client to make a new request, using the destination in the response’s Location header. The two mechanisms interact when the public and internal URL layouts differ.

Path rewriting also changes visible behavior. Suppose a public service lives under /store/ while the origin serves /. A redirect from the origin to /orders/17 can escape the public prefix unless the proxy rewrites the Location header or published links avoid the redirect. Verify both the origin address and the public path; success at one does not prove the other works.

Health-check and replicate the proxy layer, measure added latency and errors, and consider how configurations roll out. A malformed routing rule can fail every healthy backend at once. Keep configuration changes reviewable and validate representative paths, headers, uploads, and redirects.

Parsing must also agree across hops. Request framing determines where one HTTP message ends and the next begins. If a proxy and backend interpret ambiguous length information differently, they can disagree about which bytes belong to an authorized request. Prefer standards-compliant parsers, reject ambiguous framing under an explicit edge policy, and apply consistent path normalization before authorization and routing. HTTP/2 or HTTP/3 at the client does not remove this boundary when an intermediary translates to HTTP/1.1 upstream. See the HTTP/1.1 framing specification.

07Interview example: justify the proxy boundary

Interviewer: “Why do you need a reverse proxy if you already have an application?”

Candidate: “It gives the public service one controlled entry point for TLS and routing. For an order request, it forwards to an eligible order server, but the server still checks that the caller can read order 17. Public versioned images can be cached at the edge; private orders cannot share that policy. I also configure deadlines, safe forwarding headers, and redundant proxy capacity. The extra hop is useful because it performs these specific responsibilities.”

NGINX can implement this reverse-proxy role with explicit upstream routing and header policy. For a protected HTTPS backend, configure certificate verification, the expected backend name and the trusted certificate set; merely selecting an https:// upstream is not the complete identity check. The current proxy-module reference documents proxy_ssl_verify as off by default, so enable verification deliberately where required. The real-IP module separately controls which proxies may supply network-address metadata. Those options do not authenticate the application user. See the proxy module and trusted real-IP configuration.

Recall the key ideas

Answer from memory before opening each card. Explain why the choice works and what it costs. Revisit missed cards tomorrow.