접속주소 리다이렉트 유형 비교: 301·302·메타리프레시로 최신주소 진짜 이전인지 가려내기

주소창에 남은 문자열이 내가 누른 접속주소가 아닐 때

즐겨찾기에 저장해 둔 토토사이트 주소를 눌렀는데, 화면이 다 뜨고 나서 주소창을 보면 저장해 둔 문자열과 다른 도메인이 앉아 있는 경우가 있다. 링크를 두 번 누른 것도 아니고 새 창이 열린 것도 아닌데 목적지가 달라져 있다. 그 사이에서 벌어진 일이 리다이렉트, 즉 요청을 받은 서버가 브라우저에게 다른 주소로 다시 가라고 지시하는 전환이다. 접속은 성공했으니 대부분은 그냥 넘어가지만, 이 한 단계가 최신주소를 판단하는 데 가장 많은 정보를 담고 있다.

리다이렉트 자체는 좋고 나쁨이 없는 중립적인 기술이다. 운영이 도메인을 정식으로 옮기면서 옛 주소에 안내용 전환을 걸어두는 것도 리다이렉트고, 비슷한 철자의 도메인을 사둔 쪽이 방문자를 자기 페이지로 끌어가는 것도 같은 리다이렉트다. 그래서 전환이 일어났다는 사실만으로는 아무것도 결론 낼 수 없다. 어떤 유형의 전환인지, 몇 단계를 거쳤는지, 최종 목적지의 등록정보가 무엇인지를 함께 놓고 봐야 판단이 선다.

아래 표는 접속주소를 눌렀을 때 실제로 마주치는 전환 방식을 여덟 가지로 갈라 정리한 것이다. 왼쪽은 유형, 가운데는 사용자가 눈으로 확인할 수 있는 신호, 오른쪽은 최신주소 판단에서 그 신호를 어떻게 읽어야 하는지다. 표를 먼저 훑고 나면 이후 설명이 훨씬 빨리 붙는다.

전환 방식 여덟 가지 비교표

301과 302, 상태코드만으로 진위가 갈리지 않는 이유

표에서 가장 헷갈리는 두 줄이 첫 번째와 두 번째다. 흔히 301은 정상적인 도메인 변경, 302는 수상한 우회라고 단정하는 설명을 보게 되는데 실제로는 그렇게 깔끔하게 나뉘지 않는다. 301은 이 주소는 앞으로 영원히 저쪽이라는 선언이고, 302는 지금만 저쪽으로 가라는 임시 지시다. 도메인을 완전히 접고 옮기는 상황이라면 301이 자연스럽지만, 접속이 몰려 서버를 나눠 쓰거나 며칠 뒤 원래 주소로 돌아올 계획이라면 302 쪽이 오히려 기술적으로 맞는 선택이다.

그래서 상태코드는 진위 판정의 근거가 아니라 이후 관찰 주기를 정하는 근거로 쓰는 편이 낫다. 301을 만났다면 옛 주소는 정리 대상으로 분류하고 새 주소를 정본으로 올린다. 302나 307을 만났다면 아직 확정이 아니라는 뜻이므로 사흘에서 일주일 간격으로 목적지가 유지되는지 다시 확인하고, 그 사이 즐겨찾기는 옛 주소와 새 주소를 함께 남겨 둔다. 같은 302가 2주 넘게 같은 목적지를 가리키고 있다면 사실상 이전이 끝난 것으로 봐도 된다.

브라우저가 기억해 버린 301이 만드는 착시

표의 첫 줄 오른쪽에 적어둔 단서가 실제로는 가장 자주 사람을 헷갈리게 만든다. 301은 영구 이동이라는 의미 때문에 브라우저가 그 지시를 로컬에 저장한다. 한 번 301을 받은 주소는 다음부터 서버에 묻지 않고 바로 새 주소로 넘어간다. 즉 원래 서버가 이미 꺼졌거나 그 전환 설정을 지운 뒤에도, 내 브라우저에서는 여전히 옛 주소가 매끄럽게 새 주소로 이어지는 것처럼 보인다.

이 착시가 위험해지는 건 반대 방향에서다. 옛 주소가 만료되어 제3자에게 재등록됐는데도 내 브라우저는 캐시된 지시대로 예전 목적지를 열어준다. 반면 같은 링크를 받은 다른 사람은 재등록된 새 주인의 페이지로 들어간다. 두 사람이 같은 주소를 놓고 서로 다른 화면을 보며 다투게 되는 상황이 여기서 생긴다. 확인이 필요할 때는 시크릿 창을 새로 열거나 방문 기록과 캐시를 지운 뒤 다시 눌러 보는 절차를 앞에 두어야 한다.

