Webアプリに独自ドメインを設定する方法｜DNS・CNAME・HTTPSを図解

Webアプリは公開できた。次は、サービスから発行されたURLを、自分の app.example.com にしたい。

ここで必要になるのは、ドメインの購入だけではありません。アプリの公開先に「この名前でアクセスを受ける」と登録し、DNSで接続先を示し、その名前で使えるHTTPSの証明書を用意します。

設定画面を行き来すると、この3つが同じ作業に見えがちです。この記事では役割を分けて説明し、KamuiDashを例に、入力する内容と公開後の確認までたどります。すでに既定のURLで動いているアプリと、DNS設定を編集できるドメインがあることを前提にします。

スクリーンショットは操作説明用のデモ画面です。ドメインや検証値はサンプルで、実際のドメイン登録・証明書発行・疎通成功を示すものではありません。画面の表記は2026年11月5日に確認したUIに基づきます。

ドメイン・DNS・HTTPSを分けて考える

https://app.example.com/notes というURLでは、app.example.com がホスト名、/notes がアプリ内のパスです。ドメインを取得すると、その配下の名前を管理できるようになります。どのアプリにつなぐかは、別に設定します。

複数のアプリを同じ公開基盤が受け付ける場合、接続先だけではどのアプリか決まりません。公開先への独自ドメイン登録が、その名前とアプリを結び付けます。Renderにも「公開先への追加 → DNSの設定 → 検証」という手順があります。Render公式：Custom Domains

ドメインの購入先と、DNSの編集先が同じとは限りません。DNSの管理を別サービスに移していれば、変更するのは移した先のDNSレコードです。どこで買ったかに加えて、現在どこでDNSを管理しているかを確認しておきます。

最初は app.example.com を接続する

この記事では、取得済みの example.com の配下にある app.example.com を使います。

example.com 自体はルートドメインとも呼ばれます。ルートに接続する場合は、公開先とDNSサービスの組み合わせによって設定方法が変わります。例えばCloudflareには、ルートでCNAMEの設定を使えるようにするCNAME flatteningがあります。まずサブドメインで流れを理解し、ルートを使うときは双方の案内を確認すると進めやすくなります。Cloudflare公式：CNAME flattening

接続前に、使いたい名前が既存のWebサイトなどに使われていないか確認します。新しい app の設定で、無関係な名前やメール用のレコードまで変更する必要はありません。すでに使っているホスト名を移す場合は、既存設定と戻し方を控えてから切り替えます。

また、ドメインの取得・更新費用と、公開先の独自ドメイン機能の料金は別です。KamuiDashでも独自ドメインは追加の課金対象になるため、設定前に公式ドキュメントと料金ページを確認してください。

1. 公開先にホスト名を登録する

KamuiDashでは、対象アプリの詳細画面から「カスタムドメインを設定」を開きます。入力するのは、使いたいホスト名です。

app.example.com

https:// や /notes は含めません。URL全体ではなく、アプリに接続したい名前を登録します。

登録後はDNS設定の案内を確認します。すでに設定済みなら「カスタムドメインを管理」から確認できます。KamuiDashは1アプリにつき1つの独自ドメインなので、既存ドメインのあるアプリでは、現在の設定を確認してから変更します。KamuiDash公式：カスタムドメイン

2. CNAMEと、画面に表示された検証レコードを設定する

DNS側では、まずホスト名の接続先を設定します。ここで使うCNAMEは「別のホスト名を参照する」レコードです。AレコードはIPv4アドレス、AAAAレコードはIPv6アドレスを指定します。公開先がどの種類を指定するかで、入力する値も変わります。Cloudflare公式：DNS record types

KamuiDashでは、独自ドメイン設定に表示されたCNAMEの接続先を使います。アプリの既定URLを推測して入れず、画面の値をコピーします。

例えば、この画面を example.com のDNSへ入力するなら、対応は次のようになります。表の値は説明用なので、そのまま登録しないでください。

DNSサービスによって、名前欄には app だけを入れるものと、app.example.com を入れるものがあります。保存後のレコード名が app.example.com になっているかを確認してください。末尾のドメインを自動で付ける画面に完全な名前を入れると、二重になる場合があります。

CNAMEの値に https:// やパスは付けません。また、CNAMEはDNS上の別名なので、設定しただけでブラウザのURLを別URLへ転送するものでもありません。Cloudflare公式：CNAMEレコード

TXTは、表示された目的と値を確かめる

証明書を発行するには、そのドメインを管理していることの検証が必要です。方式の一つに、指定されたTXTレコードをDNSへ置く方法があります。DNS以外の検証方法もあるため、どのサービスでもTXTが必須とは限りません。Let's Encrypt公式：Challenge Types

KamuiDashの現行UIでは、SSLの準備中に証明書検証用のTXTが表示される場合があります。SSLが有効になると、その案内が表示されない場合もあります。また、「TXTレコード（所有権確認）」が別に表示されたら、それも対象です。「CNAMEとTXTを1件ずつ」という固定の件数で判断せず、現在の画面に表示されたレコードを確認します。

