Troubleshooting connectivity between cloud services

Start from the failing workload. Record the destination name, target IP if known, port, time and error, then compare the same connection from different network locations, devices or directions. If one attempt succeeds, the problem is not in the server itself but in some aspect of the network.

At the DNS layer, run nslookup or dig for the destination name, then try its IP address. If the IP works but the name does not, focus on DNS rather than the server.

For an Azure private endpoint, check whether the private DNS zone is linked to the querying VNet; this is the most common cause of a wrong answer. Look for a missing or stale A record, or custom DNS and conditional forwarders that do not forward privatelink.* queries to Azure DNS at 168.63.129.16. A private DNS zone that overrides the whole namespace can also return NXDOMAIN for resources without A records.

If the private endpoint FQDN resolves to a public IP instead of a private one, check the DNS configuration before changing access rules. A PaaS service with firewall rules denying public access can return 403 Forbidden or a TCP connection does not allow access error when the name resolves to its public endpoint; an Approved private endpoint can still have connectivity problems.

At the port and path layer, use telnet to test basic TCP/IP connectivity to the target IP and port. If the connection fails, a firewall may be blocking access; compare the hostname and IP tests to distinguish a name-resolution failure from a path or port failure.

In Google Cloud, run Connectivity Tests between the source and destination endpoints. The tool analyses the configuration and, in some cases, performs live data-plane analysis; check its results for VPC firewall rules, hierarchical or global network firewall policies, routing issues, VPC peering, and authorised networks.

For Cloud SQL, also check that the instance is running and that the Cloud SQL Auth Proxy is using the correct port and protocol. These are configuration problems Connectivity Tests can diagnose.

For Network Connectivity Center routes that are not distributed across regions, check that the VPC network's dynamic routing mode is set to global. Use this check when the failure involves route distribution across regions.

At the service layer, check whether the destination service is running and whether its access configuration permits the connection. Do not treat an Approved Azure private endpoint as proof that the path works; Microsoft notes that connectivity from the VNet can still fail.

Fix the diagnosed cause, then repeat the same DNS and connectivity tests. Change one variable at a time and record the result so you can tell which change restored the path.

For escalation, provide the source and destination, resolved address, connection or trace result, error and last known good time. Include a correlation ID if available so networking and application owners can investigate from the same evidence.