Forward Proxy vs Reverse Proxy: Differences Explained with Examples

A proxy is a server that sits between a client and another server and passes messages between them. There are two main kinds. A forward proxy works on behalf of the clients, and a reverse proxy works on behalf of the servers. They look alike on a diagram, but they solve very different problems, and nearly every large web system uses at least one of them.

This tutorial explains what each proxy does, how a request flows through it, where each one is used, and how they compare side by side. You will also see Java code that sends traffic through a forward proxy, a small reverse proxy built with Spring Boot, and an Nginx configuration you can use as a starting point.

1. What Is a Proxy Server?

The word proxy means "someone who acts on behalf of another person". If you cannot attend a meeting, you might send a colleague as your proxy to vote for you. In networking, a proxy server does the same job: it receives a request, sends it on to the real destination for someone else, and returns the answer.

Because every message passes through it, a proxy is a natural place to add extra behaviour, such as:

• Hiding identity: the other side sees the proxy's address instead of the real sender or receiver.
• Filtering: blocking requests that break a rule.
• Caching: keeping copies of responses so repeat requests are answered faster.
• Logging and monitoring: recording who accessed what, and when.
• Security: inspecting traffic and stopping attacks before they reach their target.

The key question that separates the two proxy types is simple: whose side is the proxy on? A forward proxy belongs to the clients. A reverse proxy belongs to the servers.

2. What Is a Forward Proxy?

A forward proxy sits in front of a group of clients, such as the computers in an office or a school. When any of those clients wants to reach a website, the request goes to the forward proxy first. The proxy then contacts the website on the client's behalf and passes the response back.

From the website's point of view, every request comes from the proxy. The website does not know which laptop or phone actually asked for the page.

3. How a Forward Proxy Works

Suppose an employee opens https://news-site.com on a company laptop that is configured to use a forward proxy:

1. The client sends the request to the proxy. The browser knows the proxy's address because it was set in the operating system, the browser settings, or a configuration script provided by the company.
2. The proxy checks its rules. It may confirm that the user is logged in, that the website is not on a block list, and that the request is allowed at this time.
3. The proxy may answer from its cache. If someone in the office requested the same public file a moment ago and it can be reused, the proxy returns its stored copy.
4. Otherwise, the proxy contacts the website. It opens its own connection to news-site.com. The website sees the proxy's IP address as the sender.
5. The response travels back the same way. The website replies to the proxy, the proxy may log or scan the response, and then it passes the response to the laptop.

For HTTPS sites, the browser usually asks the proxy to open a tunnel with the HTTP CONNECT method. The proxy then relays encrypted bytes without reading them. It knows which website the client is visiting, but not what is inside the pages, unless the company has installed its own certificate on every device to inspect the traffic.

4. Common Uses of a Forward Proxy

• Content filtering: schools and companies block categories of websites, such as gambling or malware sites.
• Privacy: the destination sees the proxy's address instead of the user's real IP address. Anonymous proxies and many VPN-style services rely on this idea.
• Shared caching: when hundreds of people download the same software update, the proxy can fetch it once and serve the rest from its cache, saving internet bandwidth.
• Controlled outbound access: servers in a locked-down data centre are often not allowed to reach the internet directly. They must go through an approved forward proxy, so every outbound call is logged and checked.
• Accessing region-specific content: a proxy located in another country makes the request look as if it came from that country. Testers use this to check how a site behaves in different regions.
• Auditing: security teams can see which external services each machine talks to.

5. What Is a Reverse Proxy?

A reverse proxy sits in front of a group of servers. Users on the internet think they are talking directly to your website, but they are really talking to the reverse proxy. The proxy decides which backend server should handle each request, forwards it, and returns the response to the user.

This time it is the servers that are hidden. Users never learn how many servers you run, what their internal addresses are, or which one handled their request.

6. How a Reverse Proxy Works

Imagine a user opens https://www.shop.com/products/42, and the domain points to a reverse proxy:

1. DNS points to the proxy. The domain name resolves to the public IP address of the reverse proxy, not to any application server.
2. The proxy terminates HTTPS. It holds the website's TLS certificate, decrypts the request, and can now read the URL and headers.
3. The proxy applies its rules. It may reject a request from a blocked IP, enforce a rate limit, or return a cached copy of the page if one is still fresh.
4. The proxy picks a backend. Based on the path (/products goes to the product service), the load-balancing algorithm, and the health of each server, it chooses where to send the request.
5. The proxy forwards the request. It usually adds headers such as X-Forwarded-For so the backend still knows the user's real IP address.
6. The response returns through the proxy. The proxy can compress it, add security headers, store it in its cache, and then send it to the user.

The user's browser only ever talks to the proxy. If App Server 2 crashes, the proxy stops sending traffic to it, and users do not notice.

7. Common Uses of a Reverse Proxy

