깃허브 페이지(GitHub Pages)에 내 도메인을 연결하는 순서는 세 단계입니다. 도메인 확인(verify)을 먼저 하고, 저장소의 Pages 설정에 도메인을 적은 뒤, 도메인을 산 곳에서 DNS 레코드를 만듭니다.
2026년 10월 23일 GitHub Docs 기준으로 www 없는 주소는 A 레코드 네 개, www가 붙은 주소는 CNAME 레코드 하나를 씁니다. GitHub 공식 문서를 직접 읽고 값과 메뉴 이름을 그대로 옮겼습니다.
깃허브 페이지로 사이트를 처음 올리는 법은 깃허브로 웹사이트 무료 배포하기에 정리했습니다. 이 글은 「사용자이름.github.io」 주소를 내 도메인으로 바꾸는 일에만 집중합니다.

1. 깃허브 페이지 도메인 연결, 무엇부터 하나요?
도메인 확인부터 합니다. GitHub Docs는 도메인을 저장소에 넣기 전에 먼저 확인하라고 권합니다.
사용자 지정 도메인을 리포지토리에 추가하기 전에 확인하는 것이 좋습니다. 이렇게 해야 보안을 개선하고 탈취 공격을 피할 수 있습니다.
여기서 리포지토리(저장소)는 사이트 파일을 담아 두는 깃허브의 폴더입니다. 확인을 해 두지 않으면 저장소를 지우거나 요금제가 내려가 연결이 끊긴 사이, 다른 깃허브 사용자가 내 도메인으로 자기 사이트를 올릴 수 있다고 문서는 적었습니다.
순서도 정해져 있습니다. DNS 쪽 설정보다 저장소에 도메인을 넣는 일이 먼저입니다. 반대로 하면 다른 사람이 내 하위 도메인에 사이트를 올릴 수 있다고 GitHub Docs는 경고합니다.

2. 도메인 확인은 저장소가 아니라 프로필 설정에서
가장 많이 헤매는 곳입니다. 도메인 확인은 저장소 설정이 아니라 내 계정의 프로필 설정에서 합니다. 문서도 옵션이 안 보이면 프로필 설정에 있는지 보라고 적었습니다.
- 깃허브 오른쪽 위 프로필 사진을 누르고
Settings를 엽니다 - 왼쪽 「Code, planning, and automation」 아래
Pages를 누릅니다 - 오른쪽
Add a domain을 누르고 도메인을 적습니다 - 「Add a DNS TXT record」 안내대로 도메인을 산 곳에 TXT 레코드(확인용 글자 기록)를 만듭니다
- 반영되면
Verify를 누릅니다
DNS(도메인 이름을 서버 주소로 바꿔 주는 전화번호부 같은 체계) 변경은 바로 되기도 하고 최대 24시간이 걸리기도 합니다. 확인이 끝난 뒤에도 TXT 레코드는 지우지 말고 그대로 둬야 확인 상태가 유지됩니다.
반영됐는지는 명령어로 볼 수 있습니다. USERNAME은 내 사용자 이름, example.com은 내 도메인으로 바꿉니다.
dig _github-pages-challenge-USERNAME.example.com +nostats +nocomments +nocmd TXT
윈도우에는 dig 명령이 없습니다. GitHub Docs는 대신 PowerShell의 Resolve-DnsName 명령을 쓰거나 BIND를 설치하라고 안내합니다.
3. 저장소 Pages의 Custom domain에 주소 적기
확인이 끝나면 사이트 저장소로 갑니다. 저장소 이름 아래 Settings → 왼쪽 Pages → 「Custom domain」(사용자 지정 도메인) 칸에 도메인을 적고 Save를 누릅니다.
브랜치(저장소 안의 작업 갈래)에서 사이트를 게시하고 있다면, 저장하는 순간 그 브랜치 맨 위 폴더에 CNAME 파일을 넣는 커밋(변경 기록)이 자동으로 만들어집니다.
GitHub Actions 워크플로(자동 배포 설정)로 게시한다면 이 파일은 만들어지지 않고 필요하지도 않습니다. 저장소에 원래 있던 CNAME 파일은 무시됩니다.
4. www 없는 주소는 A 레코드, www 주소는 CNAME
이제 도메인을 산 곳의 DNS 설정 화면으로 갑니다. 어떤 레코드를 만드는지는 주소 모양에 따라 다릅니다. 아래 값은 모두 GitHub Docs의 공식 안내 값입니다.
- www 없는 주소(예: example.com, 문서는 apex 도메인이라 부릅니다): A 레코드(주소를 IP로 잇는 기록) 네 개를
185.199.108.153,185.199.109.153,185.199.110.153,185.199.111.153으로 - www가 붙은 주소(예: www.example.com): CNAME 레코드(다른 이름으로 잇는 기록)를
사용자이름.github.io로

