Console
Start free

Debug connection issues

Introduction

Generally, connection issues fall into one of the following three areas:

Each of those can be further broken down into different paths for investigation. The following section includes examples of questions you can ask yourself to help further narrow down the issue:

Connection issues checklist

Error messages

For specific API error messages, see the Error messages reference page.

Additional connectivity troubleshooting

For other issues, see the Connectivity section in the troubleshooting page.

Common connection issues

Verify that your application is closing connections properly

If you see errors containing "Aborted connection nnnn to db:", it usually indicates that your application is not stopping connections properly. Network issues can also cause this error. The error does not mean that there are problems with your Cloud SQL instance. You are also encouraged to run tcpdump to inspect the packets to track down the source of the problem.

For examples of best practices for connection management, see Managing database connections.

Verify that your certificates have not expired

If your instance is configured to use SSL, go to the Cloud SQL Instances page in the Google Cloud console and open the instance. Open its Connections page, select the Security tab and make sure that your server certificate is valid. If it has expired, you must add a new certificate and rotate to it.

Verify that you are authorized to connect

If your connections are failing, check that you are authorized to connect:

  • If you are having trouble connecting using an IP address, for example, you are connecting from your on-premises environment with the psql client, then make sure that the IP address you are connecting from is authorized to connect to the Cloud SQL instance.

    Connections to a Cloud SQL instance using a private IP address are automatically authorized for RFC 1918 address ranges. This way, all private clients can access the database without going through the Cloud SQL Auth Proxy. Non-RFC 1918 address ranges must be configured as authorized networks.

    Cloud SQL doesn't learn Non-RFC 1918 subnet routes from your VPC by default. You need to update the network peering to Cloud SQL to export any Non-RFC 1918 routes. For example: 

    gcloud compute networks peerings update cloudsql-postgres-googleapis-com \
