GitHub Pages 사이트의 사용자 지정 도메인 관리

리포지토리에 대한 관리자 권한이 있는 사용자는 GitHub Pages 사이트 대한 사용자 지정 도메인을 구성할 수 있습니다.

사용자 지정 도메인 구성 정보

팁: 사용자 지정 도메인을 리포지토리에 추가하기 전에 확인하는 것이 좋습니다. 이렇게 해야 보안을 개선하고 탈취 공격을 피할 수 있습니다. 자세한 내용은 "GitHub Pages에 대한 사용자 지정 도메인 확인"을(를) 참조하세요.

DNS 공급자를 사용하여 사용자 지정 도메인을 구성하기 전에 GitHub Pages 사이트에 사용자 지정 도메인을 추가해야 합니다. GitHub Enterprise Cloud에 사용자 지정 도메인을 추가하지 않고 DNS 공급자를 사용하여 사용자 지정 도메인을 구성하면 다른 사용자가 하위 도메인 중 하나에서 사이트를 호스트할 수 있습니다.

dig DNS 레코드의 올바른 구성을 확인하는 데 사용할 수 있는 명령은 Windows에 포함되지 않습니다. DNS 레코드가 올바르게 구성되었는지 확인하려면 PowerShell 명령을 사용하거나 BIND를 Resolve-DnsName 설치할 수 있습니다.

참고: DNS 변경 내용을 적용하는 데 최대 24시간이 걸릴 수 있습니다.

apex 도메인 구성

Apex 도메인을 설정하려면, example.com 리포지토리 설정에서 사용자 지정 도메인을 구성하고 DNS 공급자와 함께 ALIAS, ANAME, 또는 A 레코드 중 하나 이상을 구성해야 합니다.

GitHub Enterprise Cloud에서 사이트의 리포지토리로 이동합니다.
리포지토리 이름 아래에서 Settings(설정)를 클릭합니다. "설정" 탭이 표시되지 않으면 드롭다운 메뉴를 선택한 다음 설정을 클릭합니다.
사이드바의 “코드 및 자동화” 섹션에서 페이지를 클릭합니다.
“사용자 지정 도메인”에서 사용자 지정 도메인을 입력한 다음 저장을 클릭합니다. 분기에서 사이트를 게시하는 경우 원본 분기의 루트에 CNAME 파일을 직접 추가하는 커밋이 만들어집니다. 사용자 지정 GitHub Actions 워크플로를 사용하여 사이트를 게시하는 경우 CNAME 파일이 생성되지 않으므로 수동으로 생성해야 합니다(사용자 지정 도메인이 있는 텍스트 한 줄만 포함). 게시 원본에 대한 자세한 내용은 "GitHub Pages 사이트에 대한 게시 원본 구성"을 참조하세요.
DNS 공급자로 이동하여 ALIAS, ANAME 또는 A 레코드를 만듭니다. IPv6 지원에 대한 AAAA 레코드를 만들 수도 있습니다. IPv6 지원을 구현하는 경우 전 세계적으로 느린 IPv6 채택으로 인해 AAAA 레코드 외에 A 레코드를 사용하는 것이 좋습니다. 올바른 레코드를 만드는 방법에 대한 자세한 내용은 DNS 공급자의 설명서를 참조하세요.
- ALIAS 또는 ANAME 레코드를 만들도록 apex 도메인이 사이트의 기본 도메인을 가리킵니다. 사이트에 대한 기본 도메인에 대한 자세한 내용은 "GitHub Pages 정보"을 참조하세요.
- A 레코드를 만들도록 apex 도메인이 GitHub Pages에 대한 IP 주소를 가리킵니다.
```
185.199.108.153
185.199.109.153
185.199.110.153
185.199.111.153
```
- AAAA 레코드를 만들도록 apex 도메인이 GitHub Pages에 대한 IP 주소를 가리킵니다.
```
2606:50c0:8000::153
2606:50c0:8001::153
2606:50c0:8002::153
2606:50c0:8003::153
```
경고: *.example.com과 같은 와일드카드 DNS 레코드를 사용하지 않는 것이 좋습니다. 이러한 레코드는 도메인을 확인하더라도 즉각적인 도메인 인수 위험에 처하게 됩니다. 예를 들어 example.com을 확인하면 다른 사용자는 a.example.com를 사용할 수 없지만 여전히 b.a.example.com을 인수할 수 있습니다(와일드카드 DNS 레코드가 적용됨). 자세한 내용은 "GitHub Pages에 대한 사용자 지정 도메인 확인"을(를) 참조하세요.
Terminal(터미널)Terminal(터미널)Git Bash를 엽니다.