同じ名前のTXTに複数の値が案内されている場合は、それぞれを独立した値として登録します。文字列を連結して1つにしません。複数の証明書検証レコードが必要になるケースは、CloudflareのTXTによる証明書検証の説明にも記載されています。

CloudflareでDNSを管理している場合も、公開先が指定するプロキシ状態などの条件に従ってください。DNSのみで使う設定と、Cloudflareが通信を中継する設定では挙動が異なります。Cloudflare公式：Proxy status

3. DNSとSSLを確認してから、アプリを開く

DNSレコードを保存しても、すべての問い合わせ先がすぐ同じ答えを返すとは限りません。DNSには応答を一定期間保存する仕組みがあり、その時間にTTLが関係します。「保存した時刻から必ず何分で使える」とは決めず、登録内容と応答を確認します。Cloudflare公式：TTL

KamuiDashの画面で状態を再確認し、「SSL有効」になっているかを見ます。

SSLの表示だけで完了にはせず、ブラウザで https://app.example.com を開き、想定したアプリが表示されることを確認します。トップページに加え、実際に使うページやAPIにもアクセスします。

ログイン機能や外部API連携があるアプリでは、URLが変わる影響も確認します。例えば、認証サービスに登録したコールバックURL、別オリジンへのAPI接続、CookieのDomain設定などです。DNSとHTTPSが正しくても、アプリが以前のURLを前提にしていれば、その機能は別途調整が必要です。

HTTPからHTTPSへの転送も確認対象です。次の例はレスポンスヘッダーを表示するコマンドで、app.example.com は自分の名前に置き換えます。

curl -sS -D - -o /dev/null http://app.example.com/

HTTPSへの転送を期待する場合は、応答のステータスと Location を確認します。HTTPSが利用できることと、HTTPから自動転送されることは別です。挙動は公開先やアプリの設定で確認してください。

開かないときは、DNS・証明書・アプリの順に見る

名前が見つからない・違う場所につながる

DNSを編集したサービスが、現在そのドメインのDNSを管理しているかを確認します。続いて、レコードの名前と値を見ます。名前の二重付加、接続先のコピー間違い、同じ名前に残っている競合レコードなどが確認点です。

ターミナルに dig があれば、次のようにDNSの応答を調べられます。

dig app.example.com CNAME +short
dig app.example.com A +short
dig _acme-challenge.app.example.com TXT +short

TXTの問い合わせ名は、画面に表示されたものに置き換えます。CNAMEの結果に接続先が出る設定もあれば、プロキシやCNAME flatteningによってAレコードとして返る設定もあります。CNAMEの結果が空という理由だけでは、設定失敗と断定できません。 公開先とDNSサービスの方式に合わせて読みます。Cloudflare公式：CNAME flattening

dig が使えない場合も、まずDNS管理画面で保存された名前と値を確認できます。コマンドの導入より先に、入力先と入力内容を確かめてください。

証明書の警告が出る・SSL準備中が続く

登録したホスト名、DNSの接続先、要求された検証レコードを確認します。SSL準備中のままなら、画面に示された検証が完了しているかを見ます。証明書の警告を無視して公開完了とせず、ブラウザに表示されたエラー内容と、公開先の状態を照らし合わせます。

KamuiDashで「要対応」や「確認できません」と表示された場合も、何度もドメインを削除・再登録する前に、現在のレコードとエラーを確認します。待つ必要がある状態と、入力を直す必要がある状態を分けて考えます。

HTTPSで開くが、404・502になる

この段階では、独自ドメインの登録先とアプリの状態を確認します。既定のURLでも同じエラーになるなら、起動状態やアプリ内のルーティングを調べる手掛かりになります。独自ドメインだけで起きる場合は、ホスト名の登録や、アプリ側の許可ホスト設定などを確認します。

ただし、404や502の発生元は公開基盤の場合もアプリの場合もあります。HTTPのエラー応答を受け取れたことだけでDNS以降がすべて正しいと決めず、表示内容やログでどこが返しているかを確認します。

自分のURLで、いつもの操作ができれば完了

独自ドメインの接続は、ホスト名を公開先に登録し、DNSの接続先と必要な検証レコードを設定し、HTTPSとアプリの応答を確かめる作業です。

最後に、入力したホスト名の https:// で目的のアプリが開くこと、必要なページやログインが動くこと、HTTPの扱いが想定どおりであることを確認します。ここまで分けて見ると、開かないときにも「反映待ちだろう」で止まらず、次に確認する場所を選べます。

アプリ自体の公開がまだなら、GitHubにpushしたら自動公開する手順から進められます。公開先を検討している場合は、個人開発のWebアプリの公開先も参考にしてください。

KamuiDashは、GitHubからWebアプリをデプロイできるPaaSです。