What you see
$ cloud-sql-proxy project:europe-west1:db Listening on 127.0.0.1:5432 The proxy has started successfully $ psql -h 127.0.0.1 -p 5432 connection refused
The proxy is running. The connection is refused. Both are true.
This is the most common confusion around the Cloud SQL Auth Proxy: it announces that it is listening before it is genuinely ready, and it keeps running after authentication has failed. Here are the causes, in the order you should check them, most frequent first.
macOS 11+ · Windows soon
What you read, what is happening
Two messages that are not about the same thing.
The proxy says it is ready to receive. It does not say it can reach the instance.
What it means
“Listening” = the local port is open · nothing more The instance may be unreachable The token may have expired The API may be disabled The proxy runs regardless.
The five causes
In the order to check them.
| The cause | How to spot it | The command that settles it |
|---|---|---|
| Missing or stale credentials | the proxy starts, then logs an authentication error | gcloud auth application-default login |
| Wrong active project | the instance “does not exist” although it does | gcloud config get-value project |
| Cloud SQL Admin API disabled | 403 error in the proxy log | gcloud services enable sqladmin.googleapis.com |
| Missing role | authenticated, but refused on the instance | the account needs roles/cloudsql.client |
| Too early | refused for a second, then it works | wait for the port to actually answer, not for the proxy to say so |
From the Cloud SQL Auth Proxy documentation and gcloud error messages. Recorded on 7 August 2026.
What stays true afterwards
Four things you redo every time.
Once the cause is found, the command works. The next day, it starts over.
The full instance name
project:region:instance, three segments nobody memorises and everyone looks up in the console every time. Kestro discovers them from your gcloud credentials and offers them in a list.
The port that stays taken
A proxy that closed badly keeps 5432, and the next one fails with a message that says nothing about it. Kestro tells you a port is already taken before trying to open it.
The token that expires
Application default credentials have a lifetime. The proxy keeps running past their expiry, and the connection stops without anything announcing it.
One more terminal
The proxy occupies a window to show nothing useful most of the time, and it is the one you close by mistake when tidying your desktop.
On your machine
Everything stays with you.
Your connections run from your computer to your servers, never through us.
No account
Nothing to create, no password.
Your keys stay put
SSH, Google Cloud, AWS: Kestro uses your own tools, locally.
No usage statistics
We don’t know what you open, or when.
One exception
Your licence renews with us. Nothing else leaves.
When the command is enough
Three cases where you need nothing more.
The official proxy is a good tool, and it is free.
In CI, or on a server
The proxy is built for that: one process, one service account, no interface. Kestro has no business there and does not pretend otherwise.
One database, once a month
If you open it rarely, the command is quick to retype and shell history finds it. The gain does not justify a purchase.
On Linux, or on Windows today
Kestro only runs on macOS; the Windows version is in progress. The proxy runs everywhere.
Pricing
You pay once. That’s it.
A tool you open forty times a day shouldn’t send an invoice every month.
Kestro licence
€29.99$29.99£25.99CHF 25.90CA$40.99A$45.99€39.99$39.99£34.99CHF 33.90CA$54.99A$61.99 · Launch offer · upcoming price
1 computer · one-time
- Every feature of the app, no tiers, no “Pro” edition
- One year of updates included, then renew if you want to
- The app stays yours, renewed or not
- One key, the same on all your computers
- Switch machines whenever you like, no limit
- No account to create: the key arrives by email
Or download it for free first →
Refunded within 14 days, no questions asked.
Questions we get asked
Why does the proxy say “started successfully” when it does not work?
Because the two statements are about different things. “Listening” means the local port is open and the proxy accepts connections; it says nothing about its ability to reach the instance behind it, which depends on your credentials, the active project, the API and your roles. The proxy discovers those problems on the first client, not at startup.
Is it gcloud auth login or application-default login?
The second. gcloud auth login authenticates the gcloud command itself; the proxy looks for “application default credentials”, which only gcloud auth application-default login writes. It is the most common mistake, and the most confusing, because you are authenticated: just not in the way the proxy asks for.
How do I know the port is really ready?
By trying to connect to it, not by reading the log. A short nc -z 127.0.0.1 5432 loop settles it; that is exactly what Kestro does before showing a tunnel as open.
Does Kestro replace the proxy?
No, it launches it. That is Google’s official binary, with your gcloud credentials, in a real terminal. Kestro composes the command, discovers the instances, checks that the port answers and reopens the tunnel when the machine wakes: the plumbing stays Google’s.