Azure Front Door Resource Health 異常時の原因調査と504対策：X-Azure-Refとログで行う実践トラブルシュート

2025年9月8日に発生した Azure Front Door（AFD）の Resource Health 異常は、クラウドフロントエンド依存度の高いシステムにとって「よくあるが見逃せない」インシデントです。本記事では、同様の事象が再発したときに、最初の10〜15分で何を確認し、どのログを集め、どのように緩和・復旧し、最後にどんな恒久対策を設計すべきかを、実運用目線で整理します。

Azure Front Door の Resource Health 異常は「何が壊れている」のサインか

AFD の Resource Health に「異常」や「デグレード」が表示されると、「Azure 側のプラットフォーム障害だ！」と思いがちですが、実際には オリジン（バックエンド）の遅延・無応答 や 構成不整合 が原因で AFD のヘルス判定が悪化しているケースが少なくありません。

AFD は、エッジからオリジンに対して ヘルスプローブ を定期的に送信し、その結果をもとにオリジンの健全性を判断します。オリジンを論理的に束ねた オリジングループ 単位でヘルスを評価し、ヘルシーなオリジンにだけトラフィックを流します。

このとき、ヘルスプローブ先のパスが重い処理だったり、認証が必要だったり、アプリ側で一時的に遅延・エラーが増えていると、AFD 側からは「バックエンドが不健康」「到達できない」ように見えます。その結果が Resource Health の「異常」として現れます。

つまり、Resource Health の異常は必ずしも AFD プラットフォームの障害を意味するわけではなく、

オリジンが高負荷・タイムアウトしている
ヘルスプローブ設計が不適切（重い/認証必須/リダイレクトなど）
WAF や Rules Engine の誤設定でヘルスプローブをブロックしている

といった「自分たちの構成・実装」が原因であることが多い、という前提を持っておくことが重要です。

AFD が付与するトラッキングヘッダーと Resource Health の関係

AFD はすべてのリクエストに対して X-Azure-Ref というユニークなトラッキング ID（Reference String）を付与します。これはアクセスログや WAF ログの TrackingReference フィールドと対応しており、個別リクエストを追跡するためのキーです。

Resource Health 異常の時間帯に、クライアント側で取得した X-Azure-Ref をもとにログを検索することで、

エッジ PoP（どのリージョン/PoP 経由だったか）
どのオリジンが選択されたか
WAF にブロックされていないか
オリジンの応答コード（X-Azure-OriginStatusCode）

などを突き合わせられます。これが「AFD 側かオリジン側か」を切り分けるうえでの最重要情報になります。

再発時の即時対応チェックリスト（最初の10〜15分）

次に同様の事象が起きたとき、最初の 10〜15 分でやるべきことを、実際の運用フローとして整理します。この部分はそのまま Runbook としても活用できます。

1. 影響範囲を素早く把握する

最初の数分で「どれくらいヤバいのか」を定量的に把握することが、以降の判断（緊急エスカレーション／段階的対応）に直結します。Azure Monitor のメトリックビューや事前に作成したダッシュボードで、以下を確認します。

観点	代表的メトリック	チェックポイント
エラー率	5xx エラー数、HTTP 504 件数	通常時との比（例：5分平均で 3〜5 倍以上なら要注意）
オリジン健全性	Origin Availability / Backend Health	特定のオリジングループ・オリジンだけ落ちていないか
遅延	Backend/Origin Latency、Client Latency	エッジ〜オリジン間の遅延が急に伸びていないか
スコープ	ドメイン別・ルート別メトリック	一部ドメイン／特定ルートだけ問題が出ていないか

この時点で、「全体に広がる問題か」「一部ドメイン／一部地域／一部ルートだけか」をざっくり分けておくと、後続の調査が一気に楽になります。

2. プラットフォーム障害か、自社側かを切り分ける

次に確認すべきは、Azure Service Health / Resource Health のイベントです。

Service Health：Azure プラットフォーム全体・特定リージョンの障害情報
Resource Health：特定リソース（今回なら AFD プロファイル）の状態

Service Health に同時間帯・同リージョンの障害イベントがある場合は、Azure 側のインシデントの可能性が高まります。なければ、まずは オリジン側の要因 を強く疑います。

Resource Health が「デグレード」と表示されていても、それが「オリジン応答が悪くてヘルスプローブに失敗している」ことの結果であるケースは多々あります。ここで勘違いして「Azure 側のせい」と決めつけないことが重要です。

3. オリジンとヘルスプローブの健全性を確認する

AFD 配下のオリジン（App Service・VM・AKS・APIM など）について、次の観点でざっと見るだけでもかなりの情報が得られます。

CPU 使用率、メモリ使用量、接続数/スレッド数
GC（一時的なフル GC の増加など）、スレッドプール枯渇
DB・キャッシュ・外部 API の応答時間とエラー率

