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

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

この記事の内容

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

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

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 など) を使用しないことを強くお勧めします。 このようなレコードを使うと、ドメイン乗っ取りのリスクが直ちに発生します (ドメインの検証を行ったとしても)。 たとえば、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に、先頭か最後がダッシュのユーザ名もしくは Organization 名が含まれていたり、連続するダッシュが含まれていたりすると、Linux でブラウズするユーザがそのサイトにアクセスしようとするとサーバーエラーを受け取ることになります。 これを修正するには、GitHubのユーザ名から非英数字を取り除くよう変更してください。 詳しくは、「GitHub ユーザ名の変更」を参照してください。

ブラウザのキャッシュ

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