목차5개 항목
출처와 참고
팔만코딩경(42Seoul 커뮤니티 위키)의 「Proxy, Front Proxy, Reverse Proxy란?」을 바탕으로 재구성하고, ByteByteGo의 System Design 101 가이드 「Proxy vs Reverse Proxy」로 보강한 노트다. karanpratapsingh의 「System Design」 강의 저장소를 바탕으로 포워드 프록시의 쓰임과 한계, 리버스 프록시의 단일 장애점, 로드 밸런서와의 차이를 보강했다.
프록시란
프록시(proxy)는 클라이언트와 서버 사이에서 요청을 대신 받아 전달하는 중간 서버다. 대리인이 끼어들면 그 자리에서 캐싱, 접근 정책, 로깅, 주소 감추기를 할 수 있다. 보통 HTTP 같은 응용 계층 메시지를 이해하고 다룬다는 점에서 IP 주소만 바꾸는 NAT와 다르다(비교표는 네트워크 계층 프로토콜).
프록시의 종류는 누구를 대리하느냐로 나뉜다.
포워드 프록시: 클라이언트 쪽에 있음
flowchart LR
c1["클라이언트들"] --> fp["포워드 프록시<br/>서버는 프록시만 본다"] --> i1["인터넷"] --> s1["아무 서버"]리버스 프록시: 서버 쪽에 있음
flowchart LR
c2["아무 클라이언트"] --> i2["인터넷"] --> rp["리버스 프록시<br/>클라이언트는 프록시만 본다"] --> s2["내부 서버들"]| 구분 | 포워드 프록시 (forward, 프런트 프록시) | 리버스 프록시 (reverse) |
|---|---|---|
| 대리하는 쪽 | 클라이언트 | 서버 |
| 설정하는 쪽 | 클라이언트(브라우저·OS 프록시 설정) 또는 네트워크 관리자 | 서비스 운영자. 클라이언트는 프록시가 있는지 모른다 |
| 클라이언트가 접속하는 주소 | 실제 목적지 주소 | 프록시의 주소(서비스 도메인이 프록시를 가리킴) |
| 숨겨지는 것 | 클라이언트의 IP | 내부 서버의 주소와 구성 |
| 쓰임 | 사내 인터넷 접근 통제·감사, 공용 캐시, 지역 제한 우회 | 웹 서버 앞단, API 게이트웨이, CDN |
| 예 | Squid, 기업 보안 게이트웨이 | Nginx, HAProxy, Envoy, Cloudflare |
포워드 프록시는 특정 콘텐츠 차단, 지역 제한(geo-blocking) 우회, 익명성, 그 밖의 접속 제한 우회에 쓰인다. 다만 목적지 서버에 IP를 감출 뿐 프록시 운영자는 사용자의 요청을 모두 볼 수 있고 기록할 수 있다. 직접 운영하면 설정·유지 비용도 든다.
리버스 프록시가 맡는 일
| 기능 | 설명 |
|---|---|
| 로드 밸런싱 | 여러 서버 인스턴스에 요청을 나눈다. 죽은 인스턴스는 헬스 체크로 뺀다 |
| TLS 종료 | 인증서와 암호화를 프록시가 맡고, 내부에서는 평문이나 내부 인증서로 통신한다(HTTPS와 TLS) |
| 내부 구조 은닉 | 앱 서버·DB가 외부에 노출되지 않는다. 앱 서버를 DMZ(내부·외부가 함께 접근하는 구역)에 두지 않아도 된다 |
| 정책 일원화 | 방화벽 규칙, 요청 크기 제한, 속도 제한, WAF를 한곳에서 관리한다 |
| 캐시·압축 | 정적 자원과 캐시 가능한 응답을 직접 응답한다. CDN은 전 세계에 흩어진 리버스 프록시 캐시다(CDN) |
| 경로 라우팅 | /api는 API 서버로, 나머지는 프런트 서버로. 마이크로서비스나 컨테이너 환경에서 서비스 여러 개를 한 도메인 아래 묶는다 |
리버스 프록시를 두면 구성이 복잡해진다. 한 대뿐이면 그 자체가 단일 장애점이 되고, 여러 대로 페일오버를 만들면 복잡도가 더 오른다.
로드 밸런서는 서버가 여러 대일 때 같은 일을 하는 서버들에 나눠 주는 것이 목적이다. 리버스 프록시는 웹 서버가 한 대여도 보안·캐시·TLS 종료를 위해 쓸 만하다. 리버스 프록시는 로드 밸런서 역할을 겸할 수 있지만, 로드 밸런서가 곧 리버스 프록시의 모든 기능을 하지는 않는다.
리버스 프록시, 로드 밸런서, API 게이트웨이는 같은 자리에 서서 기능이 겹친다. 주된 목적으로 구분하면 리버스 프록시는 서버를 숨기고 보호, 로드 밸런서는 고르게 나누기, API 게이트웨이는 API 호출의 라우팅과 정책이다. 비교표는 API 게이트웨이에 있다.
Nginx로 리버스 프록시를 설정하는 예는 웹 서버와 Nginx에 있다.
원래 클라이언트 IP 전달하기
리버스 프록시 뒤의 서버에는 모든 요청이 프록시의 IP에서 온 것처럼 보인다. 그래서 프록시가 원래 정보를 헤더에 담아 넘긴다.
| 헤더 | 뜻 |
|---|---|
X-Forwarded-For | 지나온 클라이언트·프록시 IP 목록. 왼쪽이 원래 클라이언트 |
X-Forwarded-Proto | 원래 요청이 http였는지 https였는지 (TLS 종료 뒤에도 리다이렉트를 바르게 하려고) |
X-Forwarded-Host | 원래 요청의 Host |
Forwarded | 위 정보를 하나로 묶은 표준 헤더(RFC 7239) |
이 헤더는 클라이언트도 마음대로 넣을 수 있다. 신뢰하는 프록시가 붙인 값만 믿는다. 프레임워크의 "trust proxy" 설정에 프록시 개수나 주소를 정확히 지정하지 않으면, 공격자가 IP를 위조해 IP 기반 제한을 우회한다.
VPN과 무엇이 다른가
둘 다 "내 IP 대신 다른 IP로 보이게" 할 수 있지만 계층이 다르다.
| 구분 | 포워드 프록시 | VPN |
|---|---|---|
| 범위 | 프록시를 쓰도록 설정한 앱의 요청(주로 HTTP) | 기기의 모든 IP 트래픽 |
| 계층 | 응용 계층 | 네트워크 계층 터널 |
| 암호화 | 기본은 없음 (HTTPS면 내용만 보호) | 터널 전체를 암호화 |
정리
- 포워드 프록시는 클라이언트를, 리버스 프록시는 서버를 대리한다.
- 리버스 프록시는 로드 밸런싱, TLS 종료, 캐시, 정책 일원화를 한곳에 모은다.
- 뒤쪽 서버는
X-Forwarded-For·Forwarded로 원래 클라이언트를 알지만, 신뢰하는 프록시가 붙인 값만 쓴다.
관련 노트: API 게이트웨이, 로드 밸런서, 웹 서버와 Nginx, 네트워크 계층 프로토콜, CDN, HTTPS와 TLS