AZ VNet SpaceAzure Networking Wiki
Home / Operations & Troubleshooting
Operations & Troubleshooting参照資料確認: 2026-09-11

Connection Troubleshoot

Connection Troubleshootをpoint-in-time reachability testとして使い、Reachable/Unreachable、latency、hops、faultを5-tupleと実application journeyへ結び付ける。

この記事の目次
要点証拠診断順序仕組み設計確認証明範囲切り分け変更安全CurrentSources

Connection Troubleshootを理解するための前提

Connection Troubleshootはpoint-in-timeの接続性診断。継続監視のConnection Monitorとは目的が違う。 current documentationではTCPまたはICMPを、VM、VMSS、Azure Bastion、Application Gateway v2（Private Application Gateway deploymentを除く）等からVM/FQDN/URI/IPへ検査できる。

結果はReachable/Unreachableだけでなく、minimum/maximum/average latency、probes、hop path、configuration/platform issueのinsightを返す。 2026年のcurrent docsではVM extension不要のagentless experienceがpreviewとして追加された。preview機能をproduction runbookの唯一の前提に固定しない。

Reachableは「そのtest条件でnetwork到達性が成立した」証拠であり、HTTP responseの内容、authentication、backend全台、継続可用性を証明しない。 FQDN/URIテストは名前解決もfailure domainに含む。結果を保存する際は実際に解決されたdestinationと時刻を併記する。

通信や判断の流れを追う
症状を再現設定を確認能動試験ログ / packetアプリ確認

診断結果をどう読み分けるか

Input

source resource、destination、protocol、destination port、必要ならsource port。ここがincidentの再現条件。

Reachability

Reachable/Unreachableとprobe成功率。network pathのpoint-in-time評価。

Path / fault

hops、route/security/configuration fault。原因層を絞るhintであり全middleboxのpacket proofではない。

Application

実client/curl/backend log。Connection Troubleshootの外側でapplication semanticsを閉じる。

判定原則あるtoolがPASSしたら、そのtoolの責任範囲だけを通過条件にします。「Allow」「Reachable」「Healthy」をnetwork/application全体の正常証明へ拡大しません。

障害が起きたときの調べ方

  1. production failureを1つ選び、source resource ID、destination FQDN/IP、protocol/port、時刻、期待statusを固定する。
  2. FQDN/URIの場合はsource側が解決するIPを別途保存し、DNS failureとIP reachability failureを混ぜない。
  3. Connection Troubleshootを同じsource/destinationで実行し、ConnectionStatus、ProbesSent/Failed、latency、Hops/faultを保存する。
  4. Unreachableなら表示されたroute/NSG/port/DNS等のfaultを、Next Hop、IP Flow Verify、guest側listen確認など専用toolで検証する。
  5. Reachableなのにapplication failureならnetwork reachabilityをいったん通過条件とし、TLS/Host/auth/application/backend dependencyへ移る。
  6. 修正後に同じ条件で再実行し、production clientのnew connectionでも同じ回復を確認する。

仕組みと読み方

Connection Troubleshootは複数の接続性チェックを1回のtestへまとめ、NSG、UDR、port、DNS、resource状態などの問題を短時間で絞り込むための入口です。ただし、返却されるhop/pathはAzureが評価可能な範囲の診断結果であり、任意のNVA内部処理やアプリケーションの業務レスポンスまで直接観測するものではありません。

運用では「UnreachableだからNSGを開ける」のではなく、faultの種類を次の専用証拠へ変換します。RouteMissingならeffective route/Next Hop、NSG blockならIP Flow Verify/effective security rules、port/listenならguest/application、DNSならsource contextでの名前解決という順です。

運用設計

判断軸運用設計
Point-in-time use障害の今を測る。SLA/継続異常検知はConnection Monitorへ分ける。
Source fidelity本番clientとnetwork contextが違うjump VMからの成功を本番成功とみなさない。
Preview dependencyagentless preview利用可否をrunbookに明記し、extension-based pathも把握する。
Negative test本来blockedである通信もtest vector化し、変更で意図せず開通していないか確認する。

確認手順 / read-only first

実行前に固定する情報

  • subscription / resource group / resource ID / region
  • source IP/NIC/subnet と destination FQDN/IP
  • protocol / source port / destination port
  • UTC time window + JST表示
  • expected result と known-good comparison

Evidence to keep

  • command/query textとraw JSON/CSV
  • Portal screenshotだけでなくresource IDを含む機械可読結果
  • 変更前/変更後の同一test vector
  • negative test と adjacent critical path
  • rollback実施時の復帰確認
Azure CLI — read-only first
az network watcher test-connectivity \
  --resource-group <rg> \
  --source-resource <vm-name-or-id> \
  --dest-address <fqdn-or-ip> \
  --protocol TCP \
  --dest-port 443 -o jsonc
PowerShell — read-only first
Test-AzNetworkWatcherConnectivity -NetworkWatcher <watcher> -SourceId <vm-resource-id> -DestinationAddress <fqdn-or-ip> -DestinationPort 443

この結果で何を証明できるか

観測結果証明できることそれだけでは証明できないこと
Reachable + low latencyそのsource/test時点でprobeがdestinationへ到達。実ユーザーrequestのstatus/body、全backend、継続性。
Unreachable + RouteMissing診断時のsource側reachabilityにroute問題がある可能性が高い。どの設定変更が正解か。effective routes/desired designと照合が必要。
Unreachable + NSG indicationsecurity ruleがreachabilityを阻害。Firewall/WAF/guest firewallを含む全security layer。
DNS resolution failureその診断contextでname resolutionが失敗。別client/別DNS resolverでも同じ結果になること。
Reachable but app 500network reachabilityは成立。application/dependency正常性。別レイヤーへ移る。

よくある切り分けの失敗

症状 / 状態疑う層次の証拠
結果はReachableだがWebは失敗L7/TLS/auth/backend issuecurl/browser/backend logを同時刻で確認。
jump VMからだけ成功source context差本番sourceと同一subnet/route/security/DNSで再試験。
FQDNだけ失敗DNS resolutionresolved IPへのdirect testとDNS query pathを分ける。
App Gateway sourceで使えないprivate deployment等のsupport boundarycurrent supported source typesを確認し別source/packet evidenceを使う。
agentlessが使えないpreview availability/feature changeextension前提のsupported workflowへfallbackする。

変更時の確認と rollback

  • 診断のためだけにroute/NSGを恒久変更しない。
  • 一時的なallow/bypassを使う場合はConnection Troubleshootのbefore/after結果を同一条件で保存する。
  • 回復後はtemporary changeを戻し、再度Reachableと実application成功の両方を確認する。
Change safety: 診断中にsecurity、route、DNS、proxy/backendを同時変更すると、どの差分が効いたか分からなくなります。1 hypothesisずつ変更し、同じtest vectorでbefore/afterを取ります。

Current notes — 2026-09-11

Current behavior / guidance

Microsoft Learnの2026-04頃の更新ではConnection Troubleshootにagentless experience（preview）が追加されています。previewは「extension不要になる可能性があるcurrent path」として記載し、一般提供済み機能と混同しない表記にしています。

Connection Monitor
同じtest vectorを別の観測面から確認する。IP Flow Verify
同じtest vectorを別の観測面から確認する。Next Hop
同じtest vectorを別の観測面から確認する。Packet Walk Method
同じtest vectorを別の観測面から確認する。

Official sources

動作、support boundary、preview/GA、retirement、schemaはMicrosoft Learnのcurrent documentationを基準にしています。productionで使う際は対象subscription/region/resource provider/API/CLI versionの最新documentationを再確認してください。