Cloudflare Pages에 배포한 정적 사이트나 랜딩페이지를 자체 도메인으로 열고 싶다면, 먼저 Pages 프로젝트에 커스텀 도메인을 추가한 뒤 DNS 레코드와 SSL/TLS 상태를 차례로 확인하는 방식이 가장 안전합니다. 연결이 안 될 때는 대부분 도메인 입력, DNS 레코드 유형, 기존 레코드 충돌, SSL 인증서 준비 상태 중 하나에서 막히므로 한 번에 여러 설정을 바꾸기보다 아래 순서대로 점검하세요.
핵심 요약
1) Cloudflare Pages 프로젝트에서 사용할 도메인 또는 하위 도메인을 먼저 추가합니다.
2) Cloudflare DNS의 레코드 화면에서 안내된 레코드가 맞는지 확인합니다.
3) 루트 도메인, www, 캠페인용 하위 도메인을 구분해 테스트합니다.
4) HTTPS 접속은 SSL/TLS 인증서 준비와 브라우저 캐시 영향까지 함께 봅니다.
5) Cloudflare 화면, 요금제, 메뉴 이름, 기능 위치는 바뀔 수 있으므로 배포 직전 공식 문서를 다시 확인하세요.
1. 이 작업이 필요한 상황부터 구분하세요
Cloudflare Pages는 HTML, CSS, JavaScript 기반의 정적 웹사이트나 프론트엔드 앱을 배포할 때 자주 쓰입니다. 기본 Pages 주소로는 테스트가 가능하지만, 실제 업무용 랜딩페이지나 포트폴리오, 제품 안내 페이지라면 자체 도메인을 붙여야 방문자에게 신뢰감을 줄 수 있습니다. 이때 핵심은 “사이트 배포”와 “도메인 연결”을 같은 작업으로 보지 않는 것입니다. Pages 프로젝트가 정상 배포되어도 도메인 DNS가 맞지 않으면 방문자는 다른 서버로 이동하거나 오류 화면을 보게 됩니다.
따라서 첫 단계에서는 이미 Pages 프로젝트가 열리는지, 빌드 결과가 최신인지, 기본 제공 주소에서 페이지가 표시되는지 확인합니다. 기본 주소도 열리지 않는다면 도메인 문제가 아니라 빌드, 배포 브랜치, 출력 폴더 문제일 수 있습니다. 반대로 기본 주소는 정상인데 자체 도메인만 안 열린다면 DNS와 SSL/TLS 점검으로 좁혀도 됩니다.
2. 루트 도메인과 하위 도메인을 먼저 결정합니다
가장 흔한 실수는 연결할 주소를 정하지 않은 채 DNS 레코드를 여러 개 만드는 것입니다. 예를 들어 example.com으로 열지, www.example.com으로 열지, 또는 landing.example.com처럼 캠페인 전용 하위 도메인으로 열지 먼저 정해야 합니다. 주소별로 DNS 이름과 레코드가 달라질 수 있고, 이미 다른 서비스가 쓰고 있는 레코드와 충돌할 수도 있습니다.
회사 소개 사이트는 루트 도메인이나 www를 쓰는 경우가 많고, 테스트 페이지·이벤트 페이지·문서 사이트는 하위 도메인이 관리하기 쉽습니다. 기존 운영 사이트가 있다면 루트 도메인을 건드리기 전에 하위 도메인으로 먼저 연결해 검증하는 편이 안전합니다. 운영 중인 메일, 기존 웹호스팅, 다른 SaaS 연결이 있다면 현재 DNS 레코드를 백업하거나 캡처해 두세요.
3. Pages 프로젝트에서 커스텀 도메인을 추가합니다
Cloudflare 공식 문서 기준으로 Pages의 커스텀 도메인 설정은 Pages 프로젝트와 연결할 도메인 또는 하위 도메인을 등록하는 흐름입니다. Pages 프로젝트 화면에서 커스텀 도메인 항목을 추가하고, 연결하려는 주소를 정확히 입력합니다. 철자, www 포함 여부, 하위 도메인 이름을 실수하면 DNS가 맞아도 원하는 주소로 열리지 않습니다.
도메인을 Cloudflare가 관리하고 있다면 안내 화면이 DNS 설정과 이어지는 경우가 많습니다. 그렇더라도 자동으로 모든 충돌이 해결된다고 생각하면 안 됩니다. 같은 이름의 기존 A, AAAA, CNAME 레코드가 남아 있으면 새 연결이 예상대로 동작하지 않을 수 있습니다. 특히 루트 도메인은 다른 서비스와 연결되어 있을 가능성이 높으므로, 실제 운영 주소라면 변경 전에 기존 사용처를 반드시 확인해야 합니다.
4. DNS 레코드는 이름, 유형, 대상 값을 나눠 봅니다
Cloudflare DNS 문서는 DNS 레코드를 만들고 수정하는 기본 화면을 안내합니다. 실무 점검에서는 레코드 한 줄을 통째로 보지 말고 이름, 유형, 대상 값으로 쪼개서 확인하는 것이 좋습니다. 이름은 @, www, landing처럼 방문자가 입력할 주소의 앞부분입니다. 유형은 A, AAAA, CNAME 등 연결 방식입니다. 대상 값은 실제로 가리킬 위치입니다.
정적 사이트 연결에서는 하위 도메인에 CNAME이 쓰이는 경우가 많지만, 상황에 따라 Cloudflare 화면이 요구하는 값이 다를 수 있습니다. 공식 화면이 제시하는 값을 우선하고, 블로그 글이나 예전 캡처에 나온 값을 그대로 복사하지 마세요. DNS는 보이는 메뉴가 단순해도 영향 범위가 넓습니다. 잘못된 레코드는 사이트뿐 아니라 기존 서비스 접속 흐름까지 바꿀 수 있습니다.
5. 기존 레코드 충돌을 정리하는 체크리스트
| 확인 항목 | 점검 방법 | 주의점 |
|---|---|---|
| 같은 이름의 기존 레코드 | DNS Records 화면에서 같은 Name 값을 검색 | 같은 주소가 다른 서비스로 향하면 연결이 꼬일 수 있음 |
| www와 루트 도메인 구분 | example.com과 www.example.com을 따로 테스트 |
둘 중 하나만 연결되어도 다른 하나는 오류가 날 수 있음 |
| 하위 도메인 철자 | Pages에 입력한 주소와 DNS 이름 비교 | dash, dot, 복수형 오타가 자주 발생 |
| DNS 전파 대기 | 변경 직후와 몇 분 뒤를 나눠 확인 | 브라우저 캐시와 네트워크 캐시가 결과를 늦게 보여줄 수 있음 |
| 운영 영향 | 기존 웹사이트, 메일, 외부 도구 사용처 확인 | 중요 주소라면 업무 시간 외 변경이 안전 |
6. SSL/TLS 상태는 “자물쇠가 보이는지”만 보지 않습니다
Cloudflare SSL/TLS 문서는 방문자, Cloudflare, 원본 서버 사이의 암호화 연결과 인증서 관리를 다룹니다. Pages에 커스텀 도메인을 추가하면 HTTPS가 준비되는 동안 잠시 대기 상태가 보일 수 있습니다. 이때 브라우저에서 바로 접속해 오류가 난다고 해서 무작정 레코드를 지우고 다시 만들면 원인 추적이 어려워집니다.
점검 순서는 간단합니다. 먼저 Cloudflare 화면에서 도메인 연결 상태와 인증서 관련 메시지를 확인합니다. 다음으로 https:// 주소와 http:// 주소가 어떻게 동작하는지 봅니다. 마지막으로 다른 브라우저나 시크릿 창에서 테스트해 캐시 영향을 줄입니다. SSL/TLS 모드, 인증서 발급 상태, Cloudflare 정책 화면은 시점에 따라 달라질 수 있으므로, 중요한 페이지를 공개하기 전 공식 문서와 현재 대시보드 문구를 다시 확인하는 것이 좋습니다.
7. 연결 후에는 리디렉션과 기본 주소를 정리합니다
도메인이 열린다고 해서 작업이 끝난 것은 아닙니다. 방문자가 www를 붙여 들어오는지, 루트 도메인으로 들어오는지, 캠페인 링크가 하위 도메인을 쓰는지에 따라 하나의 대표 주소를 정해야 합니다. 대표 주소가 흩어지면 북마크, 공유 링크, 분석 도구의 페이지 주소가 나뉘어 관리가 어려워집니다.
운영 실무에서는 대표 주소 하나를 정하고, 나머지 주소는 필요한 경우 리디렉션 정책이나 안내 페이지로 정리합니다. 이때도 기존 서비스와 충돌하지 않도록 조심해야 합니다. 특히 루트 도메인을 이미 다른 호스팅에서 쓰고 있다면 Pages 연결을 하위 도메인부터 시작하고, 이후 전환 계획을 따로 잡는 편이 안전합니다.
8. 업무용 랜딩페이지라면 공개 전 검수 항목을 남기세요
Cloudflare Pages 커스텀 도메인 연결은 기술적으로는 짧은 작업처럼 보이지만, 실제 공개 품질은 검수표에서 갈립니다. 최소한 기본 주소, 커스텀 도메인, 모바일 화면, HTTPS, 양식 제출, 분석 스크립트, 검색 노출 설정을 함께 봐야 합니다. 도메인 연결만 성공하고 폼 전송이나 버튼 링크가 깨진 상태로 광고를 집행하면 방문자를 놓치기 쉽습니다.
- 기본 Pages 주소와 커스텀 도메인 모두 최신 배포본을 보여주는지 확인
- 모바일 브라우저에서 상단 주소와 HTTPS 표시 확인
- 문의 버튼, 다운로드 버튼, 결제 전환 버튼 등 주요 링크 클릭 테스트
- 분석 도구, 픽셀, 태그 매니저가 새 도메인 기준으로 동작하는지 확인
- 운영 문서에 DNS 변경 시간, 변경한 레코드, 담당자, 되돌림 방법 기록
9. 자주 막히는 오류별 빠른 분기
브라우저가 “사이트를 찾을 수 없음”에 가까운 메시지를 보인다면 DNS 이름이나 레코드 대상부터 봅니다. Cloudflare 화면에서 도메인 연결은 되었지만 HTTPS 오류가 보인다면 SSL/TLS 준비 상태와 인증서 메시지를 확인합니다. 어떤 네트워크에서는 열리고 어떤 네트워크에서는 안 열린다면 DNS 캐시 또는 전파 대기 가능성을 둡니다. 특정 경로만 404라면 도메인 문제가 아니라 Pages 빌드 결과, 라우팅, SPA 설정 문제일 수 있습니다.
중요한 점은 한 번에 여러 설정을 바꾸지 않는 것입니다. DNS 레코드, Pages 도메인, SSL/TLS 옵션, 빌드 설정을 동시에 바꾸면 무엇이 해결책이었는지 남지 않습니다. 변경 전후 화면을 캡처하고, 한 단계씩 기다리며 테스트 결과를 남기면 다음 연결 작업도 빨라집니다.
10. 마무리: 도메인 연결은 배포가 아니라 운영 절차입니다
Cloudflare Pages 커스텀 도메인은 랜딩페이지, 문서 사이트, 포트폴리오, 내부 도구 안내 페이지를 빠르게 공개할 때 유용합니다. 다만 DNS와 SSL/TLS는 작은 실수가 전체 접속 경험을 바꿀 수 있으므로, Pages 프로젝트 추가 → DNS 레코드 확인 → SSL/TLS 상태 확인 → 대표 주소 정리 → 공개 전 검수 순서로 진행하세요. Cloudflare의 화면 이름, 기능 위치, 요금제 조건, 인증서 처리 방식은 시간이 지나며 달라질 수 있습니다. 실제 운영 전에는 현재 대시보드와 공식 문서를 기준으로 마지막 확인을 남기는 것이 안전합니다.
FAQ
Q1. Cloudflare Pages 기본 주소가 열리면 커스텀 도메인도 바로 열리나요?
아닙니다. 기본 주소는 Pages 배포 확인이고, 커스텀 도메인은 별도의 도메인 추가와 DNS 확인이 필요합니다. 기본 주소가 정상이라면 도메인 문제를 더 좁혀 볼 수 있을 뿐입니다.
Q2. www와 루트 도메인은 같은 설정인가요?
같지 않습니다. example.com과 www.example.com은 DNS에서 별도 이름으로 관리될 수 있습니다. 둘 다 쓰고 싶다면 각각의 연결 상태와 대표 주소 정책을 확인해야 합니다.
Q3. DNS를 바꿨는데 바로 안 열리면 실패인가요?
바로 실패라고 단정하지 마세요. DNS 캐시, 브라우저 캐시, SSL/TLS 준비 시간 때문에 결과가 늦게 보일 수 있습니다. 다만 같은 이름의 기존 레코드 충돌이나 오타가 없는지는 즉시 확인하는 것이 좋습니다.
Q4. SSL 오류가 보이면 어떤 순서로 봐야 하나요?
Cloudflare 대시보드의 도메인 연결 상태, 인증서 관련 메시지, SSL/TLS 설정 화면을 먼저 봅니다. 그다음 시크릿 창이나 다른 브라우저로 접속해 캐시 영향을 줄이고, 공식 문서 기준으로 현재 화면 문구를 확인하세요.
Q5. 실무에서 가장 안전한 시작 방식은 무엇인가요?
기존 운영 사이트가 있다면 루트 도메인을 바로 바꾸기보다 landing.example.com 같은 하위 도메인으로 먼저 연결해 검증하는 방식이 안전합니다. 검수 후 대표 주소 전환 계획을 따로 잡으면 되돌림도 쉽습니다.
