19 days ago
I have a PostgreSQL database on Railway with public TCP proxy disabled for security reasons. I'm trying to connect to it locally from my Windows machine using the Railway CLI without exposing the database publicly.
When I run:
railway connect Postgres --tunnel-only
I get the error:
Connection URL should point to the Railway TCP proxy
According to the Railway documentation (https://docs.railway.com/cli/connect), the --tunnel-only flag should create a local SSH tunnel without requiring a public TCP proxy. However, this flag doesn't seem to be working on my version of the Railway CLI.
My setup:
- OS: Windows 11
- Railway CLI version: v5.57.12+ (latest)
- Database: PostgreSQL (private, no public TCP proxy)
What I've tried:
-
railway connect Postgres→ requires public TCP proxy -
railway connect Postgres --tunnel-only→ "Connection URL should point to the Railway TCP proxy" -
Updated to latest CLI version
What I need:
A way to create a local tunnel to my private database using the Railway CLI without enabling public TCP proxy, ideally for use with DBeaver or other database clients.
Is there an alternative command or solution available?
10 Replies
Status changed to Awaiting Railway Response Railway • 19 days ago
19 days ago
This thread has been opened as a bounty so the community can help solve it.
Status changed to Open Railway • 19 days ago
j53466946-boop
check your coding well
18 days ago
Did you read my question?
18 days ago
I can't reproduce the problem, Tested on Windows, CLI v5.58.0 (latest)
What happen when you run the command?
Attachments
mayori
I can't reproduce the problem, Tested on Windows, CLI v5.58.0 (latest) What happen when you run the command? 
18 days ago
I receive just this
Attachments
alsytimestech
I receive just this 
18 days ago
Try add the --ssh flag explicitly in the command
mayori
Try add the `--ssh` flag explicitly in the command
18 days ago
Same error
Attachments
17 days ago
I had a look through the current Railway CLI code because that error seemed a bit weird with --tunnel-only.
From what I can tell, --tunnel-only is supposed to use the SSH path and shouldn't need a public TCP proxy.
The confusing part is that the CLI can still throw:
Connection URL should point to the Railway TCP proxy
even while it's going through the tunnel code. The tunnel path reads the private DATABASE_URL, parses it, and rewrites the host to 127.0.0.1. If that parsing fails, it seems to end up using the same generic error message, so the message might be sending you in the wrong direction.
As a workaround I'd try bypassing railway connect and make the SSH tunnel directly.
First:
railway ssh config --service Postgres --alias railway-postgresYou can also check what it's going to generate first with:
railway ssh config --service Postgres --alias railway-postgres --dry-runThen:
ssh -N -L 15432:127.0.0.1:5432 railway-postgresKeep that terminal open and point DBeaver/pgAdmin at:
Host: 127.0.0.1
Port: 15432
Database: your PGDATABASE value
Username: your PGUSER value
Password: your PGPASSWORD valueThat shouldn't require enabling the Postgres TCP proxy at all.
If the manual SSH tunnel works, then I'd suspect the problem is specifically in how railway connect --tunnel-only is handling/parsing the private database URL rather than Railway requiring a public proxy.
bl4ckph4ntom1
I had a look through the current Railway CLI code because that error seemed a bit weird with `--tunnel-only`. From what I can tell, `--tunnel-only` is supposed to use the SSH path and shouldn't need a public TCP proxy. The confusing part is that the CLI can still throw: `Connection URL should point to the Railway TCP proxy` even while it's going through the tunnel code. The tunnel path reads the private `DATABASE_URL`, parses it, and rewrites the host to `127.0.0.1`. If that parsing fails, it seems to end up using the same generic error message, so the message might be sending you in the wrong direction. As a workaround I'd try bypassing `railway connect` and make the SSH tunnel directly. First: ```powershell railway ssh config --service Postgres --alias railway-postgres ``` You can also check what it's going to generate first with: ```powershell railway ssh config --service Postgres --alias railway-postgres --dry-run ``` Then: ```powershell ssh -N -L 15432:127.0.0.1:5432 railway-postgres ``` Keep that terminal open and point DBeaver/pgAdmin at: ```text Host: 127.0.0.1 Port: 15432 Database: your PGDATABASE value Username: your PGUSER value Password: your PGPASSWORD value ``` That shouldn't require enabling the Postgres TCP proxy at all. If the manual SSH tunnel works, then I'd suspect the problem is specifically in how `railway connect --tunnel-only` is handling/parsing the private database URL rather than Railway requiring a public proxy.
17 days ago
It worked, but with a little adjustment
When I send the command ssh -N -L 15432:127.0.0.1:5432 railway-postgres I receive this error:
lipe_@Liipe MINGW64 ~
$ ssh -N -L 15432:127.0.0.1:5432 railway-postgres
channel 2: open failed: connect failed: port forwarding rides your dev.new session: run ssh -L ... dev.new with a shell or command, not -N
Connection to ssh.railway.com closed by remote host.
So I removed the -N flag, and because I didn't have SSH Key configured in my Railway Account, the CLI generated a url link to I configure a new one, after that I was in the machine by the ssh command.
So I opened Dbeaver and configured a new connection with:
Host: 127.0.0.1
Port: 15432
Database: your PGDATABASE value
Username: your PGUSER value
Password: your PGPASSWORD value
And It worked!!
After a Ctrl + C on my terminal, the connection ended
Thank you so much bl4ckph4ntom1
17 days ago
Glad the manual SSH tunnel got you unblocked. For the record, since bl4ckph4ntom1's suspicion about the error message was exactly right — I checked the actual CLI source and can confirm the mechanism precisely.
--tunnel-only does correctly route to its own dedicated code path (it's not silently falling through to the public-proxy logic). But that path calls a shared helper that parses your database's connection URL and rewrites it to point at the local tunnel — and that helper raises the exact same "Connection URL should point to the Railway TCP proxy" error on ANY parsing or host-rewrite failure, not specifically on "this isn't a TCP proxy." The message is reused generically across several distinct failure modes in that function, which is what made it point in the wrong direction here.
So bl4ckph4ntom1 was right that this is a message-generation issue in the tunnel path, not an actual proxy requirement — the error text just doesn't distinguish "your URL isn't a proxy" from "I couldn't parse/rewrite your URL" even though those are very different problems. Worth flagging to the Railway team as a CLI error-message improvement so future users on this exact wording aren't misdirected the same way.
