GitHub Pages 커스텀 도메인 연결: DNS 레코드 설정 오류와 무한 루프(ERR_TOO_MANY_REDIRECTS) 완벽 해결 가이드
작성자: 장진서 | 카테고리: Web Hosting & DNS 인프라
1. 커스텀 도메인 연결의 기술적 배경과 DNS의 역할
무료 호스팅의 대명사인 GitHub Pages를 활용하여 정적 웹사이트나 블로그를 구축하는 것은 현대 프론트엔드 개발자 및 테크 블로거들의 표준이 되었습니다. 기본적으로 제공되는 username.github.io 도메인 대신, 자신만의 브랜드를 나타내는 커스텀 도메인(예: example.com)을 연결하는 작업은 필수적입니다. 이 과정에서 도메인 구입처(가비아, 호스팅케이알, Cloudflare 등)의 DNS(Domain Name System) 레코드를 수정하여 GitHub의 서버 IP와 내 도메인을 매핑해야 합니다.
이때 가장 중요한 개념이 바로 Apex Domain(루트 도메인, www가 없는 도메인)과 Subdomain(서브도메인, www가 붙은 도메인)의 차이입니다. GitHub Pages는 이 두 가지 형태를 모두 지원하지만, DNS 레코드에서 A 레코드(A Record)와 CNAME 레코드를 규칙에 맞게 혼용하지 않으면 곧바로 치명적인 라우팅 오류가 발생합니다. 특히 구글 애드센스 승인을 준비하는 블로그라면, 도메인 소유권 확인과 크롤러 접근을 위해 단 한 치의 DNS 설정 오류도 허용되어서는 안 됩니다.
2. 리다이렉션 무한 루프(ERR_TOO_MANY_REDIRECTS)의 발생 원인
커스텀 도메인을 연결한 후 사이트에 접속했을 때, 브라우저에 ERR_TOO_MANY_REDIRECTS 에러가 출력되며 페이지가 하얗게 변하는 현상이 있습니다. 이는 브라우저가 A 페이지에서 B 페이지로 이동하라는 지시를 받고 갔더니, B 페이지가 다시 A 페이지로 가라고 지시하여 핑퐁 게임처럼 무한 루프에 빠진 상태입니다. 이 현상의 근본적인 기술적 원인은 다음과 같습니다.
① 강제 HTTPS 설정과 인증서 발급 지연의 충돌
GitHub Pages는 Let's Encrypt를 통해 무료 SSL/TLS 인증서를 자동 발급해 줍니다. DNS 레코드를 변경한 직후, GitHub 서버가 인증서를 발급받기 전에 리포지토리 설정에서 'Enforce HTTPS(HTTPS 강제)' 옵션을 체크해 버리면 이 문제가 발생합니다. HTTP로 접속한 사용자를 HTTPS로 넘기려 하지만, 유효한 인증서가 없어 연결이 거부되고 다시 HTTP로 떨어지는 과정이 무한 반복되는 것입니다.
② 구형 A 레코드 IP 방치 및 충돌
과거 GitHub Pages가 사용하던 레거시 IP(예: 192.30.252.153 등)가 DNS 설정에 남아있거나, 파킹 페이지(도메인 구매처의 기본 안내 페이지)로 향하는 기존 A 레코드를 삭제하지 않은 채 GitHub IP를 추가하면 트래픽 분산에 혼선이 발생합니다. 네임서버는 여러 IP 중 무작위로 응답을 반환하므로 사이트 접속이 극도로 불안정해집니다.
3. 무한 루프를 끊어내는 DNS 설정 완벽 가이드
이 문제를 완전히 해결하고 구글 봇이 쾌적하게 사이트를 긁어갈 수 있도록 인프라를 세팅하는 구체적인 4단계 프로세스입니다. 기존에 설정했던 모든 A 레코드와 CNAME을 삭제하고 아래 상태에서 새로 시작하십시오.
# 1단계: 루트 도메인(Apex Domain)을 위한 4개의 A 레코드 등록
# 호스트 이름(이름)에는 '@' 또는 도메인명 입력
Type: A | Name: @ | Value: 185.199.108.153
Type: A | Name: @ | Value: 185.199.109.153
Type: A | Name: @ | Value: 185.199.110.153
Type: A | Name: @ | Value: 185.199.111.153
# 2단계: www 서브도메인을 위한 CNAME 레코드 등록
# Value에는 본인의 깃허브 페이지 주소를 정확히 입력
Type: CNAME | Name: www | Value: username.github.io
3단계: 레포지토리 최상단에 CNAME 파일 생성
로컬 저장소의 루트 디렉토리(혹은 gh-pages 브랜치)에 확장자 없는 CNAME이라는 이름의 파일을 생성합니다. 파일 내용에는 example.com과 같이 자신이 구매한 도메인명만 딱 한 줄 적어 넣고 커밋(Commit) 및 푸시(Push)를 진행합니다.
4단계: TTL 대기 및 HTTPS 활성화의 타이밍
DNS 레코드 변경 사항이 전 세계 네임서버에 전파되는 시간(TTL, Time To Live)은 최소 15분에서 최대 24시간이 소요됩니다. dig example.com +noall +answer 명령어를 터미널에 입력하여 GitHub의 IP 4개가 정상적으로 반환되는지 확인하십시오. 완벽히 매핑된 것을 확인한 후, GitHub Settings - Pages 메뉴로 이동하여 'Enforce HTTPS'에 체크합니다. 인증서 발급 전 미리 체크하면 루프에 빠지니 반드시 순서를 지켜야 합니다.
이 모든 과정이 정상적으로 완료되면, 브라우저는 www가 있는 주소로 접속하든 없는 주소로 접속하든, HTTP로 접속하든 단일한 HTTPS 커스텀 도메인 주소로 안전하게 라우팅합니다. 이는 구글 검색 엔진 최적화(SEO)에서 '중복 문서' 페널티를 피하는 가장 핵심적인 기술적 세팅입니다.