2025年11月19日·1 分
DNS と SSL の問題のためのカスタムドメイントラブルシューティングチェックリスト
このカスタムドメイントラブルシューティングチェックリストを使って、DNS レコードの問題、伝播遅延、SSL 発行のタイミングを診断し、簡単な検証手順で確認できます。
このカスタムドメイントラブルシューティングチェックリストを使って、DNS レコードの問題、伝播遅延、SSL 発行のタイミングを診断し、簡単な検証手順で確認できます。
「カスタムドメインが動かない」はいくつかの異なる障害をまとめた表現です。ブラウザには症状が出ますが、原因は別にあります。何かを変更する前に、実際に何が見えているかを言葉にしてください。
典型的な症状には:
大抵の場合、問題は一つです:
トラブルシュートする前に、DNS レコードを編集する場所（レジストラや DNS プロバイダ）と、ホスティング側でドメインを接続する場所の両方にアクセスできることを確認してください。例えば Koder.ai にデプロイしたアプリをカスタムドメインに接続するなら、ドメインの DNS にアクセスでき、かつアプリ側のドメイン設定にもアクセスできる必要があります。
即時に直るもの（タイプミスの修正など）もありますが、時間がかかるものもあります。DNS の変更は反映に時間がかかることがあり、SSL は通常 DNS が正しく向いてドメインに到達できるようになるまで完了しません。目的は推測を止め、各レイヤーを順に確認することです。
多くのドメイン問題は、(1) テストしているホスト名、(2) DNS を管理している場所、(3) 実際にそのレコードが指している先、の不一致に帰着します。これらが揃うと、SSL は通常最後のステップになります。
ドメインにはよく使われる形が二つあります：ルートドメイン（example.com、apex とも呼ばれる）とサブドメイン（www.example.com、app.example.com）。関連はありますが別々の DNS レコードを持てます。したがって www が動くのに apex が失敗する、またはその逆は普通のことです。
ネームサーバーはどこが DNS を管理しているかを決めます。ドメインをある会社で買ったがネームサーバーが別の会社を指している場合、ネームサーバーが指す場所で DNS を編集しなければなりません。「更新したのに何も変わらない」という多くのケースは、間違ったダッシュボードでレコードを編集してしまったために起きます。
主なレコードタイプの役割は次のとおりです：
TTL は「どれくらいの間キャッシュするか」のタイマーです。TTL が低いほどキャッシュの更新が速く、高いほど修正後に反映されるまで長く待つ必要があります。古い値がしばらく見えるのは普通です。
カスタムドメインが失敗したとき、通常は次の四つのどれかに分類できます：DNS が解決しない、DNS が間違った場所を指している、SSL が準備できていない、あるいは一部の人だけに失敗する（キャッシュのため）。
この意思決定ツリーを使ってください：
www が動いて root が動かない（またはその逆）なら、片方だけを設定したか、競合するリダイレクトルールがある可能性が高いです。失敗している正確なホスト名（apex か www か）と正確なエラーメッセージを書き留めると早く進みます。ドメインと証明書を自動化するホスティングプラットフォームでは、「ホストが見つからない」と「証明書保留中」の違いが、DNS を修正すべきか単に DNS が反映されて SSL を待つべきかを教えてくれます。
多くのドメイン失敗は単純な不一致から始まります：あるホスト名の DNS を設定したつもりが、別のホスト名をテストしている、というミスです。
まず、公開したい正確なホスト名を書き出してください。ルートドメインは example.com のように見えます。サブドメインは www.example.com や app.example.com のように見えます。これらは別個の DNS エントリなので、www が動くからといって apex が動くとは限りません。
次に、ホスティングプラットフォームが期待するターゲットを確認します。プラットフォームによっては IP アドレス（A または AAAA 用）を示すものもあれば、ターゲットのホスト名（CNAME 用）を示すものもあります。ホストがドメイン設定画面に出す値を信頼できる「正解」と考えてください。
何かを変える前に現在の設定を記録してください。簡潔に：
また、正しい DNS ゾーンを編集しているかも確認してください。間違ったドメイン、間違った環境、間違ったプロバイダアカウントを更新してしまうのは簡単です。
多くの問題は、接続しようとしているホスト名に対して不適切なレコードタイプを使っているだけです。まずはルートドメイン（example.com）とサブドメイン（www.example.com）の二つのケースを分けて考えてください。DNS プロバイダによって振る舞いが異なることが多いです。
A レコードは名前を IPv4 アドレスに向けます。多くのセットアップでは、apex に対して A レコードを使います（いくつかのプロバイダは apex に CNAME を許可しないため）。ホストが IP を与えているなら A が通常正解です。
AAAA レコードは IPv6 用です。古い方向を指す AAAA が残っていると、訪問者の一部が IPv6 を使い古い先に行き、他は IPv4 で正しい先に行くため、挙動が矛盾することがあります。ホストが IPv6 ターゲットを出していないなら、誤った AAAA を削除すると不整合が解消することが多いです。
CNAME はサブドメインを別のホスト名に向けます（多くの場合 www に使われます）。ホストが名前で終点を指定する場合に便利です。
TXT レコードは検証やチャレンジ（SSL の一部）に使われます。よくある間違いは、TXT を間違った名前（ルートと _acme-challenge や別のサブドメインを取り違える）、余分なスペースを入れる、値を間違えて貼り付ける、などです。
次に、競合がないか確認してください。最もトラブルを起こすのは以下のような状況です：
www や apex に古いレコードが残っている多くの「カスタムドメインが動かない」ケースはレコード値の問題ではありません。レコードを間違ったプロバイダに追加しているために起きます。もしドメインが Provider A のネームサーバーを使っているのに Provider B のダッシュボードで変更しても、公開される内容は変わりません。
ドメインが実際にどのネームサーバーを使っているかを確認してください。通常はレジストラのドメイン設定の「Nameservers」で見られます。別の確認方法として、コンピュータから直接 DNS に聞くこともできます：
dig NS example.com
そのコマンドが返すネームサーバーが権威あるネームサーバーです。
簡単なチェックリスト：
ns1... や ns2... のようなネームサーバーを提供しているなら、その正確な値がレジストラに登録されている必要があります。間違ったプロバイダで更新すると、二つの不一致なダッシュボードが存在することがよくあります。公開上は権威あるネームサーバーだけが効くので、そちらを編集していないと何も変わりません。
また、レジストラでネームサーバーを変えた直後は伝播による遅延が発生します。切り替え中はテストする場所によって結果が不安定に見えるので、ネームサーバーセットが安定するまでレコード編集を一時停止してください。
「伝播」は単一のスイッチではありません。ISP、携帯回線、パブリックリゾルバ、自分のデバイスといった一連の DNS キャッシュがそれぞれ別々の速度で更新されます。だから同僚のところでは動くが自分では動かない、ということが起きます。
TTL（time to live）はキャッシュが回答を保持する時間を示します。古い TTL が 1 時間なら、修正後もしばらくは古い値を見る人がいるのは普通です。TTL を下げるのは変更前に行っておくと役に立ちます。
キャッシュ遅延と設定ミスを切り分けるために、いくつかの簡単なチェックを行ってください：
www）を再確認するもしどこでチェックしてもレコードが間違っている（間違った IP、www がない、古い CNAME）なら修正してください。多くの場所で正しいが一部のネットワークだけ古い値を返すなら、通常はキャッシュ遅延です。
SSL 証明書が失敗する基本的な理由は一つです：証明書発行者がドメインを検証できない、つまり DNS が正しく一貫して正しい場所を指すまで検証できない、という点です。
一般的な手順はシンプルです：
見落としやすいブロッカーは簡単です。誤った A や CNAME ターゲットは検証チェックを間違ったサーバーに送ります。古い AAAA が残っていると一部の訪問者は HTTPS で失敗し、他は成功することがあります。必要な TXT が欠けているとプラットフォームは証明書を発行できません。
症状で「発行中」と「設定ミス」を分けられます：
待っている間にレコードを頻繁に切り替えないでください。変更するたびに時計がリセットされ、異なるネットワークで異なる結果が出る「分裂世界」が生まれます。正しいレコードを一度設定したら、DNS の安定と検証を繰り返し確認してから証明書の発行を待ちましょう。
Koder.ai のようなプラットフォームを使っている場合も流れは同じです：DNS が期待するターゲットを指していることを確認し、不要な AAAA を削除し、DNS が安定してから SSL に時間を与えてください。
良いトラブルシュートは比較が大半です：見えているものと期待するものを比べる。単に「スマホでは開く」と頼るのではなく、再現可能なチェックを使ってください。
nslookup や dig のような DNS 検索ツールで返ってくる値が意図したもの（A/AAAA なら IP、CNAME ならホスト名、TXT ならトークン）と一致するか確認してください。
# Apex (root) domain
dig example.com A
dig example.com AAAA
# www subdomain
dig www.example.com CNAME
# TXT (often used for verification)
dig example.com TXT
apex（example.com）と www（www.example.com）の両方を確認してください。一方が正しく他方が古い先を指すのはよくあることです。
apex と www の両方を http:// と https:// で開いて、どちらが正しいホームでどちらがリダイレクトされるべきかを確認します。
ネットワークによって結果が異なるなら、キャッシュや伝播の影響です。小さなログ（何をいつ変更したか、どこで何を観察したか）を付けておくと原因特定が速くなります。
多くの DNS と SSL の問題は謎ではありません。小さなミスの連続で、間違ったものを調べ続けたり、頻繁に変更して状況を混乱させたりしてしまいます。
最も多い時間の無駄は、二箇所で DNS を編集してしまうことです。これはネームサーバーを切り替えた後によく起きます：レジストラ側でレコードを更新しても DNS が別の場所でホストされていると公開には反映されません。見た目は正しいが実際は効かない、という状況になります。
もう一つの古典的なミスは、apex に CNAME を置こうとして DNS プロバイダがそれをサポートしていない場合です。その場合は A レコード、あるいはプロバイダが提供する ALIAS / ANAME スタイルのレコードが必要です。
IPv6 も厄介です。古い AAAA が残っていると一部の訪問者は間違ったサーバーへ行きます。
「念のため」に残した複数の A レコードも注意が必要です。誤ったターゲットが含まれると意図しない負荷分散のようになり、特にホストされたアプリへ向けると問題になります。
最後のルール：時計をリセットしないでください。
小さく落ち着いた変更のほうが頻繁な微調整よりうまくいきます。
www は動くがルートドメインは動かない新しいアプリを公開して example.com と www.example.com をセットアップしたとします。数分後、www.example.com は正しく読み込まれるがルートドメインは DNS エラーを返す、古いサイトを読み込む、または HTTPS が保留中のままになる、というパターンはよくあります。原因はたいてい小さなものです。
まず地味な問いから始めてください：正しい場所で DNS を編集していますか？ ドメインがある会社で登録されていても DNS は別の会社で管理されていることがあります。ネームサーバーをまず確認し、そのネームサーバーが指すプロバイダの DNS パネルを開いて編集してください。
次に二つのホスト名を比較してください。www は通常 CNAME です。ルートドメインは扱いが難しく、多くのプロバイダは apex に CNAME を許さないので、IP への A レコード、または ALIAS/ANAME タイプのレコードが必要になることがあります。
実務的な決定フロー：
example.com にレコードがない（または別の場所を指している）なら apex のレコードを修正する。最終的に目指す状態は地味で確実です：example.com と www.example.com の両方が同じアプリに繋がり、片方が正規（もう片方はリダイレクト）になり、HTTPS が有効であること。
ドメイン設定が失敗したとき、多くの修正は数分でできるチェックから見つかります。何かを変更する前にこれらを実行してください。
DNS が明らかに正しくなってから SSL を確認してください。多くのプラットフォームはドメインが一貫して期待先を指した後でしか証明書を発行しません。早すぎる確認は正常な遅延を誤ってエラーと見なす原因になります。
Koder.ai にカスタムドメインを追加する場合は、ドメイン設定画面の期待ターゲットを基準に、権威あるプロバイダで DNS を一致させ、伝播の時間を置いてから SSL 状態を再確認してください。
DNS と SSL のミスを繰り返さない最速の方法は、各プロジェクトに短い「ドメインセットアップノート」を残すことです。次回のローンチではそれをコピーすれば手順が再現できます。
プロジェクトのドキュメントに保存し、DNS を触る前に記入してください：
ローンチ中は一人を DNS の責任者にしてください。DNS は二人が同時に「直す」ときに最も壊れます（例：一人がネームサーバーを変えている間に別の人がレコードを編集する、など）。
ホスティング側では安全に戻せる手順を用意してください。プラットフォームがスナップショットやロールバックをサポートしているなら、ルーティングを変更する前にスナップショットを取っておくと素早く既知の正常状態に戻せます。Koder.ai を利用する場合は、Planning Mode でドメイン手順を書き、順に適用し、本番が壊れたらロールバックできます。
DNS が正しいことを確認しても問題が続くなら、証拠を添えてエスカレーションしてください：
エスカレーション時にはホスト名、期待するレコード、現在のリゾルバ結果、タイムスタンプを添えてください。これにより遅いやり取りが素早い修正に変わります。
通常はチェーンのどこか一箇所が間違っています：DNS が解決しない、DNS が間違ったターゲットを指している、サーバー/ホストがあなたのホスト名を認識していない、または HTTPS/SSL の発行がまだ完了していない、などです。まずは出ている正確なエラーと入力した正確なホスト名（apex と www のどちらか）を書き出してください。
example.com（apex）と www.example.com は別々のホスト名で、それぞれ別の DNS レコードを持ちます。www に正しい CNAME があっても、apex に A レコードがない、誤った A レコードがある、または DNS プロバイダが CNAME をサポートしていない、ということがよくあります。
レジストラでドメインのネームサーバーを確認し、それが今編集している DNS プロバイダと一致するかを比べてください。アクティブなネームサーバーに記載されているプロバイダだけが権威ある DNS です。他の場所で編集しても公開される内容は変わりません。
ホストが IPv4 アドレスを渡しているなら A レコード、IPv6 を渡しているなら AAAA、別のホスト名を指定しているなら CNAME、検証用の文字列なら TXT を使います。TXT は正確な名前で作成する必要があり、間違ったサブドメインに置くと失敗します。
古いか間違った AAAA レコードが残っていると、一部の訪問者だけが IPv6 経由で古いサーバーに行き、他は正しい IPv4 に行く、といった「自分では動くのに他では動かない」事象を起こします。ホストが IPv6 を提供していないなら、不要な AAAA を削除することで解決することが多いです。
多くの場合、ホスティング側で片方のホスト名（apex か www のどちらか）しか設定していないか、HTTP/HTTPS のリダイレクトルールが競合しているためです。どちらか一方を正規ドメインに決め、もう一方は一方向のきれいなリダイレクトにしてください。
はい。DNS が複数箇所から一貫して正しいターゲットを返すようになるまで、SSL の発行は完了しないことが多いです。DNS がきちんと安定していれば「待つ」のが正しい対応です。DNS を何度も切り替えると発行がリセットされ続けます。
TTL はリゾルバが回答をキャッシュする時間です。レコードを直しても TTL の間は古い値が残ることがあります。異なるネットワーク（Wi‑Fi とモバイルなど）で確認し、数分ごとに変更を繰り返さないでください。
dig や nslookup などで A / AAAA / CNAME / TXT の回答が期待どおりかを確認し、そのうえで apex と www の両方を http:// と https:// で開いて挙動を確認してください。ネットワークごとに DNS の回答が違うなら伝播やキャッシュを疑い、すべての場所で間違っているなら設定ミスです。
Koder.ai の場合、アプリのドメイン設定画面に記載されている期待ターゲットを参照元とし、権威ある DNS プロバイダでその値と完全に一致するように設定してください。DNS の変更後は SSL を確認する前に伝播の時間を与え、ルーティングを変更する際はスナップショット／ロールバックを使って素早く戻せるようにしましょう。