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:
Service Networking API for your project?Cloud SQL Admin API for your project?access denied errors?cloudsql.iam_authentication flag on your instance?-enable_iam_login or an Oauth 2.0 token as the database password?For specific API error messages, see the Error messages reference page.
For other issues, see the Connectivity section in the troubleshooting page.
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.
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.
If your connections are failing, check that you are authorized to connect:
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-mysql-googleapis-com \ --network=NETWORK \ --export-subnet-routes-with-public-ip \ --project=PROJECT_ID
Here's your current IP address.
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 mysql 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 mysql client pre-installed.
Cloud Shell provides a Compute Engine instance that you can use
to connect to Cloud SQL.
0.0.0.0/0 (for IPv6, authorize ::/0.
ERROR 1045 (28000): Access denied for user 'root'@'1.2.3.4' (using password: NO)
when you connect, verify that you are providing a password.
If you get an error message like:
ERROR 1045 (28000): Access denied for user 'root'@'1.2.3.4' (using password: YES)
when you connect, verify that you are using the correct password and that you are connecting over SSL if the instance requires it.
You can see information about your current connections by connecting to your database and running the following command:
SHOW PROCESSLIST;
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.
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.
If you get the "too many connections" error message, or want to find out what is
happening on an instance, you can show the number of connections and threads
with SHOW PROCESSLIST.
From a MySQL client, run:
mysql> SHOW PROCESSLIST;
You get output similar to the following:
+----+-----------+--------------+-----------+---------+------+-------+----------------------+ | Id | User | Host | db | Command | Time | State | Info | +----+-----------+--------------+-----------+---------+------+-------+----------------------+ | 3 | user-name | client-IP | NULL | Query | 0 | NULL | SHOW processlist | | 5 | user-name | client-IP | guestbook | Sleep | 1 | | SELECT * from titles | | 17 | user-name | client-IP | employees | Query | 0 | NULL | SHOW processlist | +----+-----------+--------------+-----------+---------+------+-------+----------------------+ 3 rows in set (0.09 sec)
For information about how to interpret the columns returned from
PROCESSLIST, see the MySQL reference.
To get a thread count, you can use:
mysql> SHOW STATUS WHERE Variable_name = 'Threads_connected';
You get output similar to the following:
+-------------------+-------+ | Variable_name | Value | +-------------------+-------+ | Threads_connected | 7 | +-------------------+-------+ 1 row in set (0.08 sec)
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_timeSet 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_timeIf you get either of the error messages
Can't connect to MySQL server on '2001:1234::4321' (10051) Can't connect to MySQL server on '2001:1234::4321' (101)
when you connect it is likely that you are attempting to connect to the IPv6 address of your instance but do not have IPv6 available on your workstation. You can verify whether IPv6 is functional on your workstation by going to ipv6.google.com. If it does not load then you do not have IPv6 available. Connect to the IPv4 address or your Cloud SQL instance instead. You may need to add an IPv4 address to your instance first.
When Cloud SQL restarts an instance due to maintenance events, connections might be routed to the failover replica. When connecting to the failover replica:
After the event is over, Cloud SQL resets the connection. Retry the connection. We recommend that you design your applications to handle occasional connection failures by implementing an error handling strategy like exponential backoff. See Application implementation for more information.
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.
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.
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.
You can use the mysql client to test your ability to connect from your local environment. For more information, see Connecting the mysql client using IP addresses and Connecting the mysql client using the Cloud SQL Auth Proxy.
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:
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 MySQL database running, then port 3306 should be up and
listening. For SSH, you should see port 22.
Use the netstat command to see all the local port activity. For
example, netstat -lt shows all the currently active ports.
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.
telnet 35.193.198.159 3306.
On success, you see the following:
Trying 35.193.198.159...
Connected to 35.193.198.159. .
On failure, you seetelnet hangs until you force-close the attempt:
Trying 35.193.198.159...
^C. .
Cloud SQL and Cloud SQL use Cloud Logging. See the Cloud Logging documentation for complete information and review the Cloud SQL sample queries.
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:
In the Google Cloud console, go to the Cloud Logging page.
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/mysql-general.log" \ --limit=10
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-mysql-googleapis-com
--network=NETWORK
--export-subnet-routes-with-public-ip
--project=PROJECT_ID
See the Cloud VPN troubleshooting page.
Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 4.0 License, and code samples are licensed under the Apache 2.0 License. For details, see the Google Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.
Last updated 2026-07-22 UTC.