next.config.js의 headers / rewrites / redirects 영향¶
Next.js는 next.config.js를 통해
headers / rewrites / redirects를 애플리케이션 레이어에서 직접 제어할 수 있다.
이는 편리하지만,
Nginx와 동일한 책임을 중복 수행할 경우 운영 이슈의 원인이 된다.
1. headers 설정¶
- HTTP 응답 헤더를 Next.js 레이어에서 정의
- 적용 대상:
- 페이지
- API Routes
- Nginx에서도 동일 헤더를 설정할 수 있음
운영 특성¶
- Next.js와 Nginx에 동일 헤더를 정의하면:
- 우선순위 혼동
- 환경별 동작 불일치
발생 가능
- 보안 헤더(CSP, HSTS 등)는 특히 충돌 위험 큼
2. rewrites / redirects 설정¶
- rewrites
- URL은 유지한 채 내부 경로로 매핑
- 클라이언트는 변경을 인식하지 못함
- redirects
- HTTP redirect(301/302) 응답 반환
- 클라이언트 URL 변경 발생
운영 특성¶
- Next.js의 rewrites/redirects는:
- 애플리케이션 내부 라우팅 규칙
- Nginx의 rewrites/redirects는:
- 프록시/네트워크 레벨 규칙
- 두 계층에서 동시에 정의 시:
- 요청 흐름 추적 어려움
- 예기치 않은 라우팅 결과 발생
3. 계층별 책임 구분¶
| 항목 | Nginx | Next.js |
|---|---|---|
| 외부 URL 제어 | ⭕ | ❌ |
| 보안 헤더 전역 적용 | ⭕ | ⚠️ |
| 앱 내부 라우팅 | ❌ | ⭕ |
| 페이지 단위 헤더 | ⚠️ | ⭕ |
4. 운영 기준 (Baseline)¶
- headers / rewrites / redirects는:
- 한 계층에서만 정의한다
- 운영 기준 기본값:
- 외부 URL, 전역 보안 정책 → Nginx
- 애플리케이션 내부 라우팅 → Next.js
- 동일 목적의 설정을:
- Nginx와 Next.js에 중복 정의하지 않는다
5. 운영 체크리스트¶
- headers 설정 위치(Nginx vs Next.js) 확인
- rewrites/redirects 이중 정의 여부 점검
- SEO/캐시 영향 경로 확인
- 변경 시 요청 흐름 다이어그램 검토