1. What Is a Reverse Proxy?

A reverse proxy is a server that receives requests from clients and forwards them to one or more backend servers. Instead of connecting directly to an application server, users connect to the reverse proxy first.

The reverse proxy decides where each request should go based on rules such as the requested hostname, URL path, or backend availability.

User's Browser
      |
      v
Reverse Proxy (Nginx)
      |
      +--------> Web Application Server 1
      |
      +--------> Web Application Server 2
      |
      +--------> API Server
        

For example, a website might use Nginx to receive public HTTPS traffic and forward requests to a React frontend, a Node.js API, or another internal application.

2. How Does a Reverse Proxy Work?

1. A user opens a website in a browser.
2. The browser connects to the reverse proxy's public address.
3. The reverse proxy receives the HTTP or HTTPS request.
4. It selects the appropriate backend using its routing rules.
5. The backend processes the request and returns a response.
6. The reverse proxy sends the response back to the user.

Users normally see the public website address, not the internal addresses of the backend servers.

Example: A company could configure example.com to serve its website, example.com/api to route API requests, and admin.example.com to route requests to an administration application.

3. What Is Nginx?

Nginx is a web server that can also act as a reverse proxy, load balancer, and HTTP cache. It is commonly used in front of web applications to receive client requests and forward them to application servers.

Common Nginx reverse proxy features

• Request routing: Forward requests to the correct backend.
• TLS termination: Handle HTTPS encryption at the proxy.
• Load balancing: Distribute requests across multiple backend servers.
• Caching: Store eligible responses to reduce repeated backend work.
• Access controls: Restrict access according to configured rules.
• Request logging: Record useful information for troubleshooting and monitoring.

4. Reverse Proxy Architecture

                   Internet
                      |
                      v
             Public HTTPS Request
                      |
                      v
              +---------------+
              | Nginx Proxy   |
              | TLS + Routing |
              +---------------+
                 /         \
                v           v
        +-------------+  +-------------+
        | Web App     |  | API Server  |
        | Port 3000   |  | Port 5000   |
        +-------------+  +-------------+
                \           /
                 v         v
                 Database or
              Internal Services
        

In this example, Nginx is the public entry point. The application servers can run on private interfaces or internal network addresses, depending on the deployment design.

A reverse proxy does not replace the application, database, firewall, or authentication system. It is one component in the overall architecture.

5. What Is TLS Termination?

TLS is the protocol used to secure HTTPS connections. TLS termination means the reverse proxy handles the incoming TLS connection, decrypts the request, and then forwards the request to a backend.

Browser
  |
  | HTTPS (encrypted)
  v
Nginx Reverse Proxy
  | TLS termination
  |
  | HTTP on a trusted private network
  v
Backend Application
        

This can simplify certificate management because certificates can be configured at the reverse proxy rather than separately on every application server.

Important: If traffic between the proxy and backend travels over an untrusted network, use HTTPS or another suitable protected connection for that internal leg too. TLS termination does not automatically encrypt every connection beyond the proxy.

6. How to Configure a Basic Nginx Reverse Proxy

Imagine a web application running on the same machine as Nginx, listening on port 3000. Nginx will receive requests for example.com and forward them to that application.

server {
    listen 80;
    server_name example.com;

    location / {
        proxy_pass http://127.0.0.1:3000;

        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}
        

What do these directives do?

• listen 80; — listens for HTTP connections on port 80.
• server_name example.com; — matches requests for this hostname.
• location / — applies the rules to requests under this path.
• proxy_pass — forwards the request to the backend application.
• proxy_set_header Host $host; — passes the requested hostname to the backend.
• X-Real-IP and X-Forwarded-For — pass client IP information through the proxy.
• X-Forwarded-Proto — indicates the original request scheme, such as HTTP or HTTPS.

This is a basic HTTP example, not a complete production HTTPS configuration. A real deployment should configure TLS certificates, redirect HTTP to HTTPS where appropriate, validate the configuration, and protect the backend from direct public access.

7. Routing Requests to Different Applications

A reverse proxy can direct requests to different backend applications according to the hostname or URL path.

server {
    listen 80;
    server_name example.com;

    location / {
        proxy_pass http://127.0.0.1:3000;
    }

    location /api/ {
        proxy_pass http://127.0.0.1:5000/;
    }
}
        

In this example, requests to the root path are directed to the web application, while requests under /api/ are directed to the API service. The trailing slash in a proxy_pass URL can affect how the URI is forwarded, so test the exact paths your application expects.

For more complex systems, you may route by subdomain, such as api.example.com, or use separate server blocks for different applications.

8. Reverse Proxy vs Forward Proxy vs Load Balancer

A reverse proxy can also perform load-balancing functions. These terms describe roles, so one product may provide more than one of them.

9. Reverse Proxy Security Best Practices

• Use valid TLS certificates and modern TLS settings.
• Keep Nginx and the operating system updated.
• Restrict direct public access to backend application ports.
• Configure trusted proxy handling for forwarded headers; do not blindly trust client-supplied IP headers.
• Apply suitable request-size, timeout, and rate-limiting policies for your application.
• Use authentication and authorization for private or administrative routes.
• Monitor logs and investigate repeated failures or suspicious traffic.
• Use a web application firewall when it fits the application's risk and deployment requirements.

A reverse proxy can improve the security architecture, but it does not automatically make an application secure. Application vulnerabilities, weak credentials, and incorrect access rules still need to be addressed.

10. Common Real-World Use Cases

• Websites: Route public traffic to one or more web servers.
• APIs: Forward API requests to the correct service.
• Microservices: Provide a controlled entry point for multiple services.
• HTTPS management: Centralize certificate configuration and TLS handling.
• Caching: Cache eligible responses to reduce repeated work.
• Application scaling: Work with load balancing to distribute requests.

11. Quick Quiz

12. Key Takeaways

• A reverse proxy sits between clients and backend servers.
• Nginx can provide reverse proxying, routing, caching, and load balancing.
• TLS termination centralizes incoming HTTPS handling.
• Routing rules can direct requests by hostname or URL path.
• Backend ports should be protected from unnecessary public access.
• Reverse proxies are useful, but they are only one part of a secure and reliable application architecture.