サポートされているカスタムドメイン
ヒント: カスタム ドメインをリポジトリに追加する前に検証し、セキュリティを向上させ、乗っ取り攻撃を回避することをお勧めします。 詳しくは、「GitHub Pagesのカスタムドメインの検証」を参照してください。
GitHub Pages では、サブドメインとApexドメインの 2 種類のドメインを使用できます。 サポートされていないカスタム ドメインの一覧については、「カスタムドメインとGitHub Pages のトラブルシューティング」を参照してください。
サポートされているカスタムドメインの種類 | 例 |
---|---|
www サブドメイン | www.example.com |
カスタム サブドメイン | blog.example.com |
Apex ドメイン | example.com |
サイトには、頂点および www
サブドメインのいずれか、あるいは両方の構成を設定できます。 頂点ドメインの詳細については、「GitHub Pages サイトに頂点ドメインを使用する」を参照してください。
頂点ドメインを使用している場合でも、www
サブドメインを使用することをお勧めします。 頂点ドメインで新しいサイトを作成すると、サイトのコンテンツを提供する際に使用するために www
サブドメインのセキュリティ保護が自動的に試みられますが、www
サブドメインを使うための DNS の変更はユーザーが行わなければなりません。 www
サブドメインを設定すれば、関連する頂点ドメインのセキュリティ保護が自動的に試みられます。 詳しくは、「GitHub Pages サイトのカスタムドメインを管理する」を参照してください。
複数のリポジトリで Custom Domain を使用する
ユーザーまたは組織サイトに Custom Domain を設定した場合、既定では、同じアカウントが所有するすべてのプロジェクト サイトで同じ Custom Domain が使用されます。 サイトの種類について詳しくは、「GitHub Pages について」をご覧ください。
たとえば、サイトのカスタム ドメインが www.octocat.com
で、octo-project
というリポジトリから公開されているプロジェクト サイトにカスタム ドメインをまだ設定していない場合、そのリポジトリの GitHub Pages サイトは、www.octocat.com/octo-project
で公開されます。
Custom Domain を個々のリポジトリに追加することで、デフォルトの Custom Domain をオーバーライドできます。
メモ: プライベートに公開されたプロジェクト サイトの URL は、ユーザーまたは組織サイトのカスタム ドメインの影響を受けません。 プライベートに公開されたサイトについて詳しくは、GitHub Enterprise Cloud ドキュメントの「GitHub Pages サイトの可視性を変更する」をご覧ください。
デフォルトの Custom Domain を削除するにはメインユーザーまたは組織サイトから Custom Domain を削除する必要があります。
あなたの GitHub Pages サイトにサブドメインを使用する
サブドメインは、URL のうちルートドメインの前の部分です。 サブドメインは www
として、またはサイトの個別のセクションとして blog.example.com
のように構成できます。
サブドメインは、DNS プロバイダーを通じて CNAME
レコードで設定されます。 詳しくは、「GitHub Pages サイトのカスタムドメインを管理する」を参照してください。
www
サブドメイン
サブドメインの種類として最もよく使われているのは、www
サブドメインです。 たとえば、www.example.com
には www
サブドメインが含まれています。
www
サブドメインは、最も安定している種類のカスタム ドメインです。GitHub のサーバーの IP アドレスが変更されても、www
サブドメインは影響を受けないからです。
カスタム サブドメイン
カスタム サブドメインは、標準の www
形式を使わない種類のサブドメインです。 カスタムサブドメインは、サイトに 2 つの独自セクションを作成したい場合に最もよく使われます。 たとえば、blog.example.com
というサイトを作成し、www.example.com
から個別にそのセクションをカスタマイズできます。
あなたの GitHub Pages サイトに Apex ドメインを使用する
頂点ドメインは、example.com
のようにサブドメインを含まないカスタム ドメインです。 Apex ドメインは、ベースドメイン、ベアドメイン、裸ドメイン、ルート Apex ドメイン、ゾーン Apex ドメインなどとも呼ばれます。
頂点ドメインは、DNS プロバイダーを通じて、A
、ALIAS
、または ANAME
のレコードを使用して設定されます。 詳しくは、「GitHub Pages サイトのカスタムドメインを管理する」を参照してください。
カスタム ドメインとして Apex ドメインを使用している場合は、www
サブドメインも設定することをお勧めします。 DNSプロバイダを通じて各ドメインの種類のための正しいレコードを設定しているなら、GitHub Pagesは自動的にドメイン間のリダイレクトを生成します。 たとえば、www.example.com
をご自分のサイトのカスタム ドメインとして構成し、GitHub Pages DNS レコードを Apex と www
のドメインに設定している場合、example.com
は www.example.com
にリダイレクトされます。 自動リダイレクトは www
サブドメインにのみ適用されることに注意してください。 自動リダイレクトは、blog
などのその他のサブドメインには適用されません。 詳細については、「GitHub Pages サイトのカスタムドメインを管理する」を参照してください。
GitHub Pagesサイトのためのカスタムドメインの保護
GitHub Pages サイトが無効になっているが、カスタム ドメインが設定されている場合、ドメインの乗っ取りのリスクがあります。 サイトが無効な間に、DNS プロバイダでカスタムドメインを設定していると、サブドメインのいずれかで誰かにサイトをホストされてしまう恐れがあります。
カスタム ドメインを確認すると、他の GitHub ユーザーが自分のリポジトリでそのドメインを使用できなくなります。 ドメインが確認されておらず、GitHub Pages サイトが無効になっている場合は、DNS プロバイダーで DNS レコードを直ちに更新または削除する必要があります。 詳細については、「GitHub Pagesのカスタムドメインの検証」と「GitHub Pages サイトのカスタムドメインを管理する」を参照してください。
サイトが自動的に無効化される理由は、いくつかあります。
- GitHub Pro から GitHub Free へダウングレードすると、アカウント内のプライベートリポジトリから公開されている GitHub Pages のサイトは公開されなくなります。 詳しくは、「アカウントのプランをダウングレードする」を参照してください。
- GitHub Free を利用している個人アカウントへプライベートリポジトリを移譲した場合、そのリポジトリからは GitHub Pages の機能を利用できなくなり、公開されている GitHub Pages は公開されなくなります。 詳しくは、「リポジトリを移譲する」を参照してください。