Nginx 리버스 프록시란? 웹서버·앱서버 연결 원리

핵심 요약

리버스 프록시는 사용자와 애플리케이션 서버 사이에 서서, 요청을 대신 받아 뒤쪽 서버로 전달하는 중계 서버입니다. Nginx가 대표적입니다.
사용자는 Nginx(443 포트)에만 접속하고, 실제 앱 서버(예: 3000·8080 포트)는 뒤에 숨습니다.
한 대의 Nginx로 HTTPS 처리·로드밸런싱·캐싱·정적 파일 제공·보안을 한곳에서 담당할 수 있습니다.
설정의 핵심은 location 블록의 proxy_pass 한 줄 — “이 경로로 온 요청을 이 서버로 넘겨라”.

Node.js나 Spring Boot로 만든 서버를 배포하면 보통 3000번, 8080번 같은 포트로 뜹니다. 그런데 사용자에게 example.com:8080으로 접속하라고 할 수는 없고, HTTPS 인증서도 앱마다 따로 붙이기 번거롭습니다. 이때 앞단에 Nginx 리버스 프록시를 한 대 세우면 이 문제가 깔끔하게 풀립니다. 이 글에서는 리버스 프록시가 무엇인지, 왜 실무의 거의 모든 서버 앞에 Nginx가 서 있는지, 그리고 최소 설정은 어떻게 생겼는지 정리합니다.

리버스 프록시란?

프록시(proxy)는 “대리인”이라는 뜻입니다. 리버스 프록시는 서버 쪽을 대리하는 중계 서버로, 사용자의 요청을 대신 받아 뒤에 있는 실제 애플리케이션 서버로 넘겨주고, 그 응답을 다시 사용자에게 전달합니다. 사용자 입장에서는 Nginx가 곧 서버처럼 보이고, 진짜 앱 서버가 몇 대인지, 어떤 포트를 쓰는지는 알 수 없습니다.

사용자는 Nginx에만 접속하고, Nginx가 요청을 뒤쪽 서버로 나눠 전달합니다.

포워드 프록시와 무엇이 다른가?

둘 다 중계 서버지만 누구를 대리하느냐가 반대입니다. 포워드 프록시는 클라이언트를 대리해 외부로 나가는 요청을 대신 보내고(회사 내부망의 프록시 서버가 대표적), 리버스 프록시는 서버를 대리해 외부에서 들어오는 요청을 대신 받습니다.

구분	포워드 프록시	리버스 프록시
대리 대상	클라이언트(사용자)	서버
위치	사용자 앞	서버 앞
주 목적	내부망 통제·우회·캐싱	HTTPS·로드밸런싱·보안
사용자 인지	사용자가 설정함	사용자는 존재를 모름

Nginx 리버스 프록시가 하는 일

HTTPS(SSL) 종료: 인증서를 Nginx 한 곳에만 설치하면, 뒤쪽 앱 서버들은 평문 HTTP로 통신해도 됩니다. 인증서 관리가 단순해집니다.
로드밸런싱: 같은 앱을 여러 대 띄워 두고 Nginx가 요청을 분산해, 한 대가 죽어도 서비스가 계속됩니다.
정적 파일 제공: 이미지·CSS·JS 같은 정적 자원은 Nginx가 직접 빠르게 응답하고, 동적 요청만 앱 서버로 넘깁니다.
캐싱·압축: 자주 쓰이는 응답을 캐시하고 gzip으로 압축해 속도를 높입니다.
보안·은닉: 실제 서버의 포트·구조를 숨기고, 요청 제한(rate limit)·헤더 필터링으로 앞단에서 방어합니다.

최소 설정 예시

가장 기본적인 리버스 프록시 설정은 다음과 같습니다. 80/443으로 들어온 요청을 로컬에서 도는 앱 서버(3000 포트)로 넘기는 형태입니다.

server {
    listen 80;
    server_name example.com;

    location / {
        proxy_pass http://127.0.0.1:3000;   # 뒤쪽 앱 서버로 전달
        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;
    }

    location /static/ {
        root /var/www/myapp;                 # 정적 파일은 Nginx가 직접 응답
    }
}

핵심은 proxy_pass 한 줄입니다. 나머지 proxy_set_header들은 뒤쪽 앱이 원래 클라이언트의 IP·호스트·프로토콜을 알 수 있게 넘겨 주는 역할을 합니다. 이걸 빼먹으면 앱 로그에 접속자 IP가 전부 127.0.0.1로만 찍히는 흔한 문제가 생깁니다.

직접 세워 보며 느낀 점 (신입 관점)

학교 시스템프로그래밍 과제로 한 학기 동안 웹·WAS·메일·DNS 등 여러 서버를 직접 구축하면서, 앞단에 Nginx를 리버스 프록시로 두는 구조를 반복해서 만들었습니다. 그때 가장 크게 와닿은 건 “관심사가 분리된다”는 점이었습니다. 인증서, 도메인, 포트 라우팅, 정적 파일 같은 네트워크·운영 관심사는 Nginx가, 비즈니스 로직은 앱 서버가 나눠 맡으니, 앱 코드를 건드리지 않고도 HTTPS를 붙이거나 서버를 늘릴 수 있었습니다. 신입 인프라·백엔드 면접에서 “리버스 프록시를 왜 쓰나요?”는 단골 질문인데, 이 관심사 분리와 SSL 종료·로드밸런싱을 실제 설정과 함께 설명할 수 있으면 충분합니다.

자주 묻는 질문 (FAQ)

Q. Nginx와 아파치(Apache)는 무엇이 다른가요?
둘 다 웹서버이자 리버스 프록시로 쓸 수 있습니다. Nginx는 이벤트 기반 구조라 동시 접속이 많을 때 메모리 효율과 성능이 좋아, 리버스 프록시·정적 파일 서버로 특히 많이 선택됩니다.

Q. 리버스 프록시와 로드밸런서는 같은 건가요?
겹치지만 같지는 않습니다. 로드밸런싱은 리버스 프록시가 제공하는 여러 기능 중 하나입니다. Nginx는 리버스 프록시로 동작하면서 upstream 블록으로 여러 서버에 부하를 분산하는 로드밸런서 역할도 함께 할 수 있습니다.

Q. 앱 서버에 직접 HTTPS를 붙이면 안 되나요?
가능하지만, 서버가 여러 대면 인증서를 각각 관리해야 하고 갱신도 번거롭습니다. Nginx 한 곳에서 SSL을 종료하면 인증서 관리가 단순해지고, 뒤쪽 서버 구성을 자유롭게 바꿀 수 있습니다.

마무리

리버스 프록시는 “사용자와 앱 서버 사이에 서는 대리 서버”라는 한 문장으로 요약됩니다. Nginx를 앞단에 두면 HTTPS·로드밸런싱·정적 파일·보안을 한곳에서 처리하고, 앱은 비즈니스 로직에만 집중할 수 있습니다. 처음에는 proxy_pass로 요청을 넘기는 최소 설정부터 익히고, 이후 upstream 로드밸런싱과 캐싱으로 확장해 나가면 됩니다.

더 읽어보기

이 글은 학습·정보 제공을 목적으로 작성되었습니다. 실제 서버 구성과 Nginx 버전에 따라 설정 문법은 달라질 수 있습니다.

Nginx 리버스 프록시란? 웹서버와 애플리케이션 서버를 연결하는 원리