nginx 리버스 프록시: 완전한 설정 튜토리얼

nginx 리버스 프록시는 하나 이상의 백엔드 애플리케이션을 대신해 들어오는 요청을 받고, 각 요청을 올바른 백엔드로 전달한 뒤 응답을 클라이언트에 반환하는 nginx 서버입니다. 이 튜토리얼에서는 바로 복사해 사용할 수 있는 완전한 nginx 리버스 프록시 구성을 제공합니다. 전체 서버 블록과 proxy_pass, 전달 헤더, 업스트림 로드 밸런싱, SSL 종료, WebSocket 지원, 버퍼링 및 타임아웃 조정, gzip, 위치 기반 라우팅, 그리고 많은 사용자가 겪는 502 및 504 오류 해결 방법까지 다룹니다.

끝까지 따라 하면 실행 가능한 nginx 리버스 프록시 설정과 각 구성 요소가 어떻게 맞물리는지에 대한 이해를 갖추게 됩니다. 또한 nginx 리버스 프록시가 더 이상 적합한 도구가 아니고 포워드 프록시 또는 레지덴셜 프록시가 필요한 지점도 솔직하게 살펴봅니다.

DataImpulse는 195개국에서 9천만 개가 넘는 레지덴셜 프록시(residential proxy), 모바일 프록시, 데이터센터 프록시 IP 주소를 제공하는 윤리적 프록시 제공업체입니다. GB당 1달러부터 시작하는 종량제 모델과 만료되지 않는 트래픽을 사용하며, 웹 스크래핑, 광고 검증, 가격 모니터링, 시장 조사, 다중 계정 관리에 사용됩니다.

nginx는 리버스 프록시이며, 어떻게 작동합니까?

예. nginx는 가장 널리 배포된 리버스 프록시 중 하나이며, 리버스 프록싱은 추가 기능이 아니라 핵심 기능입니다. 리버스 프록시는 백엔드 서버 앞에 위치하여 공개 호스트 이름에서 클라이언트 연결을 받고, 클라이언트가 직접 보지 못하는 내부 애플리케이션으로 각 요청을 라우팅합니다.

구성 요소를 명확히 이해하기 위해 이 가이드에서는 간단한 이름의 모델을 사용합니다. 이를 nginx 리버스 프록시 5계층 모델이라고 하며, 아래의 모든 작동하는 구성은 이 계층들을 순서대로 쌓은 것입니다.

• 리스너. listen 지시어와 server_name은 이 블록이 처리할 요청을 결정합니다. 포트 80, 포트 443, 호스트 이름이 여기에 해당합니다.
• 위치 라우팅. location 블록은 들어오는 경로를 분리하므로 /api/, /static/, /를 각각 다른 곳으로 보낼 수 있습니다.
• 업스트림. upstream 블록은 백엔드 서버 풀과 로드 밸런싱 방식을 이름으로 정의합니다.
• 헤더. proxy_set_header 행은 원래 Host 및 클라이언트 IP를 보존하므로 백엔드는 nginx가 아닌 실제 요청을 확인합니다.
• TLS. listen 443의 ssl_certificate는 nginx에서 HTTPS를 종료하여 백엔드가 내부적으로 일반 HTTP를 사용할 수 있게 합니다.

두 프록시 방향 사이에서 아직 결정 중이라면 리버스 프록시와 포워드 프록시 설명에서 개념을 자세히 다룹니다. 이 글은 리버스 방식만 다룹니다. 외부로 나가는 클라이언트 측 설정은 관련 nginx 포워드 프록시 가이드를 참조하십시오.

시작하기 전에 무엇이 필요합니까?

nginx가 설치된 Linux 서버, 로컬 포트에서 수신 대기하는 백엔드 애플리케이션 하나 이상, 그리고 HTTPS용 TLS 인증서가 필요합니다. 리버스 프록싱은 표준 nginx 빌드만 사용하므로 사용자 지정 모듈이나 재컴파일이 필요하지 않습니다.

무엇이든 편집하기 전에 nginx가 설치되어 있고 구성이 유효한지 확인하십시오.

nginx -v
sudo nginx -t

