웹사이트 운영

Cloudflare Pages 도메인 연결과 중복 경로 점검

작성: KYD 디지털 가이드 편집팀 · 게시 2026년 7월 12일 · 최종 검토 2026년 9월 7일

Cloudflare Pages에 도메인을 연결할 때는 도메인 등록, DNS, Pages 프로젝트, 실제 배포 파일을 구분해야 합니다. 연결 성공 표시만으로 모든 경로가 원하는 파일을 제공하는지는 알 수 없습니다. 이 글에는 KYD에서 확인한 중복 경로 사례와 직접 비교할 주소를 담았습니다.

등록기관에서 바꾸는 것과 Pages에서 바꾸는 것

가비아 같은 등록기관은 도메인 소유와 갱신을 관리합니다. 권한 있는 DNS는 호스트가 어디로 연결되는지를 관리합니다. Pages 프로젝트는 어떤 저장소·브랜치·출력 폴더의 파일을 배포할지 관리합니다. 도메인 구매와 파일 게시를 같은 작업으로 생각하면 원인을 찾기 어렵습니다.

1. Pages의 배포 주소에서 의도한 페이지가 열리는지 먼저 확인합니다. 실패했다면 사용자 지정 도메인보다 빌드·파일 문제를 먼저 해결합니다.
2. 프로젝트의 Custom domains에 사용할 호스트를 추가합니다. 예를 들어 www와 루트 도메인은 서로 다른 호스트입니다.
3. Cloudflare 문서에 따라 DNS를 연결합니다. 루트 도메인은 Cloudflare 영역과 네임서버 설정이 필요하고, 외부 DNS를 사용하는 하위 도메인은 CNAME 방식 등 해당 조건을 확인합니다.
4. 기존 메일·다른 서비스의 DNS 레코드를 보존합니다. 네임서버 변경 전에 현재 레코드 목록을 확인하세요.
5. 도메인·인증서가 준비되면 HTTPS와 대표 주소 이동을 실제 요청으로 검사합니다.

이 사이트 운영자의 등록기관이 가비아라고 확인한 것은 아닙니다. 가비아는 등록기관 역할을 설명하는 예시입니다. 특정 대기 시간만으로 연결 성공·실패를 판단하지 말고 대시보드 오류와 실제 DNS 응답을 함께 확인하세요.

KYD에서 실제로 확인한 /public/ 중복

2026년 9월 6일 수정 전 공개 사이트에서 아래 네 주소를 비교했습니다. 홈과 파일 확장자 글이 각각 두 경로에서 모두 200을 반환했습니다. 이 관찰은 공개 HTTP 응답에 관한 것으로, 다른 프로젝트의 배포 설정까지 확인한 것은 아닙니다.

2026년 9월 7일 배포 후 확인: /public/은 /로, /public/posts/windows-file-extension/은 /posts/windows-file-extension/로 301을 반환했습니다. 이동한 목적지는 각각 200이었습니다. /blog는 /posts/로 301 이동하고, 존재하지 않는 임의 주소는 404를 반환했습니다. 수정 전후 같은 경로를 비교해 규칙의 실제 적용을 확인했습니다.

저장소에는 루트와 public 양쪽에 같은 배포 파일이 있었습니다. 루트를 게시하면 public도 웹 경로로 노출될 수 있습니다. 따라서 출력 폴더를 확인하는 것과 함께, 이미 공개된 중복 경로를 대표 주소로 보내는 처리가 필요했습니다. 일반적으로는 실제 게시할 폴더 하나를 명확히 정하는 편이 관리하기 쉽습니다.

리디렉션 규칙은 배포되는 폴더 안에 둡니다

정적 Pages 프로젝트에서 _redirects 파일은 배포 산출물에 포함돼야 합니다. 다음은 KYD의 public 접두 경로를 정리하기 위한 규칙 예시입니다. 파일이 없는 로컬 HTTP 서버에서는 Cloudflare 규칙이 실행되지 않습니다.

/public / 301
/public/* /:splat 301

와일드카드 뒤의 경로를 유지하므로 글 주소도 홈페이지로 뭉뚱그려 보내지 않습니다. Pages Functions가 처리하는 경로 등은 별도 규칙이 필요할 수 있으니 공식 문서의 적용 범위를 확인합니다. 기존 페이지를 이동할 때는 새 주소에서 실제로 같은 콘텐츠를 제공하는지 확인해야 합니다.

연결 후 여섯 가지를 각각 확인하세요

1. HTTP와 HTTPS: HTTP 요청이 의도한 HTTPS 대표 주소로 이동하는지 확인합니다.
2. www와 루트: 최종 주소가 한쪽으로 모이는지 봅니다.
3. 글 직접 접속: 홈페이지를 거치지 않고 글 URL을 열고 새로고침합니다.
4. 없는 페이지: 존재하지 않는 경로는 오류 페이지와 실제 404 상태를 제공해야 합니다. 겉모습만 오류인 200 응답과 다릅니다.
5. 크롤링 파일: robots.txt, sitemap.xml과 소유권 확인 파일이 HTML 홈페이지로 대체되지 않았는지 확인합니다.
6. 중복 경로: 공개 폴더 접두어·이전 주소·HTML 확장자 변형을 검사하고 canonical과 최종 주소를 비교합니다.

canonical은 검색엔진에 대표 URL을 알리는 표시이고, 301은 요청한 방문자를 다른 URL로 이동시키는 응답입니다. canonical이 있다는 이유만으로 불필요한 경로의 공개가 없어지지는 않습니다.

새 배포가 반영되지 않는다면

GitHub 커밋, Pages 운영 배포가 참조하는 커밋, 공개 HTML의 수정 문장을 비교합니다. 배포 성공을 확인하지 않고 DNS를 반복 변경하면 문제를 더 늘릴 수 있습니다. 예전 화면이 보일 때의 응답 비교 방법으로 배포와 캐시를 구분하세요.