도입
서비스를 운영하다 보면 클라이언트가 직접 애플리케이션 서버에 붙지 않게 해야 하는 경우가 많다.
이때 가장 많이 쓰는 구조가 Reverse Proxy다. 앞단에서 요청을 받고, 뒤쪽 서버로 대신 전달하는 방식이다.
처음에는 단순 중계처럼 보이지만 실무에서는 보안, SSL, 로드밸런싱, 캐시 처리의 시작점이 된다.
핵심 개념 설명
Reverse Proxy는 사용자 앞에 있는 프록시 서버다. 사용자는 실제 백엔드 서버 주소를 직접 알지 못한다.
클라이언트는 Reverse Proxy에 요청을 보내고, Reverse Proxy가 내부 서버에 요청을 전달한 뒤 결과를 다시 응답한다.
중요한 점은 프록시의 위치다. Forward Proxy는 클라이언트 쪽, Reverse Proxy는 서버 쪽에 놓인다.
- 클라이언트가 보는 대상: Reverse Proxy
- 실제 요청을 처리하는 대상: 내부 웹 서버 또는 앱 서버
- 대표 도구: Nginx, Apache, HAProxy, Envoy
동작 원리 또는 구조
구조는 단순하다. 외부 요청을 프록시가 먼저 받고, 내부 서버로 전달한다.
flowchart LR
A[Client Browser] --> B[Reverse Proxy]
B --> C[Web Server 1]
B --> D[Web Server 2]
B --> E[App Server]
C --> B
D --> B
E --> B
B --> A
사용자는 Reverse Proxy와만 통신한다. 내부 서버는 외부에 직접 노출되지 않는다.
이 구조를 쓰는 이유는 명확하다. 접점 하나에서 공통 처리를 묶을 수 있기 때문이다.
구조 안에서 Reverse Proxy가 하는 일
1. 요청 라우팅
URL 경로나 도메인 기준으로 어느 서버에 보낼지 결정한다.
예를 들어 /api는 백엔드로,
/는 프론트 정적 파일 서버로 보낼 수 있다.
server {
listen 80;
server_name example.com;
location / {
proxy_pass http://frontend_server;
}
location /api/ {
proxy_pass http://backend_server;
}
}
2. SSL 종료
HTTPS 처리를 Reverse Proxy에서 끝내는 경우가 많다. 내부 서버는 HTTP로만 운영하는 방식이다.
이렇게 하면 인증서 관리 지점이 하나로 줄어든다. 서버가 여러 대여도 SSL 설정을 분산하지 않아도 된다.
server {
listen 443 ssl;
server_name example.com;
ssl_certificate /etc/ssl/fullchain.pem;
ssl_certificate_key /etc/ssl/private.key;
location / {
proxy_pass http://app_server;
}
}
3. 로드밸런싱
백엔드 서버가 여러 대일 때 트래픽을 분산하는 역할도 맡는다.
요청을 한 서버에 몰아주지 않고 여러 서버에 나눠 보내서 장애 위험을 줄인다.
upstream app_cluster {
server 10.0.0.11:8080;
server 10.0.0.12:8080;
server 10.0.0.13:8080;
}
server {
listen 80;
location / {
proxy_pass http://app_cluster;
}
}
4. 보안 은닉
내부 서버 IP와 포트를 외부에 직접 드러내지 않는다. 이게 실무에서 매우 크다.
공격자는 Reverse Proxy만 보게 되고, 내부 네트워크 구조를 바로 파악하기 어려워진다.
5. 캐시 및 응답 최적화
정적 파일이나 자주 요청되는 응답은 앞단에서 캐시해 성능을 높일 수 있다.
백엔드까지 매번 요청이 가지 않으므로 트래픽과 서버 부하를 줄이는 효과가 있다.
실무 기준 / 적용 방법
1. 가장 흔한 구성
실무에서는 보통 Nginx를 Reverse Proxy로 두고, 뒤에 PHP, Node.js, Java 서버를 붙인다.
프론트 정적 파일과 API 서버를 분리해도 사용자는 하나의 도메인만 보게 만드는 식으로 운영한다.
Client
↓
Nginx Reverse Proxy
├─ Frontend Server
└─ Backend API Server
2. PHP-FPM과 함께 쓰는 경우
PHP 환경에서는 Nginx가 요청을 받고 PHP 실행은 PHP-FPM에 넘기는 구조가 일반적이다.
이 구조를 쓰는 이유는 역할 분리다. 웹 요청 처리와 PHP 프로세스 관리를 나눌 수 있다.
server {
listen 80;
server_name example.com;
root /var/www/html/public;
location / {
try_files $uri $uri/ /index.php?$query_string;
}
location ~ \.php$ {
include fastcgi_params;
fastcgi_pass 127.0.0.1:9000;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
}
}
3. 프록시 헤더 전달
Reverse Proxy를 거치면 원래 클라이언트 IP 정보가 사라질 수 있다.
그래서 실무에서는 반드시
X-Forwarded-For, Host 같은 헤더를 넘겨야 한다.
location / {
proxy_pass http://backend_server;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
이 설정이 없으면 백엔드 로그에 프록시 IP만 찍히는 문제가 생긴다.
4. 헬스체크와 장애 대응
서버가 여러 대면 죽은 서버로 요청을 보내지 않도록 관리해야 한다.
이 부분이 빠지면 로드밸런싱 구조라도 오히려 장애가 더 크게 보일 수 있다.
자주 발생하는 문제
1. 클라이언트 IP가 전부 127.0.0.1 또는 프록시 IP로 보임
원인은 프록시 헤더 미전달이다. 백엔드에서 전달된 헤더를 신뢰하도록 설정도 함께 필요하다.
2. HTTPS 무한 리다이렉트
Reverse Proxy에서 SSL 종료를 했는데 백엔드가 다시 HTTPS 리다이렉트를 거는 경우 발생한다.
이때는 X-Forwarded-Proto를 기준으로
백엔드가 원래 프로토콜을 인식하게 해야 한다.
3. 파일 업로드 실패
대용량 업로드 시 프록시 단의 업로드 제한 때문에 막히는 경우가 많다.
server {
client_max_body_size 50M;
}
애플리케이션 문제가 아니라 Nginx 설정 문제인 경우가 매우 많다.
4. 웹소켓 연결 실패
일반 HTTP 프록시 설정만 하고 업그레이드 헤더를 빼먹으면 웹소켓이 끊긴다.
location /socket/ {
proxy_pass http://backend_socket;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
}
5. 타임아웃 문제
백엔드 응답이 느린데 프록시 기본 timeout이 짧으면 504가 발생한다.
이 경우에는 무조건 timeout만 늘릴 게 아니라 느린 쿼리나 백엔드 병목도 같이 봐야 한다.
실무에서 Reverse Proxy를 쓰는 이유 정리
실무에서는 기능 하나 때문에 쓰지 않는다. 여러 운영 문제를 한 지점에서 통제하려고 쓴다.
- 외부 노출 최소화
- SSL 인증서 관리 단순화
- 트래픽 분산
- 도메인/경로별 라우팅
- 캐시 및 성능 최적화
- 장애 대응 구조 마련
즉 Reverse Proxy는 단순 중계 서버가 아니다. 운영 구조를 안정적으로 만드는 앞단 제어 지점이다.
한 줄 요약
Reverse Proxy는 클라이언트 대신 내부 서버와 통신하는 앞단 서버이며, 실무에서는 보안, SSL 종료, 로드밸런싱, 라우팅을 한 곳에서 처리하기 위해 사용한다.
댓글 0