포워드 프록시(Forward Proxy)와 리버스 프록시(Reverse Proxy)의 개념과 실무 활용 - 4
today key : 포워드, 리버스, 프록시, forward, reverse, proxy, 보안, 정책, policy, 통제, 개념
3. 리버스 프록시(Reverse Proxy)
리버스 프록시는 외부 사용자가 내부 서비스(웹/애플리케이션)에 접속할 때, 서버를 대신해 요청을 먼저 받아 처리하는 프록시입니다. 배치 위치는 보통 서비스 입구(Ingress)이며, 클라이언트는 실제 서버(오리진)가 아니라 리버스 프록시의 주소로 접속합니다. 그리고 리버스 프록시가 내부의 실제 서버로 요청을 전달합니다.
리버스 프록시를 두는 목적은 크게 다음 두 가지로 정리할 수 있습니다.
○ 보안/보호 관점: 서비스 앞단에서 공격 트래픽을 걸러내고(접근 제어, WAF, 레이트 리밋 등), 내부 서버를 직접 노출하지 않음
○ 가용성/운영 관점: 서버 풀을 묶어 부하 분산과 장애 대응을 하고(헬스체크/우회), 배포·로그·인증 같은 공통 기능을 입구에서 일괄 처리
3.1 리버스 프록시는 어떻게 작동하는가?
리버스 프록시는 “클라이언트 요청을 앞단에서 받아 필요한 처리를 한 뒤, 내부 서버로 전달하고 응답을 다시 돌려주는 구조”로 동작합니다. 흐름은 다음과 같습니다.
① 클라이언트는 ‘서버’가 아니라 리버스 프록시로 접속한다
클라이언트가 접속하는 도메인(DNS)은 보통 리버스 프록시(또는 그 앞단의 로드밸런서/CDN)를 가리킵니다. 사용자는 그 사실을 의식하지 않고, 평소처럼 도메인으로 접속하면 됩니다. 이때 실제 서버는 내부망에 있고, 외부에서는 직접 접근할 수 없도록 구성하는 경우가 많습니다.
| 참고 |
| 리버스 프록시 뒤에 있는 서버는 클라이언트 IP를 직접 보지 못하는 경우가 많습니다. 그래서 실제 서비스에서는 원본 클라이언트 IP를 전달하기 위해 X-Forwarded-For(또는 Forwarded) 같은 헤더를 함께 사용합니다. 이 값은 보안/감사에도 중요하기 때문에 “누가 헤더를 신뢰할 수 있는가(신뢰 경계)”를 함께 설계합니다. |
② 리버스 프록시는 요청을 받고, 라우팅/정책을 먼저 적용한다
요청이 리버스 프록시에 도착하면, 단순히 서버로 넘기기 전에 서비스 입구에서 처리해야 할 공통 정책을 적용할 수 있습니다. 예를 들면 다음과 같습니다.
- 도메인(Host), 경로(Path) 기반 라우팅(예: /api는 API 서버로, /static은 정적 서버로)
- 인증/인가(SSO 연동, 특정 경로 보호, 토큰 검증 등)
- 레이트 리밋/봇 차단/접근 제어(IP, 국가, 사용자 에이전트 등)'
- WAF 정책 적용(공격 패턴 차단)
- 요청/응답 헤더 정리(보안 헤더 추가, 내부 정보 제거 등)
③ 정책을 통과한 요청만 내부 서버로 전달한다
리버스 프록시는 요청을 내부 서버 풀(업스트림)로 전달합니다. 여기서 흔히 함께 사용되는 기능이 부하 분산과 장애 우회입니다.
- 여러 대의 서버 중 한 대를 선택해 전달(라운드로빈, 최소 연결 등)
- 헬스체크 결과가 나쁜 서버는 자동 제외
- 특정 사용자를 같은 서버로 유지하는 세션 고정(필요한 경우)
④ 응답도 리버스 프록시가 먼저 받고, 필요한 처리를 한 뒤 클라이언트에게 전달한다
내부 서버의 응답은 리버스 프록시로 돌아오며, 프록시는 이를 클라이언트에게 전달하기 전에 다음과 같은 처리를 할 수 있습니다
- 캐시(정적 콘텐츠/자주 조회되는 응답)
- 압축, 커넥션 최적화(keep-alive 등)
- 보안 헤더 추가, 민감 헤더 제거
- 로그 기록(요청/응답, 지연, 상태코드 등)
정리하면, 리버스 프록시는 서비스 입구에서 “요청 수신 → 정책/라우팅 → 내부 전달 → 응답 처리”를 담당하는 계층입니다.