• Load balancing: spreading requests across several servers so no single server is overwhelmed.
• SSL/TLS termination: handling the costly encryption work in one place, so backend servers can focus on business logic and certificates are managed centrally.
• Caching: storing responses for pages and files that many users request, which lowers load on the application.
• Compression: shrinking responses with gzip or Brotli before they leave the data centre.
• Security shield: backend servers have no public IP, so attackers cannot reach them directly. The proxy can also run a Web Application Firewall (WAF) and absorb some denial-of-service traffic.
• Path-based routing: sending /api to one service, /images to object storage and everything else to the web front end, all under one domain.
• Zero-downtime deployments: moving traffic gradually from the old version of an application to the new one.

Popular reverse proxies include Nginx, HAProxy, Envoy, Traefik, Apache HTTP Server, and the edge servers of CDN providers.

8. Forward vs Reverse Proxy: The One-Picture Difference

Both proxies sit in the middle of a client-to-server conversation. The difference is which side owns the proxy, and therefore who gets hidden.

A handy way to remember it: a forward proxy pushes your requests forward out into the internet; a reverse proxy receives requests coming in the reverse direction, from the internet into your servers.

9. Comparison Table

10. Calling the Internet Through a Forward Proxy in Java

Many companies require backend services to reach external APIs only through an approved forward proxy. Java's built-in HttpClient (Java 11+) supports this with a ProxySelector. The example below sends every request through a proxy at proxy.company.local:3128.

package com.javabytechie.proxy;

import java.net.InetSocketAddress;
import java.net.ProxySelector;
import java.net.URI;
import java.net.http.HttpClient;
import java.net.http.HttpRequest;
import java.net.http.HttpResponse;
import java.time.Duration;

public class ForwardProxyClient {

    public static void main(String[] args) throws Exception {
        // All requests made by this client go to the forward proxy first
        HttpClient client = HttpClient.newBuilder()
                .proxy(ProxySelector.of(new InetSocketAddress("proxy.company.local", 3128)))
                .connectTimeout(Duration.ofSeconds(5))
                .build();

        HttpRequest request = HttpRequest.newBuilder()
                .uri(URI.create("https://api.example.com/status"))
                .timeout(Duration.ofSeconds(10))
                .GET()
                .build();

        HttpResponse<String> response = client.send(request, HttpResponse.BodyHandlers.ofString());

        System.out.println("Status: " + response.statusCode());
        System.out.println("Body:   " + response.body());
    }
}

Status: 200
Body:   {"service":"example-api","state":"UP"}

The external API sees the proxy's IP address, not your server's. If you prefer not to change code, you can set the proxy for the whole JVM with system properties instead. The nonProxyHosts list makes internal addresses bypass the proxy:

java -Dhttps.proxyHost=proxy.company.local -Dhttps.proxyPort=3128 \
     -Dhttp.proxyHost=proxy.company.local  -Dhttp.proxyPort=3128 \
     -Dhttp.nonProxyHosts="localhost|*.internal.company.local" \
     -jar order-service.jar

Java's HttpClient picks up these JVM-wide properties automatically when no proxy is set on the builder, because it falls back to ProxySelector.getDefault(). Some third-party libraries behave differently. For example, Apache HttpClient 5 ignores them unless you build the client with useSystemProperties(), so always check how your HTTP library finds its proxy.

11. Building a Tiny Reverse Proxy with Spring Boot

To see what a reverse proxy really does, here is a minimal one written with Spring Boot 3. It accepts requests on port 8080 and forwards anything under /api/ to a backend running on port 8081, adding the standard forwarding headers. This is for learning only. In production you would use Nginx, HAProxy, Envoy or Spring Cloud Gateway, which handle streaming, timeouts, retries and errors properly.

package com.javabytechie.proxy;

import jakarta.servlet.http.HttpServletRequest;
import org.springframework.http.ResponseEntity;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;
import org.springframework.web.client.RestClient;

@RestController
public class ReverseProxyController {

    // The hidden backend: users never see this address
    private final RestClient backend = RestClient.create("http://localhost:8081");

    @GetMapping("/api/**")
    public ResponseEntity<String> forward(HttpServletRequest request) {
        String path = request.getRequestURI();
        String query = request.getQueryString();
        String target = (query == null) ? path : path + "?" + query;

        return backend.get()
                .uri(target)
                // Tell the backend who the real client is
                .header("X-Forwarded-For", request.getRemoteAddr())
                .header("X-Forwarded-Proto", request.getScheme())
                .header("X-Forwarded-Host", request.getServerName())
                .retrieve()
                .toEntity(String.class);
    }
}

The backend service can read those headers to learn the original client address:

package com.javabytechie.backend;

import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.PathVariable;
import org.springframework.web.bind.annotation.RequestHeader;
import org.springframework.web.bind.annotation.RestController;

@RestController
public class ProductController {

