[Infra Ops] Nginx 리버스 프록시와 로드밸런싱 설정

"프록시"라는 단어가 같아서 혼동하기 쉽지만, 포워드 프록시와 리버스 프록시는 트래픽이 흐르는 방향과 보호하는 대상이 완전히 다릅니다. 실무에서 "Nginx를 프록시로 써라"는 말을 들었을 때, 클라이언트를 대신하는 역할인지 서버를 보호하는 역할인지 구분하지 못하면 설정 방향 자체가 틀려집니다. 리버스 프록시의 핵심은 백엔드 서버를 인터넷에 직접 노출하지 않고, 트래픽 제어를 한 지점에서 처리한다는 것입니다.

확대

왜 "리버스"라는 단어가 붙었을까요? 방향이 반대이기 때문입니다. 포워드 프록시는 클라이언트 앞에 서서 내부 사용자가 외부 인터넷에 나가는 트래픽을 대신 처리합니다 (사내 방화벽, VPN이 대표적). 리버스 프록시는 서버 앞에 서서 외부 클라이언트가 내부 서버로 들어오는 트래픽을 받습니다.

클라이언트 입장에서는 Nginx 뒤에 백엔드 서버가 몇 대 있는지, 어떤 언어로 짜여 있는지 알 수 없습니다. 이 불투명성이 보안, 부하분산, 캐싱, SSL 종단 처리를 한 곳에서 해결하는 구조를 만듭니다.

# 리버스 프록시 가장 기본 형태
server {
    listen 80;
    server_name example.com;

    location / {
        proxy_pass http://127.0.0.1:8080;  # 백엔드 서버로 전달
    }
}

location / { proxy_pass http://app_servers; } 한 줄이면 트래픽이 백엔드로 넘어갑니다. 하지만 그 한 줄 뒤에서 Nginx는 요청을 받고 → 어느 upstream에 보낼지 고르고 → 헤더를 다시 쓰고 → 백엔드에 연결하고 → 응답을 받아 중계하는 6단계를 밟습니다. 이 단계를 알아야 "왜 백엔드 로그에 클라이언트 IP가 안 남지", "왜 502지", "왜 504지"가 각각 어느 단계의 문제인지 짚을 수 있습니다.

[클라이언트]  GET /api/order  (Host: shop.example.com)
   │
   ① 요청 수신          Nginx가 클라이언트 연결 종단 (여기서 remote_addr = 클라이언트 IP)
   │
   ② location 매칭      /api/ location → proxy_pass http://app_servers 결정
   │
   ③ upstream 선택      app_servers 풀에서 알고리즘(round-robin·least_conn·ip_hash)으로 1대 선택
   │
   ④ 헤더 재작성        Host·X-Real-IP·X-Forwarded-For 세팅 후 백엔드 전달 요청 구성
   │
   ⑤ 백엔드 연결·전송    선택된 WAS로 TCP 연결(또는 keepalive 재사용) → 요청 송신
   │
   ⑥ 응답 중계·버퍼링    백엔드 응답을 buffer에 받아 클라이언트로 전달 (proxy_buffering)
   ▼
[클라이언트]  200 / 502 / 504

각 단계에서 무슨 일이 일어나고, 막히면 어떤 증상인가:

즉 리버스 프록시의 상태코드는 어느 단계에서 백엔드와의 중계가 깨졌는지를 가리킵니다 — 502는 ③·⑤에서 백엔드에 아예 못 붙은 것(다운·격리·포트), 504는 ⑤·⑥에서 붙었지만 응답이 제 시간에 안 온 것(백엔드 처리 지연), "클라이언트 IP 유실"은 ④에서 헤더를 안 넘긴 것입니다. 그래서 502면 백엔드에 직접 curl로 붙어보고(⑤ 확인), 504면 $upstream_response_time으로 지연을 재고, IP 유실이면 nginx -T로 ④의 proxy_set_header 설정을 확인하는 식으로 단계별로 접근합니다.

proxy_pass만 설정하면 트래픽은 넘어가지만 문제가 생깁니다. 백엔드 서버는 요청을 보낸 주체가 클라이언트가 아니라 Nginx(127.0.0.1)라고 인식합니다. 이렇게 되면 접근 로그 분석, IP 기반 차단, 지역 기반 기능이 모두 망가집니다.

proxy_set_header는 이 문제를 해결합니다. Nginx가 실제 클라이언트 정보를 헤더에 담아 백엔드로 전달합니다. 실무에서 이 설정을 빠뜨리면 "왜 모든 접속이 내부 IP로만 찍히죠?"라는 질문이 나옵니다.

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

    location / {
        proxy_pass http://127.0.0.1:8080;

        # 실제 클라이언트 IP를 백엔드에 전달
        proxy_set_header X-Real-IP $remote_addr;

        # 프록시 체인 전체 IP 목록 (여러 프록시를 거쳤을 때 유용)
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

        # 원본 Host 헤더 전달 (백엔드가 가상호스트 기반일 때 필수)
        proxy_set_header Host $host;

        # 백엔드가 HTTP/1.1을 사용하도록 강제 (기본값은 HTTP/1.0)
        proxy_http_version 1.1;

        # 프록시 연결 타임아웃
        proxy_connect_timeout 10s;
        proxy_send_timeout 60s;
        proxy_read_timeout 60s;
    }
}

자주 쓰는 Nginx 변수:

확대

WAS 서버를 3대로 늘렸는데 특정 서버에 요청이 몰려 CPU가 튀는 현상이 있었습니다. 파일 업로드 API라 요청 처리 시간이 일정하지 않았고, 라운드로빈으로는 "처리 중인 요청이 많은 서버"를 고려하지 못했기 때문입니다. 알고리즘을 least_conn으로 바꾸니 부하가 균등해졌습니다. upstream 블록 없이 여러 서버를 관리하면 설정이 복잡해지고 가중치, 헬스체크, 알고리즘 설정도 불가합니다.

