Reverse Proxy — 구조와 운영 시 주의할 점

Forward Proxy와 Reverse Proxy

 

웹 서비스를 구성하다 보면 사용자가 보는 하나의 서비스 뒤에 여러 서버가 존재하게 된다.

예를 들어 화면은 Frontend가 처리하고, 로그인과 세션은 IAM이 담당하며, 실제 데이터 요청은 별도의 Backend API가 처리할 수 있다.

역할	서비스 예시
화면 제공	Frontend
로그인·인증	IAM
데이터 처리	Backend API
운영 기능	Admin Console

 

각 서비스를 서로 다른 주소와 Port로 직접 노출하는 것도 가능하다.

서비스	주소 예시
Frontend	app.example.com:3000
IAM	auth.example.com:8000
Backend API	api.example.com:9000

하지만 브라우저가 각 서비스의 주소를 직접 알고 접근하는 구조에서는 Cookie, CORS, TLS 인증서, Client IP, 내부 서비스 주소 관리 같은 문제를 각각 처리해야 한다.

 

Reverse Proxy는 여러 서비스 앞에서 외부 요청을 먼저 받은 뒤, 요청의 목적에 따라 적절한 내부 서버로 전달한다.

이 구조를 사용하면 브라우저에 노출되는 외부 주소와 실제 서비스 배치를 분리할 수 있다.

 

이번 글에서는 Reverse Proxy가 요청을 어떻게 전달하는지부터 TLS, Cookie, Client IP, Trusted Proxy 같은 운영상의 문제를 살펴본다.

 

목차

1. Forward Proxy와 Reverse Proxy
2. 요청을 내부 서비스로 전달하는 방법
3. Reverse Proxy가 담당할 수 있는 역할
   - TLS Termination
   - 외부 주소와 내부 서비스 주소 분리
   - Load Balancing
4. Reverse Proxy 운영에서 주의할 점
   - 브라우저 진입점과 Cookie / Origin
   - Client IP와 신뢰 경계
   - Routing Rule
   - 중앙 진입점의 장애 (Single point of failure)

---

1. Forward Proxy와 Reverse Proxy

Proxy는 Client와 Server 사이에서 요청을 대신 전달하는 중간 시스템이다.

일반적으로 Client가 Server에 직접 연결한다면 요청은 Client에서 Server로 바로 전달된다.

 

Proxy가 사이에 들어가면 Client와 Server가 직접 통신하는 대신 Proxy가 한쪽의 요청을 받아 다른 쪽으로 전달한다.

Proxy는 어느 쪽을 대신하느냐에 따라 크게 Forward Proxy와 Reverse Proxy로 나눌 수 있다.

 

Forward Proxy

Forward Proxy는 Client 측에 위치하여 Client를 대신해 외부 서버에 요청한다.

 

예를 들어 회사 내부 PC의 인터넷 접근을 중앙 Proxy를 통해 통제하거나, 특정 외부 사이트 접근을 제한하거나, 외부 서버에 Client의 직접 주소를 노출하지 않는 구조에서 사용할 수 있다.

Forward Proxy

Server 입장에서는 실제 Client와 직접 연결된 것이 아니라 Forward Proxy에서 연결이 들어온다.

핵심은 Client 측의 요청을 대신 수행한다는 것이다.

 

Reverse Proxy

Reverse Proxy는 Server 측에 위치하여 여러 서버를 대신해 외부 요청을 받는다.

Client는 뒤에 몇 개의 서버가 존재하는지, 각 서버가 어느 주소에서 동작하는지 알 필요가 없다.

 

예를 들어 Client에게는 다음 주소 하나만 공개할 수 있다.

https://app.example.com

실제 내부에서는 다음과 같이 여러 서비스가 존재할 수 있다.

내부 서비스	내부 주소 예시
Frontend	frontend:3000
IAM	iam:8000
Backend API	api:9000

Reverse Proxy는 외부 요청을 받아 이 중 적절한 서비스로 전달한다.

 

