Get hands-on experience with 20+ free Google Cloud products and $300 in free credit for new customers.

Help Needed: Cloud SQL Auth Proxy Timeout (ECONNRESET) to Private IP - PostgreSQL

Hello Google Cloud Developers Community,

I'm encountering a persistent connectivity issue and would greatly appreciate any insights or suggestions from the community. I am trying to connect to my Cloud SQL PostgreSQL instance (instance name: ad-120-tlv-instance) via its Private IP address using the Cloud SQL Auth Proxy from my local Windows development machine. This is my first project on GCP, and I have not been able to establish a successful Private IP connection via the proxy since the initial setup, despite extensive troubleshooting.

Project Details:

Project ID: new-ad-120-project
Project Number: 574075281842
Cloud SQL Instance Details:

Instance Name: ad-120-tlv-instance
Instance Connection Name: new-ad-120-project:me-west1:ad-120-tlv-instance
Database Version: PostgreSQL 17
Region: me-west1 (Tel Aviv)
Zone: me-west1-c
Private IP Address: 10.85.160.3 (internally listens on port 3307)
Public IP: Disabled
Database Name (within instance): ad_120_ad
Application User in DB: ad_120_app_user
Secret Name for App User Password (in Secret Manager): ad-120-app-user-password
Date of Instance Creation & Network Configuration: The Cloud SQL instance and associated network configurations (Private IP, Private Services Access) were initially set up between May 19-23, 2025.
Problem Description:
When running the Cloud SQL Auth Proxy from my local Windows machine to connect to the instance ad-120-tlv-instance using its Private IP, the proxy successfully authenticates using a Service Account Key JSON file (specified with --credentials-file) and starts listening on 127.0.0.1:5432. The proxy log shows:
Authorizing with the credentials file at "C:\\DevTools\\cloud_sql_proxy\\ad-120-sa-key.json"
followed by:
Listening on 127.0.0.1:5432 and The proxy has started successfully and is ready for new connections!.

However, when my Node.js backend application (running locally) attempts to connect to the proxy at 127.0.0.1:5432, the proxy accepts the local connection (e.g., Accepted connection from 127.0.0.1:XXXXX) but then consistently fails to establish the onward connection to the Cloud SQL instance's Private IP. The proxy log shows the following error:
failed to connect to instance: dial error: failed to dial (connection name = "new-ad-120-project:me-west1:ad-120-tlv-instance"): dial tcp 10.85.160.3:3307: connectex: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.

As a result, my Node.js application (which successfully retrieves DB passwords from Secret Manager using Application Default Credentials with the GOOGLE_APPLICATION_CREDENTIALS environment variable set) receives an ECONNRESET error when trying to connect to the proxy.

Troubleshooting Steps Taken:

Verified Cloud SQL Instance Status: The instance ad-120-tlv-instance is "RUNNABLE" and appears healthy. No relevant errors were found in the instance's postgres.log during the connection attempts (only routine checkpoint messages).
Verified APIs Enabled: Confirmed enabled for project new-ad-120-project: Cloud SQL Admin API, Secret Manager API, IAM API, Cloud Resource Manager API, Service Networking API, Compute Engine API, Firebase Management API, Firebase Rules API, Identity Toolkit API.
Verified Private Services Access & VPC Network Peering: A "Private service connection" is configured for the default VPC network. An IP range (10.85.160.0/20) is allocated for servicenetworking-googleapis-com. The VPC network peering connection servicenetworking-googleapis-com status is "Active". The "Private path for Google Cloud services" option is enabled for the Cloud SQL instance.
Verified Firewall Rules: The default VPC network has the default-allow-internal firewall rule, allowing all ingress traffic from 10.128.0.0/9 (which includes the 10.85.160.0/20 PSA range) on all protocols and ports. No specific DENY rules appear to be blocking this internal traffic.
Verified IAM Permissions: My user account (....), used for gcloud auth application-default login for the Node.js application ADC, has the "Owner" role on the project. The Service Account (sql-proxy-runner@new-ad-120-project.iam.gserviceaccount.com), used with the --credentials-file flag for the proxy, has the "Cloud SQL Client" (roles/cloudsql.client) and "Service Usage Consumer" (roles/serviceusage.serviceUsageConsumer) roles.
Cloud SQL Auth Proxy Command Used (with Service Account Key): .\cloud_sql_proxy.exe --private-ip --debug --credentials-file="C:\DevTools\cloud_sql_proxy\ad-120-sa-key.json" new-ad-120-project:me-west1:ad-120-tlv-instance (Attempts with Application Default Credentials for the proxy also failed with the same dial tcp error).
Restarted Cloud SQL Instance: The instance was restarted, and sufficient time was allowed for network configurations to stabilize, but the issue persists.
VPC Flow Logs: Enabled on the default subnet in me-west1 (100% sampling, all metadata). Queries for dest_ip="10.85.160.3" and dest_port=3307 (and vice-versa for src_ip) yielded "No data found" for relevant timeframes during connection attempts. This suggests connection attempts might not be reaching a point where they are logged, or there's an issue with Flow Logs setup/ingestion.
Local Environment:

