[Python] Google Cloud Run: "No route to host" error for internet persists across multiple...

I'm trying to deploy a Python/FastAPI backend service on Google Cloud Run (Project ID: autolearnai-side-a, Project Number: 190291710544, Service: autolearnai-backend-api). The goal is for the service to access Google's public APIs (such as Cloud Storage and Gemini API) and eventually a Cloud SQL instance with a private IP.

The fundamental problem I'm facing is that the Cloud Run container is unable to establish outbound connectivity to the public internet. A simple test at the start of my application (flows.py) using urllib.request.urlopen("https://www.google.com", timeout=15) consistently fails with the error: OSError: [Errno 113] No route to host (or urllib.error.URLError: <urlopen error [Errno 113] No route to host>).

This error occurs:

In the southamerica-east1 region.

Crucially, it also occurs when the service is deployed in the us-central1 region. It occurs even when the Cloud Run service is NOT configured with Direct VPC Egress (i.e. without the --vpc-egress and --network flags, using Google's default egress to the internet). The application is built with Docker using a Python base image and contains FastAPI served by Uvicorn. The connectivity error prevents essential components that rely on internet access (such as the Google Cloud Storage client) from starting.

We performed extensive debugging to isolate the cause of this "No route to host" error:

Initial Configuration and Code:

Fixed initial errors in the application code (IndentationError). Added verbose logging and an explicit internet connectivity test at the beginning of the service startup. Project and Account Level Checks:

Confirmed that the autolearnai-lado-a project does not belong to a Google Cloud Organization (it is a personal project). Confirmed that there are no active VPC Service Controls Perimeters for the project. All essential APIs (Cloud Run Admin, Compute Engine, Artifact Registry, Cloud Storage, Cloud SQL Admin, IAM, Logging, Monitoring, Service Networking) have been verified and are ON. Billing is active, the account is paid (after upgrading from Free Trial) and has credits. There are no billing integrity issues. The quotas for Cloud Run, Compute Engine, and Networking in the southamerica-east1 region have been verified and are not exhausted. The default subnet in the southamerica-east1 region is configured as stackType: IPV4_ONLY and privateIpv6GoogleAccess: DISABLE_GOOGLE_ACCESS, ruling out issues with incomplete IPv6 configuration. Default VPC Network Settings (although the error persists even without using the VPC for egress):

Routes: The default route to the internet (0.0.0.0/0 via Default Internet Gateway with priority 1000) has been confirmed as existing and correct. Cloud NAT: Confirmed that it is NOT CONFIGURED. Egress Firewall: A rule named allow-egress-https-internet was created with: Direction: Egress Action: Allow Priority: 1000 Targets: "All instances on the network" Source IP Filter: 10.158.0.0/20 (the CIDR of the default subnet in southamerica-east1) Destination IP Filters: 0.0.0.0/0 Protocols and Ports: tcp:443 Status: Enabled It was reported that this is the only Egress firewall rule configured. Temporarily, this rule was also tested with "Allow all" protocols and ports, without changing the result of the "No route to host" error in the tests without VPC Egress. Cloud Run Deployment Tests:

With Direct VPC Egress (for southamerica-east1): "No route to host" error was observed.

WITHOUT Direct VPC Egress (for southamerica-east1, revision autolearnai-backend-api-00012-45s): "No route to host" error persisted.

WITHOUT Direct VPC Egress (for us-central1, revision autolearnai-backend-api-00001-wgg or the latest autolearnai-backend-api-00013-lxk): "No route to host" error also persisted. Logs for revision autolearnai-backend-api-00013-lxk (referring to file downloaded-logs-20250515-175444.json) confirm the connectivity test to https://www.google.com failed with OSError: [Errno 113] No route to host. What I expected to happen: I expected that by removing the Direct VPC Egress configuration, the Cloud Run service would use Google's default network infrastructure and be able to access the public internet, causing the urllib.request.urlopen("https://www.google.com", timeout=15) test to succeed. This did not happen, even when testing in a different region (us-central1).

Given that the common network configurations and project/organization level policies seem to be correct or not applicable (such as Organization and VPC Service Controls), I am trying to understand what the remaining causes could be for this fundamental blockage of outbound internet connectivity for Cloud Run in my project and how I can diagnose and resolve this.

Continue reading...