DNS 레코드가 올바르게 구성되었는지 확인하려면 dig 명령을 사용하여 _WWW.EXAMPLE.COM_을 하위 도메인으로 바꿉니다. 결과가 위 GitHub Pages의 IP 주소와 일치하는지 확인합니다.

A 레코드의 경우:

$ dig EXAMPLE.COM +noall +answer -t A
> EXAMPLE.COM    3600    IN A     185.199.108.153
> EXAMPLE.COM    3600    IN A     185.199.109.153
> EXAMPLE.COM    3600    IN A     185.199.110.153
> EXAMPLE.COM    3600    IN A     185.199.111.153

AAAA 레코드의 경우:

$ dig EXAMPLE.COM +noall +answer -t AAAA
> EXAMPLE.COM     3600    IN AAAA     2606:50c0:8000::153
> EXAMPLE.COM     3600    IN AAAA     2606:50c0:8001::153
> EXAMPLE.COM     3600    IN AAAA     2606:50c0:8002::153
> EXAMPLE.COM     3600    IN AAAA     2606:50c0:8003::153

또한 A 레코드를 검사합니다.

정적 사이트 생성기를 사용하여 사이트를 로컬로 빌드하고 생성된 파일을 GitHub Enterprise Cloud에 푸시하는 경우 로컬 리포지토리에 CNAME 파일을 추가한 커밋을 풀(pull)합니다. 자세한 내용은 "사용자 지정 도메인 및 GitHub Pages 문제 해결"을(를) 참조하세요.
필요에 따라 사이트에 HTTPS 암호화를 적용하려면 HTTPS 적용을 선택합니다. 이 옵션을 사용할 수 있게 되기까지 최대 24시간이 걸릴 수 있습니다. 자세한 내용은 "HTTPS를 사용하여 GitHub Pages 사이트 보호"을(를) 참조하세요.

apex 도메인 및 `www` 하위 도메인 변형 구성

참고: HTTPS 보안 웹 사이트의 경우 apex 도메인과 함께 www 하위 도메인을 설정하는 것이 좋습니다.

apex 도메인을 사용자 지정 도메인으로 사용하는 경우 www 하위 도메인도 설정하는 것이 좋습니다. DNS 공급자를 통해 각 도메인 유형에 대해 올바른 레코드를 구성하는 경우 GitHub Pages는 도메인 간에 리디렉션을 자동으로 만듭니다. 예를 들어 www.example.com을 사이트의 사용자 지정 도메인으로 구성하고 apex 및 www 도메인에 대해 설정된 GitHub Pages DNS 레코드가 있는 경우 example.com은 www.example.com으로 리디렉션됩니다. 자동 리디렉션은 www 하위 도메인에만 적용됩니다. 자동 리디렉션은 다른 하위 도메인(예: blog)에 적용되지 않습니다. 자세한 내용은 “하위 도메인 구성”을 참조하세요.

DNS 공급자로 이동하여 GitHub Pages 기본 도메인을 가리키는 www 하위 도메인에 대한 CNAME 레코드를 만듭니다. 예를 들어 사이트가 <user>.github.io에 있는 경우 www.example.com를 <user>.github.io로 가리키는 CNAME 레코드를 만들어야 합니다. 마찬가지로 <organization>.github.io에 있는 조직 사이트의 경우 www.example.com를 <organization>.github.io로 가리키는 CNAME 레코드를 만들어야 합니다. CNAME 레코드가 리포지토리 이름을 포함하지 않고 <user>.github.io 또는 <organization>.github.io를 직접 가리키도록 합니다.

올바른 레코드를 만드는 방법에 대한 자세한 내용은 DNS 공급자의 설명서를 참조하세요. 사이트에 대한 기본 도메인에 대한 자세한 내용은 "GitHub Pages 정보"을 참조하세요.

하위 도메인 구성

