--- cuppy_hub: gcp cuppy_path: reference/networking/errors.md cuppy_section: docs cuppy_doc: QA71-2AQP cuppy_doc_uuid: 98c03bc8-e5f4-43ab-85c1-d80b0365fd02 cuppy_permalink: https://cuppy.io/gcp/d/QA71-2AQP cuppy_version: 1 cuppy_updated: 2026-10-23T16:16:52.575Z cuppy_canonical: https://cuppy.io/gcp/docs/reference/networking/errors cuppy_mcp: https://cuppy.io/mcp cuppy_body_sha256: 5d38138f3ad75202af3ec186f50261181bd2f0574d6d755c308e6795c61ceee6 # cuppy_body_sha256 is over the document body ALONE, excluding both generated blocks. --- # 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 | Symptom | Cause | Check | Fix | |---|---|---|---| | a new instance accepts nothing | the **implied deny for ingress** — a VPC network denies unsolicited inbound by default | is 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 outside | you are on the **default** network and relying on `default-allow-internal` | which 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 NAT | **Cloud 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 | Symptom | Cause | Check | Fix | |---|---|---|---| | egress works when you expected it blocked | the **implied allow for egress**. A new VPC permits all outbound | is 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 IP | no **Public NAT** on that region's Cloud Router | is 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 address | NAT addresses are not the ones it allowlisted | — | use **manual NAT IP address assignment** so the egress addresses are stable | ## 3. Topology | Symptom | Cause | Check | Fix | |---|---|---|---| | A reaches B, B reaches C, A cannot reach C | **VPC peering is not transitive** | draw 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 all | overlapping address ranges — classically two **auto mode** networks, both from `10.128.0.0/9` | what 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 | Symptom | Cause | Check | Fix | |---|---|---|---| | UDP, ESP, AH, GRE, SCTP or ICMP traffic will not pass | you chose an **Application** or **proxy Network** load balancer; only **passthrough** carries those | which family is it? | move to a passthrough Network Load Balancer | | backends see the load balancer's address, not the client's | a **proxy** terminates the connection | is 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 regionally | **classic** Application and proxy Network balancers are global in **Premium Tier** and regional in **Standard Tier** | which 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 attach | that balancer type is not on Cloud Armor's supported list | check against `reference/networking/cloud-armor.md` §2 | change 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`. --- You are reading one file. The same content is free over MCP at https://cuppy.io/mcp with no signup: ranked search across all 91 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/gcp/ Something wrong in this document? Report it with the `session feedback` tool on the same endpoint.