CNAME 값에는 저장소 이름을 붙이지 않습니다. 문서는 CNAME이 저장소 이름 없이 사용자이름.github.io를 바로 가리키게 하라고 적었습니다. 도메인 업체가 기본 레코드를 미리 넣어 뒀다면 먼저 지웁니다.
www 없는 주소를 쓰더라도 www 주소까지 함께 설정해 두면, 깃허브가 둘 사이를 자동으로 이어 줍니다. example.com을 등록했다면 www.example.com으로 들어온 방문자가 example.com으로 넘어갑니다.
IPv6용 AAAA 레코드도 만들 수 있는데, GitHub Docs는 이때 A 레코드도 함께 두라고 권합니다. *.example.com 같은 와일드카드 레코드는 도메인을 확인해도 탈취 위험이 있어 쓰지 말라고 강하게 권합니다.
5. Enforce HTTPS 켜고 인증서 기다리기
HTTPS는 주소창에 자물쇠가 뜨는 보안 연결입니다. 저장소 Settings → Pages에서 Enforce HTTPS(HTTPS 강제)를 고르면 HTTP로 들어온 요청도 HTTPS로 넘어갑니다.
도메인을 연결한 직후에는 이 옵션이 바로 보이지 않을 수 있습니다. GitHub Docs는 이 옵션을 쓸 수 있게 되기까지 최대 24시간이 걸릴 수 있다고 적었습니다.
도메인을 저장하면 깃허브가 DNS를 자동으로 검사하고, 맞으면 Let's Encrypt에 인증서를 요청합니다. 저장하고 몇 분이 지나도 끝나지 않으면 도메인 옆 Remove를 누른 뒤 다시 적고 Save를 누르라고 문서는 안내합니다.
자물쇠가 깨져 보이면 혼합 콘텐츠를 봅니다. 사이트 HTML에 남은 http:// 이미지·CSS·자바스크립트 주소를 https://로 바꾸면 됩니다.
6. 도메인이 안 붙을 때 먼저 볼 것
연결이 안 되면 DNS 값보다 먼저 저장소에 CNAME 파일이 그대로 남아 있는지 확인합니다. 정적 사이트 생성기(사이트 파일을 자동으로 만들어 주는 도구) 가운데 저장소를 통째로 덮어쓰는 것이 많아, 이 파일이 사라질 수 있다고 GitHub Docs는 적었습니다.
CNAME파일 이름은 모두 대문자, 안에는 도메인 하나만 적습니다- 「이미 사용 중」 오류가 나면 다른 저장소에서 그 도메인을 지우거나, 도메인 확인을 먼저 합니다
- 도메인을 바꾼 직후 새 주소가 안 열리면 브라우저 캐시를 지워 봅니다
- CAA 레코드를 쓰고 있다면
letsencrypt.org값의 CAA 레코드가 하나 이상 있어야 HTTPS로 열립니다
DNS가 무엇이고 반영에 왜 시간이 걸리는지는 도메인 연결 방법 총정리와 도메인 연결 시간에, 증상별 점검은 도메인 연결 안됨에 따로 정리했습니다.
7. 깃허브 페이지 도메인 연결 정리
- 프로필
Settings→Pages→Add a domain으로 도메인을 확인합니다(TXT 레코드는 그대로 둡니다) - 저장소
Settings→Pages→ 「Custom domain」에 적고Save를 누릅니다 - www 없는 주소는 A 레코드 네 개, www 주소는 CNAME 레코드를 만듭니다
Enforce HTTPS를 켭니다- 안 되면
CNAME파일과 브라우저 캐시부터 봅니다
배포할 곳을 아직 고르는 중이라면 웹사이트 배포 무료, 어디에 올릴까 총정리를 먼저 보세요. Vercel에 올린 사이트라면 Vercel 도메인 연결, 내 주소 붙이는 법이, 깃허브 페이지 주소가 404로 뜬다면 깃허브 페이지 배포 안됨, 404 해결 순서가 이어집니다.
참고자료 (모두 2026년 10월 23일 확인)
- GitHub Docs 「GitHub Pages 사이트의 사용자 지정 도메인 관리」 — docs.github.com
- GitHub Docs 「GitHub Pages에 대한 사용자 지정 도메인 확인」 — docs.github.com
- GitHub Docs 「HTTPS를 사용하여 GitHub Pages 사이트 보호」 — docs.github.com
- GitHub Docs 「사용자 지정 도메인 및 GitHub 페이지 문제 해결」 — docs.github.com
#깃허브페이지 #GitHubPages #도메인연결 #사용자지정도메인 #웹사이트배포



