Diagnose a connection that times out or is refused inside Azure

The ordered checks for "it can't connect" between Azure resources, or from an app to a PaaS service — resolve the name from where the caller runs, confirm the private endpoint connection, read effective NSG rules and routes, test with Network Watcher (IP flow verify, next hop, connection troubleshoot and its issue types), then the target's own firewall, then the app — with the CLI call for each step and what each answer means.

markdownguidev10DBP-P6ECstage: operatetrust: officialservice: networkinginterface: cliAzure connection timeoutdiagnose connectivity Azurenslookup private endpointaz network watcher test-connectivityconnection troubleshoot issue typesNetworkSecurityRuleUserDefinedRoute NoneUDRLoopIPForwardingNotEnabledVnetAccessNotAllowedNoListenerOnDestinationGuestFirewallaz network watcher test-ip-flowaz network watcher show-next-hopInterfaceEndpointaz network nic show-effective-route-tableaz network nic list-effective-nsgNetworkWatcherRGApp Service outbound diagnosticsKudu tcpping nameresolver

Created 21 Oct 2026 · Modified 23 Oct 2026 · 1 version

Diagnose a connection that times out or is refused

A timeout is almost always one of five things, checked in this order: the name resolves to the wrong address, a private endpoint connection isn't approved, an NSG drops the packet, a route sends it somewhere else, or the target's own firewall refuses the caller. Run each check from where the caller runs (the VM, or the app's VNet), not from your laptop.

1. What does the name resolve to, from the caller?

nslookup <account>.blob.core.windows.net
  • A private IP (10.x, 172.16–31.x, 192.168.x) when you expect a private endpoint: good, go on.
  • A public IP with a privatelink CNAME, or NXDOMAIN: a DNS problem; fix it before anything else (reference/networking/private-endpoints-and-dns.md).
  • From App Service or Functions, Kudu's nslookup doesn't use the VNet's DNS (Microsoft's VNet integration troubleshooting): use nameresolver <host> and tcpping <host>:443 there. The app's DNS comes from its integrated VNet. A TCP timeout of about 21 seconds means something drops packets; a DNS timeout is 3 seconds per server.

2. Is the private endpoint connection approved?

az network private-endpoint show -g <rg> -n <pe> --query "privateLinkServiceConnections[0].privateLinkServiceConnectionState.status" -o tsv

Pending or Rejected → reference/networking/errors.md. (For a manual connection, read manualPrivateLinkServiceConnections instead.)

3. Do NSGs and routes allow it? (VM or NIC source)

az network watcher test-ip-flow -g <rg> --vm <vm> --direction Outbound --protocol TCP \
  --local <vm-private-ip>:<any-port> --remote <dest-ip>:443
az network watcher show-next-hop -g <rg> --vm <vm> --source-ip <vm-private-ip> --dest-ip <dest-ip>
az network nic list-effective-nsg -g <rg> -n <nic>
az network nic show-effective-route-table -g <rg> -n <nic> -o table
  • IP flow verify names the rule that allows or denies the packet.
  • Next hop: Internet, VirtualAppliance (which IP), VirtualNetworkGateway, VnetLocal, None (dropped by a route), or InterfaceEndpoint (a private endpoint's /32 route, which bypasses broader UDRs). Rules and route selection: reference/networking/nsgs-and-routes.md.
  • Network Watcher must be enabled in the region (it lives in NetworkWatcherRG); the VM must be running.

4. Test the whole path

az network watcher test-connectivity -g <rg> --source-resource <vm> --dest-address <host-or-ip> --dest-port 443

The result names the hop that fails and an issue type:

Issue typeMeaning
NetworkSecurityRuleAn NSG rule denies the traffic
UserDefinedRoute / UDRLoopA route sends it to None, or loops back to the same hop
IPForwardingNotEnabledThe NVA the route points to doesn't have IP forwarding on its NIC
VnetAccessNotAllowed / AllowGatewayTransitNotEnabled / PeeringInfoNotFoundPeering settings block the path
DNSResolutionThe source couldn't resolve the destination name
GuestFirewallThe OS firewall on either VM blocks it
NoListenerOnDestinationNothing listens on that port: the network is fine, the service isn't
VMNotAllocated, VMStopped, VMDeallocatedThe destination isn't running
DIPProbeDownThe load balancer's health probe marks that backend down (reference/load-balancer/errors.md)

Connection troubleshoot without the Network Watcher VM extension is in preview; the classic path installs the extension on the source VM.

5. Does the target's own firewall accept the caller?

The network path can be fine while the PaaS service refuses the source: Storage AuthorizationFailure, Key Vault "client address is not authorized", and the databases' own IP firewalls. Check the service's public network access, firewall rules and trusted-service exceptions (reference/storage/network-and-firewall.md, reference/keyvault/access-and-errors.md). Same-region callers never present their public IP, so IP rules don't match them.

6. Only then, the application

Connection resets under load from many short connections point to SNAT exhaustion (reference/networking/outbound-connectivity.md); TLS errors to certificates or a TLS-inspecting firewall; 401 or 403 with a working connection to identity (guides/identity/fix-access-denied.md).

Read this document as markdown — the same bytes an agent receives.