Redirect vs Rewrite, 어느 레이어에서 처리할까

문제 상황

1. 메일 작성 도중 링크 작성 후 마침표를 찍는 경우, 마침표가 링크에 들어가 404 반환
2. 신규 주소의 경우, search parameter로 특정 id를 받는데, 이전 주소의 경우 해당 parameter가 없어 항상 404를 반환

모두 리다이렉트, 혹은 리라이트를 해야하는 상황이었다. 하지만 리다이렉트, 리라이트의 구분을 알지 못하였고, Cloudflare -> CloudFront -> NextJS 서버를 통해 들어오는 구조, 즉 어디서 리다이렉트, 리라이트를 해야할지 구분이 가지 않았다.

따라서 아래의 내용을 정리한다.

1. Redirect, Rewrite의 차이점
2. Redirect, Rewrite의 사용 Layer
3. Redirect, Rewrite의 사용 용도

1. Redirect, Rewrite의 차이점

Redirect는 서버가 클라이언트에게 "이 주소 말고 저 주소로 다시 요청해"라고 알려주는 방식이다. 300번대 응답 코드를 통해 새 URL을 전달한다.

Rewrite의 경우, server에서 요청을 받으면 내부에서 다른 주소로 처리를 하여서 응답을 반환한다. 즉 200 ok를 반환하게 된다.

	Redirect	Rewrite
요청횟수	2회	1회
주소창 URL	변경	유지
SEO 영향	O	X
처리 위치	client + server	server

2. Redirect, Rewrite의 사용 Layer

문제는 여기였다. 레이어가 많아 어디서 처리할지 결정하기 어렵고, 규칙이 난잡하게 모여있었다.

따라서, 용도에따라 규칙을 정하고 어느 레이어에서 리다이렉트 할지 정해야했다. 아래의 규칙을 작성하였다.

Layer	Redirection Performance	Rewrite Performance	Usage
CDN/Edge	매우 빠름 (오리진 불필요)	빠름 (엣지 프록시)	URL 정규화
리버스 프록시	빠름	빠름	MSA 라우팅, 배포 전략
앱 서버	느림 (앱 로직 거침)	느림 (앱 로직 거침)	인증 분기, 비즈니스 로직

 

Redirect HTTP Code

Code	HTTP Message	Description
301	Moved Permanently	영구 리다이렉션 (메서드 변경 가능성 O)
302	Found	임시 리다이렉션 (메서드 변경 가능성 O)
303	See Other	메서드가 GET으로 반환됨
304	Not Modified	캐싱된 항목
307	Temporary Redirect	임시 리다이렉션 + 메서드 유지
308	Permanent Redirect	영구 리다이렉션 + 메서드 유지

 

 

3. Redirect, Rewrite 사용 용도

SEO - Redirect

도메인 변경시 SEO를 신규 도메인으로 이전 도메인의 SEO점수를 이전할 경우 Redirect를 사용한다.

반드시 301 code로 영구 리다이렉트라는것을 Crawler에 알려야 해당 링크를 삭제 후, 새로운 링크를 등록한다. 

302 redirect시 임시 리다이렉트로 판단, 새로운 도메인이 SEO에 반영되지 않는다. 

 

Rewrite로 처리시 애초에 Crawler는 도메인 변경을 감지할 수 없으며, SEO반영이 되지 않는다. 

 

 

배포 전략 - Rewrite

배포전략을 사용할 시, 사용자에게 URL이 변경됨을 알려줄 필요가 없다. 이 경우 Rewrite를 사용해서 진행한다. 

nginx 에서 Rewrite전략을 사용하며 예시는 아래와 같다.

 

A/B테스트, Blue Green 배포 시 Rewrite를 사용하여 사용자에게 다른 컨텐츠를 같은 url내에서 보여줄 경우 사용할 수 있다.

# A/B 테스트
if($cookie_ab_test="new") {
  proxy_pass http://v2;
}
proxy_pass http://v1;

# Blue Green Deploy
upstream backend {
  server blue-v1:3000;
}

upstream backend {
  server green-v2:3000;
}

 

 

SPA Fallback - Rewrite

React와 같은 Single Page Application에서도 Rewrite를 사용한다.

React build의 결과물은 index.html과 js, css가 전부인데, router등의 path가 붙을 경우 해당 URL의 경로에 파일이 없어 404를 반환해버리기 때문이다.  

개발시, vercel netlify등의 플랫폼을 사용시 해당 내용을 플랫폼에서 자동으로 처리해주기 때문에 이 동작을 인식하기 어렵다.

 

Vite, Webpack을 사용시, 개발서버 내에서 spa fallback을 지원하는 코드가 들어가있다.

{
  server: {
    historyApiFallback: true  // 모든 경로 → index.html
  }
}

 

또한 vercel, netlify에서는 각 프레임워크를 감지하여, index.html으로 rewrite하는 옵션을 자동으로 제공한다.

 

nginx등을 통해 직접 배포할 경우 모든 url을 index.html 컨텐츠를 제공하는 방식으로 rewrite해줘야한다. 

# Nginx
location / {
    try_files $uri $uri/ /index.html;
}

 

 

문제 해결을 위해

우리의 문제는 따라서, redirect방식으로 해결한다. 

1. 도메인이 변경되었다.

2. 해당 url이 변경됨을 유저가 알고, 북마크를 변경하는 등의 작업이 필요하다. 

 

따라서 Redirect 방식으로 진행하되

 

1. 마침표 문제의 경우 CDN단에서 . 제거하는 로직을 넣은 redirect를 제공한다.

2. 이전 주소에는 id parameter가 없으므로, DB에서 조회해서 새 주소로 리다이렉트한다

 

즉 CDN layer와 App layer에서 각각 리다이렉트하는 방식으로 문제를 해결하였다.