同時に、AFD のオリジングループ設定で以下を確認します。

ヘルスプローブのパスが /healthz のような軽量・認証不要のエンドポイントか
ヘルスプローブに対してリダイレクトや認証がかかっていないか
直前にヘルスプローブ設定を変更していないか

ヘルスプローブが 401/403/302 などを返す設定になっていると、オリジンが正常でも AFD からは「不健康」と判定され、トラフィックが止まることがあります。

4. AFD を経由しない直接疎通テスト

AFD 側の評価とオリジンの実態のギャップを埋めるために、AFD を経由しない疎通テストを必ず行います。

curl -I https://&lt;origin-host&gt;
curl -I -H "Host: &lt;afd のホスト名&gt;" https://&lt;origin-host&gt;

ポイントは次の通りです。

AFD と同じ Host ヘッダーで叩いてみる（仮想ホスト設定の差を排除）
レスポンスステータス（200 / 500 / 502 等）
応答時間（例：5 秒以上かかるリクエストが大量にあるか）

ここで「オリジン直でも遅い/落ちる」なら、AFD ではなくオリジン側の問題と判断しやすくなります。

5. 一時的な緩和策の適用

ユーザー影響を抑えるために、根因究明と並行してとれる緩和策を検討します。

オリジン応答タイムアウトの一時拡大

AFD Standard/Premium では Origin response timeout を構成できます。既定値から 16〜240 秒の範囲で変更可能で、AFD プロファイルの概要画面から設定します。

オリジン側のレスポンスが一時的に遅くなっているが、遅延を許容すれば処理できる状況であれば、タイムアウトを一時的に延長することで 504（Gateway Timeout）を減らせます。

ただし、タイムアウトを闇雲に伸ばすとスレッド占有や輻輳を招くため、

ピークの想定レスポンス時間
アプリケーションのスレッド/接続モデル
ユーザー体験上許容できる待ち時間

を考慮した上で、段階的（例：30 → 45 → 60 秒）に調整するのが安全です。

フェイルオーバー・トラフィックシフト

オリジングループがアクティブ/スタンバイ構成になっている場合、AFD の優先度・重み設定で「動いているオリジン」にトラフィックを逃がします。

特定リージョンのオリジンだけが高負荷なら、他リージョンに一時退避
オンプレ/クラウド二重化構成で、どちらか片系に切り替え

トラフィックシフトの前後で、エラー率・遅延が期待通りに変化するかをメトリックで確認します。

静的メンテナンスページへの切替

どうしても動的オリジンが耐えられない場合は、Rules Engine を使って一時的に静的メンテナンスページへリダイレクト/レスポンス上書きすることも検討します。

特定のパスだけ 302/307 で静的サイト（BLOB Static Web など）に飛ばす
一律 503 + カスタムメッセージを返すルールを一時適用

ユーザーに「落ちている」ではなく「計画外メンテナンス中」であることを明示し、問い合わせの殺到を防ぐことにもつながります。

6. WAF / ルール変更の有無を確認

同じ時間帯に、WAF ログでブロックが急増していないかを確認します。WAF ログにも TrackingReference（X-Azure-Ref）が出力されるため、クライアントから取得した ref と容易に突き合わせできます。

直近でカスタムルールを追加/変更していないか
誤検知しやすいルール（SQLi/XSS など）が突然ヒットしていないか
Rate Limit のしきい値を絞りすぎていないか

もしヘルスプローブが WAF にブロックされている場合、ヘルスプローブ用のパスやヘッダー（X-FD-HealthProbe）を条件に除外ルールを作ることで解決できます。

7. `X-Azure-Ref` を中心としたトレース情報の採取

再発防止・サポート連携のために、インシデント発生中から以下の情報をテンプレート的に残します。

X-Azure-Ref（複数パターン・複数クライアントから）
URL（パス・クエリパラメータを含む）
クライアント地域 / ASN（ISP）
AFD エッジ PoP（アクセスログから特定）
オリジン名 / OriginUrl

これらをもとに、後述するような Kusto クエリでログを絞り込むと、原因特定がかなりスムーズになります。

ログとトレースを使った原因特定の実践

`X-Azure-Ref`（Reference String）の実用的な使い方

Microsoft は「4xx/5xx エラーのトラブルシューティングには Reference String（X-Azure-Ref）を使う」ことを公式に案内しており、専用のトラブルシューティングツールも用意されています。

基本的な流れは次の通りです。

ブラウザの開発者ツールや Fiddler でレスポンスヘッダーの X-Azure-Ref を確認し、値をコピーする。
Azure Portal の AFD リソースから、「トラブルシューティング」や「診断」メニューを開く。
「4xx/5xx エラーの診断」等の項目を選び、Reference String を入力して、既知の問題・構成誤りがないかを自動チェックする。

