Azure Front Door StandardでAzure Storage静的Webサイトを公開しているのに、カスタムドメインが「CNAME/Alias record is not currently detected」と表示され続け、アクセスすると404になる…。本記事ではDNS設定の確認ポイントと、Front Door側の状態不整合を解消する具体的手順をまとめます。
よくある症状
構成としては「Azure Storage の静的ウェブサイト」→「Azure Front Door Standard（以下 AFD）」→「独自ドメイン（例：www.dongan.cloud）」の順に公開しているのに、次のような状態から抜け出せないケースがあります。
- AFD のカスタムドメイン画面で、ドメイン検証ステータスが Approved（承認済み）
- 証明書ステータスが Deployed（デプロイ済み）
- しかし「DNS 状態」に CNAME/Alias record is not currently detected の警告が残り続ける
https://www.dongan.cloudにアクセスすると Azure の Page not found が表示される- 24時間以上待っても改善しない
一見すると「CNAME が間違っている」「まだ伝播していない」と考えがちですが、検証が Approved になり証明書も Deployed まで到達しているなら、DNS 側は概ね正しく、AFD 側の“状態の更新”が追いついていないパターンも疑うべきです。
構成を図解的に整理する
まずは、どこが“入口”で、どこで詰まっているのかを言語化しておくと、切り分けが早くなります。今回の典型構成を表にすると次の通りです。
| 役割 | 具体例 | 正常時に期待すること |
|---|---|---|
| オリジン | Azure Storage 静的ウェブサイト（*.web.core.windows.net） | 直接アクセスでコンテンツが表示される |
| CDN/リバースプロキシ | Azure Front Door Standard（*.azurefd.net） | AFD のエンドポイント URL でも表示される（またはホストヘッダーを付けて疎通できる） |
| 独自ドメイン | www.dongan.cloud | DNS が AFD に向き、AFD のルートにドメインが紐づいて表示される |
まず切り分けるべきポイント
「Page not found」と「CNAME が検出されない」が同時に見えると混乱しますが、トラブルシューティングでは “どの層の問題か” を先に確定させるのがコツです。
| 見えている症状 | 疑う層 | 最初にやる確認 |
|---|---|---|
AFD の *.azurefd.net に直接アクセスできる | AFD 自体は稼働 | ルートとオリジンに問題がないかを確認 |
| ストレージ静的サイトは直接アクセス可能 | オリジンは稼働 | AFD からオリジンへの Host ヘッダー/パス/ヘルスプローブを確認 |
| 独自ドメインで Azure の 404 | AFD の「ルートに紐づくドメイン判定」 | ドメインがルートに関連付いているか、状態が同期しているかを確認 |
| ポータルに CNAME 未検出の警告が残る | DNS か AFD の内部チェック | DNS の競合レコード有無、AFD 側の検証状態更新を試す |
DNS が正しいのに警告が消えないときの考え方
今回のように Namecheap 側で次のような CNAME を設定していて、外部からの名前解決も正常なら、DNS そのものはほぼOKです。
| 項目 | 設定例 |
|---|---|
| 種別 | CNAME |
| ホスト | www |
| 値 | CDN-profile1-axavdqaya2dkfffr.z02.azurefd.net |
それでもポータルの「DNS 状態」だけが古いまま残る場合、次のような “表示と実態のズレ” が起きていることがあります。
- AFD のカスタムドメインは、ドメイン検証（TXT） と DNS 状態検出（CNAME/ALIAS） が別系統でチェックされる
- TXT は検出できて証明書も Deployed なのに、CNAME 状態だけ更新されない
- 外部の
nslookupやオンライン DNS チェッカーでは正しい CNAME が見えている
この条件が揃っているなら、「本当に CNAME が無い」よりも「AFD 側の内部状態が同期していない」 の方が症状に合致します。現場ではこのパターンが意外と多く、設定自体をいじり倒すよりも、AFD に“再判定のきっかけ”を与える方が早く復旧します。
解決手順
ここからは、実務で再現率の高い順に、手戻りが少ない手順を紹介します。上から順に実施してください。
ルートから一度外して付け直す
AFD に「このドメインの紐づきと DNS 状態をもう一度評価して」と促す操作です。カスタムドメイン側ではなく、Front Door Manager のルート設定 を触るのがポイントになります。
- Azure ポータルで対象の Front Door プロファイル（例：
afd-dongan-portfolio）を開きます。 - Front Door Manager を開き、対象の ルート（Route） を選択します（例：
default-route）。 - ルートの Domains セクションで、
www.dongan.cloudのチェックを外して関連付けを解除し、保存します。 - 構成の反映が落ち着くまで少し待ちます（“反映の波”を作るのが目的です）。
- 同じルートに戻り、再び
www.dongan.cloudをドメインとして関連付け、保存します。 - Front Door プロファイルの Domains 画面で
www.dongan.cloudを選択し、Refresh Validation State（検証状態の更新）を実行します。
ポイント：この操作は「DNS を変える」のではなく、AFD 側の内部テーブル（状態管理）を更新させるのが目的です。DNS 側が正しいのに警告が消えないときほど効果があります。
DNS の競合レコードが無いか最終確認する
同一ホスト名（ここでは www）に対して CNAME と他のレコードが共存 していると、プロバイダによっては見え方が変わったり、ある resolver では A が返り別の resolver では CNAME が返るなどの“揺れ”が起きます。ポータルが検出できない原因にもなり得るため、必ず潰しておきます。
| 確認対象 | なぜ問題になるか | 対応 |
|---|---|---|
www の A レコード | CNAME と競合し、正しい CNAME が返らないことがある | 不要なら削除 |
www の AAAA レコード | IPv6 側だけ別の行き先になる | 不要なら削除 |
www の URL Redirect / Web Redirect | DNS ではなくリダイレクト機能が優先されることがある | オフにするか設定を見直す |
www の TXT レコード | ドメイン検証用 TXT は別ホスト名で作るのが安全な場合がある | 必要性を確認して整理 |
すでに nslookup で CNAME が引けている場合でも、レコード競合は「時々だけおかしい」「一部の地域だけおかしい」という形で残ることがあるため、ここは手間を惜しまない方が結果的に早く復旧します。
ホストヘッダーで AFD を直接テストする
DNS を経由せず、AFD 側の「この Host でルーティングできるか」を確認できる便利な方法です。独自ドメインの名前解決が疑わしいときでも、AFD のルート設定やドメイン紐づきの問題を切り分けられます。
例として、AFD のエンドポイントが CDN-profile1-axavdqaya2dkfffr.z02.azurefd.net の場合、次のようにリクエストします。
curl -I https://CDN-profile1-axavdqaya2dkfffr.z02.azurefd.net/ -H "Host: www.dongan.cloud"- ここで期待するのは、ストレージの静的サイト（または AFD のルートが返す想定のコンテンツ）に繋がることです。
- もしここでも 404 になるなら、DNS ではなく AFD のルート／ドメイン紐づき／オリジン設定 に原因が寄ってきます。
- ここで正常に返るのに独自ドメインだけ 404 なら、DNS もしくは AFD の DNS 状態検出（ポータル表示）に原因が寄ります。
Front Door 側で見落としやすい設定
「CNAME が検出されない」と表示されていると DNS ばかり見がちですが、実際には AFD 側の設定ミスで 404 を踏んでいるケースもあります。次のチェックを“復習”として入れておくと、別原因を同時に潰せます。
ルートのドメイン関連付け
- 対象のルート（例：
default-route）にwww.dongan.cloudが確実に関連付いているか - ルートが Enabled になっているか（無効化されていないか）
- パターンが
/*など、想定のパスを包含しているか
オリジングループとオリジンの健全性
- オリジングループに Azure Storage の静的ウェブエンドポイントが登録されているか
- ヘルスプローブが失敗していないか（失敗していると AFD がバックエンドに流さない）
- 複数オリジンがある場合、優先度/重みづけが意図通りか
オリジンへの Host ヘッダー
Azure Storage の静的ウェブサイトは、Host ヘッダーが合わないと 404 になりやすいです。AFD からオリジンに送る Host ヘッダー（Origin host header）が、ストレージ静的サイトのホスト名になっているか確認します。ここが誤って独自ドメインのままだと、オリジン側で見つからず 404 になることがあります。
| 設定項目 | 推奨の考え方 | 例 |
|---|---|---|
| Origin hostname | 実際のオリジンのホスト名 | <storage>.zXX.web.core.windows.net |
| Origin host header | 原則としてオリジンのホスト名に合わせる | <storage>.zXX.web.core.windows.net |
HTTPS リダイレクトやルールセット
- HTTP→HTTPS リダイレクトを入れている場合、意図しないルートに飛んでいないか
- Rules Engine（ルールセット）で Host や Path を書き換えていないか
- WAF を使っている場合、誤検知でブロックされていないか
Namecheap 側の設定で確認したいポイント
Namecheap などのレジストラ/ DNS 事業者の UI では、同じホスト名に複数種別のレコードを追加できてしまう場合があります。次のチェックリストを、最後に“目視”で確認してください。
| チェック項目 | OK の状態 | NG の例 |
|---|---|---|
www が CNAME になっている | CNAME 1本のみ | A と CNAME が同居 |
| CNAME の値 | AFD のエンドポイント（*.azurefd.net） | 別のホスト名（タイプミス、末尾の余計な文字） |
| TTL | 極端に長くない | 過去設定のまま数日単位 |
| DNSSEC/特殊機能 | 意図通り有効/無効 | 途中で設定を変えて検証が揺れる |
また、www.dongan.cloud と dongan.cloud（ルートドメイン）は別物です。ルートドメインは CNAME を置けない DNS 事業者も多い ため、まずは www だけを確実に動かし、その後にルートドメインは ALIAS/ANAME 対応の有無を見て設計するのが安全です。
確認に使えるコマンド
「自分のPCでは見えるのに、Azure では検出できない」といった時は、複数の resolver で引いて差分を見ると原因に近づきます。代表的なコマンド例を載せます。
名前解決の確認
nslookup www.dongan.cloud
nslookup -type=cname www.dongan.cloud別の DNS で引いて差を見る
nslookup www.dongan.cloud 8.8.8.8
nslookup www.dongan.cloud 1.1.1.1キャッシュの影響を避けた疎通
DNS が揺れているときは、前述の Host ヘッダー指定の curl が特に役立ちます。
curl -I https://CDN-profile1-axavdqaya2dkfffr.z02.azurefd.net/ -H "Host: www.dongan.cloud"それでも改善しない場合の現実的な選択肢
上の手順をやっても、ポータルの警告が消えない／独自ドメインの 404 が続く場合は、AFD 側で状態が固まっている可能性があります。こうなると利用者側の操作だけでは限界があるため、Azure サポートに「カスタムドメインの DNS 状態が更新されない」 旨で依頼するのが最短です。
サポートに出すときは、調査が早く進むように次の情報をまとめておくとスムーズです。
- 対象のカスタムドメイン（例：
www.dongan.cloud） - Front Door プロファイル名、エンドポイント名
- CNAME の値（例：
CDN-profile1-axavdqaya2dkfffr.z02.azurefd.net） - 問題が発生している時刻帯（できれば UTC も併記）
nslookupの結果（複数 resolver の結果があると強い）- ブラウザで表示されるエラー画面のスクリーンショット
復旧後にやっておきたいチェック
復旧した直後は「表示できるようになった」で終わらせず、再発防止のために次も確認しておくのがおすすめです。
- AFD の Domains 画面で DNS 状態が正常表示に変わっているか
- 証明書の有効期限と自動更新の状態
- キャッシュ（Purge）後の反映が想定通りか
- ストレージ側の
index.htmlと404.html（エラードキュメント）の設定が適切か www以外に必要なサブドメイン（cdn、assetsなど）が増える予定があるなら、レコード設計を先に固める
Azure ポータルのステータスを正しく読む
AFD のカスタムドメイン周りには複数のステータスがあり、それぞれ見ているものが違います。混同すると「証明書は出ているのに、なぜ CNAME を見つけられない？」という違和感が強くなります。代表的な項目を整理しておきます。
| ポータルの表示 | 主に見ているもの | この状態で言えること | 次の一手 |
|---|---|---|---|
| Domain validation: Pending | 検証用 TXT レコード | TXT が見えていない、または反映待ち | TXT 名・値・ホスト名（@ かサブドメインか）を再確認 |
| Domain validation: Approved | 検証用 TXT レコード | TXT は少なくとも一度検出されている | 証明書/ルート/ DNS 状態の確認へ進む |
| Certificate: Deploying | 証明書の発行と AFD への展開 | HTTPS で提供する準備中 | 待機しつつ DNS/ルートの設定を見直す |
| Certificate: Deployed | 証明書の展開完了 | AFD 側は HTTPS 提供の準備が整っている | 表示が 404 の場合はルート・オリジン側を疑う |
| DNS state: CNAME/Alias record is not currently detected | AFD が独自ドメインからの CNAME/ALIAS を検出できるか | DNS が誤りの可能性もあるが、状態更新の遅延/不整合でも発生し得る | 競合レコード確認→ルート付け直し→Refresh Validation State |
特に重要なのは、Approved + Deployed まで進んでいるのに DNS state だけが赤い、という組み合わせです。このときは「DNS がゼロから間違っている」より、AFD 側の状態が追従していない ケースを優先して疑うと、ムダな試行錯誤を減らせます。
Page not found を見分ける
同じ「404」でも、どこが返しているかで対処が変わります。目視の画面だけだと判断が難しいので、ヘッダーで切り分けるのがおすすめです。
| 404 の出どころ | ありがちな見え方 | 原因候補 | 確認方法 |
|---|---|---|---|
| AFD（ルートに一致しない） | Azure の汎用的な 404 画面になりやすい | ドメインがルートに紐づいていない、ルートが無効、パスパターン不一致 | Host ヘッダー指定の curl、ルートの Domains を再確認 |
| オリジン（ストレージ） | ストレージ側の 404（独自デザインを入れている場合も） | Origin host header 不一致、ファイルが無い、index/404 ドキュメント設定 | オリジンに直接アクセスして同じパスを叩く |
| WAF/ルール | 403/404 が混在することも | 誤検知、URL 書き換え、リダイレクトループ | ルールセット無効化で再現性を見る、ログを見る |
実務では「独自ドメインだけ 404」「エンドポイントは表示できる」という組み合わせが多く、この場合は ルートに独自ドメインが“認識されていない” ことが原因の中心になります。ポータルの DNS state が古いまま残っていると、その“認識”がうまく同期していないサインにもなります。
反映待ちでやりがちな失敗
焦って設定を変更し続けると、どの変更が効いたのか分からなくなり、逆に復旧が遅れます。次の行動は避けるのが無難です。
- DNS レコードの値を何度も変えて「前の値に戻す」を繰り返す
- 証明書を削除して作り直す（問題が DNS state のみの場合は遠回りになりやすい）
- ルートやオリジングループを増やして構成を複雑化させる
- Purge を連打して「効いていない」と判断する（そもそもルーティングされていない 404 には効果が薄い）
今回のように DNS と設定が“ほぼ正しい”状況では、状態を再評価させる 操作（ルート付け直し、検証状態更新）が一番効率的です。
ログで確証を取る
どうしても判断がつかないときは、AFD の診断ログ（アクセスログ、ヘルスプローブ、WAF など）を Azure Monitor に出して、実際にどこまで到達しているかを確認します。
- 独自ドメインへのアクセスログが 一切出ない → DNS/クライアント側で AFD に届いていない可能性
- アクセスログは出るが、結果が 404 でオリジンに到達していない → ルート/ドメイン関連付けの問題が濃厚
- オリジンへの疎通ログやヘルスプローブが失敗している → オリジンホスト名、ホストヘッダー、TLS、ネットワーク制限を疑う
サポートに依頼する場合も、ログの有無は非常に強い材料になります。「いつ、どの URL にアクセスし、どこで 404 になっているか」を示せるだけで、調査の時間が大きく短縮されます。
よくある質問
nslookup で CNAME が見えるのに、なぜ AFD が検出できないのか
AFD 側の検出は、あなたの PC が参照している DNS resolver と同じとは限りません。地域やキャッシュ、DNSSEC、CNAME チェーン、負のキャッシュ（NXDOMAIN のキャッシュ）などで、特定のタイミングだけ“見えない”ことがあります。また、ポータル表示が更新されず、内部的には解決できているのに警告だけ残るケースもあります。まずは競合レコードを潰し、ルート付け直しと検証状態更新で再判定を促してください。
www は OK なのにルートドメインがうまくいかない
dongan.cloud のようなルートドメインは、DNS 仕様上 CNAME を置けないため、DNS 事業者が ALIAS/ANAME など独自機能で吸収しているかどうかに依存します。ルートドメインも AFD で受けたい場合は、DNS 事業者が ALIAS 相当を提供しているか確認し、提供していない場合は www に統一してリダイレクト する設計が現実的です。
証明書が Deployed なのに 404 になるのはおかしくないか
証明書は「HTTPS で受けられる」ことを保証するだけで、ルートが正しく紐づき、オリジンに流れていることまでは保証しません。つまり Deployed でも 404 は普通に起こり得ます。ルートの Domains、パスパターン、オリジンホストヘッダーを順に確認してください。
運用で再発を減らすコツ
一度直っても、ドメイン追加や構成変更のタイミングで似た問題が再発することがあります。次の運用を入れておくと、切り分けが楽になります。
- DNS を変更する前に TTL を短めにしておき、変更後に落ち着いたら戻す
- 変更作業の前後で
nslookup結果を保存して差分を残す - AFD のルートに紐づくドメイン一覧を「最小限」に保つ（不要なドメインを残さない）
- Host ヘッダー指定の
curlを“いつでもできる確認手段”として覚えておく
まとめ
「CNAME/Alias record is not currently detected」が消えないからといって、必ずしも DNS が誤っているとは限りません。特に、ドメイン検証が Approved で証明書も Deployed まで到達しているなら、DNS 側はほぼ整っている可能性が高く、AFD 側の状態更新が追いついていないケースも現実的に起こります。
現場対応としては次の流れが実用的です。
- DNS の競合（同一ホストの A/AAAA など）が無いか確認
- Front Door Manager のルートからドメインを一度外し、付け直して検証状態を更新
- Host ヘッダー指定の
curlで「AFD がそのドメインを認識しているか」を切り分け - 改善しなければ Azure サポートへ依頼して状態をリフレッシュ
この順番で進めると、DNS を無駄に弄って泥沼化するのを避けつつ、最短で復旧できる可能性が高まります。
コメント