www.example.com 또는 blog.example.com과 같은 www 또는 사용자 지정 하위 도메인을 설정하려면 리포지토리 설정에서 도메인을 추가해야 합니다. 그런 다음 DNS 공급자를 사용하여 CNAME 레코드를 구성합니다.

GitHub Enterprise Cloud에서 사이트의 리포지토리로 이동합니다.
리포지토리 이름 아래에서 Settings(설정)를 클릭합니다. "설정" 탭이 표시되지 않으면 드롭다운 메뉴를 선택한 다음 설정을 클릭합니다.
사이드바의 “코드 및 자동화” 섹션에서 페이지를 클릭합니다.
“사용자 지정 도메인”에서 사용자 지정 도메인을 입력한 다음 저장을 클릭합니다. 분기에서 사이트를 게시하는 경우 원본 분기의 루트에 CNAME 파일을 직접 추가하는 커밋이 만들어집니다. 사용자 지정 GitHub Actions 워크플로를 사용하여 사이트를 게시하는 경우 CNAME 파일이 생성되지 않으므로 수동으로 생성해야 합니다(사용자 지정 도메인이 있는 텍스트 한 줄만 포함). 게시 원본에 대한 자세한 내용은 "GitHub Pages 사이트에 대한 게시 원본 구성"을 참조하세요.

참고: 사용자 지정 도메인이 국제화된 도메인 이름인 경우 Punycode 인코딩 버전을 입력해야 합니다.

Punycode에 대한 자세한 내용은 국제화된 도메인 이름을 참조하세요.
DNS 공급자로 이동하여 하위 도메인을 사이트의 기본 도메인으로 가리키는 CNAME 레코드를 만듭니다. 예를 들어, 사용자 사이트에 하위 도메인 www.example.com을 사용하려는 경우 www.example.com이 <user>.github.io를 가리킨다는 CNAME 레코드를 만듭니다. 조직 사이트에 하위 도메인 another.example.com을 사용하려는 경우 another.example.com이 <organization>.github.io를 가리킨다는 CNAME 레코드를 만듭니다. CNAME 레코드는 리포지토리 이름을 제외하고 항상 <user>.github.io 또는 <organization>.github.io를 가리킵니다. 올바른 레코드를 만드는 방법에 대한 자세한 내용은 DNS 공급자의 설명서를 참조하세요. 사이트에 대한 기본 도메인에 대한 자세한 내용은 "GitHub Pages 정보"을 참조하세요.

경고: *.example.com과 같은 와일드카드 DNS 레코드를 사용하지 않는 것이 좋습니다. 이러한 레코드는 도메인을 확인하더라도 즉각적인 도메인 인수 위험에 처하게 됩니다. 예를 들어 example.com을 확인하면 다른 사용자는 a.example.com를 사용할 수 없지만 여전히 b.a.example.com을 인수할 수 있습니다(와일드카드 DNS 레코드가 적용됨). 자세한 내용은 "GitHub Pages에 대한 사용자 지정 도메인 확인"을(를) 참조하세요.
Terminal(터미널)Terminal(터미널)Git Bash를 엽니다.

DNS 레코드가 올바르게 구성되었는지 확인하려면 dig 명령을 사용하여 WWW.EXAMPLE.COM 하위 도메인으로 바꿉니다.

$ dig WWW.EXAMPLE.COM +nostats +nocomments +nocmd
> ;WWW.EXAMPLE.COM.                    IN      A
> WWW.EXAMPLE.COM.             3592    IN      CNAME   YOUR-USERNAME.github.io.
> YOUR-USERNAME.github.io.      43192   IN      CNAME   GITHUB-PAGES-SERVER .
> GITHUB-PAGES-SERVER .         22      IN      A       192.0.2.1

정적 사이트 생성기를 사용하여 사이트를 로컬로 빌드하고 생성된 파일을 GitHub Enterprise Cloud에 푸시하는 경우 로컬 리포지토리에 CNAME 파일을 추가한 커밋을 풀(pull)합니다. 자세한 내용은 "사용자 지정 도메인 및 GitHub Pages 문제 해결"을(를) 참조하세요.
필요에 따라 사이트에 HTTPS 암호화를 적용하려면 HTTPS 적용을 선택합니다. 이 옵션을 사용할 수 있게 되기까지 최대 24시간이 걸릴 수 있습니다. 자세한 내용은 "HTTPS를 사용하여 GitHub Pages 사이트 보호"을(를) 참조하세요.