また、Log Analytics や他の SIEM に送っている AFD の診断ログでも、TrackingReference（または類似名の列）をキーに検索できます。

アクセスログの Kusto クエリ例

Log Analytics に AFD の FrontDoorAccessLog を送っている場合、代表的なクエリ例は次のようになります（テーブル名や列名は環境に合わせて調整してください）。

// 特定の X-Azure-Ref に対応するリクエストを検索
FrontDoorAccessLog
| where TrackingReference == "&lt;X-Azure-Ref の値&gt;"
| project TimeGenerated, ClientIP, RequestUri, HttpStatus, OriginStatusCode, 
          OriginUrl, BackendLatency, ClientLatency, CacheStatus

// 504 が多発している時間帯に、オリジンごとの傾向を見る
FrontDoorAccessLog
| where TimeGenerated between (datetime(2025-09-08T04:00:00Z)..datetime(2025-09-08T09:00:00Z))
| where HttpStatus == 504
| summarize count() by OriginUrl, bin(TimeGenerated, 5m)
| order by count_ desc

WAF ログ（例：FrontDoorWebApplicationFirewallLog）でも同様に TrackingReference で結合すると、

同じリクエストが WAF にブロックされていたか
どのルール ID がヒットしたか

をほぼ一発で突き止められます。

オリジン側で見直すべき典型ポイント

多くの 504（OriginTimeout）や Resource Health 異常は、「オリジンが遅い」か「オリジンに到達できない」が主因です。実際、OriginTimeout に関する Q&A でも、オリジンレスポンスの遅延や構成の不整合が原因になっているケースが繰り返し報告されています。

App Service / AKS / VM 共通の観点

CPU / メモリ使用率のスパイク（縦に伸びたグラフを探す）
スレッドプールや接続プールの枯渇（待ち時間の増加）
DB・キャッシュ（Redis）・外部 API の応答時間とタイムアウト
アプリケーションのログ（例外・タイムアウト・リトライ失敗）

特に、DB や外部 API のレスポンスが遅くなると、アプリケーションのレスポンスも連鎖的に遅くなり、結果として AFD から見ると「オリジンがタイムアウトした」と判定されます。

ヘルスプローブ用エンドポイントの実装

オリジンに、AFD のヘルスプローブ専用の軽量エンドポイント（例：/healthz）を用意しておくと、アプリの一部障害とインフラの致命的障害を切り分けやすくなります。

認証不要・極力軽い処理（DB 接続が必須かどうかは用途次第）
正常時は必ず 200 を返す
アプリの致命的状態（例：DB 完全ダウン）では 500/503 を返す

このパスを AFD のヘルスプローブに設定し、逆にログインページや重いレポートページなどをプローブに設定しないよう注意します。

よくある原因と見直しポイント（早見表＋おすすめアクション）

症状 / ログ	典型原因	見直しポイント	おすすめアクション
504 増加、`X-Azure-Ref` あり	オリジン遅延 / 無応答	アプリ/DB/外部 API の遅延、スケール不足	オートスケールしきい値見直し、クエリ/キャッシュ最適化、 Origin response timeout を段階的に調整
プローブ不健康（Probe 失敗率増加）	プローブ先の不適切なパス・認証	プローブパスがログインページ・重い API になっていないか	`/healthz` 導入、WAF でヘルスプローブを許可
一部のパス / メソッドのみ 4xx/5xx	Rules / WAF / リダイレクト設定ミス	直近のルール変更、HTTP→HTTPS 変換の影響	Rules Engine / WAF 設定の差分確認、疑わしいルールを一時無効化して切り分け
特定 PoP / 地域のみ障害	地域的ネットワーク要因、特定オリジンの問題	PoP 単位のエラー率、OriginUrl 単位の 5xx 率	優先度/重み設定で他リージョンへフェイルオーバー
TLS / 証明書エラー	証明書期限切れ、ホスト名不一致、SNI ミス	証明書の SAN/CN、期限、エクスポートミス	証明書の自動更新設定、AFD へのバインド確認

タイムアウトとリトライの設計方針

AFD 側の Origin response timeout を伸ばすだけでは根本解決になりません。クライアント・AFD・オリジン・DB/外部 API の間で、タイムアウトとリトライの設計を全体最適で考える必要があります。

クライアントのタイムアウト < AFD タイムアウト < オリジンの総処理時間上限
オリジンから DB/外部 API へのタイムアウトはさらに短めに設定し、失敗したら即座にフォールバックやエラー応答を返す
リトライは「短時間のネットワーク揺らぎ」にだけ効くよう、回数と待ち時間を抑える

