Nginx를 리버스 프록시로 설정하는 방법

Linux 서버에서 Nginx를 리버스 프록시로 구성하는 완전하고 정확한 가이드입니다. 프록시 헤더, WebSocket, HTTPS, 로드 밸런싱, 캐싱을 다루며 그대로 복사해 사용할 수 있는 프로덕션 수준의 설정을 제공합니다.

리버스 프록시의 역할

리버스 프록시는 하나 이상의 백엔드 애플리케이션 앞에 위치하여 클라이언트 요청을 백엔드로 전달합니다. 애플리케이션 서버(Node.js, Python, PHP-FPM, Docker 컨테이너)를 인터넷에 직접 노출하는 대신, 클라이언트는 Nginx와 통신하고 Nginx는 비공개 주소를 통해 애플리케이션과 통신합니다.

이를 통해 단일 공개 진입점을 확보하게 되며, 여기에서 TLS 종료, 여러 백엔드 간 트래픽 분산, 응답 캐싱, 속도 제한 적용, 내부 토폴로지 은닉을 수행할 수 있습니다. 이는 프로덕션 웹 애플리케이션의 표준 패턴이며, 데이터가 PDPL 및 NCA 정렬을 위해 국내(in-Kingdom)에 보관되는 Skyline Cloud의 VPS 또는 클라우드 서버와 자연스럽게 어울립니다.

이 가이드는 Ubuntu/Debian 경로를 사용하지만, 모든 디렉티브는 RHEL 계열 시스템에서도 동일하게 적용됩니다.

사전 준비 사항

• sudo 액세스 권한이 있는 Linux 서버(Skyline Cloud VPS 또는 클라우드 서버가 적합합니다).
• 이미 실행 중이며 로컬에서 수신 대기 중인 백엔드 애플리케이션 — 예를 들어 127.0.0.1:3000.
• 서버의 공개 IP를 가리키는 A 레코드가 설정된 도메인(예: .sa 도메인).

1단계 — Nginx 설치

sudo apt update
sudo apt install nginx -y

실행 중이며 부팅 시 활성화되어 있는지 확인합니다:

sudo systemctl status nginx
sudo systemctl enable nginx

UFW를 사용하는 경우 방화벽을 엽니다:

sudo ufw allow 'Nginx Full'

2단계 — 리버스 프록시 서버 블록 생성

Nginx는 /etc/nginx/conf.d/에서 .conf로 끝나는 모든 파일을 로드하며, Debian/Ubuntu에서는 /etc/nginx/sites-enabled/도 읽습니다. 기본 설정을 건드리지 않도록 전용 파일을 만듭니다:

sudo nano /etc/nginx/conf.d/app.conf

다음 내용을 추가하되, app.example.com과 백엔드 주소를 본인의 값으로 교체합니다:

server {
    listen 80;
    listen [::]:80;
    server_name app.example.com;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_http_version 1.1;

        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 60s;
        proxy_send_timeout    60s;
        proxy_read_timeout    60s;
    }
}

각 헤더가 중요한 이유

3단계 — 테스트 및 리로드

설정을 적용하기 전에 항상 검증하세요. 이렇게 하면 사이트가 다운되기 전에 구문 오류를 잡아낼 수 있습니다:

sudo nginx -t

syntax is ok와 test is successful이 표시되어야 합니다. 그런 다음 리로드합니다 — reload는 restart와 달리 설정을 우아하게 다시 읽어 들이며 중단을 거의 일으키지 않습니다:

sudo systemctl reload nginx

http://app.example.com에 접속하면 Nginx를 통해 제공되는 백엔드 애플리케이션을 볼 수 있습니다.

4단계 — WebSocket 지원

애플리케이션이 WebSocket(채팅, 실시간 대시보드, 개발 서버)을 사용하는 경우 Upgrade와 Connection 헤더를 전달해야 하며, 그렇지 않으면 연결이 프로토콜 전환에 실패합니다. 동일한 location 블록 안에 다음을 추가합니다:

        proxy_set_header Upgrade    $http_upgrade;
        proxy_set_header Connection "upgrade";

이 동작이 작동하려면 2단계의 proxy_http_version 1.1; 줄이 필요합니다.

5단계 — 무료 인증서로 HTTPS 추가

