2 months ago
Postgres WebSocket tunnel failed to connect (wss://ssh.railway.com:2226/ws/tcpip)
The sidebar agent said:
"This looks like a Railway platform issue with the database connection tunnel. Let me check your Postgres service configuration and status:
Fetched service config
I can't open a support thread automatically right now, but you'll need to reach out to Railway support for this. The WebSocket tunnel error is a platform-level issue that requires Railway's infrastructure team to investigate.
In the meantime, you can still access your database:
- From your (project) application using the DATABASE_URL environment variable (it's set and available)
- Via a database client (psql, DBeaver, TablePlus) using the TCP proxy public connection details from your Railway dashboard
Your data is safe — the issue is only with the SSH tunnel connection in the web interface."
Deploy Logs:
Mounting volume on: /var/lib/containers/railwayapp/bind-mounts/b3c1a848-4808-47c2-827d-a07a23134670/vol_efn5im1umql3p4b7
Starting Container
wrapper: removing stale /var/lib/postgresql/data/pgdata/postmaster.pid (no postgres running at container start)
Certificate will not expire
pgbackrest: volume 46626 MiB; sized wal-drop= MiB queue-max=5120 MiB
pgbackrest: restore-gate WAL_RECOVER_FROM_BUCKET= POSTGRES_RECOVERY_TARGET_TIME= PG_VERSION=present PG_CONTROL=present RESTORED_MARKER=missing PGDATA=/var/lib/postgresql/data/pgdata
PostgreSQL Database directory appears to contain a database; Skipping initialization
2026-07-28 16:26:39.464 UTC [18] LOG: starting PostgreSQL 18.4 (Debian 18.4-1.pgdg13+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 14.2.0-19) 14.2.0, 64-bit
2026-07-28 16:26:39.464 UTC [18] LOG: listening on IPv4 address "0.0.0.0", port 5432
2026-07-28 16:26:39.464 UTC [18] LOG: listening on IPv6 address "::", port 5432
2026-07-28 16:26:39.498 UTC [18] LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
2026-07-28 16:26:39.524 UTC [50] LOG: database system was interrupted; last known up at 2026-07-27 15:09:38 UTC
2026-07-28 16:26:39.992 UTC [50] LOG: database system was not properly shut down; automatic recovery in progress
2026-07-28 16:26:40.015 UTC [50] LOG: redo starts at 0/3ACFAA8
2026-07-28 16:26:40.015 UTC [50] LOG: invalid record length at 0/3ACFBB0: expected at least 24, got 0
2026-07-28 16:26:40.015 UTC [50] LOG: redo done at 0/3ACFB78 system usage: CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s
2026-07-28 16:26:40.033 UTC [48] LOG: checkpoint starting: end-of-recovery immediate wait
2026-07-28 16:26:40.116 UTC [48] LOG: checkpoint complete: wrote 0 buffers (0.0%), wrote 3 SLRU buffers; 0 WAL file(s) added, 0 removed, 0 recycled; write=0.014 s, sync=0.006 s, total=0.090 s; sync files=2, longest=0.003 s, average=0.003 s; distance=0 kB, estimate=0 kB; lsn=0/3ACFBB0, redo lsn=0/3ACFBB0
2026-07-28 16:26:40.127 UTC [18] LOG: database system is ready to accept connections
collation-refresh: psql: error: /tmp/collation-refresh.0OoBhB.sql: Permission denied
2026-07-28 16:37:48.541 UTC [83] LOG: could not accept SSL connection: unexpected eof while reading
2026-07-28 16:38:05.399 UTC [85] LOG: could not accept SSL connection: unexpected eof while reading
Attachments
5 Replies
2 months ago
This thread has been opened as a bounty so the community can help solve it.
Status changed to Open Railway • 2 months ago
2 months ago
Have you tried redeploying the postgres service? It usually fixes this issue. Try to do it by clicking on the service, then press CTRL + K, then select redeploy source image.
darseen
Have you tried redeploying the postgres service? It usually fixes this issue. Try to do it by clicking on the service, then press CTRL + K, then select **redeploy source image**.
2 months ago
Yes, I've tried the hard refresh (CTRL + K) and redeploying the database (both 'remove' and 'redeploy'). Regrettably, neither of those fixed the issue.
2 months ago
-
Temporarily change the deployment Region (e.g., from US West to US East) OR temporarily increase the Resource Limits (CPU/RAM).
-
Trigger a new deployment after that.
If it still doesn't connect, completely disable Brave Shields, uBlock Origin, or VPNs/firewalls for railway.com.
msns-dev
1. Temporarily change the deployment Region (e.g., from US West to US East) OR temporarily increase the Resource Limits (CPU/RAM). 2. Trigger a new deployment after that. If it still doesn't connect, completely disable Brave Shields, uBlock Origin, or VPNs/firewalls for railway.com.
2 months ago
Changed from US West >> US East and redeployed to no avail. Also was already at max CPU limits for my account. I'm not able to make firewall changes in my department, so can't test your second option. Thank you for the input though!
awitmer-suhsd
Changed from US West >> US East and redeployed to no avail. Also was already at max CPU limits for my account. I'm not able to make firewall changes in my department, so can't test your second option. Thank you for the input though!
2 months ago
your network is blocking outbound traffic to port 2225, which the Railway dashboard requires for its internal data tunnel.
Deploy pgAdmin on Railway which will then connect to your PostgreSQL database internally, rendering your local port restrictions irrelevant.