CDN을 붙인 뒤 갑자기 “로그인이 풀린다”, “세션이 안 잡힌다”, “CORS policy 에러가 난다” 같은 문제가 생기면, 원인은 대개 쿠키 속성(SameSite/Secure/Domain)과 HTTPS(종단/재암호화), 그리고 CDN 캐시가 엮이면서 발생합니다. 특히 Nginx 뒤에서 API와 프론트 도메인이 나뉘는 구조면 더 자주 터져요.
아래는 보안(CORS/쿠키/HTTPS)을 중심으로, 캐시/CDN까지 포함해 “어디부터 만져야 덜 망가지는지” 기준으로 정리한 점검 루트입니다.
1) 증상 분류: 지금 겪는 에러 메시지부터 고정하기
먼저 브라우저 DevTools에서 에러 문구를 정확히 잡아두면, 불필요한 설정 변경을 줄일 수 있습니다.
- CORS 오류: “Blocked by CORS policy”, “No 'Access-Control-Allow-Origin' header”
- 쿠키/세션: 로그인은 되는데 다음 요청에서 401, 새로고침하면 로그아웃, 크로스도메인에서 쿠키가 안 붙음
- 혼합 콘텐츠/HTTPS: “Mixed Content”, “This request has been blocked; the content must be served over HTTPS”
- 캐시 문제: 특정 사용자만 로그인 상태 꼬임, 응답 헤더에 Age/HIT가 찍히며 동적 응답이 캐시됨
이 글의 루트는 쿠키/HTTPS/CORS → 캐시 순서로 진행합니다. 이유는 캐시를 먼저 건드리면 증상이 가려져서 원인 추적이 더 어려워질 수 있기 때문입니다.
2) HTTPS 경로 점검: CDN에서 TLS 종료(SSL termination) 후 원서버는 어떻게 보이나?
CDN이 앞단에서 HTTPS를 종료한 뒤, 원서버(Nginx)로는 HTTP로 전달되는 구성이 흔합니다. 이때 애플리케이션이 “내가 HTTPS로 접속 중”이라고 인지하지 못하면, 쿠키에 Secure가 빠지거나 리다이렉트가 꼬일 수 있어요.
- CDN → Origin 연결이 HTTP라면, CDN이 X-Forwarded-Proto: https를 넣는지 확인
- Nginx가 해당 헤더를 애플리케이션에 전달하는지 확인
- 가능하면 CDN → Origin도 HTTPS(재암호화)로 맞추면 단순해집니다
Nginx에서 일반적으로 확인하는 전달 헤더 예시는 아래 방향입니다(환경에 맞게 조정). “https로 들어왔다”는 힌트를 애플리케이션이 받아야 합니다.
- proxy_set_header X-Forwarded-Proto $scheme;
- proxy_set_header X-Forwarded-Host $host;
- proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
그리고 CDN을 거치면 브라우저는 HSTS 정책(Strict-Transport-Security) 적용 여부도 중요합니다. HSTS는 한 번 잘못 걸면 롤백이 까다로울 수 있으니, 도메인/서브도메인 범위를 신중히 정하세요.
3) 쿠키가 안 붙는 핵심: SameSite/Secure/Domain/Path를 CDN 앞 도메인 기준으로 재정의
CDN 적용 후 로그인 유지가 깨지는 케이스에서 가장 흔한 원인은 SameSite 기본값 변화와 Secure 누락, 그리고 Domain 불일치입니다. 특히 프론트가 www.example.com, API가 api.example.com처럼 분리되어 있으면 “크로스 사이트/크로스 서브도메인” 취급이 얽힐 수 있어요.
- SameSite=None를 써야 하는 상황(크로스사이트 요청에서 쿠키 필요)이면, 반드시 Secure도 함께 있어야 합니다(최신 브라우저 정책).
- Domain이 origin 기준으로 잘못 찍히면(예: origin 내부 도메인), CDN 앞 도메인에서 쿠키가 재사용되지 않습니다.
- Path가 지나치게 좁으면 특정 API 경로에서만 쿠키가 붙습니다.
Nginx 레벨에서 애플리케이션이 내려주는 Set-Cookie를 조정해야 하는 경우도 있습니다. 예를 들어 origin이 http로 인식해 Secure가 빠질 때, 혹은 Domain이 내부 도메인으로 찍힐 때입니다. 이건 근본적으로는 애플리케이션 설정에서 해결하는 게 가장 안전하지만, 급한 복구를 위해 Nginx/CDN의 쿠키 재작성 기능을 쓰기도 합니다.
체크 포인트: DevTools → Network → 요청 헤더의 Cookie, 응답 헤더의 Set-Cookie를 보고 “쿠키가 저장되는지”, “다음 요청에 실려가는지”를 분리해서 확인하세요.
4) CORS를 ‘열기’보다 ‘정확히 맞추기’: Origin/Allow-Credentials/캐시 키
쿠키 기반 인증을 쓰는 API라면 CORS는 단순히 Access-Control-Allow-Origin을 *로 두는 방식으로는 해결이 안 됩니다. 보안상도 위험하고, 브라우저 정책상 credentials 포함 요청에서는 와일드카드가 막히는 경우가 많습니다.
- 프론트 도메인이 여러 개면, 요청의 Origin 값을 검사해 허용 목록에 있는 경우에만 그대로 반사(reflect)해서 내려주는 방식이 안전합니다.
- 쿠키/인증이 필요하면 Access-Control-Allow-Credentials: true가 필요하고, 이때 Access-Control-Allow-Origin: *는 피해야 합니다.
- Preflight(OPTIONS) 응답에 필요한 Access-Control-Allow-Methods, Access-Control-Allow-Headers가 빠지면 특정 요청만 실패합니다.
CDN을 끼면 CORS 응답도 캐시될 수 있습니다. 이때 중요한 게 Vary: Origin입니다. Origin별로 다른 헤더를 내려주는데 Vary가 없으면, 한 Origin에 맞춘 허용 헤더가 다른 Origin에 재사용되어 오동작할 수 있어요.
- 가능하면 API 응답에 Vary: Origin 추가
- CDN 캐시 키에 Origin이 반영되는지(정책/규칙) 확인
5) 캐시/CDN 성능 개선 루트: “동적은 안 캐시, 정적은 길게 캐시”로 경계선부터
보안 이슈(쿠키/CORS/HTTPS)가 안정화되면, 그 다음이 성능 개선 단계입니다. 핵심은 경계선을 분명히 긋는 것입니다.
- API/HTML(로그인 연동): 기본은 캐시 금지 또는 매우 짧게(사이드이펙트 방지)
- 정적 파일(js/css/png/webp/svg): CDN 캐시 + 긴 Cache-Control (버전 해시 파일명 권장)
- 개인화 응답: Cookie가 있는 요청은 캐시에서 제외(또는 별도 정책)
점검할 응답 헤더 체크리스트를 두면 편합니다.
- Cache-Control: public/max-age/s-maxage가 의도대로인지
- Set-Cookie가 붙는 응답이 CDN에서 캐시되고 있지 않은지(HIT 여부)
- ETag/Last-Modified가 정적에 유효하게 붙는지
성능을 올리려고 HTML까지 캐시하려다 로그인/쿠키 문제가 재발하는 경우가 많습니다. 먼저 정적만 확실히 길게 캐시해도 체감 개선이 크게 나오는 편입니다.
6) 운영 중 재발 방지: 로그와 테스트를 “원본/엣지/브라우저” 3군데에서 맞추기
CDN 환경에서는 한 군데만 보면 원인을 놓치기 쉽습니다. 아래 3가지를 동시에 확인하는 습관이 도움이 됩니다.
- 브라우저: DevTools에서 Set-Cookie 저장 여부, SameSite 경고, Preflight 실패 사유 확인
- CDN: 캐시 HIT/MISS, Edge에서 헤더가 변형되는지(규칙/Workers/Transforms 등)
- Nginx(Origin): access_log에 X-Forwarded-Proto/Host/For가 의도대로 들어오는지, OPTIONS 요청이 어디서 막히는지
변경은 한 번에 여러 개를 하지 말고, 쿠키 → HTTPS 인지 → CORS → 캐시 순으로 한 단계씩 검증하는 게 가장 빠르게 복구됩니다.
마무리
CDN을 붙인 뒤의 로그인/CORS 이슈는 “설정이 부족해서”라기보다, 서로 다른 계층(CDN/Origin/브라우저)의 기본 동작이 엇갈리면서 생기는 경우가 많습니다.
쿠키(SameSite/Secure/Domain)와 HTTPS 인지부터 안정화한 다음, CORS를 정확히 맞추고 마지막에 캐시 정책을 확장하면 성능도 챙기면서 재발 가능성도 줄일 수 있습니다.