[Daily morning study] 프록시 서버와 리버스 프록시 동작 방식

in Daily morning study / Network

#daily morning study

Image

프록시 서버란

프록시(Proxy)는 ‘대리인’이라는 뜻 그대로, 클라이언트와 서버 사이에서 요청/응답을 중계하는 중간 서버다.

클라이언트가 직접 목적지 서버에 연결하는 대신, 프록시 서버를 거쳐 통신한다. 이 구조 덕분에 다양한 부가 기능(캐싱, 필터링, 익명화 등)을 중간 계층에서 처리할 수 있다.

포워드 프록시 (Forward Proxy)

포워드 프록시는 클라이언트 쪽에 위치하는 프록시다.

클라이언트 → [포워드 프록시] → 인터넷 → 목적지 서버

목적지 서버 입장에서는 실제 클라이언트의 IP를 모른다. 프록시 서버의 IP만 보인다.

주요 용도

1. 익명성 확보

클라이언트의 실제 IP를 숨긴다. 목적지 서버에는 프록시 IP가 노출되므로 클라이언트를 특정할 수 없다.

2. 접근 제어 / 콘텐츠 필터링

기업이나 학교 네트워크에서 특정 사이트 차단 용도로 사용한다. 모든 아웃바운드 트래픽이 프록시를 거치기 때문에 중앙에서 정책을 적용하기 쉽다.

3. 캐싱

동일한 리소스를 반복적으로 요청할 때, 프록시가 응답을 캐시해 두고 재사용한다. 외부 대역폭 절약과 응답 속도 향상 효과가 있다.

4. 지역 우회

특정 국가에서 차단된 콘텐츠에 다른 지역 프록시를 통해 접근할 수 있다. VPN과 비슷한 원리지만 프록시는 애플리케이션 레벨에서만 동작한다.

리버스 프록시 (Reverse Proxy)

리버스 프록시는 서버 쪽에 위치하는 프록시다.

클라이언트 → 인터넷 → [리버스 프록시] → 내부 서버들

클라이언트 입장에서는 리버스 프록시가 곧 서버처럼 보인다. 내부에 실제 서버가 몇 대 있는지, 어떤 구조인지 알 수 없다.

포워드 vs 리버스 핵심 차이

구분포워드 프록시리버스 프록시
위치클라이언트 측서버 측
숨기는 대상클라이언트 (내부 사용자)서버 (내부 인프라)
주요 목적익명성, 필터링, 우회로드 밸런싱, 보안, 캐싱
설정 주체클라이언트/네트워크 관리자서버/인프라 관리자

주요 용도

1. 로드 밸런싱

가장 흔한 용도다. 여러 대의 백엔드 서버에 트래픽을 분산한다. Nginx, HAProxy 같은 도구가 이 역할을 한다.

클라이언트 → Nginx (리버스 프록시)
                ├─ 백엔드 서버 1 (10.0.0.1:8080)
                ├─ 백엔드 서버 2 (10.0.0.2:8080)
                └─ 백엔드 서버 3 (10.0.0.3:8080)

2. SSL/TLS 종단 (SSL Termination)

HTTPS 처리를 리버스 프록시에서 전담한다. 백엔드 서버는 평문 HTTP로 통신해도 되므로 CPU 부하를 줄일 수 있다.

클라이언트 --HTTPS--> 리버스 프록시 --HTTP--> 백엔드 서버

인증서 관리도 프록시 한 곳에서만 하면 된다.

3. 캐싱

정적 파일(이미지, CSS, JS)이나 API 응답을 캐시해 두고 백엔드까지 요청이 도달하지 않게 한다.

4. 내부 인프라 보호

백엔드 서버의 IP, 포트, 구조를 외부에 노출하지 않는다. 공격자가 직접 백엔드를 타겟하기 어렵다. WAF(Web Application Firewall) 기능을 함께 붙이는 경우도 많다.

5. 압축

응답을 gzip/brotli로 압축해서 전송한다. 백엔드에서 압축 처리를 하지 않아도 된다.

Nginx 리버스 프록시 설정 예시

server {
    listen 80;
    server_name example.com;

    location / {
        proxy_pass http://backend_pool;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

upstream backend_pool {
    server 10.0.0.1:8080;
    server 10.0.0.2:8080;
    server 10.0.0.3:8080;
}

X-Real-IP와 X-Forwarded-For 헤더를 백엔드로 넘겨야 백엔드가 실제 클라이언트 IP를 알 수 있다. 프록시를 거치면 백엔드에서 보이는 IP가 프록시 IP가 되기 때문이다.

X-Forwarded-For 헤더

리버스 프록시를 쓰면 백엔드 서버는 클라이언트 IP 대신 프록시 IP를 받는다. 이 문제를 해결하기 위해 X-Forwarded-For 헤더에 원본 IP를 담아서 전달한다.

X-Forwarded-For: 203.0.113.10, 192.168.1.1

왼쪽이 원래 클라이언트 IP고, 오른쪽으로 갈수록 거쳐온 프록시 IP가 추가된다. 단, 이 헤더는 클라이언트가 임의로 조작할 수 있으므로 신뢰 구간을 잘 설정해야 한다.

CDN도 리버스 프록시의 일종

CDN(Content Delivery Network)은 전 세계 엣지 서버에 콘텐츠를 캐시해두는 구조다. 클라이언트는 지리적으로 가장 가까운 CDN 노드에 접속하고, CDN 노드가 원본 서버(Origin)에서 콘텐츠를 가져와 캐시한다.

본질적으로는 전 세계에 분산된 리버스 프록시 + 캐싱 레이어다.

사용자(서울) → CDN 엣지(서울) → Origin 서버
사용자(뉴욕) → CDN 엣지(뉴욕) → (캐시 히트 시 Origin 불필요)

프록시와 VPN의 차이

구분프록시VPN
동작 레벨애플리케이션 레벨 (HTTP 등)네트워크 레벨 (IP 전체)
암호화선택적 (HTTPS 프록시는 됨)기본 제공
적용 범위특정 앱/브라우저만OS 전체 트래픽
속도상대적으로 빠름암호화 오버헤드 있음

VPN은 OS 수준에서 전체 트래픽을 터널링하고 암호화까지 하는 반면, 프록시는 특정 프로토콜/앱의 트래픽만 중계한다.

정리

  • 포워드 프록시: 클라이언트 대신 요청, 클라이언트 IP 숨김, 필터링·우회·캐싱
  • 리버스 프록시: 서버 앞단에서 요청 수신, 내부 인프라 보호, 로드 밸런싱·SSL 종단·캐싱
  • Nginx, HAProxy, Envoy 등이 리버스 프록시로 많이 사용됨
  • CDN은 전 세계에 분산된 리버스 프록시+캐시 구조
  • 프록시를 거치면 실제 클라이언트 IP가 가려지므로 X-Forwarded-For 헤더로 보완