WebUtils
ENKOJA

개발자 작업 흐름

HTTP 응답 헤더 확인하기

CORS, 캐시, 리디렉션, 쿠키, 보안 헤더를 바꾸기 전에 curl, 브라우저 DevTools, API 클라이언트, CDN 로그에서 응답 헤더를 캡처하고 비교하는 방법입니다.

HTTP 헤더 파서 | 요청 및 응답 헤더 확인 열기

문제 상황

HTTP 헤더는 많은 운영 장애의 원인을 설명하지만, 복사한 헤더 블록에는 Set-Cookie 중복, CDN Cache-Control, 프록시 CORS, 호스팅 리디렉션, 프레임워크 보안 헤더가 섞여 있습니다. 본문이나 상태 코드만 보면 실제로 브라우저 동작을 바꾸는 설정을 놓치기 쉽습니다.

이럴 때 사용하세요

  • CORS, credentials, preflight 응답 헤더 때문에 브라우저 요청이 막힐 때 사용합니다.
  • 배포 후에도 CDN이나 브라우저가 오래된 파일을 계속 제공할 때 적합합니다.
  • 리디렉션, API 요청, 로그인 콜백이 환경마다 다르게 동작할 때 도움이 됩니다.
  • curl, DevTools, API 클라이언트, 운영 로그의 응답 헤더를 같은 기준으로 비교해야 할 때 사용합니다.
  • 호스팅이나 CDN 설정으로 security, cache, cookie 변경을 배포했고 다음 설정 변경 전에 증거가 필요할 때 사용합니다.

단계

  1. 1단계

    원본 헤더 캡처

    브라우저 DevTools, `curl -I`, API 클라이언트, CDN 로그, 서버 로그에서 전체 응답 헤더 블록을 복사합니다. 가능하면 상태 줄도 함께 남깁니다.

  2. 2단계

    공유 전 민감한 값 제거

    헤더 블록을 티켓이나 채팅에 붙여넣기 전에 세션 쿠키, Bearer 토큰, API 키, 사용자 ID, 내부 호스트명을 제거합니다.

  3. 3단계

    설정 변경 전에 파싱

    `HTTP Header Parser`에 붙여넣어 이름을 정규화하고 cache, CORS, content, security, request, response 그룹을 분리합니다.

  4. 4단계

    중복 헤더 확인

    `set-cookie`, `vary`, `cache-control`, 반복된 `access-control-*` 값을 확인합니다. 일부 중복은 정상이고, 일부는 브라우저 혼란의 원인입니다.

  5. 5단계

    증상에 맞춰 추적

    오래된 콘텐츠는 cache 헤더부터, 차단된 브라우저 요청은 CORS부터, 로그인 실패는 redirect, cookie, token 관련 헤더부터 비교합니다.

  6. 6단계

    대상 URL과 함께 기록

    리디렉션이나 콜백 문제는 `URL Parser`와 `Query String Parser`로 URL도 확인한 뒤, 파싱된 헤더 요약을 디버깅 메모에 함께 남깁니다.

예시

HTTP 응답 헤더 확인하기 예시

입력

HTTP/2 200
content-type: application/json; charset=utf-8
cache-control: public, max-age=3600
access-control-allow-origin: https://app.example.com
vary: origin, accept-encoding
strict-transport-security: max-age=31536000; includeSubDomains

출력

Start line: HTTP/2 200
Total headers: 5
Cache headers: cache-control, vary
CORS headers: access-control-allow-origin
Security headers: strict-transport-security

흔한 실수

응답 본문만 확인

JSON 본문이 정상이어도 cache, CORS, cookie, security 헤더 때문에 브라우저가 응답을 거부하거나 재사용할 수 있습니다.

헤더가 추가된 위치를 무시

헤더는 앱 코드, 프레임워크 미들웨어, CDN, 리버스 프록시, 호스팅 기본값에서 올 수 있습니다. 앱만 바꾸기 전에 환경을 비교하세요.

모든 중복을 버그로 판단

`set-cookie`는 여러 번 나오는 것이 흔합니다. 헤더 이름과 브라우저 동작을 확인하기 전에 중복을 무작정 지우지 마세요.

최종 요청만 보고 preflight를 놓침

CORS 문제는 최종 API 응답이 아니라 OPTIONS preflight 응답에서 생길 수 있습니다. 브라우저가 cross-origin 요청을 차단하면 둘 다 캡처하세요.

쿠키와 토큰을 그대로 공유

헤더 스크린샷이나 로그에는 세션 쿠키, Bearer 토큰, 사용자 식별자가 들어갈 수 있습니다. 공유 전 민감한 값을 마스킹합니다.

자주 묻는 질문

개인 쿠키나 토큰을 붙여넣어도 되나요?

공유용 메모나 스크린샷에는 세션 ID, 토큰, API 키, 사용자 식별자를 지우세요. 로컬 파싱은 편하지만 복사한 출력은 그대로 노출될 수 있습니다.

응답 헤더로 CORS 오류를 설명할 수 있나요?

네. CORS 실패는 `access-control-allow-origin`, credentials 허용, methods, allowed headers, preflight 응답 조합에 따라 달라집니다.

curl과 브라우저의 헤더가 다른 이유는 무엇인가요?

요청 헤더, 쿠키, 리디렉션, 프로토콜, 캐시가 다를 수 있습니다. 정확한 URL과 요청 조건을 맞춘 뒤 비교하세요.

캐시 문제에서는 어떤 헤더를 먼저 봐야 하나요?

`cache-control`, `etag`, `last-modified`, `age`, `vary`, CDN 관련 헤더를 먼저 봅니다. 브라우저 캐시와 CDN 캐시가 서로 다른 규칙을 가질 수 있습니다.

보안 헤더는 어떤 항목을 확인해야 하나요?

CSP, HSTS, X-Frame-Options, Referrer-Policy, Permissions-Policy처럼 브라우저 기능을 제한하는 헤더가 현재 화면이나 API 흐름을 막는지 확인합니다.

응답 헤더뿐 아니라 요청 헤더도 필요하나요?

필요한 경우가 많습니다. CORS, cache, content negotiation, cookie, authorization 동작은 요청 헤더에 따라 달라질 수 있으므로 환경 비교 시 요청 조건도 함께 캡처하세요.