14-4. Origin / CORS / nginx

Feb 26, 2026

1. Origin / Upstream / Downstream

1️⃣ Origin (출처)

1) Origin 이란?

Origin = 프로토콜 + 도메인 + 포트


https://example.com:443

2) 구성 요소

Scheme (Protocol) → http / https

Host (Domain) → example.com

Port → 80 / 443 / 3000 등

➡️ 셋 중 하나라도 다르면 다른 Origin

URL	Same Origin?
https://example.com/api	✅
http://example.com/api	❌ (scheme 다름)
https://api.example.com	❌ (host 다름)
https://example.com:3000	❌ (port 다름)

2️⃣ Upstream

1) Upstream 이란?

Upstream = 서버 관점에서 요청을 전달하는 대상 서버

➡️ 현재 서버가 의존하는 뒤쪽 서버

2) 대표 사례

Reverse Proxy

API Gateway

Load Balancer 뒤의 서버

3) 예


Client → Nginx → Backend Server

Nginx 기준 → Backend = Upstream

3️⃣ Downstream

1) Downstream 이란?

Downstream = 요청을 보내는 쪽 / 앞단

2)예


Client → Nginx → Backend

Backend 기준 → Nginx / Client = Downstream

➡️ 상대적 개념 (관점 중요)

2. Same Origin / Cross Origin

1️⃣ Same Origin

1) Same Origin 이란?

Protocol + Host + Port 모두 동일 (브라우저 기준)


https://example.com → https://example.com/api

제약 없음

쿠키 / LocalStorage 접근 가능

2️⃣ Cross Origin

1) Cross Origin 이란?

Protocol + Host + Port 셋 중 하나라도 다름


https://example.com → https://api.example.com

2) 브라우저 기본 정책

Same-Origin Policy (SOP) 적용

3) 제약

AJAX 요청 제한

쿠키 접근 제한

DOM 접근 제한

3. CORS (Cross-Origin Resource Sharing)

1️⃣ 개념

브라우저 보안 정책 완화 메커니즘

서버가 명시적으로 허용해야 함

2️⃣ 동작 흐름

1) Simple Request

조건

GET / POST
특정 Safe Header만 사용

흐름


Browser → Request (Origin 포함)
Server → Response (Access-Control-Allow-Origin)


Access-Control-Allow-Origin: https://example.com

2) Preflight Request (OPTIONS)

조건

PUT / DELETE
Custom Header
JSON Content-Type 등

흐름


Browser → OPTIONS 요청
Server → 허용 여부 응답
Browser → 실제 요청

3️⃣ 주요 헤더

Header	역할
Access-Control-Allow-Origin	허용 Origin
Access-Control-Allow-Methods	허용 HTTP Method
Access-Control-Allow-Headers	허용 Header
Access-Control-Allow-Credentials	쿠키 허용 여부

4️⃣ ⚠ 흔한 오류

1) ❌ 와일드카드 + Credentials


Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true

➡️ 불가능 조합

✔ Credentials 사용할 경우 → Origin 명시 필수

4. nginx 핵심 정리

1️⃣ nginx

1) nginx 란?

nginx = 고성능 웹 서버 / 리버스 프록시 / 로드 밸런서

nginx는 요청을 직접 처리하기도 하고, 다른 서버로 똑똑하게 전달하는 프론트 역할 서버

2) 주요 용도

Reverse Proxy

Static File Server

Load Balancer

SSL Termination

CORS 처리

2️⃣ 현실 비유로 이해하기

1) nginx 없는 구조


Client → Backend Server

문제점

❌ 트래픽 몰리면 서버 과부하

❌ 정적 파일 처리 비효율

❌ SSL 처리 부담

❌ 보안 취약

❌ 확장 어려움

2) nginx 있는 구조


Client → nginx → Backend Server(s)

➡️ nginx가 중간 관리자 역할 수행

3️⃣ nginx가 하는 핵심 역할들

1) Reverse Proxy (가장 중요 ⭐)

요청을 대신 받아서 Backend로 전달


Client → Nginx → Backend

장점

보안 (Backend 숨김)
로드 분산
SSL 처리 집중화
캐싱 가능

왜 필요할까?

Backend 서버를 직접 노출하지 않음

✔ 보안 강화

✔ 서버 구조 숨김

✔ 트래픽 제어 가능

2) Load Balancer

여러 서버로 트래픽 분산


Client → nginx → Server A / Server B / Server C

✔ 서버 과부하 방지

✔ 장애 대응

✔ 확장성 확보

3) Static File Server

이미지 / CSS / JS 같은 파일 초고속 제공

Backend까지 안 감

✔ 빠름

✔ 리소스 절약

✔ 비용 절감

4) SSL Termination

HTTPS 처리 담당


Client (HTTPS) → nginx → Backend (HTTP)

✔ Backend 부담 감소

✔ 인증서 관리 집중화

✔ 성능 향상

5) Traffic Control / Security

필터 & 방어막 역할

✔ Rate Limiting

✔ IP 차단

✔ Bot 방어

✔ 요청 크기 제한

6) Caching

응답 저장 후 재사용

✔ 속도 향상

✔ Backend 부하 감소

4️⃣ nginx를 쉽게 정의하면

nginx = "스마트 관제탑"

요청 접수

어디로 보낼지 결정

트래픽 분산

빠르게 응답

보안 처리

최적화 수행

6️⃣ Upstream 설정 예시


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

server {
    location / {
        proxy_pass http://backend;
    }
}

로드 밸런싱

장애 서버 자동 제외 가능

7️⃣ CORS 처리 예시


location /api/ {
    add_header Access-Control-Allow-Origin https://example.com;
    add_header Access-Control-Allow-Methods "GET, POST, OPTIONS";
    add_header Access-Control-Allow-Headers "*";

    if ($request_method = OPTIONS) {
        return 204;
    }

    proxy_pass http://backend;
}

Preflight 대응

서버 단에서 CORS 제어 가능

8️⃣ nginx가 자주 쓰이는 이유

이벤트 기반 → 고성능

낮은 메모리 사용량

대규모 트래픽 대응

DevOps / Infra 표준급

9️⃣ 설치 방법

nginx: download

https://nginx.org/en/download.html

html :

conf :

Spring Boot