문제 상황
- 메일 작성 도중 링크 작성 후 마침표를 찍는 경우, 마침표가 링크에 들어가 404 반환
- 신규 주소의 경우, search parameter로 특정 id를 받는데, 이전 주소의 경우 해당 parameter가 없어 항상 404를 반환
모두 리다이렉트, 혹은 리라이트를 해야하는 상황이었다. 하지만 리다이렉트, 리라이트의 구분을 알지 못하였고, Cloudflare -> CloudFront -> NextJS 서버를 통해 들어오는 구조, 즉 어디서 리다이렉트, 리라이트를 해야할지 구분이 가지 않았다.
따라서 아래의 내용을 정리한다.
- Redirect, Rewrite의 차이점
- Redirect, Rewrite의 사용 Layer
- 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에서 각각 리다이렉트하는 방식으로 문제를 해결하였다.
'개발 기록 > Web' 카테고리의 다른 글
| 광고 차단과 웹의 미래에 관해서 (3) | 2026.01.02 |
|---|---|
| React Hook에 대해서 (0) | 2025.12.16 |
| Lexical Editor Life Cycle (0) | 2025.10.23 |
| NextJS Image Optimization (0) | 2025.10.16 |
| Typescript: Union 형식, Intersection 형식, 상속 (2) | 2025.01.24 |