Application Gateway Listeners & Routingを理解するための前提
listenerはfrontend IP、frontend port、protocol、optional host nameを組み合わせてincoming requestを受ける。 multi-site listenerはHostでsiteを分離し、path-based ruleはURL path mapでbackendを選ぶ。
v2ではrequest routing rule priorityを明示し、重複条件がある場合の評価順を制御する。 backend settingのHost overrideはbackend TLS SNI、application routing、redirect/cookie生成に影響する。
host preservationが必要なappでは不用意なHost overrideを避け、incoming Hostをbackendへ渡す設計を優先する。 rewrite setはheader/URLを変更できるが、root causeであるhost/routing modelを隠すための場当たり対応にしない。
Control plane / Data plane / Observability
frontend + port + protocol + Hostで入口を特定。
basic/path-based ruleとpriorityでbackend pathを選択。
backend Host/SNIとapplication virtual hostを一致させる。
Client-to-backend path
- DNSがclientをAppGW frontendへ向ける。
- listenerがIP/port/protocol/Hostに一致する。
- rule priorityとURL path mapがbackend pool/settingsを決める。
- 必要ならrewrite setでrequest header/URLを変更する。
- backend settingに基づくHost/SNIでbackendへconnectする。
- response rewrite/redirectを経てclientへ返す。
仕組みを分解する
「listenerは合っているがbackendで別siteが出る」場合、routing ruleだけでなくHost headerとSNIを見ます。backend FQDNを設定したから自動的にapplication Hostも正しいとは限りません。App Service等のplatform originではhost mismatchがredirectやcookie domain、authentication callback failureを生むため、original Host preservationを設計要件として扱います。
運用時は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は到達しません。
設計判断
| 判断軸 | 設計方針 |
|---|---|
| Multi-site | Host別にlistenerを分ける。wildcardを使う場合はspecific listenerとのpriority/coverageを試験する。 |
| Path routing | API/static等をpathで分ける場合、default backendとcatch-all順序を明示する。 |
| Host header | backend platform requirementとoriginal-host preservationのどちらを優先するか根拠を残す。 |
| Rule priority | 重複listener/ruleを機械的に解決できるようpriorityをIaCで固定する。 |
確認手順
Read-only verification
- listenerのhostNames、frontendIPConfiguration、frontendPort、protocolを確認する。
- rule priorityとurlPathMapのdefault/pathRuleを展開する。
- backend access logでHost/X-Original-Host/X-Forwarded-Hostを確認する。
- HTTPS backendはSNIで返るcertificateを直接確認する。
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 http-listener list -g <rg> --gateway-name <appgw> -o jsonc
az network application-gateway rule list -g <rg> --gateway-name <appgw> -o jsonc
az network application-gateway url-path-map list -g <rg> --gateway-name <appgw> -o jsonc(Get-AzApplicationGateway -ResourceGroupName <rg> -Name <appgw>).HttpListeners | Format-List *障害切り分け
| 症状 | 第一候補 | 証拠 | 次の確認 |
|---|---|---|---|
| 別siteへ入る | listener Host/wildcard | Host + listener config | priority/specificity確認 |
| 特定pathだけ502 | path rule backend | URL path map + health | target backend setting確認 |
| redirect loop | Host/proto rewrite | Location + X-Forwarded-* | host preservation |
| TLS CN mismatch | backend SNI | cert + backend setting host | Host/SNI一致 |
| 変更後一部routeだけ旧 | rule priority overlap | rule list | priority/IaC差分確認 |
変更時の確認と rollback
- listener/rule/path mapをJSON exportする。
- Host override/rewrite変更はresponse redirect/cookieまで含めてA/B検証する。
- wildcard追加は既存specific listenerを奪わないことを確認する。
- rollback後は各Host/pathの代表URLを同じHost headerで再試験する。
Current notes — 2026-09-11
v2ではrule priorityを明示管理できる。host preservationはFront Door/App Gatewayを含むreverse proxy設計の重要なapplication compatibility要件。
Related articles
Official sources
動作、retirement、feature availability、health/TLS behaviorはMicrosoft Learnのcurrent documentationを基準に確認しています。production変更時は対象subscription/region/SKUの最新documentationとresource provider stateを再確認してください。