2dayapp.com을 GitHub Pages에 붙일 때 저장소 안에 남는 설정과 서비스 화면에서만 확인할 수 있는 설정이 갈렸습니다. DNS 레코드를 바꾸는 작업은 저장소에 남지 않으므로, 먼저 빌드와 배포 대상부터 확인한 뒤 Cloudflare와 GitHub Pages 쪽으로 범위를 넓히는 순서가 필요합니다.
이 저장소에서 확인한 사실은 세 가지입니다.
astro.config.mjs의site가https://2dayapp.com으로 설정되어 있습니다.- 배포 결과 루트의
public/CNAME에2dayapp.com이 들어 있습니다. - GitHub Actions가
dist를gh-pages브랜치에 복사하면서 같은CNAME파일을 다시 만듭니다.
이 파일들만으로 DNS 전파나 HTTPS 인증서 상태까지 알 수는 없습니다. 아래 명령은 실제 도메인인 2dayapp.com을 기준으로 적었고, <username>만 GitHub 계정 또는 조직 이름으로 바꾸면 됩니다.
이 저장소에서 먼저 확인한 것
2dayapp.com 같은 루트 도메인은 저장소의 Pages 설정에 등록한 뒤 GitHub Pages가 안내하는 네 개의 A 레코드로 연결할 수 있습니다.
185.199.108.153
185.199.109.153
185.199.110.153
185.199.111.153GitHub는 IPv6용 AAAA 레코드도 제공합니다. 다만 IPv6만 쓰지 말고 A 레코드도 함께 유지하도록 권장합니다.
www.2dayapp.com에는 GitHub Pages의 기본 도메인을 가리키는 CNAME을 둡니다.
www CNAME <username>.github.io<username>.github.io/my-repo처럼 저장소 경로까지 넣으면 안 됩니다. CNAME 대상은 사용자 또는 조직의 Pages 도메인까지만 적습니다.
설정 순서가 중요하다
안전한 순서는 다음과 같습니다.
- GitHub에서 사이트 저장소를 엽니다.
- Settings → Pages로 이동합니다.
- Custom domain에 최종 도메인을 등록합니다.
- 배포 방식에 따라
CNAME파일이 필요한지 확인합니다. - Cloudflare에 DNS 레코드를 추가합니다.
- DNS 전파를 기다립니다.
- GitHub에서 사용할 수 있게 되면 Enforce HTTPS를 켭니다.
GitHub 공식 문서는 DNS 제공자에서 레코드를 만들기 전에 Pages 설정에 커스텀 도메인을 추가하도록 안내합니다. GitHub Pages에 도메인을 등록하지 않은 채 DNS만 먼저 연결하면 하위 도메인 탈취 위험이 생길 수 있기 때문입니다.
브랜치에서 배포하면 Pages 설정에 도메인을 저장할 때 CNAME 파일이 만들어질 수 있습니다. 커스텀 GitHub Actions 워크플로로 배포한다면 이 파일이 필수는 아닙니다. 먼저 배포 방식을 확인하고 필요한 경우에만 파일을 둡니다.
Cloudflare DNS 레코드
루트 도메인은 다음처럼 구성할 수 있습니다.
| 유형 | 이름 | 대상 | 프록시 상태 |
|---|---|---|---|
| A | @ | 185.199.108.153 | 프록시 또는 DNS 전용 |
| A | @ | 185.199.109.153 | 프록시 또는 DNS 전용 |
| A | @ | 185.199.110.153 | 프록시 또는 DNS 전용 |
| A | @ | 185.199.111.153 | 프록시 또는 DNS 전용 |
www는 다음과 같습니다.
| 유형 | 이름 | 대상 | 프록시 상태 |
|---|---|---|---|
| CNAME | www | <username>.github.io |
프록시 또는 DNS 전용 |
Google Search Console이나 Bing의 소유권 확인용 TXT 레코드는 웹 요청을 전달하지 않습니다.
| 유형 | 이름 | 값 | 프록시 상태 |
|---|---|---|---|
| TXT | @ | google-site-verification=... |
DNS 전용 |
| TXT | @ | msvalidate.01=... |
DNS 전용 |
Cloudflare에서는 A, AAAA, CNAME 같은 웹 트래픽용 레코드만 프록시할 수 있습니다. TXT 레코드는 DNS 전용으로 유지됩니다.
Cloudflare 프록시는 켜야 할까
프록시를 켜면 HTTP와 HTTPS 요청이 Cloudflare를 통과합니다. 캐시, WAF 규칙, 리다이렉트와 Cloudflare 분석 기능을 쓸 수 있습니다.
다만 처음부터 반드시 켤 필요는 없습니다.
- GitHub Pages가 도메인을 검증하는 중이라면 DNS 전용으로 두는 편이 실제 대상을 확인하기 쉽습니다.
- TXT 같은 소유권 확인 레코드는 프록시 대상이 아닙니다.
정적 블로그라면 먼저 DNS 전용 상태에서 GitHub Pages 검증과 HTTPS가 정상인지 확인합니다. Cloudflare 캐시나 WAF가 필요해진 뒤 A와 CNAME 레코드의 프록시를 켜도 늦지 않습니다.
터미널에서 DNS 확인하기
루트 도메인의 A 레코드를 확인합니다.
dig 2dayapp.com +noall +answer -t ADNS 전용 상태라면 다음과 같은 결과가 나와야 합니다.
2dayapp.com. 300 IN A 185.199.108.153
2dayapp.com. 300 IN A 185.199.109.153
2dayapp.com. 300 IN A 185.199.110.153
2dayapp.com. 300 IN A 185.199.111.153www도 확인합니다.
dig www.2dayapp.com +noall +answerwww.2dayapp.com. 300 IN CNAME <username>.github.io.Cloudflare 프록시가 켜져 있으면 GitHub IP 대신 Cloudflare anycast IP가 보일 수 있습니다. 프록시를 사용한다면 정상적인 결과입니다. 원본 DNS 대상을 확인해야 할 때만 잠시 DNS 전용으로 전환합니다.
흔한 오류
도메인과 대체 도메인이 잘못 구성됐다는 경고
GitHub Pages가 루트 도메인과 www가 올바른 Pages 주소를 가리키는지 확인하지 못할 때 나타날 수 있습니다. 한쪽만 보지 말고 둘을 같이 확인합니다.
[ ] GitHub Pages의 Custom domain이 최종 도메인인가
[ ] 루트 도메인에 네 개의 A 레코드 또는 ALIAS/ANAME이 있는가
[ ] www가 <username>.github.io를 가리키는가
[ ] 오래된 A, AAAA, CNAME 또는 wildcard 레코드가 충돌하지 않는가
[ ] DNS 변경 후 충분히 기다렸는가GitHub는 DNS 변경 전파에 최대 24시간이 걸릴 수 있다고 안내합니다. 와일드카드 DNS는 하위 도메인 탈취 위험도 있으므로 편의를 위해 추가하지 않는 편이 안전합니다.
Search Console에서 사이트맵을 가져오지 못한다
먼저 파일 자체를 확인합니다.
curl -I https://2dayapp.com/sitemap-index.xml
curl -Ls https://2dayapp.com/sitemap-index.xml응답이 200이고 XML 내용이 정상이라면 DNS나 HTTPS를 바꾼 직후 Search Console에 일시적인 오류가 남아 있을 수 있습니다. 사이트맵 인덱스가 계속 실패할 때만 하위 사이트맵도 확인합니다.
https://2dayapp.com/sitemap-0.xml/repo-name으로 리다이렉트된다
정적 사이트가 예전 GitHub Pages 프로젝트 경로를 base로 둔 채 빌드됐을 가능성이 큽니다. Astro에서 커스텀 도메인을 쓴다면 운영 설정의 site는 최종 도메인이고, 저장소 이름을 위한 base는 남아 있지 않아야 합니다.
export default defineConfig({
site: "https://2dayapp.com",
});https://username.github.io/repo-name으로 배포할 때는 base가 필요할 수 있습니다. https://2dayapp.com을 쓰는 시점에는 보통 제거하는 것이 맞습니다.
저장소에 고정한 설정
GitHub Pages와 Cloudflare를 함께 쓰는 정적 블로그라면 다음 구성이 단순합니다.
- 루트 도메인을 canonical로 사용
www는 루트 도메인으로 리다이렉트- 루트 도메인은 GitHub Pages A 레코드 사용
www는<username>.github.ioCNAME 사용- Search Console과 Bing 확인용 TXT는 DNS 전용으로 유지
- 사이트맵은
/sitemap-index.xml에 제공 - 정적 사이트 설정에서 저장소용
base경로 제거
이 구조는 글 URL을 커스텀 도메인 아래에 고정합니다. 나중에 호스팅을 옮겨도 글 주소를 유지하기 쉽고, 검색 데이터도 하나의 도메인에 쌓입니다.
이 기록만으로 확인할 수 없는 것
저장소 파일은 Pages가 어느 도메인을 목표로 빌드하고, 배포 산출물에 어떤 CNAME을 넣는지는 보여줍니다. 다음 항목은 DNS 제공자와 GitHub 화면에서 직접 확인해야 합니다.
- 네임서버가 Cloudflare를 실제로 사용 중인지
- 네 개의 GitHub Pages
A레코드가 응답하는지 wwwCNAME과 루트 도메인이 같은 운영 주소로 연결되는지- GitHub Pages의 HTTPS 인증서 발급이 끝났는지
그래서 이 글의 명령 예시는 “실행하면 반드시 이 결과가 나온다”는 보장이 아닙니다. dig 출력과 GitHub 경고를 함께 보고, 프록시를 잠시 DNS 전용으로 바꿀 수 있는 상황에서만 원인을 좁혀야 합니다.