Networking error catalogue — the failures that present as a timeout, and how to tell them apart

Networking failures rarely come with a message; they come with a hang. Cause, check and fix for the recognisable Google Cloud cases: the implied ingress deny, open egress that is not open through NAT, the non-transitive peering hop, the load balancer that cannot carry your protocol, and the Cloud Armor policy that cannot attach.

markdownreferencev1QA71-2AQPstage: operatetrust: officialfamily: networkingservice: vpcinterface: anytimeoutconnection refusedimplied deny ingressimplied allow egresscloud NAT inboundnon-transitive peeringunsolicited inboundload balancer protocolsecurity policy attachdefault-allow-internal

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

Networking error catalogue

A networking failure usually has no error string. It has a hang, a timeout, or a connection refused. So this catalogue is indexed by symptom and topology rather than by message, and every row's check is designed to separate it from its neighbours.

1. Inbound hangs

SymptomCauseCheckFix
a new instance accepts nothingthe implied deny for ingress — a VPC network denies unsolicited inbound by defaultis there any ingress allow rule matching this target, port and source?add the narrowest ingress rule. Not 0.0.0.0/0
it works between two VMs but not from outsideyou are on the default network and relying on default-allow-internalwhich network is this, and does it still have the default rules?a hardened design does not use the default network. Write explicit rules
traffic to a private service hangs through NATCloud NAT "doesn't allow unsolicited inbound connections" — it translates "established inbound response packets only"is anything expecting to reach in through the NAT?use a load balancer, Private Service Connect, or an external address. No NAT setting enables this

2. Outbound surprises

SymptomCauseCheckFix
egress works when you expected it blockedthe implied allow for egress. A new VPC permits all outboundis there any egress deny rule at all?add egress rules deliberately; data-exfiltration control is opt-in here
egress fails from an instance with no external IPno Public NAT on that region's Cloud Routeris there a Cloud Router with NAT for this region and subnet?configure Public NAT. Remember it is per region, on the router
an external system rejects your calls by source addressNAT addresses are not the ones it allowlisted—use manual NAT IP address assignment so the egress addresses are stable

3. Topology

SymptomCauseCheckFix
A reaches B, B reaches C, A cannot reach CVPC peering is not transitivedraw the peerings. Is there a direct one A-to-C?peer directly, or stop using peering for this: Private Service Connect for a service, Network Connectivity Center for a network
two networks cannot peer at alloverlapping address ranges — classically two auto mode networks, both from 10.128.0.0/9what are both subnet ranges?custom-mode subnets with a planned address space. For service access, Private Service Connect sidesteps overlap entirely

4. The load balancer cannot do what you asked

SymptomCauseCheckFix
UDP, ESP, AH, GRE, SCTP or ICMP traffic will not passyou chose an Application or proxy Network load balancer; only passthrough carries thosewhich family is it?move to a passthrough Network Load Balancer
backends see the load balancer's address, not the client'sa proxy terminates the connectionis this a proxy family?passthrough preserves the source IP by direct server return — or read a forwarded header, knowing it is a trust decision
a design validated as global behaves regionallyclassic Application and proxy Network balancers are global in Premium Tier and regional in Standard Tierwhich network tier is the project or forwarding rule on?pick a non-classic global variant, or set the tier deliberately
a Cloud Armor policy will not attachthat balancer type is not on Cloud Armor's supported listcheck against reference/networking/cloud-armor.md §2change the balancer. This is a front-door rework, so check it during design

5. The cross-family row

A Cloud Run 503 — "The request failed because the instance could not start successfully" — lists network configuration among its causes. So a networking fault can present as a compute error. Check secrets and IAM first (they are more common), then egress rules (reference/compute/errors.md §4).

Next: guides/networking/reach-a-private-service.md and guides/parity/networking.md.

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