nginx -t 테스트는 전체 구성을 해석하고 파일 및 행 번호와 함께 구문 오류를 보고합니다. nginx는 손상된 구성을 다시 로드하지 않고 이전 구성을 계속 실행하므로, 이 튜토리얼의 모든 변경 뒤에 실행하십시오. 배포판에 따라 리버스 프록시 서버 블록을 /etc/nginx/conf.d/ 또는 /etc/nginx/sites-available/에 넣고, 테스트가 통과하면 sudo nginx -s reload로 다시 로드하십시오. proxy_pass가 가리킬 대상이므로, 예를 들어 127.0.0.1:3000에서 실행되는 Node 또는 Python 앱 같은 백엔드 주소도 준비해야 합니다.

nginx 리버스 프록시는 단계별로 어떻게 설정합니까?

포트 80에서 수신 대기하고, proxy_pass로 모든 요청을 하나의 백엔드에 전달하며, 전달 헤더를 설정하는 단일 서버 블록부터 시작하십시오. 그다음 로드 밸런싱, TLS, WebSocket, 버퍼링, gzip을 추가합니다. 첫 번째 블록은 최소한으로 작동하는 nginx 리버스 프록시 설정입니다.

server {
    listen 80;
    server_name app.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;
    }
}

이 네 개의 proxy_set_header 행은 선택 사항이 아닙니다. 없으면 백엔드는 nginx를 클라이언트로 인식하고 잘못된 IP를 기록하며, 잘못된 리디렉션 URL을 만들 수 있습니다. Host는 요청한 호스트 이름을 보존하고, X-Real-IP 및 X-Forwarded-For는 실제 클라이언트 주소를 전달하며, X-Forwarded-Proto는 원래 요청이 HTTP인지 HTTPS인지 앱에 알려 줍니다.

업스트림 로드 밸런싱을 추가합니다. 여러 백엔드 인스턴스 앞에 두려면 upstream 블록을 정의하고 proxy_pass가 그 이름을 가리키게 하십시오. least_conn 방식은 활성 연결이 가장 적은 인스턴스로 각 요청을 보냅니다.

