본문으로 건너뛰기

안동민 개발노트

본문 시작

프록시와 VPN

포워드·리버스 프록시의 중개 방향과 용도를 구분하고 Nginx 프록시 설정 및 VPN 터널의 보호 범위를 이해합니다.

프록시(Proxy)는 대리인이라는 뜻 그대로, 클라이언트와 서버 사이에서 요청을 중개하는 서버입니다.

어떤 방향에서 중개하느냐에 따라 포워드 프록시와 리버스 프록시로 나뉘며, 각각 전혀 다른 목적으로 사용됩니다.


포워드 프록시 vs 리버스 프록시

포워드와 리버스 프록시는 대리하는 쪽이 다르다

포워드는 클라이언트 쪽을 대표하고, 리버스는 서버 묶음을 대표한다는 기준으로 먼저 구분한다.

  1. 대리 대상 클라이언트 서버 풀
  2. 외부 노출 프록시 출구 IP

    하나의 공개 도메인

  3. 주요 목적 접속 통제, 캐시

    익명화 TLS, WAF, routing, cache

  4. 예시 회사망 proxy, VPN Nginx

    CDN, API gateway


포워드 프록시

포워드 프록시(Forward Proxy)클라이언트 측에 위치하여 클라이언트의 요청을 대신 보냅니다.

일반적으로 목적지 서버는 직접 연결한 주체인 프록시의 IP를 보며, 실제 클라이언트 IP는 프록시가 별도 헤더로 전달하지 않는 한 알기 어렵습니다.

기업에서 직원들의 인터넷 접속을 관리하는 용도로 많이 사용합니다.

회사 프록시가 특정 사이트 접근을 차단하거나, 직원들의 웹 사용 기록을 모니터링합니다.

HTTPS 트래픽의 본문까지 검사하려면 단순 프록시만으로는 부족하고, 기업 단말에 신뢰된 루트 인증서를 배포하는 TLS inspection 구성이 필요합니다.

학교나 도서관의 인터넷 필터링도 포워드 프록시 방식으로 구현될 수 있습니다.

개발 환경에서도 포워드 프록시를 만납니다.

회사 네트워크에서 npm install이 안 되는 경우, 프록시 설정이 원인인 경우가 많습니다.

proxy_config.sh
# 환경 변수 설정
export HTTP_PROXY=http://proxy.company.com:8080
export HTTPS_PROXY=http://proxy.company.com:8080
export NO_PROXY=localhost,127.0.0.1,.company.com

# npm 프록시 설정
npm config set proxy http://proxy.company.com:8080
npm config set https-proxy http://proxy.company.com:8080

# git 프록시 설정
git config --global http.proxy http://proxy.company.com:8080

리버스 프록시

리버스 프록시는 하나의 공개 입구로 여러 backend를 대표한다

클라이언트는 하나의 주소만 보지만, 프록시는 TLS, Host, cache, WAF, routing 정책을 적용한 뒤 내부로 넘긴다.

  1. 1 Client

    Client public URL 요청 내부 서버를 모름

  2. 2 Proxy

    Proxy TLS/WAF/cache/routing 정책을 먼저 적용

  3. 3 Backend

    Backend app-1, app-2 실제 서비스 처리

  4. 4 Response

    Response 하나의 도메인으로 응답 내부 구조 숨김

리버스 프록시(Reverse Proxy)서버 측에 위치하여 클라이언트의 요청을 받아 적절한 백엔드 서버로 전달합니다.

클라이언트는 리버스 프록시와만 통신하고, 뒤에 어떤 서버가 있는지 알 수 없습니다.

이전 절의 로드 밸런서가 사실 리버스 프록시의 한 형태입니다.

그 외에도 다양한 역할을 합니다.

기능설명효과
SSL 종단TLS를 프록시에서 처리인증서 관리 일원화
캐싱정적 파일, API 응답 캐시백엔드 부하 감소
압축gzip/brotli 압축대역폭 절약
보안백엔드 IP 은닉, WAF공격 표면 축소
속도 제한요청 수 제한(Rate Limit)DDoS 완화

Nginx를 리버스 프록시로 사용하기

Nginx 리버스 프록시는 요청 경로별로 책임을 나눈다

설정 파일을 외우기보다 HTTP에서 HTTPS로 보내고, 정적 파일과 API를 서로 다른 처리 경로로 나누는 구조를 읽습니다.

  1. Host + URI

    Request Host + URI 같은 도메인 안에서 경로가 갈라진다.

  2. 301 HTTPS

    :80 301 HTTPS 평문 요청은 443으로 이동

  3. 파일 직접 응답

    /static 파일 직접 응답 캐시 헤더와 함께 제공

  4. upstream

    /api upstream 원 IP와 Host를 넘김

  5. Upgrade

    /ws Upgrade 연결 전환 헤더 유지

Nginx는 가장 널리 사용되는 리버스 프록시이자 웹 서버입니다.

