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