curl에서 301·302만 보일 때: Location과 최종 URL 확인

curl에서 301·302가 보이면 첫 서버가 이동할 주소를 알려준 것인지 확인하세요. 기본 요청의 응답과 --location으로 따라간 뒤의 최종 응답을 나누어 기록하면 브라우저와 결과가 다른 이유를 좁힐 수 있습니다.

적용 환경: curl 명령행 도구와 공개 HTTPS 조회용 URL; 아래 예시는 인증·쿠키·POST 데이터가 없는 GET만 대상으로 하며 POSIX 셸 기준. 자료 확인일: 2026-10-28. 공식 문서 기반 안내이며 실제 계정·운영 환경에서 실행한 시험 결과가 아닙니다.

1. 원인: HTTP 이동을 자동으로 따라가지 않은 경우

curl FAQ는 URL 뒤의 슬래시 유무 등으로 301 이동 응답이 생길 수 있으며 -L 또는 --location으로 HTTP 이동을 따라갈 수 있다고 설명합니다. 브라우저가 최종 페이지를 보여줬다는 사실과 curl이 첫 응답을 출력했다는 사실은 함께 성립할 수 있습니다.

브라우저의 자바스크립트나 HTML meta 방식 이동은 HTTP Location 리디렉션과 다릅니다. curl이 페이지 내용을 가져왔어도 이런 브라우저 코드를 실행해 다음 화면으로 이동하지는 않습니다.

2. 해결: 첫 응답 헤더를 먼저 확인

본인이 조회하도록 허가받은 공개 주소로 바꿔 실행하세요. 첫 명령은 GET 응답의 본문을 버리고 헤더를 표준 출력으로 보냅니다. -I로 HEAD 요청을 보내면 GET과 동작이 달라질 수 있어 이 예시에서는 사용하지 않습니다.

curl -sS -D - -o /dev/null 'https://example.com/'

상태 코드와 Location의 스킴·호스트·경로를 확인합니다. 목적지가 의도한 곳이고 추가 요청이 허용될 때만 다음 조회로 이동합니다. 아래 두 번째 명령은 이동을 최대 다섯 번 따라가며 마지막 응답 상태와 URL을 출력합니다.

curl -sS -L --max-redirs 5 -o /dev/null \
  -w 'status=%{http_code} url=%{url_effective}\n' \
  'https://example.com/'

3. 확인: 첫 응답과 마지막 응답을 별도 판정

관찰	확인할 범위
첫 응답 301·302	Location이 예상 목적지인지
최종 응답 200	요청한 서비스·경로·내용인지
이동 횟수 제한 오류	반복되는 호스트·경로가 있는지
브라우저만 이동	HTTP 이동인지 JS/meta인지

200이라는 숫자만으로 원하는 화면이 맞다고 확정하지 마세요. 인증 화면이나 다른 서비스의 안내 페이지가 최종 목적지일 수 있습니다. 현재 URL과 기대한 호스트·경로를 대조한 뒤 필요한 내용 확인을 따로 진행합니다. 오류가 나면 종료 코드도 기록하고 제한을 무작정 늘리지 않습니다.

4. 주의와 FAQ

인증 요청에도 그대로 -L을 붙여도 되나요? 이 예시는 공개 GET만 다룹니다. 다른 호스트로 이동할 때 자격 증명이나 사용자 지정 헤더가 전달되는 규칙을 별도로 검토해야 합니다. --location-trusted를 편의상 추가하거나 민감한 쿼리를 그대로 외부에 공유하지 마세요.

POST에도 같은 명령을 쓰나요? 요청 메서드와 이동 응답 코드에 따라 다음 요청의 메서드가 달라질 수 있습니다. 결제·업로드·변경 요청에 이 GET 진단 예시를 적용하지 않습니다.

공식 출처와 관련 글

curl FAQ의 301과 브라우저 이동 차이

curl location·max-redirs·write-out 옵션

curl 종료 코드와 HTTP 상태 구분

curl은 성공인데 HTTP 404일 때: 종료 코드와 응답 상태를 따로 확인

직접 생성한 개념 이미지입니다. 실제 서비스 화면이나 구축·성능 시험 결과가 아닙니다.