웹 서비스를 배포하다 보면 nginx.conf에서 이런 구문을 한 번쯤 봤을 것이다.
처음 보면 “이게 뭐지?” 싶지만, 사실 리버스 프록시(reverse proxy) 설정의 핵심이다.
오늘은 이 리버스 프록시가 무엇을 하는 녀석인지, 왜 꼭 알아야 하는지 쉽게 정리해보겠습니다!
프록시와 리버스 프록시의 차이
먼저 용어부터 정리해볼게요.
‘프록시(proxy)’는 대리인이라는 뜻을 가지고 있어요. 즉, 직접 통신하지 않고 누군가가 대신 요청하거나 응답하는 구조를 말합니다.
| 위치 | 클라이언트 앞단 | 서버 앞단 |
| 역할 | 클라이언트 대신 외부 서버에 요청 | 클라이언트의 요청을 대신 받아 내부 서버로 전달 |
| 주요 목적 | 사용자 익명성, 캐싱, 보안 | 서버 보호, 트래픽 분산, SSL 처리 |
| 예시 | 회사 네트워크 프록시 | Nginx, Apache, HAProxy 등 |
즉,
- 프록시 서버는 “사용자가 외부에 나갈 때 대신 나가주는 서버”
- 리버스 프록시 서버는 “외부 요청이 들어올 때 대신 받아주는 서버”
입니다.
리버스 프록시의 작동 원리
아래 그림처럼 동작합니다.
사용자는 example.com으로 요청을 보냅니다.
하지만 이 요청은 실제 서버(Spring Boot, Node.js 등)로 바로 가지 않아요.
먼저 Nginx가 요청을 받고, 내부적으로 localhost:8080 같은 서버로 전달합니다.
👉 즉, Nginx가 대신 요청을 전달하고 응답을 다시 돌려주는 중간 관리자 역할을 합니다.
Nginx 리버스 프록시 설정 예시
가장 기본적인 설정은 아래와 같습니다.
🔑 proxy_pass
클라이언트가 example.com에 요청하면, 실제 내부 서버 localhost:8080으로 요청을 전달합니다.
이렇게 하면 외부에서는 내부 서버 주소를 전혀 알 수 없어요.
proxy_set_header는 클라이언트의 실제 IP 등을 백엔드로 전달하기 위한 설정이에요.
이걸 안 하면 백엔드 서버에서는 모든 요청이 127.0.0.1에서 온 것처럼 보일 수도 있습니다.
왜 리버스 프록시를 써야 할까?
- 보안 강화
내부 서버 주소(localhost:8080 등)가 외부에 노출되지 않아요.
모든 요청이 Nginx를 거쳐 들어오기 때문에 방어선 역할을 합니다. - 부하 분산 (로드 밸런싱)
여러 대의 서버를 두고 트래픽을 분산시킬 수 있습니다.
👉 proxy_pass 뒤에 여러 서버를 두거나 upstream 블록을 이용하면 가능해요. - SSL(HTTPS) 처리
SSL 인증서를 각 서버마다 설치하는 대신, Nginx 한 곳에서 통합 관리 가능.
즉, HTTPS 종료 지점(TLS termination point) 으로 활용할 수 있습니다. - 정적 파일 캐싱
이미지, CSS, JS 같은 정적 리소스를 Nginx가 캐싱해두면
백엔드 서버 부하를 크게 줄일 수 있습니다.
실제로는 어디에 쓰일까?
리버스 프록시는 대부분의 실제 서비스 배포 구조에서 기본값처럼 쓰입니다.
예를 들어 AWS EC2에 Spring Boot 애플리케이션을 올린다고 할 때:
- Nginx는 80/443 포트를 열고 HTTPS 요청을 처리
- Spring Boot는 내부적으로 8080 포트에서 동작
- Nginx가 모든 요청을 내부 포트로 라우팅
이렇게 하면 HTTPS 인증서, CORS, 로드 밸런싱 등 관리가 쉬워집니다.
한 줄 정리
리버스 프록시 = 서버 앞단의 문지기
내부 서버를 대신해 요청을 받고, 필요한 곳으로 트래픽을 안전하고 효율적으로 전달한다.
다음 포스팅
- [실전] Spring Boot + Nginx 리버스 프록시 설정 가이드
- [보안] Let's Encrypt로 무료 HTTPS 인증서 적용하기
- [운영] Nginx 로그와 캐싱을 활용한 트래픽 최적화

'DevOps' 카테고리의 다른 글
| [AWS] Amazon Q Developer + MCP 환경 구성 방법 (0) | 2026.01.05 |
|---|---|
| [DevOps] AWS EC2에 대해 알아보자 (9) | 2025.08.13 |
| [Docker] 로컬에서 Docker 이미지 빌드하고 서버에서 실행하기 (0) | 2025.07.02 |