Proxy & Reverse Proxy

A proxy is a server that sits between two things and handles traffic on behalf of one of them. The direction determines what kind of proxy it is.

Forward Proxy (Client-Side)

A forward proxy sits in front of clients. The client sends requests to the proxy, and the proxy forwards them to the internet. The destination server only sees the proxy’s IP address, not the client’s.

Real-world examples we already use:

• VPNs — route all our traffic through another server, hiding our real IP
• Corporate proxies — companies route employee traffic through a proxy to filter content, block sites, and log activity
• Tor — bounces traffic through multiple proxies for anonymity

The client knows it’s using a proxy. The server doesn’t know (or care).

Reverse Proxy (Server-Side)

A reverse proxy sits in front of servers. The client sends requests to the reverse proxy thinking it’s the actual server. The reverse proxy then decides which backend server should handle the request.

The client doesn’t know a reverse proxy exists. It just talks to api.example.com and gets a response. Behind that domain, there could be 50 servers — the reverse proxy manages all of it.

Why Reverse Proxies Are Everywhere

Almost every production web app sits behind a reverse proxy. Here’s why:

• SSL termination — the reverse proxy handles HTTPS encryption/decryption, so backend servers deal with plain HTTP (simpler and faster)
• Load balancing — distribute traffic across multiple backend servers
• Caching — cache static assets and repeated responses, reducing load on backends
• Security — hide internal server IPs, add rate limiting, block malicious requests
• Compression — gzip responses before sending them to clients

Nginx as a Reverse Proxy

Nginx is the most popular reverse proxy for web apps. Here’s a basic config that proxies requests to a Node.js backend.

server {
    listen 80;
    server_name api.example.com;

    location / {
        # Forward all requests to our Node app on port 3000
        proxy_pass http://localhost:3000;

        # Pass the original client info to the backend
        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;
    }
}

Without those proxy_set_header lines, our backend would think every request comes from 127.0.0.1 (the proxy itself). The headers pass through the real client information.

Dev Proxies (Avoiding CORS During Development)

This is one we hit all the time in frontend development. Our React app runs on localhost:5173 but the API is on localhost:3000. Browsers block cross-origin requests — but we can fix this with a dev proxy.

// vite.config.js
export default {
  server: {
    proxy: {
      // Any request to /api/* gets forwarded to port 3000
      '/api': {
        target: 'http://localhost:3000',
        changeOrigin: true,
        rewrite: (path) => path.replace(/^\/api/, '')
      }
    }
  }
}

Now fetch('/api/users') from our React app hits http://localhost:3000/users under the hood. The browser thinks it’s same-origin, so no CORS issues. This is technically a forward proxy built into our dev server.

CDN as a Reverse Proxy

A CDN (Cloudflare, CloudFront, Fastly) is just a globally distributed reverse proxy. Users hit the CDN’s edge server closest to them. If the edge has a cached copy, it responds immediately. If not, it fetches from our origin server, caches the response, and serves it.

The user never talks to our server directly — the CDN handles everything in between.

In simple language, a forward proxy hides who the client is, a reverse proxy hides who the server is — and almost everything in production sits behind a reverse proxy for SSL, load balancing, and security.