カスタムドメインとGitHub Pages のトラブルシューティング

GitHub Pages サイトのカスタムドメインまたは HTTPS について、よくあるエラーを確認して Issue を解決することができます。

この機能を使用できるユーザーについて

GitHub Pagesは、パブリック・リポジトリのGitHub Freeと組織用のGitHub Free、パブリック・リポジトリとプライベート・リポジトリのGitHub Pro、GitHub Team、GitHub Enterprise Cloud、GitHub Enterprise Serverで利用できます。 詳しくは、「GitHub のプラン」をご覧ください。

GitHub Pages で、Jekyll ビルドの実行に GitHub Actions が使用されるようになりました。 ビルドのソースとしてブランチを使用する際、組み込みの Jekyll ワークフローを使用する場合は、リポジトリで GitHub Actions を有効にする必要があります。 GitHub Actions が使用できない場合、または無効になっている場合は、ソース ブランチのルートに .nojekyll ファイルを追加すると、Jekyll ビルド プロセスがバイパスされ、コンテンツが直接デプロイされます。 GitHub Actions の有効化の詳細については、「リポジトリの GitHub Actions の設定を管理する」を参照してください。

この記事の内容

CNAME エラー

カスタム GitHub Actions ワークフローから公開する場合、CNAME ファイルは無視され、必要ありません。

ブランチから公開している場合、カスタム ドメインは公開元のルートにある CNAME ファイルに格納されます。 このファイルは、リポジトリ設定を通じて、あるいは手動で追加または更新することができます。 詳しくは、「GitHub Pages サイトのカスタムドメインを管理する」をご覧ください。

サイトが正しいドメインでレンダリングされるようにするには、CNAME ファイルがまだリポジトリに存在していることを確認します。 たとえば、多くの静的サイト ジェネレーターがリポジトリへのプッシュを強制する場合、カスタム ドメインの構成時にリポジトリに追加された CNAME ファイルが上書きされる可能性があります。 ローカルでサイトをビルドし、生成されたファイルを GitHub Enterprise Cloud にプッシュする場合は、最初に CNAME ファイルをローカル リポジトリに追加したコミットをプルして、そのファイルがビルドに含まれるようにしてください。

その後、CNAME ファイルが正しく書式設定されていることを確認します。

  • CNAME ファイル名はすべて大文字である必要があります。
  • CNAME ファイルにはドメインを 1 つだけ含めることができます。 複数のドメインをサイトにポイントするには、DNSプロバイダ経由のリダイレクトを設定する必要があります。
  • CNAME ファイルにはドメイン名のみを含める必要があります。 たとえば、「www.example.com」、「blog.example.com」、「example.com」のように指定します。
  • ドメイン名は、すべての GitHub Pages サイトで一意である必要があります。 たとえば、別のリポジトリの CNAME ファイルに example.com が含まれている場合、自分のリポジトリの example.comCNAMEファイルでは を使用することはできません。

DNS の設定ミス

サイトのデフォルトドメインをカスタムドメインを指すようにすることに問題がある場合は、DNS プロバイダに連絡してください。

カスタムドメインのDNSレコードが正しく設定されているかをテストするには、以下の方法のいずれかを使うこともできます。

サポートされていないカスタムドメイン名

カスタムドメインがサポートされていない場合、使用しているドメインをサポートされているドメインに変更しなければならないかもしれません。 DNSプロバイダに問い合わせて、ドメイン名の転送サービスを提供しているかどうかを確認することもできます。

サイトが以下に当てはまっていないを確認してください。

  • 複数の Apex ドメインを使用している。 たとえば、example.com と anotherexample.com の両方です。

  • 複数の www サブドメインを使用している。 たとえば、www.example.com と www.anotherexample.com の両方です。

  • Apex ドメインとカスタムサブドメインの両方を使用している。 たとえば、example.com と docs.example.com の両方です。

    1 つの例外として、www サブドメインがあります。 正しく構成されていれば、www サブドメインは自動的に apex ドメインにリダイレクトされます。 詳しくは、「GitHub Pages サイトのカスタムドメインを管理する」をご覧ください。

Warning

ワイルドカード DNS レコード (*.example.com など) は使わないことを強くお勧めします。 このようなレコードを使うと、ドメイン乗っ取りのリスクが直ちに発生します (ドメインの検証を行ったとしても)。 たとえば、example.com を検証すれば a.example.com を使うことはできなくなりますが、依然として (ワイルドカード DNS レコードの対象範囲である) b.a.example.com を乗っ取ることができます。 詳しくは、「GitHub Pagesのカスタムドメインの検証」を参照してください。

サポートされているカスタム ドメインの一覧については、「カスタムドメインとGitHub Pagesについて」を参照してください。

HTTPS エラー

CNAME、ALIAS、ANAME、または A DNS レコードで適切に構成されたカスタム ドメインを使用している GitHub Pages サイトには、HTTPS 経由でアクセスできます。 詳しくは、「HTTPS で GitHub Pages サイトを保護する」をご覧ください。

カスタムドメインを設定した後、サイトが HTTPS 経由で利用可能になるには最長 1 時間かかります。 既存の DNS 設定をアップデートした後、HTTPS を有効化するプロセスを開始するには、カスタムドメインを削除してサイトのリポジトリに再追加しなければならない可能性があります。 詳しくは、「GitHub Pages サイトのカスタムドメインを管理する」をご覧ください。

Certification Authority Authorization (CAA) レコードを使用している場合、HTTPS 経由でサイトにアクセスするには、値が letsencrypt.org の CAA レコードが少なくとも 1 つ存在している必要があります。 詳細については、Let's Encrypt ドキュメントの「Certificate Authority Authorization (CAA)」を参照してください。

Linux での URL フォーマット

サイトのURLに、先頭か最後がダッシュのユーザ名もしくは組織名が含まれていたり、連続するダッシュが含まれていたりすると、Linux でブラウズするユーザがそのサイトにアクセスしようとするとサーバーエラーを受け取ることになります。 これを修正するには、GitHub Enterprise Cloudのユーザ名から非英数字を取り除くよう変更してください。 詳しくは、「GitHub ユーザ名の変更」をご覧ください。

ブラウザのキャッシュ

最近カスタムドメインを変更または削除し、ブラウザで新しい URL にアクセスできない場合は、ブラウザのキャッシュを削除してから新しい URL にアクセスすることが必要になる場合があります。 キャッシュの削除についての詳しい情報については、ブラウザのドキュメントを参照してください。

ドメイン名の取得

カスタムドメインを使おうとして、そのドメインが既に使われていると表示された場合は、まずそのドメインを検証することで、自分のドメインとして使えるようにすることができます。 詳しくは、「GitHub Pagesのカスタムドメインの検証」をご覧ください。