Application Gateway Troubleshootingを理解するための前提
AppGW troubleshootingはclient→frontendとGateway instance→backendを別connectionとして扱う。 502は「Gateway自体が死んだ」とは限らず、全backend unhealthy、TLS/SNI mismatch、DNS failure、backend timeout等が代表原因。
Backend HealthのHealthy/Unhealthy/Unknownとdetailを最初の客観証拠として保存する。 backend FQDN利用時はGateway VNet DNSが実際に何を返すかが重要。client PCのnslookupだけではGateway側DNSを証明できない。
WAF_v2ではrequestがbackendへ届く前にWAFがblockするため、WAF logとaccess logをrequest timestamp/URIで相関する。 Application Gatewayはx-appgw-trace-id等のheaderを付与し、request chainをbackend logと照合できる。
Control plane / Data plane / Observability
DNS→VIP→listener match→access log。
Backend Health→DNS→route/NSG→TLS→HTTP。
WAF policy/log→rewrite→backend response。
Client-to-backend path
- 同じclient/URL/Hostでfailureを再現しtimestampを固定する。
- DNS answerとfrontend listener/rule matchを確認する。
- Access log/WAF logでGatewayがrequestを受けたか確認する。
- Backend Healthのstatus/detailを取得する。
- Gateway→backendのDNS/TCP/TLS/SNI/HTTPを順に切り分ける。
- 修正後に同じjourneyを再実行し、reload/new connectionでも再現しないことを確認する。
仕組みを分解する
最も避けたいのは、502を見てNSGを広げる、WAF blockを見てmanaged ruleを丸ごとdisableする、といった証拠なし変更です。status code、backend health detail、WAF rule ID、DNS answer、TLS certificateを積み上げれば変更scopeを小さくできます。
運用時は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は到達しません。
設計判断
| 判断軸 | 設計方針 |
|---|---|
| Runbook | 502/403/404/TLS timeout等の症状ごとに最初の証拠を固定する。 |
| Diagnostics | Access/WAF/Performance/resource healthの必要logを事前に送信する。 |
| Correlation | timestamp、Host、URI、client IP、x-appgw-trace-id等でbackend logと結ぶ。 |
| Safe change | probe/NSG/WAF exclusion/cert変更を一度に混ぜず、1 hypothesisずつ検証する。 |
確認手順
Read-only verification
- Backend HealthをCLIで保存する。
- Access/WAF logsを同時刻・Host・URIでqueryする。
- backend certificate/SNIを直接検証する。
- Network Watcher/packet captureでGateway subnet→backend flowを必要時に確認する。
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 monitor diagnostic-settings list --resource <appgw-resource-id> -o jsonc
az network application-gateway waf-policy show -g <rg> -n <policy> -o jsoncGet-AzApplicationGatewayBackendHealth -Name <appgw> -ResourceGroupName <rg>
Get-AzApplicationGateway -Name <appgw> -ResourceGroupName <rg>障害切り分け
| 症状 | 第一候補 | 証拠 | 次の確認 |
|---|---|---|---|
| 502 | backend health/TLS/DNS | Backend Health + access log | reason別にprobe/DNS/TLS |
| 403 | WAF/application auth | WAF rule ID/backend log | WAF blockかapp 403か分離 |
| 404 | listener/path/Host | access log/rule map | routing/Host確認 |
| TLS client error | frontend cert/listener | browser/curl TLS | cert chain/SAN/SNI |
| Backend Unknown | DNS/control-plane/subnet | health detail | custom DNS/route/CRL |
変更時の確認と rollback
- 変更前にhealth/log/cert/DNS snapshotを保存する。
- WAF exclusionは最小field/rule scopeにし、期限/ownerを持たせる。
- NSG allow-anyをtemporary fixとして残さない。
- 修正後は同一failure request + adjacent正常requestを再試験する。
Current notes — 2026-09-11
Microsoftの2026 troubleshooting docsはBackend Health detailを起点にDNS、NSG/UDR、TLS/SNI、CRL reachabilityを個別に確認する流れを示している。
Related articles
Official sources
動作、retirement、feature availability、health/TLS behaviorはMicrosoft Learnのcurrent documentationを基準に確認しています。production変更時は対象subscription/region/SKUの最新documentationとresource provider stateを再確認してください。