가비아에서 산 도메인을 Cloudflare Pages에 연결해도 도메인 등록기관까지 옮길 필요는 없습니다. 등록·갱신은 가비아에 두고 DNS와 웹사이트 배포는 Cloudflare에서 관리할 수 있습니다.
이 문서는 GitHub에 있는 정적 사이트를 루트 도메인에 연결하는 흐름입니다. 이미 연결된 사이트라면 네임서버를 다시 바꾸지 말고 현재 어느 단계가 정상인지부터 확인하세요. 설명을 위해 설정을 안내하며, 이 글의 개정 과정에서 실제 계정 설정을 변경하지는 않았습니다.
1. 세 곳에서 맡는 일을 구분하기
| 구분 | 이 구성의 담당 | 확인할 것 |
|---|---|---|
| 등록과 갱신 | 가비아 | 소유자 연락처, 만료일, 사용 중인 네임서버 |
| DNS 레코드 | Cloudflare | 웹 연결, 메일, 소유권 확인 레코드 |
| 소스와 배포 | GitHub와 Cloudflare Pages | 배포 브랜치, 빌드 명령, 결과 폴더, 커스텀 도메인 |
루트 주소를 Pages에 연결하는 일반적인 구성에서는 도메인을 Cloudflare 영역으로 추가하고 안내받은 네임서버를 사용합니다. 하위 도메인만 연결하는 경우에는 외부 DNS에 CNAME을 추가하는 다른 구성이 가능하므로 루트 연결 절차와 혼동하지 마세요. Pages 커스텀 도메인 문서가 두 경우를 구분합니다.
2. 네임서버 변경 전에 반드시 남길 기록
현재 네임서버와 DNS 레코드를 내보내거나 별도 목록으로 보관합니다. 자동 가져오기가 기존 레코드를 전부 찾았다고 가정하지 마세요. 특히 메일을 사용 중이라면 홈페이지가 열리는 것과 메일이 유지되는 것은 별개입니다.
- 웹: 루트와 www, 운영 중인 다른 하위 도메인의 연결값.
- 메일: MX, SPF용 TXT, DKIM, DMARC 및 메일 서비스가 요구하는 관련 레코드.
- 인증: Search Console과 다른 외부 서비스의 TXT/CNAME.
- 전환: 변경 전 값, 변경 담당자, 되돌릴 조건과 연락할 공급업체.
Cloudflare에 가져온 목록을 원본과 비교한 다음 변경합니다. DNSSEC을 사용 중이면 기존 DS 정보와 새 DNS의 서명이 맞지 않아 접속이 실패할 수 있으므로, 공식 전환 절차에 따라 조정하고 전환 후 보호를 다시 구성해야 합니다. 잘 모르는 보안 옵션을 일괄 해제하는 방식으로 해결하지 마세요.
3. 도메인보다 먼저 Pages 기본 배포 확인
Cloudflare의 Workers & Pages에서 Pages 프로젝트를 만들고 GitHub 저장소를 연결합니다. 실제 사이트가 되는 배포 브랜치를 선택한 뒤 빌드 명령과 결과 폴더를 확인합니다. 다른 프레임워크에 이 사이트의 설정값을 그대로 넣지는 마세요.
| 항목 | 값 | 확인 근거 |
|---|---|---|
| 빌드 명령 | npm run build | package.json의 build 항목 |
| 결과 폴더 | dist | 생성되는 dist/index.html과 하위 글 주소 |
| 운영 브랜치 | main | 이 저장소에서 사용하는 브랜치. 다른 저장소는 실제 설정에 맞춤 |
먼저 발급된 자신의-프로젝트.pages.dev 주소에서 홈과 하위 글을 엽니다. 기본 배포가 실패한다면 DNS를 바꾸기 전에 빌드 로그와 결과 폴더를 고칩니다. Pages에는 실제 정적 결과물만 배포하고, 환경변수나 자격 증명 파일을 공개 폴더에 넣지 않습니다.
4. 가비아 네임서버와 Pages 도메인 연결
- Cloudflare에 도메인을 추가하고 가져온 DNS와 보존할 레코드를 비교합니다. 해당 도메인에 배정된 네임서버 값을 기록합니다.
- 가비아의 도메인 관리에서 대상 도메인과 네임서버 설정을 찾습니다. 다른 사람의 예시 네임서버가 아닌 본인에게 배정된 값을 사용하고 소유자 인증 후 적용합니다. 화면이 다르면 가비아 공식 네임서버 안내를 확인합니다.
- Cloudflare Pages 프로젝트의 Custom domains에서 루트 도메인을 연결하고 안내되는 DNS 작업을 완료합니다. DNS에 CNAME만 만들고 Pages 쪽 연결을 생략하지 않습니다.
- www를 사용할 경우 www도 연결하고 대표 주소로의 이동 방식을 별도로 정합니다. 루트가 열린다고 www도 자동으로 준비됐다고 판단하지 않습니다.
변경 전파와 인증서 준비는 서로 다른 과정입니다. 반복해서 네임서버를 바꾸기보다 현재 NS 응답, Pages 도메인 상태, HTTPS 결과를 나눠 확인하세요. 변경이 꼭 필요하지 않은 기존 정상 사이트에서는 이 절차를 재실행하지 않습니다.
5. 어디가 고장 났는지 분리하기
| 증상 | 먼저 확인할 것 | 피할 조치 |
|---|---|---|
| pages.dev도 열리지 않음 | 빌드 로그, 배포 결과와 index.html | 네임서버를 반복 변경 |
| pages.dev는 정상, 커스텀 도메인은 실패 | Pages의 도메인 연결과 실제 DNS 값 | 무관한 MX/TXT 삭제 |
| 522 등 연결 실패 | Pages에 해당 이름을 먼저 연결했는지. 오류의 다른 원인도 함께 확인 | 방화벽을 전부 끄거나 오류를 무조건 DNS 전파로 단정 |
| 홈은 정상, 하위 글은 404 | 결과 폴더에 해당 경로의 파일이 생성됐는지 | 모든 주소를 홈으로 보내 오류 숨기기 |
| 웹은 정상, 메일만 실패 | 기존 메일 공급업체의 MX와 관련 인증 레코드 | 웹 연결 성공을 전체 전환 성공으로 간주 |
문제가 생기면 변경 전후 값을 비교해 해당 항목만 복구합니다. 기존 네임서버로 되돌리는 결정도 전파 지연과 메일 영향을 고려해야 합니다. 서비스 중단이 큰 손실로 이어지는 도메인은 전환 전에 담당 공급업체와 복구 절차를 합의하세요.
6. 이 사이트에서 공개적으로 확인한 범위
2026년 10월 26일 공개 DNS 조회에서 alphaadsense.com의 네임서버는 Cloudflare 주소로 응답했습니다. 홈과 사이트맵도 HTTPS에서 200 응답을 확인했습니다. 이 결과는 공개 응답 검사이며, 가비아 결제 상태나 Cloudflare 관리자 화면의 모든 설정, 메일 송수신까지 확인한 것은 아닙니다.
배포 완료 여부는 기본 주소만이 아니라 대표 도메인의 실제 글에서 확인합니다. 연결이 끝나면 Search Console 인증 방법을 선택할 수 있지만, HTTPS 정상화나 소유권 인증 자체가 AdSense 승인을 보장하지는 않습니다.
공식 자료와 확인 범위
공식 자료 확인일: . 정책 판단은 원문과 현재 계정 안내를 함께 확인하세요.
- 가비아 네임서버 관리하기
네임서버 입력, 소유자 인증과 변경 시 주의사항을 확인하는 공식 안내입니다.
- Cloudflare Pages Git integration
저장소 연결, 배포 브랜치와 빌드 설정에 관한 안내입니다.
- Cloudflare Pages Custom domains
루트/하위 도메인의 연결 조건과 Pages 쪽 도메인 등록 절차입니다.
- Cloudflare 네임서버 전환
기존 DNS 레코드 검토, 네임서버와 DNSSEC 전환 시 참고합니다.
이번 개정: 도메인 등록과 DNS 호스팅을 구분하고, 메일 레코드 보존·Pages 연결·장애 분리 절차를 추가했습니다. 업데이트 기록