← Back to glossary

Reverse Proxy

A reverse proxy is a server that sits between the client (browser) and the backend server (application). It receives incoming requests, forwards them to the responsible backend service and returns the response to the client. Unlike a forward proxy (which protects the client), a reverse proxy protects the server and provides additional features like Caching , load balancing and SSL termination.

Why a reverse proxy in front of the application server?

Application servers (Django/Gunicorn, Node.js, PHP-FPM) are optimized for processing application logic, not for efficiently serving static files or handling thousands of simultaneous connections. A reverse proxy like Nginx or Apache handles: static file delivery, SSL Certificate termination, compression (gzip/brotli), request buffering and Rate Limiting .

Security features of a reverse proxy

The reverse proxy hides the internal server structure from the internet. Backend ports and services are not directly reachable. Additional security measures: setting Content-Security-Policy and other security headers. Request filtering against known attack patterns. IP-based access restrictions. DDoS mitigation through connection limiting. These measures are an essential part of Server Hardening .

Reverse proxy and container architectures

In Containerization environments, the reverse proxy serves as the entry point (ingress): Traefik or Nginx routes incoming requests based on hostnames or URL paths to the responsible containers. In Kubernetes clusters, an Ingress Controller takes on this role. For local development with Docker Compose, an Nginx container defines the routing between frontend, backend and static services.

Nginx vs. Apache as reverse proxy

Nginx: event-based, high concurrency, low memory footprint. Preferred for reverse proxy scenarios and static file delivery. Apache: process-/thread-based, powerful .htaccess configuration, proven mod_proxy. Both are suitable as reverse proxies – the choice depends on existing infrastructure and expertise. For optimal PageSpeed , configuration matters more than the choice of tool.

How we use it

For btech-solutions.eu, we use Apache with .htaccess as the reverse proxy: SSG rewrite rules serve prerendered HTML files directly, security headers (CSP, HSTS, Permissions-Policy) are set centrally, and gzip compression reduces transfer size. For containerized Django backends, we deploy Nginx as a proxy in front of Gunicorn. The entire configuration is versioned as Infrastructure as Code and automatically deployed via CI/CD .