We've looked into this from our side and haven't found anything on the Railway platform that explains what you're seeing, so working it out means digging into your specific setup.

That's exactly what the Railway community is good at, so we'd like to open your thread as a community bounty. Railway pays a bounty to the community member who solves it, and threads like this usually get picked up quickly.

Opening it makes this entire thread public, including everything already posted. Nothing becomes public until you decide. Use the buttons below.

• Open to the community - Before you click, take a moment to edit or remove anything you'd rather not share. The thread becomes publicly visible right away.
• Keep it private and close the thread - Nothing becomes public and the thread closes.

Hi Railway team,

Thanks for checking. I still need help with this because the issue remains reproducible and is specifically isolated to the public PostgreSQL proxy path.

Our application continues to connect to the same PostgreSQL service successfully over Railway private networking, while connections through the public proxy are intermittent. Simple queries sometimes succeed, but representative read-only catalog sessions consistently fail or stall.

If there are any specific diagnostics you would like us to run to help isolate the public proxy/session-establishment issue, please let us know and we can provide the results.

We would also appreciate guidance on whether regenerating/reprovisioning the public proxy is recommended, or whether Railway provides another officially supported operator-side method for database migrations that does not rely on the public TCP proxy.

Thanks,

Rohit

We still haven't found anything on the Railway side behind this, so the community is the best next step. The buttons below are still live: open the thread up as a public bounty after editing out anything sensitive, or keep it private and close it.

Hi Railway team,

We have one additional reproducible data point that may help narrow this down.

We tested Railway CLI’s documented SSH tunnel path using railway connect --tunnel-only against the same staging Postgres service. The CLI successfully binds a local listener and SSH authentication succeeds, but the Railway SSH endpoint refuses the forwarding channel with:

channel 1: open failed: unknown channel type: unsupported

Every connection through the local tunnel is then closed immediately. This happened 3/3 times and is distinct from the intermittent public TCP proxy issue.

So currently both documented operator access paths are unusable:

• Public TCP proxy: intermittent; simple queries sometimes succeed, representative catalog sessions fail/stall.
• Railway SSH tunnel: authenticates, but the server refuses the TCP forwarding channel.

The PostgreSQL service itself remains healthy and our application continues to connect successfully over Railway private networking.

Could you please confirm:

1. Whether direct-tcpip forwarding is expected to be supported for this Postgres service with railway connect --tunnel-only.
2. Whether anything needs to be enabled on the Railway side for tunnel forwarding.
3. Whether this service’s public proxy or SSH endpoint should be reprovisioned/regenerated.
4. Whether there is another officially supported operator-side database migration path for this setup.

We have not changed Railway networking, credentials, or the database while investigating.

Thanks,

Rohit

We still haven't found anything on the Railway side behind this, so the community is the best next step. The buttons below are still live: open the thread up as a public bounty after editing out anything sensitive, or keep it private and close it.

the command railway connect postgres --tunnel-only will:

force the use of SSH

open a local tunnel

use external tools such as pgAdmin, DBeaver, and TablePlus

and should work even if the database does not have a public TCP proxy.

Therefore, the OP's encounter with:

channel 1: open failed: unknown channel type: unsupported

is not normal behavior. According to the official documentation, direct-tcpip forwarding should be part of this functionality.

The OP's database has always worked correctly through Railway private networking, so the database itself is unlikely to be the root cause.

"Migrating methods that don't rely on public proxies":

Railway officially recommends running database migrations using Pre-Deploy Commands.

Pre-deploy commands execute internally within Railway and have access to private network and application environment variables, making them ideal for migrations like Prisma, Drizzle, Django, and Alembic.