--network=NETWORK \
--export-subnet-routes-with-public-ip \
--project=PROJECT_ID

    • Here's your current IP address.

  • Try the gcloud sql connect command to connect to your instance. This command authorizes your IP address for a short time. You can run this command in an environment with gcloud CLI and psql client installed. You can also run this command in Cloud Shell, which is available in the Google Cloud console and has gcloud CLI and the psql client pre-installed. Cloud Shell provides a Compute Engine instance that you can use to connect to Cloud SQL.
  • Temporarily allow all IP addresses to connect to an instance by authorizing 0.0.0.0/0.

    • Verify how you connect

    If you get an error message like:

    FATAL: database `user` does not exist.

    The gcloud sql connect --user command only works with the default user (postgres). The workaround is to connect using the default user, then use the "\c" psql command to reconnect as the different user.

    Determine how connections are being initiated

    You can see information about your current connections by connecting to your database and running the following command:

    SELECT * from pg_stat_activity ;

    Connections that show an IP address, such as 1.2.3.4, are connecting using IP. Connections with cloudsqlproxy~1.2.3.4 are using the Cloud SQL Auth Proxy, or else they originated from App Engine. Connections from localhost may be used by some internal Cloud SQL processes.

    Connection limits

    There are no QPS limits for Cloud SQL instances. However, there are connection, size, and App Engine specific limits in place. See Quotas and Limits.

    Database connections consume resources on the server and the connecting application. Always use good connection management practices to minimize your application's footprint and reduce the likelihood of exceeding Cloud SQL connection limits. For more information, see Managing database connections.

    Show connections and threads

    To see the processes that are running on your database, use the pg_stat_activity table:

    select * from pg_stat_activity;

    Connections timeout (from Compute Engine)

    Connections with a Compute Engine instance timeout after 10 minutes of inactivity, which can affect long-lived unused connections between your Compute Engine instance and your Cloud SQL instance. For more information, see Networking and Firewalls in the Compute Engine documentation.

    To keep long-lived unused connections alive, you can set the TCP keepalive. The following commands set the TCP keepalive value to one minute and make the configuration permanent across instance reboots.

    Display the current tcp_keepalive_time value.

    cat /proc/sys/net/ipv4/tcp_keepalive_time

    Set tcp_keepalive_time to 60 seconds and make it permanent across reboots.

    echo 'net.ipv4.tcp_keepalive_time = 60' | sudo tee -a /etc/sysctl.conf

    Apply the change.

    sudo /sbin/sysctl --load=/etc/sysctl.conf

    Display the tcp_keepalive_time value to verify the change was applied.

    cat /proc/sys/net/ipv4/tcp_keepalive_time

    Tools for debugging connectivity

    tcpdump

    The tcpdump is a tool to capture packets. It's highly encouraged to run tcpdump to capture and inspect the packets between your host and the Cloud SQL instances when you are debugging the connectivity problems.

    Locate your local IP address

    If you don't know the local address of your host, then run the ip -br address show command. On Linux, this shows the network interface, the status of the interface, the local IP, and MAC addresses. For example: eth0 UP 10.128.0.7/32 fe80::4001:aff:fe80:7/64.

    Alternatively, you can run ipconfig or ifconfig to see the status of your network interfaces.

    Test with Connectivity Test

    Connectivity Test is a diagnostics tool that lets you check connectivity between endpoints in your network. It analyzes your configuration and in some cases performs run-time verification. It supports Cloud SQL now. Follow these instructions to run tests with your Cloud SQL instances.

    Test your connection

    You can use the psql client to test your ability to connect from your local environment. For more information, see Connecting the psql client using IP addresses and Connecting the psql client using the Cloud SQL Auth Proxy.

    Determine the IP address for your application

    To determine the IP address of a computer running your application so you can authorize access to your Cloud SQL instance from that address, use one of the following options:

    Open local ports

    To verify that your host is listening on the ports you think it is, run the ss -tunlp4 command. This tells you what ports are open and listening. For example, if you have a PostgreSQL database running, then port 5432 should be up and listening. For SSH, you should see port 22.

    All local port activity

    Use the netstat command to see all the local port activity. For example, netstat -lt shows all the currently active ports.

    Connect to your Cloud SQL instance using telnet

    To verify that you can connect to your Cloud SQL instance using TCP, run the telnet command. Telnet attempts to connect to the IP address and port you give it.

    If your Cloud SQL instance is running a PostgreSQL database, for example, then you should be able to telnet to it on port 5432: telnet 35.193.198.159 5432. On success, you see the following:

    Trying 35.193.198.159...

    Connected to 35.193.198.159. .

    On failure, you see telnet hangs until you force-close the attempt:

    Trying 35.193.198.159...

    ^C. .

    Client authentication

    Client authentication is controlled by a configuration file, which is named pg_hba.conf (HBA stands for host-based authentication).

    Make sure the replication connections section of the pg_hba.conf file on the source database is updated to accept connections from the Cloud SQL VPC's IP address range.

    Cloud Logging

    Cloud SQL and Cloud SQL use Cloud Logging. See the Cloud Logging documentation for complete information and review the Cloud SQL sample queries.

    View logs

    You can view logs for Cloud SQL instances and other Google Cloud projects such as Cloud VPN or Compute Engine instances. To view logs for your Cloud SQL instance log entries:

    Console

    1. In the Google Cloud console, go to the Cloud Logging page.

      Go to Cloud Logging

    2. Select an existing Cloud SQL project at the top of the page.
    3. In the Query builder, add the following:
      • Resource: Select Cloud SQL Database. In the dialog, select a Cloud SQL instance.
      • Log names: Scroll to the Cloud SQL section and select appropriate log files for your instance. For example:
        • cloudsql.googleapis.com/postgres.log
      • Severity: Select a log level.
      • Time range: Select a preset or create a custom range.

    gcloud

    Use the gcloud logging command to view log entries. In the example below, replace PROJECT_ID. The limit flag is an optional parameter that indicates the maximum number of entries to return.

    gcloud logging read "projects/PROJECT_ID/logs/cloudsql.googleapis.com/postgres.log" \
--limit=10

    Private IP addresses

    Connections to a Cloud SQL instance using a private IP address are automatically authorized for RFC 1918 address ranges. Non-RFC 1918 address ranges must be configured in Cloud SQL as authorized networks. You also need to update the network peering to Cloud SQL to export any Non-RFC 1918 routes. For example: 

    gcloud compute networks peerings update cloudsql-postgres-googleapis-com 
    
--network=NETWORK 
    
--export-subnet-routes-with-public-ip 
    
--project=PROJECT_ID

    VPN troubleshooting

    See the Cloud VPN troubleshooting page.