Forward Proxy와 Reverse Proxy (https://www.geeksforgeeks.org/system-design/difference-between-forward-proxy-and-reverse-proxy/)

두 Proxy의 차이를 정리하면 다음과 같다.

구분	Forward Proxy	Reverse Proxy
위치	Client 측	Server 측
대신하는 대상	Client	Server
외부 서버가 직접 보는 연결 상대	Forward Proxy	일반적으로 Reverse Proxy 뒤의 서버에는 Reverse Proxy
주요 목적	Client의 외부 접근 중계·통제	서버 진입점 통합·Routing
대표 활용	사내 인터넷 Proxy	Nginx, API Gateway 앞단, Web Service 진입점

Reverse Proxy의 핵심은 서버들을 대신해 외부 요청을 받는 것이다.

---

2. 요청을 내부 서비스로 전달하는 방법

Reverse Proxy가 어떤 내부 서버로 요청을 전달할지는 여러 기준으로 결정할 수 있다.

HTTP Reverse Proxy에서 가장 흔한 기준은 Host와 Path다.

 

Host 기반 Routing

요청이 들어온 Host에 따라 서로 다른 서비스로 전달할 수 있다.

요청 Host	전달 대상
app.example.com	Frontend
auth.example.com	IAM
api.example.com	Backend

여러 도메인이 동일한 IP 주소를 가리키더라도 Reverse Proxy는 HTTP 요청의 Host 정보를 사용해 어느 서비스로 보낼지 구분할 수 있다.

따라서 하나의 서버나 Load Balancer가 여러 도메인의 진입점 역할을 하는 구성이 가능하다.

 

Path 기반 Routing

같은 Host를 사용하면서 URL Path에 따라 내부 서비스를 나눌 수도 있다.

외부 요청	전달 대상
https://app.example.com/	Frontend
https://app.example.com/auth	IAM
https://app.example.com/api	Backend

 

Reverse Proxy와 요청 경로

Nginx에서는 다음과 같이 구성할 수 있다.

server {
    listen 80;

    location /auth/ {
        proxy_pass http://iam:8000;
    }

    location /api/ {
        proxy_pass http://backend:9000;
    }

    location / {
        proxy_pass http://frontend:3000;
    }
}

 

브라우저에서는 모든 요청이 같은 Host로 전송된다.

• / 요청은 Frontend로 전달된다.
• /auth/login 요청은 IAM으로 전달된다.
• /api/users 요청은 Backend로 전달된다.

여기서 HTTP Reverse Proxy는 단순히 Client가 보낸 패킷을 그대로 복사해 Backend로 넘기는 장치가 아니다.

 

Reverse Proxy는 Client와 연결을 맺고 요청을 받은 뒤, 선택한 upstream 서버와 별도의 연결을 사용해 HTTP 요청을 전달한다. upstream의 응답을 받으면 다시 Client 쪽 응답으로 반환한다.

Reverse Proxy: Create New Upstream Request

이 구조 덕분에 외부에서 보이는 주소와 실제 내부 서비스의 주소 및 배치를 서로 독립적으로 관리할 수 있다.

Backend 서버가 변경되더라도 외부 Client가 사용하는 주소까지 함께 변경할 필요가 없는 이유도 여기에 있다.

---

3. Reverse Proxy가 담당할 수 있는 역할

Reverse Proxy의 기본 역할은 요청을 적절한 upstream으로 전달하는 것이지만, 실제 운영 환경에서는 그 진입점을 이용해 여러 기능을 함께 처리한다.

 

1. TLS Termination

각 Backend 서버가 HTTPS를 직접 처리하도록 구성할 수도 있다.

하지만 서비스가 많아질수록 인증서 배포, 갱신, TLS 설정도 각 서버에서 관리해야 한다.

Reverse Proxy가 외부 HTTPS 연결을 담당하도록 만들면 TLS 처리를 한곳에 집중시킬 수 있다.

Reverse Proxy: TLS Termination

 

이 구조를 TLS Termination이라고 한다.

Reverse Proxy는 Client와 TLS 연결을 맺고 HTTPS 요청을 복호화한 뒤 내부 서비스로 전달한다.

 

내부 구간은 환경에 따라 HTTP를 사용할 수도 있고 다시 HTTPS를 사용할 수도 있다.

구간	구성 예시
Client → Reverse Proxy	HTTPS
Reverse Proxy → Backend	HTTP 또는 HTTPS

내부 네트워크라고 해서 항상 평문 HTTP를 사용해야 하는 것은 아니다.

서비스 간 통신까지 암호화해야 하는 환경에서는 Reverse Proxy와 Backend 사이에도 TLS를 적용할 수 있다.

 

2. 외부 주소와 내부 서비스 주소 분리

Reverse Proxy가 없고 Client가 각 서비스를 직접 호출해야 한다면 Client 설정에 실제 서비스 주소가 노출되기 쉽다.

 

예를 들어 Frontend가 다음과 같은 주소를 직접 알고 있을 수 있다.

서비스	내부 주소 예시
IAM	10.0.1.21:8000
Backend	10.0.1.30:9000

Reverse Proxy를 사용하면 Client는 공개된 진입점만 알면 되고, 실제 Backend 주소는 Proxy 내부 설정에서 관리할 수 있다.

다만 Backend 주소가 Client에게 보이지 않는 것과 Backend에 직접 접근할 수 없는 것은 다른 문제다.

 

Reverse Proxy를 설치했더라도 Backend가 다른 네트워크 경로를 통해 외부에서 접근 가능하다면 사용자는 Reverse Proxy를 우회해 Backend에 직접 연결할 수 있다.

 

따라서 Reverse Proxy를 보안 경계로 사용하려면 실제 네트워크 접근 제어도 함께 구성해야 한다.

예를 들어 다음과 같은 요소를 사용할 수 있다.

• Firewall
• Security Group
• Network Policy
• Backend의 Listen Address
• Private Subnet
• 서비스 간 ACL

즉, 의미 있는 구조는 Internet → Reverse Proxy → Private Backend가 되어야 한다.

Reverse Proxy는 요청의 진입점을 만들 수 있지만, 네트워크 접근 제어까지 자동으로 만들어 주는 것은 아니다.

 

3. Load Balancing

동일한 애플리케이션 서버가 여러 대 존재한다면 Reverse Proxy가 요청을 여러 서버로 분산할 수도 있다.

Reverse Proxy: Load Balancing

예를 들어 하나의 API가 세 개의 Instance로 실행되고 있다면 Reverse Proxy가 Round Robin 등의 정책을 사용해 요청을 분산할 수 있다.

 

이 경우 Reverse Proxy가 Load Balancer 역할도 함께 수행한다.

다만 Reverse Proxy와 Load Balancer가 같은 개념은 아니다.

개념	의미
Reverse Proxy	Client 대신 서버 측에서 요청을 받아 upstream으로 전달하는 구조
Load Balancing	여러 대상 중 하나를 선택해 트래픽을 분산하는 기능

Reverse Proxy는 더 넓은 구조적 개념이고, Load Balancing은 Reverse Proxy가 제공할 수 있는 기능 중 하나다.

---

4. Reverse Proxy 운영에서 주의할 점

Reverse Proxy를 사용하면 외부 진입점과 내부 서비스를 분리하고, Routing이나 TLS 같은 공통 기능을 한곳에서 처리할 수 있다.

하지만 Client와 Backend 사이에 Proxy가 하나 더 들어오면서 브라우저가 보는 주소, Backend가 보는 Client 정보, 네트워크의 신뢰 경계도 달라진다.

 

실제 운영에서는 이 차이를 이해하고 설정해야 한다.

 

• 브라우저 진입점과 Cookie / Origin
• Client IP와 신뢰 경계
• Routing Rule
• 중앙 진입점의 장애

 

 

브라우저에 노출되는 진입점과 Cookie

Reverse Proxy를 인증 시스템과 함께 사용할 때는 브라우저가 어떤 Host와 통신하고 있는지가 중요하다.

 

예를 들어 애플리케이션과 IAM을 브라우저가 서로 다른 Host로 직접 호출한다고 하자.

역할	브라우저가 접근하는 Host
Application	192.168.0.20
IAM	10.0.0.10

브라우저가 IAM에서 로그인하고 다음과 같이 Domain 속성이 없는 Cookie를 받으면,

Set-Cookie: session=abc123; Path=/; HttpOnly

이 Cookie는 응답을 보낸 Host에 묶이는 host-only Cookie가 된다.

 

따라서 10.0.0.10에서 설정된 Cookie는 192.168.0.20으로 보내는 요청에 자동으로 포함되지 않는다.

Reverse Proxy를 사용하면 브라우저에 노출되는 진입점을 하나로 통합할 수 있다.

 

예를 들어 브라우저는 항상 다음 Host에 요청한다.

192.168.0.20

 

Reverse Proxy는 Path에 따라 내부 서비스를 선택한다.

외부 Path	내부 서비스
/	Frontend
/auth/	IAM

로그인도 브라우저 관점에서는 다음 주소에서 이루어진다.

http://192.168.0.20/auth/login

실제 IAM이 다른 내부 주소에서 실행되더라도 브라우저는 IAM에 직접 연결하지 않는다. IAM의 응답 역시 Reverse Proxy를 통해 돌아온다.

Browser는 전체 과정에서 동일한 공개 Host와 통신하고 Set-Cookie도 Proxy를 통해 전달되는 구조

핵심은 Cookie의 범위를 억지로 넓히는 것이 아니다.

 

브라우저가 보는 애플리케이션과 인증 시스템의 진입점을 일관되게 만드는 것이다.

이때 Cookie의 범위와 Origin은 구분해야 한다.

 

Cookie는 Port별로 나뉘지 않지만, Origin은 다음 세 값의 조합으로 구분된다.

Scheme + Host + Port

 

따라서 다음 URL은 서로 다른 Origin이다.

URL	차이
http://example.com:3000	기준
https://example.com:3000	Scheme이 다름
http://example.com:8000	Port가 다름

또한 Cookie의 Host/Domain 범위, SameSite에서 사용하는 Site, CORS와 Same-Origin Policy에서 사용하는 Origin은 서로 같은 기준이 아니다.

 

Cookie가 전송되지 않는 문제를 확인할 때는 다음 순서로 보는 것이 좋다.

Cookie 저장 여부 → Host/Domain 범위 → Path → Secure → SameSite

현재 요청 Host에 사용할 Cookie 자체가 없다면 SameSite=None으로 변경해도 해결되지 않는다.

 

Client IP와 신뢰 경계

Reverse Proxy가 들어오면 Backend가 직접 연결을 맺는 상대는 실제 Client가 아니라 Reverse Proxy가 된다.

 

예를 들어 Client IP가 192.168.1.100, Reverse Proxy의 내부 주소가 172.20.0.5라고 하자.

Client와 Reverse Proxy 사이의 연결은 Proxy에서 종료되고, Reverse Proxy가 Backend와 별도의 연결을 만든다.

따라서 Backend에서 직접 확인하는 연결 상대는 다음과 같이 Proxy의 주소가 될 수 있다.

remote_addr = 172.20.0.5

Reverse Proxy 뒤에서 Client IP는 어떻게 전달되는가

 

Backend가 remote_addr만 사용하면 서로 다른 사용자 요청도 모두 같은 Proxy IP에서 들어오는 것처럼 보인다.

그래서 Reverse Proxy는 일반적으로 원래 Client 정보를 HTTP Header로 전달한다.

X-Real-IP: 192.168.1.100
X-Forwarded-For: 192.168.1.100

 

Nginx에서는 다음과 같이 설정할 수 있다.

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가 여러 단계라면 X-Forwarded-For에는 여러 주소가 들어갈 수 있다.

X-Forwarded-For: 203.0.113.10, 10.0.0.5, 10.0.0.8

 

하지만 이 Header를 그대로 믿어서는 안 된다.

X-Forwarded-For나 X-Real-IP는 일반 HTTP Header이기 때문에 Client도 임의로 만들 수 있다.

X-Forwarded-For: 127.0.0.1

따라서 Client IP를 해석할 때는 Header 값만 보는 것이 아니라 누가 그 Header를 전달했는지를 함께 봐야 한다.

 

핵심 판단은 다음과 같다.

Backend에 직접 연결한 Peer가 신뢰할 수 있는 Proxy인가 → 그렇다면 그 Proxy가 전달한 Client 정보를 해석

이 경계를 Trusted Proxy 설정으로 관리한다.

Trusted Proxy 예시

이 때문에 Trusted Proxy 설정과 Backend의 네트워크 접근 제어는 따로 생각할 수 없다.

 

Backend에 외부 Client가 직접 접근할 수 있다면 Reverse Proxy를 우회해 임의의 Forwarded Header를 보낼 수 있다.

따라서 Reverse Proxy를 실제 진입점으로 사용하려면 Backend도 일반적으로 Proxy를 통해서만 접근 가능하도록 제한한다.

Internet → Reverse Proxy → Private Backend

 

여기에는 다음과 같은 접근 제어를 사용할 수 있다.

• Firewall
• Security Group
• Network Policy
• Private Subnet
• Backend의 Listen Address
• 서비스 간 ACL

즉, 역할은 다음처럼 나뉜다.

영역	역할
Reverse Proxy	요청을 받아 Backend로 전달
Trusted Proxy	어떤 Proxy가 전달한 Client 정보를 신뢰할지 결정
Network 접근 제어	누가 Backend에 직접 연결할 수 있는지 제한

 

 

또 하나 주의할 점은 Reverse Proxy에 도착하기 전에 Client IP가 이미 변경될 수 있다는 것이다.

NAT가 있다고 해서 항상 Source IP가 바뀌는 것은 아니다.

방식	변경되는 주소
DNAT	Destination Address
SNAT	Source Address
Masquerade	Source Address

예를 들어 원래 Client IP가 192.168.1.100인데 Proxy 앞단에서 SNAT이나 Masquerade가 적용되어 10.0.0.1로 변경되었다고 하자.

Reverse Proxy 도달 전, SNAT 또는 masquerade 적용시 Source Address 변경

이 경우 Reverse Proxy가 실제로 관찰하는 연결 상대는 이미 10.0.0.1이다.

 

따라서 다음 설정을 사용해도,

proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

Nginx가 알고 있는 $remote_addr 자체가 10.0.0.1이다.

 

Reverse Proxy는 자신에게 도착한 Client 정보를 Backend로 전달할 수는 있지만, 앞선 Network Layer에서 이미 사라진 정보를 복원할 수는 없다.

 

결국 Client IP 문제는 Application의 Header만 봐서는 안 된다.

Client → Network → NAT → Reverse Proxy → Backend

전체 경로에서 Source Address가 어디까지 유지되는지를 함께 확인해야 한다.

 

Routing Rule은 의도보다 넓게 적용될 수 있다

Reverse Proxy의 Path Routing도 설정 방식에 따라 예상보다 넓게 적용될 수 있다.

 

예를 들어 정확히 /me만 IAM으로 전달하고 싶다고 하자.

Nginx에서 다음과 같이 Prefix Location을 사용하면,

location /me {
    ...
}

 

/me로 시작하는 다른 URI도 같은 Rule에 포함된다.

요청 URI	/me Prefix와 일치
/me	O
/members	O
/message	O

 

정확히 /me만 처리하려면 exact location을 사용할 수 있다.

location = /me {
    ...
}

 

/me/ 아래의 하위 경로를 처리하려면 별도의 Prefix를 둘 수 있다.

location /me/ {
    ...
}

Route가 많아질수록 Reverse Proxy 설정도 하나의 Routing Table처럼 동작한다.

따라서 Host와 Path가 어떤 upstream으로 전달되는지 명확한 규칙으로 관리하는 것이 중요하다.

 

Reverse Proxy가 중앙 진입점이면 장애 영향도 집중된다

모든 외부 요청을 하나의 Reverse Proxy가 받는 구조에서는 Proxy가 전체 서비스의 중앙 진입점이 된다.

Reverse Proxy: Single pont of failure

이 경우 Backend 서비스가 모두 정상이어도 Reverse Proxy가 장애를 일으키면 외부에서는 서비스에 접근할 수 없다.

 

즉, Reverse Proxy 자체가 Single Point of Failure가 될 수 있다.

가용성이 중요한 환경에서는 다음과 같은 구성을 함께 고려해야 한다.

• 여러 Reverse Proxy Instance
• 상위 Load Balancer
• Health Check
• Failover
• 설정 배포 및 Rollback 전략

Reverse Proxy는 Routing, TLS, 인증 진입점 같은 기능을 한곳에 모아 운영을 단순하게 만들지만, 그만큼 해당 지점의 설정 오류나 장애가 미치는 범위도 커진다.

 

그리고 Reverse Proxy보다 앞선 네트워크에서 Source IP가 어떻게 처리되는지는 다음 글에서 WireGuard, NetBird, Routing Peer와 Masquerade를 통해 더 자세히 살펴본다.