A reverse proxy is the public entry layer in front of one or more application processes. On a cloud VM, it commonly terminates TLS, routes requests by hostname or path, forwards the correct client/protocol headers, applies request limits and timeouts, and centralizes access logs.
For most small teams, Nginx or Caddy is enough. The decision is less about raw proxy throughput and more about configuration style, automatic HTTPS, operational familiarity, and how much routing complexity the application needs.
Raff Technologies customers running public web applications on Linux VMs should treat the reverse proxy as part of the production architecture rather than a last-minute web-server setting.
What a reverse proxy does on a cloud VM
Without a reverse proxy, an application framework might listen directly on a public port. That is simple during development but weakens the production boundary.
A common production path is:
Internet
↓
DNS
↓
Firewall
↓
Reverse proxy :443
↓
Application :3000 / :8000 / :8080
The reverse proxy becomes the stable public endpoint while the application can stay bound to localhost or a private interface.
Typical responsibilities include:
- TLS termination;
- HTTP-to-HTTPS redirects;
- host and path routing;
- forwarding
Host, X-Forwarded-For, and protocol information;
- request/body size limits;
- timeouts;
- compression;
- access logs;
- routing to multiple local services;
- basic load distribution across multiple upstream processes.
A reverse proxy is not automatically a replacement for a managed load balancer. The two can overlap, but they solve different infrastructure layers.
Reverse proxy vs web server vs load balancer
The same software can perform several roles, which is why the terminology gets confusing.
| Role | Primary job | Example |
|---|
| Web server | Serve static files or HTTP content | Nginx, Caddy |
| Reverse proxy | Forward client requests to application backends | Nginx, Caddy |
| Load balancer | Distribute traffic across multiple backend instances | Nginx, HAProxy, managed LB |
A single Nginx instance can be all three at once. Architecture—not the binary name—determines the role.
Use Reverse Proxy vs Load Balancer when the question is whether traffic should be distributed across multiple servers. That page remains owned by the Networking cluster.
Nginx or Caddy?
Raff already has strong search visibility for Caddy Server vs Nginx, so this guide does not duplicate that comparison.
The short version:
Choose Nginx when:
- your team already knows Nginx;
- you want explicit, mature configuration patterns;
- you need extensive examples for complex routing;
- you are integrating with an established Nginx-based stack.
Choose Caddy when:
- automatic HTTPS is a major convenience;
- configuration simplicity matters;
- the routing model is straightforward;
- you want fewer moving parts around certificate issuance and renewal.
Both can proxy production applications correctly.
Bind the application privately
A reverse proxy is most useful when the application server is not independently exposed to the public internet.
For example:
127.0.0.1:3000 → Node.js
127.0.0.1:8000 → FastAPI / Django
127.0.0.1:9000 → PHP-FPM (FastCGI rather than HTTP)
The firewall exposes 80/443, while the application listens on localhost or a private interface.
That reduces the number of public entry points and makes the proxy the place where TLS and HTTP policy live.
TLS should be part of the proxy design
For public applications, HTTPS is not optional production polish.
With Nginx, a common model is:
DNS → Nginx → Certbot/ACME certificate → application
With Caddy, HTTPS can be managed automatically when DNS and reachability conditions are satisfied.
The important operating requirements are:
- certificate issuance succeeds;
- renewal is automatic;
- port 80/443 reachability matches the ACME method;
- the hostname resolves correctly;
- the proxy redirects HTTP as intended;
- the application receives the original scheme/host when it needs them.
For the Nginx path, use Certbot for Nginx on Ubuntu 24.04.
Applications frequently need to know the original hostname, client IP, and whether the request arrived over HTTPS.
A reverse proxy therefore needs correct forwarding headers.
Common headers include:
Host
X-Real-IP
X-Forwarded-For
X-Forwarded-Proto
The application must also be configured to trust proxy headers only from expected proxy sources. Blindly trusting forwarded headers from arbitrary clients can produce incorrect scheme/client-IP handling.
Framework-specific proxy trust settings should stay in the framework tutorial rather than in a generic connector page.
Timeouts and buffering should match the workload
Defaults may not fit every application.
Long requests, streaming responses, WebSockets, large uploads, and server-sent events can require specific timeout or buffering behavior.
Examples:
- a normal REST API can use conservative request timeouts;
- WebSockets require upgrade handling;
- large uploads may need a larger body limit;
- long-running HTTP tasks often indicate that background-job architecture would be better than simply increasing proxy timeouts.
Do not solve an application architecture problem solely by making every proxy timeout extremely large.
Reverse proxy routing patterns
A reverse proxy can route by hostname:
api.example.com → API service
app.example.com → frontend service
admin.example.com → admin service
Or by path:
/api/ → API backend
/app/ → application backend
/static/ → static files
Host-based routing is often easier to reason about when services have distinct responsibilities. Path routing can be appropriate when the public application intentionally shares one hostname.
Keep routing rules minimal. A proxy configuration that embeds too much business logic becomes difficult to test and migrate.
Logs are part of the production interface
Reverse-proxy logs can answer questions that application logs cannot.
Useful fields include:
- timestamp;
- request method/path;
- status code;
- response time;
- upstream response time;
- host;
- client IP or trusted forwarded IP;
- user agent;
- request ID where available.
Avoid logging sensitive authorization headers, tokens, or confidential query-string data.
Proxy logs should complement, not replace, application observability.
Reverse proxy health and failure modes
A reverse proxy adds another process to the request path.
Monitor at least:
- whether the proxy service is running;
- whether ports 80/443 accept connections;
- TLS validity;
- 4xx/5xx trends;
- upstream connection errors;
- latency;
- public synthetic checks.
Common failure modes include expired/misissued certificates, DNS pointing at the wrong IP, firewall rules blocking 80/443, the upstream application listening on the wrong address, and stale proxy configuration after a deployment.
When one reverse proxy is enough
A single reverse proxy on the application VM can be appropriate when:
- the application runs on one VM;
- traffic volume is modest;
- a single-server failure domain is acceptable;
- simple routing is sufficient.
Once multiple application VMs are serving the same workload, a separate load-balancing layer may make more sense.
At that point, continue to Cloud Networking, Private Networks & Load Balancing rather than turning one VM proxy into an accidental multi-server control plane.
Reverse proxy implementation paths
Use the tutorial that matches the chosen proxy:
For framework deployment, continue to Application Deployment on a Linux VM.
Reverse proxy production checklist
Before production:
- DNS points to the intended server;
- only required public ports are open;
- the application listens privately;
- TLS is valid and renews automatically;
- proxy headers are correct;
- application proxy-trust settings are explicit;
- timeouts match the workload;
- WebSocket/streaming behavior is tested where relevant;
- logs are available;
- configuration passes syntax validation before reload;
- the public hostname is checked externally after changes.
Frequently asked questions
What is a reverse proxy?
A reverse proxy receives client requests and forwards them to one or more backend application processes. It can also terminate TLS, route traffic, add forwarding headers, and centralize HTTP policy.
Is Nginx a reverse proxy?
Yes. Nginx can act as a web server, reverse proxy, and load balancer depending on configuration.
Is Caddy a reverse proxy?
Yes. Caddy can reverse-proxy HTTP applications and can automatically manage HTTPS for supported public-hostname configurations.
Do I need a reverse proxy for Node.js or Python?
Not always, but it is a common production pattern because it separates public HTTP/TLS handling from the application process.
Should the application port be public?
Usually no. Bind it to localhost or a private interface when the reverse proxy is the intended public entry point.
Is a reverse proxy the same as a load balancer?
No. They overlap, but a reverse proxy primarily sits in front of application backends while a load balancer specifically distributes traffic across multiple backend instances or servers.
Sources
