역방향 프록시 기초

A reverse proxy is the mirror image of a forward proxy — it sits in front of your servers, intercepting client requests before they reach the real backends.

The key split: a forward proxy fronts clients and hides them; a reverse proxy fronts servers, hides them, and routes requests to the right backend.

A reverse proxy's killer feature is load balancing — spreading incoming requests across multiple backends so no single server gets overwhelmed.

A reverse proxy adds a security layer: clients never touch your backends directly, so their IPs stay hidden and malicious requests get filtered first.

Reverse proxies speed things up with caching — they store static assets like images and CSS and serve them directly, sparing your backends the work.

With SSL/TLS termination, the reverse proxy decrypts HTTPS and forwards plain HTTP to backends — offloading CPU-heavy crypto and centralizing certs.

A request flows in: the client hits the reverse proxy, it picks a backend, forwards the request, then relays that server's response back to the client.

Reverse proxies are everywhere: fronting high-traffic sites, routing microservices, powering CDNs, and serving as the backbone of API gateways.

Picture a blog on Server A and a store on Server B. A reverse proxy at yourdomain.com sends /blog to A and /store to B — clients only ever see the proxy.

Which of the following is a primary benefit of using a reverse proxy for a web application?

Recap: a reverse proxy fronts your servers to add load balancing, security, caching, and SSL termination — the foundation of scalable web apps.