    @GetMapping("/api/products/{id}")
    public String product(@PathVariable long id,
                          @RequestHeader(value = "X-Forwarded-For", required = false) String clientIp) {
        return "Product " + id + " served by backend on port 8081 for client " + clientIp;
    }
}

Product 42 served by backend on port 8081 for client 203.0.113.25

In real Spring Boot applications that sit behind a proxy, set server.forward-headers-strategy=framework (or native when running on Tomcat, Jetty or Undertow). Spring then uses the forwarded headers when building redirect URLs and when you call request.getRemoteAddr(), so links and logs show the user's details instead of the proxy's. Only trust these headers when they come from your own proxy, because any client can send a fake X-Forwarded-For.

12. Reverse Proxy Configuration Example with Nginx

Nginx is one of the most widely used reverse proxies. This configuration terminates HTTPS, balances traffic across two Spring Boot instances, and passes the forwarding headers:

upstream shop_backend {
    server 10.0.1.11:8080;
    server 10.0.1.12:8080;
}

server {
    listen 443 ssl;
    server_name www.shop.com;

    ssl_certificate     /etc/ssl/shop/fullchain.pem;
    ssl_certificate_key /etc/ssl/shop/privkey.pem;

    location /api/ {
        proxy_pass http://shop_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;
        proxy_connect_timeout 3s;
        proxy_read_timeout    30s;
    }

    location /static/ {
        root /var/www/shop;
        expires 7d;
    }
}

Requests for /static/ are served straight from disk by Nginx, while /api/ requests are spread across the two application servers. The backends at 10.0.1.11 and 10.0.1.12 live on a private network and have no public IP address.

13. Reverse Proxy vs Load Balancer vs API Gateway

These three terms overlap, which often confuses beginners. They are best understood as layers of features:

In practice, a single product such as Nginx or Envoy can play all three roles. Network load balancers that work at the TCP level (layer 4) are a partial exception: they forward packets or connections without reading HTTP, so they cannot route by URL path.

14. Other Proxy Types You May Hear About

• Transparent proxy: a forward proxy that intercepts traffic without any client configuration. Public Wi-Fi networks and some internet providers use them. The client may not even know it exists.
• Anonymous proxy: a forward proxy that deliberately removes identifying headers so the destination cannot find the user's real IP address.
• SOCKS proxy: works at a lower level than HTTP and can relay any kind of TCP traffic, such as database or email connections.
• Sidecar proxy: in a service mesh, a small proxy such as Envoy runs next to each microservice and handles both its inbound traffic (reverse proxy role) and its outbound calls (forward proxy role).
• Egress gateway: a cloud or Kubernetes component that acts as a forward proxy for all outbound traffic leaving a cluster.

15. Common Mistakes to Avoid

• Trusting X-Forwarded-For from anyone. A user can send this header themselves. Only accept it when the request came from your own proxy, otherwise rate limits and IP blocks can be bypassed.
• Running a single reverse proxy. If every request flows through one proxy and it fails, the whole site is down. Run at least two instances behind a floating IP or a cloud load balancer.
• Leaving backends reachable from the internet. If the application servers still have public IPs, attackers can skip the proxy and its protections entirely.
• Creating an open forward proxy. A forward proxy that accepts requests from anyone on the internet will quickly be abused to hide attacks and spam. Always restrict who can use it.
• Caching private data. A reverse proxy that caches responses must never store pages containing one user's personal data and serve them to another user.
• Forgetting timeouts. Without connect and read timeouts, slow backends tie up proxy connections until the proxy itself stops responding.

16. Best Practices

• Decide the purpose first: use a forward proxy to control outbound traffic and a reverse proxy to protect and scale inbound traffic.
• Run reverse proxies in pairs or clusters, and use health checks so failed backends are removed automatically.
• Terminate TLS at the reverse proxy, and use TLS again between the proxy and backends when the internal network is not fully trusted.
• Configure your application framework to understand forwarded headers, and restrict which proxy addresses are trusted.
• Set sensible timeouts, request size limits and rate limits on the proxy.
• Add security headers such as Strict-Transport-Security in one place at the reverse proxy.
• Log and monitor proxy metrics: request rate, error rate, latency and upstream health.
• For forward proxies, require authentication and keep allow lists of approved external destinations.

17. Summary

• A proxy is a middle server that passes requests and responses on behalf of someone else.
• A forward proxy works for clients. It controls and hides outbound traffic, and destinations only see the proxy.
• A reverse proxy works for servers. It receives inbound traffic, hides the backends, and adds load balancing, TLS termination, caching and security.
• Clients usually configure a forward proxy themselves, while a reverse proxy is invisible to them because DNS points straight to it.
• Load balancers and API gateways are specialised reverse proxies.

Once you can answer "whose side is the proxy on?", you can tell the two apart in any architecture diagram. Open the FAQ tab for answers to common questions about forward and reverse proxies.

Frequently Asked Questions (FAQ)