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.com
CNAMEファイルでは を使用することはできません。
DNS の設定ミス
サイトのデフォルトドメインをカスタムドメインを指すようにすることに問題がある場合は、DNS プロバイダに連絡してください。
カスタムドメインのDNSレコードが正しく設定されているかをテストするには、以下の方法のいずれかを使うこともできます。
dig
などの CLI ツール。 詳細については、「GitHub Pages サイトのカスタムドメインを管理する」を参照してください。- オンラインの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に、先頭か最後がダッシュのユーザ名もしくは組織名が含まれていたり、連続するダッシュが含まれていたりすると、Linux でブラウズするユーザがそのサイトにアクセスしようとするとサーバーエラーを受け取ることになります。 これを修正するには、GitHub Enterprise Cloudのユーザ名から非英数字を取り除くよう変更してください。 詳しくは、「GitHub ユーザ名の変更」を参照してください。
ブラウザのキャッシュ
最近カスタムドメインを変更または削除し、ブラウザで新しい URL にアクセスできない場合は、ブラウザのキャッシュを削除してから新しい URL にアクセスすることが必要になる場合があります。 キャッシュの削除についての詳しい情報については、ブラウザのドキュメントを参照してください。
ドメイン名の取得
カスタムドメインを使おうとして、そのドメインが既に使われていると表示された場合は、まずそのドメインを検証することで、自分のドメインとして使えるようにすることができます。 詳しくは、「GitHub Pagesのカスタムドメインの検証」を参照してください。