본문으로 건너뛰기

안동민 개발노트

본문 시작

프록시와 VPN

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

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

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


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

HTML 다이어그램: /docs/network/ch13/ch13-3/1.html

포워드 프록시

포워드 프록시(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

리버스 프록시

HTML 다이어그램: /docs/network/ch13/ch13-3/3.html

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

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

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

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

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

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

HTML 다이어그램: /docs/network/ch13/ch13-3/4.html

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)은 공용 인터넷을 통해 가상의 사설 네트워크를 구성합니다.

HTML 다이어그램: /docs/network/ch13/ch13-3/2.html

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을 운영할 때 확인해야 할 기준을 정리합니다.

HTML 다이어그램: /docs/network/ch13/ch13-3/6.html

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

HTML 다이어그램: /docs/network/ch13/ch13-3/7.html

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