הבנתי — הנה הדיווח מנוקה, כולו באנגלית, מוכן לפתיחת thread חדש: --- **Project ID:** `f1de28b3-7808-4fd9-bb61-d34bb6a6da01` **Service:** Postgres (`6483e74a-786f-4da5-bdce-dd317a13afa0`), environment: `production` **Issue:** The TCP Proxy feature against our Postgres service is not working. The database itself is healthy — another service in the same project (`api`) connects to it fine over Railway's internal network the entire time — but the public TCP proxy fails to actually reach it from outside. **What we tried (all failed the same way):** 1. Created a TCP proxy — raw TCP connect sometimes succeeds, sometimes returns `ECONNRESET` immediately. 2. Even when the raw TCP connect succeeds, any real Postgres protocol client (tested with Prisma's CLI) times out completing the handshake, failing with `P1001: Can't reach database server`. 3. Deleted and recreated the proxy multiple times (different proxy IDs, ports, and domains each time) — same behavior every time. 4. Ran `railway restart --service Postgres` to restart the database service itself — the command hung for several minutes with no output before completing, and the issue persisted afterward. 5. Ruled out a client-side/network problem: general internet connectivity is fine, and other Railway CLI calls (`railway status`, `railway variables`) to Railway's API work normally throughout. **Impact:** Low for the live app (unaffected, since it uses the internal network). This only blocks running a one-off `prisma migrate deploy` against production from outside the platform. **Ask:** Could you check the TCP proxy routing/health for this Postgres service, or advise an alternative way to reach it externally?

hi - Railway Central Station

igproject-tal

PROOP

25 days ago

הבנתי — הנה הדיווח מנוקה, כולו באנגלית, מוכן לפתיחת thread חדש:

Project ID: f1de28b3-7808-4fd9-bb61-d34bb6a6da01

Service: Postgres (6483e74a-786f-4da5-bdce-dd317a13afa0), environment: production

Issue: The TCP Proxy feature against our Postgres service is not working. The database itself is healthy — another service in the same project (api) connects to it fine over Railway's internal network the entire time — but the public TCP proxy fails to actually reach it from outside.

What we tried (all failed the same way):

Created a TCP proxy — raw TCP connect sometimes succeeds, sometimes returns ECONNRESET immediately.
Even when the raw TCP connect succeeds, any real Postgres protocol client (tested with Prisma's CLI) times out completing the handshake, failing with P1001: Can't reach database server.
Deleted and recreated the proxy multiple times (different proxy IDs, ports, and domains each time) — same behavior every time.
Ran railway restart --service Postgres to restart the database service itself — the command hung for several minutes with no output before completing, and the issue persisted afterward.
Ruled out a client-side/network problem: general internet connectivity is fine, and other Railway CLI calls (railway status, railway variables) to Railway's API work normally throughout.

Impact: Low for the live app (unaffected, since it uses the internal network). This only blocks running a one-off prisma migrate deploy against production from outside the platform.

Ask: Could you check the TCP proxy routing/health for this Postgres service, or advise an alternative way to reach it externally?

$10 Bounty

2 Replies

Railway

BOT

25 days ago

This thread has been opened as a bounty so the community can help solve it.

Status changed to Open Railway • 25 days ago

zidaan11223344-coder

FREE

25 days ago

Hi! I’d like to help troubleshoot this issue.

Based on the symptoms you described, the PostgreSQL service itself appears healthy because the internal Railway connection works, while the public TCP Proxy is intermittently returning ECONNRESET.

Could you please run the following tests?

Test a normal SSH connection:

railway connect Postgres --ssh

Please confirm whether this connects successfully and consistently.

Test the SSH tunnel separately:

railway connect Postgres --tunnel-only --port 15432

Keep the tunnel running, then from another terminal try connecting through the local port:

psql "postgresql://USER:PASSWORD@127.0.0.1:15432/railway"

If the SSH connection succeeds but the tunnel fails with:

channel 1: open failed: unknown channel type: unsupported

or:

ECONNRESET

please share the exact output.

Also, could you confirm whether the Postgres service has more than one replica?

If possible, please also provide:

the Railway CLI version
the approximate frequency of successful vs failed TCP Proxy connections
whether the failures happen from the same client/network or from multiple networks

These tests should help determine whether the problem is specifically with the public TCP Proxy path or with SSH TCP forwarding.

larrybol

PRO

an hour ago

Since the internal network is healthy, your Postgres is fine — this is the public TCP proxy path being flaky, which is a known Railway weak spot.

Confirm it's the proxy, not Prisma: psql with the public URL from your machine. If it also drops intermittently, it's the route.
Add timeouts and retries to Prisma: append ?connect_timeout=10&pool_timeout=20 to the datasource URL, and run prisma migrate deploy in a loop with 2-3 retries and a sleep between them.
Run migrations from inside Railway instead of over the proxy: a one-off railway run shell or a small job service in the same project using the private/internal database URL doesn't touch the public proxy at all.
If the proxy keeps resetting, delete and re-create the TCP proxy on the Postgres service (Service → Settings → Networking → TCP Proxy). A fresh proxy gets a new edge route and has fixed persistent ECONNRESET for others.
Still broken after a fresh proxy? That's platform-side — post your region and the proxy hostname and Railway staff can check the edge route.

Welcome!