Skip to main content
ドキュメントへの更新が頻繁に発行されており、このページの翻訳はまだ行われている場合があります。最新情報については、英語版のドキュメントをご覧ください。
 

 

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

この記事では、次の項目が扱われます。

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

GitHub Pagesは、GitHub Free及びOrganizationのGitHub Freeのパブリックリポジトリ、GitHub Pro、GitHub Team、GitHub Enterprise Cloud、GitHub Enterprise Serverのパブリック及びプライベートリポジトリで利用できます。 詳細については、「GitHub's products」を参照してください。

CNAME エラー

カスタムの GitHub Actions ワークフローから発行している場合は、CNAME ファイルは無視されるので、必要ありません。

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

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

警告: ワイルドカード DNS レコード (*.example.com など) を使用しないことを強くお勧めします。 ワイルドカード DNS レコードを使用すると、サブドメインが検証済みでも、そのいずれかで GitHub Pages サイトを誰でもホストできてしまいます。 詳細については、「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に、先頭か最後がダッシュのユーザ名もしくは Organization 名が含まれていたり、連続するダッシュが含まれていたりすると、Linux でブラウズするユーザがそのサイトにアクセスしようとするとサーバーエラーを受け取ることになります。 これを修正するには、GitHubのユーザ名から非英数字を取り除くよう変更してください。 詳細については、「GitHub ユーザー名の変更」を参照してください。

ブラウザのキャッシュ

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