Operating System: Windows
Cloud SQL Auth Proxy Version: 2.16.0+windows.amd64
gcloud CLI version: Google Cloud SDK 522.0.0 (with the warning: You may be running gcloud with a python interpreter installed from Microsoft Store...)
Question for the Community / Request for Help:
I'm trying to understand why the Cloud SQL Auth Proxy, despite successful authentication, is unable to establish a TCP connection to the Private IP (10.85.160.3:3307) of my Cloud SQL instance. The configurations appear correct, IAM permissions are verified, and the instance itself is healthy. The lack of relevant VPC Flow Logs is also a concern.

Has anyone encountered similar issues or can offer insights or suggestions for further diagnosing the dial tcp ... timeout error? Are there common network issues, misconfigurations in Private Services Access, or instance-specific problems that I might be overlooking? Any guidance would be highly appreciated.

This technical issue is blocking my project's progress, and I'm eager to start utilizing the Cloud SQL service.

Thanks for any help,
Yakov

 

Solved Solved
0 2 121
1 ACCEPTED SOLUTION

The root of the connectivity issue is that the Cloud SQL Auth Proxy, running on your local Windows machine, cannot directly reach the private IP address of your Cloud SQL instance. A private IP is only accessible from within its specific VPC network on Google Cloud. Your local machine is outside this network.

The standard and most direct way to solve this is to run the Cloud SQL Auth Proxy on a resource inside your VPC network, and then securely connect to it.

  1. Create a GCE VM: In your project (new-ad-120-project), launch a small Compute Engine VM (e.g., e2-micro) in the same region (me-west1) and VPC network (default) as your Cloud SQL instance. This VM will act as your secure "jump box."

  2. Install the Proxy on the VM: Use SSH to connect to the new GCE VM and install the Cloud SQL Auth Proxy.

  3. Run the Proxy on the VM: On the GCE VM, start the proxy and configure it to listen for connections from your tunnel:


     
    ./cloud_sql_proxy --private-ip --address 0.0.0.0 new-ad-120-project:me-west1:ad-120-tlv-instance
    
    • Note: The --address 0.0.0.0 flag is critical. It allows the proxy to accept the forwarded connection from the SSH tunnel. Ensure your VM's firewall rules do not expose this port to the public internet.
  4. Create an SSH Tunnel: From your local Windows machine (using PowerShell or another terminal), run the following gcloud command to create a secure tunnel. This command forwards your local port 5432 to the proxy running on the GCE VM.


     
    gcloud compute ssh [YOUR_GCE_VM_NAME] --zone me-west1-c -- -L 5432:localhost:5432
    
  5. Connect Your Application: With the tunnel active, you can now run your local Node.js application. Connect it to 127.0.0.1:5432 as you originally intended. Your connection will be securely tunneled through the GCE VM, which has the necessary network access to your Cloud SQL instance's private IP.

View solution in original post

2 REPLIES 2

The root of the connectivity issue is that the Cloud SQL Auth Proxy, running on your local Windows machine, cannot directly reach the private IP address of your Cloud SQL instance. A private IP is only accessible from within its specific VPC network on Google Cloud. Your local machine is outside this network.

The standard and most direct way to solve this is to run the Cloud SQL Auth Proxy on a resource inside your VPC network, and then securely connect to it.

  1. Create a GCE VM: In your project (new-ad-120-project), launch a small Compute Engine VM (e.g., e2-micro) in the same region (me-west1) and VPC network (default) as your Cloud SQL instance. This VM will act as your secure "jump box."

  2. Install the Proxy on the VM: Use SSH to connect to the new GCE VM and install the Cloud SQL Auth Proxy.

  3. Run the Proxy on the VM: On the GCE VM, start the proxy and configure it to listen for connections from your tunnel:


     
    ./cloud_sql_proxy --private-ip --address 0.0.0.0 new-ad-120-project:me-west1:ad-120-tlv-instance
    
    • Note: The --address 0.0.0.0 flag is critical. It allows the proxy to accept the forwarded connection from the SSH tunnel. Ensure your VM's firewall rules do not expose this port to the public internet.
  4. Create an SSH Tunnel: From your local Windows machine (using PowerShell or another terminal), run the following gcloud command to create a secure tunnel. This command forwards your local port 5432 to the proxy running on the GCE VM.


     
    gcloud compute ssh [YOUR_GCE_VM_NAME] --zone me-west1-c -- -L 5432:localhost:5432
    
  5. Connect Your Application: With the tunnel active, you can now run your local Node.js application. Connect it to 127.0.0.1:5432 as you originally intended. Your connection will be securely tunneled through the GCE VM, which has the necessary network access to your Cloud SQL instance's private IP.

Huge thanks, @ms4446! Your detailed solution worked perfectly. Setting up the Cloud SQL Auth Proxy on a GCE VM in the same VPC and using an SSH tunnel from my local machine was exactly what I needed to resolve the private IP connectivity issue. I can now connect to my PostgreSQL instance. Really appreciate your clear guidance!