Glossary
Reverse proxy
A reverse proxy is a server that accepts requests on behalf of one or more origin servers behind it, forwards them, and returns the responses. From the client's point of view it is the website. It is where TLS termination, caching, compression, load balancing and request filtering are usually implemented, which means a site's observable behaviour is frequently the proxy's configuration rather than the application's.
What it typically handles
TLS termination: the certificate and the handshake belong to the proxy, and the connection to the origin behind it may be plain HTTP inside a private network.
Load balancing across several origins, with health checks removing ones that stop responding.
Caching, so that repeated requests for the same resource never reach the origin.
Compression, applied to responses the origin sent uncompressed.
Header manipulation: adding security headers, removing ones that disclose the origin's software, rewriting cache directives.
Protocol translation: accepting HTTP/2 or HTTP/3 from visitors while speaking HTTP/1.1 to an origin that does not support the newer versions.
What it changes about a request
The origin sees the proxy's address as the client, not the visitor's. The real address is carried in `X-Forwarded-For` or the standard `Forwarded` header.
The origin sees plain HTTP even though the visitor used HTTPS, which is why `X-Forwarded-Proto` exists and why omitting it produces redirect loops.
An application that trusts these headers without the proxy setting them authoritatively can be lied to by a client sending its own, which is a real spoofing vector.
Logging, rate limiting and geolocation all depend on the forwarded address being read correctly, and all fail quietly when it is not.
Request and response buffering changes timing: an origin may finish generating a response long before the visitor receives it, which makes origin-side timing measurements disagree with what a visitor experiences.
What it hides, and what it does not
It hides the origin's address, provided the origin is not also reachable directly. An origin left open at its own address can be found and contacted, bypassing everything the proxy does.
It hides the origin's software when it strips the `Server` header, though timing and behavioural differences remain.
It does not hide application behaviour: an authorisation flaw is exactly as exploitable through a proxy as without one.
It does not make an origin secure. It relocates the network boundary.
How to tell one is there
Response headers naming a proxy or CDN, or a cache status header reporting hits and misses.
The resolved address belonging to a network operator different from the hosting provider.
Headers that differ from what the application is configured to send, which identifies the layer adding them.
Comparing the response from the public hostname against one from a known origin hostname, where the difference is the proxy's contribution.
A `Via` header, when present, names the intermediaries a response passed through, although most deployments strip it.
Frequently asked questions
- What is the difference between a reverse proxy and a CDN?
- A CDN is a geographically distributed set of reverse proxies with caching as its primary purpose. A reverse proxy may be a single server in front of one origin.
- Why does my application redirect in a loop behind a proxy?
- The application sees plain HTTP from the proxy and redirects to HTTPS, which the proxy forwards as HTTP again. The forwarded-protocol header resolves it.
- Can X-Forwarded-For be trusted?
- Only when the proxy sets it authoritatively and the application ignores any value a client sent. Otherwise a client can put anything it likes there.
Sources
Related
VeriFixScan crawls a site and applies its checks to every page it reaches, keeping the evidence behind each finding. Scanning one website is free.
Scan a website