북마크한 사이트가 갑자기 5xx를 뱉는다면, HTTP 301 리디렉션 체인을 따라가면 90% 이상의 경우 새 주소로 도달하게 됩니다.
즐겨찾기를 눌렀는데 “연결할 수 없음”이 뜨는 상황, 다들 한 번쯤 겪어봤을 겁니다. 구글에 다시 검색해봐도 구버전 캐시만 걸리고, 커뮤니티 링크를 하나씩 눌러보다가 결국 포기하는 그 흐름이요.
사실 대부분의 경우는 브라우저가 이미 새 주소를 알고 있습니다. 서버가 “나 여기로 이사 갔어”라는 흔적을 남기고 있지만 브라우저가 반영하지 못한 경우입니다.
이 글에서는 초보자도 쉽게 적용할 수 있는 클릭 한 번 수준부터 CDX API 자동화까지 한 번에 정리했습니다.
왜 사이트 주소가 자주 바뀌는가?
도메인이 바뀌는 이유를 알면 새 주소를 찾는 방식도 달라집니다.
서비스 리브랜딩이 가장 흔한 이유입니다. 회사 이름이 바뀌거나 서비스 통합이 일어나면 도메인도 함께 바뀝니다. 도메인 만료도 자주 발생합니다. 갱신을 깜빡한 도메인은 하루아침에 타인에게 넘어가며, 이때 운영자가 새 도메인으로 서비스를 이어가기도 합니다.
호스팅 이전이나 CDN 설정 변경으로 서브도메인 구조가 달라지는 케이스도 있습니다. 커뮤니티나 포럼 사이트의 경우, 운영자 교체나 플랫폼 이전 시 도메인이 통째로 바뀝니다.
공통점은 하나입니다. 기존 도메인에서 새 도메인으로 301 리디렉션을 설정해두는 경우가 대부분입니다. 이걸 추적하는 것이 가장 빠른 길입니다.
1. 터미널 없이 3단계로 끝내기
명령어를 쓸 필요 없이 아래 순서대로만 해도 80% 이상의 경우는 새 주소를 찾을 수 있습니다.
첫 번째, 주소창에 그냥 한 번 더 입력해봅니다
브라우저는 서버가 “이 주소는 저쪽으로 이사 갔음”이라고 신호를 보내면 자동으로 따라갑니다.
즐겨찾기에 http://로 저장된 주소가 이미 https://로 이전된 경우가 많은데, 이때 주소창에 다시 치는 것만으로 새 주소로 넘어갑니다. 입력 후 주소창 URL이 바뀌어 있으면 그게 현재 주소입니다. 북마크만 업데이트하면 끝입니다.
HTTP → HTTPS 리디렉션이 안 된다면? ISP나 방화벽 레벨에서 특정 도메인이 차단된 경우 리디렉션 자체가 막히기도 합니다. 이 경우 HTTPS 우회로 새 주소 찾는 법을 참고하시면 됩니다.
두 번째, Wayback Machine에서 사이트 마지막 확인
리디렉션도 없고 그냥 오류만 뜬다면, 사이트가 죽기 직전 모습을 보면 됩니다. 운영자가 “이전했습니다” 공지를 본문에 남겨두는 경우가 꽤 있습니다. 메인 화면이나 공지 게시판을 먼저 확인하세요.
- web.archive.org 접속
- 검색창에 죽은 URL 붙여넣고 Enter
- 달력에서 가장 최근에 파란 원이 진한 날짜 클릭 (원이 진할수록 캡처 횟수가 많습니다)
- 해당 시점 사이트 내용 확인 → 이전 공지 또는 새 주소 배너 여부 체크
세 번째, 구글에 사이트 이름 + 새 주소로 검색
운영자가 커뮤니티나 SNS에 직접 공지를 올렸을 수 있습니다. 아래 패턴이 효과적입니다.
"사이트이름" 새 주소 2026
"사이트이름" 이전 안내
"사이트이름" new domain검색 결과에서 링크를 클릭하기 전, 주소창 도메인 철자를 한 번 확인하세요.
원래 사이트와 비슷한 이름의 가짜 도메인이 검색 상위에 걸리는 경우가 있습니다. https:// 자물쇠가 없거나 도메인에 숫자·특수문자가 섞여 있으면 그냥 닫는 게 맞습니다. 여기서도 해결이 안 됐다면 아래 기술적인 방법들을 순서대로 시도해보세요.
2. 브라우저 DevTools로 리디렉션 경로 확인하기 (30초)
이 작업의 목적은 브라우저가 자동으로 따라가는 리디렉션 경로를 눈으로 직접 확인하는 것입니다.
크롬 기준 경로
- 죽은 URL을 주소창에 입력
- F12 → Network 탭 열기
- Preserve log 체크
- 페이지 로드
- 첫 번째 요청을 클릭 → Headers 탭에서 Status Code: 301 확인
- Location 헤더 값이 새 주소
리디렉션이 여러 단계를 거치는 경우(예: oldsite.com → www.oldsite.com → newsite.com), Network 탭에 요청이 순서대로 쌓입니다. 마지막으로 200 OK가 뜬 요청의 URL이 최종 목적지입니다.
HTTP에서 HTTPS로 바뀌는 케이스가 특히 많습니다. HTTP로 접속 시도 시 자동으로 HTTPS로 리디렉션되는 건 정상 동작입니다.
3. curl로 리디렉션 체인 전체 추적하기
브라우저 DevTools보다 정확하고, 스크립트 자동화에도 쓸 수 있습니다. 캐시 없이 서버 응답을 그대로 보여주기 때문에 디버깅에 훨씬 유리합니다.
기본 명령: 최종 도착지만 확인
curl -sLD - http://oldsite.com -o /dev/null -w '%{url_effective}'-s: 진행 표시 숨김-L: 리디렉션 자동 추적 (최대 50회)-D -: 헤더를 표준 출력으로 덤프-o /dev/null: 본문은 버림%{url_effective}: 최종 도착 URL 출력
헤더 전체 보기: 중간 경로 포함
curl -IL http://oldsite.com출력 예시
HTTP/1.1 301 Moved Permanently
Location: https://www.oldsite.com/
HTTP/1.1 301 Moved Permanently
Location: https://newsite.com/
HTTP/1.1 200 OK중간 홉(hop)이 2개 이상인 경우, SEO 관점에서도 리디렉션 체인이 길수록 크롤링 비용이 높아집니다. 운영자라면 단일 301로 줄이는 것이 좋습니다.
리디렉션 횟수 제한: 루프 방지
curl -IL --max-redirs 3 http://oldsite.com--max-redirs -1로 설정하면 제한 없이 따라갑니다. 무한 루프 가능성이 있는 서버에서는 사용하지 않는 것이 좋습니다.
JavaScript 리디렉션은 curl로 체크 안됨
window.location 변경이나 <meta http-equiv="refresh"> 방식의 리디렉션은 curl이 처리하지 못합니다. 이 경우 방법 6(커뮤니티/공지 검색)으로 넘어가세요.
4. Wayback Machine CDX API로 도메인 변경 이력 조회
리디렉션이 이미 끊겼거나 도메인 자체가 폐기된 경우, Wayback Machine의 CDX(Content Index) API로 해당 도메인이 과거에 어떤 URL로 운영됐는지 확인할 수 있습니다.
가장 최근 스냅샷 URL 확인
https://archive.org/wayback/available?url=oldsite.comJSON 응답
{
"archived_snapshots": {
"closest": {
"available": true,
"url": "https://web.archive.org/web/20241101123456/https://oldsite.com/",
"timestamp": "20241101123456",
"status": "200"
}
}
}timestamp는 YYYYMMDDhhmmss 형식입니다. 이 스냅샷 URL로 접속하면 해당 시점의 사이트 내용을 볼 수 있습니다.
CDX API로 전체 캡처 목록 뽑기
https://web.archive.org/cdx/search/cdx?url=oldsite.com&output=json&fl=timestamp,original,statuscode&limit=20&from=20230101파라미터 설명
url=: 조회할 도메인output=json: JSON 형식 출력fl=: 반환할 필드 (timestamp, original, statuscode 등)limit=: 결과 수 제한from=,to=: 기간 필터 (YYYYMMDDhhmmss형식)
실전 활용: 사이트가 특정 시점 이후 응답이 없다면, CDX에서 마지막으로 statuscode=200이 찍힌 타임스탬프를 확인하세요. 그 직후 캡처에서 리디렉션 주소를 찾을 수 있습니다.
Python으로 자동화하기
import httpx
def get_wayback_captures(url: str, limit: int = 20):
resp = httpx.get(
"http://web.archive.org/cdx/search/cdx",
params={
"url": url, # 조회할 도메인
"output": "json", # JSON 형식으로 받기
"fl": "timestamp,original,statuscode", # 가져올 필드
"limit": limit, # 최대 결과 수 (기본 20개)
"filter": "statuscode:200" # 정상 응답 캡처만 필터
},
timeout=30
)
fields, *rows = resp.json() # 첫 번째 row가 필드명, 나머지가 데이터
return [dict(zip(fields, row)) for row in rows] # 필드명-값 dict로 변환
# "oldsite.com" 자리에 조회할 도메인 입력
for capture in get_wayback_captures("oldsite.com"):
print(capture)5. DNS 조회로 현재 IP 및 네임서버 확인
도메인 자체는 살아있는데 사이트가 다른 곳을 가리키는 경우, DNS 레코드를 직접 확인합니다. 호스팅 이전이나 CDN 변경 직후에 특히 유용합니다.
nslookup (Windows/macOS/Linux 공통)
# A 레코드 조회 (IPv4 주소)
nslookup example.com
# 특정 DNS 서버(1.1.1.1)로 조회
nslookup example.com 1.1.1.1
# NS 레코드: 네임서버 확인
nslookup -type=ns example.com출력 예시
Non-authoritative answer:
Name: example.com
Address: 93.184.216.34dig (macOS/Linux 권장 도구)
nslookup보다 상세한 출력을 제공하며, +trace 옵션으로 루트 DNS부터 authoritative 네임서버까지 전체 조회 경로를 추적할 수 있습니다.
# 기본 조회
dig example.com
# 전체 DNS 조회 경로 추적
dig example.com +trace
# 역방향 조회: IP → 도메인
dig -x 93.184.216.34+trace 옵션은 도메인 설정에 문제가 있을 때 어느 단계에서 끊기는지 정확히 짚어줍니다.
DNS 변경 후 반영 시간은 TTL(Time to Live) 설정에 따라 다르지만, TTL이 3600초(1시간)로 설정된 경우 전 세계 DNS 서버에 변경이 전파되는 데 최대 1시간이 걸립니다. 방금 도메인이 바뀐 상황이라면 여기서 시간 차이가 발생할 수 있습니다.
글로벌 DNS 전파 확인
전 세계 여러 지역에서 동시에 DNS 조회 결과를 보여주는 whatsmydns.net 을 사용하면 전파 완료 여부를 한눈에 확인할 수 있습니다. 도메인을 입력하고 레코드 타입(A, CNAME 등)을 선택하면 수십 개 국가의 DNS 서버 응답이 한 화면에 나옵니다.
6. 커뮤니티·공식 채널에서 공지 찾기
위 방법이 전부 막혔다면 사람이 직접 공지를 올렸을 가능성이 높습니다.
검색 쿼리 패턴
"사이트명" 새 주소 site:reddit.com
"사이트명" 주소 변경 2026
"사이트명" new domain site:twitter.com체크해야 할 채널
공식 트위터/X, 공식 텔레그램 채널, 디시인사이드·클리앙·루리웹 등 해당 커뮤니티 관련 갤러리나 게시판, Reddit의 관련 서브레딧 순으로 확인하세요.
주의: 커뮤니티에서 퍼지는 링크는 피싱 사이트일 가능성이 있습니다. 새 도메인 접속 전 반드시 다음을 확인하세요.
- HTTPS 자물쇠 표시 존재 여부
- 도메인 철자 오타 여부 (예:
g00gle.comvsgoogle.com) - whois 조회로 도메인 등록일이 최근인지 확인 (
https://whois.domaintools.com/)
7. Google 검색 연산자 및 Internet Archive 링크 활용
Google cache 연산자는 2024년 9월부로 완전 종료됐습니다
cache:oldsite.com 방식은 2024년 2월 캐시 링크 제거를 시작으로, 같은 해 9월 연산자 자체가 완전히 비활성화됐습니다. Bing 캐시도 2024년 12월에 종료됐습니다. 2026년 현재 주요 검색엔진 캐시는 사실상 전멸 상태입니다.
대신 Google 검색결과의 Internet Archive 링크
Google은 캐시 제거의 대안으로 2024년 9월부터 검색결과에 Internet Archive(Wayback Machine) 링크를 추가했습니다. 검색결과에서 URL 옆 점 3개 더보기(⋮) → 검색결과 정보로 들어가면 해당 페이지의 Wayback Machine 아카이브로 바로 이동할 수 있습니다.
도메인 변경 공지 찾기
"oldsite.com" "이전" OR "이사" OR "새 주소" 2026사이트 내에서 이전 공지를 올린 경우 검색에 잡힙니다.
상황별 우선순위 비교
| 상황 | 권장 방법 | 소요 시간 |
|---|---|---|
| 터미널 없이 빠르게 해결 | 방법 1 (주소 재입력 → Wayback UI → 구글 검색) | 1~3분 |
| 리디렉션 경로 눈으로 확인 | 방법 2 (DevTools Network 탭) | 30초 |
| 정확한 리디렉션 체인 분석 | 방법 3 (curl -IL) | 1분 |
| 도메인이 완전히 폐기된 경우 | 방법 4 (Wayback CDX API) | 3분 |
| DNS 전파 지연 의심 | 방법 5 (dig +trace / whatsmydns) | 2분 |
| 모든 기술적 방법 실패 | 방법 6·7 (커뮤니티/구글 캐시) | 5~10분 |
마치며
도메인 변경 추적은 결국 HTTP 스펙의 기본 동작을 이해하는 문제입니다. 301은 “영구 이동”이고, 브라우저와 curl은 이 신호를 자동으로 따라갑니다. 이것만 알아도 대부분의 케이스는 30초 안에 해결됩니다.
리디렉션이 끊겼거나 도메인 자체가 사라진 경우라면 CDX API가 과거 이력을 채워줍니다. DNS 레벨까지 내려가는 건 그다음 단계입니다. 이 순서대로 시도하면 사이트 주소 하나 찾는 데 시간을 낭비하는 일은 없을 겁니다.
FAQ
curl -IL 최종 응답이 200인데 사이트 내용이 비어있다면?
200이어도 서버가 빈 HTML이나 파킹 페이지를 반환하는 케이스가 있습니다. 도메인이 만료 후 파킹 서비스로 넘어간 경우입니다. 이때는 curl -IL 출력의 Server 헤더가 GoDaddy 또는 Sedo 등 파킹 서비스 이름을 반환합니다. 실질적으로 사이트가 없어진 것으로 봐야 하며, Wayback Machine에서 마지막 활성 스냅샷을 찾는 것이 현실적인 대안입니다.
Wayback Machine CDX API에서 조회 결과가 하나도 없다면?
해당 도메인이 Wayback Machine에 아예 크롤링되지 않은 경우입니다. robots.txt에 User-agent: ia_archiver Disallow: /가 설정돼 있었거나, 로그인이 필요한 사이트였을 가능성이 높습니다. 이 경우 Google 캐시나 커뮤니티 공지 검색으로 전환하세요.
dig와 nslookup 중 어느 것을 써야 하나요?
Windows 환경에서는 기본 제공되는 nslookup을 쓸 수밖에 없습니다. macOS와 Linux에서는 dig가 출력이 더 상세하고 +trace 같은 고급 옵션이 많아 권장됩니다. 단순 IP 확인이라면 nslookup으로 충분합니다.