Nginx 오픈소스 버전이 지원하는 세 가지 알고리즘은 각각 적합한 상황이 다릅니다.

# round-robin (기본값) — 순서대로 균등 분배
upstream app_backend {
    server 10.0.0.1:8080;
    server 10.0.0.2:8080;
    server 10.0.0.3:8080;
}

# weight — 서버 성능이 다를 때
upstream app_backend_weighted {
    server 10.0.0.1:8080 weight=3;  # 3배 더 많은 요청
    server 10.0.0.2:8080 weight=1;
}

# least_conn — 활성 연결이 적은 서버 우선
upstream app_backend_lc {
    least_conn;
    server 10.0.0.1:8080;
    server 10.0.0.2:8080;
}

# ip_hash — 같은 클라이언트는 같은 서버로 (세션 고정)
upstream app_backend_session {
    ip_hash;
    server 10.0.0.1:8080;
    server 10.0.0.2:8080;
}

알고리즘 선택 가이드:

채팅 기능을 배포했는데 연결이 5초마다 끊겼습니다. Nginx에 WebSocket 설정이 없어서 연결 유지가 안 됐기 때문입니다. proxy_http_version 1.1과 Upgrade 헤더 설정을 추가하니 연결이 지속됐습니다. WebSocket은 처음에 HTTP로 시작해 프로토콜 전환을 요청하는 구조라, Nginx가 이 헤더를 전달하지 않으면 백엔드가 전환을 거부합니다.

WebSocket은 일반 HTTP와 달리 연결을 끊지 않고 양방향으로 지속합니다. 채팅, 알림, 실시간 대시보드가 대표적입니다. 문제는 Nginx의 기본 프록시 설정이 WebSocket을 인식하지 못한다는 점입니다.

WebSocket 연결은 처음에 HTTP로 시작해 Upgrade: websocket 헤더로 프로토콜 전환을 요청합니다. Nginx가 이 헤더를 그냥 지나치면 백엔드는 프로토콜 전환을 거부하고 연결이 실패합니다. proxy_http_version 1.1과 Connection Upgrade 헤더 설정이 이 문제를 해결합니다.

확대

upstream ws_backend {
    server 127.0.0.1:3000;
    server 127.0.0.1:3001;
}

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

    # WebSocket 엔드포인트
    location /ws/ {
        proxy_pass http://ws_backend;

        # WebSocket 필수 설정
        proxy_http_version 1.1;
        proxy_set_header Upgrade    $http_upgrade;  # WebSocket Upgrade 헤더 전달
        proxy_set_header Connection "upgrade";       # 커넥션 유지

        proxy_set_header Host            $host;
        proxy_set_header X-Real-IP       $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

        # WebSocket은 연결이 오래 유지되므로 타임아웃 늘리기
        proxy_read_timeout 3600s;  # 1시간
        proxy_send_timeout 3600s;
    }

    # 일반 HTTP API는 별도 location
    location /api/ {
        proxy_pass http://ws_backend;
        proxy_set_header Host            $host;
        proxy_set_header X-Real-IP       $remote_addr;
        proxy_http_version 1.1;
    }
}

proxy_pass는 '어디로 보낼지'만 정합니다. '연결을 재사용할지, 응답을 어떻게 실어 나를지'는 keepalive와 버퍼링 설정이 정하는데, 이걸 모르면 부하가 커질 때 원인 모를 포트 고갈·502·스트리밍 지연을 만납니다.

• 기본은 매 요청마다 새 연결: proxy_pass만 쓰면 Nginx는 요청마다 백엔드로 TCP 연결을 새로 맺고 응답 후 닫습니다. 트래픽이 크면 Nginx→백엔드 사이에 짧게 살고 죽는 소켓이 폭증해, 닫힌 소켓이 TIME_WAIT로 쌓이고 로컬 포트(ephemeral port)가 고갈됩니다.
• keepalive는 조건부로만 켜집니다: upstream 블록의 keepalive N으로 유휴 연결 풀을 두면 연결을 재사용합니다. 그런데 이게 실제로 켜지려면 그 location에 proxy_http_version 1.1과 proxy_set_header Connection ""(hop-by-hop Connection 헤더 제거)가 함께 있어야 합니다. 둘 중 하나라도 없으면 Nginx는 백엔드에 Connection: close를 보내 매번 연결을 닫아버려, keepalive 32를 적어놨어도 무효입니다. 그리고 keepalive는 반드시 upstream 블록 안에 있어야 하며 server/location에 두면 동작하지 않습니다.
• 응답 버퍼링: 기본값 proxy_buffering on에서 Nginx는 백엔드 응답을 버퍼(proxy_buffers)에 받아 두었다가 클라이언트로 내보냅니다. 느린 클라이언트가 다 받기 전에 백엔드 연결을 먼저 놓아줄 수 있어 대개 유리하지만, 두 함정이 있습니다 — ① SSE·스트리밍·실시간 진행률은 버퍼링 탓에 '한꺼번에 몰려' 나올 수 있어 해당 location만 proxy_buffering off가 필요. ② 백엔드가 보낸 응답 헤더가 proxy_buffer_size보다 크면(거대한 Set-Cookie·토큰 등) upstream sent too big header로 502가 나므로 proxy_buffer_size·proxy_buffers를 키워야 합니다.

정리하면 리버스 프록시의 성능·안정성은 proxy_pass 한 줄이 아니라 '연결 재사용(keepalive)'과 '응답 실어나르기(buffering)'라는 두 내부 동작에서 갈립니다.