TrueURL
TrueURL

메뉴

무료 리디렉션 도구

HTTPS 리디렉션 검사

도메인을 입력하면 방문자가 접속할 수 있는 네 가지 경로, 즉 www가 있거나 없는 http와 https를 모두 테스트합니다. 네 가지 모두 한 번의 영구 리디렉션으로 같은 HTTPS 주소에 도착해야 합니다.

HTTPS 검사 항목

TrueURL은 입력한 호스트로 네 가지 시작 URL을 만들어 각각 추적합니다.

  • http://example.com
  • http://www.example.com
  • https://example.com
  • https://www.example.com

올바르게 설정되어 있다면 네 가지 모두 하나의 표준 HTTPS URL에서 끝납니다. 그 버전은 바로 200 OK로 응답하고, 나머지 세 버전은 한 번의 301 또는 308로 그 URL에 도달합니다. HTTPS에서 HTTP로 되돌아가는 홉은 경고로 표시됩니다.

TrueURL은 HSTS도 검사합니다. 최종 HTTPS 응답(보통 표준 URL)에서 Strict-Transport-Security 헤더를 읽어 헤더 값 원문, max-age, 그리고 includeSubDomains와 preload 설정 여부를 보여 줍니다. max-age가 1년 이상이면 통과입니다. max-age가 그보다 짧거나 max-age=0인 경우, 유효한 max-age가 없는 헤더, 헤더가 아예 없는 경우는 경고로 표시됩니다.

흔한 HTTPS 리디렉션 문제와 해결 방법

  • HTTP에서 리디렉션 없음: http:// 버전이 리디렉션하지 않고 페이지를 그대로 보여 줍니다. 사이트 전체에 HTTPS 리디렉션을 추가하세요. canonical 태그만으로는 방문자를 보호할 수 없습니다.
  • 두 번 이상의 홉: 예를 들어 http://example.com에서 https://example.com을 거쳐 https://www.example.com으로 이동하는 경우입니다. 스킴 규칙과 호스트 규칙을 합쳐 모든 버전이 최종 URL로 바로 이동하게 하세요(단, 아래의 HSTS 프리로드 예외 참고).
  • 임시 리디렉션: HTTP에서 HTTPS로 302나 307을 사용하는 경우입니다. 검색엔진이 HTTPS 버전만 색인하도록 301이나 308을 사용하세요.
  • HTTPS 다운그레이드: https://에서 http://로 되돌아가는 홉입니다. 대개 잘못 남은 규칙이나, 프록시 또는 CDN 뒤에 있는 애플리케이션이 잘못된 스킴으로 절대 URL을 만드는 것이 원인입니다.
  • 인증서 오류: 한 버전(주로 www)이 인증서에 포함되어 있지 않습니다. Cloudflare 엣지는 항상 인증서를 검증하므로 해당 버전에는 리디렉션 대신 TLS 오류가 표시됩니다.
  • 버전 간 불일치: www와 non-www가 서로 다른 URL에서 끝나 신호가 두 호스트로 나뉩니다.

HSTS와 프리로드 예외

HSTS(Strict-Transport-Security)는 브라우저가 HTTP로 먼저 요청하지 않고 해당 도메인에 자동으로 HTTPS를 사용하도록 지시합니다. 일반적인 헤더는 Strict-Transport-Security: max-age=31536000; includeSubDomains입니다. 브라우저는 이 헤더를 HTTPS 응답에서만 받아들이고 일반 HTTP 응답에서는 무시합니다.

hstspreload.org에서 브라우저의 HSTS 프리로드 목록에 도메인을 등록하려면 HTTP에서 시작하는 첫 번째 홉이 같은 호스트에 머물러야 합니다. 즉 http://example.com에서 https://example.com으로 이동한 다음에야 https://www.example.com으로 가야 합니다. 이 두 홉짜리 체인은 단일 홉 원칙의 허용되는 예외입니다. 이때 헤더에는 1년 이상의 max-age, includeSubDomains, preload가 있어야 하며, HTTPS 리디렉션 응답 자체에도 이 헤더를 보내야 합니다.

