HTTPS, CORS, trust proxy를 한 번에 정리하는 법

서론 (문제 정의)

2026-05-05 기준으로 도메인과 API 경로가 정리되지 않으면 배포는 성공해도 브라우저에서 요청이 막힐 수 있습니다.

이 글은 같은 상황을 겪는 독자가 원인을 빠르게 좁히고 다음 행동을 고를 수 있도록 문제, 배경, 개념, 적용 방법을 분리해 정리합니다.

이어 읽을 글은 전체 글 목록과 DevOps 카테고리에서 확인할 수 있습니다.

상황/배경

서버 내부에서 API가 열려 있어도 브라우저가 접근하는 URL이 다르면 CORS 문제가 납니다. 공개 프론트가 HTTPS라면 API도 HTTPS 공개 경로를 사용해야 mixed content를 피할 수 있습니다.

같은 도메인에서 `/api`로 프록시하면 설정이 단순해집니다. 프론트는 `https://blog.example.com`, API는 `https://blog.example.com/api`처럼 맞추는 방식입니다.

핵심 개념 설명

Nginx 뒤에 NestJS가 있을 때 원래 요청이 HTTPS였는지 알리려면 proxy header와 backend trust proxy 설정이 맞아야 합니다. 이 값이 어긋나면 쿠키, 리다이렉트, 로그 판단이 이상해질 수 있습니다.

운영에서는 `X-Forwarded-Proto`, `Host` 헤더 전달과 백엔드 `TRUST_PROXY=true`를 함께 확인하는 것이 안전합니다.

실제 적용 방법

브라우저 개발자 도구에서 API 요청 URL, 상태 코드, CORS 오류 메시지를 봅니다. 동시에 서버에서는 reverse proxy access log와 backend log를 같이 봐야 원인이 프론트 설정인지 프록시인지 API인지 나뉩니다.

문제가 재현되면 먼저 공개 URL 환경변수와 Nginx upstream 포트를 확인하세요. 대부분의 초기 장애는 이 두 곳에서 발견됩니다.

발행 기준과 수정 원칙은 운영 기준 페이지에 연결해 독자가 글의 맥락을 함께 확인할 수 있게 합니다.

체크리스트

• VITE_SITE_URL과 VITE_API_BASE_URL이 공개 HTTPS 기준인지 확인
• BACKEND_CORS_ORIGINS에 공개 origin 포함
• Nginx가 /api와 /uploads를 frontend fallback보다 먼저 처리
• TRUST_PROXY=true 설정

결론

좋은 글은 하나의 답만 제공하지 않고 다음 확인 경로를 함께 남깁니다. 이 글에서 다룬 기준을 적용한 뒤에는 다른 글과 관련 카테고리를 이어서 확인하며 자신의 서비스 상황에 맞게 보완하는 것이 좋습니다.