Redirect, Rewrite, Host Header Forwarding — 요청 전달 기법 완전 정리

웹 서비스나 API 게이트웨이를 운영하다 보면, 트래픽을 다른 서버나 경로로 전달하거나 내부적으로 라우팅하는 기법을 자주 다루게 됩니다.

대표적인 것이 Redirect, Rewrite, Host Header Forwarding인데, 이름은 비슷해도 동작 원리와 목적은 꽤 다릅니다.

이 글에서는 이 세 가지를 포함해 DevOps·Infra 환경에서 자주 사용하는 관련 기술들을 한 번에 정리합니다.

---

1️⃣ Redirect (리다이렉트)

Redirect는 클라이언트(브라우저 등)에게 “이 주소로 다시 요청해 주세요”라고 알려주는 방식입니다.

즉, 서버가 301, 302, 307 등의 HTTP 상태 코드를 반환하며, 클라이언트가 새 URL로 재요청을 보내게 됩니다.

💡 예시 (Nginx)

return 301 https://new.example.com$request_uri;

✅ 장점

• 구현이 간단하고 표준적
• SEO-friendly (특히 301 Permanent Redirect)

⚠️ 단점

• 클라이언트가 재요청해야 하므로 지연 발생
• 브라우저 주소가 변경됨 (내부 구조 노출)

---

2️⃣ Rewrite (리라이트)

Rewrite는 URL을 서버 내부에서 다른 경로로 바꾸는 기술입니다.

사용자는 원래 URL을 그대로 보지만, 서버 내부에서는 다른 경로나 리소스로 요청이 전달됩니다.

💡 예시 (Nginx)

rewrite ^/app/(.*)$ /api/v1/$1 break;

✅ 장점

• 클라이언트 입장에서는 URL이 변하지 않음
• 내부 라우팅, 버전 구분 등에 유용

⚠️ 단점

• 디버깅이 어려움 (로그에 실제 요청 경로가 보이지 않음)
• 복잡한 규칙이 많아지면 유지보수 어려움

---

3️⃣ Host Header Forwarding

Host Header Forwarding은 요청 헤더의 Host 값을 조작하거나 그대로 전달하여

프록시 뒤의 백엔드가 어떤 도메인으로 요청되었는지 인식할 수 있도록 하는 기술입니다.

예를 들어, a.example.com으로 들어온 요청을

내부의 b.internal.local 서버로 전달하면서도 Host: a.example.com을 유지시킬 수 있습니다.

💡 예시 (Nginx)

proxy_set_header Host $host;
proxy_pass <http://backend-service>;

✅ 장점

• 멀티도메인 환경에서 단일 백엔드 처리 가능
• 도메인 기반 라우팅 및 멀티테넌시 구현에 유용

⚠️ 단점

• 헤더 위조 공격 가능성 (보안 강화 필요)
• 백엔드가 Host 의존적인 경우 설정 오류 위험

---

4️⃣ Reverse Proxy (리버스 프록시)

Reverse Proxy는 서버 앞단에서 클라이언트 대신 백엔드 서버에 요청을 전달하는 구조입니다.

Nginx, CloudFront, API Gateway, ALB 모두 이 역할을 수행할 수 있습니다.

✅ 장점

• SSL 오프로딩, 캐싱, 보안 강화 가능
• 로드밸런싱 및 장애 격리에 유용

⚠️ 단점

• 프록시 계층이 늘어나면 성능 저하
• 설정 복잡도 증가

---

5️⃣ Path-based / Header-based Routing

이 방식은 API Gateway나 ALB에서 흔히 사용하는 고급 라우팅 기법입니다.

 

구분	설명	예시
Path-based Routing	요청 경로에 따라 다른 백엔드로 분기	/api/* → API 서버, /img/* → CDN
Header-based Routing	헤더값에 따라 다른 백엔드로 전달	X-Version: v2 → 신규 서비스

이 두 가지는 A/B 테스트, 버전별 Canary 배포 등에 유용합니다.

---

🔧 그 외 자주 사용하는 관련 기술

 

기술	설명	사용 예시
Forward Proxy	내부 사용자가 외부로 나갈 때 요청을 대신 전달	기업 방화벽, 보안 게이트웨이
DNS Forwarding (CNAME)	DNS 레벨에서 트래픽 분산	api.example.com → alb.example.net
Response Rewrite (Substitution)	백엔드 응답의 링크를 외부 주소로 변경	Nginx sub_filter, Istio EnvoyFilter

---

⚖️ 기술별 장단점 비교표

 

구분	Redirect	Rewrite	Host Header Forwarding	Reverse Proxy	Path Routing
계층	HTTP 응답	서버 내부	HTTP 헤더	L7	L7
URL 변화 여부	있음	없음	없음	없음	없음
동작 방식	새 요청 유도	내부 경로 변경	Host 헤더 유지/변경	요청 전달	요청 분기
주 사용 위치	웹 서버, CDN	웹 서버, 프록시	프록시, 로드밸런서	Nginx, CloudFront	ALB, API GW
장점	단순, 표준적	유연한 내부 처리	멀티도메인 지원	보안/성능 향상	Canary, API 분리
단점	재요청 발생	규칙 복잡	헤더 보안 주의	복잡성 증가	설정 다층화

---

🧭 정리 — 언제 어떤 방식을 써야 할까?

 

상황	추천 기술	이유
사용자가 다른 URL로 이동해야 함	Redirect	클라이언트에 새 주소 알려야 할 때
내부 라우팅만 변경 (URL 유지)	Rewrite	SEO 영향 없이 내부 경로만 조정
멀티 도메인 백엔드 운영	Host Header Forwarding	동일 백엔드로 다중 도메인 처리
API Gateway나 CDN 앞단 설계	Reverse Proxy + Path Routing	트래픽 분산, 보안, 캐싱 모두 가능

---

✍️ 마무리

이러한 요청 전달 기법들은 단일 서버 → 멀티 서비스 구조로 확장할 때 반드시 고려해야 하는 부분입니다.

특히 AWS, Nginx, Istio, CloudFront, API Gateway 같은 환경에서는

이 기법들이 “같이 동작하면서도 서로 다른 계층에서 역할을 수행”합니다.

👉 간단한 요령

• 외부에서 URL이 바뀌면 Redirect
• 내부에서만 바꾸면 Rewrite
• 도메인 그대로 유지하려면 Host Header Forwarding