실무적으로는 검증할 주소 하나당 일반 창 1회, 캐시를 비운 시크릿 창 1회로 두 번 열어보는 습관이면 충분하다. 두 결과가 다르면 그 차이 자체가 정보다. 일반 창에서만 잘 열린다면 내 브라우저가 붙들고 있는 옛 기억일 뿐, 지금 유효한 최신주소는 아니라는 뜻이다.

흰 화면 0.5초의 정체, 메타 리프레시와 스크립트 전환

표의 네 번째와 다섯 번째 줄은 서버가 아니라 페이지 안에서 일어나는 전환이다. 메타 리프레시는 HTML 문서 맨 위에 몇 초 뒤 어디로 가라는 한 줄을 넣어두는 방식이고, 스크립트 전환은 그 일을 자바스크립트가 한다. 둘 다 서버 설정 권한이 없어도 되고, 무료 호스팅에 파일 하나만 올려도 동작한다. 복제 페이지들이 이 두 가지를 선호하는 이유가 정확히 여기에 있다.

구분하는 방법은 단순하다. 브라우저 설정에서 해당 사이트의 자바스크립트를 잠시 끄고 같은 주소를 다시 열어보면, 스크립트 전환은 멈추고 원래 페이지에 그대로 남는다. 메타 리프레시는 스크립트와 무관하게 계속 넘어간다. 멈춰 세운 화면의 소스에는 목적지 주소가 그대로 적혀 있으므로, 실제로 어디로 보내려 했는지를 눈으로 읽을 수 있다. 스크립트를 껐을 때 목적지가 달라진다면 방문자별로 다른 곳을 열어주도록 짜인 페이지이며, 이런 링크는 검증 대상이 아니라 폐기 대상이다.

체인이 몇 단계부터 손을 떼야 하는가

전환은 한 번으로 끝나지 않을 때가 많다. 단축주소 하나가 추적 도메인을 거치고, 거기서 다시 안내 페이지로, 안내 페이지가 최종 도메인으로 넘기면 벌써 세 단계다. 정상적인 운영 환경에서도 두 단계까지는 흔하다. 문제는 그 이상이다. 단계가 늘어날수록 중간에 낀 주소 가운데 하나만 남의 손에 넘어가도 최종 목적지 전체가 바뀌는데, 사용자는 마지막 화면만 보기 때문에 어디서 갈라졌는지 알 수 없다.

기준선을 숫자로 잡아두면 판단이 빨라진다. 1~2단계는 그대로 진행, 3단계는 중간 도메인들을 하나씩 적어두고 진행, 4단계 이상이면 그 경로를 버리고 다른 경로로 같은 주소를 다시 구한다. 특히 중간에 서로 다른 최상위 도메인이 세 개 이상 섞여 있다면 단계 수와 상관없이 신뢰도를 낮게 본다. 정상적인 도메인 교체는 보통 옛 도메인에서 새 도메인으로 한 번에 이어지지, 국적과 확장자가 제각각인 주소를 네 번 갈아타지 않는다.

주소창이 그대로인데 화면이 다를 때

표의 마지막 두 줄은 전환 신호가 아예 보이지 않는 경우다. 프레임 감싸기는 겉껍데기 페이지가 자기 주소를 유지한 채 안쪽에 다른 사이트를 통째로 끼워 넣는 방식이다. 주소창에는 내가 아는 문자열이 그대로 있으니 안심하게 되지만, 실제로 보고 있는 내용은 전혀 다른 서버에서 온 것이다. 화면 안에서 마우스 오른쪽 버튼을 눌렀을 때 프레임 관련 항목이 뜨거나, 스크롤 막대가 두 겹으로 보이는 것이 흔한 단서다.

DNS 교체는 더 조용하다. 주소는 바뀌지 않았고 전환도 없었는데 도착지 서버만 달라진 상태다. 도메인이 만료되어 다른 사람이 가져갔거나, 등록 계정이 넘어간 경우에 이렇게 된다. 이때는 겉으로 드러나는 신호가 화면 구성의 미세한 차이뿐이라 알아채기가 가장 어렵다. 주소가 그대로라는 사실은 안전의 근거가 되지 못한다는 점만 기억해도 절반은 걸러진다.

화요일 밤에 네 단계를 되짚은 12분

지인이 메신저로 보내온 짧은 주소를 눌렀더니 로딩 표시가 두 번 깜빡이고 낯선 도메인이 열렸다. 처음 눌린 것은 단축주소, 두 번째는 처음 보는 추적용 도메인, 세 번째는 흰 화면이 1초쯤 머문 안내 페이지, 마지막이 실제 목적지였다. 네 단계였고 사용된 확장자는 서로 달랐다. 눈으로는 매끄러웠지만 개발자도구를 켜고 다시 열어보니 중간 두 단계가 각각 메타 리프레시와 302였다.