upstream app_backend {
    least_conn;
    server 10.0.0.11:3000;
    server 10.0.0.12:3000;
    server 10.0.0.13:3000 backup;
}

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

    location / {
        proxy_pass http://app_backend;
        proxy_set_header Host              $host;
        proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

backup 서버는 주 서버가 다운될 때만 트래픽을 받습니다. 스티키 세션이 필요하여 동일 클라이언트를 동일 백엔드에 고정해야 한다면 least_conn 대신 ip_hash를 사용하십시오.

포트 443에서 SSL을 종료합니다. 프로덕션 리버스 프록시는 HTTPS를 제공하고 일반 HTTP를 리디렉션해야 합니다. nginx가 TLS를 처리하므로 백엔드는 내부적으로 일반 HTTP를 유지할 수 있습니다.

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

    ssl_certificate     /etc/letsencrypt/live/app.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/app.example.com/privkey.pem;
    ssl_protocols       TLSv1.2 TLSv1.3;

    location / {
        proxy_pass http://app_backend;
        proxy_set_header Host              $host;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

server {
    listen 80;
    server_name app.example.com;
    return 301 https://$host$request_uri;
}

WebSocket을 지원합니다. WebSocket 연결은 HTTP로 시작한 뒤 업그레이드되므로 nginx는 Upgrade 및 Connection 헤더를 전달하고 HTTP/1.1을 사용해야 합니다. 실시간 경로에는 별도 위치를 부여하십시오.

location /ws/ {
    proxy_pass http://app_backend;
    proxy_http_version 1.1;
    proxy_set_header Upgrade    $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_set_header Host       $host;
    proxy_read_timeout 3600s;
}

긴 proxy_read_timeout은 유휴 소켓이 세션 중간에 닫히지 않게 하며, 이는 실시간 연결이 끊기는 흔한 원인입니다.

버퍼링과 타임아웃을 조정합니다. 기본값은 보수적입니다. 느린 백엔드는 앱이 응답하기 전에 nginx가 연결을 닫지 않도록 명시적 값의 이점을 얻습니다.

location / {
    proxy_pass http://app_backend;
    proxy_connect_timeout 5s;
    proxy_send_timeout    60s;
    proxy_read_timeout    60s;
    proxy_buffering       on;
    proxy_buffers         16 16k;
    proxy_buffer_size     32k;
}

gzip을 활성화합니다. 프록시된 응답을 압축하면 텍스트 자산의 대역폭을 줄입니다. 사이트 전체에 적용되도록 http 블록에 넣으십시오.

gzip on;
gzip_types text/plain text/css application/json application/javascript;
gzip_min_length 1024;
gzip_comp_level 5;

경로별로 라우팅합니다. 하나의 리버스 프록시는 서로 다른 위치 접두사를 서로 다른 업스트림과 일치시켜 여러 서비스를 처리하고, 백엔드를 거치지 않고 디스크에서 정적 파일을 직접 제공할 수 있습니다.

server {
    listen 80;
    server_name example.com;

    location /api/ {
        proxy_pass http://api_backend;
        proxy_set_header Host $host;
    }

    location /static/ {
        root /var/www/assets;
    }

    location / {
        proxy_pass http://web_backend;
        proxy_set_header Host $host;
    }
}

nginx 리버스 프록시가 작동하는지 어떻게 확인합니까?

nginx를 다시 로드한 다음 공개 호스트 이름으로 요청을 보내고 기본 nginx 페이지가 아니라 백엔드에서 응답하는지 확인하십시오. 오타로 사이트가 중단되지 않도록 먼저 구성을 테스트합니다.

sudo nginx -t && sudo nginx -s reload
curl -I http://app.example.com

응답 헤더의 200 또는 예상된 리디렉션은 라우팅이 작동한다는 뜻입니다. 백엔드가 전달 헤더를 수신하는지 증명하려면 액세스 로그 또는 에코 엔드포인트를 확인하고, 127.0.0.1이 아닌 X-Forwarded-For의 실제 클라이언트 IP가 보이는지 확인하십시오. DNS를 우회하고 호스트 이름을 위장하면서 프록시를 직접 대상으로 지정할 수도 있습니다.

curl -H "Host: app.example.com" http://127.0.0.1

HTTPS의 경우 curl -I https://app.example.com을 실행하여 인증서가 승인되고 요청이 다운그레이드되지 않는지 확인하십시오. 백엔드가 잘못된 스킴으로 링크 또는 리디렉션을 렌더링한다면, 이는 TLS 문제라기보다 거의 항상 X-Forwarded-Proto 헤더 누락입니다.

502 및 504 오류는 어떻게 해결합니까?

502 Bad Gateway는 nginx가 업스트림에 도달했지만 유효하지 않거나 거부된 응답을 받았다는 뜻이고, 504 Gateway Timeout은 업스트림이 연결을 수락했지만 제시간에 응답하지 않았다는 뜻입니다. 둘 다 nginx 버그가 아닌 업스트림 문제이며, 오류 로그에 정확한 원인이 표시됩니다. 요청을 재현하면서 실시간으로 확인하십시오.

sudo tail -f /var/log/nginx/error.log
# [error] connect() failed (111: Connection refused) while connecting to upstream

일반적인 원인을 다음 순서로 점검하십시오.

• 502, 연결 거부. 백엔드가 실행 중이 아니거나 proxy_pass 대상과 다른 주소 또는 포트에서 수신 대기 중입니다. 서버 자체에서 curl http://127.0.0.1:3000으로 확인하십시오.
• 502, SELinux 또는 방화벽. RHEL 계열 시스템에서는 setsebool -P httpd_can_network_connect 1을 실행하기 전까지 SELinux가 nginx의 외부 연결 열기를 차단합니다.
• 504, 느린 백엔드. 앱의 응답 시간이 proxy_read_timeout보다 깁니다. 전역적으로 가리기보다 해당 위치의 타임아웃을 늘리거나 느린 쿼리를 수정하십시오.
• 502, 큰 헤더. 큰 응답 헤더를 보내는 백엔드는 프록시 버퍼를 초과할 수 있습니다. proxy_buffer_size 및 proxy_buffers를 늘리십시오.
• 잘못 선택된 업스트림. 업스트림 풀의 서버 하나가 다운되면 nginx는 이를 비정상으로 표시하고 다음 서버를 재시도하므로, 간헐적 502는 흔히 단일 비정상 백엔드를 가리킵니다.

어떤 리버스 프록시가 적합하며, 언제 다른 프록시가 필요합니까?

자체 서버 앞에서 TLS를 종료하거나 로드 밸런싱 또는 경로 라우팅을 할 때는 nginx 리버스 프록시를 사용하십시오. 많은 IP에서 외부 요청을 보내는 작업에는 포워드 프록시 또는 레지덴셜 프록시를 사용해야 합니다. nginx는 인바운드 작업에 탁월하며 아웃바운드 작업용으로 설계되지 않았습니다. 다음은 결정 매트릭스입니다.

• nginx 리버스 프록시를 사용할 때 백엔드를 호스팅하고, 여러 내부 서비스 앞에 하나의 공개 HTTPS 엔드포인트를 원하며, 인스턴스 간 로드 밸런싱이 필요하거나 엣지에서 캐싱 및 gzip을 원할 때입니다.
• 프록시로 nginx를 피해야 할 때 많은 서로 다른 IP 또는 국가에서 온 것처럼 보여야 하는 아웃바운드 요청이 목표인 경우입니다. 리버스 프록시는 단일 서버 IP에서 나가며 주소를 로테이팅할 수 없기 때문입니다.

리버스 프록시만 비교하면 nginx, Caddy, HAProxy는 서로 다른 절충점을 제공합니다.

대규모 아웃바운드 자동화는 웹 스크래핑 모범 사례 가이드에서 로테이션과 속도 제어를 다루며, 비용 또는 통신사 IP가 레지덴셜 IP의 실제성보다 중요할 때는 데이터센터 프록시 또는 모바일 프록시가 적합합니다.

nginx 리버스 프록시의 한계와 위험은 무엇입니까?

nginx 리버스 프록시는 인바운드 트래픽에 강력하지만 실제 한계가 있습니다. 아웃바운드 IP를 로테이팅할 수 없고, 잘못 구성된 헤더는 클라이언트를 노출하거나 숨기며, 패치와 모니터링이 필요한 운영 구성 요소를 추가합니다. 이를 알면 기대치를 현실적으로 유지할 수 있습니다.

• 단일 출구 IP. 프록시에서 나가는 모든 아웃바운드 요청은 서버 자체 IP를 통과하므로 리버스 프록시는 많은 원본 주소가 필요한 작업에 도움이 될 수 없습니다.
• 헤더 실수는 조용합니다. X-Forwarded-For를 빠뜨리면 앱과 속도 제한에서 실제 클라이언트 IP가 숨겨지고, X-Forwarded-Proto를 빠뜨리면 HTTPS 리디렉션이 중단됩니다. nginx는 경고하지 않습니다.
• TLS 및 인증서 관리. 인증서는 만료되므로 일반적으로 certbot과 cron 작업 또는 systemd 타이머를 통해 갱신 및 다시 로드를 관리해야 합니다.
• 새로운 장애 지점. 이제 프록시가 핵심 경로에 있으므로 다운되면 뒤에 있는 모든 백엔드에 도달할 수 없습니다. 그래서 상태 확인과 모니터링이 중요합니다.
• 아웃바운드 익명화 도구가 아닙니다. 리버스 프록시는 요청의 출처를 숨기도록 만들어지지 않았습니다. 이는 포워드 프록시의 역할입니다.

nginx는 DataImpulse 제품이 아니며, DataImpulse는 관리형 스크래핑 API 또는 무료 웹 프록시를 판매하지 않습니다. 적합한 곳에서는 직접 nginx를 실행하십시오. 아웃바운드 규모가 필요한 경우 DataImpulse는 옵트인하고 보상을 받는 사용자로부터 IP를 윤리적 프록시로 확보합니다. 최종 업데이트: 2026-07-22.

자주 묻는 질문

관련 가이드

• NGINX 포워드 프록시
• Cloudflare 리버스 프록시
• Docker 리버스 프록시

nginx가 로테이팅할 수 없는 아웃바운드 IP가 필요하십니까?

리버스 프록시는 인바운드 트래픽을 처리하지만, 작업에 많은 실제 IP에서 나가는 아웃바운드 요청이 필요하면 DataImpulse는 195개국에서 90M+ 로테이팅 레지덴셜 프록시, 모바일 프록시, 데이터센터 프록시 IP를 제공합니다. GB당 1달러부터의 종량제이며 트래픽은 만료되지 않습니다. 계정 만들기로 게이트웨이 자격 증명을 받아 클라이언트를 풀로 라우팅하십시오.