nginx.conf
upstream backend {
    least_conn;                         # 최소 연결 알고리즘
    server 127.0.0.1:3001 weight=3;     # 가중치 3
    server 127.0.0.1:3002 weight=1;     # 가중치 1
    server 127.0.0.1:3003 backup;       # 백업 서버
}

server {
    listen 80;
    server_name example.com;
    return 301 https://$host$request_uri;  # HTTP → HTTPS 리다이렉트
}

server {
    listen 443 ssl http2;
    server_name example.com;

    ssl_certificate     /etc/ssl/cert.pem;
    ssl_certificate_key /etc/ssl/key.pem;

    # 정적 파일 직접 서빙 (백엔드 거치지 않음)
    location /static/ {
        root /var/www;
        expires 30d;
        add_header Cache-Control "public, immutable";
    }

    # API는 백엔드로 프록시
    location /api/ {
        proxy_pass http://backend;
        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;

        # 타임아웃 설정
        proxy_connect_timeout 5s;
        proxy_read_timeout 30s;
    }

    # WebSocket 지원
    location /ws/ {
        proxy_pass http://backend;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}

X-Real-IPX-Forwarded-For 헤더는 원래 클라이언트의 IP 주소를 백엔드에 전달하기 위한 것입니다.

프록시를 거치면 백엔드가 보는 직접 연결 IP는 프록시의 IP이므로, 이 헤더로 원래 클라이언트 IP를 전달합니다.

다만 이 헤더는 클라이언트가 임의로 넣을 수도 있으므로, 백엔드는 신뢰한 프록시에서 온 헤더만 사용해야 합니다.


VPN

VPN(Virtual Private Network)은 공용 인터넷을 통해 가상의 사설 네트워크를 구성합니다.

VPN은 원래 패킷을 암호화해 새 패킷 안에 싣는다

외부망은 VPN 게이트웨이와 통신한다는 사실만 보고, 내부 사설 주소와 애플리케이션 데이터는 터널 안에 남습니다.

  1. 원격 사용자

    원래 사설 IP 패킷 생성

  2. VPN 게이트웨이

    복호화 후 내부망으로 전달

VPN의 핵심은 터널링(Tunneling)입니다.

원래의 패킷을 암호화한 후, 새로운 패킷으로 감싸서 전송합니다.

외부 네트워크에서는 VPN 게이트웨이와 통신한다는 사실, 대략적인 트래픽 양, 타이밍 같은 메타데이터는 볼 수 있지만, 터널 안의 사설 IP와 애플리케이션 데이터는 알기 어렵습니다.

또한 모든 트래픽을 VPN으로 보내는 full tunnel과 내부망 트래픽만 보내는 split tunnel은 동작 범위가 다릅니다.

프로토콜계층암호화/핸드셰이크성능특징
IPsecL3ESP + IKEv2좋음AWS VPN, site-to-site
OpenVPNL4 (TLS)TLS보통오픈소스, 유연
WireGuardL3Noise + ChaCha20매우 좋음작은 코드베이스, 현대적
L2TP/IPsecL2+L3IPsec보통레거시, 잘 안 씀

개발자 실무에서 VPN은 주로 회사의 개발 서버, 데이터베이스, 내부 API에 외부에서 접근할 때 사용합니다.

VPN에 연결하면 회사의 사설 IP 대역에 접근할 수 있게 됩니다.

마지막으로 프록시와 VPN을 운영할 때 확인해야 할 기준을 정리합니다.

프록시와 VPN 점검은 신뢰 경계와 원 IP부터 확인한다

중개 장비가 들어가면 원 IP, 인증서, 라우팅 범위, 로그 기준이 모두 달라질 수 있다.

  1. 원 IP X-Forwarded-For 신뢰 주체

    임의 header를 그대로 신뢰

  2. 인증서 TLS

    어디서 끝나는가 중간 복호화 경계 불명확

  3. 라우팅 터널

    어느 prefix를 가져가는가 split/full tunnel 혼동

  4. 로그 client, proxy, origin log

    연결 사고 시 사용자 추적 불가

프록시와 VPN에서는 프로토콜 상태, 실패 응답, 관측 도구, 복구 기준을 확인합니다.

프록시·VPN 보충 점검은 숨겨진 경로를 찾는 일이다

정책상 허용된 통신인지, 우회 경로가 남아 있는지, 원 IP를 믿어도 되는지까지 확인해야 합니다.

  1. 이름 해석

    DNS 이름 해석 VPN 연결 뒤 해석 서버 확인

  2. 라우팅

    Route 라우팅 내부 대역만 터널로 가는지 확인

  3. 검사 가능 범위

    TLS 검사 가능 범위 단말 신뢰 인증서 필요

  4. 원 IP 신뢰

    Header 원 IP 신뢰 프록시가 넣은 값만 사용

다음 절에서는 클라우드와 컨테이너 환경의 네트워크를 다루겠습니다.