여기서 결론을 내리지 않고, 같은 주소를 시크릿 창에서 다시 열었다. 이번에는 세 번째 단계의 안내 페이지가 다른 도메인을 가리켰다. 같은 링크가 두 번의 접속에서 서로 다른 최종 목적지를 준 것이다. 그 시점에서 이 링크는 최신주소 후보에서 제외했고, 대신 평소 기록해 두던 경로로 주소를 새로 확인해 대조했다. 확인된 도메인은 등록 후 14개월이 지나 있었고 만료까지 8개월이 남아 있었다.

전 과정에 12분이 걸렸다. 이 12분을 아끼려고 첫 화면만 보고 넘어갔다면, 세션마다 목적지를 바꾸는 링크를 즐겨찾기에 저장해 두었을 것이다. 나중에 접속이 이상해졌을 때 원인을 되짚기는 훨씬 더 오래 걸린다.

개발자도구 네트워크 탭에서 체인을 펼쳐 읽기

지금까지의 신호들은 대부분 눈으로도 잡히지만, 확실히 보려면 브라우저 개발자도구의 네트워크 탭을 쓰는 편이 빠르다. 도구를 먼저 열고 로그 보존 옵션을 켠 다음 주소를 입력하면, 전환된 단계들이 사라지지 않고 목록에 차례로 남는다. 각 줄의 상태코드 칸에서 301인지 302인지가 보이고, 응답 헤더의 목적지 항목에 다음으로 보내려는 주소가 그대로 적혀 있다.

이 방법의 장점은 화면이 아예 열리지 않는 상황에서도 쓸 수 있다는 것이다. 최종 페이지가 오류를 내더라도 그 앞 단계들의 기록은 남아 있어서, 어디까지 정상이었고 어디서 끊겼는지 구간을 좁힐 수 있다. 모바일에서는 이 탭을 쓰기 어려우므로, 의심스러운 링크는 판단을 미루고 PC에서 확인하는 쪽이 낫다. 메신저 인앱 브라우저는 전환 기록을 거의 보여주지 않는다는 점도 함께 기억해 둘 만하다.

주소모음 옆에 남기는 전환 기록의 형식

확인한 내용은 그때만 알고 있어도 소용이 없다. 링크모음이나 즐겨찾기 폴더를 정리할 때, 각 접속주소 옆에 전환 정보를 한 줄로 붙여두면 다음 도메인 변경 때 판단 속도가 달라진다. 형식은 길 필요가 없다. 확인한 날짜, 전환 유형과 단계 수, 최종 도메인, 그리고 재확인 예정일 정도면 충분하다.

예를 들어 09-06 / 302 2단계 / 최종 확장자 com / 09-13 재확인처럼 적어두면, 일주일 뒤 같은 주소를 열었을 때 목적지가 그대로인지 바뀌었는지 즉시 대조된다. 302로 기록해 둔 항목이 어느 날 301로 바뀌어 있다면 임시 조치가 정식 이전으로 굳어졌다는 뜻이므로 그때 정본을 교체하면 된다. 반대로 301로 적어둔 항목에서 갑자기 새로운 중간 단계가 늘어났다면, 경로 어딘가가 남의 손에 넘어갔을 가능성을 먼저 의심한다.

기록이 쌓이면 특정 주소의 전환 습관이 보인다. 어떤 주소는 늘 한 단계로 끝나고, 어떤 주소는 점검 시간대마다 임시 전환을 붙인다. 그 패턴에서 벗어나는 순간이 바로 확인이 필요한 순간이다. 상태코드를 외우는 것보다 내 기록과 지금 화면이 어긋나는지를 보는 쪽이 훨씬 실용적이다.

다음에 주소창이 바뀔 때 볼 것

전환은 접속 과정에서 가장 빨리 지나가고 가장 적게 의심받는 구간이다. 그러나 도메인 변경이 잦은 환경에서는 이 구간에 담긴 정보가 최신주소가 진짜 이전인지, 아니면 누군가 끼어든 결과인지를 가르는 거의 유일한 실마리다. 다음에 주소창이 저절로 바뀌는 것을 보게 되면, 화면 내용을 살피기 전에 몇 단계를 거쳤고 마지막에 남은 도메인이 무엇인지부터 확인해 보면 된다.

그 한 번의 확인에 드는 시간은 길어야 2~3분이다. 반대로 잘못 저장한 링크 하나를 나중에 되짚는 데는 훨씬 긴 시간과 불필요한 위험이 따라붙는다. 표의 여덟 줄 가운데 지금 내 화면이 어디에 해당하는지만 짚어도, 대부분의 판단은 그 자리에서 끝난다.