단축 URL, 클릭 전에 어디로 가는지 확인하는 법

문자나 메신저로 받은 bit.ly/... 같은 짧은 주소가 어디로 연결되는지, 누르기 전에 확인할 수 있습니다. 방법은 단순합니다. 링크를 여는 대신 서버가 돌려주는 Location 헤더만 읽으면 됩니다.
단축 링크 자체가 문제인 건 아닙니다. 문제는 주소 안에 목적지 정보가 한 글자도 남아 있지 않아서 눈으로는 판단할 재료가 없다는 점입니다. 재료를 꺼내 보는 방법만 알면 됩니다.
요약 ① 단축 주소를 요청하면 서버가 301·302 같은 응답과 함께
Location헤더로 다음 주소를 알려줍니다. 이 헤더만 읽으면 페이지를 열지 않고 목적지를 알 수 있습니다. ② 301은 영구 이동, 302는 임시 이동입니다. 한 번에 도착하지 않고 두세 번 경유하는 것도 정상적인 경우가 많습니다. ③ 최종 도착지가 200이라는 건 "페이지가 열린다"는 뜻이지 "안전하다"는 뜻이 아닙니다. 도착 도메인은 사람이 눈으로 읽어야 합니다.
주소만 봐서는 알 수 없는 이유
일반 주소는 news.example.com/2026/07/…처럼 도메인과 경로에 힌트가 남습니다. 단축 주소는 bit.ly/xyzabc처럼 단축 서비스의 도메인과 무작위 문자열만 남습니다.
즉 bit.ly는 목적지가 아니라 안내소입니다. 눌러야만 안내소가 "여기로 가세요"라고 알려주는 구조라, 링크 위에 마우스를 올려 봐도 나오는 건 단축 주소 그대로입니다.
그래서 확인하려면 안내소에만 물어보고 실제로 가지는 않는 방법이 필요합니다. 그게 아래의 헤더 확인입니다.
도구 없이 확인하는 방법
1) 헤더만 요청해 보기. 맥과 윈도우 10 이상에는 curl이 기본으로 들어 있습니다. 터미널(윈도우는 명령 프롬프트나 PowerShell)에 이렇게 입력합니다.
curl -I http://bit.ly/xyzabc
-I는 본문은 받지 않고 응답 헤더만 달라는 옵션입니다. 실제로 실행하면 아래처럼 나옵니다.
HTTP/1.1 301 Moved Permanently
Location: http://www.pandora.com
첫 줄의 301이 "이동한다"는 신호이고, Location 줄이 다음 주소입니다. 페이지를 열지 않았는데도 목적지가 나왔습니다.
2) 경유지를 전부 보기. 목적지가 또 다른 곳으로 넘기는 경우가 있어서, 한 번만 봐서는 최종 도착지가 아닐 수 있습니다. -L을 붙이면 이동을 따라가며 각 단계의 헤더를 차례로 보여줍니다.
curl -sIL http://bit.ly/xyzabc
최종 주소 한 줄만 알고 싶다면 이렇게 씁니다.
curl -sL -o /dev/null -w "%{url_effective}\n" http://bit.ly/xyzabc
3) 단축 서비스가 제공하는 미리보기. bit.ly는 주소 끝에 +를 붙이면(bit.ly/xyzabc+) 이동하지 않고 그 링크의 정보 페이지가 열리면서 도착지 주소가 표시됩니다. 다만 규칙은 서비스마다 달라서, 다른 단축 서비스에는 통하지 않을 수 있습니다.
4) 이미 열어본 링크라면 개발자 도구. 브라우저 개발자 도구(대개 F12)의 네트워크 탭에서 로그 보존 옵션을 켜고 열면 각 단계가 301·302로 기록에 남습니다. 다만 이건 실제로 방문한 뒤에 보는 방법이라 "클릭 전 확인"은 아닙니다.
문제는 터미널을 열어야 하고 옵션을 기억해야 한다는 점, 그리고 경유지가 여러 개면 출력에서 필요한 줄만 골라 읽어야 한다는 점입니다.
저희 도구로 확인하기. 주소를 붙여 넣고 '추적'을 누르면 위 과정을 한 홉씩 대신 밟아 결과만 정리해 보여줍니다.
설치·회원가입 없이 무료로, 내 브라우저 대신 서버가 한 홉씩 따라가 경유지와 최종 도착지만 보여줍니다.

