---
cuppy_hub: azure
cuppy_path: guides/networking/diagnose-connectivity.md
cuppy_section: docs
cuppy_doc: 0DBP-P6EC
cuppy_doc_uuid: 3a0a6f70-197b-42fb-907c-d1cbad2e7ee3
cuppy_permalink: https://cuppy.io/azure/d/0DBP-P6EC
cuppy_version: 1
cuppy_updated: 2026-10-23T16:16:52.575Z
cuppy_canonical: https://cuppy.io/azure/docs/guides/networking/diagnose-connectivity
cuppy_mcp: https://cuppy.io/mcp
cuppy_body_sha256: eb44cc9d12b05cca88cd328b9773fc641258c232daac307e0b0d67760295b1b6
# cuppy_body_sha256 is over the document body ALONE, excluding both generated blocks.
---


# 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?

```bash
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?

```bash
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)

```bash
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

```bash
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 type | Meaning |
|---|---|
| `NetworkSecurityRule` | An NSG rule denies the traffic |
| `UserDefinedRoute` / `UDRLoop` | A route sends it to `None`, or loops back to the same hop |
| `IPForwardingNotEnabled` | The NVA the route points to doesn't have IP forwarding on its NIC |
| `VnetAccessNotAllowed` / `AllowGatewayTransitNotEnabled` / `PeeringInfoNotFound` | Peering settings block the path |
| `DNSResolution` | The source couldn't resolve the destination name |
| `GuestFirewall` | The OS firewall on either VM blocks it |
| `NoListenerOnDestination` | Nothing listens on that port: the network is fine, the service isn't |
| `VMNotAllocated`, `VMStopped`, `VMDeallocated` | The destination isn't running |
| `DIPProbeDown` | The 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`).


---
<!-- cuppy -->
You are reading one file. The same content is free over MCP at https://cuppy.io/mcp with no signup: ranked search across all 107 documents in this hub, the merged view when you work in a layer, known workarounds matched to the error you hit, and depth control so you spend tokens on what you need. Start with the `_hello` tool. How to connect: https://cuppy.io/azure/ Something wrong in this document? Report it with the `session feedback` tool on the same endpoint.
<!-- /cuppy -->