Application Gateway Backend Healthを理解するための前提
Backend Healthはprobe結果に基づきbackend serverごとにHealthy/Unhealthy/Unknownを報告する。 Healthyはprobeがexpected responseを受信、Unhealthyはresponseなし/期待外response、Unknownはcontrol-plane communicationやbackend FQDN DNS resolution等でも発生する。
health reportはprobe refresh intervalに従って更新され、Portal refresh時刻そのものとは一致しない。 custom probeではHost、path、expected status code等を指定できる。backend HTTPSではSNI/CN/trustがprobe resultを左右する。
全backendがUnhealthy/Unknownならclientは502等に遭遇し得る。 backend healthはapplication business transaction成功を証明しない。代表journeyを別途実行する。
Control plane / Data plane / Observability
Gateway instance→backendのhealth request。
backend setting associationごとの状態とreasonを読む。
client requestは別connection。healthが緑でもHost/path/authは失敗し得る。
Client-to-backend path
- Gatewayがbackend setting/probe associationを解決する。
- backend FQDNがあればGateway VNet DNSでresolveする。
- probe protocol/Host/path/SNIでbackendへ接続する。
- response/timeout/TLS結果をhealth stateへ反映する。
- routingはhealthy backendをcandidateにする。
- 状態変化は次回probe cycleでreportへ反映される。
仕組みを分解する
Backend Healthのreasonを「NSGでblocked」と即断せず、DNS→TCP→TLS/SNI→HTTP statusの順に分解します。特にFQDN backendでUnknownならGateway VNetのcustom DNSを疑い、HTTPSでUnhealthyならbackend certificate subject、trusted root、backend setting Host、custom probe Hostを照合します。
運用時はresource configurationだけで完了判定せず、実clientからの名前解決、TCP/TLS handshake、HTTP status、backend側のsource IP/Host/header、health telemetryを同じtimestampで揃えます。load balancer/proxyがhealthyでもapplication dependencyが壊れている場合があり、逆にbackend applicationが正常でもhealth probe条件やrouting ruleが不整合ならtrafficは到達しません。
設計判断
| 判断軸 | 設計方針 |
|---|---|
| Default vs custom probe | defaultで十分か、Host/path/readinessを指定する必要があるかを決める。 |
| Expected status | maintenance/redirect/auth endpointをprobeに使わず、安定したreadiness responseにする。 |
| DNS | backend FQDNはGateway VNetから解決可能なauthorityへ置く。Private Endpointの場合はPrivate DNS pathを確認する。 |
| TLS | backend cert lifecycleとtrusted root/SNI configを同じchange windowで管理する。 |
確認手順
Read-only verification
- Portal Backend healthでpool/server/setting/status/detailsを保存する。
- CLI/PowerShellでも同じ時刻にbackend healthを取得し、Portal表示だけに依存しない。
- Gateway VNetと同等DNS contextからbackend FQDNをresolveする。
- backend logでprobe Host/path/statusを確認する。
Evidence to keep
- resource ID / subscription / region / frontend / backend targetを保存し、同名resource取り違えを防ぐ。
- DNS answer、source IP、destination IP/port、Host/SNI、health status、timestampを同じincident recordへ残す。
- 変更前後で同じclient journeyをnew connectionとして再実行する。
- Portal表示だけでなくCLI/PowerShell/APIまたはlogsを併用し、観測面の一時差を識別する。
az network application-gateway show-backend-health -g <rg> -n <appgw> -o jsonc
az network application-gateway probe list -g <rg> --gateway-name <appgw> -o jsoncGet-AzApplicationGatewayBackendHealth -Name <appgw> -ResourceGroupName <rg> | ConvertTo-Json -Depth 10障害切り分け
| 症状 | 第一候補 | 証拠 | 次の確認 |
|---|---|---|---|
| Unhealthy: timeout | route/NSG/listener | probe detail + packet capture | Gateway instance→backend path |
| Unhealthy: cert | SNI/CN/root | TLS error/cert | backend setting/probe Host |
| Unknown: DNS | custom DNS | FQDN resolution | VNet DNS/Private DNS |
| Healthyだが502 | live request差 | access log/request ID | Host/path/backend setting |
| No results | RBAC/permission | portal/API response | reader permissions確認 |
変更時の確認と rollback
- probe/backend setting変更前にhealth snapshotをJSON保存する。
- DNS変更はTTL/cacheを考慮し、旧answer/新answerを併記する。
- certificate rollbackはold chainとtrusted rootを保持する。
- rollback後はhealth report更新を待つだけでなく同じclient requestを再試験する。
Current notes — 2026-09-11
2026年のtroubleshooting guidanceではbackend health Unknown/Unhealthyの要因としてDNS、NSG/UDR、CRL到達、TLS/SNI等を個別に扱っている。
Related articles
Official sources
動作、retirement、feature availability、health/TLS behaviorはMicrosoft Learnのcurrent documentationを基準に確認しています。production変更時は対象subscription/region/SKUの最新documentationとresource provider stateを再確認してください。