엣지에서 처리하는 리다이렉트와 URL 정규화: www·슬래시·HTTPS 강제

URL이 여러 개면 무엇이 문제인가요?

같은 콘텐츠가 http·https·www·슬래시 차이로 여러 주소가 되면 캐시와 검색 평가가 쪼개집니다. 예를 들어 http://example.com/page, https://www.example.com/page/, https://example.com/page는 사람에게는 같은 페이지지만, 시스템에는 서로 다른 세 개의 URL입니다.

문제는 세 갈래로 번집니다. 첫째, 캐시 분산이에요. CDN은 URL을 기준으로 캐시를 저장하니, 변형마다 캐시 키가 따로 생겨 같은 파일을 여러 번 받아 옵니다. 히트율이 떨어지고 오리진 요청이 늘죠. 둘째, 검색 평가 분산입니다. 검색엔진이 여러 주소를 각각 다른 페이지로 보면, 한 페이지에 모여야 할 평가가 흩어집니다. 셋째, 분석과 로그도 주소별로 쪼개져 실제 트래픽을 읽기 어려워집니다.

301과 302는 어떻게 다른가요?

301은 주소가 영구히 바뀌었다는 뜻이고, 302는 임시 이동이라, 정규화에는 보통 301을 씁니다. 301(영구 이동)은 브라우저와 검색엔진이 그 사실을 기억하고, 원래 주소가 갖고 있던 검색 신호를 새 주소로 넘겨받아요. 그래서 대표 주소로 모으거나 HTTPS로 강제할 때처럼 앞으로도 유지될 이동에 알맞죠.

반면 302(임시 이동)는 지금만 잠깐 다른 곳으로 보낸다는 뜻이라, 검색 신호 이전이 일어나지 않습니다. 점검 페이지나 임시 실험처럼 곧 되돌릴 이동에 씁니다. 참고로 POST 같은 메서드를 그대로 유지해야 한다면 307·308을 쓰죠. 상태 코드 하나하나가 무엇을 뜻하는지는 HTTP 상태 코드로 CDN 읽기 글에서 정리했습니다.

엣지에서 정규화하면 무엇이 좋은가요?

리다이렉트를 엣지에서 끝내면 오리진까지 왕복하지 않아 빠르고, 규칙이 일관되며 오리진 부하도 줄어듭니다. 리다이렉트 응답 자체는 본문이 거의 없는 짧은 신호인데, 이걸 굳이 오리진까지 다녀와 만들 이유가 없죠. 엣지가 대신 즉시 응답하면 사용자는 더 빨리 대표 주소로 이동하고, 오리진은 불필요한 요청을 덜어냅니다.

또 하나 중요한 것이 리다이렉트 체인입니다. http에서 https로, 다시 non-www에서 www로, 또 슬래시를 붙이며 단계별로 넘기면 왕복이 세 번 쌓여 그만큼 느려져요. 엣지에서 규칙을 모아 두면 이 여러 단계를 한 번의 301로 최종 대표 주소까지 곧장 보낼 수 있습니다. 왕복 횟수를 줄이는 것이 체감 속도에 크게 작용한다는 점은 브라우저에 미리 알려주기 글의 결과 힌트와도 통하는 이야기죠.

정규화 규칙은 어떻게 정하나요?

대표 호스트, HTTPS 강제, 트레일링 슬래시, 대소문자, 기본 파일을 한 방향으로 정합니다. 핵심은 방향을 하나로 확정하는 것이에요. www로 갈지 non-www로 갈지, 슬래시를 붙일지 뗄지는 취향의 문제지만, 한 서비스 안에서는 반드시 한쪽으로 통일해야 합니다.

한 가지 주의할 점이 있습니다. 호스트 이름은 대소문자를 구분하지 않아 소문자로 통일해도 안전하지만, URL 경로는 오리진이 대소문자를 구분하는 경우가 있어요. 경로를 함부로 소문자로 바꾸면 있는 파일도 못 찾을 수 있으니, 경로 정규화는 서비스 동작을 확인한 뒤 적용해야 합니다. 리다이렉트로 해결하기 어려운 중복이 남는다면, 대표 주소를 알려 주는 rel="canonical"을 함께 쓰는 것도 방법이죠.

이것만 기억하세요

자주 묻는 질문 (FAQ)