Jan Mikoláš
Glossary
Reverse proxy
A reverse proxy is the public HTTP boundary in front of an application. It routes traffic and forwards technical context, but should not decide user permissions or order rules.
Short definition
A server that protects and exposes the backend, not the client.
A reverse proxy sits between a client and one or more backend services. The client communicates with the public proxy address, which selects an application by domain, path or another rule, sends it the request and returns its response. The backend does not need its own public port or to handle every TLS connection directly.
The name matters: a forward proxy represents a client when accessing external services, while a reverse proxy represents or protects the server side. nginx, Traefik, Apache HTTP Server, a cloud load balancer and an API gateway can all perform this role to different extents. The specific tool is not the essence of the principle.
What it is used for
One controlled path to several internal services
A proxy concentrates technical HTTP decisions at a point in front of the application runtime.
- HTTPS and redirects from HTTP for the website, administration interface and API
- routing app.example.cz, api.example.cz and the administration interface to different services
- keeping the ports of a PHP application, Node.js service, database and worker hidden on the internal network
- delivering static files, providing basic caching and limiting request size
- forwarding trusted information about the original host, scheme and client address
Practical example
A website and API as internal services
An online store has a public website and a separate API. The reverse proxy accepts HTTPS on both domains and forwards each request to the corresponding Docker service based on the hostname. PostgreSQL, Redis and the worker have no public port; they are reachable only by the applications that need them.
The example is deliberately a simple nginx rule. It illustrates the boundary, not a complete production configuration for certificates, health checks and trusted IP addresses of an upstream load balancer.
server {
listen 443 ssl;
server_name api.example.cz;
location / {
proxy_set_header Host $host;
proxy_set_header X-Forwarded-Proto https;
proxy_set_header X-Forwarded-For $remote_addr;
proxy_pass http://api:8080;
}
}How it works
The path of a request from the internet to the backend
A proxy translates the public HTTP entry point into a deliberately restricted path to a service inside the infrastructure.
- The client connects A browser or API client sends a request to a public domain. The proxy accepts the connection and handles the TLS layer for HTTPS.
- A rule is selected Based on the host, path, method or another safely defined condition, the proxy selects a target backend or static response.
- Context is forwarded The proxy supplies the headers the application needs, including the original host and protocol. A backend must not trust forwarded values from a client without a known proxy chain.
- Communication with the upstream The application receives an internal HTTP or FastCGI connection. The proxy monitors timeouts and errors and can select another healthy instance when configured to do so.
- Response and logs The proxy returns the response and may buffer or cache it. Access and error logs provide a shared view of boundary traffic.
Main parts and concepts
A proxy protects the network and HTTP boundary.
Everything placed in front of the application needs a precisely defined purpose and relationship with it.
Routing and upstream
Routing selects the service; an upstream is a target server or group of instances. URL redirects and load balancing change the operational path, not the meaning of an application command.
TLS termination
The proxy can hold the server certificate and terminate TLS at the infrastructure edge. The connection to the backend may be on a trusted internal network or encrypted again according to the risk model.
Forwarded headers
An application behind a proxy needs to recognise the original HTTPS scheme or client address. X-Forwarded-* and standard Forwarded headers are meaningful only when they come from a proxy the application knows and trusts.
Timeouts, buffering and retries
A timeout should suit the endpoint. Automatically retrying a write request can create a duplicate operation when the API does not have idempotent semantics.
Caching and limits
Caching is suitable only for safely shareable content with deliberate invalidation. Rate limiting protects capacity but does not replace authentication, authorization or validation.
Benefits and limitations
A central HTTP boundary simplifies operations but adds another layer.
Benefits
- one place for domains, HTTPS and part of the HTTP policy
- backend ports and databases are not exposed directly to the internet
- the ability to route multiple applications and collect consistent operational logs
- separation of static content from the application runtime
Limitations and common mistakes
- blindly trusting headers sent directly by the client
- an incorrect path in a proxy rule changing the URI passed to the application
- excessive timeouts or retries on write endpoints
- caching a personalised response without checking cookies and authorization
- moving business logic and authorization into the proxy configuration
When it makes sense
When the public HTTP entry point needs to be managed independently of the runtime.
A reverse proxy is a natural fit for multiple domains, a separate API and frontend, a Docker environment or an application with its own PHP-FPM and workers. It provides one place for TLS, redirects and access to internal services without exposing their ports externally.
A small website on a managed platform may already receive this layer as part of the service, making custom configuration unnecessary. Even in larger infrastructure, the proxy should remain proportionate. Complex rules for orders, roles or state synchronisation belong in versioned and tested application code.
What to consider
The public boundary should be minimal and traceable.
The configuration is tested together with the application rather than merely as an isolated file.
- publish only the necessary ports and keep backends on an internal network
- set clear rules for the host, path, HTTPS and expected redirects
- rewrite or trust forwarded headers only within a controlled proxy chain
- choose timeouts and retries according to whether the endpoint reads or changes state
- monitor status codes, upstream time, TLS failures and rejected requests
Common questions
Reverse proxies without confusing responsibilities
Is a reverse proxy the same as a load balancer?
Load balancing can be one reverse proxy function when it selects from multiple backends. A reverse proxy can also sit in front of a single application and handle TLS, routing or static files.
Can a backend trust X-Forwarded-For?
Only if the request came through a known proxy chain that safely replaces or correctly processes the client-supplied value. A direct client can forge such a header.
Does HTTPS replace user authentication?
No. TLS usually authenticates the server and protects transport. The application must still verify the session or token and evaluate permission for the operation.
Can a proxy safely retry a request after a timeout?
Only if the specific operation is safely idempotent and the retry has well-defined semantics. Otherwise, a write could create duplicate state.
How I design application operations
I separate the public entry point from internal services and data.
For backends, I design the HTTP boundary, API, database, cache and workers together so that network responsibilities remain clear.