참고: 사용자 지정 하위 도메인을 apex 도메인으로 가리키면 웹사이트에 HTTPS를 적용하는 데 문제가 발생할 수 있으며, 하위 도메인이 GitHub Pages 사이트에 전혀 연결되지 않는 문제가 발생할 수 있습니다.

사용자 지정 도메인에 대한 DNS 레코드

GitHub Pages 사이트에 도메인을 구성하는 프로세스가 익숙하다면 아래의 테이블을 사용해 특정 시나리오의 DNS 값과 자신의 DNS 제공업체가 지원하는 DNS 레코드 종류를 찾을 수 있습니다. GitHub Enterprise Cloud의 GitHub Pages 사이트를 구성하는 방법 및 dig 명령을 사용하여 구성을 확인하는 방법을 비롯한 자세한 내용은 위의 섹션을 참조하세요.

apex 도메인을 구성하려면 아래 테이블에서 단일 DNS 레코드 종류만 선택하면 됩니다. apex 도메인 및 www 하위 도메인(예: example.com 및 www.example.com)을 구성하려면 apex 도메인을 구성한 다음 하위 도메인을 구성합니다. 자세한 내용은 "apex 도메인 및 www 하위 도메인 변형 구성"을 참조하세요.

경고: *.example.com과 같은 와일드카드 DNS 레코드를 사용하지 않는 것이 좋습니다. 이러한 레코드는 도메인을 확인하더라도 즉각적인 도메인 인수 위험에 처하게 됩니다. 예를 들어 example.com을 확인하면 다른 사용자는 a.example.com를 사용할 수 없지만 여전히 b.a.example.com을 인수할 수 있습니다(와일드카드 DNS 레코드가 적용됨). 자세한 내용은 "GitHub Pages에 대한 사용자 지정 도메인 확인"을(를) 참조하세요.

시나리오	DNS 레코드 종류	DNS 레코드 이름	DNS 레코드 값
Apex 도메인 （`example.com`）	`A`	`@`	`185.199.108.153` `185.199.109.153` `185.199.110.153` `185.199.111.153`
Apex 도메인 （`example.com`）	`AAAA`	`@`	`2606:50c0:8000::153` `2606:50c0:8001::153` `2606:50c0:8002::153` `2606:50c0:8003::153`
Apex 도메인 （`example.com`）	`ALIAS` 또는 `ANAME`	`@`	`USERNAME.github.io` 또는 `ORGANIZATION.github.io`
하위 도메인 （`www.example.com`、 `blog.example.com`）	`CNAME`	`SUBDOMAIN.example.com.`	`USERNAME.github.io` 또는 `ORGANIZATION.github.io`

사용자 지정 도메인 제거

수행한 사용자 지정 도메인에 대한 오류가 발생하면 다른 리포지토리에서 사용자 지정 도메인을 제거해야 할 수 있습니다.

GitHub Enterprise Cloud에서 사이트의 리포지토리로 이동합니다.
리포지토리 이름 아래에서 Settings(설정)를 클릭합니다. "설정" 탭이 표시되지 않으면 드롭다운 메뉴를 선택한 다음 설정을 클릭합니다.
사이드바의 “코드 및 자동화” 섹션에서 페이지를 클릭합니다.
“사용자 지정 도메인”에서 제거를 클릭합니다.

사용자 지정 도메인 보호

GitHub Pages 사이트가 비활성화되었지만 사용자 지정 도메인이 설정된 경우 도메인이 인수될 위험이 있습니다. 사이트가 비활성화된 동안 DNS 공급자를 사용하여 사용자 지정 도메인을 구성하면 다른 사용자가 하위 도메인 중 하나에서 사이트를 호스팅할 수 있습니다.

사용자 지정 도메인을 확인하면 다른 GitHub 사용자가 해당 리포지토리와 함께 도메인을 사용할 수 없습니다. 도메인이 확인되지 않고 GitHub Pages 사이트가 비활성화된 경우 DNS 공급자를 사용하여 DNS 레코드를 즉시 업데이트하거나 제거해야 합니다. 자세한 내용은 GitHub Pages에 대한 사용자 지정 도메인 확인"을(를) 참조하세요.

추가 참고 자료

"사용자 지정 도메인 및 GitHub Pages 문제 해결"