特に 504 の多くは「時間をかけても結局成功しない」処理に対して過度に待っている結果として発生します。タイムアウトを延ばすのではなく、「早めに失敗と判断して、ユーザーに分かりやすいエラーを返す」ほうが、ユーザー体験として好ましいことも少なくありません。

監視とアラート設計のベストプラクティス

再発防止のカギは、「壊れてから気づく」のではなく「壊れかけで気づく」監視設計です。AFD とオリジンの両方で、次のようなアラートを設定しておくと安心です。

AFD
- 5xx 率 / 504 件数のしきい値（例：5分平均で 1% を超えたら警告、5% で重要）
- Origin Availability / Backend Health の急激な悪化
- Probe 失敗率の増加（特定オリジン単位）
- BackendLatency の異常な増加
オリジン
- CPU / メモリ / 接続数 / スレッド数の上限近傍
- DB・外部 API 応答時間の増加、タイムアウト件数の増加
- アプリケーションログ中の例外・タイムアウトの急増

加えて、アクセスログや WAF ログに X-Azure-Ref を必ず残し、Log Analytics で検索しやすい形（JSON フォーマットなど）にパースしておくことで、障害発生時のトリアージ時間を大きく短縮できます。

Resource Health / Service Health / 実際の障害の関係を理解する

最後に、やや概念的ですが非常に重要なポイントです。

Service Health … Azure プラットフォームのインシデント（リージョン全体・サービス全体）
Resource Health … 特定リソース（AFD プロファイルなど）の状態
実際の現象 … ユーザーが体験しているレスポンス遅延・エラー

Resource Health に「異常」と出ていても、その根因がオリジン側であることは現実にあり得ます。「Resource Health のステータスだけを見て原因を決めつけない」ことが重要です。

逆に、Service Health に障害が出ている場合は、AFD だけでなく他の Azure サービスにも影響が出ている可能性があります。この場合は、自分たちの構成・実装だけでは解決できないため、Azure サポートからの情報更新を待ちつつ、ユーザー周知や一時的なバイパス構成（別 CDN への切替など）を検討します。

社内・サポート連携用の証跡テンプレート

インシデント対応中・直後に、少なくとも次の項目をまとめておくと、社内報告・ポストモーテム・Microsoft サポートとのやり取りがスムーズになります。

影響期間（UTC / ローカル両方）
影響ドメイン・ルート（例：www.example.com /api/）
エラー率推移（5xx / 504）、レイテンシ推移、オリジン健全性の変化グラフ
代表的な失敗リクエストの X-Azure-Ref、URL、クライアント地域/ASN、エッジ PoP、オリジン名
オリジン側メトリック（CPU、メモリ、スレッド/接続、GC、DB/外部 API 応答時間）
直近の構成変更（AFD ルール/WAF、証明書、DNS、アプリリリース、スケール設定変更）

これらをあらかじめテンプレート化し、障害発生時に埋めていく形式にしておけば、対応の属人化を防ぎつつ、素早く詳細な報告を出すことができます。

運用 Runbook に落とし込むときのポイント

本記事の内容をそのまま Runbook にする場合、次のような構成がおすすめです。

検知：どのアラートでインシデントを開始するか（例：AFD 5xx 率 > 5%）
初動（10〜15分）：本記事の「即時対応チェックリスト」をそのまま手順化
緩和フェーズ：タイムアウト調整・フェイルオーバー・静的ページ切替等のオプションと判断基準
復旧判断：エラー率・レイテンシがどこまで戻ったら「収束」とみなすか
ポストモーテム：原因特定・恒久対策・再発防止アクションアイテム

特に、「どの段階で誰にエスカレーションするか」「どのタイミングでお客様へのアナウンスを行うか」といった運用フローを明文化しておくと、深夜や休日のインシデントでも迷いなく動けます。

まとめ：オリジンを含めたエンドツーエンドの設計が Resource Health 安定化の鍵

2025/09/08 の Azure Front Door Resource Health 異常のような事象は、今後も完全には避けられません。しかし、

オリジン遅延／無応答が主因であることが多い という前提を持つ
X-Azure-Ref を中心にログとトレースを設計 しておく
ヘルスプローブ・タイムアウト・スケール・WAF/ルール を一貫したポリシーで設計する
Runbook と監視 を標準化して、再発時の初動を自動化に近づける

ことで、「同じ種類の障害」に対しては短時間で切り分け・緩和・復旧できるようになります。

AFD はあくまで「賢いリバースプロキシ/エッジ」であり、アプリやオリジンが抱えるボトルネックまで自動で解決してくれるわけではありません。Resource Health のステータスだけに振り回されるのではなく、オリジンを含めたエンドツーエンドの設計と運用を整えることが、結果として AFD の安定運用にも直結します。

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

Azure Front Door Resource Health 異常時の原因調査と504対策：X-Azure-Refとログで行う実践トラブルシュート