프록시와 리버스 프록시 — 방향이 뒤집히면 뭐가 달라지나

2026.07.04·3분 읽기

터널을 만들다가 깨달았다

Custom Tunnel을 만들면서 공개 서버 쪽 코드를 쓰다 보니, 내가 하고 있는 일이 낯익었다. 요청을 받아서 대신 전달하고, 응답을 받아서 돌려주고, 헤더를 고치고, 백엔드가 죽으면 502를 뱉고. 이거 그냥 리버스 프록시잖아?

그런데 막상 "프록시랑 리버스 프록시가 뭐가 달라?"라고 스스로에게 물으니 답이 바로 안 나왔다. 둘 다 "중간에서 대신 전달하는 놈"인데, 뭐가 리버스라는 건지. 정리하고 나니 기준은 딱 하나였다. 누구를 대신하느냐.

프록시(포워드 프록시): 클라이언트의 대리인

포워드 프록시는 클라이언트 편에 선다. 내가 어딘가에 요청을 보낼 때, 내 정체를 감추거나 회사 정책을 통과하기 위해 중간에 끼우는 놈이다.

[나] ──▶ 프록시 ──▶ 인터넷의 아무 서버
 ▲                        │
 └── 서버는 프록시만 보인다 ──┘

서버는 진짜 클라이언트가 누군지 모른다. 서버 입장에선 프록시가 요청을 보낸 것으로 보인다.
클라이언트가 프록시의 존재를 알고, 직접 설정한다. (브라우저 프록시 설정, http_proxy 환경변수)
회사에서 특정 사이트를 차단하거나, 국가 차단을 우회하거나, 발신 트래픽을 감사 로그로 남기는 게 전부 이 구조다.

핵심: 프록시가 "나가는 방향" 을 대리한다. 그래서 forward다.

리버스 프록시: 서버의 대리인

리버스 프록시는 반대로 서버 편에 선다. 방문자는 리버스 프록시에 접속하고, 그 뒤에 진짜 서버가 몇 대 있는지, 어디 있는지 전혀 모른다.

방문자 ──▶ 리버스 프록시(nginx 등) ──▶ 백엔드 서버 1
                                  ├──▶ 백엔드 서버 2
                                  └──▶ 백엔드 서버 3

클라이언트는 진짜 서버가 누군지 모른다. 아까와 정확히 반대다.
설정하는 쪽도 반대다. 클라이언트는 아무것도 안 하고, 서버 운영자가 리버스 프록시를 세운다.
nginx로 로드밸런싱, TLS 종료(HTTPS를 프록시에서 풀고 뒤로는 HTTP), 캐싱, 압축을 하는 게 전부 이 구조다. CDN도 본질적으로 거대한 리버스 프록시다.

한 줄로 비교하면:

	포워드 프록시	리버스 프록시
누구 편인가	클라이언트	서버
누가 숨나	클라이언트	서버(백엔드)
누가 설정하나	클라이언트	서버 운영자
대표 예	회사 프록시, 우회 프록시	nginx, CDN, 로드밸런서

이름이 헷갈리면 이렇게 기억하면 된다. 프록시가 숨겨주는 쪽이 곧 프록시의 주인이다. 클라이언트를 숨기면 포워드, 서버를 숨기면 리버스.

그래서 Custom Tunnel은 뭐냐

터널의 공개 서버는 리버스 프록시의 정의에 정확히 들어맞는다. 방문자는 공개 URL만 알고, 뒤에 있는 내 로컬 서버의 존재를 모른다. 실제로 하는 일도 리버스 프록시가 하는 일 그대로다.

요청을 백엔드(내 로컬)로 대신 전달하고 응답을 돌려준다
백엔드 응답이 30초 안 오면 504, 백엔드가 죽어 있으면 502
헤더를 고쳐서 내보낸다 — CSP·X-Frame-Options 제거, Location 치환

그런데 nginx 같은 보통 리버스 프록시와 결정적으로 다른 점이 하나 있다. 백엔드로 연결하는 방향이다.

nginx는 프록시가 백엔드로 직접 접속한다. 같은 데이터센터 안에 있으니 가능하다. 하지만 내 로컬 PC는 NAT와 방화벽 뒤에 있어서, 공개 서버가 접속해 들어올 방법이 없다. 그래서 방향을 뒤집는다. 로컬이 먼저 공개 서버로 WebSocket을 열어두고, 방문자 요청이 오면 그 미리 열린 연결로 거꾸로 밀어 넣는다.

nginx:          프록시 ──접속──▶ 백엔드          (프록시가 접속)
Custom Tunnel:  프록시 ◀──접속── 백엔드(로컬)    (백엔드가 먼저 접속)
                       ──요청──▶                 (트래픽은 반대로 흐름)

연결을 여는 방향과 트래픽이 흐르는 방향이 반대인 것. 이게 리버스 터널이고, ngrok이 NAT를 뚫는 원리다. 정리하면 Custom Tunnel은 "HTTP 중계 계층은 리버스 프록시, 백엔드 연결은 리버스 터널"인 구조다.

이 구조 때문에 생기는 문제들이 있다. HTTP는 요청-응답이 쌍인데 WebSocket은 그냥 메시지 스트림이라 매칭을 직접 해야 하고, 텍스트 채널로 바이너리를 날라야 한다. 보통 리버스 프록시에는 없는, 터널이라서 생기는 비용이다.

덤: 둘 다인 놈도 있다

경계가 항상 깔끔하진 않다. VPN은 사용자를 대신해 나가니 포워드 프록시 성격인데, 회사 VPN은 내부 서버 접근 통로이기도 하다. Cloudflare 같은 CDN은 방문자에겐 리버스 프록시지만, Workers에서 외부 API를 호출하면 그 순간엔 나가는 요청의 대리인이다. 결국 구조 이름보다 중요한 건 그 요청에서 누구를 대신해 누구를 숨기고 있는가를 볼 줄 아는 것이다.

GitHub: debug_tool (Custom Tunnel)