HTTP 프록시는 클라이언트와 서버 사이에서 HTTP 메시지를 중개하는 중간 서버다. 프록시는 요청을 받아 서버로 전달하고, 응답을 받아 클라이언트에게 돌려준다. 이 과정에서 캐싱, 보안, 로드 밸런싱 등 다양한 기능을 수행한다.
클라이언트가 직접 서버에 요청하지 않고 프록시를 거친다.
클라이언트 → 프록시 → 서버
← 프록시 ←
포워드 프록시 vs 리버스 프록시
프록시는 위치와 용도에 따라 포워드 프록시와 리버스 프록시로 나뉜다.
포워드 프록시는 클라이언트 쪽에 위치하며, 클라이언트를 대신하여 요청을 보낸다.
[클라이언트] → [포워드 프록시] → [인터넷] → [서버]
회사나 학교에서 사용하는 프록시가 대표적이다. 직원들의 모든 인터넷 요청이 회사 프록시를 거쳐 나간다.
클라이언트는 프록시를 명시적으로 설정해야 하며 브라우저나 운영체제에서 프록시 주소를 지정한다.
리버스 프록시는 서버 쪽에 위치하며, 서버를 대신하여 응답을 보낸다.
[클라이언트] → [인터넷] → [리버스 프록시] → [서버]
클라이언트는 프록시가 있는지 모르고 실제 서버로 인식한다. Nginx, HAProxy, AWS ELB가 대표적인 리버스 프록시다.
프록시의 주요 기능
캐싱
프록시는 응답을 저장해두고 재사용하며 같은 요청이 들어오면 서버까지 가지 않고 캐시에서 바로 응답한다. 서버 부하가 줄어들고, 응답 속도가 빨라진다. CDN의 핵심 동작 원리다.
첫 번째 요청:
클라이언트 → 프록시 → 서버
← (캐시에 저장) ←
두 번째 요청:
클라이언트 → 프록시 (캐시에서 응답) 서버
←
로드 밸런싱
여러 서버로 요청을 분산하여 부하를 나눈다. 한 서버가 다운되어도 다른 서버로 트래픽을 보내 가용성을 높인다.
→ [서버1]
[프록시]→ → [서버2]
→ [서버3]
- 라운드 로빈: 순서대로 서버에 분배
- 최소 연결: 연결이 가장 적은 서버에 분배
- IP 해시: 클라이언트 IP를 해시하여 같은 서버로 연결
SSL/TLS 종료
HTTPS 연결을 프록시에서 종료하고, 백엔드와는 HTTP로 통신한다. SSL 인증서 관리를 프록시에서 중앙화할 수 있고, 백엔드 서버의 CPU 부담이 줄어든다.
[클라이언트] --HTTPS--> [프록시] --HTTP--> [서버]
압축
응답을 gzip이나 brotli로 압축하여 전송 크기를 줄인다. 대역폭 사용량이 줄어들어 전송 속도가 빨라진다.
[서버] → 100KB HTML → [프록시] → 20KB (압축) → [클라이언트]
인증과 권한 관리
프록시에서 인증을 처리하고, 인가된 요청만 백엔드로 전달한다. API 게이트웨이가 이 패턴을 사용한다.
[클라이언트] → [프록시] (인증 확인)
↓
인증 실패: 401
인증 성공: → [서버]
로깅과 모니터링
모든 요청이 프록시를 거치므로, 중앙에서 로그를 수집하고 분석할 수 있다. 트래픽 패턴을 분석하고, 이상 징후를 감지하며, 성능 지표를 추적한다.
[프록시] → 로그: IP, URL, 응답 시간, 상태 코드
프록시 관련 HTTP 헤더
프록시를 거치면서 추가되거나 수정되는 헤더들이 있다.
Via 헤더
요청과 응답이 거친 프록시 정보를 기록한다. 여러 프록시를 거칠 때마다 추가되어, 전체 경로를 추적할 수 있다.
요청:
GET /api/users HTTP/1.1
Host: example.com
Via: 1.1 proxy1.company.com
응답:
HTTP/1.1 200 OK
Via: 1.1 proxy1.company.com, 1.1 cdn.example.com
X-Forwarded-For 헤더
원래 클라이언트의 IP 주소를 전달한다. 프록시를 거치면 서버는 프록시의 IP만 보이므로, 실제 클라이언트 IP를 알려주는 헤더가 필요하다. 첫 번째가 원래 클라이언트, 나머지는 중간 프록시들이다. 서버는 이를 보고 실제 클라이언트를 식별한다.
X-Forwarded-For: 203.0.113.1, 198.51.100.2
X-Forwarded-Proto 헤더
원래 프로토콜(HTTP/HTTPS)을 전달한다. 프록시가 SSL을 종료하면 백엔드는 HTTP 요청을 받지만, 원래는 HTTPS였음을 알아야 리다이렉션 등을 올바르게 처리할 수 있다.
X-Forwarded-Proto: https
X-Forwarded-Host 헤더
원래 호스트 이름을 전달해 프록시가 Host 헤더를 변경할 때, 원래 호스트를 보존한다.
X-Forwarded-Host: www.example.com
Forwarded 헤더
위의 X-Forwarded-* 헤더들을 통합한 표준 헤더다. 더 명확하고 표준화되었지만, X-Forwarded-* 헤더가 여전히 널리 사용된다.
Forwarded: for=203.0.113.1; proto=https; host=www.example.com
실무에서의 프록시 활용
Nginx
Nginx는 가장 널리 사용되는 리버스 프록시 중 하나로 주로 로드 밸런싱과 SSL 종료를 수행하며, 정적 파일을 직접 서빙하여 애플리케이션 서버 부담을 줄인다.
CDN
CDN은 전 세계에 분산된 캐싱 프록시 네트워크로 사용자와 가까운 위치의 프록시에서 콘텐츠를 제공한다. 물리적 거리가 줄어들어 지연 시간이 감소하고, 원본 서버 부하가 줄어든다.
한국 사용자 → 서울 CDN 노드 (캐시)
미국 사용자 → 뉴욕 CDN 노드 (캐시)
API 게이트웨이
마이크로서비스 환경에서 API 게이트웨이가 중앙 진입점 역할을 한다. 인증, Rate Limiting, 라우팅, 로깅을 중앙에서 처리한다. AWS의 API Gateway가 API 게이트웨이다.
[클라이언트]
↓
[API Gateway]
├→ [인증 서비스]
├→ [사용자 서비스]
├→ [주문 서비스]
└→ [결제 서비스]
프록시 체인
여러 프록시가 연쇄적으로 동작할 수 있으며 각 프록시가 서로 다른 역할을 수행하고, Via 헤더로 전체 경로를 추적한다.
[클라이언트] → [회사 프록시] → [CDN] → [로드 밸런서] → [서버]
프록시와 보안
캐시 보안
민감한 데이터가 프록시 캐시에 저장되지 않도록 해야 한다. 아래의 private는 공유 프록시에서는 캐시하지 말고, 브라우저에서만 캐시하라는 의미다.
# 캐시하지 않음
Cache-Control: no-store, private
# 개인 정보는 private
Cache-Control: private, max-age=3600
헤더 검증
X-Forwarded-For 같은 헤더는 클라이언트가 위조할 수 있다. 신뢰할 수 있는 프록시에서 온 요청인지 확인해야 한다.
# 신뢰할 수 있는 프록시 IP만 허용
if (request.ip not in trusted_proxies) {
ignore X-Forwarded-For header
}
SSL 검증
프록시가 SSL을 종료할 때, 백엔드와의 통신도 암호화하는 것이 안전하다. 내부 네트워크라도 중간자 공격이 가능하므로, 민감한 데이터는 종단 간 암호화가 권장된다.
[클라이언트] --HTTPS--> [프록시] --HTTPS--> [서버]
HTTP 프록시는 단순한 중개자를 넘어 웹 인프라의 핵심 구성 요소로 캐싱으로 성능을 높이고, 로드 밸런싱으로 확장성을 확보하며, 중앙 집중식 관리로 보안을 강화해야한다.