화면에는 맨 위에 리다이렉트 횟수, 그 아래 경유지마다 순번·상태코드·주소, 맨 아래 최종 도착지가 표시됩니다. 상태코드는 이동(3xx)이면 노란색, 정상 도착이면 초록색, 실패나 오류면 빨간색으로 구분됩니다.
입력창에는 http:// 또는 https://까지 포함해 넣어야 합니다. 주소 부분만 붙여 넣으면 형식을 다시 확인해 달라는 안내가 뜹니다.
상태코드가 알려주는 것
이동 응답은 300번대입니다. 숫자마다 의미가 정해져 있습니다.
| 코드 | 뜻 |
|---|---|
| 301 | 영구 이동. 앞으로도 계속 이 주소로 간다는 표시 |
| 302 | 임시 이동. 지금만 다른 곳으로 보낸다는 표시 |
| 303 | 다른 주소를 새로 요청해서 받으라는 표시 |
| 307 | 임시 이동. 원래 요청 방식을 그대로 유지 |
| 308 | 영구 이동. 원래 요청 방식을 그대로 유지 |
| 200 | 이동 끝. 여기가 실제 페이지 |
주의할 점이 두 가지 있습니다. 300번대라도 Location 헤더가 없으면 갈 곳이 지정되지 않은 것이고, 304는 300번대지만 이동이 아니라 "바뀐 게 없으니 저장해 둔 걸 쓰라"는 캐시 응답입니다.
307·308이 따로 있는 이유는 요청 방식 때문입니다. 301·302는 과거부터 이동 과정에서 요청 방식이 바뀌는 구현이 흔했고, 그걸 바꾸지 않도록 못 박은 것이 307·308입니다. 링크를 누르는 상황(단순 조회)에서는 체감 차이가 거의 없습니다.
체인을 읽을 때 막히는 지점
여러 번 경유한다고 수상한 건 아닙니다. 실제로 위키백과 단축 주소 http://w.wiki/4Jx를 추적하면 301이 두 번 찍힙니다. 첫 번째는 http를 https로 올리는 이동이고, 두 번째가 실제 문서로 가는 이동입니다.
이 밖에도 모바일 페이지로 나누거나, 예전 도메인을 새 도메인으로 합치거나, 주소 끝에 유입 경로 파라미터를 붙이면서 한 번 더 이동하는 경우가 흔합니다.
상태코드에 잡히지 않는 이동도 있습니다. 페이지 안의 meta refresh나 자바스크립트로 옮기는 방식은 HTTP 응답이 아니라 페이지가 열린 뒤에 일어납니다. 이런 경우 헤더 추적은 200에서 끝난 것처럼 보이므로, 최종 도착지 화면이 또 다른 곳으로 넘어갈 수 있다는 점은 남습니다.
최종 도착지가 200이어도 안전 판정은 아닙니다. 200은 "그 주소에 페이지가 있다"는 뜻일 뿐입니다. 판단은 결국 도착 도메인을 사람이 읽는 데서 나옵니다.
도메인은 오른쪽부터 읽습니다. 주소에서 // 다음부터 첫 / 전까지가 도메인이고, 실제 사이트를 정하는 건 그 안의 맨 오른쪽 부분입니다. 예를 들어 https://example.com.abc-login.top/pay의 실제 도메인은 example.com이 아니라 abc-login.top입니다.
확인 자체는 내 브라우저로 열지 않습니다. 저희 도구는 브라우저 대신 저희 서버가 요청을 보내므로, 목적지에는 내 IP나 쿠키가 전달되지 않습니다. 다만 단축 서비스 쪽에서는 요청이 한 번 들어온 것이므로 클릭 집계에는 잡힐 수 있습니다.
끝없이 도는 링크도 있습니다. 두 주소가 서로를 가리키면 이동이 끝나지 않습니다. 그래서 이 도구는 10홉에서 멈추고 "리다이렉트가 10회를 넘어 중단했습니다(무한 루프 가능성)"라고 알려 줍니다.
정리
- 단축 주소는 눌러야만 목적지를 알려주지만,
Location헤더만 읽으면 열지 않고도 확인할 수 있습니다. curl -I 주소로 헤더를,curl -sIL 주소로 경유지 전체를 볼 수 있습니다. 맥·윈도우 10 이상에 기본 탑재돼 있습니다.- 301은 영구, 302는 임시 이동입니다. 304는 이동이 아니라 캐시 응답입니다.
- 경유가 두세 번인 것은 흔한 일입니다(https 승격, 도메인 통합, 유입 파라미터 부착).
- 최종 200은 "열린다"는 뜻입니다. 도착 도메인은 오른쪽 끝부터 읽어 눈으로 확인하십시오.
설치·회원가입 없이 무료로, 내 브라우저 대신 서버가 한 홉씩 따라가 경유지와 최종 도착지만 보여줍니다.
자주 묻는 질문
링크를 누르지 않고도 목적지를 정말 알 수 있나요?
네. 단축 서비스는 요청을 받으면 목적지로 데려가는 대신 "이 주소로 가라"는 응답(301·302)과 Location 헤더를 먼저 돌려줍니다. 그 헤더만 읽고 따라가지 않으면 목적지 페이지는 열리지 않습니다. curl -I가 하는 일이 정확히 이것이고, 이 도구도 이동을 자동으로 따라가는 대신 한 홉씩 끊어서 응답만 확인합니다.
301과 302는 뭐가 다른가요?
301은 "앞으로도 계속 여기로 간다"는 영구 이동, 302는 "지금만 여기로 보낸다"는 임시 이동입니다. 브라우저와 검색엔진은 301을 주소가 바뀐 것으로 취급하고, 302는 원래 주소가 그대로 유지되는 것으로 취급합니다. 링크를 확인하는 입장에서는 둘 다 "다음 주소가 있다"는 신호라는 점이 같습니다.
리다이렉트가 3~4번이면 이상한 링크인가요?
그 자체로는 판단 근거가 되지 않습니다. http에서 https로 올리는 이동, 옛 도메인에서 새 도메인으로 합치는 이동, 모바일 화면으로 보내는 이동, 유입 경로 파라미터를 붙이는 이동이 겹치면 흔히 서너 번이 됩니다. 봐야 할 것은 횟수가 아니라 최종 도착지의 도메인입니다.
최종 도착지가 200이면 안전한가요?
아닙니다. 200은 "그 주소에 페이지가 있고 정상 응답했다"는 뜻일 뿐, 내용에 대한 평가가 아닙니다. 도착 도메인이 내가 아는 그 사이트가 맞는지(특히 오른쪽 끝 부분), 로그인이나 결제 정보를 요구하는 페이지인지는 별도로 확인해야 합니다. 판단이 서지 않으면 링크를 따라가지 말고 해당 서비스의 앱이나 즐겨찾기로 직접 접속하는 편이 확실합니다.