TLS를 Nginx에서 종료하여 백엔드는 내부적으로 일반 HTTP만 처리하도록 합니다. Certbot을 설치하고 SSL을 자동으로 구성하도록 합니다:

sudo apt install certbot python3-certbot-nginx -y
sudo certbot --nginx -d app.example.com

Certbot은 서버 블록을 편집하여 listen 443 ssl 서버를 추가하고 자동 갱신 타이머를 설정합니다. 드라이런으로 갱신이 작동하는지 확인합니다:

sudo certbot renew --dry-run

HTTP/2를 활성화하려면 SSL 블록의 listen 줄을 버전 호환 형식으로 변경합니다:

    listen 443 ssl http2;

별도의 http2 on; 디렉티브 대신 listen 443 ssl http2;를 사용하세요 — 이 결합 형식은 현재의 모든 Nginx 버전에서 작동합니다.

6단계 — 여러 백엔드에 걸친 로드 밸런싱

여러 애플리케이션 인스턴스에 트래픽을 분산하려면 upstream 그룹을 정의하고 이름으로 프록시합니다. upstream 블록은 server 바깥, 파일 맨 위에 배치합니다:

upstream backend_pool {
    least_conn;
    server 127.0.0.1:3000;
    server 127.0.0.1:3001;
    server 127.0.0.1:3002 backup;
    keepalive 32;
}

server {
    listen 80;
    server_name app.example.com;

    location / {
        proxy_pass http://backend_pool;
        proxy_http_version 1.1;
        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_set_header Connection        "";
    }
}

• least_conn은 각 요청을 활성 연결 수가 가장 적은 백엔드로 보냅니다. 기본값(디렉티브 없음)은 라운드 로빈입니다.
• backup은 다른 서버가 모두 다운되었을 때만 사용되는 서버를 표시합니다.
• keepalive 32는 업스트림 연결을 재사용합니다. 이를 사용할 때는 요청마다 연결이 닫히지 않도록 proxy_set_header Connection "";를 설정합니다.

7단계 — 백엔드 응답 캐싱(선택 사항)

캐싱은 사용자별로 변하지 않는 콘텐츠에 대해 애플리케이션의 부하를 줄여줍니다. http 컨텍스트(예: /etc/nginx/nginx.conf)에 캐시 저장소를 정의합니다:

proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=app_cache:10m
                 max_size=1g inactive=60m use_temp_path=off;

그런 다음 location 블록 안에서 이를 참조합니다:

        proxy_cache       app_cache;
        proxy_cache_valid 200 302 10m;
        proxy_cache_valid 404 1m;
        add_header X-Cache-Status $upstream_cache_status;

X-Cache-Status 응답 헤더는 HIT, MISS, 또는 BYPASS를 보고하므로 브라우저의 네트워크 탭에서 캐싱을 확인할 수 있습니다.

문제 해결

• 502 Bad Gateway — 백엔드에 접근할 수 없습니다. ss -tlnp | grep 3000으로 수신 대기 중인지 확인하고, proxy_pass의 주소가 일치하는지 확인하세요.
• 504 Gateway Timeout — 백엔드가 느립니다. proxy_read_timeout을 늘리세요.
• HTTPS 뒤에서 애플리케이션이 http:// 링크를 생성함 — X-Forwarded-Proto $scheme가 설정되어 있고 애플리케이션이 이를 신뢰하는지 확인하세요.
• 로그를 확인하세요: sudo tail -f /var/log/nginx/error.log.

마무리

이제 프로덕션 수준의 리버스 프록시를 갖추게 되었습니다: TLS 종료, 올바른 클라이언트 헤더, WebSocket 지원, 로드 밸런싱, 그리고 선택적 캐싱. 사용자 및 데이터와 가까운 곳에서 실행하세요 — Skyline Cloud는 PDPL/NCA 정렬, 현지 아랍어 지원, 투명한 요금제와 함께 모든 것을 국내(in-Kingdom)에서 호스팅합니다. 이 프록시를 관리형 비즈니스 이메일 호스팅과 결합하여 완전한 스택을 구성하고, 사우디 웹 호스팅 허브에서 더 많은 가이드를 살펴보세요.

배포할 준비가 되셨나요? Skyline Cloud 계정을 만들고 몇 분 안에 VPS를 시작하세요.