HTTPS로 전환한 뒤 할 일

  • 크롤러가 계속 리디렉션을 거치지 않도록 내부 링크, canonical 태그, hreflang 주석, 사이트맵을 HTTPS URL로 업데이트하세요.
  • HTTP에서 HTTPS로 가는 리디렉션은 영구히 유지하세요. 예전 링크는 몇 년 동안 http://를 가리킵니다.
  • Google Search Console에서 사이트 HTTPS 버전의 소유권 확인이 완료되어 있는지 점검하고 업데이트한 사이트맵을 제출하세요.
  • CDN, 호스팅, 인증서를 변경할 때마다 다시 검사하세요.

가이드

자주 묻는 질문

HTTP가 HTTPS로 리다이렉트되는지 어떻게 확인하나요?

위에 도메인을 입력하세요. TrueURL이 www가 있는 버전과 없는 버전의 http://와 https://를 요청하고, 각각 어디에 도착하는지, 어떤 상태 코드가 사용되었는지, 몇 개의 홉을 거쳤는지 보여 줍니다. 네 가지 모두 같은 HTTPS URL에 도달하고 모든 리디렉션이 영구 리디렉션이라면 올바르게 설정된 것입니다.

www와 non-www 중 무엇을 사용해야 하나요?

SEO 측면에서는 어느 쪽이든 괜찮습니다. 중요한 것은 하나를 선택하고, 다른 쪽을 301로 그쪽에 리디렉션하며, 링크, canonical 태그, 사이트맵에서 일관되게 사용하는 것입니다. DNS는 루트 도메인에 CNAME 레코드를 허용하지 않으므로(일부 DNS 제공업체는 우회 방법을 제공합니다) www 호스트가 CDN에 연결하기 더 쉬울 수 있지만, 이는 기술적인 선택일 뿐 순위 요소는 아닙니다.

Chrome 개발자 도구에 HTTP에서 HTTPS로 갈 때 307이 표시되는 이유는 무엇인가요?

이 “307 Internal Redirect”는 사이트가 HSTS 목록에 있어서 Chrome이 자체적으로 만든 것이며, HTTP로는 요청이 아예 전송되지 않았습니다. 서버의 실제 리디렉션은 301이거나 전혀 다른 것일 수 있습니다. TrueURL에는 HSTS 캐시가 없으므로 항상 서버의 실제 응답을 보여 줍니다.

HTTP에서 HTTPS로 302 리디렉션하면 문제가 되나요?

작은 문제입니다. 방문자는 결국 HTTPS에 도착하지만, 임시 리디렉션은 HTTP URL이 다시 돌아올 수 있다고 검색엔진에 알리므로 전환이 늦어지거나 혼선이 생길 수 있습니다. 301이나 308로 바꾸세요.

사이트가 HSTS를 보내는지 어떻게 확인하나요?

위에 도메인을 입력하고 결과의 HSTS 헤더 항목을 확인하세요. TrueURL은 최종 HTTPS 응답에서 Strict-Transport-Security 헤더를 읽어 그 값과 max-age(1년 미만이면 경고), 그리고 includeSubDomains와 preload 설정 여부를 보여 줍니다. 이 헤더가 없으면 도메인을 직접 입력하거나 예전 http:// 링크로 시작하는 모든 방문이 암호화되지 않은 요청으로 시작되며, 같은 네트워크에 있는 누군가가 이를 가로챌 수 있습니다. 헤더가 있으면 이를 한 번 받은 브라우저는 다음부터 바로 HTTPS로 접속합니다. 처음에는 짧은 max-age로 시작하고, includeSubDomains를 추가하기 전에 모든 하위 도메인이 HTTPS로 작동하는지 확인한 다음, 값을 1년 이상으로 늘리세요.

인증서가 잘못되었거나 만료된 사이트도 테스트할 수 있나요?

문제는 확인할 수 있지만 그 너머는 볼 수 없습니다. Cloudflare 엣지에서는 SSL 오류 무시를 켜도 인증서 검증을 끌 수 없으므로, 해당 버전은 그 홉에서 TLS 오류를 표시합니다. 대개는 그것이 바로 알아야 할 정보입니다. 브라우저도 그 지점에서 방문자에게 경고를 표시하기 때문입니다.

모든 페이지를 리디렉션해야 하나요, 아니면 홈페이지만 하면 되나요?

모든 URL을 리디렉션해야 합니다. 사이트 전체 규칙은 http://example.com/any/path?query를 HTTPS의 같은 경로와 쿼리로 보내야 합니다. 하위 페이지 URL 몇 개는 리디렉션 체인 검사로, 여러 개는 리디렉션 일괄 검사로 한 번에 테스트하세요.